Et nettprosjekt begynner ofte med setningen: «Vi trenger et nytt nettsted.» Snart dreier samtalen over på CMS, mal, farger og lanseringsdato. Det er fortsatt uklart hva det nye nettstedet skal endre.
Det er en kostbar feil. Teknologi kan svært raskt produsere noe selskapet ikke trenger.
Skriv først ned hvilken beslutning nettstedet skal støtte
Jeg begynner ikke med en sideliste. Jeg begynner med situasjonen til selskapet og besøkende. Skal nettstedet skaffe kvalifiserte henvendelser, korte ned salgsforklaringer, selge uten en person, redusere supportarbeidet eller flytte merkevaren inn i en annen kategori?
Målet må lede til en beslutning. «En mer moderne presentasjon» er et ønske. «Flere relevante henvendelser fra produksjonsbedrifter og færre spørsmål om enkeltstående småjobber» gjør det allerede mulig å ta beslutninger om innhold, navigasjon og måling.
- Hvem er viktig for nettstedet, og i hvilken situasjon kommer de dit?
- Hva trenger de å forstå, sammenligne eller gjøre?
- Hvilke bevis kan selskapet vise frem på en ærlig måte?
- Hvilket neste steg passer til hvor klare de er?
- Hvordan vil vi se at det har blitt bedre etter lansering?
Innholdskartet kommer før wireframen
Først da setter jeg sammen informasjonsarkitekturen. Hovednavigasjonen bør ikke kopiere selskapets organisasjonsstruktur. Den bør hjelpe folk med å finne et svar og forstå tilbudet.
For et eksisterende nettsted kartlegger jeg først URL-er, trafikk, lenker og det faktiske innholdet. Noen sider beholder jeg, andre slår jeg sammen, videresender eller fjerner. En migrering må ikke baseres på inntrykk. En lite tiltalende side kan ha gode lenker eller skaffe relevant forretning; en svært besøkt side kan tiltrekke seg mennesker som ikke har noe med virksomheten å gjøre.
For SEO er tydelig struktur, lenking og innhold for en reell målgruppe viktig. Google oppsummerer spørsmålene sine om nytte i veiledningen om innhold laget for mennesker. Et praktisk SEO-grunnlag finner du også i artikkelen min SEO for nybegynnere.
En prototype skal kontrollere brukerreisen, ikke imponere møtet
Først tegner jeg de viktigste brukerreisene uten detaljert design. Kan en person forstå hvem selskapet er til for? Kan de finne en tjeneste, dokumentasjon, pris eller kontaktmåte? Fungerer reisen på en smal mobilskjerm og med bare tastatur?
Jeg legger inn ekte overskrifter og omtrent riktige tekstlengder i prototypen. Lorem ipsum skjuler et problem som på magisk vis dukker opp igjen etter at innholdet er levert – vanligvis fredagen før lansering.
Velg teknologi ut fra driften
Et statisk nettsted, WordPress, en e-handelsplattform eller en spesialutviklet applikasjon kan alle være riktige valg. Det som betyr noe, er behovet for redigering, integrasjoner, tillatelser, endringstakt, sikkerhet, budsjett og menneskene som skal administrere nettstedet etter lansering.
Kravspesifikasjonen bør minst inneholde:
- eierskap til domenet, kontoene, kildekoden og analyseverktøyene;
- redaksjonelle roller og publiseringsprosessen;
- skjemaer, e-postlevering og tilkobling til salg;
- videresendinger for gamle URL-er og en egendefinert feilside;
- sikkerhetskopier, oppdateringer, overvåking og ansvar for hendelser;
- et driftsbudsjett, ikke bare et produksjonsbudsjett.
Ytelse og tilgjengelighet er ikke pynt som legges til på slutten
Det er enkelt å legge til et stort bilde, eksterne skrifter og ti markedsføringsskript. Da betaler hver besøkende kostnaden. Core Web Vitals måler innlasting av hovedinnhold, responsivitet og visuell stabilitet; Google vedlikeholder aktuelle målinger og terskler i dokumentasjonen om Web Vitals.
Derfor fastsetter jeg et ytelsesbudsjett før design: mediedimensjoner og -formater, antall skriftvarianter, regler for tredjepartsskript og ønsket atferd på en vanlig mobil. Analyseverktøy bør lastes inn uten å blokkere innholdet og bare samle inn data som støtter beslutninger.
Jeg tar også opp tilgjengelighet samtidig: semantisk HTML, synlig fokus, tastaturbetjening, kontrast, skjemamerking og respekt for redusert bevegelse. Dette er ikke en spesialversjon av et nettsted. Det er et godt bygget nettsted.
Planlegg målingen før lansering
Etter lansering vil jeg ikke diskutere hva suksess betyr. Jeg lister opp hendelser og forbindelsen deres til beslutninger: en kvalifisert henvendelse sendt inn, kalkulator brukt, viktig dokumentasjon åpnet eller bestilling fullført. Ikke hvert klikk fortjener en hendelse.
Teknisk måling er dekket i veiledningen om Google Analytics 4. En bredere sjekkliste finner du i sjekklisten for nettprosjekter.
Et nettsted er ikke ferdig ved lansering
De første ukene overvåker jeg feil, hastighet, indeksering, skjemaer og de faktiske spørsmålene fra folk. Deretter forbedrer jeg steder der nettstedet ikke hjelper en beslutning. Ikke etter hver kommentar eller én enkelt måling, men basert på en kombinasjon av data, tilbakemeldinger og forretningspåvirkning.
Et nytt nettsted er ikke målet. Det er et nytt operativsystem for selskapet. Uten en eier, et budsjett og regler for endringer begynner det å eldes på lanseringsdagen.
Hvis du allerede har et nettsted og trenger å finne svake punkter, kan du begynne med Slik gjør du et nettsted raskere. Hvis du trenger å samordne beslutningene før produksjon, kan du se hvordan samarbeid fungerer.