De SaaS-websitediagnose die je bureau keer op keer kunt gebruiken zonder dat klanten op elkaar lijken

Samenvatting

Hoe vaak heb je dit kwartaal precies hetzelfde discoverygesprek gevoerd—dezelfde vragen over het product, de klant, de concurrent—voor twee klanten die beweerden totaal verschillend te zijn? Je weet al dat de antwoorden anders zullen zijn, maar de taken die elke SaaS-site moet uitvoeren, zijn dat niet. Elke SaaS-productwebsite is een kleine set machines die dezelfde taken draaien: uitleggen wat het product doet, laten zien wat het kost, ontwikkelaars vertellen hoe ze moeten integreren, bezwaren beantwoorden die een aankoop stoppen en bewijzen dat het bedrijf geloofwaardig is. Een herhaalbare diagnose die die vijf taken controleert, overleeft elk contact met een klant, omdat de taken niet veranderen. Het systeem dat je eromheen bouwt, is wat je in staat stelt om van de ene opdracht naar de volgende te gaan zonder vanaf nul te beginnen. Het kost minder tijd dan je huidige discoveryproces, het geeft de klant een duidelijke reden om je te vertrouwen, en het levert een deliverable op die er niet uit ziet als een sjabloon, omdat de vragen standaard zijn maar de antwoorden specifiek.

Hoe vaak heb je dit kwartaal precies hetzelfde discoverygesprek gevoerd—dezelfde vragen over het product, de klant, de concurrent—voor twee klanten die beweerden totaal verschillend te zijn? Je weet al dat de antwoorden anders zullen zijn, maar de taken die elke SaaS-site moet uitvoeren, zijn dat niet. Elke SaaS-productwebsite is een kleine set machines die dezelfde taken draaien: uitleggen wat het product doet, laten zien wat het kost, ontwikkelaars vertellen hoe ze moeten integreren, bezwaren beantwoorden die een aankoop stoppen en bewijzen dat het bedrijf geloofwaardig is. Een herhaalbare diagnose die die vijf taken controleert, overleeft elk contact met een klant, omdat de taken niet veranderen. Het systeem dat je eromheen bouwt, is wat je in staat stelt om van de ene opdracht naar de volgende te gaan zonder vanaf nul te beginnen. Het kost minder tijd dan je huidige discoveryproces, het geeft de klant een duidelijke reden om je te vertrouwen, en het levert een deliverable op die er niet uit ziet als een sjabloon, omdat de vragen standaard zijn maar de antwoorden specifiek.

'Mijn klanten zijn te verschillend voor één systeem'

Voer dezelfde vijfpuntsdiagnose uit bij elke klant voordat je ook maar één woord schrijft of een designtool opent. De verschillen die jouw klanten bijzonder maken—branche, doelgroep, prijsmodel—zitten bovenop een gedeelde basis. Een salarisadministratie-SaaS en een tool voor het plannen van sociale media hebben niets gemeen behalve de vijf taken die elke pagina uitvoert. Als je op die taken controleert, vind je dezelfde patronen op dezelfde plekken.

Pagina of sectie	Waar je klant meestal om vraagt	Wat er daadwerkelijk op de pagina gebeurt
Functie-showcase	'Laat elke functie zien die we hebben gebouwd'	Het tonen van het resultaat dat een gebruiker krijgt, niet alleen de functie. Beelden zoals screenshots, GIF's of video's moeten een moment demonstreren waarop het product de manier waarop iemand werkt verandert.
Prijzen	'Maak de prijzen makkelijk leesbaar'	De koper wordt gedwongen te beslissen welk abonnement voor hem of haar is. De niveaus moeten als een progressie lezen die een keuze begeleidt, niet als een platte lijst met prijzen.
API-documentatie	'Onze ontwikkelaars vinden dat in de docs'	Vaak de eerste test die een ontwikkelaar uitvoert bij het evalueren of het product te vertrouwen is. Duidelijkheid is hier een functie, geen aardigheid.
FAQ-sectie	'Beantwoord vragen zodat supportgesprekken afnemen'	Het laatste wat een koper leest voordat hij op een knop klikt. Het moet prijsbezwaren en randgevallen behandelen, niet alleen algemene bedrijfsvragen.
Social proof	'Zet de logo's erop'	Het bewijs dat de eerder gemaakte claims waar zijn. Logo's en testimonials zijn vertrouwensindicatoren, geen decoratie.

Een diagnose is geen sjabloon. Het is een reeks vragen die je aan elke pagina stelt: zorgt dit ervoor dat de koper begrijpt wat het product doet, maakt het de volgende stap duidelijk, beantwoordt het het bezwaar dat de verkoop op dit moment blokkeert? Wanneer je deze vragen stelt in aanwezigheid van een klant, ziet de klant jou als de persoon die hun markt begrijpt, in plaats van als het tiende bureau dat een slide deck liet zien. Het onderzoek naar SaaS-websites wijst op bedrijven zoals HubSpot, Slack en Zendesk als voorbeelden van goed georganiseerde FAQ-secties, en op Stripe, GitHub en Twilio als normen voor documentatieduidelijkheid. Geen van die bedrijven is daar gekomen door de FAQ te behandelen als een stapel supporttickets. Ze behandelden het als een conversieoppervlak. Dat is de houding die jouw diagnose bij elke klant moet brengen.

Neem een klant die voorraadsoftware verkoopt en een andere die salarissoftware verkoopt. De diagnose brengt vaak dezelfde drie hiaten aan het licht: de functiepagina vermeldt modules in plaats van resultaten, de prijspagina rechtvaardigt de sprong tussen abonnementen niet, en de FAQ beantwoordt supportvragen in plaats van aankoopaarzelingen. Omdat je deze hiaten in beide hebt gezien, weet je precies waar je in de ontwerpfase om moet vragen. De klant ziet een proces dat specifiek is, niet generiek. Schrijf de diagnose als een PDF van één pagina met voor elke taak een score van 1 tot 5 en een notitie per taak. Deel het met de klant vóór de design-kickoff. Dit geeft jullie een gedeelde woordenschat en verandert de audit in een deliverable waar je voor kunt factureren. Dit is de kern van een herhaalbaar systeem, en we hebben een aparte walkthrough over hoe je dat systeem opzet hier.

'Het zorgt ervoor dat ons werk eruitziet als dat van alle anderen'

Standaardiseer de vragen die je stelt, niet de antwoorden die je levert. De diagnose geeft je een beoordelingsrubriek, geen lay-out. Het onderzoek naar SaaS-featureshows toont aan dat ze gebruikmaken van beelden zoals screenshots, GIF's of video's—maar de inhoud van die beelden is voor elk product verschillend. De salarisrapportagefunctie in een HR-tool en de barcodescanfunctie in voorraadsoftware zullen er nooit hetzelfde uitzien. Wat constant blijft, is de vraag die je aan je strategische geest stelt: 'Toont deze pagina het resultaat, of alleen de functie?'

Het aanmeldformulier van een arts zorgt er niet voor dat alle diagnoses hetzelfde zijn; het maakt de arts betrouwbaar. Jouw raamwerk is het aanmeldformulier. De klant krijgt nog steeds een op maat gemaakte website, maar jij krijgt een diagnose die herhaalbaar is. Wat je werk er daadwerkelijk generiek uit zal laten zien, is het ontbreken van een diagnose—want zonder diagnose val je terug op dezelfde hero-afbeelding, dezelfde driekoloms-functielay-out, dezelfde homepage-structuur die je voor het laatste project gebruikte om snel te kunnen schakelen. De diagnose dwingt je om de structuur te rechtvaardigen op basis van het bewijs, zodat elke site structureel verschilt waar dat nodig is.

In de praktijk betekent dit dat de diagnose je kan vertellen om de functiepagina van de ene klant te starten met een video van een importwizard en die van een andere met een GIF van een drag-and-drop rapportbuilder. De paginastructuur blijft hetzelfde, maar de assets, de tekst en het tempo zijn uniek. De klant ziet maatwerk; jij ziet een herhaalbaar proces. Wanneer je de diagnose aan een klant presenteert, laat je zien dat je weet wat elke SaaS-site moet doen. Dat is een sterkere pitch dan 'we maken een uniek design.' Het design is het gevolg van de diagnose, niet het startpunt.

'We hebben geen tijd om elke pagina te controleren'

Doe de gerichte 90-minutenversie, geen volledige audit. De meeste discoveryprocessen van bureaus zijn al een audit, alleen een ongestructureerde. Je besteedt vijfenveertig minuten aan een discoverygesprek dat achtergrond, concurrenten en 'wat wil je hiermee bereiken' behandelt, en dan ben je wekenlang aan het reageren. De diagnose draait dat om: je scoort de vijf taken, zet de fixes met de hoogste hefboom op een rij en gaat over naar het ontwerp. Het bespaart tijd omdat je stopt met het opnieuw doen van werk na de eerste designreview. De goedkoopste fixes zijn de fixes die je maakt voordat iemand pixels ziet.

Hier is een concrete 90-minutenverdeling: blok één (30 minuten) beoordeelt de homepage en functiepagina op de vijf taken. Blok twee (30 minuten) bekijkt de prijspagina en FAQ. Blok drie (15 minuten) controleert of de API-docs antwoord geven op 'kan ik de data eruit halen', en de laatste 15 minuten zet je de belangrijkste fixes en de eigenaar per fix op een rij. Je hoeft niet elke pagina van boven tot onder te lezen; je hoeft te ontdekken of de taak wordt uitgevoerd. Als de prijspagina geen FAQ heeft, wordt het design sneller goedgekeurd als je dat opmerkt voordat je de vierde prijskolom uitschetst. Als de API-docs zijn geschreven volgens een interne norm in plaats van de norm van de ontwikkelaar, weet je dat voordat je de copywriter instrueert.

In een van de opdrachten bracht de diagnose aan het licht dat de doelkoper doodsbang was voor datamigratie. De FAQ die we voor dat antwoord toevoegden kostte twee uur schrijftijd. Zonder de diagnose zou die angst ons door het ontwerp, door de ontwikkeling en in een post-launch supportoverload hebben gevolgd. De 90-minutenversie is geen fase die voorafgaat aan het project; het is de eerste fase van het project. Het geeft je ook een eerlijke manier om te schatten: je verlaat de sessie met een lijst van wat er bestaat en wat niet, zodat het voorstel dat je schrijft is gebaseerd op bewijs in plaats van gissingen.

'Mijn niet-technische klant heeft geen API-docs nodig'

Gebruik een beslisboom, geen checklist: als het product een publieke API of een integratieverhaal heeft, zijn API-docs een kernpagina; zo niet, sla ze dan bewust over. Het onderzoek naar API-docs is bot: bedrijven zoals Stripe, GitHub en Twilio zetten de norm voor documentatieduidelijkheid omdat hun ontwikkelaars feitelijk de kopers zijn. Als je klant een ontwikkelaarsgerichte integratie heeft, zijn de docs geen gemak voor ontwikkelaars; het is een vertrouwensinstrument dat naast de prijspagina staat. Een niet-technische klant zal er misschien nooit naar kijken, maar de ontwikkelaar die een aankoop evalueert, absoluut wel.

De beslisboom maakt deel uit van het systeem. Wanneer de klant zegt 'we hebben geen ontwikkelaarspubliek', stel dan één vraag: 'moet een deel van jullie onboarding een ontwikkelaar vereisen om het product op een ander systeem aan te sluiten?' Zo ja, dan blijven de docs. Zo nee, dan sla je ze over en steek je de moeite in de FAQ en social proof. Pas dezelfde logica toe op social proof: voor de ene klant is een rij logo's genoeg; voor de andere is een gedetailleerd testimonial met meetbare resultaten vereist. De diagnose vertelt je welke, in plaats van standaard elk logo te gebruiken dat je zou kunnen verzamelen. Die keuze maakt het raamwerk herhaalbaar zonder rigide te zijn. Als je moet uitzoeken wat 'duidelijkheid' in de praktijk betekent, doorloopt deze gids voor API-documentatie de structuur.

'Maar mijn klant wil een functielijst, geen resultaten'

Wanneer de klant zegt dat ze hun functies willen laten zien, vraag hen dan om de gebruikerststaak te noemen die elke functie ontgrendelt. De gangbare aanname is dat de functie-showcase de plek is waar je de verkoop wint. De diagnose suggereert anders: op een typische SaaS-site vindt de uiteindelijke mentale berekening plaats op de prijspagina, en wordt het laatste bezwaar opgelost in de FAQ. De functie-showcase is essentieel, maar de taak is beperkt—het tonen van het moment waarop het product waardevol wordt. Een lange lijst functies met een alinea onder elke functie doet dat niet.

Klanten verzetten zich hiertegen omdat een lijst tastbaar en makkelijk goed te keuren is. Maar een pagina met vijftig functies levert een bezoeker op die scannet, en een bezoeker die je functiepagina scant, heeft zijn aandacht al verplaatst naar de prijstabel. De taak van jouw systeem is om de klant comfortabel te maken met de afweging: je verwijdert geen functies, je verplaatst ze naar waar ze gelezen zullen worden. Een goed geplaatste FAQ die zegt 'we integreren met de tools die je al gebruikt' doet vaak meer werk dan een functiepagina die hetzelfde zegt onder de verkeerde kop. Dit is de nuance die de meeste artikelen overslaan, en het is precies het soort afweging dat een diagnose expliciet kan maken.

De diagnose geeft je ook een verdedigbare reden om tegen scope creep in te gaan. Wanneer een klant vraagt om nog een rij functies aan de homepage toe te voegen, kun je naar de tabel wijzen en zeggen 'de taak van die pagina is om resultaten te tonen, geen functionaliteit te catalogiseren.' Een generieke pagebuilder kan een functiesgrid genereren, maar kan niet beslissen of het grid vervangen moet worden door een video of een FAQ. Die beslissing is het echte product, en het is de reden dat een raamwerk je werk niet commoditiseert.

'We hebben al een intern proces'

Als je bureau een homepagetraject of een checklist voor prijspagina's heeft, draait het bezwaar meestal om het niet willen vervangen. Dat hoeft ook niet. De vijf-takendiagnose is geen vervanging van je creatieve proces; het is een front-end die dat proces voedt. Het probleem met de meeste interne processen is dat ze onzichtbaar zijn. Ze leven in het hoofd van de senior designer. De diagnose externaliseert het proces, zodat een junior teamlid de eerste ronde kan draaien en jij het in minuten kunt beoordelen. Dat is de herhaalbaarheid die je daadwerkelijk nodig hebt bij een bureau met meerdere klanten.

Een zichtbaar proces verandert ook het gesprek met klanten. In plaats van 'we hebben een eigen ontwerpproces', kun je zeggen: 'we draaien een diagnose op de vijf taken die elke SaaS-site moet uitvoeren, en daarna ontwerpen we op basis van de bevindingen.' De eerste zin is een black box die klanten nerveus maakt. De tweede is een duidelijke methode die hen uitnodigt. De diagnose wordt onderdeel van je verkoopverhaal, niet alleen een productietool.

'De klant zegt dat de huidige site prima is'

De diagnose werkt nog steeds als de klant niets meer wil dan een opfrisbeurt. Het geeft je een basislijn. Je scoort de huidige site en laat zien dat een specifieke pagina een specifieke taak niet vervult. Je kunt zeggen: 'Je FAQ-pagina is georganiseerd, maar beantwoordt niet de vraag die je verkoopteam elke week hoort,' en dat is een feitelijke reden om te veranderen, geen esthetische voorkeur. Dit is vaak de zachtste manier om een redesign te starten: je vertelt de klant niet dat hun site lelijk is, je vertelt hen dat één taak niet wordt uitgevoerd.

Dit beschermt je ook tegen het veelvoorkomende falen waarbij een klant erop staat een geliefd homepage-element te behouden dat de conversie schaadt. De diagnose geeft je de woordenschat om te zeggen 'dat element voert geen van de vijf taken uit', en de klant kan het bewijs zien. Het bezwaar is niet langer een kwestie van smaak.

De diagnose is het product

Herhaalbaarheid gaat niet over het inpassen van elke klant in hetzelfde sjabloon. Het gaat over het draaien van een standaardproces dat aan het licht brengt wat uniek is aan elke klant. De vijf-takendiagnose duurt minder dan twee uur, geeft je team een gemeenschappelijke taal en geeft de klant een duidelijke lijst van beslissingen. Het bureau dat een consistente diagnose kan beloven, kan een klant in een week binnenhalen en in een maand opleveren, niet omdat het werk makkelijker is, maar omdat de discovery voorspelbaar is. En wanneer de klant vraagt waarom je zoveel vragen moet stellen, is het antwoord simpel: je doet geen auditie, je stelt een diagnose.

Voor een diepere blik op hoe de functie-showcase en prijspagina samen zouden moeten werken, en waarom de mythes eromheen blijven bestaan, zie deze gids die mythes ontkracht.