HOW I

WORK

1. Build a shared understanding

2. Learn from users and evidence

3. Explore quickly and make trade-offs visible

4. Design the whole experience

5. Build together

6. Release, learn and improve

I start by understanding the problem around the screen.

Good product design rarely begins with drawing the interface. I first try to understand what is happening around it: who the user is, what they are trying to do, what they already know, where they came from and what the business and technical constraints look like.

The exact process changes with the problem. Some projects allow time for deeper research and exploration; others need a fast improvement because a deadline is close or something is already causing friction. I prefer a flexible, iterative process over applying the same set of methods to every project.

I gather what the team already knows through existing research, support conversations, analytics, technical knowledge and conversations with stakeholders. I map the journey, states and open questions so that assumptions become visible.

This is especially important in complex products. A payment screen may look like one small touchpoint, but the experience can begin in an email or printed invoice and continue through a bank, BankID, a processing period and later reminders. Understanding that wider journey helps the team solve the actual problem instead of polishing one isolated screen.

I use the research methods that are realistic and useful for the decision at hand: interviews, usability tests, prototype testing, analytics, session observations, support feedback and experiments.

At Billogram, direct access to end users was sometimes limited because they were our customers’ customers and privacy requirements affected how we could contact or track them. We had to be creative—combining available behavioural data with support insights, customer feedback, internal subject-matter expertise and targeted external research. As the data function grew, closer collaboration with analysts made it easier to connect qualitative observations with product behaviour.

I do not see data and qualitative research as competing approaches. Analytics can show where something happens; conversations and observation help explain why.

I move between rough flows, sketches and prototypes before spending time on visual refinement. Sharing early makes it easier for engineers, product managers and other specialists to challenge the idea while it is still inexpensive to change.

Not every constraint can be removed. Regulations, legacy technology, deadlines, customer requirements and cost can all shape the final solution. My role is to make the consequences of those trade-offs visible and protect the most important parts of the user experience.

I think beyond the ideal path. What happens if the payment fails? If it is delayed? If the user leaves and returns? If the text becomes twice as long in another language? If someone uses a keyboard, zooms the page or cannot distinguish low-contrast colours?

Clear states, error handling, content, accessibility and responsive behaviour are part of the design, not finishing touches added after the main flow is complete.

I work closely with engineers throughout implementation. They bring a perspective on technical possibilities, constraints and edge cases that can materially improve the design. I stay involved during development, review the experience in context and adjust details when the real implementation teaches us something new.

I prefer releasing a focused improvement and learning from it over trying to perfect a large solution in isolation. After release, I look at behaviour, feedback and new questions with the team. The result often becomes the starting point for the next iteration.

The principles behind my process

  • Understand the wider journey, not only the interface.

  • Involve different disciplines early.

  • Design for edge cases and accessibility from the start.

  • Use both qualitative insights and behavioural data.

  • Explain the reasoning behind decisions, including assumptions, constraints and trade-offs.

  • Release, learn and improve rather than waiting for perfection.

HOW I HELP TEAMS GROW

I believe strong design work comes from the way a team learns together.

I contribute through the work itself, but also by helping create the conditions around it: shared understanding, open communication and practical ways of reusing what we learn.

Bringing people around the same problem

Complex projects become easier when design, engineering, product, support and business stakeholders can see the same journey and discuss the same questions. I use flows, prototypes and workshops to make abstract problems concrete and give everyone something to respond to.

Connecting design and development

Working closely with engineers has been one of the most valuable parts of my development as a designer. I bring the user and experience perspective; they help reveal system behaviour, technical constraints and opportunities I might otherwise miss. I try to create a working relationship where questions can be raised early and ownership is shared.

Making accessibility a team responsibility

I have consistently advocated for accessible contrast, clear hierarchy, understandable content, keyboard behaviour and reusable patterns. Accessibility becomes more sustainable when it is built into components, documentation and everyday decisions instead of depending on one person checking at the end.

Creating reusable foundations

Whether it is a design-system component, a documented decision or a clearer workflow, I look for ways a project can make the next project easier. The goal is not process for its own sake. It is to reduce repeated discussions and let the team spend more energy on genuinely new problems.

Sharing context, not just files

A finished design rarely explains why it exists. I document important decisions, constraints, states and unresolved questions so that people can understand the reasoning and make better decisions later—even when the original team is no longer in the room.

Staying open and constructive

I value teams where people can disagree without becoming defensive, share unfinished thinking and learn from one another. I try to contribute with curiosity, kindness and honesty. Good collaboration does not mean agreeing with everything; it means creating enough trust to challenge ideas productively.