SaaS-websitediagnosen, som dit bureau kan genbruge, uden at kunderne kommer til at ligne hinanden

Resumé

Hvor mange gange i dette kvartal har du kørt den præcis samme discovery-samtale – de samme spørgsmål om produktet, kunden, konkurrenten – for to kunder, der insisterede på, at de var fuldstændig forskellige? Du ved allerede, at svarene vil være forskellige, men de opgaver, hver SaaS-website skal udføre, er ikke. Enhver SaaS-produktwebsite er et lille sæt maskiner, der kører de samme opgaver: forklare, hvad produktet gør, vise, hvad det koster, fortælle udviklere, hvordan de integrerer, besvare de indvendinger, der forhindrer et køb, og bevise, at virksomheden er troværdig. En gentagelig diagnose, der reviderer disse fem opgaver, vil overleve kontakt med enhver kunde, fordi opgaverne ikke ændrer sig. Det system, du bygger omkring den, er det, der gør det muligt for dig at gå fra en opgave til den næste uden at starte fra nul. Det tager mindre tid end din nuværende discovery-proces, det giver kunden en klar grund til at stole på dig, og det producerer et leverance, der ikke ser skabelonagtigt ud, fordi spørgsmålene er standard, men svarene er specifikke.

Hvor mange gange i dette kvartal har du kørt den præcis samme discovery-samtale – de samme spørgsmål om produktet, kunden, konkurrenten – for to kunder, der insisterede på, at de var fuldstændig forskellige? Du ved allerede, at svarene vil være forskellige, men de opgaver, hver SaaS-website skal udføre, er ikke. Enhver SaaS-produktwebsite er et lille sæt maskiner, der kører de samme opgaver: forklare, hvad produktet gør, vise, hvad det koster, fortælle udviklere, hvordan de integrerer, besvare de indvendinger, der forhindrer et køb, og bevise, at virksomheden er troværdig. En gentagelig diagnose, der reviderer disse fem opgaver, vil overleve kontakt med enhver kunde, fordi opgaverne ikke ændrer sig. Det system, du bygger omkring den, er det, der gør det muligt for dig at gå fra en opgave til den næste uden at starte fra nul. Det tager mindre tid end din nuværende discovery-proces, det giver kunden en klar grund til at stole på dig, og det producerer et leverance, der ikke ser skabelonagtigt ud, fordi spørgsmålene er standard, men svarene er specifikke.

'Mine kunder er for forskellige til ét system'

Kør den samme fempunkts-diagnose på enhver kunde, før du skriver et eneste ord tekst eller åbner et designværktøj. De forskelle, der gør dine kunder særlige – branche, målgruppe, prismodel – ligger oven på et fælles fundament. En SaaS-tjeneste til lønadministration og et værktøj til planlægning af sociale medier har intet til fælles ud over de fem opgaver, som hver side udfører. Hvis du reviderer for disse opgaver, vil du finde de samme mønstre de samme steder.

Side eller sektion	Hvad din kunde normalt beder om	Hvad der faktisk sker på siden
Featurepræsentation	'Vis alle funktioner, vi har bygget'	Viser det resultat, brugeren får, ikke kun funktionen. Visuelle elementer som skærmbilleder, GIF'er eller videoer bør demonstrere et øjeblik, hvor produktet ændrer den måde, nogen arbejder på.
Priser	'Gør priserne lette at læse'	Køberen er tvunget til at beslutte, hvilken plan der er for dem. Niveauerne skal læses som en progression, der guider et valg, ikke en flad liste af priser.
API-dokumentation	'Vores udviklere finder det i dokumentationen'	Ofte den første test, en udvikler kører, når de vurderer, om produktet kan stole på. Klarhed her er en funktion, ikke en luksus.
FAQ-sektion	'Besvar spørgsmål, så supportopkald falder'	Det sidste, en køber læser, før de klikker på en knap. Det bør håndtere prisindvendinger og grænsetilfælde, ikke kun generiske virksomhedsspørgsmål.
Social proof	'Sæt logoerne op'	Beviset for, at de påstande, der blev fremsat tidligere, er sande. Logoer og testimonials er tillidsindikatorer, ikke dekoration.

En diagnose er ikke en skabelon. Det er et sæt spørgsmål, du stiller til hver side: får dette køberen til at forstå, hvad produktet gør, gør det næste skridt indlysende, besvarer det den indvending, der i øjeblikket blokerer salget? Når du stiller disse spørgsmål med en kunde til stede, ser kunden dig som den person, der forstår deres marked, snarere end som det tiende bureau, der viste en slide-deck. Forskningen i SaaS-websites peger på virksomheder som HubSpot, Slack og Zendesk som eksempler på velorganiserede FAQ-sektioner, og på Stripe, GitHub og Twilio som standarder for dokumentationsklarhed. Ingen af disse virksomheder kom dertil ved at behandle FAQ'en som en bunke supportbilletter. De behandlede den som en konverteringsflade. Det er den holdning, din diagnose skal bringe til hver kunde.

Overvej en kunde, der sælger lagerstyringssoftware, og en anden, der sælger lønsoftware. Diagnosen afdækker ofte de samme tre huller: funktionssiden nævner moduler i stedet for resultater, prissiden retfærdiggør ikke springet mellem planer, og FAQ'en besvarer supportspørgsmål snarere end købstøven. Fordi du har set disse huller i begge, ved du præcis, hvad du skal bede om i designfasen. Kunden ser en proces, der er specifik, ikke generisk. Skriv diagnosen som en et-sides PDF med en score fra 1 til 5 for hver opgave og en note for hver. Del den med kunden før design-kickoff. Dette giver dig et fælles vokabular og gør revisionen til et leverance, du kan opkræve betaling for. Dette er kernen i et gentageligt system, og vi har en separat gennemgang af, hvordan du opbygger det system her.

'Det får vores arbejde til at ligne alle andres'

Standardisér de spørgsmål, du stiller, ikke de svar, du leverer. Diagnosen giver dig et scoringsskema, ikke et layout. Forskningen i SaaS-funktionspræsentationer viser, at de bruger visuelle elementer som skærmbilleder, GIF'er eller videoer – men indholdet i disse visuals er forskelligt for hvert produkt. Lønsrapporteringsfunktionen i et HR-værktøj og stregkodescanningsfunktionen i lagerstyringssoftware vil aldrig komme til at ligne hinanden. Det, der forbliver konstant, er det spørgsmål, du stiller din strategiske tænkning: 'Viser denne side resultatet, eller kun funktionen?'

En læges optagelsesformular gør ikke alle diagnoser ens; den gør lægen pålidelig. Din ramme er optagelsesformularen. Kunden får stadig en skræddersyet hjemmeside, men du får en diagnose, der er gentagelig. Det, der faktisk vil få dit arbejde til at se generisk ud, er manglen på en diagnose – for uden den falder du tilbage på det samme hero-billede, det samme tre-kolonne-funktionslayout, den samme hjemmesidestruktur, du brugte til det sidste projekt bare for at komme hurtigt frem. Diagnosen tvinger dig til at retfærdiggøre strukturen ud fra beviserne, så hver side er strukturelt forskellig der, hvor det er nødvendigt.

I praksis betyder det, at diagnosen måske fortæller dig at starte den ene kundes funktionsside med en video af en importguide og en andens med en GIF af en træk-og-slip-rapportbygger. Sidestrukturen forbliver den samme, men aktiverne, teksten og tempoet er unikke. Kunden ser skræddersyet arbejde; du ser en gentagelig proces. Når du præsenterer diagnosen for en kunde, demonstrerer du, at du ved, hvad enhver SaaS-side skal gøre. Det er et stærkere pitch end 'vi skaber et enestående design.' Designet er konsekvensen af diagnosen, ikke udgangspunktet.

'Vi har ikke tid til at revidere hver side'

Lav den fokuserede 90-minutters version, ikke en fuld revision. De fleste bureauers discovery-processer er allerede en revision, bare en ustruktureret en. Du bruger 45 minutter på et discovery-opkald, der dækker baggrund, konkurrenter og 'hvad vil du have ud af dette,' og derefter bruger du uger på at reagere. Diagnosen vender det om: Du scorer de fem opgaver, lister de vigtigste forbedringer og går videre til design. Det sparer tid, fordi du holder op med at lave arbejdet om efter den første designgennemgang. De billigste rettelser er dem, du laver, før nogen ser pixels.

Her er en konkret 90-minutters opdeling: blok et (30 minutter) gennemgår hjemmesiden og funktionssiden for de fem opgaver. Blok to (30 minutter) skimmer prissiden og FAQ'en. Blok tre (15 minutter) tjekker, om API-dokumentationen besvarer 'kan jeg få dataene ud,' og de sidste 15 minutter lister de vigtigste rettelser og ejeren for hver. Du behøver ikke at læse hver side fra top til bund; du skal finde ud af, om opgaven bliver udført. Hvis prissiden ingen FAQ har, vil designet blive godkendt hurtigere, hvis du opdager det, før du laver en mock-up af den fjerde priskolonne. Hvis API-dokumentationen er skrevet til en intern standard i stedet for udviklerens standard, ved du det, før du briefet tekstforfatteren.

I et engagement afdækkede diagnosen, at målkøberen var bange for datamigrering. Den FAQ, vi tilføjede for at besvare det, kostede to timers skrivning. Uden diagnosen ville den frygt have fulgt os gennem design, gennem udvikling og ind i en support-overbelastning efter lanceringen. 90-minutters versionen er ikke en fase, der går forud for projektet; det er projektets første fase. Den giver dig også en ærlig måde at estimere på: du forlader sessionen med en liste over, hvad der findes, og hvad der ikke gør, så det tilbud, du skriver, er bygget på beviser snarere end gæt.

'Min ikke-tekniske kunde har ikke brug for API-dokumentation'

Brug et beslutningstræ, ikke en tjekliste: hvis produktet har en offentlig API eller en integrationshistorie, er API-dokumentationen en kerneside; hvis ikke, spring den bevidst over. Forskningen i API-dokumentation er klar: virksomheder som Stripe, GitHub og Twilio sætter standarden for dokumentationsklarhed, fordi deres udviklere i realiteten er køberne. Hvis din kunde har en udviklerrettet integration, er dokumentationen ikke en bekvemmelighed for udviklere; det er et tillidsinstrument, der ligger ved siden af prissiden. En ikke-teknisk kunde ser måske aldrig på dem, men den udvikler, der evaluerer et køb, vil helt sikkert gøre det.

Beslutningstræet er en del af systemet. Når kunden siger 'vi har ikke et udviklerpublikum,' så stil ét spørgsmål: 'kræver nogen del af din onboarding, at en udvikler forbinder produktet til et andet system?' Hvis ja, bliver dokumentationen. Hvis nej, springer du over og lægger indsatsen i FAQ og social proof. Anvend samme logik på social proof: for én kunde er en række logoer nok; for en anden kræves et detaljeret testimonial med målbare resultater. Diagnosen fortæller dig hvilken, i stedet for at du som standard bruger alle de logoer, du kan samle. Det valg er det, der gør rammen gentagelig uden at være rigid. Hvis du har brug for at finde ud af, hvad 'klarhed' betyder i praksis, gennemgår denne guide til API-dokumentation strukturen.

'Men min kunde vil have en funktionsliste, ikke resultater'

Når kunden siger, at de vil vise deres funktioner frem, så bed dem om at nævne den brugertopgave, hver funktion låser op for. Den almindelige antagelse er, at featurepræsentationen er der, hvor du vinder salget. Diagnosen antyder noget andet: på en typisk SaaS-website er prissiden, hvor den endelige mentale regning finder sted, og FAQ'en er, hvor den sidste indvending bliver løst. Featurepræsentationen er essentiel, men dens opgave er snæver – at vise det øjeblik, hvor produktet bliver værdifuldt. En lang liste af funktioner med et afsnit under hver gør ikke det.

Kunder modstår dette, fordi en liste føles håndgribelig og nem at godkende. Men en side med halvtreds funktioner skaber en besøgende, der skimter, og en besøgende, der skimter din funktionsside, har allerede flyttet deres opmærksomhed til pristabellen. Dit systems opgave er at få kunden til at være tryg ved afvejningen: du fjerner ikke funktioner, du flytter dem til, hvor de vil blive læst. En velplaceret FAQ, der siger 'vi integrerer med de værktøjer, du allerede bruger,' gør ofte mere arbejde end en funktionsside, der siger det samme under den forkerte overskrift. Det er den nuance, de fleste artikler springer over, og det er netop den slags afvejning, en diagnose kan gøre eksplicit.

Diagnosen giver dig også en forsvarlig grund til at skubbe tilbage mod scope creep. Når en kunde beder om at tilføje endnu en række funktioner til hjemmesiden, kan du pege på tabellen og sige 'den sides opgave er at vise resultater, ikke at katalogisere funktionalitet.' En generisk sidebygger kan generere et funktionsgrid, men den kan ikke beslutte, om gitteret skal erstattes af en video eller en FAQ. Den beslutning er det rigtige produkt, og det er grunden til, at en ramme ikke kommodificerer dit arbejde.

'Vi har allerede en intern proces'

Hvis dit bureau har en proces for hjemmesider eller en tjekliste til prissider, handler indvendingen normalt om ikke at ville erstatte den. Det behøver du ikke. Fem-opgaver-diagnosen er ikke en erstatning for din kreative proces; det er en front-end, der fodrer den. Problemet med de fleste interne processer er, at de er usynlige. De lever i senior designerens hoved. Diagnosen eksternaliserer processen, så et juniorteammedlem kan køre den første gennemgang, og du kan gennemgå det på få minutter. Det er den gentagelighed, du faktisk har brug for på et bureau med flere kunder.

En synlig proces ændrer også samtalen med kunder. I stedet for 'vi har en proprietær designproces' kan du sige 'vi kører en diagnose mod de fem opgaver, enhver SaaS-side skal udføre, og derefter designer vi ud fra resultaterne.' Den første sætning er en sort boks, der gør kunderne nervøse. Den anden er en klar metode, der inviterer dem ind. Diagnosen bliver en del af din salgshistorie, ikke bare et produktionsværktøj.

'Kunden siger, at den nuværende hjemmeside er fin'

Diagnosen virker stadig, hvis kunden ikke ønsker mere end en opdatering. Den giver dig en baseline. Du scorer den nuværende hjemmeside og viser, at en bestemt side fejler en bestemt opgave. Du kan sige: 'Din FAQ-side er organiseret, men den besvarer ikke det spørgsmål, dit salgsteam hører hver uge,' og det er en faktabaseret grund til at ændre, ikke en æstetisk præference. Dette er ofte den skånsomste måde at starte en redesign på: du fortæller ikke kunden, at deres hjemmeside er grim, du fortæller dem, at én opgave ikke bliver udført.

Dette beskytter dig også mod den almindelige fejl, hvor en kunde insisterer på at beholde et elsket hjemmesideelement, der skader konverteringen. Diagnosen giver dig ordforrådet til at sige 'det element udfører ingen af de fem opgaver,' og kunden kan se beviserne. Indvendingen er ikke længere et spørgsmål om smag.

Diagnosen er produktet

Gentagelighed handler ikke om at presse hver kunde ind i den samme skabelon. Det handler om at køre en standardproces, der bringer det unikke ved hver kunde frem. Fem-opgaver-diagnosen tager mindre end to timer, giver dit team et fælles sprog og giver kunden en klar liste over beslutninger. Det bureau, der kan love en konsistent diagnose, kan lande en kunde på en uge og levere på en måned, ikke fordi arbejdet er lettere, men fordi discovery er forudsigelig. Og når kunden spørger, hvorfor du har brug for at stille så mange spørgsmål, er svaret enkelt: du er ikke til audition, du diagnosticerer.

For et dybere kig på, hvordan featurepræsentationen og prissiden bør arbejde sammen, og hvorfor myterne omkring dem fortsat består, se denne myteknusende guide.