My Method

This page is about my method when doing a project. About what tools I use and how I implement them. And a bit about my story.

Why I want to be a UX Designer

First, I would like to tell more about my reasons for wanting to become a UX Designer. From as early as I can remember, when playing a game, watching a movie or reading a book, I’d always be editing it in my head to create an even better experience. Later on, especially with digital products, I’d constantly wonder why a certain product wasn’t designed in such a way to yield the best possible experience for someone using it. At the same time I was always enamoured with all things related to strategy or strategic thinking such as strategy games, books and documentaries. What I loved about strategy is that its basically finding out the best way to achieve your goal, whatever it is.

So when I discovered UX Design I saw that it was the meeting point of two of my main interests; user friendliness & strategy. The way I see it is that within the discipline of UX Design the best possible user experience is the goal and your method is the strategy to achieve it. Realising I have been alluding to that throughout my life, I thought it was time I finally became one now.

Double Diamond.png

Double Diamond

Most of my projects have been done following the Double Diamond method simply because I found it’s trajectory the most natural to follow. I altered the model a bit so it felt more intuitive to work with. The intermediary checkpoints of Learn, Insight, Ideas, Solutions and Product have been added by me to help define at what point you go from one stage to another - e.g. what you need to go from Research to Define.

The arrows for going uphill and downhill signify different brain states. Going ‘uphill’ means working in the open mode - operate broadly, keep an open mind and gather as much information as possible. Going ‘downhill’ means working in the closed mode - be focused, filter information and narrow things down to their essence.

Stakeholder Interview.png

Stakeholder Interview

The start of any UX design project involving an existing business should always involve a stakeholder interview. Not knowing your employers is like working in the dark. To this end I’ve looked at a lot of stakeholder questions, mixed them together and created my own canvas of questions.

Some questions (3, 4, 6 & 7) are quite similar on purpose - often asking the same question in different words yields different but valuable answers, I’ve found. The last two questions are not standard but have often yielded the best insights.

Business Model Canvas (EN).png

Business Model Canvas

The Business Model Canvas can provide a clear picture of how the business model you’re trying to improve is operating. Though it’s not something I use in every UX design project, it can be a great tool. The best time to use it is when the business model isn’t clear for the design team or if there are new business opportunities to be found.

Customer Profile & Value Proposition

The Customer Profile and Value Proposition usually come as a package with the Business Model Canvas, but I sometimes like to use them without the Canvas. Before discovering the Customer Profile I made Personas in various ways to give shape to the target audience. Since then the Customer Profile has become a standard tool in my method because it really narrows down the most important information into three categories: Tasks, Pains & Gains. It then connects seamlessly to the Value Proposition which very clearly defines the problems you ought to solve with your designs.

If there’s an existing audience I usually prefer to use this model.

Content Outline.png

Content Outline

This is a simple model which I came up with and is only used if the project involves a platform with a lot of content. The model helps structure all the content. You divide it into pieces, define its function and how important it is with regards to the rest of the content.

Technical Flow

The Technical Flow really forces you to think through every step of the product you’re designing. It fleshes out all the minor tasks that are usually overlooked. It can also show whether the idea or product is technically feasible.

The best (but not only) occasion to use this model is when you have to work with developers. This model will be a language both parties can understand.