UX Design: Rapid Paper Prototyping

Problem Discovery and Mobile Application Design

Zonal ReCall is an easy-to-set-up mobile app designed to remind a user when she can appropriately call contacts in other timezones, providing a smooth flow into the act of achieving a successful call.

Project 1 at General Assembly
Client:
Jill Parish, GA UXDI colleague
Sprint Number: 1 of 2 (Sprint 2)
Sprint Duration: 3 days
Methodology: Problem exploration, user interview, concept mapping, empathy diagrams, storyboarding, user-centred participatory design, user flows, screen flows, sketching and rapid prototyping.
Tools: POP app, Google Slides, pen and paper.

Introduction

This is how the project started…

Brief

Jill is a very busy person seven days a week, but as an expat she likes to keep in touch with family and friends by speaking to them. Unfortunately, the timezone difference creates a limited window of opportunity to get in touch and she often forgets to call, resulting in concern by both parties for mutual wellbeing.

Problem Exploration

To kick-off the project, I began by exploring who Jill was and what activities made up her day-to-day. A 1:1 interview was conducted, noting down her answers visually in a relational concept map of her problems:

We traced an empathic problem path (bold outline) very quickly

It was soon clear that being able to speak to her mother on a regular basis as an expatriate was important to her as she cared deeply about her mother’s wellbeing. This also applied vice versa.

However, because of Jill’s busy life throughout the week, it proved difficult to stay in touch due to a combination of the difference in timezones and their respective busy schedules. I delved deeper to understand the flow in the core activities when attempting a call:

In addition, it was important to note that Jill held the responsibility of caller in the relationship due to their personal arrangement, therefore the onus was on Jill to initiate communication.

The below illustrations summarise their frustrating situation when Jill forgets to call her mum and remembers at an inappropriate time:

Most of Jill’s mum’s available time to speak is when Jill is asleep
Most of Jill’s available time to speak is when Jill’s mum is at work

On a broader level, Jill finds it too difficult to calculate the time difference between her and her mum, particularly if either of them are traveling outside of their usual timezones.

Design Hypothesis

This is how I connected the problem to a solution…

As there is already technology involved in the calling aspect, it seemed likely that there could be a technological answer to her problem. I defined a concise design hypothesis that could potentially solve it:

A reminder app integrated into her phonebook with easy timezone setup. Clear prompts can enable her to stay in control in the moment and allow her to keep in touch with her mum regularly.

To help sell the solution, I pictured it in the form of a storyboard:

The solution storyboard clearly shows two important interactions with the app: 1) setup stage and 2) notification stage

Competitor Analysis

Due diligence was important here from a competitive standpoint. There are plenty of reminder apps already available in the app store including ones integrated with the OS and ready to use from the outset (e.g. Google Calendar).

IFTTT is a shotgun approach to triggering events based on user constraints
No existing apps specifically calculate time differences and create a flow from alert to phone

Jill’s problem was that she didn’t enjoy the prospect of calculating the time difference between her various contacts. Additionally, she could easily acknowledge a calendar reminder yet lose her flow in getting to the calling stage.

No currently available apps could address this, therefore the path was clear to go ahead and design an app for a narrow segment of the market in a similar situation to Jill’s.

Participatory Design

This is how I involved the client and other users in the design stages…

User flows

To help convert the essence of the problem into a basic solution, it was useful to enquire with Jill the specific steps she would normally take to reach the problem state. From this, I was able to draw a user flow which allowed a break down of the problem into manageable chunks and to connect these chunks into a logical sequence:

Assessing this together, it was clear the pivot point from problem to solution lay in the first decision state, targeting Jill’s memory. From here, I was able to modify the user flow of the problem into a high level user flow of the solution, intercepting the first “No” decision path:

The “Yes” path for the first decision path would require an additional snooze function

Closed Card Sorting

This user flow provided valuable insight into what might be expected in terms of the app’s screens. I consulted Jill and drew title screens on note paper so we could easily re-arrange if needed. Once we settled on an order, I numbered the screens for reference:

Determining the two critical halves of functionality for the app

With the app represented by two clear halves, it was important to work on both. However, to fulfil the project within the time limit, I focused all my efforts on the second half of the app in order to tackle the problem-solution pivot point. As a result, assumptions were made based on Jill’s likely setup as to when the reminder alert would be triggered in her day-to-day function.

Screen Flow

To elaborate on the user flow solution, it was necessary to implement the details of each screen. This lead to the screen flow of the potential golden journey where Jill is successfully reminded and is able to speak to her mother on the phone.

An early screen flow. Note: the addition of a confirmation screen in a later prototype based on user feedback of the above

Delivery

This is how the prototype was developed for the client…

Rapid Paper Prototype

To get closer to the eventual design of the app, I used a paper prototype which was essentially a simulation of a design of the app on paper. This was a useful method of conveying and sharing the potential the app held in a quick and cost-effective way.

Paper prototypes are easily understood as prototypes and once I verbally set the scenario, testers gave feedback on its usage. I manipulated the changing screens as they were interested with whilst asking open ended questions such as “What would you expect to happen if this button is pressed?”

The extra screen at the end is an unfortunate addition based on an inability to determine if a call went to voicemail

As well as testing with Jill, I managed to gain response datasets from four additional users.

Testing the paper prototype with Jill and Vincent

What was interesting to note was that each candidate provided unique feedback of some sort; this really gave value to testing the prototype with a larger sample size, particularly beyond the original client. These are some highlights of the responses:

The requested features list grew rapidly so it was important to stay within the scope of solving the brief. I involved Jill once again to determine if the additions would benefit her particular way of doing things; these responses were brought together for the final iteration of the sprint:

The addition of the ‘confirmed success’ screen was vital in not abandoning the user

Digitised Paper Prototype

The prototype can be accessed online here.

To conclude this sprint, Jill told me that she would likely use this solution were it developed into a fully fledged app. Without ignoring that there is potential for future revisions and additional features, I can say I fulfilled the original brief and consider this first sprint to be a success.

Sprint 2 - Click here to see this design developed further

Find me on:
Twitter:
@nkgpt
GA UX Journal: li.nkg.pt/uxtopia