Så här jobbar jag

Webbutveckling

Helheten är jobbet

En webblösning ska fungera för dem som besöker den, för redaktörerna som håller den aktuell och för verksamheten som äger den. Min styrka är att se hur kommunikation, design, frontend och backend hänger ihop. Utifrån det bedömer jag vad som kommer att fungera och hur det bör byggas.

Jag förstår varje del av kedjan och kan förklara den för alla som arbetar i den.

Bedöma tidigt vad som går att bygga

Redan på wireframenivå tittar jag på vad en lösning kräver i frontend och backend. Kan ett beteende styras av ett fält? Vad behöver en modul bakom kulisserna? Vad bör ändras innan något byggs? Ju tidigare frågorna ställs, desto billigare blir svaren.

Modern utveckling

I egna projekt fördjupar jag mig i den moderna webbstacken: React, Next.js och TypeScript i frontend, Tailwind för stilar och Node.js på serversidan. Den här portfolion är byggd så. Sedan hösten 2026 arbetar jag också med Umbraco och .NET, med inriktning på headless. I en pilot hämtar en frontend i Next.js innehållet via Umbracos API och bygger på mitt designsystem. Det är samma principer som jag har byggt efter i många år: komponenter som återanvänds och en tydlig gräns mellan innehåll och presentation.

Processer, inte bara sidor

Ibland är det bästa arbetet att ersätta en process. När samma innehåll tas fram på flera ställen, i flera format eller för hand, finns det ofta en enklare väg med en källa som allt annat utgår från. Det ger färre korrekturrundor och mindre som kan bli fel. Exempel är DUX digitala prislistor och InPublix.

Byggt för att förvaltas

En lansering är början. En lösning ska gå att uppdatera, säkra och vidareutveckla i många år. Därför bygger jag med förvaltningen i åtanke: tydlig struktur, återanvändbara moduler och redaktörsgränssnitt utan onödiga val. Många av mina kundrelationer har varat i mer än tio år. Det har lärt mig vad som håller.

Struktur och förankring

Rätt frågor tidigt

Vad ska lösningen åstadkomma, och varför? Vem är målgruppen? Vilka förutsättningar finns, tekniskt och för varumärke och kommunikation? Frågorna behöver besvaras så tidigt som möjligt, eftersom svaren styr allt som kommer efter: struktur, design och vad som ska byggas. Ett exempel är Stockholmspriset i kriminologi, där jag var med från offert till leverans.

Förankring och beslut

Processen ser olika ut beroende på projektet och hur väl man känner kunden. Ofta handlar det tidiga arbetet lika mycket om förankring som om lösningar. Beslut behöver tas hos kunden och internt innan design och kod tar fart. I workshops tar jag ofta hand om UX, design och teknik. Resultatet gör jag om till underlag som teamet kan arbeta vidare med. Ett exempel är LKF, där projektgruppen tillsammans fick igenom en digital områdesguide. Min del var att förklara för LKF och deras uthyrare hur lösningen skulle fungera.

Wireframes och prototyper när de behövs

Prototyper är inget självändamål. Ibland går projektet direkt på design. I andra fall behövs ett djupare arbete med innehåll och struktur först, med informationsarkitektur, navigation och de moduler innehållet behöver. Då räcker det ibland med enkla wireframes i PowerPoint, medan andra projekt kräver mer avancerade wireframes i Figma, klickbara prototyper eller en prototyp i kod. Vilken nivå som behövs bedömer jag från projekt till projekt.

Kommunikation, design och teknik

Målet är alltid en treenighet mellan kommunikation, design och teknik. När den saknas märks det sent i projektet, när nya moduler eller ny kod måste tas fram i sista stund. Det händer oftast när grundarbetet inte har gjorts fullt ut. Förutsättningar kan också ändras under ett projekt. Därför håller jag helheten levande hela vägen, inte bara i starten.

Gränssnitt för dem som använder dem

Två grupper lever med en lösning: besökarna och redaktörerna som håller den aktuell. Jag tar hänsyn till båda i struktur och flöden. Redaktörerna ska få det de behöver utan onödiga val. De bästa förbättringarna kommer ofta av att se var användarna fastnar. Ett exempel är navigeringen i InPublix, för två olika sätt att läsa.

Design och kod

Designsystem som gemensam grund

Ett designsystem är där design och kod möts. Färger, typografi, rubriknivåer och komponenter definieras en gång och används av båda. Då slår en ändring igenom överallt, och nya sidor blir konsekventa från början. Jag har länge byggt moduler som återanvänds i stället för att kodas om, och gjort Figma-skisser till fungerande komponenter. I dag arbetar jag med ett eget designsystem som både design och kod utgår från. Den här portfolion är byggd på det.

Tillgänglighet från början

Tillgänglighet avgörs till stor del i koden: hur fokus flyttas, om menyer fungerar med tangentbordet och om rubrikerna är rätt. Jag bygger in det från början i stället för att rätta i efterhand. I designsystemet följer dialoger och menyer fasta regler för fokus och tangentbord. Då blir även prototyperna tillgängliga. Jag utgår från WCAG 2.2. När kraven gäller allt fler verksamheter är det enklast att möta dem om tillgängligheten finns i grunden.

AI och framåt

Vad AI förändrar

Det blir allt billigare att ta fram design och kod, och prototyper som tog dagar tar nu timmar. Det gör inte erfarenheten mindre viktig. När det går snabbt att producera blir det viktigare att veta vad som ska byggas, att se vad som håller och att granska det verktygen tar fram. Där ligger mitt bidrag.

Nedskrivet först

I mina egna projekt arbetar jag med AI-assisterad utveckling i Claude Code. Vid större arbeten skrivs kraven ner först: vad lösningen ska uppnå och vilka förenklingar som är medvetna. Arbetet bryts ner i små steg som testas och granskas innan nästa. Allt som ska förvaltas får ett skriftligt spår. Flera projektsidor visar besluten öppet under fliken Teknik.

Design Bridge

Design Bridge är nästa steg i samma riktning. Design och kod utgår från ett gemensamt designsystem. En brief kan då snabbt bli en fungerande prototyp, och en ändring går från idé till kod utan att tappas bort.