Empathize

Our group created four Personas when designing an app. We looked at a white collar family man, a working mother, a freelancer, and small business owner. We created an empathy man for each of them (summarized below) in order to get familiar with their pains and priorities.

The statement below was created from the root common problems our users were facing.

Each team member created five to seven "who, what, why?" statements and then we clustered them together by common idea's. Each large clusters below became a major feature, smaller clusters were put into future features aka the backlog.

Now we have a much clearer idea of what kind of solution would help our users.

Define

We had a general idea of the users needs, now we needed to check what needs were not being met. I did a market analysis and looked at several popular application that focused on one of the key components above. I found that Task/errand trackers apps can't collaborate well, and collaboration apps don't have the extensive features that task trackers have.

So, with this information we set out to design an app that could do both. That way the users would not need two or three specialized apps to resolve their needs.

We think this is a big deal!! and we wanted to confirm it. So we needed to gather more information. In this step, we dove into using our empathy insight skills by conducting a 10 question survey via Survey Monkey. We were interested in learning what a person’s typical day looked like, frustrations when running tasks, and what methods they use to remember tasks.

Our survey group was aged between 19-69 years old, and this was about 37 people.

Some key insights from the survey is that a significant amount of people do share their tasks with others and significant amount of users run errands for others.

The most interesting part was that most people spent little time planning their errands and don't always feel like they were efficient at doing them.

This data provided this information that users needed a more efficient and easier way to keep track of their tasks.

To have a complete picture, we needed more than just statistics. Therefore we interviewed ten people on how they manage their tasks and errands.

We listened to their unique perspectives and found that people don't always have time to figure out where and when they need to go. Couples can have difficulty communicating between their busy schedules. There is a clear need for a more efficient way to manage tasks and errands.

To brainstorm features for the product road map, We created How Might We and Point of View Statements using insight from our research and stories. Some key insights we found that overlapped in most interviews was that people run their errands 1-5 times a week. That's a lot of times to be running errands. Most people don't have time to plan out their errands and they worry about them on the go. That can be stressful. Participants try to remember errands and locations via memory or pen and paper. That can be a problem!

As a next step, we started to draw some ideas and sketches to illustrate stories of our personas pain point.

As a next step, we started to draw some ideas and sketches to illustrate stories of our personas pain point. Upon discussing the data we received, we selected features we felt would best fit our users needs:

Here we have brought our persona's and research together. Each persona need is backed with both quantitative and qualitative data. Now that we have a clear picture of the problem.

We agreed that main idea is DOing tasks and getting them DONE. this is how the name of the product DODONE was born.

Ideate

We graphed the high-level workflows for new and returning users. This would become the blueprint architecture for the app's screens and the roads between them. By graphing the screens this way I was able to find several gaps and overlaps in our early design.

For example: Originally after logging in, the user would be sent to the dashboard. We changed this after seeing that most task required the user to go to the daily tasks screen in order to complete. Saving the user a click.

We looked as various app screen in order to help define how our app would look. Whenever we would get stuck designing the screens, we could return to the mood boards for idea's.

We put our sketches together and found out changes needed to be made to our flow. We simplified the new user walk through and combined the tutorial and call to action on their first page. We wanted to guide him with “conversational text or question”.

Another interesting feature we decided to have is picture splashes that will appear on the screens, that will invite / remind / help user to make another task. For example on the calendar “mother birthday in 2 weeks” - this will preview the splash with moms photo with link to have shopping for her Birthday.

While discussing the splash pages, we realized that this is our monetization mechanism and we added another user group.

We switched between 3 styles, but settled with this one below. We moved away from brighter colors because we expected our users to use the app early in the morning and late at night. The colors had to be easy on the eyes at all times of day.

Prototype

After figuring out the layout and the style, we updated our lo-fi screens to hi-fi. After completing the screens and connecting them together, we had a prototype ready to test the UI. I created the components and then placed them in the appropriate place. This allowed me to change every iteration of the asset by editing the master component. I also added component states to organize and simplify many components.

We exported the screens to my phone for users to test it out.

Testing

We went to a busy Starbucks and approached people for testing. It was very good experience and most everyone was happy to help. one team member would ask the users to perform a task, while the rest of the team would take notes and ask questions. afterwords we thanked them with a Starbucks gift card.

The app was very well received and the prototype's hi-fi screen's made the users think that they were testing a fully programmed application. Half way through we had to explain that we were only testing the UI and that the prototype was a series of slides connected with linked buttons.

Based on our data, we created a table that helped us discover that most of the older people skipped the video tutorial, however the younger demographic wanted to see the video tutorial. Older people successfully went through the creation of tasks.

After testing, we realized that since our app navigates our users from errand to errand, it would need voice activation for the users safety. That way our users could keep both hands on the wheel, but still control the app.

I.E. if you have a reminder to get groceries and you drive near your specified grocery store, the app could suggest stopping to completing the errand now.

We grayed out and disabled the achieving button while the user lacked any data, and then highlighted it after they complete the tutorial. That way users don't enter the achievement screen before they have any completed tasks.

We added more functionality to the map. Testers indicated that they would like an interface to review and edit their errands based on location. So we edited the map view to slide up the users errand list from the bottom.

One of our users was confused and thought the separation line was a text entry. There was a precedent we did not notice before testing. We used flat design and all our text entry spaces were straight lines. Rather than change the whole style, we removed the confusing line.

Second Testing

In round 2, all the edits we made seemed to have alleviated concerns and impacted positive results. We adjusted two main points of confusion.

The video tutorial: Because few people skipped the video tutorial, we decided to give a brief overview before the login to the app. The overview explain the limitations of the prototype and we reworded the script to be clearer.

List sorting: There was a note about the prioritized list that we had before but people asked for a time sort instead. So by default it was by priority before and now its by time. And we edited the icon of the sorting.

At the same time, from an accessibility standpoint, we thought that it would be beneficial to have customization options and created a light version of the DoDone.

Promotional Video