SaaS-nettsteddiagnosen som byrået ditt kan gjenbruke uten at kundene ser like ut

Sammendrag

Hvor mange ganger dette kvartalet har du kjørt nøyaktig samme oppdagelsessamtale – samme spørsmål om produktet, kunden, konkurrenten – for to kunder som insisterte på at de var helt forskjellige? Du vet allerede at svarene vil være forskjellige, men oppgavene hver SaaS-side skal utføre er ikke det. Ethvert SaaS-produktnettsted er et lite sett med maskiner som utfører de samme oppgavene: forklare hva produktet gjør, vise hva det koster, fortelle utviklere hvordan de integrerer, svare på innvendingene som stopper et kjøp, og bevise at selskapet er troverdig. En repeterbar diagnose som reviderer disse fem oppgavene, vil overleve kontakt med enhver kunde, fordi oppgavene ikke endres. Systemet du bygger rundt det, er det som lar deg gå fra ett oppdrag til det neste uten å starte fra null. Det tar kortere tid enn din nåværende oppdagelsesprosess, det gir kunden en klar grunn til å stole på deg, og det produserer en leveranse som ikke ser templatisk ut fordi spørsmålene er standard, men svarene er spesifikke.

Hvor mange ganger dette kvartalet har du kjørt nøyaktig samme oppdagelsessamtale – samme spørsmål om produktet, kunden, konkurrenten – for to kunder som insisterte på at de var helt forskjellige? Du vet allerede at svarene vil være forskjellige, men oppgavene hver SaaS-side skal utføre er ikke det. Ethvert SaaS-produktnettsted er et lite sett med maskiner som utfører de samme oppgavene: forklare hva produktet gjør, vise hva det koster, fortelle utviklere hvordan de integrerer, svare på innvendingene som stopper et kjøp, og bevise at selskapet er troverdig. En repeterbar diagnose som reviderer disse fem oppgavene, vil overleve kontakt med enhver kunde, fordi oppgavene ikke endres. Systemet du bygger rundt det, er det som lar deg gå fra ett oppdrag til det neste uten å starte fra null. Det tar kortere tid enn din nåværende oppdagelsesprosess, det gir kunden en klar grunn til å stole på deg, og det produserer en leveranse som ikke ser templatisk ut fordi spørsmålene er standard, men svarene er spesifikke.

'Kundene mine er for forskjellige for ett system'

Kjør den samme fempunkters-diagnosen på hver kunde før du skriver et ord med tekst eller åpner et designverktøy. Forskjellene som gjør kundene dine spesielle – bransje, målgruppe, prismodell – ligger på toppen av et felles fundament. Et lønns-SaaS og et verktøy for sosiale medier har ingenting til felles bortsett fra de fem oppgavene hver side utfører. Hvis du ser etter disse oppgavene, vil du finne de samme mønstrene på de samme stedene.

Side eller seksjon	Hva kunden din vanligvis ber om	Hva som faktisk skjer på siden
Funksjonsvisning	'Vis alle funksjonene vi har bygget'	Viser resultatet brukeren får, ikke bare funksjonen. Visuelle elementer som skjermbilder, GIF-er eller videoer bør demonstrere et øyeblikk der produktet endrer måten noen jobber på.
Prising	'Gjør prisene lette å lese'	Kjøperen blir tvunget til å bestemme hvilken plan som passer for dem. Nivåene må leses som en progresjon som veileder et valg, ikke en flat liste med priser.
API-dokumentasjon	'Utviklerne våre finner det i dokumentasjonen'	Ofte den første testen en utvikler kjører når de vurderer om produktet kan stole på. Tydelighet her er en funksjon, ikke en luksus.
FAQ-seksjon	'Svar på spørsmål så støttehenvendelsene synker'	Det siste en kjøper leser før de klikker på en knapp. Den bør håndtere prisinnvendinger og kantsaker, ikke bare generiske selskapsspørsmål.
Sosiale bevis	'Legg logoene opp'	Beviset på at påstandene som er gjort tidligere er sanne. Logoer og attester er tillitsindikatorer, ikke dekorasjon.

En diagnose er ikke en mal. Det er et sett med spørsmål du stiller til hver side: gjør dette at kjøperen forstår hva produktet gjør, gjør det neste steg åpenbart, svarer det på innvendingen som for øyeblikket blokkerer salget? Når du stiller disse spørsmålene med en kunde til stede, ser kunden deg som personen som forstår markedet deres, i stedet for som det tiende byrået som viste en lysbildepresentasjon. Forskningen på SaaS-nettsteder peker på selskaper som HubSpot, Slack og Zendesk som eksempler på godt organiserte FAQ-seksjoner, og på Stripe, GitHub og Twilio som standarder for dokumentasjonstydelighet. Ingen av disse selskapene kom dit ved å behandle FAQ som en haug med støttebilletter. De behandlet den som en konverteringsflate. Det er den holdningen diagnosen din må ta med til hver kunde.

Tenk på en kunde som selger lagerstyringsprogramvare og en annen som selger lønnssystemer. Diagnosen avdekker ofte de samme tre gapene: funksjonssiden nevner moduler i stedet for resultater, prissiden rettferdiggjør ikke hoppet mellom planene, og FAQ-en svarer på støttespørsmål i stedet for kjøpsnøling. Fordi du har sett disse gapene i begge, vet du nøyaktig hva du skal be om i designfasen. Kunden ser en prosess som er spesifikk, ikke generisk. Skriv diagnosen som en én-sides PDF med en poengsum fra 1 til 5 for hver oppgave, og en merknad for hver. Del den med kunden før designstart. Dette gir dere et felles vokabular og gjør gjennomgangen til en leveranse du kan fakturere for. Dette er kjernen i et repeterbart system, og vi har en egen gjennomgang av hvordan du setter opp det systemet her.

'Det vil få arbeidet vårt til å se ut som alle andres'

Standardiser spørsmålene du stiller, ikke svarene du leverer. Diagnosen gir deg en vurderingsmal, ikke en layout. Forskningen på SaaS-funksjonsvisninger viser at de bruker visuelle elementer som skjermbilder, GIF-er eller videoer – men innholdet i disse visuelle elementene er forskjellig for hvert produkt. Lønnsrapporteringsfunksjonen i et HR-verktøy og strekkodeskanningen i lagerstyringsprogramvare vil aldri se like ut. Det som forblir konstant, er spørsmålet du stiller til din strategiske tanke: 'Viser denne siden resultatet, eller bare funksjonen?'

En lege sitt inntaksskjema gjør ikke alle diagnoser like; det gjør legen pålitelig. Ditt rammeverk er inntaksskjemaet. Kunden får fortsatt en tilpasset nettside, men du får en diagnose som er repeterbar. Det som faktisk vil få arbeidet ditt til å se generisk ut, er mangelen på en diagnose – for uten den faller du tilbake på det samme hero-bildet, samme tre-kolonne-funksjonslayout, samme hjemmesidestruktur som du brukte for det forrige prosjektet bare for å komme raskt i mål. Diagnosen tvinger deg til å rettferdiggjøre strukturen ut fra bevisene, slik at hver side er strukturelt forskjellig der den trenger det.

I praksis betyr dette at diagnosen kan fortelle deg å starte en kundes funksjonsside med en video av en importveiviser og en annens med en GIF av en dra-og-slipp-rapportbygger. Sidestrukturen forblir den samme, men eiendelene, teksten og tempoet er unike. Kunden ser tilpasset arbeid; du ser en repeterbar prosess. Når du presenterer diagnosen for en kunde, viser du at du vet hva enhver SaaS-side må gjøre. Det er en sterkere pitch enn 'vi lager en unik design.' Designet er en konsekvens av diagnosen, ikke utgangspunktet.

'Vi har ikke tid til å gjennomgå hver side'

Gjør den fokuserte 90-minuttersversjonen, ikke en full gjennomgang. De fleste byråers oppdagelsesprosesser er allerede en gjennomgang, bare en ustrukturert en. Du bruker førtifem minutter på en oppdagelsessamtale som dekker bakgrunn, konkurrenter og 'hva ønsker du å få ut av dette,' og deretter bruker du uker på å reagere. Diagnosen snur det: du scorer de fem oppgavene, lister opp de mest effektive rettelsene og går videre til design. Det sparer tid fordi du slutter å gjøre om arbeid etter den første designgjennomgangen. De billigste rettelsene er de du gjør før noen ser pixler.

Her er en konkret 90-minutters inndeling: blokk én (30 minutter) gjennomgår hjemmesiden og funksjonssiden for de fem oppgavene. Blokk to (30 minutter) skummer prissiden og FAQ. Blokk tre (15 minutter) sjekker om API-dokumentasjonen svarer på 'kan jeg få ut dataene,' og de siste 15 minuttene lister opp de viktigste rettelsene og eieren for hver. Du trenger ikke å lese hver side fra topp til bunn; du trenger å finne ut om oppgaven blir utført. Hvis prissiden ikke har noen FAQ, vil designet bli godkjent raskere hvis du oppdager det før du lager en mock-up av den fjerde priskolonnen. Hvis API-dokumentasjonen er skrevet etter en intern standard i stedet for utviklerens standard, vet du det før du briefetekstforfatteren.

I et oppdrag avdekket diagnosen at målgruppen var livredd for datamigrering. FAQ-en vi la til for det svaret kostet to timer med skriving. Uten diagnosen ville den frykten ha fulgt oss gjennom design, gjennom utvikling og inn i en støtteoverbelastning etter lansering. 90-minuttersversjonen er ikke en fase som kommer før prosjektet; det er den første fasen av prosjektet. Den gir deg også en ærlig måte å estimere på: du forlater økten med en liste over hva som finnes og hva som ikke finnes, så forslaget du skriver er bygget på bevis i stedet for gjetninger.

'Den ikke-tekniske kunden min trenger ikke API-dokumentasjon'

Bruk et beslutningstre, ikke en sjekkliste: hvis produktet har et offentlig API eller en integrasjonshistorie, er API-dokumentasjon en kjerne side; hvis ikke, hopper du bevisst over den. Forskningen på API-dokumentasjon er tydelig: selskaper som Stripe, GitHub og Twilio setter standarden for dokumentasjonstydelighet fordi utviklerne deres i praksis er kjøperne. Hvis kunden din har en utviklerrettet integrasjon, er ikke dokumentasjonen en bekvemmelighet for utviklere; det er en tillitsenhet som sitter ved siden av prissiden. En ikke-teknisk kunde ser kanskje aldri på den, men utvikleren som vurderer et kjøp, vil definitivt gjøre det.

Beslutningstreet er en del av systemet. Når kunden sier 'vi har ikke et utviklerpublikum,' spør ett spørsmål: 'krever noen del av onboarding at en utvikler kobler produktet til et annet system?' Hvis ja, blir dokumentasjonen værende. Hvis nei, hopper du over den og legger innsatsen i FAQ og sosiale bevis. Bruk samme logikk på sosiale bevis: for én kunde er en rekke logoer nok; for en annen kreves en detaljert attest med målbare resultater. Diagnosen forteller deg hvilken, i stedet for å bruke alle logoene du kan samle inn. Det valget er det som gjør rammeverket repeterbart uten å være rigid. Hvis du trenger å finne ut hva 'tydelighet' betyr i praksis, går denne guiden til API-dokumentasjon gjennom strukturen.

'Men kunden min vil ha en funksjonsliste, ikke resultater'

Når kunden sier de vil vise frem funksjonene sine, be dem navngi brukeroppgaven hver funksjon låser opp. Den vanlige antakelsen er at funksjonsvisningen er der du vinner salget. Diagnosen antyder noe annet: på et typisk SaaS-nettsted er prissiden der den endelige mentale regnestykket skjer, og FAQ-en er der den siste innvendingen løses. Funksjonsvisningen er viktig, men jobben er smal – å vise øyeblikket produktet blir verdifullt. En lang liste med funksjoner med et avsnitt under hver enkelt gjør ikke det.

Kunder motstår dette fordi en liste føles håndgripelig og lett å godkjenne. Men en side med femti funksjoner gir en besøkende som skummer, og en besøkende som skummer funksjonssiden din, har allerede flyttet oppmerksomheten til pristabellen. Systemets jobb er å få kunden komfortabel med avveiningen: du fjerner ikke funksjoner, du flytter dem dit de vil bli lest. En godt plassert FAQ som sier 'vi integrerer med verktøyene du allerede bruker' gjør ofte mer arbeid enn en funksjonsside som sier det samme under feil overskrift. Dette er nyansen de fleste artikler hopper over, og det er nettopp den typen avveining en diagnose kan gjøre eksplisitt.

Diagnosen gir deg også en forsvarlig grunn til å motsette seg omfangssprekk. Når en kunde ber om å legge til en ny rad med funksjoner på hjemmesiden, kan du peke på tabellen og si 'den sidens jobb er å vise resultater, ikke katalogisere funksjonalitet.' En generisk sidebygger kan generere et funksjonsgrid, men den kan ikke bestemme om rutenettet skal erstattes av en video eller en FAQ. Den beslutningen er det ekte produktet, og det er grunnen til at et rammeverk ikke gjør arbeidet ditt til en vare.

'Vi har allerede en intern prosess'

Hvis byrået ditt har en hjemmesideprosess eller en prisside-sjekkliste, handler innvendingen vanligvis om at du ikke vil erstatte den. Det trenger du ikke. Femoppgave-diagnosen er ikke en erstatning for den kreative prosessen din; det er et front-end som mater den. Problemet med de fleste interne prosesser er at de er usynlige. De lever i seniordesignerens hode. Diagnosen eksternaliserer prosessen slik at et juniorteammedlem kan kjøre den første gjennomgangen, og du kan vurdere den på få minutter. Det er repeterbarheten du faktisk trenger i et byrå med flere kunder.

En synlig prosess endrer også samtalen med kunder. I stedet for 'vi har en proprietær designprosess,' kan du si 'vi kjører en diagnose mot de fem oppgavene hver SaaS-side må utføre, og så designer vi rundt funnene.' Den første setningen er en svart boks som gjør kunder nervøse. Den andre er en tydelig metode som inviterer dem inn. Diagnosen blir en del av salgshistorien din, ikke bare et produksjonsverktøy.

'Kunden sier at den nåværende nettsiden er fin'

Diagnosen fungerer fortsatt hvis kunden ikke ønsker noe mer enn en oppfriskning. Den gir deg en baseline. Du scorer den nåværende nettsiden og viser at en bestemt side svikter en bestemt oppgave. Du kan si: 'FAQ-siden din er organisert, men den svarer ikke på spørsmålet salgsteamet ditt hører hver uke,' og det er en faktabasert grunn til å endre, ikke en estetisk preferanse. Dette er ofte den skånsomste måten å starte en redesign på: du forteller ikke kunden at nettsiden deres er stygg, du forteller dem at én oppgave ikke blir utført.

Dette beskytter deg også mot den vanlige feilen der en kunde insisterer på å beholde et kjær hjemmesideelement som skader konvertering. Diagnosen gir deg vokabularet til å si 'det elementet utfører ingen av de fem oppgavene,' og kunden kan se bevisene. Innvendingen er ikke lenger et spørsmål om smak.

Diagnosen er produktet

Repeterbarhet handler ikke om å presse hver kunde inn i den samme malen. Det handler om å kjøre en standard prosess som overflater det som er unikt med hver kunde. Femoppgave-diagnosen tar under to timer, gir teamet ditt et felles språk og gir kunden en tydelig liste over beslutninger. Byrået som kan love en konsistent diagnose, kan lande en kunde på en uke og levere på en måned, ikke fordi arbeidet er enklere, men fordi oppdagelsen er forutsigbar. Og når kunden spør hvorfor du trenger å stille så mange spørsmål, er svaret enkelt: du er ikke på audition, du diagnostiserer.

For en dypere titt på hvordan funksjonsvisningen og prissiden bør fungere sammen, og hvorfor mytene rundt dem vedvarer, se denne myteknuser-guiden.