Hvor starter et godt projekt egentlig?
I de foregående dele nåede vi frem til en vigtig konklusion - vi designer ikke et site bare fordi virksomheden "trænger til en ny hjemmeside".
Vi designer et værktøj, der skal løse et konkret problem.
Nogle gange er problemet svag salg. Nogle gange for få forespørgsler. Nogle gange kan kunderne ikke finde oplysninger. Andre gange svarer sælgerne hver dag på de samme spørgsmål, fordi sitet ikke formidler basale informationer. Det kan også være, at virksomheden er vokset, og det eksisterende site ikke længere svarer til dens reelle omfang.
Derfor bør det første trin ikke være Photoshop, Figma eller valg af framework.
Det første trin bør være en samtale.
Først lærer vi forretningen at kende
En god UX-designer behøver ikke være ekspert i hver branche, men må forstå klientens forretning godt nok til at vide, hvilke problemer der skal løses.
Derfor spørger vi om ting, som i starten kan virke ikke relateret til design;
- Hvor kommer kunderne fra?
- Hvorfor vælger de netop denne virksomhed?
- Hvorfor forlader de os?
- Hvad spørger de oftest om før køb?
- Hvordan ser salgsprocessen ud?
- Hvem håndterer forespørgslerne?
- Hvad sker der med leadet efter formularafsendelse?
- Hvilke produkter er vigtigst?
- Hvilke services har størst potentiale?
- Vil virksomheden øge antal forespørgsler, ordreværdi, kundemængde eller primært forbedre sit image?
Først svarene på sådanne spørgsmål gør det muligt at fastlægge, hvad vi egentlig bør designe.
Discovery - før den første mockup
I digitale projekter bruger man ofte betegnelsen Discovery.
Det er et trin til at lære problemet, brugerne, forretningsmålene, begrænsningerne og teknologiske muligheder at kende, før det egentlige design og udvikling går i gang.
Det er ikke et "spild af tid før arbejdet starter". I et velført projekt skal Discovery reducere risikoen for at bygge noget, der ser flot ud, men som ikke løser det reelle problem.
Vi kan for eksempel opdage, at klienten slet ikke har brug for et nyt site.
Måske har de brug for bedre informationsarkitektur.
Eller en forenkling af købsprocessen.
Eller integration af sitet med CRM.
Eller automatisering af forespørgselshåndtering.
Eller en helt anden måde at præsentere tilbuddet på.
Derfor kan det betale sig at stoppe op, inden produktionen går i gang.
UX starter ikke med udseendet
UX, altså User Experience, er brugerens oplevelse, når de bruger et produkt eller en service.
For et website indeholder det langt mere end blot interfacets udseende.
Det er også:
- måden man bevæger sig rundt på sitet,
- letheden ved at finde information,
- forståeligheden af budskaber,
- købsprocessen,
- formularer,
- indholdsstruktur,
- hvor hurtigt opgaver udføres,
- systemets reaktion på brugerhandlinger,
- tilgængelighed,
- følelse af sikkerhed og tillid.
Derfor starter UX før nogen tegner den første skærm.
Først skal vi forstå, hvad brugeren forsøger at opnå.
User Flow - hvilken vej skal brugeren nå målet?
Et af de grundlæggende UX-værktøjer er User Flow. Det beskriver stien brugeren følger for at udføre en opgave.
For eksempel i en shop kan det se sådan ud: annonce → produktside → valg af variant → kurv → levering → betaling → ordrebekræftelse.
I en servicevirksomhed: Google → serviceside → referencer → cases → formular → kontakt til sælger.
For en producent: søgning → produkt → tekniske specifikationer → dokumentation → forespørgsel.
Hver af disse stier kræver forskellige designvalg.
Hvis brugerens vigtigste mål er køb, kan vi ikke tvinge dem til at læse mange skærme tekst. Hvis produktet derimod er dyrt, komplekst og kræver konsultation, kan et for hurtigt pres mod en formular være lige så forkert.
UX handler blandt andet om at finde det rette niveau af føring for brugeren.
Wireframe - før vi begynder at "pynte"
Næste trin kan være et wireframe, en forenklet skitse af skærmen der viser layout af indhold og funktioner.
Wireframe behøver ikke være smukt. Og det er helt i orden. På dette trin handler det ikke om, hvilken farve knappen får.
Det handler om at besvare spørgsmål som:
- Hvad ser brugeren først?
- Hvad er vigtigst?
- Hvad bør stå højere oppe?
- Hvor placerer vi supplerende information?
- Hvordan kommer brugeren videre til næste trin?
- Hvad sker der ved klik?
Det er lidt som at designe en lejlighed.
Først beslutter vi, hvor vægge, døre og rum skal være. Først senere vælger vi vægfargen.
Design system - så projektet ikke bliver en samling tilfældige elementer
I større projekter dukker et andet vigtigt element op - Design System.
Det er et organiseret sæt regler, komponenter og mønstre, der definerer, hvordan interfacet bygges.
Det kan omfatte blandt andet:
- farver,
- typografi,
- knapper,
- formularer,
- kort,
- tabeller,
- beskeder,
- ikoner,
- mellemrum,
- responsivitetsregler,
- komponenternes opførsel.
Hvorfor? - for at interfacet er konsistent.
Hvis en knap opfører sig på én måde på én underside og helt anderledes på en anden, må brugeren hver gang lære interfacet forfra.
Design System hjælper også udviklingsteamet. I stedet for hvert gang at bygge en komponent fra bunden, kan man bruge tidligere definerede elementer.
Det fører til større sammenhæng, lettere udvikling og ofte lavere vedligeholdelsesomkostninger.
Hvor kommer teknologien ind i billedet?
Teknologi bør inddrages i rette tid, men må ikke diktere hele projektet. Det er en vigtig sondring.
Designeren kan finde på en god funktion, der giver mening for forretningen. Udvikleren kan dog påpege, at implementeringen bliver meget dyr eller skaber performanceproblemer.
Omvendt kan udvikleren foreslå en teknologisk løsning, der er nem at implementere, men som fra brugerens synspunkt ikke løser problemet godt nok.
Derfor opstår de bedste projekter, når UX, design, udvikling og forretning taler sammen fra starten.
Ikke efter princippet: "Først designere, så udviklere".
Men: "Vi overvejer sammen, hvordan vi bedst løser problemet".
Teknologi bør ikke vælges fordi den er trendy
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, native app, PWA... man kan nævne mange teknologier.
Men klienten køber ikke teknologi. De køber en løsning.
Derfor er spørgsmålet: "Hvilket framework skal vi bruge?"
ofte mindre vigtigt end: "Hvilke problemer skal systemet løse?" Først senere vælger man passende arkitektur.
En simpel firmaside kræver en anden teknologi end en webshop med tusindvis af ordrer, og igen en anden end en B2B-platform med avancerede integrationer og brugerrettigheder.
Teknologien bør følge kravene, ikke omvendt.
Backend, frontend og det, brugeren ikke ser
Det er også værd at huske, at et website ikke kun er det, vi ser i browseren.
Frontend står for den del af applikationen, brugeren direkte interagerer med.
Backend står for logikken på serversiden - behandling af data, kommunikation med databasen, processer og integrationer.
Og imellem dem findes ofte en række ekstra elementer;
- CRM.
- ERP.
- Betalingssystem.
- Mailplatform.
- Lagerstyring.
- API.
- Analytics.
- Automatiseringer.
- Kundeservicesystem.
Hvis vi designer et nyt site uden at tage dette økosystem i betragtning, kan vi lave en smuk frontend, som fungerer som en isoleret ø.
Men målet bør være noget helt andet.
Et godt site kan gøre meget mere end bare "indsamle formularer"
Et moderne website kan være en del af en større forretningsproces;
- Brugeren sender en forespørgsel.
- Systemet genkender emnet.
- Lead går til CRM.
- Sælger får en notifikation.
- Kunden får en automatisk bekræftelse.
- Data tilknyttes en kategori.
- Systemet kan tjekke produktets tilgængelighed.
- Det kan forberede information til sælgeren.
- Det kan starte en bestemt workflow.
I en webshop kan en ordre automatisk gå gennem opfyldelsesstadier. I B2B kan kunden få adgang til individuelle priser, dokumenter og ordrehistorik.
Så stopper sitet med blot at være et "visitkort". Det bliver en del af forretningsinfrastrukturen.
Hvad med AI?
AI kan også være en del af et sådant system. Men igen - det bør ikke tilføjes bare fordi "alle nu har AI".
Hvis en chatbot ikke løser noget reelt problem, bliver den bare endnu et vindue på sitet.
Hvis brugeren derimod ved hjælp af AI hurtigere kan finde det rigtige produkt, konfigurere en service, få svar på et spørgsmål eller komme igennem valgprocessen, så giver teknologien mening.
Det samme gælder personalisering.
Vi kan vise brugeren forskellige indhold afhængigt af adfærd, kilde eller købsfase. Vi kan analysere data og bedre forudsige kundebehov.
Men vi bør altid starte med spørgsmålet: "Hvilket problem løser vi?"
Og først derefter: "Er AI den bedste måde at løse det på?"
Vi tester ikke kun om det virker
En af de mest almindelige fejl er at teste sitet først til slut. Så opdager vi, at formularen er for lang, købsprocessen er ulogisk, eller brugeren ikke finder den vigtigste information.
Jo senere vi opdager et sådant problem, desto dyrere er det at rette.
Derfor er det værd at teste projektet i faser. Vi kan teste en prototype. Vi kan observere brugernes adfærd. Vi kan lave brugbarhedstest. Vi kan analysere data fra Google Analytics eller andre analysetools. Vi kan bruge sessionoptagelser eller varmekort, hvis det er implementeret i overensstemmelse med privatlivskrav. Vi kan også bare tale med sælgerne.
Sidstnævnte undervurderes ofte.
Sælgeren hører dagligt kunders spørgsmål; ved, hvad de ikke forstår. Ved, hvad de er bekymrede for. Ved, hvilke informationer der skal gives før køb.
Det er en enorm designviden.
MVP er ikke ligegyldigt
I digitale projekter taler man ofte om MVP - Minimum Viable Product.
Det er den første version af produktet med det minimale sæt funktioner, der er nødvendigt for at verificere antagelser og levere værdi til brugerne.
MVP bør ikke betyde: "Lad os lave noget hurtigt og så ser vi".
Et godt MVP bør svare på spørgsmålet: "Hvad er den mindste version af løsningen, der tillader os at teste, om vi er på rette spor?"
Det er også vigtigt for websites og apps.
I stedet for at bygge tredive funktioner fra start, kan det nogle gange være bedre at udgive de fem vigtigste og se, hvordan brugerne anvender dem. Derefter udvikler vi systemet baseret på reelle data, ikke kun antagelser fra det første møde.
Sitet slutter ikke på lanceringsdagen
Det er endnu en ting, vi ofte glemmer.
Lanceringsøjeblikket er egentlig begyndelsen på dets rigtige liv. Først da dukker de reelle brugere op. Først da ser vi, hvilket indhold virker. Først da ved vi, hvilke elementer der ignoreres. Først da kan vi tjekke, om antal forespørgsler, salg, tid på siden eller andre tidligere aftalte KPI'er er forbedret.
Derfor bør projektet videreudvikles;
- Analyse.
- Konklusioner.
- Ændring.
- Test.
- Ny analyse.
Det ligner mere en cyklus end en engangsforestilling.
Hvad bør måles?
Det afhænger af projektets mål.
For en webshop kan det være:
- konverteringsrate,
- gennemsnitlig ordreværdi,
- kurvafgang,
- omsætning,
- kundeværdi over tid.
For en servicevirksomhed:
- antal værdifulde leads,
- formularens konverteringsrate,
- antal bookede konsultationer,
- omkostning per lead,
- kvalitet af forespørgsler.
For et informationssite:
- at finde specifik information,
- brugernes engagement,
- antal tilbagevendende brugere,
- download af materialer.
Man behøver ikke måle alt. Men man skal vide, hvad der er vigtigt.
For hvis virksomheden vil øge antallet af værdifulde forespørgsler, betyder det ikke nødvendigvis succes blot at øge trafikken. Vi kan få ti gange flere besøg uden en eneste ekstra kunde.
Den største fejl? Designe uden svar på "hvorfor?"
Man kan lave et visuelt flot site.
Man kan bruge en moderne teknologistak.
Man kan lave perfekte animationer.
Man kan finpudse hver pixel.
Alligevel kan projektet undlade at give forretningen de forventede resultater. Hvorfor?
Fordi der manglede svar på det vigtigste spørgsmål: Hvorfor gør vi det?
Hvis svaret er: "Fordi den gamle side er grim",
er det ofte for lidt.
Hvis svaret derimod er: "Vi vil øge antallet af B2B-forespørgsler, forkorte tiden til at finde den rette service og aflaste salgsafdelingen fra gentagne spørgsmål",
så har vi pludselig et konkret problem at løse.
Og vi kan designe en løsning.
Hos Web24 vil vi ikke blot levere sider
Det er forskellen mellem at udføre en opgave og et teknologisk partnerskab.
Hvis en klient kommer med en konkret idé, betyder det ikke, at vores opgave er at udføre den uden refleksion.
Vores opgave er også at sige: "Det giver mening".
Eller: "Det kan gøres bedre".
Eller: "Teknisk kan vi bygge det, men vi ser ingen forretningsmæssig begrundelse".
Eller: "Inden vi gør det, tjekker vi, om brugerne virkelig har brug for det".
Nogle gange er det bedste designvalg at tilføje en funktion. Nogle gange at fjerne den. Nogle gange at ændre hele antagelsen.
Og netop derfor ligger teamets erfaring ikke i, at vi kan bygge alt, men i at vi kan genkende, hvad der virkelig er værd at bygge.
Der findes ikke to identiske projekter
Det fører os tilbage til udgangspunktet.
Vi kan have to kunder i samme branche: to producenter, to shops, to advokatfirmaer, to softwarehuse.
Deres sites kan se ens ud. Men de bør ikke være identiske bare fordi de er i samme kategori.
Fordi deres mennesker, strategi, salgsproces, tilbud, budget, teknologi, kunder og mål er forskellige.
Derfor kræver hvert projekt egne beslutninger.
Ikke altid spektakulære. Ikke altid banebrydende. Men bevidste.
Websitet som et værktøj, ikke dekoration
Et godt designet site bør være mere end et digitalt visitkort for virksomheden.
Det bør hjælpe brugeren med at træffe beslutninger. Lettere salg. Svare på spørgsmål. Bygge tillid. Understøtte medarbejdere. Integrere med øvrige systemer, hvor det giver mening.
Og frem for alt bør det realisere et konkret forretningsmål.
Derfor er der ikke ét svar på: "Hvordan skal et godt website se ud?"
Et bedre spørgsmål er: "Hvordan skal dette konkrete firmas site fungere for at hjælpe dem med at nå deres mål?"
Og det spørgsmål bør ethvert godt projekt starte med.
Til sidst - den vigtigste regel
Vi designer ikke et site for at klienten kan sige: "Hvor pænt".
Vi designer det, så klienten efter nogle måneder kan sige: "Det hjælper os virkelig med at drive forretning".
Forskellen mellem et pænt site og et godt digitalt produkt er ofte ikke synlig på første skærm.
Den ses først i resultaterne.
Opsummering af hele serien
I denne serie så vi på, hvorfor vi ikke designer to ens websites.
Vi startede med en simpel antagelse: samme branche betyder ikke samme forretning.
Derefter viste vi, hvordan virksomhedens strategi, salgsmetode, målgruppe og brugernes behov påvirker UX, informationsarkitektur og funktionalitet.
I den sidste del gennemgik vi designprocessen - fra Discovery og forretningsforståelse, gennem User Flow, wireframes og Design System, til teknologi, integrationer, test, analytics og videreudvikling.
For et individuelt design betyder det ikke bare "et andet udseende".
Det betyder andre beslutninger baseret på et andet problem.
Og netop derfor bør hver virksomhed få en løsning designet til sig, ikke til "en gennemsnitlig virksomhed i branchen".
