UX/UI-designer eller udvikler: hvem skal du starte med?

Om du skal starte med en UX-designer eller en udvikler, afhænger af hvor den største usikkerhed i dit projekt ligger. Er du i tvivl om hvad brugerne har brug for, eller er designet selve salgsargumentet, så start med en designer. Ligger det svære i data, integrationer og forretningsregler, så start med en udvikler, og i mange MVP'er kan en udvikler med designsans klare begge dele ud fra et færdigt designsystem.

Jeg er selv udvikler og ikke designer, så læs med det forbehold. Jeg har forsøgt at være lige så tydelig om hvornår du skal starte med en designer som om hvornår du kan undvære en.

Den korte version

Min tommelfingerregel er enkel. Kan du ikke beskrive de tre vigtigste skærmbilleder og hvem der bruger dem, så start med en designer. Kan du beskrive dem, men ikke hvordan data kommer ind og ud af systemet, så start med en udvikler. Kan du begge dele, er en udvikler med designsans ofte nok til første version.

Forskellen på UX, UI og udvikling

Titlerne bliver ofte blandet sammen, også i jobopslag. Her er den korte forklaring:

• UX-design (user experience, brugeroplevelse) handler om hvordan produktet fungerer for brugeren: hvem er de, hvad prøver de at opnå, og hvilke trin skal de igennem. Resultatet er typisk brugerinterviews, brugerforløb, wireframes (skitser af skærmbilleder uden farver og grafik) og test af prototyper.
• UI-design (user interface, brugerflade) handler om hvordan det ser ud: layout, typografi, farver, ikoner og de komponenter som knapper og formularer er bygget af. Resultatet er færdige skærmbilleder og ofte et designsystem.
• Udvikling er at bygge det, så det virker: databasen, logikken, brugere og rettigheder, integrationer til andre systemer og selve brugerfladen i kode.

Rådgivningsfirmaet Nielsen Norman Group, der arbejder med brugervenlighed, skelner skarpt mellem de to første. I deres definition af brugeroplevelse er pointen at et produkt kan have en flot og logisk brugerflade og stadig give en dårlig oplevelse, hvis det ikke løser det problem brugeren kom med.

Grænserne er flydende i praksis. Mange designere arbejder med både UX og UI, og frontend-udviklere har ofte en god fornemmelse for layout. Vil du have overblik over udviklerrollerne, har jeg samlet dem i en guide til 12 typer udviklere, og hvem der gør hvad.

Det vigtigste for dig som køber er arbejdsdelingen. En designer afklarer hvad brugeren skal opleve. En udvikler afklarer hvordan det bygges, så det virker.

Hvornår designeren skal med først, og hvornår udvikleren skal

Tegn på at du skal starte med en designer

• Du er ikke sikker på hvem brugerne er, eller hvad de vil betale for.
• Produktet sælges til forbrugere eller mange forskellige brugere, og oplevelsen er det der adskiller dig fra konkurrenterne.
• Der er komplekse forløb, fx en booking, en købsproces med mange valg eller den første tid som ny bruger.
• Du skal vise produktet til investorer, kunder eller ledelsen, før der bruges penge på udvikling.
• Brandet er afgørende, og den visuelle identitet findes ikke endnu.

I de tilfælde er en klikbar prototype i Figma det billigste sted at tage fejl. Du kan flytte en knap eller slette et helt skærmbillede på få minutter. Når det er bygget i kode med en database bag, kan selv små ændringer tage timer. Nielsen Norman Group anbefaler at teste med omkring fem brugere ad gangen og hellere lave flere små runder end én stor. Det kan en designer gøre på en prototype, før udvikleren går i gang.

Du kan også bygge en simpel prototype selv i et no-code-værktøj. Det fungerer til at afprøve en idé, men det erstatter ikke samtaler med brugerne. Jeg har skrevet mere om hvad no-code og low-code kan, og hvor det stopper.

Tegn på at du skal starte med en udvikler

• Løsningen bruges af dine egne medarbejdere eller af et kendt antal faste kunder.
• Det svære er integrationer, fx til et økonomisystem, et lagersystem eller et API du ikke kender.
• Brugerfladen består mest af lister, formularer, filtre og et overblik, altså mønstre som brugerne kender fra andre systemer.
• Du har allerede et designsystem eller en designmanual fra din hjemmeside, som løsningen kan følge.
• Du er usikker på om noget overhovedet kan lade sig gøre teknisk, fx om du kan hente de data du har brug for.

Her er den største risiko ikke at brugerne misforstår skærmbillederne. Det er at systemet ikke kan det du har lovet. Så er det bedre at bruge de første penge på en teknisk afklaring end på flotte skærmbilleder af noget der måske ikke kan bygges.

Hvornår én udvikler med designsans kan klare en MVP

En MVP (minimum viable product, den mindste version af produktet der kan afprøves på rigtige brugere) har ét formål: at finde ud af om nogen vil bruge og betale for den. Her er det ofte fornuftigt at springe den separate designfase over og lade en udvikler med designsans stå for brugerfladen.

Det fungerer når tre ting er på plads:

1. Brugerfladen bygger på kendte mønstre: login, lister, formularer, et overblik og indstillinger.
2. Der findes et færdigt komponentbibliotek eller designsystem at bygge på. Til Tailwind CSS, som jeg selv bruger, findes der både gratis og betalte biblioteker med komponenter til de fleste almindelige skærmbilleder.
3. Du accepterer at første version ser ordentlig og pæn ud, men ikke unik.

Med designsans mener jeg ikke at udvikleren kan skabe en visuel identitet. Jeg mener at vedkommende holder afstande, typografi og farver konsekvente, tænker på mobilen, tomme lister, fejlbeskeder og ventetid, og siger fra når et skærmbillede bliver uoverskueligt.

Det du giver afkald på, er brugerresearch før koden skrives og et udseende der skiller sig ud. Det er ofte en god handel i en første version, så længe du planlægger at hente en designer ind, når du ved mere om brugerne.

En god mellemvej er at hyre en designer i få dage til de vigtigste skærmbilleder, fx forsiden efter login og det centrale forløb, og lade udvikleren bygge resten i samme stil. Om én udvikler i det hele taget kan bære hele projektet, har jeg skrevet om i indlægget om hvornår én fullstack-udvikler er nok.

Hvad rækkefølgen betyder for prisen

Rækkefølgen afgør hvor pengene bliver brugt, og hvornår du opdager fejlene:

• Designer først betyder en udgift før udviklingen starter. Til gengæld bliver udviklingen mere forudsigelig, fordi færre spørgsmål står åbne, og det gør det lettere at få en fast pris.
• Udvikler først flytter designarbejdet til senere. Det er billigere i starten, men hver ændring i et forløb bliver lavet i kode, og det tager længere tid end i en skitse.
• Én udvikler med designsans er typisk den billigste vej til en første version, fordi der ikke skal koordineres mellem to personer. Bagsiden er at brugerfladen ikke er testet med brugere før lancering.

Hvad designdelen koster, afhænger især af antallet af skærmbilleder og forløb, om der skal laves brugerresearch, om der findes en visuel identitet i forvejen, og hvor mange testrunder du vil have. En afgrænset designrunde til en MVP kan groft regnet tage fra et par dage til nogle uger.

Design kan også gøre udviklingen dyrere. Specialtegnede komponenter, animationer og layouts der afviger fra standard tager længere tid at bygge end komponenter fra et bibliotek, så lad en udvikler se designet igennem, før det er færdigt. Vil du se hvordan design indgår i den samlede pris på en første version, har jeg gennemgået hvad en MVP koster, og hvad der driver prisen.

Hvornår hver løsning ikke passer

Designer først

Designer først passer dårligt, når opgaven mest er teknisk, og brugerne er få og kendte. Et internt værktøj til ti medarbejdere har sjældent brug for en lang researchfase. Der får du mere ud af at sætte dig ved siden af medarbejderne en eftermiddag og se hvordan de arbejder i dag.

Det passer heller ikke, hvis designet laves uden at nogen har tjekket at det kan bygges inden for budgettet. Så risikerer du at betale for skærmbilleder du ikke har råd til at få udviklet.

Udvikler først

Udvikler først passer dårligt, når produktet skal vinde på oplevelsen. Sælger du til forbrugere eller konkurrerer mod veldesignede produkter, kan en udvikler bygge noget der virker fejlfrit og stadig ikke bliver brugt. Det passer heller ikke, hvis ingen har talt med brugerne. Så er det udvikleren der gætter på forløbene, og det er en dyr måde at gætte på.

Én udvikler alene

Én udvikler uden designer passer dårligt, når brandet er en del af produktet, forløbene er komplekse, eller der er mange brugertyper med forskellige behov. Det passer heller ikke, hvis du forventer at udvikleren også laver logo, illustrationer og visuel identitet. Det er en anden faglighed.

Har du brug for design, tekster og udvikling fra ét sted på samme tid, kan et bureau være det rigtige valg. Min sammenligning af freelancer og bureau gennemgår hvornår det betaler sig.

Sådan arbejder jeg sammen med en designer

Når der er en designer med, er min foretrukne arbejdsgang at designer og udvikler arbejder overlappende i stedet for i to adskilte faser:

1. Udvikleren er med fra de første wireframes. Det tager et minut at sige "den her del er dyr at bygge" eller "her findes en standardløsning", og det kan spare uger.
2. Designet laves i Figma, som jeg også selv arbejder i, med de samme komponenter som koden bruger. Så er en knap i designet også en knap i koden.
3. Designeren er et skridt foran. Mens det første forløb bliver bygget, designes det næste.
4. Designet dækker også de kedelige tilstande: tomme lister, fejlbeskeder, ventetid, mobil og tilgængelighed som kontrast og tastaturbetjening. Det er dem der oftest mangler, og så er det udvikleren der gætter.
5. Designfilerne ligger i din virksomheds Figma-konto, af samme grund som koden er din fra første dag.

Ved større projekter starter jeg med et betalt forprojekt til fast pris, hvor jeg sammen med dig afklarer om der er brug for en designer, hvor meget, og i hvilken rækkefølge. Det er bedre at vide før udviklingen går i gang end midt i den.

Næste skridt

Brug fire spørgsmål til at finde ud af hvem du skal starte med:

1. Hvem er brugerne, og hvad er de tre vigtigste ting de skal kunne?
2. Hvad er du mest usikker på: brugerne eller teknikken?
3. Er udseendet med til at sælge produktet?
4. Har du et designsystem eller en designmanual i forvejen?

Peger svarene på brugerne og oplevelsen, så start med en designer. Peger de på data og integrationer, så start med en udvikler. Er begge dele forholdsvis enkle, kan én udvikler med designsans bygge første version, og en designer kan komme på senere. På siden om hvordan jeg prissætter projekter kan du se hvordan forprojekt og fast pris hænger sammen.

Ofte stillede spørgsmål

Kan en UX-designer også kode?+

Nogle kan, men sjældent på det niveau et produkt i drift kræver. Mange designere kan lave HTML og CSS eller avancerede prototyper, og det hjælper samarbejdet med udvikleren. Database, brugere, rettigheder, integrationer og sikkerhed er derimod udviklerarbejde. Forvent ikke at en designer bygger din backend, og forvent heller ikke at en udvikler laver brugerresearch.

Hvad skal en udvikler have fra designeren, før arbejdet går i gang?+

En Figma-fil med komponenter, alle skærmbilleder i både desktop og mobil og de tilstande der let bliver glemt: tom, fejl og indlæsning. Dertil kommer farver, typografi og afstande samlet ét sted, licenser til skrifttyper og ikoner og en klikbar version af de vigtigste forløb. Mangler noget, ender udvikleren med at gætte.

Kan jeg bruge en færdig skabelon i stedet for en designer?+

Ja, til en første version er det ofte et fornuftigt valg. Vælg en skabelon eller et komponentbibliotek der passer til det framework udvikleren bruger, og tjek licensen før du køber. Undgå at tilpasse skabelonen så meget at den ikke længere ligner sig selv. Så betaler du for designarbejde alligevel, bare uden en designer.

Hvad er forskellen på en UX-designer og en produktdesigner?+

En produktdesigner dækker typisk både UX og UI og er ofte også med til at prioritere hvad produktet skal kunne. I mindre virksomheder overlapper titlerne så meget at de er svære at skelne. Bed derfor om at se en portefølje der viser processen, ikke kun de færdige skærmbilleder. Så kan du se om personen har talt med brugere og testet sine idéer.