Designing a time bank
Imagine TaskRabbit without money. A system where a user accrues time for favors completed and pays for favors with that accrued time; a time bank.
Design process
The first step was identifying the core users and tasks. The user personas for this system break into a person seeking help with a task, the client, and a person looking to help out and accrue time, the helper.
Given those users, the tasks break into two, ironically, temporal situations: immediate and scheduled work. In the case of immediate work, there is an immediate need a client is seeking help with and the potential for on-call helpers, given the potential of specifying an availability schedule as a helper. Scheduled work is ideal for clients that are planning ahead, maybe for a long-distance birthday surprise or help with a party, this will also benefit from some form of availability schedule for helpers. The secondary task for the client, is paying for the work completed.
With the tasks for the client fleshed out, I started considering how to communicate the monetary system to the user. Time as actual currency is a novel concept for compared to most systems, so I explored potential models to communicate accruing and spending time.
Prototypes and testing
I started by testing diverging designs through the client tasks with paper prototypes. The paper prototypes served as a way to discuss the language and iconography used within the design. The concept of time as money led to the suggestion of monetizing time as “bucks” in a later prototype. The possibility of opening up a task for bidding instead of selecting a helper based on a set cost was discussed. Additional variables for the client to assist with the helper decision were reputation, location, and throughput/efficiency.
The divergent designs explored tone and structure, where some designs were meant for a portrait orientation due to their dependence on lists where as other designs were more playful, depending on icons and large buttons to communicate interactivity.
With the feedback from the paper prototype in mind, I took to POP and created a click-through prototype for the finding help task using the button-heavy design as it was the most favored by testers. I tested 3 iterations of the POP prototype. From one iteration to the next, there were several changes made based on user feedback. The monetization of time as “bucks” was tested and failed as a concept despite the suggestion from several users primarily because users were confused what bucks translated to in terms of time. Though many users thought the icons by themselves were cute and understood what they meant, they expressed that they would be more comfortable with a label to clearly indicate what the chores were.
Phrasing was the trickiest part, since a spending time is a colloquialism and if you really think about it, the client is saving time in the realest sense as they are not wasting time on the chore they are hiring a helper to do.
The biggest point of debate was how to concisely express spending time, the task where a client is hiring a helper for a chore in exchange for accrued time, versus earning time, where a helper takes on a chore for a client and will accrue time as a result. The phrasing was the trickiest part, since a spending time is a colloquialism and if you really think about it, the client is saving time in the realest sense as they are not wasting time on the chore they are hiring a helper to do. On the flip side, the helper is earning time because that is the monetary system in the app and it is through the completion of helping another that the helper can become a client. Ultimately, the decision was made to consider the action from the users goal. A client is looking for someone to help them, they are hiring someone. While a helper is looking to earn time in their bank.
Still to come, final workflow diagrams and wireframes based on user testing…
