Published on | Prototyping: From UX to Front End — Medium Dan Andrews

It’s not easy being User Experience in 2017.

You can notice me across a wide range of digital products in many industries, but I’m not very well understood.

It’s frustrating because all I want to do is help.

Sometimes, people mistake me for Visual Design, which I’m really not.

Don’t get me wrong, I love Visual Design. We work together.

Beautiful aesthetic design bring products to life, adds personality and helps re-enforce the brand. But ultimately, how useful is a car with the body of an Aston Martin and an engine of a 1980’s lawnmower?

Sure, it will look amazing, and impress people when it’s parked on the street, but you can’t use it to travel from one location to another with any degree of efficiency.

It also makes me sad when people downgrade me to just ‘thinking about design’ or think that I’m something which is just ‘done’.

I’m so much more than that.

I’m a talker.

I’m a listener.

I’m a process.

I’m a set of tools.

I help you understand your users better.

I operate at the intersection between Business Goals, User Needs and Technical Feasibility.

I improve usability, accessibility and joy experienced by users of your product or service.

For the record, I’m not new. I’m not just a buzz-word. People have been using the same techniques I use to make informed design decisions for decades, long before the digital age.

My reason for existence is simple: I want to make you and your product better.

I’ll tell you how I do this…

Step 1: Gathering information

Design doesn’t occur in a vacuum. You need to talk to people.

By conducting research I gain information from all relevant parties to remove assumptions from the process and learn as much as possible.

I often start this process with a workshop with all team members, to make sure I have as much context as possible to begin the project.

I then have conversations with people who would be using the product, in things I call interviews, but sometimes I watch people carry out tasks. I call this an ethnographic study. I do this because sometimes, what people say, and what they do are completely different things. Something else I do is, asking people to document themselves doing something and record their thoughts and feelings. This is called a diary study.

There are many techniques which can be used here depending on the project, such as card sorting, surveys, tree tests, usability testings, A-B testing and many, many more. The deliverables themselves aren’t that important, but the process and the conversations with people help me gain insight into the problem and users needs.

Step 2: Synthesising information

Once I have collected all of this information, I process it. Sometimes this may happen organically during the workshops or exercises, but sometimes they are created retrospectively.

The documents I create depend on the project and problems uncovered by research, but I will almost always create personas. Personas help me, and the rest of the team understand the people who we are designing for. They must be created entirely from real information as with all documentation. They act as a reference piece to use as we move through the design process and ensure the focus remains on user needs. Personas are often made up of more than one person, and you may need more than one if you have very different users.

We give these personas a name, like Sarah. I don’t like the word ‘user’. We are designing for people. People who have names, families, dreams and problems. Let’s help these people. Let’s help Sarah.

I also like creating empathy maps. Building on the persona, it helps me build a greater profile of the user, considering their wants and needs, and what they do every day. All of this helps me build… you guessed it, empathy. By building empathy and an understanding of the user we are more invested in, and in a better position to solve their problems.

Customer journey maps are also really great, and storyboards work in a similar way. They bring the story to life. By considering the daily life of the user and the journey they take we can highlight problems they face at particular times, which I call pain points. Good products solve pain points with design solutions.

There are many other things I might create during this phase, such as Task Analysis’, Affinity Maps, Feature Matrixes, Site Maps, Application Maps and User Flow Diagrams. My goal however remains the same; to understand the user needs and start to think about how they can be solved in the product by laying a solid foundation of information. I understand that people like to see pieces of paper and to understand where their money is being spent, but I don’t create these documents to sit in a drawer or to look pretty. They are used as part of the process and not as fixed deliverables to tick boxes. Be flexible people.

Step 3: Design, Test, Improve…and repeat

When I start designing, I always start on paper. It’s quicker, cheaper and enables me to consider all ways to solve the problems I discovered in research. I continue to sketch ideas until I have something more concrete. Innovation requires time.

I then create very simple digital wireframes, without any colour.

Why? I have found that people focus too much on colour and how things look, when I really only want to test how my idea works at this stage. Its important to build a solid foundation to the house before we argue about the hue of blue we will paint the left wall of the bathroom. Its also easier and quicker to make changes to simple digital designs. I want to use your money and time wisely.

With my early stage designs, I conduct usability testing, either face-to-to face or remotely. Here, I ask people to carry out simple tasks and monitor their behaviour.

Based on the feedback I gain from showing people the design, I improve the product. This may happen many times. The more it happens the better the product will be. Design is a process of iteration and is never really finished. The more money and time you have the better your product will solve the problem. It’s that simple.

Why should you care?

If you aren’t motivated by creating great products and helping people like me, that’s okay. Here are some other reasons why you should be my friend.

I base my deicisons on information
Data doesn’t lie. There really is no subjective ‘right answer’ to many things in life. By asking people, and gathering data, we remove subjectivity from the process. Many times, people involved from in the project, whether owners, business analysts, marketing managers, or even designers are far too close. We can settle disputes and remove ambiguity and do what the data suggests we should to help people.

I increase customer retention
Because I involve the users at all stages of the design process, I build solutions which they like and will want to come back to. User needs change and sometimes we don’t know people as well as we thought we did.

I save you money
Building bad products is expensive for everyone. Not only is it substantially cheaper to make changes to designs on paper than after they have been developed, you have to repair the damage to your brand and customer relations by shipping poor products. A brand is hard to build but easy to destroy.

In closing

Should I disappear from your project any time soon, or the next time you consider using me, I want to leave you with a statement highlighting my belief in my power to help people.

It’s very simple; by thinking about people and involving them in our design process, we can improve products, businesses and potentially solve some of societies largest problems.

Note: Originally published at Red C. Dan works there 🙂

Hello, I’m User Experience. Let’s be friends. was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello, I’m User Experience. Let’s be friends.

Cool stuff, every week

More Articles