Designing the Task Timer app #IDXonline

Task Timer has stemmed from a real life need to be able to accurately keep track of a myriad of tasks throughout the working day. Existing solutions felt lacking: some operated smoothly in the background analysing application usage, but couldn’t tell what project you were working on, or for whom. Some were cumbersome to set up and some slow to operate. All the solutions I tried felt like work: as if the tool was getting in the way of tracking what you were doing, rather than facilitating it.

The at the core of Task Timer is the assumption that if you touch a task, you are spending time on it, and you can only do one thing at a time. This translates directly to the interface:

  • Create a task and it is already running, even before you have named it.
  • Create another and the focus shifts to the new task, just like real life.
  • If you need to switch back to a previous task, simply touch it to activate its timer instead.
Task timer makes accurately tracking your activity easy.

When combined with supplementary features which allow you to edit timers and shift time from one to another, Task Timer provides a simple, fast way to keep accurate records of your days activities, because after all: in many walks of life, time directly translates into money.

Early storyboard showing the problem

The design process was a matter of taking these core concepts and bringing them to the mobile form factor. Action button positions were chosen for operation with a thumb. Limited screen space meant that task detail edit forms could be abstracted away to separate screens or overlays rather than trying to fit an edit form within the main interface.

Early iterations explored integrations with third party apps such as Github and Trello, but these were quickly shelved in favour of a more modest, achievable project.

User testing was highly informative: things that seemed very obvious to me, as someone who was very familiar with the concept, were not at all obvious to users. This demonstrated the constant need for system state messages. Users need to be shown what is happening and what they need to do next. This is actually very challenging to do in a prototype for a dynamic application. The lack of animation and dynamic change can actually hinder the testing process.

Another area which was illustrated by user testing was the use of familiar concepts and visuals. For example, using an ‘X’ on a delete button was a mistake — users consistently tried to use that button to close dialogs.

The prototype of a list of tasks for timing

Task Timer is still a living, changing concern. The prototype design has highlighted firm improvements that can be made and I look forward to bringing these learnings to life.

The current, live, working version of Task Timer is available on github for anyone to use to track their time.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.