Where everything counts

Designing Goodwill — the app that everyone thinks of but no one should have to use.

Being in a relationship can sometimes cause arguments. A common source for this is the inequality of taking care of things at home. This app should help you and your partner to keep track of who does what at home as well as giving each task a score so you easily can tell your partner that he or she is behind.

Process

Even though I used the traditional design process in this project I choose to focus more on the UI part in order to gain experience in how to make animated UIs. That said, every design project need user input, so that’s where I started.

Design process

Research

This is an area where I have a lot of experience myself, being in a relationship for the last 16 years, but i still I made sure to get a perspective on the topic from other people. Before I started to gather data I made a decision to narrow down the the research to only include people that are in a relationship right now in order to get more recent behaviours rather than imaginary old ones.

Interviews and findings

My initial idea was to find out how people feel about what they contribute to the household and how their mental concept of an imaginary scoring system works, especially when it comes to spending points such as buying something for themselves or going away from the family. However, I soon realized that users showed more frustrations related to the fact that the other party did not realize how much they actually contributed in household tasks.

“What she means by cleaning the bathroom is not the same as I”

Many users said that they had some kind of deal with their partner of who does what but that it was not documented somewhere. This could lead to different understandings of who did what and create some issues when it comes to definition of a task

“I never get credits for that”

In most interviews the person mention the issue with the other partner not noticing or giving credits for work that he or she did. Meanwhile, this was not something the person wanted to bring up as a problem since it could be a source for an argument. This would later become one of the main problems that I wanted to solve in this project.

Define

Affinity map

In order to sort my findings I collected all the data into a affinity diagram, which soon made me realize that most issues sooner or later could cause an argument. That’s why the main motivator of the problem statement is to limit the risk for an argument.

Problem statement

People in a relationship need a way to get a mutual understanding of who does what in order to limit sources for arguments.

Persona

Moving forward in the define step I started to design a user persona. This resulted in Maria Keys, a 30 year old female from Barcelona, Spain. See more information about her in figure 2.

Figure 2, User Persona (Image: Unsplash)

Ideation

To kickstart the ideation phase I used a couple of crazy 8s just to drain my own head of ideas of how this problem could be solved. After my own evaluation I found out that the very basic solution to this problem is the following functions.

1. Add task
2. Assign task
3. Set task score
4. Set task as done
5. See stats

Figure 3, Crazy eights

User flow

In the picture below (figure 4) is the very basic flow of creating a profile to adding a new task. Since the assigning of tasks will be a central part of the application I choose to explore different interaction models of how this could be done. This was my main priority when moving in to the prototype phase.

Figure 4, Basic user flow

Prototype

When moving in to the prototype phase I soon realized that the in order to test the assignment of tasks I would need to use colors. To get the main user flow right I still ran a couple of iterations of how the whole user journey should be designed. Tests showed that the need for buttons in the nav bar was much more limited that I initially thought, which allowed me to scale it down from 5 to 3. Also, from start the paper prototype had an approval step where one part had to approve the other part’s tasks, luckily it turned out that users actually trusted their partner so the need for the function was limited. The fact that users did not understand or felt a need for the function after getting it explained made the choice to remove it even easier.

Figure 5, Paper prototype

Style tile

Before starting the test of a prototype with colors I decided to define the style tile for the app, this would allow to get results that also would be valid in the desired color scheme.

I wanted the app to be visually simple and create a sense of order and accuracy without being boring. In order to support the assignment of a task with colors I choose to go for two primary colors, one for each partner.

Function vs appearance

When testing how colors can be applied to indicated ownership of a task I found out that users felt one thing when just showing one task without it’s context compared to showing the same task in a context with several tasks, see pictures below.

Figure 6, In this picture, users preferred the left color indicator

Figure 7, In this picture, users preferred the left color indicator since they felt that the right one became too colorful

So, to avoid creating a messy and too colorful overview of tasks I followed what users said and continue to work with an indicator with as little color as possible.

Interactions

In this project I choose to spend some time on figuring out interactions with animations. I believe animations can help users understand the interaction model of the application at a much deeper level compared to just instant transitions between states and screens.

Assigning of tasks

So, the color indicators and main overview was done. But how do users interact with tasks and more specific, how do they assign a task to someone?

Figure 8, The typical three dots where you find more details and options related to the object

All user said that they would click on the typical three dots in the upper right corner to assign a task to someone. This is great because the functionality can easily be placed there. However, user felt that this was a bit to many clicks just to make a simple action of assigning a task.

Of course I wanted this to be easier.

Figure 9, Intro animation showing users how to assign a task without tapping the dots

By allowing each task to be able to swipe horizontal, the user can swipe it to either left or right in order to assign it to one of the partners. In order to make the task feel “movable” I gave it some drop shadow and as soon as the swipe starts the color of the assigned partner is showed below the task. This would of course be something that has to be shown to the user the first times he or she use the app. Se animation above (figure 9) of how I want to show this the first time the user see the overview of task.

Setting a task as done

Another feature that I wanted to be really simple was setting a task as done and to get a good understanding of who completed the task .

Of course, also this can be accessed in the tree dots but I wanted this to be accessible directly in the task as well. The solution in the picture below (figure 10) shows how the done icon change color depending of who owns the task. I discovered that I had to be really careful with the light grey color of a not done task since this could look like it was already done.

Figure 10, how to set a task as done

Seeing your tasks assigned to you

Tests showed that user expect to be able to see their own tasks by simply pressing their own name in the overview. In order to make the transition to this screen more understandable I wanted to give the user a feeling of where objects actually are and how the reorder in order show only task that are assigned to that user. The animation below (figure 11) should hopefully increase the level of understanding and the relationship between the overview of all tasks and the overview of tasks assigned to one user.

Figure 11, reordering of tasks

Seeing stats

The stats screen should show the balance between the two users and quick give you an understanding of how each partner have performed the last weeks. In order to make this consistent with the overview screen I choose to keep as much as possible of the layout from the overview, keeping the vertical separation between the two users.

Nav bar icons

When designing the nav bar icons I wanted to them to visually remind the user of the content under each page. Since the visualization of data on the stats page is not very common this icon could cause some problems. However, the text below the icon help the user to find its way the first time.

Adapting the design to Android

For the app to feel a bot more android I choose to remove the nav bar labels. In my opinion I would have done this on iOS as well since it give the app a cleaner appearance.

Final remarks

Building a prototype in principle is a mess

I have felt that invision and sketch is to limited when it comes to transitions and animations. That was why I choose to make the full prototype in Principle this time. But, this turned out to be far more challenging than I expected. Mostly because of how text and general editing is transferred from sketch to principle. Everything has to be done and properly named before moving in to Principle, if something has to changed you simply have to go back to sketch, just to correct a typo.

The mess of principle

Keynote is king

In my limited time as a UX designer I still believe that keynote gives me 90% of the functionality of both Sketch and Principle for those smaller projects that does not require a functional mockup or that is not going straight to production.

The beauty of keynote