What does a UX Designer really do?
(Clue: they don’t do much designing)
Many people think UX designers spend all their time building prototypes. But the reality is very different. I think part of the misconception lies with our job title – we are not really designers – we are problem solvers.
With this in mind, I thought I’d write a blog as a bit of a myth buster, to invite questions about the discipline of UX, and to show how our UX team can help more broadly across a business.
What people think we do:
What we actually do:
A UX designer is a user-focussed problem solver with solid business understanding. We work closely with product owners / managers to help shape the product vision and ensure it is focussed on the needs of those who use it. We are part of Digital Development, but can be of service to the wider organisation.
The purpose of UX is to ensure that the products and services we build are useful and valuable to users. Peter Morville represents this through his User Experience Honeycomb, which perfectly illustrates what is needed to design a meaningful and valuable user experience:
He notes that in order for there to be a meaningful and valuable user experience, information must be:
Useful: Your content should be original and fulfill a need
Usable: Site must be easy to use
Desirable: Image, identity, brand, and other design elements are used to evoke emotion and appreciation
Findable: Content needs to be navigable and locatable onsite and offsite
Accessible: Content needs to be accessible to people with disabilities
Credible: Users must trust and believe what you tell them
Below, I’ll talk you through my ‘design’ process (I’ve found this a handy process for all types of work).
When I take on a new piece of work I ask myself four questions:
What problem am I trying to solve?
Who is the user?
Why is it important?
What do I know & what don’t I know?
What problem am I trying to solve?
Einstein said: “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.” He believed that the quality of the solution we generate is in direct proportion to our ability to identify the problem.
And I’m absolutely with him on this!
This stage of the process is often referred to as ‘problem definition’. I dedicate a considerable amount of time to it. If I received a brief to “Improve the checkout process” my first question would be: What problem are we trying to solve? And improve what, exactly? Understanding the problem is vitally important if we hope to design the right solution. Approaching the problem of trolley abandonment would likely be different to approaching the problem of low engagement with “forgotten favourites”.
I use the 5 Whys interrogative technique as part of my problem definition process. It helps me get directly to the core of the problem.
Just like a small child, a UX Designer must keep asking “why”. Often, you’ll find your “why” gets harder to answer. You might even stumble on an insightful answer that you never could have expected. This technique aims to differentiate the symptoms of a problem from the cause of a problem. If we are always fixing symptoms, we’ll continue to see the same problems arise again and again. And we’ll invest more time and resources into fixing the same problems. You’ve likely heard people say “All I do is firefighting”, but, if we fix the cause, both the user and the business are happy: it’s a valuable use of time and resource, and the problem is solved.
Who is the user?
We can’t design a good solution if we don’t know who it’s for. We need to spend time learning about our audience: what is important to them? What do they struggle with? What are their likes and dislikes? At Waitrose we lean on our incredible Insight Team, who have produced personas customer segmentation, and share of wallet information, which are all fantastic tools to get a better understanding of our users and their behaviours. We lean on the Data & Analytics Team to understand what devices are being used and how this might impact their experience. For example, we may be testing on new fast devices, but our customers may be using old devices with slow connectivity. Everything needs to be aligned to the user.
Every Monday I pencil out half an hour to digest the most recent customer verbatim – this is what our customers have fed back to us in the last week. This helps me empathise with our users and understand their core pain points. After this, I spend time in Google Analytics familiarising myself with behavioural patterns and site usage. The more familiar I am with this, the quicker I’ll be able to spot any anomalies.
Why is it important?
It doesn’t matter how great the solution is if we solve the wrong problem. I always ask why solving a particular problem is important. Are a lot of people complaining about it? Does it fail accessibility standards? Is it a business priority? We need to ensure our efforts are used strategically to deliver the biggest gains to the customer and the business.
I will go on to ask the business stakeholder what success looks like to them, and how we should measure it. For example, if someone from the Trading team wants to improve the checkout process, what exactly do they mean? Increased trolley value? Improved availability to promise? But if a stakeholder from Brand gives me the very same brief, they may simply wish to achieve a more consistent experience. We will then work together on balancing business requirements with user needs.
Until key performance indicators have been established, I will not pick up a piece of work. The measure of success will drive my design.
What do I know and what don't I know?
This is the point at which I reach out to all areas of the business to understand what work has already been done, what has already been tested, and what we have already learned. Duplication of effort is one of the biggest causes of inefficiency in large companies. This is why UX designers need to be first rate communicators.
Once I’ve figured out what we know it’s time to think about what we don’t know. For example, whether something is technically feasible, whether it aligns with our future strategy, whether there are dependencies with other teams, whether there would be an operational impact. Design cannot happen in a silo.
When I have gathered the answers to these four key questions, I then start to plan my approach. It might be that more research is needed. It might be that a competitor review is called for. It might be that we can just push something straight to live.
I often refer to a helpful checklist to guide my approach (see image below). It’s easy to get formulaic in our approach to problem solving, which can result in our solutions becoming too similar. By using a checklist, I can prompt myself to approach a problem differently, and come up with a better or unique solution. It’s a handy way of challenging our ways of working, getting us to think differently and to lead the market rather than to simply follow.
