Explanations of UX often come wrapped in lofty and nebulous concepts: it’s about uncovering needs, challenging assumptions and designing solutions. We use lots of metaphors and conceptual frameworks to try and explain the discipline. This sort of explanation is all well and good to understand why UX is important, but it leaves out half of the story. What does UX design look like in a real project? What’s the nitty-gritty of the work?

To start with, the reason it’s so hard to talk concretely about UX is that it isn’t really one specific thing. The role of a UI (User Interface) Designer is to create final screen designs. The role of a Developer is to write the code to build a website (forgive me, I’m simplifying). But UX Designers have a toolbox of activities that can be used at any stage of a project. The role of a UX designer is to choose the right methodologies for a project’s needs and limitations. And now we’re back into lofty and nebulous territory…

In this post, I’m going to share the most helpful way I’ve found to understand what UX actually looks like in a project. It’s generally broken into four stages, with some clear activities associated with each stage.

1. Discover

The only goal of this phase is to learn. Learn what business goals the website or project is going to help achieve (for larger companies, this can often be surprisingly inconsistent). Discover what competitors are doing. Learn about who users are, how they behave and – crucially – what their problems are. The point of this stage is to truly understand before jumping into solutions.

For a startup that wants to create an MVP product quickly, we might do these activities:

• Requirements gathering workshop
• User interviews
• User surveys
• Competitor review

Conversely, for an established company that wants to design a new multi-market product, we might do some additional activities:

• Stakeholder workshops
• Audit of existing website/product
• Experience maps
• Cognitive walkthroughs
  

2. Define

Here is where we start to think about solutions. Given everything we know, how should this website or product work? What will be truly valuable to users while meeting business goals?

In this stage, we think creatively to produce lots of quick, rough ideas and put them in front of real users to get feedback. Then, we start to develop the most promising idea.

This stage usually ends with a solid concept, backed up with user insights, to which we can assign a budget and timeline.

For our startup on a shoestring budget, this might look like:

• Proto-personas
• Concept testing
• User flows
• Feature prioritisation
• Sitemaps
• Low-fidelity wireframes
• Sprint planning
  

For our more established client launching a new multi-market product, we might do all of the above, plus:

• Prototyping
• Personas
• Information architecture
• Experience principles
• Product roadmap
• Backlog generation

3. Design

Now we’re ready to bring the digital solution to life through sketches and screen designs. A UX designer starts with wireframes – a basic (admittedly ugly) grey version of screens – to agree on the underlying structure and content of every screen. Wireframes are crucial to lock down first – we risk wasting time on beautiful visual details that might be thrown away if the basic structure of the page needs to change.

Then UI (User Interface) designers will often take the wireframes, and bring them to life through colour, typography, graphics and animation. This is where designs start to look like a real website.

For our startup, this stage might include:

• UX and UI design sprints
• Specifications
• Developer handover

For our mature enterprise client, it might need some additional activities:

• Medium-to-high fidelity wireframes
• UX and UI design sprints
• Usability testing
• Design system creation
• Specifications
• Developer handover

4. Iterate

The often neglected final stage. This happens after the product has been built and launched, and there’s been enough time for people to use it. It can be easy to forget this stage – the product is live, the box has been checked. But it’s a great time to gather real world use data, and speak to early adopters to uncover any problems. The goal of this stage is to learn what’s working well and improve what isn’t.

For our startup, this could include:

• Analytics review
• Usability testing
• New feature definition

For our mature enterprise client, we might have more sources of data to consider, and a backlog of features to execute. We might add the following activities:

• In-product surveys
• Backlog execution
• New feature definition

Final thoughts

It can be tempting to ignore the early UX process and jump right into Design. It might feel like the best use of money because you get tangible, beautiful outputs quickly. But this comes with the real risk that you’re building something no one will use. UX might be hard to understand, but it’s crucial to a product’s success.