Så startar du ett webbprojekt: beslut först, teknik sedan

Ett webbprojekt börjar ofta med meningen: ”Vi behöver en ny webbplats.” Snart handlar samtalet om CMS, mall, färger och lanseringsdatum. Det är fortfarande oklart vad den nya webbplatsen ska förändra.

Det är ett dyrt misstag. Teknik kan mycket snabbt skapa något företaget inte behöver.

Skriv först ner vilket beslut webbplatsen ska stödja

Jag börjar inte med en sidlista. Jag börjar med företagets och besökarens situation. Ska webbplatsen ge kvalificerade förfrågningar, korta ner säljarens förklaringar, sälja utan en person, minska supportarbetet eller flytta varumärket till en annan kategori?

Målet måste leda till ett beslut. ”En modernare presentation” är en önskan. ”Fler relevanta förfrågningar från tillverkningsföretag och färre frågor om enstaka småjobb” gör det redan möjligt att fatta beslut om innehåll, navigering och mätning.

  • Vem är viktig för webbplatsen och i vilken situation kommer de dit?
  • Vad behöver de förstå, jämföra eller göra?
  • Vilka bevis kan företaget ärligt visa upp?
  • Vilket nästa steg passar deras beredskap?
  • Hur känner vi igen en förbättring efter lanseringen?

Innehållskartan kommer före wireframen

Först därefter sätter jag ihop informationsarkitekturen. Huvudnavigeringen ska inte kopiera företagets organisationsstruktur. Den ska hjälpa människor att hitta ett svar och förstå erbjudandet.

För en befintlig webbplats inventerar jag först URL:er, trafik, länkar och faktiskt innehåll. Vissa sidor behåller jag, andra slår jag ihop, omdirigerar eller tar bort. Migreringen får inte bygga på intryck. En oattraktiv sida kan ha bra länkar eller ge relevanta affärer; en välbesökt sida kan locka människor som helt ligger utanför verksamheten.

För SEO spelar tydlig struktur, länkning och innehåll för en verklig målgrupp roll. Google sammanfattar sina frågor om användbarhet i guiden om innehåll för människor först. En praktisk SEO-grund finns också i min artikel SEO för nybörjare.

En prototyp ska verifiera resan, inte imponera på mötet

Först ritar jag upp viktiga användarresor utan detaljerad design. Kan en person förstå vem företaget är till för? Kan de hitta en tjänst, ett bevis, ett pris eller ett sätt att kontakta företaget? Fungerar resan på en smal mobilskärm och med endast tangentbord?

Jag lägger in riktiga rubriker och ungefärliga verkliga textlängder i prototypen. Lorem ipsum döljer ett problem som magiskt dyker upp igen efter att innehållet levererats – vanligtvis fredagen före lanseringen.

Välj teknik efter driften

En statisk webbplats, WordPress, en e-handelsplattform eller en skräddarsydd applikation kan alla vara rätt. Det viktiga är behovet av redigering, integrationer, behörigheter, förändringstakt, säkerhet, budget och vilka personer som ska hantera webbplatsen efter lanseringen.

Specifikationen bör åtminstone innehålla:

  • ägande av domän, konton, källkod och analys;
  • redaktionella roller och publiceringsprocessen;
  • formulär, e-postleverans och koppling till försäljning;
  • omdirigeringar för gamla URL:er och en anpassad felsida;
  • säkerhetskopior, uppdateringar, övervakning och ansvar vid incidenter;
  • en driftbudget, inte bara en produktionsbudget.

Prestanda och tillgänglighet är inte yta som läggs till på slutet

Det är enkelt att lägga till en stor bild, externa typsnitt och tio marknadsföringsskript. Då betalar varje besökare deras kostnad. Core Web Vitals följer laddning av huvudinnehåll, responsivitet och visuell stabilitet; Google underhåller aktuella mätvärden och trösklar i sin dokumentation om Web Vitals.

Därför sätter jag en prestandabudget före designen: mediedimensioner och format, antal teckensnitt, regler för tredjepartsskript och målbeteende på en vanlig mobil. Analysverktyg ska laddas utan att blockera innehållet och bara samla in data som stödjer beslut.

Jag hanterar tillgänglighet samtidigt: semantisk HTML, synligt fokus, tangentbordsanvändning, kontrast, formuläretiketter och respekt för minskad rörelse. Det här är inte en specialversion av en webbplats. Det är en välbyggd webbplats.

Utforma mätningen före lanseringen

Efter lanseringen vill jag inte diskutera vad framgång betyder. Jag listar händelser och deras koppling till beslut: en kvalificerad förfrågan skickad, kalkylator använd, ett viktigt bevis öppnat eller en order slutförd. Alla klick förtjänar inte en händelse.

Teknisk mätning behandlas i guiden om Google Analytics 4. En bredare checklista finns i checklistan för onlineprojekt.

En webbplats är inte färdig vid lanseringen

Under de första veckorna övervakar jag fel, hastighet, indexering, formulär och människors verkliga frågor. Sedan förbättrar jag de platser där webbplatsen inte hjälper till med ett beslut. Inte efter varje kommentar eller ett enda mätvärde, utan utifrån en kombination av data, feedback och affärspåverkan.

En ny webbplats är inte målet. Den är ett nytt operativsystem för företaget. Utan en ägare, budget och regler för förändring börjar den åldras på lanseringsdagen.

Om du redan har en webbplats och behöver hitta svaga punkter, börja med Så snabbar du upp en webbplats. Om du behöver samordna beslut före produktionen, se hur samarbete fungerar.

Behöver du tydlighet i marknadsföringen?

Låt oss först klargöra situationen.

Om ditt företag står inför ett liknande beslut, skicka mig en kort beskrivning av sammanhanget. Sedan ser vi om det är meningsfullt att fortsätta.

Beskriv situationen