Var börjar egentligen en bra design?
I tidigare delar drog vi en viktig slutsats - vi designar inte en webbplats bara för att företaget behöver en "ny webbplats".
Vi designar ett verktyg som ska lösa ett konkret problem.
Ibland är problemet svag försäljning. Ibland för få förfrågningar. Ibland kan kunderna inte hitta information. Andra gånger svarar säljarna dagligen på samma frågor eftersom webbplatsen inte förmedlar grundläggande information. Det händer också att företaget helt enkelt har vuxit och den befintliga sajten inte längre motsvarar dess verkliga omfattning.
Därför bör första steget inte vara Photoshop, Figma eller val av ramverk.
Första steget bör vara ett samtal.
Först lär vi känna verksamheten
En bra UX-designer behöver inte vara expert i varje bransch hen designar för. Däremot måste hen förstå kundens verksamhet tillräckligt väl för att veta vilka problem som ska lösas.
Därför frågar vi om saker som i början kan verka orelaterade till design;
- Var kommer kunderna ifrån?
- Varför väljer de just detta företag?
- Varför lämnar de?
- Vad frågar de oftast före ett köp?
- Hur ser försäljningsprocessen ut?
- Vem ansvarar för att hantera förfrågningar?
- Vad händer med en lead efter att ett formulär skickats?
- Vilka produkter är viktigast?
- Vilka tjänster har störst potential?
- Vill företaget öka antalet förfrågningar, ordervärdet, antalet kunder eller kanske framför allt förbättra sin image?
Först när vi fått svar på sådana frågor kan vi avgöra vad vi egentligen bör designa.
Discovery - innan den första mockupen skapas
I digitala projekt används ofta begreppet Discovery.
Det är steget där man lär sig om problemet, användarna, affärsmålen, begränsningar och tekniska möjligheter innan man börjar med själva designen och utvecklingen.
Det är inte en "tidsförlust innan arbetet börjar". I ett väl genomfört projekt ska Discovery minska risken att bygga något som ser bra ut men inte löser det verkliga problemet.
Vi kan till exempel upptäcka att kunden inte alls behöver en ny webbplats.
Kanske behöver de bättre informationsarkitektur.
Eller förenkling av köpprocessen.
Eller integration av webbplatsen med CRM.
Eller automatisering av hanteringen av förfrågningar.
Eller ett helt annat sätt att presentera erbjudandet.
Och just därför är det ibland värt att pausa innan produktionen påbörjas.
UX börjar inte med utseendet
UX, det vill säga User Experience, betyder användarens upplevelse när hen använder en produkt eller tjänst.
För en webbplats innefattar det mycket mer än hur gränssnittet ser ut.
Det handlar också om:
- sättet att navigera på sidan,
- lättheten att hitta information,
- tydlighet i budskapen,
- köpprocessen,
- formulär,
- innehierarki,
- hur snabbt uppgifter utförs,
- systemets respons på användarens handlingar,
- tillgänglighet,
- känsla av säkerhet och förtroende.
Därför börjar UX långt innan någon ritar den första skärmen.
Först måste vi förstå vad användaren försöker uppnå.
User Flow - vilken väg ska användaren ta för att nå målet?
Ett av grundläggande verktyg inom UX-design är User Flow. Det är en beskrivning av stigen användaren går för att utföra en viss uppgift.
Till exempel kan det i en butik se ut så här: reklam → produktsida → välj variant → varukorg → leverans → betalning → orderbekräftelse.
I ett tjänsteföretag: Google → tjänstesida → referenser → case → formulär → kontakt med säljare.
För en tillverkare: sökmotor → produkt → tekniska specifikationer → dokumentation → offertförfrågan.
Var och en av dessa vägar kräver olika designbeslut.
Om användarens viktigaste mål är att köpa kan vi inte tvinga hen att läsa ett dussin skärmar med text. Om produkten däremot är dyr, komplex och kräver konsultation kan det vara lika fel att snabbt leda vidare till ett formulär.
UX handlar bland annat om att hitta rätt nivå av vägledning för användaren.
Wireframe - innan vi börjar "försköna"
Nästa steg kan vara en wireframe, ett förenklat diagram över skärmen som visar hur innehåll och funktioner ska placeras.
Wireframet behöver inte vara vackert. Och det är bra så. I detta skede handlar det inte om vilken färg knappen ska ha.
Det handlar om att svara på frågor:
- Vad ser användaren först?
- Vad kommer att vara viktigast?
- Vad bör vara högst upp?
- Var placerar vi tilläggsinformation?
- Hur går användaren vidare till nästa steg?
- Vad händer efter ett klick?
Det är lite som att planera en lägenhet.
Först bestämmer vi var väggar, dörrar och rum ska vara. Först senare tänker vi på väggfärgen.
Designsystem - så att projektet inte blir en hopplockning av slumpmässiga element
I större projekt dyker ett annat viktigt element upp - Design System.
Det är en ordnad uppsättning regler, komponenter och mönster som definierar hur gränssnitt byggs.
Det kan omfatta bland annat:
- färger,
- typografi,
- knappar,
- formulär,
- kort,
- tabeller,
- meddelanden,
- ikoner,
- marginaler,
- responsivitetsregler,
- komponenters beteenden.
Varför? - För att gränssnittet ska vara konsekvent.
Om en knapp beter sig på ett sätt på en undersida och helt annorlunda på en annan, måste användaren lära om gränssnittet varje gång.
Designsystemet hjälper också utvecklingsteamet. Istället för att bygga varje komponent från grunden kan de återanvända tidigare fastställda element.
Det leder till större konsekvens, enklare utveckling och ofta även lägre kostnader för underhåll.
Och var passar tekniken in i allt detta?
Tekniken bör involveras i god tid, men den bör inte diktera hela projektet. Det är en viktig distinktion.
Designern kan hitta på en fantastisk funktion som ur ett affärsperspektiv är logisk. Utvecklaren kan dock påpeka att implementeringen blir mycket kostsam eller skapar prestandaproblem.
Å andra sidan kan utvecklaren föreslå en teknisk lösning som är enkel att genomföra, men som ur användarens perspektiv inte löser problemet tillräckligt bra.
Därför blir de bästa projekten till när UX, design, utveckling och affärssidan samtalar från början.
Inte enligt principen: "Först design, sedan utvecklare".
Utan: "Vi funderar tillsammans på hur vi bäst löser problemet".
Teknik bör inte väljas för att den är trendig
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, native-app, PWA... man kan rada upp många teknologier.
Men kunden köper inte teknologi. Kunden köper en lösning.
Därför är frågan: "Vilket ramverk ska vi använda?"
ofta mindre viktig än: "Vilka problem ska systemet lösa?" Först därefter kan man välja lämplig arkitektur.
En enkel företagswebb behöver annan teknologi än en butik som hanterar tusentals ordrar, och helt annan än en B2B-plattform med omfattande integrationer och individuella användarrättigheter.
Teknologin bör följa kraven, inte kraven följa teknologin.
Backend, frontend och det utrymme användaren inte ser
Det är också värt att komma ihåg att en webbplats inte bara är det vi ser i webbläsaren.
Frontend ansvarar för den del av applikationen som användaren direkt interagerar med.
Backend ansvarar för logiken på serversidan - databehandling, kommunikation med databasen, processhantering och integrationer.
Och mellan dem finns ofta många ytterligare element;
- CRM.
- ERP.
- Betalningssystem.
- E-postplattform.
- Lagersystem.
- API.
- Analys.
- Automatiseringar.
- Kundservice-system.
Om vi designar en ny webbplats utan att ta hänsyn till detta ekosystem kan vi bygga en vacker frontend som fungerar som en ensam ö.
Men målet bör vara något helt annat.
En bra webbplats kan göra mycket mer än att "samla in formulär"
En modern webbplats kan vara en del av en större affärsprocess;
- Användaren skickar en förfrågan.
- Systemet känner igen ämnet.
- Leaden går till CRM.
- Säljaren får en avisering.
- Kunden får en automatisk bekräftelse.
- Data kategoriseras korrekt.
- Systemet kan kontrollera produktens tillgänglighet.
- Det kan förbereda information för säljaren.
- Det kan starta ett bestämt workflow.
I en butik kan en beställning automatiskt gå igenom olika steg i leveransprocessen. I B2B kan kunden få tillgång till individuella priser, dokument och orderhistorik.
Då slutar webbplatsen vara bara en "visitkort". Den blir en del av affärsinfrastrukturen.
Vad händer med AI?
AI kan också vara en del av ett sådant system. Men återigen - den bör inte läggas till bara för att "alla nu har AI".
Om en chatbot inte löser något verkligt problem blir den bara ytterligare ett fönster på sidan.
Om användaren däremot kan hitta rätt produkt snabbare med hjälp av AI, konfigurera en tjänst, få svar på en fråga eller gå igenom ett valprocess, då börjar teknologin vara motiverad.
Samma gäller personalisering.
Vi kan visa olika innehåll beroende på användarens beteende, trafikkälla eller vilket steg i köpprocessen hen befinner sig i. Vi kan analysera data och bättre förutse kundernas behov.
Men vi bör alltid börja med frågan: "Vilket problem löser vi?"
Först därefter: "Är AI det bästa sättet att lösa det?"
Vi testar inte bara om det fungerar
Ett av de vanligaste misstagen är att testa webbplatsen först i slutet. Då upptäcker vi att formuläret är för långt, köpprocessen ologisk och att användaren inte hittar det viktigaste.
Ju senare vi upptäcker ett sådant problem, desto dyrare blir det att åtgärda.
Därför är det värt att testa i etapper. Vi kan testa prototyper. Vi kan observera användarbeteende. Vi kan genomföra användbarhetstester. Vi kan analysera data från Google Analytics eller andra analysverktyg. Vi kan använda inspelningar av sessioner eller värmekartor, om de är implementerade i enlighet med sekretesskrav. Vi kan också helt enkelt prata med säljarna.
Det sistnämnda är ofta underskattat.
Säljaren hör dagligen kunders frågor; hen vet vad som inte förstås. Hen vet vad kunderna oroar sig för. Hen vet vilken information som måste ges före köp.
Det är en enorm kunskapskälla för designen.
MVP betyder inte vad som helst
I digitala projekt används ofta begreppet MVP - Minimum Viable Product.
Det handlar om den första versionen av produkten som innehåller den minsta uppsättning funktioner som behövs för att verifiera antaganden och leverera värde till användarna.
MVP bör inte betyda: "Låt oss slarva ihop något och se senare".
Ett bra MVP ska svara på frågan: "Vad är den minsta versionen av lösningen som låter oss testa om vi valt rätt riktning?"
Det är också mycket viktigt för webbplatser och applikationer.
Istället för att bygga trettio funktioner direkt kan det vara bättre att lansera de fem viktigaste och se hur användarna faktiskt använder dem. Senare utvecklar vi systemet baserat på verkliga data, inte bara antaganden från första mötet.
Webbplatsen tar inte slut på publiceringsdagen
Det är en annan sak vi ofta glömmer.
Publiceringsögonblicket är egentligen början på dess verkliga liv. Först då kommer riktiga användare. Först då ser vi vilka innehåll som fungerar. Först då vet vi vilka element som ignoreras. Först då kan vi kontrollera om antalet förfrågningar, försäljning, tid på sidan eller andra indikatorer som vi tidigare definierat har ökat.
Därför bör projektet vidareutvecklas;
- Analys.
- Insikter.
- Förändring.
- Test.
- Ny analys.
Det liknar mer en cykel än en engångshändelse.
Vad bör egentligen mätas?
Det beror på projektets mål.
För en e-handel kan det vara:
- konverteringsgrad,
- genomsnittligt ordervärde,
- varukorgsavhopp,
- intäkter,
- kundvärde över tid.
För ett tjänsteföretag:
- antal värdefulla leads,
- formulärkonverteringsgrad,
- antal bokade konsultationer,
- kostnad per lead,
- kvalitet på förfrågningarna.
För en informationssajt:
- hitta specifik information,
- användarengagemang,
- antal återbesök,
- nedladdningar av material.
Man behöver inte mäta allt. Men man måste veta vad som är viktigt.
För om företaget vill öka antalet värdefulla förfrågningar betyder inte en ökad trafik nödvändigtvis framgång. Vi kan ha tio gånger fler besök och ingen extra kund.
Största misstaget? Design utan svar på frågan "varför?"
Man kan skapa en visuellt fantastisk sajt.
Man kan använda en modern teknologistack.
Man kan förbereda perfekta animationer.
Man kan vårda varje pixel.
Och ändå kanske projektet inte ger företaget förväntade resultat. - Varför?
För att det saknades svar på den viktigaste frågan: Varför gör vi allt detta?
Om svaret är: "För att den gamla sidan är ful",
så är det lite för tunt.
Om svaret däremot är: "Vi vill öka antalet förfrågningar från B2B-kunder, förkorta vägen till rätt tjänst och avlasta säljavdelningen från att svara på repetitiva frågor",
då har vi plötsligt ett konkret problem att lösa.
Och vi kan designa en lösning.
På Web24 vill vi inte bara leverera sidor
Det är skillnaden mellan att utföra en beställning och att ha ett teknologiskt samarbete.
Om en kund kommer med en konkret idé betyder det inte att vårt uppdrag är att utan reflektion förverkliga den.
Vårt uppdrag är också att säga: "Detta gör mening".
Eller: "Det går att göra det bättre".
Eller: "Tekniskt kan vi bygga det, men vi ser ingen affärsmässig motivering".
Eller: "Innan vi gör det ska vi kontrollera om användarna verkligen behöver det".
Ibland är det bästa designbeslutet att lägga till en funktion. Ibland att ta bort den. Ibland att ändra hela förutsättningen.
Och just där ligger teamets erfarenhet - inte i att vi kan bygga allt, utan i att vi kan avgöra vad som verkligen är värt att bygga.
Det finns inga två identiska projekt
Det tar oss tillbaka till utgångspunkten.
Vi kan ha två kunder i samma bransch. Vi kan ha två tillverkare. Två butiker. Två advokatbyråer. Två mjukvaruföretag.
Deras sajter kan se lika ut. Men de bör inte vara lika bara för att de verkar i samma kategori.
För de skiljer sig åt: människor. Strategi. Försäljningsprocess. Erbjudande. Budget. Teknik. Kunder. Mål.
Och just därför kräver varje projekt egna beslut.
Inte alltid spektakulära. Inte alltid banbrytande. Men medvetna.
Webbplatsen som verktyg, inte dekoration
En väl designad webbplats bör vara mer för företaget än en digital visitkort.
Den bör hjälpa användaren att fatta beslut. Den bör underlätta försäljningen. Den bör svara på frågor. Bygga förtroende. Stötta medarbetare. Integrera med andra system där det är meningsfullt.
Och framför allt bör den uppfylla ett konkret affärsmål.
Därför finns det inget enda svar på frågan: "Hur ska en bra webbplats se ut?"
En bättre fråga är: "Hur ska denna specifika företags webbplats fungera för att hjälpa dem nå sina mål?"
Och just från den frågan bör varje bra projekt börja.
Till sist - den viktigaste regeln
Vi designar inte en sida för att kunden ska kunna säga: "Men visst är den fin".
Vi designar den för att efter några månader kunna säga: "Det här hjälper oss verkligen att driva affären".
Skillnaden mellan en snygg sida och en bra digital produkt syns ofta inte på första skärmen.
Den syns först i resultaten.
Sammanfattning av serien
I den här serien har vi sett varför vi inte designar två identiska webbplatser.
Vi började med ett enkelt antagande: samma bransch innebär inte samma verksamhet.
Sedan visade vi hur företagets strategi, försäljningssätt, målgrupp och användarbehov påverkar UX, informationsarkitektur och funktionalitet.
I sista delen gick vi igenom designprocessen - från Discovery och att lära känna verksamheten, genom User Flow, wireframes och Design System, till teknik, integrationer, testning, analys och vidareutveckling.
För en individuell design betyder det inte bara "annorlunda utseende".
Det betyder andra beslut som följer av ett annat problem.
Och just därför bör varje företag få en lösning designad för dem, inte för "genomsnittsföretaget i branschen".
