Story of an app

From needfinding to prototype

In the last month I developed the prototype of an app called Time For Tasks as the assignment for the final course of the specialization in Interaction Design of the University of California, San Diego, on Coursera (https://www.coursera.org/specializations/interaction-design).

My final result is there: https://pr.to/NYZMGL/.

I had to focus on a particular topic, Time. Basically, Time For Tasks is a calendar app but with some interesting new features. Among all, the possibility:

• to add an event to the calendar by scanning what an user wrote on paper, with an OCR functionality that converts it from paper into digital text that users can modify;
• to add a subtask to a main event and to manage the time needed to do it.

In order to have the prototype I had to follow a series of steps that summarize what I learned during the entire specialization.

I think it’s a good story to tell and a good example of the steps needed to produce an app that has value for the final user.

Step 1: Needfinding

I started not by jotting down an idea and beginning to design, but by talking with real users to find their needs.

I interviewed some people with busy work life in order to understand how they managed their work tasks and the time dedicated to them. My goal was to find if something could help them.

What I found was extremely interesting. People didn’t use only digital tools but also analog ones because in this way they could do things:

• easier and quicker (e.g. write a task on paper is easier and quicker than insert a task on a calendar app);
• in a more satisfying way (e.g. pull a real row above a task once it is finished);
• in a safer way (e.g. a paper agenda doesn’t get out of charge).

Each of these points was an opportunity for me (e.g. for new features of a digital calendar).

Another great area of opportunity was this one: all the people that I interviewed didn’t have a tool to manage the time needed to do activities to finish a task (e.g. doing a presentation for a meeting). This caused them a lot of stress.

Step 2: Ideation

In this phase I transformed what I learned from users in ideas.

Based on what I understood during the interviews, I jotted down 20 ideas of possible user needs that an app could satisfy, in order to give users the possibility to manage their work tasks and the time needed to complete them in a very efficient way.

I decided to focus on these two ideas:

• users need a way to transfer tasks from paper to their digital tool;
• users need a way to divide each task in subtasks and to manage each subtask separately from the others or as a whole.

I tried to find some inspiration from other apps on the market, not only strictly connected to the one I would like to build (e.g. Google Calendar) but also of different type (e.g. Scannable, an app to scan everything on paper and transform it in a digital, sometimes modifiable, object).

Step 3: Storyboards and paper prototypes

Each of the two ideas became first a storyboard, narrating a story that drove a user from a real need to satisfaction by using the app I thought, and then a paper prototype, that simulated, in a very easy way to make, the behaviour of my final app (and in particular of its innovative features).

I first made one storyboard for each of my two ideas.

Storyboard #1: Users need a way to transfer tasks from paper to their digital tool.

Storyboard #2: Users need a way to manage the time to do a subtask.

The next step was to build, for both of my ideas, paper prototypes that simulated each step of the two features of the app I had in mind.

Prototype #1: the page that simulated the Scan feature to transfer tasks from paper to a digital calendar.

Prototype #2: the page that simulated the feature to add a subtask to a main event and to select a time to allocate to finish it.

Step 4: Testing paper prototypes with real users

By seeing real users playing with my paper prototypes, I collected some issues about them that I translated in changes to do.

Before moving on, I conducted a test with a real user on my paper prototypes to find issues.

A real user playing with my first paper prototype.

First of all I asked her to use the Scan feature of my first paper prototype to scan a post-it note and to insert it as an event in the calendar.

Secondly I asked her to use the Subtask feature of the second prototype to add a subtask to a main event, edit it (changing the title, range of days and time allocated to finish the subtask) and then save it.

Observing her doing these activities, I collected some issues, things that I had to modify.

For example a major problem in the first prototype was that the user was unable to understand how to scan.

I collected some other issues from an evaluation, using Nielsen’s heuristics, that one of my peer in the Coursera specialization made on my two paper prototypes.

As the final result of this step, I had a lot of problems to solve.

Step 5: Going digital

It was time to create a digital prototype.

Based on the observation of real users and on what suggested by my peer, I listed the changes I would like to make in my prototype.

For example these were a couple of issues, each with its own solution.

Issue #1
The app does not provide a visual and audio feedback for the scanning/OCR recognition phase. So it is hard to understand if anything has been scanned or not.
Solution: I will insert a modal screen that alerts the user that his scan went well.

Issue #2
There is no support or contact form to ask for help.
Solution: I will introduce an help. In the help there will be also the possibility to contact via mail a customer service.

I began working on a digital prototype (just only one with both the features). To make it I choose proto.io, an online solution that permits, as written on the site, to “create fully.-interactive and high-fidelity prototypes that look and work exactly like your app should”.

First I made a digital prototype that only had just two screens completed, the home screen and the key screen for the functionality I would like to show (in this case the Scan feature). The other screens were placeholders to give the idea of the navigational skeleton.

Then I completed the prototype with all the screens. Here is my first complete digital prototype: https://pr.to/XF7Q5J/.

From this step on, I listed on a plan all the the things I had to do in the next following weeks in order to have full control over my schedule.

My plan.

Step 6: Testing digital prototype with real users

By seeing real users playing with my digital prototype, I collected some issues about it that I translated in changes to do.

Once completed my digital prototype, I did in-person tests with three people: all of them had busy work life and used calendar apps on iPhone to keep track of their events, tasks and appointments.

First of all I developed a protocol to do the test. Then I invited the three persons, one at a time, in a small meeting room to do the test. I recorded the video of each session, with the permission of the users.

These were the steps of the test session.

Welcome and explanation of the test

I welcomed users and, first of all, I explained the aim of the test, stressing especially on the fact that I was testing the app, not them.

Then I asked them to sign the consent form to permit me to record the session.

Questions

I asked some questions, from general to more specific topics, to collect some information and as an icebreaker.

First page tour

The users had an iPhone, on the table in front of them, where there was my prototype already opened on a page simulating an iPhone home screen.

I asked users to click on the Time For Tasks icon on the iPhone home screen.

I let users explore the first page for at most three or four minutes. I asked them to think aloud trying to figure out for example what’s the app was for and what they could do with it.

The tasks

In this phase I asked users to do some tasks. I read tasks aloud but I also gave users a document with the tasks to do.

I asked users again to think aloud while they were doing tasks. These were the tasks:

• Insert an event on the 20th of September, from 10 to 11 am, by scanning a post it.
• Change the title of the event in “Meeting with the board”.
• Then insert in the event a subtask “Make a presentation” and assign to complete it 1 day, 6 hours and 30 minutes.
• Save the event with his subtask.
• Finally, erase the event.

Conclusions

I asked users if they had some questions for me and then I shared with them the goals of the study.

Then I thanked users and escorted them out.

Finally I stopped the screen recorder and saved the video file.

It was incredibly interesting to see people using the prototype of my app. I found a lot of issues that I decided to fix in a following version of my prototype. These were two examples of issues I found.

All users, when they had to access to the Scan feature (or to the Add an event feature) from the popover menu, tried to click on the word Scan (or Add an event) and not on the icon, which was the only thing active.

For the first and second users it wasn’t so clear how to insert a subtask for an event. The first and second user clicked on Add a subtask before modifying the title and the time allocated to the subtask (which was the flow I had imagined). A subtask was added but without title and time.

Step 7: A/B Test

I did an A/B test on usertesting.com to find if there were some differences between two versions of my prototype.

From all the issues found from the in-person tests, I selected one: all users had problems to access to the Scan and Add an event pages from the popover in the Day view. This is probably because in the original design only the icons were activated and not the text nearby (and users tried to click on it).

So I prepared two different versions of the propotype. The A version was exactly the same version with which I did the in-person tests. In the B version I made the texts Add an event and Scan active so users could click on them, and not only on the related icons, to access respectively to the Add an event and Scan pages.

This was my original design (A): https://pr.to/XF7Q5J/.

And this was my alternative design (B): https://pr.to/N7JW4X/.

On the left: original design (A). On the right: alternative design (B).

I uploaded the two versions in usertesting.com, a site that permits to try apps and prototypes with real people having back from each a video in which they did the tasks that I asked them, speaking their thoughts while they were doing them.

Two users tested each version of my prototype (four in total).

The tasks they had to do were the same of the in-person test:

• Insert an event on the 20th of September, from 10 to 11 am, by scanning a post it.
• Change the title of the event in “Meeting with the board”.
• Then insert in the event a subtask “Make a presentation” and assign to complete it 1 day, 6 hours and 30 minutes.
• Save the event with his subtask.
• Finally, erase the event.

They had also to answer some questions (e.g. What frustrated you most about this app?)

I watched the four videos focusing first on the A/B screens. I had a very strong evidence that the redesign was better than the original as shown in the following two images.

Test A — User 2: she faced some problems in understanding that she had to click only on the Scan icon. She tried first to click on the word Scan, then on Add an event (as you can see in the image), but nothing happened. I sensed from her voice that she was a little upset (she repeated different times: “Wait, wait, wait. How do I do this?). Then she calmed down, read again the instructions and finally clicked on the Scan icon.

Test B — User 2: he didn’t have any problem but it’s interesting to note that he clicked on the word Scan. If he would have tested prototype A he couldn’t have accessed to the next step of the task.

So I decided to maintain the change also in the final version of my prototype.

Step 8: Finalizing my prototype

I made all the changes to my prototype in order to resolve all the issues I found.

Cause I asked users to do broader tasks, other issues emerged from the A/B test that partially confirmed the ones I found during in-person tests. I decided to do all the changes emerged during both the in-person and online tests.

For example the task that most stressed users in each test was adding a subtask to a main event. From the information collected I decided to redesign the whole feature.

On the left: original design for adding a subtask. On the right: redesign.

In the original design they didn’t understand:

• where to digit the title: they didn’t realize that they had to type over Insert a title for the subtask;
• the time format;
• that, after digiting the title and the time, they had to click on the Add a subtask button to really add the subtask (instead they tried to click on the + icon, which was purely graphic).

In my redesign:

• I modified the icon that indicate the subtask;
• I added real input fields where users have to digit the title and the time of the subtask. The instructions are above the input fields. I modified accordingly the way to insert the title of the main event;
• to save the subtask, users have to click on the main Save button;
• I added a better explanation of the format of the time allocated for a subtask;
• I changed the text of the button Add a subtask in Add another subtask and I deactivated it so the user can’t click on it.

Conclusion

And finally here I am. This is the final version of my prototype: https://pr.to/NYZMGL/.

The steps I had to do in order to have it were the following:

• interviewing potential users in order to find real needs;
• jotting down ideas based on those real needs;
• selecting some ideas;
• transforming selected ideas in storyboards and then in paper prototypes;
• testing paper prototypes with real users and with experts, using heuristic evaluation, in order to collect issues;
• creating a digital prototype resolving those issues;
• testing the digital prototype with real users and doing an A/B test for a specific problem in order to collect some other issues;
• refining the prototype by solving those issues.

Done! To promote my prototype I did also a video:

And a Facebook page: https://www.facebook.com/TimeForTasksApp/.

In general, the interaction design specialization was a really good experience from which I learned a lot.

In particular, because I work as a product owner, I think I will try to follow the steps I showed in this post in my future work projects.