Waar begint een goed ontwerp echt?
In de vorige delen kwamen we tot een belangrijke conclusie - we ontwerpen geen website alleen omdat het bedrijf een "nieuwe website" nodig heeft.
We ontwerpen een tool die een concreet probleem moet oplossen.
Soms is het probleem een slechte verkoop. Soms te weinig aanvragen. Soms kunnen klanten de informatie niet vinden. Andere keren beantwoorden verkopers elke dag dezelfde vragen omdat de site geen basisinformatie biedt. Het kan ook zo zijn dat het bedrijf is gegroeid en de bestaande site niet meer past bij de werkelijke schaal.
Daarom zou de eerste stap geen Photoshop, Figma of frameworkkeuze moeten zijn.
De eerste stap zou een gesprek moeten zijn.
Eerst leren we het bedrijf kennen
Een goede UX-ontwerper hoeft niet in elke sector een expert te worden. Wel moet hij het bedrijf van de klant voldoende begrijpen om te weten welke problemen het probeert op te lossen.
Daarom stellen we vragen die aanvankelijk misschien niet direct met ontwerp te maken lijken te hebben;
- Waar komen de klanten vandaan?
- Waarom kiezen ze juist dit bedrijf?
- Waarom haken ze af?
- Wat vragen ze meestal voor aankoop?
- Hoe ziet het verkoopproces eruit?
- Wie is verantwoordelijk voor het behandelen van aanvragen?
- Wat gebeurt er met een lead nadat het formulier is verzonden?
- Welke producten zijn het belangrijkst?
- Welke diensten hebben het grootste potentieel?
- Wil het bedrijf het aantal aanvragen verhogen, de orderwaarde, het aantal klanten of vooral zijn imago verbeteren?
Pas antwoorden op zulke vragen maken duidelijk wat we eigenlijk zouden moeten ontwerpen.
Discovery - voordat de eerste mockup ontstaat
In digitale projecten gebruikt men vaak de term Discovery.
Het is de fase van het leren kennen van het probleem, gebruikers, zakelijke doelen, beperkingen en technologische mogelijkheden voordat het echte ontwerp en de development beginnen.
Het is geen "verspilde tijd voordat we beginnen". In een goed geleid project moet Discovery het risico beperken dat we iets bouwen dat er mooi uitziet, maar het echte probleem niet oplost.
We kunnen bijvoorbeeld ontdekken dat de klant helemaal geen nieuwe website nodig heeft.
Misschien heeft hij een betere informatiearchitectuur nodig.
Of vereenvoudiging van het aankoopproces.
Of integratie van de site met het CRM.
Of automatisering van het behandelen van aanvragen.
Of een totaal andere manier om het aanbod te presenteren.
En daarom is het soms de moeite waard om even te stoppen voordat we beginnen met produceren.
UX begint niet bij uiterlijk
UX, oftewel User Experience, betekent de ervaring van de gebruiker bij het gebruik van een product of dienst.
Bij een website omvat het veel meer dan alleen het uiterlijk van de interface.
Het is ook:
- de manier waarop men door de site navigeert,
- de vindbaarheid van informatie,
- de duidelijkheid van boodschappen,
- het aankoopproces,
- formulieren,
- contenthiërarchie,
- snelheid van taken uitvoeren,
- reactie van het systeem op gebruikersacties,
- toegankelijkheid,
- gevoel van veiligheid en vertrouwen.
Daarom begint UX nog voordat iemand het eerste scherm tekent.
Eerst moet je begrijpen wat de gebruiker probeert te bereiken.
User Flow - via welke weg moet de gebruiker zijn doel bereiken?
Een van de basistools van UX-ontwerp is de User Flow. Dit is de beschrijving van het pad dat de gebruiker volgt om een bepaalde taak uit te voeren.
Bijvoorbeeld in een webshop kan het er zo uitzien: advertentie → productpagina → keuze variant → winkelwagen → levering → betaling → orderbevestiging.
In een dienstverlenend bedrijf: Google → dienstpagina → realisaties → referenties → formulier → contact met verkoper.
Bij een fabrikant: zoekfunctie → product → technische specificaties → documentatie → offerteaanvraag.
Elk van deze paden vereist andere ontwerpbeslissingen.
Als het belangrijkste doel van de gebruiker aankoop is, mogen we hem niet dwingen om tientallen schermen tekst te lezen. Als het product daarentegen duur en complex is en consultatie vereist, kan te snel richting formulier leiden ook een slechte keuze zijn.
UX draait onder andere om het vinden van het juiste niveau van begeleiding voor de gebruiker.
Wireframe - voordat we gaan "verfraaien"
Een volgende stap kan een wireframe zijn, een vereenvoudigd schema van het scherm dat de indeling van content en functies toont.
Een wireframe hoeft niet mooi te zijn. En dat is goed. In dit stadium gaat het niet om of de knopkleur goed gekozen is.
Het gaat om antwoorden op vragen:
- Wat ziet de gebruiker als eerste?
- Wat is het belangrijkste?
- Wat moet hoger geplaatst worden?
- Waar plaatsen we aanvullende informatie?
- Hoe gaat de gebruiker naar de volgende stap?
- Wat gebeurt er na een klik?
Het is een beetje zoals het ontwerpen van een huis.
Eerst bepalen we waar muren, deuren en kamers komen. Pas later denken we na over muurkleuren.
Design system - zodat het ontwerp geen samenraapsel van toevallige elementen wordt
In grotere projecten verschijnt een ander belangrijk element - het Design System.
Dat is een gestructureerde set regels, componenten en patronen die definiëren hoe de interface wordt opgebouwd.
Het kan onder andere bevatten:
- kleuren,
- typografie,
- knoppen,
- formulieren,
- kaarten,
- tabellen,
- meldingen,
- iconen,
- marges,
- regels voor responsiviteit,
- gedragingen van componenten.
Waarom? - zodat de interface consistent is.
Als op de ene pagina een knop op een manier werkt en op een andere pagina totaal anders, moet de gebruiker telkens opnieuw de interface leren.
Een Design System helpt ook het developmentteam. In plaats van steeds opnieuw een component vanaf nul te bouwen, kan men gebruikmaken van vooraf ingestelde elementen.
Dat leidt tot meer consistentie, gemakkelijker onderhoud en vaak ook lagere kosten voor het beheer van het project.
En waar past technologie in dit geheel?
Technologie moet tijdig in beeld komen, maar mag niet het hele project dicteren. Dat is een belangrijk onderscheid.
De ontwerper kan een geweldige functie bedenken die zakelijk zinvol is. De developer kan echter opmerken dat de implementatie erg duur is of prestatieproblemen veroorzaakt.
Aan de andere kant kan een developer een technologische oplossing voorstellen die heel makkelijk te implementeren is, maar vanuit gebruikersperspectief het probleem niet goed genoeg oplost.
Daarom ontstaan de beste projecten waar UX, design, development en business vanaf het begin met elkaar praten.
Niet volgens het patroon: "Eerst de ontwerpers, daarna de developers".
Maar: "We bedenken samen hoe we het probleem het beste oplossen".
Technologie moet niet gekozen worden omdat het hip is
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, native app, PWA... je kunt een lange lijst maken van technologieën.
Maar de klant koopt geen technologie. Hij koopt een oplossing.
Dus de vraag: "Welke framework gebruiken we?"
is vaak minder belangrijk dan: "Welke problemen moet het systeem oplossen?" Pas daarna kies je de juiste architectuur.
Een eenvoudige bedrijfswebsite heeft andere technologie nodig dan een winkel die duizenden orders verwerkt, en weer andere dan een B2B-platform met uitgebreide integraties en individuele gebruikersrechten.
Technologie moet voortkomen uit de eisen, niet de eisen uit de technologie.
Backend, frontend en het deel dat de gebruiker niet ziet
Het is ook goed te onthouden dat een website niet alleen is wat we in de browser zien.
Frontend is verantwoordelijk voor het deel van de applicatie waarmee de gebruiker direct interacteert.
Backend is verantwoordelijk voor de logica aan de serverzijde - gegevensverwerking, databasecommunicatie, procesafhandeling en integraties.
En tussen die twee bevinden zich vaak nogal wat extra elementen;
- CRM.
- ERP.
- Betaalsysteem.
- Mailingplatform.
- Magazijnsysteem.
- API.
- Analytics.
- Automatiseringen.
- Klantenservicesysteem.
Als we een nieuwe site ontwerpen zonder rekening te houden met dit ecosysteem, kunnen we een prachtige frontend maken die functioneert als een geïsoleerd eiland.
Terwijl het doel iets heel anders zou moeten zijn.
Een goede site kan veel meer dan alleen "formulieren verzamelen"
Een moderne website kan onderdeel zijn van een groter bedrijfsproces;
- De gebruiker stuurt een aanvraag.
- Het systeem herkent het onderwerp.
- De lead gaat naar het CRM.
- De verkoper krijgt een melding.
- De klant ontvangt een automatische bevestiging.
- De gegevens worden aan de juiste categorie toegewezen.
- Het systeem kan de productbeschikbaarheid controleren.
- Het kan informatie voor de verkoper voorbereiden.
- Het kan een bepaald workflow starten.
In een webshop kan een bestelling automatisch door de volgende realisatiefasen gaan. In B2B kan een klant toegang krijgen tot individuele prijzen, documenten en ordergeschiedenis.
Dan wordt de site geen "visitekaartje" meer. Het wordt onderdeel van de zakelijke infrastructuur.
Wat met AI?
AI kan ook onderdeel zijn van zo’n systeem. Maar nogmaals - het moet niet worden toegevoegd alleen omdat "iedereen nu AI heeft".
Als een chatbot geen echt probleem oplost, is het slechts nog een venster op de site.
Als AI de gebruiker daarentegen helpt om sneller het juiste product te vinden, een dienst te configureren, antwoord op een vraag te krijgen of door een keuzeproces te lopen, dan krijgt de technologie een reden van bestaan.
Hetzelfde geldt voor personalisatie.
We kunnen de gebruiker andere content tonen afhankelijk van zijn gedrag, verkeersbron of aankoopfase. We kunnen data analyseren en beter de behoeften van klanten voorspellen.
Maar we moeten altijd beginnen met de vraag: "Welk probleem lossen we op?"
En pas daarna: "Is AI de beste manier om het op te lossen?"
We testen niet alleen of het werkt
Een van de meest voorkomende fouten is pas aan het eind te testen. Dan ontdekken we dat het formulier te lang is, het aankoopproces niet intuïtief en de gebruiker de belangrijkste informatie niet vindt.
Hoe later we zo’n probleem ontdekken, hoe duurder het is om het te verhelpen.
Daarom is het verstandig om het project in fasen te testen. We kunnen prototypen testen. We kunnen gebruikersgedrag observeren. We kunnen gebruikerstests uitvoeren. We kunnen data uit Google Analytics of andere analysetools analyseren. We kunnen sessie-opnames of heatmaps gebruiken, mits ze zijn geïmplementeerd volgens privacyvereisten. We kunnen ook gewoon met verkopers praten.
Dat laatste wordt vaak onderschat.
Een verkoper hoort dagelijks klantvragen; hij weet wat ze niet begrijpen. Hij weet waar ze bang voor zijn. Hij weet welke informatie vóór aankoop moet worden gegeven.
Dat is enorme ontwerpkennis.
MVP betekent niet wat dan ook
In digitale projecten komt vaak de term MVP - Minimum Viable Product voor.
Het gaat om de eerste versie van het product met de minimale set functies die nodig zijn om aannames te verifiëren en waarde te leveren aan gebruikers.
MVP mag niet betekenen: "Laten we iets in elkaar flansen en later zien we het".
Een goede MVP moet antwoord geven op de vraag: "Wat is de kleinste versie van de oplossing die ons laat controleren of we de juiste richting kiezen?"
Dat is ook erg belangrijk voor websites en apps.
In plaats van meteen dertig functies te bouwen, is het soms beter om de vijf belangrijkste te lanceren en te kijken hoe gebruikers ze gebruiken. Later breid je het systeem op basis van echte data, niet alleen op basis van aannames van de eerste meeting.
De site eindigt niet op de publicatiedag
Dit is nog zo’n ding dat we vaak vergeten.
De livegang van de site is eigenlijk het begin van haar echte leven. Pas dan verschijnen echte gebruikers. Pas dan zien we welke content werkt. Pas dan weten we welke onderdelen genegeerd worden. Pas dan kunnen we controleren of het aantal aanvragen, de verkoop, de tijd op de site of andere eerder vastgestelde indicatoren zijn toegenomen.
Daarom moet het project worden doorontwikkeld;
- Analyse.
- Conclusies.
- Verandering.
- Test.
- Heranalyse.
Het lijkt meer op een cyclus dan op een eenmalig evenement.
Wat moet eigenlijk gemeten worden?
Dat hangt af van het doel van het project.
Voor een webwinkel kunnen dat zijn:
- conversieratio,
- gemiddelde orderwaarde,
- winkelwagenverlaters,
- omzet,
- customer lifetime value.
Voor een dienstverlener:
- aantal waardevolle leads,
- formulierconversie,
- aantal geplande consulten,
- kosten per lead,
- kwaliteit van aanvragen.
Voor een informatiedienst:
- het vinden van specifieke informatie,
- gebruikersbetrokkenheid,
- aantal terugkerende bezoekers,
- downloads van materialen.
Je hoeft niet alles te meten. Maar je moet weten wat belangrijk is.
Want als het bedrijf waardevolle aanvragen wil verhogen, betekent meer verkeer op zichzelf niet per se succes. We kunnen tien keer meer bezoeken hebben en geen enkele extra klant.
De grootste fout? Ontwerpen zonder antwoord op de vraag "waarom?"
Je kunt een visueel prachtige site maken.
Je kunt een moderne technologiestack toepassen.
Je kunt perfecte animaties voorbereiden.
Je kunt op elke pixel letten.
En toch kan het project de zakelijke resultaten niet opleveren. - Waarom?
Omdat het antwoord op de belangrijkste vraag ontbrak: Waarom doen we dit allemaal?
Als het antwoord is: "Omdat de oude site lelijk is",
dan is dat te weinig.
Als het antwoord echter is: "We willen het aantal aanvragen van B2B-klanten vergroten, de tijd naar de juiste dienst verkorten en de sales afdeling ontlasten van repetitieve vragen",
hebben we plotseling een concreet probleem om op te lossen.
En kunnen we een oplossing ontwerpen.
Bij Web24 willen we niet alleen sites opleveren
Dat is het verschil tussen het uitvoeren van een opdracht en technologische samenwerking.
Als een klant met een concreet idee komt, betekent dat niet dat ons werk is het klakkeloos te realiseren.
Ons werk is ook om te zeggen: "Dat heeft zin".
Of: "Het kan beter".
Of: "Technisch kunnen we het bouwen, maar we zien geen zakelijke onderbouwing".
Of: "Voordat we het doen, testen we of gebruikers het echt nodig hebben".
Soms is de beste ontwerpbeslissing het toevoegen van een functie. Soms het verwijderen. Soms een volledige herziening van aannames.
En dat is waar de ervaring van het team om draait - niet dat we alles kunnen bouwen, maar dat we kunnen herkennen wat echt de moeite waard is om te bouwen.
Er zijn geen twee identieke projecten
We zijn terug bij het uitgangspunt.
We kunnen twee klanten in dezelfde branche hebben. Twee fabrikanten. Twee webshops. Twee kantoren. Twee softwarehuizen.
Hun sites kunnen er vergelijkbaar uitzien. Maar ze moeten niet hetzelfde zijn alleen omdat ze in dezelfde categorie werken.
Omdat ze verschillen in mensen. Strategie. Verkoopproces. Aanbod. Budget. Technologie. Klanten. Doelstellingen.
En daarom vereist elk project zijn eigen beslissingen.
Niet altijd spectaculair. Niet altijd baanbrekend. Maar wel bewust.
Een website als tool, niet als decoratie
Een goed ontworpen site moet voor een bedrijf meer zijn dan een digitaal visitekaartje.
Ze moet de gebruiker helpen een beslissing te nemen. Ze moet verkoop vergemakkelijken. Ze moet vragen beantwoorden. Ze moet vertrouwen opbouwen. Ze moet medewerkers ondersteunen. Ze moet integreren met andere systemen waar dat zinvol is.
En vooral moet ze een concreet zakelijk doel realiseren.
Daarom is er niet één antwoord op de vraag: "Hoe zou een goede website eruit moeten zien?"
Een betere vraag is: "Hoe moet de site van dit specifieke bedrijf werken om zijn doelen te helpen bereiken?"
En precies vanaf die vraag zou elk goed project moeten beginnen.
Tot slot - de belangrijkste regel
We ontwerpen geen site zodat de klant kan zeggen: "Wat een mooie site".
We ontwerpen haar zodat de klant na enkele maanden kan zeggen: "Dit helpt ons echt ons bedrijf te runnen".
Want het verschil tussen een mooie site en een goed digitaal product is vaak niet zichtbaar op het eerste scherm.
Je ziet het pas in de resultaten.
Samenvatting van de hele serie
In deze serie hebben we gekeken waarom we niet twee identieke websites ontwerpen.
We begonnen met de eenvoudige aanname: dezelfde branche betekent niet hetzelfde bedrijf.
Vervolgens hebben we laten zien hoe bedrijfsstrategie, verkoopmethode, doelgroep en gebruikersbehoeften invloed hebben op UX, informatiearchitectuur en functionaliteiten.
In het laatste deel doorliepen we het ontwerpproces - van Discovery en bedrijfskennis, via User Flow, wireframes en Design System, tot technologie, integraties, testen, analytics en verdere ontwikkeling.
Een individueel ontwerp betekent niet gewoon "een ander uiterlijk".
Het betekent andere beslissingen voortkomend uit een ander probleem.
En daarom verdient elk bedrijf een oplossing die voor hem is ontworpen, niet voor een "gemiddeld bedrijf in de branche".
