The first thing that I needed to do was to come up with a project. Through some brainstorming sessions, I came up with a list of ideas that might prove worth fleshing out. Deciding to work on a “task manager” application as my project, I needed to first find out if there would be interest in the project. To gauge this I used three types of research – a focus group, a literature review and an online questionnaire.
The focus group was small and informal but provided valuable feedback. Everyone in the group admitted that they used “task” and “to do” lists regularly, but had mixed feelings both about their effectiveness and their usefulness. This helped to give me a direction that I wanted to take with the application.
For the literature review, I focused my research around one book that proved to be incredibly insightful into what makes checklists effective. In his book, the Checklist Manifesto, Atul Gawande follows the history of the checklist from its formalization by pilots through its use today in operating rooms around the world. One thing that he realized is that checklists are only effective if the user refers back to them. If they write them and then put them by the wayside, they lose any value that they might have had. This insight helped in locking down a direction for the application.
With the first two pieces of the idea starting to take shape, I devised an online questionnaire using Survey Monkey and convinced some co-workers and fellow students to take it. I used the survey to not only gauge interest, but also to get a glimpse into how people saw the information that they were trying to capture with their lists. By showing them different schemes for informational structure and asking them to rate how effectively the presentation of the information related to its importance, I was able to discern a clear pattern. The respondents often wrote their lists in a “stream of consciousness” format – i.e. writing it down as they thought of them – but acknowledged that this was not the best representation of that information.
The problem and proposal
I distilled the information from the research to three key points:
- People do use lists to track what they need to accomplish
- Referring back to said lists is crucial to success
- People often do not write their lists in a way that makes the most sense
With those key points laid out in front of me, the problem was easy to see:
“People make lists, but they don’t return to them, even though doing so would prevent mistakes”
So I hypothesized that if we created more user engagement through design and gamification principles, people would refer back to their lists more often and have fewer mistakes, thus being able to accomplish more.
Now that I had an idea and a direction, I set about the task of creating an application that would address these issues.
In my many years in the restaurant industry, I made hundreds of thousands of lists. Chefs know that to insure service goes off without a hitch, it is important to have everything you need set up ahead of time and in front of you. This mentality is known as “mise en place” and chefs live and die by it. One of the key aspects of making list with this method is breaking everything down into the smallest possible component. Doing this breaks tasks that may seem daunting into little bitty pieces that are easy to swallow. If I applied this to making task lists, I realized that I could present users with a much better visualization and breaking down of their task.
One of the things that I realized while learning front-end development is that JSON data is almost identical in structure to how mise-en-place lists are written. In both one starts with a top level object that then has other objects, or tasks, as it relates to this application – nested within them. One of my first concepts for visualizing data in this fashion was to create nested lists. These lists would show which tasks were sub-task with indentation. This approach was very straight forward but it did create a bit of confusion if a lot of task were deeply nested. As I wanted the ability to nest tasks as deeply as the user felt was needed, I saw this as a short coming.
To address this I devised a scheme where each top level task would be shown as a card that listed only a preview of the first couple of items. The user would then tap on the card to get an expanded view that made all sub-tasks visible. In this scheme the information would be visually grouped making it easier to distinguish between the various tasks.
“While we build our lists from the top down, they need to be accomplished from the bottom up.”
Immediately I realized that both of these approaches did not address the major advantage of using mise-en-place as the guiding philosophy: when tasks are broken down to their simplest parts, the simplest parts are the first priority. To address this I conceived a structure for the app that consisted of three parts.
The user would need to make their lists in the manner that they were accustomed to – from the top down.
The application would then create a view that showed which items needed to be accomplished first – from the bottom up.
The application would then present the data in a way that was visually engaging.
To get a feel for the app, I designed a paper prototype. Doing so gave me some great insight into how the app would feel when in the hands of a user. It also has the advantage of stripping away all of the technological assumptions that can come with digital prototypes and letting me see the raw interaction with the app. I learned that the application, at this early stage, needed to address input and editing more fluidly. In the first iterations adding tasks was done on a separate screen, which took the user out of the flow. With this in mind it became more obvious that the application should adopt the “card” style look. This gave the advantages of better visual groupings and the ability to maintain the flow.
With all of the lessons learned from the research and the paper prototype, I set about creating digital prototypes. The first iteration addressed lots of the visual issues that had come up, but still needed work to address the flow issue.
With the second iteration I took a different approach to the editing problem. Instead of hiding all of the functionality in a hamburger icon and small top menu, I decided to go in a bolder and more radical direction. Considering the goals of the application, I decided that it was worth using screen real estate for a dashboard. This addressed the issue of editing by having the options visible to the user. Due to the fact that it would need to take up a good bit of room, I decided that here would be an excellent place to incorporate the visuals of the application. This lets the user see at a glance the state of the tasks that need to get done. This also has the advantage of not hiding the visual aspects on some other screen where they are less likely to engage the user.
These are the latest versions of the application mocked up to give a feel for what the actual app would look like.