# Nestlé Hydration Calculator 02: Wireframe & Early User Test

A brief introduction: During my graduation internship at Poke I was asked to work on the Nestlé Pure Life website, specifically the hydration calculator and infographics. In this series of post, I’m writing about my design process and what I’ve been learning along the way.

### Wireframe

#### Starting point

After having done my research, I moved forward and started working on the wireframes.

The following wireframe of the hydration calculator was given to me as part of the brief, although it hadn’t been fully thought through. It had been produced to communicate several points:

• That the calculator might combine 3 existing calculators: For families, individuals and businesses
• The idea that we might be able to use the calculator for more than simply hydration information. The team wanted to leverage it for lead generation and data capture.

#### Quick and dirty. Sketch, sketch, sketch!

Following Sam’s advice, I started sketching the flow on paper, getting the basic concept right. The medium forces me to think more thoroughly about the elements that go into each step so that I won’t be spending hours pushing pixels.

I started off with the calculator for one person first since it’s a the most complicated one.

As I started sketching, I quickly realised how fast you can iterate the design. We had one feedback session a day. I sat down with Sam, as we reviewed the sequence, rearranged the steps, reformulated the questions, etc.

#### Single-step, two-step or multi-step calculator?

Structure first! Which layout works best to help the user get to their result in an easy and helpful way?

In the initial wireframe, the questions were split into two groups. I called this the two-step layout. Here is the logic behind it:

• Physiological factors: Age, gender, weight, and height.
• Environmental factors: Activity level and zip code (to measure temperature and humidity level).
All we need is basic information, so I guess the 2-step layout could work. Simple and sufficient. But is it the best choice?

I explored the option of putting everything in one step, then I quickly realised that it didn’t work. It’s difficult to add more to the experience when you gather all the information in one place.

How about a multi-step layout? Having researched different form structures including this article about online webforms, the team and I decided to adopt a multi-step, single field approach so that we could explain why we were asking sensitive information at each stage. It also allowed us to use a more engaging UI — in line with our evolving experience principles. Additionally, the facts will help improve organic search rankings.

By asking one question at a time, we now have space to give users useful tips and facts along the way, as suggested in my competitive review outcome.

#### Limit typing: Does it always work?

As I wanted users to have an effortless experience using the calculator, I explored ways to improve usability.

When asking for data such as age, height, and weight, I used text fields in the existing prototype. This required users to type in the information, but was this the best choice?

At that point, I didn’t have a clear idea of how precise the data needed to be. However one of my colleagues suggested that I could try dividing the data into different groups. This would allow users to pick the group they belong, which helps limit typing.

I took some time to explore this option, then ended up going back to using a text field as grouping seemed to make users think too hard about which group they belonged to.

#### Wireframes

With the information in place, I put together a wireframe that allowed users to step through the hydration calculator for one person.

Sam and I had a discussion regarding the placement of the Did-you-know section. I initially placed it in the bottom left corner, not following the F-shaped reading pattern. This allowed users to go through the form quickly without being forced to read the facts.

On the other hand, Sam argued that it should be placed in the top right corner because they explain why we need the information from users.

It was undecided which solution works best, I took the mobile first approach and tried out Sam’s solution on the mobile version.

Once I have the calculator for one person wireframe, I moved onto the other two calculators (one for family and one business). Compared to the personal one, these two are a lot simpler and require less data from users.

### Test Early, Refine Later

Now that I have the wireframe of the mobile version, I’m better off testing it with quick experiments. Early experiments enabled me to quickly gather insights, learn and adapt to users need.

#### Target audience demographics

To find out whom I should approach for user testing, I asked Andrea and Sam as they both have been working at Poke for quite a long time. They advised me to choose my test subjects based on the personas, talk to non-tech savvy people and people that don’t know about the project.

Among the 8 people I talked to, there were:

• Gender: 3 males and 5 females.
• Nationality: 5 British, 1 Italian, 1 American and 1 South African.
• Job: 2 designers, 2 producers, 1 receptionist, 1 office manager, 1 developer, and 1 copywriter.
• Age range: 23 to 42 years old.
• 1 has family with young children.
• 25% are non-tech savvy

I understood that this was an acceptable but not perfect representation of the Nestlé Pure Life target audience. These interviews were quick experiments to help me improve the usability of the calculator.

#### Creating an interview guide

Once I have established whom to talk to, Sam and I created an interview guide. This guide was to help me to stay on topic and get the information I needed.

#### And finally, conducting the tests!

Over 2 days, I conducted the tests with 8 users. Each session lasted about 15 minutes.

In the first 3 tests, I attempted to both observe users and take notes at the same time. It didn’t work! It was simply impossible to build up good conversational rapport while also taking notes.

Learning from my mistake, I set up audio recording for the rest of the user testing sessions. After the tests, I listened to the audio file and summarised the main takeaways. Here is my documentation:

Note: Notice how the note for my interview with Rachel is extra long? She’s the only American among 8 people I talked to, pretty much the closest to our target group.

These 15-minutes interview session turned out to be a lot more useful than I expected. For example, it was a surprise for me when Monique said she would lie about her age.

“I’d lie about my true age. I was gonna put 25 but I’m actually in my 30s. I just feel like I don’t want to admit it. I can’t be truthful about that. I might lie about my weight too.” — Monique Brown

And let’s not forget how upset Giulia was when she read the first fun fact “As you get older, your sensation of thirst is reduced so you might not drink as much fluid as you need”.

When I read the first fun fact “As you get older”. Yes, I know. For fuck’s sake. Thank you.—Giulia Grimaldi

However, Sam advised me not to take these points too seriously as they could be interpreted as jokey conversation rather than serious comments.

#### From Raw Data to Usable Data

Now that I got all the notes from each interview session, let’s compile and turn them into a usable format. I started with highlighting important observations, comments, and thoughts.

Afterward, using an affinity diagram, I grouped them into the following respective themes: Results, Did-you-know, Sensitive Information and Information Accuracy.

Based on the affinity diagram, I generated conclusions for each theme.

• Result: 5 out of 8 found the result of the family and business calculators vague. They’d like to see how the result is broken down and what the calculations are based on.
• Facts in Did-you-know section: Facts need to feel positive as well as helpful. Not too hard to digest. Most users read the first fact as they were positioned above the question, then skipped the rest. Some got happy when they found something that they already knew.
• Sensitive information: 1 out of 8 had problems being truthful about her weight and age. 1 had problems filling in her zip-code (she worked in one and live in another).
• Information accuracy: All users know their height. 25% roughly know their weight and most know their exact weight.
• Other observations: The ‘next’ button is a bit too low as users have to scroll down to find it. For the activity level question, most users choose their answers without reading the description.

#### Actions to take

• Add a result breakdown for each calculator. For the family and business calculator, give the estimation in day, week and month.
• Review all the facts from the Did-you-know section. Make sure they’re simple, short and positive. Get a copywriter involved if possible.
• Take out the answer description in the activity level step.
• Make ‘lbs’ the default unit in ‘Weight’ step.
• Move the ‘Next’ button up

About the Zip code question, we had one user that struggled to fill it out — they questioned whether it was the area they worked or lived in. However, I decided to keep it for the time being as most people were not confused by the question.

Also, before conducting this test, my concern was that people might be skeptical giving away their zip code. Rachel, our American tester, confirmed that it would be okay as long as we didn’t ask for their names.

“I would feel okay giving it if somebody hadn’t asked for my name. I think asking for zip code is pretty common in the US since it does cover a wide-enough area. You go to shops and sometimes they ask for zip code for marketing purpose. People mostly give it.”— Rachel

#### Takeaways

Even though the people I talked to were not a perfect representation of our target audience, the information I discovered during user testing was invaluable. I realised that having stared at the wireframe for so long, even the most obvious flaws didn’t really stand out. The test helped identify those issues.

#### Next step

Having identified the issues, I updated the wireframe and presented it back to the team. I was then advised to progress to the visual design.