The Story of the Development of a Productivity Solution

Grant Davis
10 min readNov 20, 2016

--

Introduction

Last year, I set out on a journey to study Interaction Design.

https://www.coursera.org/specializations/interaction-design

How people relate to things has been interesting to me ever since I took a course in college from Donald Norman. The topic of user experience comes up frequently in my engineering work. After studying various disciplines in the first seven courses, the final capstone project brings it all together to design my own solution.

This is the story of that process.

We began with a choice of “design briefs”. I went for “Time”, with the mission to “Redesign the way we experience of interact with time”.

Need finding

The first step was to observe what people do and need, and to find the successes, the breakdowns, and opportunities to improve.

For practicality, I found people nearby which are generally working professionals. A sample of three subjects cannot provide a very broad view, but I tried to get some variety. I chose ones who have full-time jobs, but seem to enjoy life, and have control of the balance with work. They are interesting to learn from. It would be satisfying to find ways to further improve their lives.

I started with the subjects at their desks at work, because that is a common situation for them. I asked them about things they needed to remember, how they did that, and how it worked for them.

Needs for remembering

Out of those interviews, I started to find needs and patterns. I started narrowing down the objective to: how to help people remember to do things.

People forget to do things that are important to them. They generally do not use complex solutions. They want to enjoy their lives, and not spend time using tools. They take notes and forget the notes. Reminders sometimes don’t get set, and then they are unreliable. Human memory is a great tool, but it has limits. Distractions lead us in other directions.

A good solution needs to be extremely simple to learn, simple to use, easily available at all times, transparent in their lives, partner with their memory, and be reliable. It needs to help remember. It needs to be friendly, and not annoying.

Out of need finding came my statement of purpose:

“Many people’s lives are very busy and they struggle to do all of the things that they want to do. They would like a simpler life where they remember to do things, and spend their time on the things that are meaningful to them.”

Ideation

Next, it was time to come up with some ideas. First, some brainstorming about lots of opportunities for design innovation. I won’t list everything, but these are three of the best foundational ones that carried forward into the design:

  • Many people commonly make notes to remember. Sometimes they forget to look at the notes. They need a way to remember tasks that are currently put into notes.
  • Project management systems emphasize planning as necessary to achieve goals. A person needs a way to plan and prioritize at the beginning of a context (work day morning, after work, etc).
  • The human brain is an important part of remembering. Some people at some times are able to handle all of the tasks and appointments in their heads. That probably happens more when the complexity is low. A person needs a way to refresh their memory about the most immediate part of the plan, to form a synergy between their brain and the tool.

Next, what are existing solutions?

There are many applications for task lists, and reminders, and calendars. I looked deeper into some of them, like Google Reminders, Franklin Planners, and Trello. A lot of good ideas come out of those. It would be good to combine the task list with the calendar. One should regularly review and prioritize. A short task list helps un-clutter your memory, focus, and get important things done. But this leaves questions about why people mostly use just a calendar and a notepad. And they still forget things.

Google Reminders
Franklin Planners
Trello

I also thought about more remote examples. My gym bag sits in the hallway, on the path to my car, so I remember to take it to work, and it is there when I need it. The fuel gauge in my car reminds me continuously as the need to get gas increases, so I can coordinate a gas stop with my other activities. A Sleep Cycle app matches my wake-up time with my level of sleep, and then gives a gentle increasing alarm. These ideas also feed into the solution.

Gym bag “on the path” reminder
Fuel gauge reminders
Sleep Cycle reminders

Storyboards

Now it is time to look at how to solve the problem. The basic plot of the story in a storyboard is to show the problem, a solution, and satisfaction. We want to outline multiple solutions to pick the best parts to go into the design. Here is the one I later decided to proceed with:

Paper prototype

Now, I mock up the applications on paper with a fat pen. Not too much time or detail. The purpose is to quickly get the basic design ideas in front of users.

Heuristic evaluation

The next level of testing is meant see how users interact with the designs. The paper pages are flipped and stacked as the user points at buttons, to mimic the real operation. I am looking for basic problems, and categorizing them against “Nielson’s Heuristics”.

Nielsen’s Heuristics

Reference: https://www.nngroup.com/articles/ten-usability-heuristics/

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
(Read full article on preventing user errors.)

Recognition rather than recall

Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
(Read full article on recognition vs. recall in UX.)

Flexibility and efficiency of use

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

My Heuristic Results

Many details came out of the heuristic evaluations on the paper prototypes. Some concepts needed explanations. Users were confused in some places about what buttons were for and what to do. There were missing indications of the status. There were missing controls for undo. There were functions that were needed that had not been conceived.

Many of these issues were addressed in the design going forward. Some specific improvements:

  • Formally plan the navigation paths and buttons
  • Standardize the top bar and controls
  • Distinguish the page title for “New Task” from “Edit Task”
  • Provide an introduction, and some guidance for the meaning of “context”

Skeleton Prototype

The next iteration of the prototype started to clean up, using PowerPoint, and applying the learning from the previous testing. At this point, the first design idea was left aside, in favor of the simpler second idea.

Working Prototype

I was then heading for a semi-working prototype that can be used for more detailed testing. It was a matter of drawing each screen, and some different configurations of the screens. These were loaded into a prototyping tool online from inVision. Basic definitions of the active regions for buttons, and actions were added over the images online.

Some of the pages of the first working prototype

Prototype Testing

This form of prototype is very restricted. There is no database for the user to enter their own tasks. It does not function through many paths in the application. The testing needs to be targeted and planned. A careful script is used, requesting the user to imagine the situation, and to perform very specific tasks. And carefully thought-out questions.

Users were given the prototype on a phone, and instructed. They were observed and recorded.

The testing uncovered some specific breakdowns and pain points. There was confusion about some of the buttons. Those led to several updates in the design, visible in the “A” version later.

A/B Testing

One particular problem area identified in the previous testing was the confusion about the meaning of the “drag item” icon. There was a difficulty to re-order the list (which is the purpose of this icon).

This element was chosen for a controlled experiment to try to improve it.

Users were tested online through a service by Usertesting.com. Given the absence of the experimenter, the instructions needed to be polished and focused toward the very specific task of moving a task item in the list. That worked well.

The hypothesis was that to move an item in the list, the users would find the new icon more frequently than the old one.

Actual results went a bit different. With a sample size of only two in each condition, the result is not statistically significant, but it was dramatic. Both users of “B” clicked on the icon, whereas, both users of “A” tried to drag on a position to the left side of the icon.

This is a very useful result. Users were expecting different responses to the two icons. That might be from the outline drawing, as was improved in other buttons. It opens the possibility of more tuning and testing. At this point, I have to go with the A version, because it is not useful to click to move a task to one of multiple positions. I do think that removing the up-arrow at the top and down-arrow at the bottom is useful. This was from a user suggestion out of earlier testing, and it went into the B version.

Final Design

Here is the final design, at the end of the course. It has improved considerably through the process, though it has a way to go to get to the app store.

Note that the design still looks very basic and monochrome. That is partly intentional, and partly limited by time. It is meant to be as simple as possible.

You can try the inVision prototype yourself:
https://invis.io/XP99WIPD5#/202955694_Slide17

See “In-Context Lists- the movie”
https://youtu.be/dyZFiHyB3Ko

What Was Achieved

  • A simple application
  • On the phone that is conveniently with them
  • Very similar to existing solutions that people use
  • Divide and simplify tasks into contexts == Actionable categories of time and place
  • Coordinated with other related activities
  • With a unique concept of reminders for context planning
  • Reminders reliably trigger at context change (context-by-context, daily, leaving or arriving, and within a time window)
  • Review and prioritize
  • Puts the task list “On the path” through life
  • Coordinate with human memory by promoting a short must-do list, and off-loading the rest
  • Flexible alerts that come accurately at the correct location and window of time

Some Future Development Ideas

  • Actual coding
  • Synchronize the data with their other computers and devices
  • Integration with notepad
  • Integration with calendar
  • Voice interface option
  • User appearances choices — “skins”

That is the story. Your comments would be greatly appreciated.

--

--