Checking your GPS.

It’s easy to get lost when you’re building something.

I’ve worked at several start-ups, agencies and product companies over my career, and the design process was relatively similar across each of them.

1. Start with a solution to some problem that people have.
2. Design the shit out of it until its perfect.
3. Build and polish until it’s just like how you imagined it.
4. Launch!
5. Learn from users and fix problems based on feedback.
6. Repeat.

Often you spend most of your time and resources designing and building. Always assuming you’re building the perfect, or relatively close, solution to the problem. Shortly after launching you realise your solution didn’t fit the way you hoped. It isn’t “better”, from your anyalitcs and user feedback people aren’t loving it as much as you hoped. Often there’s too many problems that need fixing. Depending how much money you have left you either start again, leave it and hope for the best or you say fuck it and move on with your life.

This process routinely falls short for a few key reasons:

1. It assumes your solution is the best solution for the masses.
2. 80% of your resources are expended before you even launch.
3. It’s not a truly collaborative experience.
4. Learning from users is left until too late.
5. Great opportunities can be missed.

To fix this process we need to reboot and change the way we think.

We aren’t our users.
We need to realise as Designers and Developers, we don’t think like our users, we don’t act like our users and we don’t have the same daily experiences as our users. I believe that as soon as we set out to solve a problem, we set ourselves on a course which seperates us from the core user group.

In the process of designing a solution to a problem, we start to build a pattern of logic that seems to make sense at the time and drives us to the conclusions that we eventually build into our solution. We drown ourselves in the details of this problem as we become experts on the topic, as a result we often forget what its like to have to problem in the first place. We think we know the problem but often we have gone so far down the rabbit hole, our pattern of logic is based on so many assumptions and irrelevant details it becomes extremely abstract to the people we are suppose to be helping.

You must constantly validate your assumptions and check that your logic is relevant to the people you set out to help.

Learn as early as you can.
We need to involve users sooner in order to learn and validate our ideas and assumptions sooner. The further we push user feedback down the process pipeline, the more expensive it becomes to change the course of our thinking when we find flaws in our logic.

As creators it’s hard to show concepts that aren’t finished. I remember in the old days where I would quickly hide my work if I saw my Product Manager heading in my direction. A pattern I’m sure is common among budding Designers. It’s not that I didn’t enjoy feedback, it was because I knew what was in my head wasn’t on my screen yet, my vision hadn’t been fully realised yet. The problem here is that I was putting my own ego in front of the user. This mentality is not only a big blocker to the process, but oppose to our role as Designers — someone who is suppose to be helping the user.

As soon as you get over this hurdle, your users will thank you.

Discovery.

Let’s pretend we have a hunch we can design a fitness app that is more relevant to todays users wants and needs.

So to get started, we talk to a small group of people who fit our potential user base. Ask them about the problems they have in this area. How?, Who?, What?, When?, Where? and Why? are the kinds of questions would be asking. Context is a very important piece of information, understanding the events leading up the to the topic in question, and even the environment, can be very helpful. Lets call this the Discovery phase.

Heres a basic example of how it could go:

Designer: Tell me how you track your fitness?

Sophie: After a gym session I write down my sets, then record my weight and then take a photo in the mirror.

Designer: Why do you record those?

Sophie: Because if I’m trying to lose weight and I want to know what workouts have the best results on my body. Images and weight are great for that!

Designer: How do you record your notes?

Sophie: I use my notes app for my sets, calendar for weight and photos for my pictures.

Designer: Why do you use so many apps?

Sophie: Because I can’t record my sets, weight and photos in one place.

In the scenario above, we have learnt when our user records their notes, how they they record their notes and what metrics they are interested in and why they record these specific metrics. We even learn that images and weight are super important for this individual!

After talking to several people you will start to see trends and develop an understanding as to what experiences they have, why they do the things they do and what information is important to them.

This phase is about listening to people, understanding their metal models, their priorities and workflows. This info will help you shine light on the real reasons behind the problems they are having, and in turn also help you make better decisions later down the track, putting you in a better position to create a solution that fits.

Write stories.

At this stage you should have a good understanding of your potential users workflows, and a rough idea on where you can help improve it. I like to write a short narrative detailing the process, by doing this you have a good story to refer to and it also helps break down the workflows into steps.

Here’s an example:

“Sophie likes to track her weight after a gym session. She opens FitTrack and takes a picture in the mirror, adds her weight and includes a note with todays workout, then hits save.”

What did we do there? We just wrote a short little story using our new app idea, based on a real world workflow we have validated in out discovery phase. We also have a rough concept of the steps our user needs to do take to achieve their goal.

I do this for all the little goals that the user may want to achieve in the app: sharing, deleting, comparing, editing, etc. Be sure to have these goals tie back to the workflows you listed in your discovery phase, its ok if they don’t because we will soon test our new workflows and see how useable and useful they are.

Create wireframes.

At this stage we have a bunch of short stories that are ready to be sketched out in detail. To prep for this I like to break my short stories down into the steps required to hit the goal.

It looks something like this:

As you break it down you get a really good idea of what exactly is involved and you may even get a few ideas on how to simplify.

Once you’re done here, you’re ready to draw some wireframes. I typically sketch mine out pen and paper. I highly recommend this as it helps you quickly experiment with layout options quickly. As you progress make sure you’re following the steps in your workflows, and you may have a few different options for each flow.

As you work through it, no doubt you will have some questions about your users behaviour, some really abstract questions too. Like “Why are users recording their weight?”, “What would an ideal weight input experience be like?”, “What do they think they’re recording their weight in? A timeline or a journal?”. Shit can get weird real fast, but even though these questions may mean everything to you, they may mean nothing to the user. Take note of them, try to not to get caught up on them, we will get back to them later.

Once you have worked through all of your workflows you should have a bunch of wireframes that can guide a user from A to their goal at B, maybe even a few different paths for the same goal, and a few more questions to ask. Soon we will be putting them to the test.

User interviews and design testing.

I know what you’re thinking. You’re thinking hold on “Chris, you’ve skipped a step, we haven’t fleshed out our wireframes yet.”, and thats when I say “Bro, we are totes ready for testing. Yolo!”. The idea here is that once we have a flow down on paper, we should test it so we can learn what our users think. The sooner we can learn the better.

If we draw out the details of the interface in pixel perfect goodness, two things will happen. Firstly the people we are interviewing will get caught up on how it looks, it may look great but the fundamentals may be flawed, and this may not me as obvious if they are raving about how pretty it is. Secondly if there are flaws in the fundamentals of our thinking, we have wasted a lot of time and effort to find out our we need to start again.

I like to break my design tests and interviews into two parts. The first being an additional Discovery Phase, but this time we will have a few specific topics we are interested in.

Discovery (again).
Remember those abstract questions we had earlier about our users intentions. Instead of racking our brain about it, we can let them to tell us!

We need to prep these questions so that they don’t lead the respondent to answer in a particular way. In other words we want our respondents to use their words, and gain better insight into their mental modals and patterns.

Here’s an example:

“Do you prefer to use a keypad to quickly enter your weight or a scroll wheel?”

This implies that the keypad is quicker than a scroll wheel, and may in a subtle way may lead the respondent to answer with keypad.

“Tell me about the last time you recorded your weight”

This question allows the respondent to answer based on their own experiences. And if they don’t like the experience, they will tell you.

Usability.
So, with our discovery questions prepped and our wireframes at the ready, we need need to write a script that helps guide us through the second part of our user interviewer. You’ve actually done 80% of this work already, those short stories we wrote earlier will become the foundations of our script.

Heres an example:

“You like to keep track of your fitness. With the interface in front of you, how would you take a photo, and record your weight.”

Your script may have a series of these small workflows strung together. Prep a couple of questions you can ask your test user after they have taken a shot at your tasks, open ended questions like “How did that feel?”, “Did that work as expected?”, “Tell me how that worked for you?”.

Technique.
Interviews can be awkward, and it’s a unnatural situation to be putting someone into. Be sure to do your best to comfort the test user, assure them that they aren’t the ones being tested, the design is.

Give them a quick run down of what to expect during the interview, and when it does get to the usability testing phase be sure to remind the user to think out aloud. If there is a pause, fight the urge to fill it with conversation, wait for the user to tell you whats going on in their head.

Design testing and user interviewing is skill that takes some time to master, theres a lot to remember and a lot to be aware of when you’re interviewing you’re user. The important thing is that you are doing this, because no matter how you do it, you will learn a lot.

While conducting your interviews, you’re not looking for peoples opinions or suggestions. You’re looking for reactions, expressions and emotional states.

Learnings.

After interviewing several people, you will have a much better idea of how well your designs align with your real world user’s experiences and expectations. You will also have a clear idea of where your workflows could be improved, and what assumptions you have made about your users understanding of the process.

Now we can go back to our wireframes, update them with our new found learning and maybe move to a higher fidelity form of artwork. Once completed we move to another another round of testing, maybe with a clickable prototype to simulate a more realistic environment.

This whole process can be done within a few days, giving you a much better understanding of your user and the opportunities available to you at a very low cost.

This is a quick look at user research and design testing. Basically, this how you check your GPS on the way to creating an effective product.