How I work

Web development

The whole is the job

A web solution has to work for the people who visit it, for the editors who keep it current and for the organisation that owns it. My strength is seeing how communication, design, frontend and backend fit together. From that I judge what will work and how it should be built.

I understand every part of the chain and can explain it to everyone who works in it.

Judging early what can be built

Already at wireframe level I look at what a solution requires in frontend and backend. Can a behaviour be controlled by a field? What does a module need behind the scenes? What should change before anything is built? The earlier the questions are asked, the cheaper the answers.

Modern development

In my own projects I am going deep into the modern web stack: React, Next.js and TypeScript in the frontend, Tailwind for styling and Node.js on the server side. This portfolio is built that way. Since autumn 2026 I also work with Umbraco and .NET, focused on headless. In a pilot, a Next.js frontend fetches content through Umbraco's API and builds on my design system. These are the same principles I have built by for many years: components that are reused and a clear line between content and presentation.

Processes, not just pages

Sometimes the best work is replacing a process. When the same content is produced in several places, in several formats or by hand, there is often a simpler way with one source that everything else starts from. That means fewer proofing rounds and less that can go wrong. Examples are DUX Digital Price Lists and InPublix.

Built to be maintained

A launch is the beginning. A solution should be possible to update, secure and develop further for many years. That is why I build with maintenance in mind: clear structure, reusable modules and editor interfaces without unnecessary choices. Many of my client relationships have lasted more than ten years. That has taught me what lasts.

Structure and alignment

The right questions early

What should the solution achieve, and why? Who is the audience? What are the conditions, technically and for brand and communication? These questions need answers as early as possible, because the answers steer everything that follows: structure, design and what gets built. One example is the Stockholm Prize in Criminology, where I was involved from quote to delivery.

Alignment and decisions

The process differs depending on the project and how well you know the client. Early work is often as much about alignment as about solutions. Decisions need to be made by the client and internally before design and code pick up speed. In workshops I often take care of UX, design and technology. I turn the outcome into material the team can carry forward. One example is LKF, where the project team together got a digital area guide accepted. My part was explaining to LKF and their leasing agents how the solution would work.

Wireframes and prototypes when they are needed

Prototypes are not an end in themselves. Sometimes a project goes straight to design. In other cases deeper work on content and structure comes first, with information architecture, navigation and the modules the content needs. Then simple wireframes in PowerPoint are sometimes enough, while other projects call for more advanced wireframes in Figma, clickable prototypes or a prototype in code. I judge the level needed from project to project.

Communication, design and technology

The goal is always a unity of communication, design and technology. When it is missing, it shows late in the project, when new modules or new code have to be made at the last minute. That usually happens when the groundwork has not been done fully. Conditions can also change during a project. That is why I keep the whole in view all the way, not just at the start.

Interfaces for the people who use them

Two groups live with a solution: the visitors and the editors who keep it current. I take both into account in structure and flows. Editors should get what they need without unnecessary choices. The best improvements often come from seeing where users get stuck. One example is the navigation in InPublix, for two different ways of reading.

Design and code

A design system as shared ground

A design system is where design and code meet. Colours, typography, heading levels and components are defined once and used by both. A change then takes effect everywhere, and new pages are consistent from the start. I have long built modules that are reused instead of recoded, and turned Figma sketches into working components. Today I work with my own design system that both design and code start from. This portfolio is built on it.

Accessibility from the start

Accessibility is largely decided in the code: how focus moves, whether menus work with the keyboard and whether the headings are right. I build it in from the start instead of fixing it afterwards. In the design system, dialogs and menus follow fixed rules for focus and keyboard. That makes the prototypes accessible too. I work from WCAG 2.2. As the requirements apply to more and more organisations, they are easiest to meet when accessibility is in the foundation.

AI and what's next

What AI changes

Producing design and code keeps getting cheaper, and prototypes that took days now take hours. That does not make experience less important. When production is fast, it matters more to know what should be built, to see what will hold up and to review what the tools produce. That is where my contribution lies.

Written down first

In my own projects I work with AI-assisted development in Claude Code. For larger pieces of work the requirements are written down first: what the solution should achieve and which simplifications are deliberate. The work is broken into small steps that are tested and reviewed before the next. Everything that will be maintained gets a written trail. Several project pages show the decisions openly under the Technical tab.

Design Bridge

Design Bridge is the next step in the same direction. Design and code start from a shared design system. A brief can then quickly become a working prototype, and a change goes from idea to code without getting lost.