Spring til indhold
Media Access

Webudvikling

Webudvikling for virksomheder: fra behov til en hjemmeside, der fungerer

Skal virksomheden have en ny hjemmeside, webshop eller webapp? Brug en konkret kravspecifikation til at vælge løsning og kontrollere leverancen ved lancering.

Af Media AccessUdgivet 5 min. læsetid

En ny hjemmeside til virksomheden bør udføre en konkret opgave: forklare tilbuddet, skaffe relevante henvendelser, sælge produkter eller lade kunden løse en opgave selv. Når opgaven er tydelig, bliver det nemmere at vurdere både teknologi, omfang og pris.

Denne guide handler om køb af webudvikling. Den hjælper dig med at skrive et godt grundlag for tilbud og kontrollere, at leverancen fungerer i praksis, uanset om du har brug for en virksomhedshjemmeside, en netbutik eller en webapplikation.

Hjemmeside, netbutik eller webapp?

Start med det vigtigste, brugeren skal gøre. En hjemmeside kan være den rigtige løsning, når kunden har brug for information og derefter tager kontakt. En netbutik skal også håndtere købet og opfølgningen omkring ordren. En webapp bliver relevant, når brugeren skal arbejde med data, processer eller personlige oplysninger over tid.

Grænserne kan overlappe. En virksomhedshjemmeside kan have booking, og en netbutik kan have en kundeportal. Spørg derfor, hvad der skal fungere ved første lancering. Ekstra funktioner bør begrundes med et konkret behov og en person, der skal bruge dem.

Et udgangspunkt for at afgrænse projektet
LøsningTypisk hovedopgaveAfklar tidligt
VirksomhedshjemmesideForklare tilbuddet og skabe kontakt.Indhold, redigering, kontaktflow og synlighed.
NetbutikLade kunden vælge, bestille og betale.Produktdata, fragt, betaling, ordre og kundeservice.
Webapp eller portalLade kunden udføre en opgave over tid.Login, roller, datakilder, historik og integrationer.

Beskriv tre opgaver, siden skal løse

Vælg tre vigtige opgaver, og skriv dem som korte situationer. For en servicevirksomhed kan de være: En ny kunde skal finde ud af, om I dækker området, en indkøber skal forstå, hvad en serviceaftale indeholder, og en eksisterende kunde skal bede om hjælp.

Gennemgå den nuværende løsning med disse opgaver. Notér, hvor der mangler information, hvor kunden skal lede, og hvor medarbejdere skal udføre dobbeltarbejde. Det giver et bedre grundlag for webdesign og udvikling end en liste over websites, I synes ser flotte ud.

Beskriv også et vellykket slutpunkt. »Formularen virker« er uklart. »En kunde kan sende en forespørgsel fra mobil, får en bekræftelse, og forespørgslen vises hos den rette ansvarlige« kan demonstreres. På den måde knytter I det visuelle arbejde til en faktisk leverance.

Skriv en kravspecifikation, der kan bruges

Del kravene op i skal være med ved lancering, bør være med og kan vente. Hvert krav bør have en ansvarlig og en enkel måde at godkende det på. Bed leverandøren forklare forudsætninger, afhængigheder og hvad der ligger uden for tilbuddet.

Tabellen viser forslag til krav. Tilpas detaljerne til virksomheden, især roller, integrationer og hvad I selv har brug for at kunne ændre.

Eksempel på krav, der kan kontrolleres
OmrådeKravSådan kan det godkendes
IndholdRedaktøren kan opdatere servicetekst og kontaktoplysninger.En medarbejder udfører ændringen efter oplæring.
KontaktIndsendte forespørgsler kommer til det rette team.En markeret test spores fra formular til modtager.
MobilVigtige opgaver fungerer på små skærme.Opgaverne gennemføres på aftalte telefoner og browsere.
IntegrationAftalte felter overføres til det rette system.Test med både komplet og mangelfuld indsendelse.
OverdragelseAdgange, dokumentation og driftsansvar er afklaret.Virksomheden modtager og kontrollerer en overdragelsesliste.

Giv indholdet en ejer, før designet er færdigt

En ny løsning kræver tekst, billeder og afklarede oplysninger om ydelserne. Fordel ansvaret for hver side. Aftal, hvem der kan bekræfte priser, leveringsområder, produktbeskrivelser og eventuelle kundereferencer. Indhold, der er »på vej«, bør have en aftalt leveringsdato.

Brug en faktisk serviceside i designarbejdet. Den viser, om overskrifter, forklaringer, billeder og handlingsknapper fungerer sammen. Et pænt udkast med korte eksempeltekster kan skjule problemer, som først dukker op, når den virkelige beskrivelse skal ind.

For netbutikker skal produktdata have samme opmærksomhed. Aftal, hvor navne, varianter, lagerstatus og billeder kommer fra, og hvem der retter fejl. Et nyt design løser ikke uklare produktdata eller uklare ansvarsforhold.

Aftal kvalitet i brug, ikke kun en pointscore

Bed om test af de vigtigste brugeropgaver på mobil og med tastatur. Medtag tydelige feltetiketter, læsbar tekst og forståelige fejlmeddelelser. W3C anbefaler, at tilgængelighed indgår gennem hele produktionsprocessen og vurderes tidligt og regelmæssigt. Gør derfor dette til en del af arbejdet fra start.

Ydelsen bør også vurderes med reelt indhold. Googles Core Web Vitals beskriver indlæsning af hovedindhold, respons på handlinger og visuel stabilitet. Brug målinger til at finde problemer, og kombinér dem med praktiske opgavetests. En hurtig forside hjælper kun lidt, hvis kontaktformen er svær at bruge.

Bed om, at testgrundlaget beskrives: hvilke sider, enheder og situationer der blev kontrolleret, hvilke fejl der er rettet, og hvad der eventuelt stadig mangler.

Planlæg lancering og ejerskab før den sidste uge

Ved udskiftning af en eksisterende hjemmeside skal vigtige webadresser kortlægges. Hvis adresserne ændres, anbefaler Google en plan, der kobler gamle sider til relevante nye sider og videresender trafikken. Inkludér dette i omfanget sammen med kontrol af interne links og vigtige formularer.

Aftal, hvem der ejer domænet, publiceringsløsningen og de nødvendige konti. Virksomheden bør vide, hvem der overvåger driften, tager sikkerhedskopier, hvor det er relevant, håndterer fejl og gennemfører opdateringer. Beskriv også, hvordan I bestiller mindre ændringer efter lancering.

Afsæt et særskilt tidspunkt til overdragelse. Den, der skal redigere siden, bør prøve opgaverne selv. Først når indhold, kontaktflow, måling og ansvar fungerer sammen, har I et godt grundlag for at bruge hjemmesiden i markedsføringen.

Spørgsmål og svar

Skal vi vælge teknologi, før vi kontakter et udviklingsbureau?

Normalt er det bedre først at beskrive brugeropgaver, redigeringsbehov og integrationer. Har I interne systemkrav eller kompetencer, som skal bruges videre, bør det naturligvis stå i behovsbeskrivelsen.

Har en lille virksomhed brug for en skræddersyet hjemmeside?

Ikke nødvendigvis. Afklar, hvilke krav en standardløsning dækker, og hvilke behov der faktisk kræver tilpasning. Sammenlign også redigering, drift, videreudvikling og muligheden for at flytte senere.

Hvad bør vi have klar, før vi beder om tilbud på webudvikling?

Beskriv hovedmålet, de vigtigste brugeropgaver, omtrentlige sidetyper, indholdsansvar, integrationer og ønsket lancering. Vedlæg linket til den nuværende hjemmeside og hvad I vil forbedre.

Kilder og videre læsning

Fra indsigt til noget, der virker.

Tag en snak med os om, hvad din virksomhed har brug for, og hvor det er fornuftigt at starte.

Drøft virksomhedens nye hjemmeside

Læs videre