Disclaimer: This is a long post, partly because the basics have already been covered on countless of blogs, books and Youtube tutorials, and mostly because I love writing. You can skip to the section headers and bits in bold, and that should give you a rough idea of what my process is like. Or you can read the whole thing, if you’ve got the time. Your choice.

You know how there are several schools of psychotherapy, like CBT, talk therapy, psychoanalysis, behavioural therapy, cognitive therapy, Gestalt therapy, and then there’s something called integrative therapy, which basically combines different forms of therapy in order to offer the client the best solution for their particular problem?

Well, that’s what my process is like. It’s a combination of tools, concepts and systems that I’ve been collecting for the past year from books, conferences, blogs, youtuber-designers, colleagues and – well – just plain old work experience. And I don’t necessarily use them all every time I approach a new design problem.

Sometimes a problem is so small it doesn’t need further user testing – sometimes repeated complaints from current users are enough to go on (speak to the Customer Support team, they really know what’s out there). Sometimes you finding out that something in the flow doesn’t even – uh – make sense to yourself (the original designer!) might be enough to just go fix that before users figure out who you are and start making voodo dolls with your face on them.

Sometimes, however, a problem is so big that it requires a lot of thinking and discussing before you even go into it. A rule of thumb is that if it’s going to take a long time to design and build, you might as well take just as much time getting the problem, specs, research and potential solutions right first. In that case, I’m fully on board with getting the post-its, the white walls, the markers and the people into one room and going through a full-on Design Sprint.

Here are some of the things I like to do as part of my UX Process.

Understanding the problem

Talking. Asking questions. Listening. Talking some more. Speaking to Sally, the Product Manager. Speaking to Matt, the Account Manager, and Lisa, the Customer Support Manager. Speaking to Kai and Rami, the developers. You get the idea.

Why are we even building this? Why is this our next project? What problem are we trying to solve?


The research phase already started with the “Understanding the problem phase”, but now we already kind of know what the problem is, so we can start to look at what the competition is doing to solve that same problem.

We can also start to investigate the market, see who would ever use that product. If the product already exists and we already have users (hooray us!), then this is a good moment to get in touch with them and go through the current flow and test the live product to see what’s working for them – and what isn’t.

If the product doesn’t exist but there are similar products in the market, you can still test your competitor’s product with some people to see what – again – works for them or doesn’t work for them.

And if the product is a brand new concept no one’s ever heard of, congrats on your bravery; your concept needs some guerrilla testing and user research before we dig in any deeper.

User personas and flows

This stage of the UX process really pleases the fiction writer in me because I can start to make up stories for user personas. For instance, this is me working on a user persona for a young-ish NHS patient who is very overweight and needs to bring their weight down:

Suzanne is particularly motivated to change, as she’s struggling to keep up with her fiance’s fitness levels, and last time they went trekking she had to quit the trip mid-way and get a bus. She also loves dancing, and would like to dance at her wedding without getting tired – she’s getting married in six months! The plan is to get her down to 65-70 kg by the end of the year.

From the user research and conversations I’ve had, I start creating a user persona that represents most of our users, or at least the users we’re targeting with the new design/feature/functionality. This helps me and other team members empathise with our user persona and think of the designs in terms of, “What would Suzanne do?”, “Would Suzanne be frustrated by this?” or “How is this helping Suzanne?”.

After having a user persona in place, it’s time to work out the current flow – how Suzanne is going to get from A to B and solve her problem.

User flows

User flows don’t necessarily represent everything that happens online. In fact, user flows are meant to represent everything that happens from the moment Suzanne realises she’s too overweight to the moment she feels super happy she’s lost those 15kg. Is all of that going to happen within the realm of the product? Heck no! But Suzanne going to spinning classes and cooking yummy broccoli recipes will also be part of the user flow.

My user flows also involve storyboarding, because I enjoy drawing cute comic strips with characters (I mean, users).

Wireflows or screen flows

Now, this is when I start doing diagrams. I know, they are not as exciting as sketches or wireframes, but this is just what I do.

So I’ll write down a list of steps or draw a flowchart with all of the steps, depending on how inspired I am on that day. An example of one of my diagrams for Instagram would be as follows:

Context: Macy (user) sees a beautiful flower and decides to take a picture and post it on Instagram

  1. Macy opens Instagram app
  2. Macy taps on “add photo/take photo” button
  3. Macy chooses to take photo
  4. Macy takes photo and it’s too blurry
  5. Macy goes back to “take photo” mode and re-takes the photo
  6. Photo looks good the second time. Macy decides to post it
  7. Macy applies filters and retouches photo
  8. Macy taps on “Next”
  9. Macy writes a caption
  10. Macy adds location
  11. Macy tags her friend Johnny who is with her
  12. Macy taps on “Share” button
  13. Macy reviews photo on her profile and waits for the likes to bombard her Notifications hub

Now that I have a step-by-step flow in place, I can start to think of how Macy is going to move from one step to the next. Is there going to be a “re-take photo” button? Are we going to have Location, Tagging and Caption capabilities on the same screen?

And I can begin to quickly sketch a very, very rough version of the screens that are to follow.

Design and prototype

And that’s it, that’s the end. Only it’s not. It’s just the beginning!

When I say prototype, I don’t necessarily mean an Invision mockup full of colour and micro-interactions. A prototype can be anything that represents the product you are desiging in some shape or form. A prototype can be made of paper, low-fidelity wireframes, mid-fidelity wireframes or – yes, of course – high-fidelity wireframes.

A prototype can be made on Invision, Sketch, Figma, Framer, Marvel, Whimsical, Keynote, Power Point and even that good old notebook with My Little Pony on the cover your mother got you back in 2005 – it was heavily discounted!

So here’s the drill: you prototype and you test it. You show it to the rest of your team, you show it to your partner, your mother and your best friend, and you show it to your users. You write down all the comments they make. The content that doesn’t make sense, the screen that’s missing, the icon they don’t understand. All of it.

And then you design and prototype again. It’s called constant iteration. And I’m a big fan.