interactive prototype
jobs-to-be-done planning Designed: 2018 Product: Hireup Customer Audience:
|
"Profiles are are 'me in a nutshell', Plans are 'what we intend to do'.
We need a bit of both, to get the clearest picture across— of a person, of a job." Traditionally, a disability support plan itemises all of service options a person may need, and how they need them to be done. This can comprise instructions from medical professionals, preferences from the individuals, and third-party documentation for technical needs.
Even in the best cases, support plans can feel clinical, impersonal, and reductive. In the worst, they can be overwhelming with detail, and difficult to utilise. Some support-seekers may be reluctant to share details for privacy reasons, while others balk at the time investment of itemising their needs. On the receiving end, support workers feel saturated with detail, and find a complex plan confusing or intimidating. In this project, we aimed to find the heart of what made a support plan meaningful, and distribute those strengths across the product in the most effective way possible. |
Who benefits from a good plan?
We knew the existing implementation (a blank text area) was inadequate, so, rather than collect opinions on it, we interviewed folks about how their best client/worker relationships began.
These dialogues revealed that, like most jobs, it was important to be up-front about the high-level responsibilities of the role— but that too much detail at the early phase felt irrelevant, inappropriate, and unfocused. Support-seekers generally avoided filling out or updating lengthy documents, and most workers didn't read them anyway. |
How can we share information organically?
From the research, we knew that process and nuance were best learned on the job. A successful relationship was defined by open dialogue and feedback, so our tool could be most effective by promoting communication over documentation. We used a conventional recruitment process as inspiration, and planned detail to be rolled out progressively, as trust and interest were built. This gave the support-seeker privacy, and the worker the best context for each stage. The highest-level items (ie: "I'm looking for help around the house and transportation") could be posted openly, alongside with content that completed the profile of the user— their suburb, age range, personal interests. This would enable the worker to get a complete picture of their potential client, and make a confident self-evaluation about their ability to do the services required. From here, further specifics could be revealed as the two met for an interview. Here, the items in the profile could serve as talking points— exactly what does 'help around the house' mean for your life? If both parties agreed that 'meal prep', 'rubbish disposal', and 'pet care' were a go, they could discuss and plan a shift together that might involve those elements. When that shift arrived, the highest level of detail would become relevant and available for reference— Does the worker need a diagram showing how to collapse the wheelchair? A password for the wifi? Does the cat have preferences for one type of food over another? |
How can we apply what we know?
We wanted to categorise content as much as possible, so we it could be easily populated, referenced and leveraged by other features. By using predefined tags to code the areas of support, we can make it efficient for the support-seeker to complete the form, by choosing from a cloud of suggestions. Once areas are added to the profile, they can be pulled back out and slotted into a shift agenda, creating a helpful checklist for worker and client to itemise a day's work— this keeps expectations clear for both parties. The presence of coded data provides further options to explore future feature design, such as matchmaking ("You need a car, they have a car") or reward structures ("This worker has 500 hours of experience at [skill x]"). |