My process.

We all have our ways to go about things, and sometimes I get asked what my design process looks like.


For me, it completely depends on the project; what I am designing, and who I’m designing it with. Of course, there are a few steps or “ingredients” I use when I design something, but I don’t always need the same amount of ingredients in order for something to work. For example, sometimes I might need to do a lot of research to figure out what the users actually want and need, and sometimes research is barely needed.

With that said, here are some of the “ingredients” I use more or less of when I design stuff:

  • Find the REAL problem.

    I often get problems “served” to me by clients or by my employer. Sometimes the problem and the wanted solution can be very clear, and sometimes more work is needed to figure out what REALLY needs to be done.

    I’ve often found that in order to do that, I need to learn more about the business and its users/customers and ask the right questions. The more you know, the easier it is to figure out a solution.

  • Do some qualitative research.

    Data doesn’t always have to be numbers and statistics. While it is easy to get swooped into the analytical side of behavioral research, listening to what people have to say in order to figure out why they behave in certain ways is equally as important.

    Qualitative research can be done in a lot of ways: interviews, observations, focus groups, surveys with open-ended questions… take your pick!

  • Come up with ideas.

    Brainstorming, crazy eights, brainwriting, rapid ideation, mind mapping… there are so many methods one can try in order to come up with ideas. I prefer to come up with ideas together with other people, but when I have to do it myself I usually make a mind map or scour the internet for some inspiration. You don’t always have to reinvent the wheel.

  • Sketching.

    I think in images, so I tend to sketch a lot during meetings or as soon as I get an idea for something. It’s almost a way of writing for me. This means that I usually have a bullet journal or easy access to Figma (which is my preferred tool for sketching and prototyping at the moment) with me at work. In my notes, you’ll likely find storyboards, wireframes, mobile navigation sketches, weird or not yet fully thought-through concepts, project plans, logo designs, and much, much more.

  • Planning.

    I love planning. Almost a bit too much. As clearly as I can see user flows and wireframes in my head, I can also see the process for getting a project done. It’s almost like having a huge Gantt scheme in my head. I find comfort in planning and making lists, so that is a big part of my process.

  • From low to high.

    When I feel like I have a clear view of the problem and the final solution, I make a high-fidelity mockup or prototype of it. Sometimes, while making something high-fi, I realize new problems that might take me back to the sketchy parts of my process - or sometimes even further back.

  • Design review / Test.

    I often ask other people to review or test my designs. It’s always good to know you’re on the right track and you might get new ideas and feedback from others that could become essential to the project. I’ve found though, that depending on who I ask to review or test my design, it might need to be more high-fidelity than low. However, I try to make it a habit of asking for design reviews in the early stages - and not just from the client but preferably from developers too.

  • Pass it on to Development.

    Before passing a design over to developers, I usually give a final design presentation for the stakeholders and dev team. Hopefully, developers have been somewhat included in the design process so they kind of know what to expect. But still, there might be elements to the design that needs more explaining.

    I then always make sure to clean up my design files (usually Figma) and that everyone who needs access to those files have access.

I feel it worth mentioning that these are just some of the steps I use when I design. I’ve also been known to measure and analyze quantitative data, as well as work with budgeting and recruiting team members. But like I said in the beginning - it all depends on the project.

Furthermore, just because something is pushed on to development doesn’t mean that my job is done. Things can just as well need adjusting in the developing stage. Also, post-release tasks, such as analyzing user feedback, assessing UI usability, A/B testing, and tracking user behavior are of course also part of what I do.