Hva som skjer mellom beslutningen og publiseringen: stegene i et nettsideprosjekt

Avtalen er signert, forskuddsbetalingen er gjort, og så blir det stille. Bedriften venter på at nettstedet skal dukke opp, utvikleren venter på tekster og fotografier, og ingen av dem tenker at de venter gjennom nøyaktig den samme uken, så etter en måned er begge parter misfornøyde, og ingen av dem har gjort noe galt; det var bare det at ingen hadde skrevet ned hvem som leverer hva, og innen hvilken dato.

Denne artikkelen handler om det som skjer mellom beslutningen og publiseringen, og først og fremst om arbeidsfordelingen mellom de to partene, for det er den som avgjør fristen langt oftere enn utviklingshastigheten eller den valgte teknologien. Om hvilke feil bestillere gjør, har vi skrevet separat i artikkelen om ti feil når du skal bestille nettside, og her gjentar vi dem ikke. Her er det heller verken priser eller en sammenligning mellom å gjøre det selv og å bestille, for begge er temaer for andre artikler, og det dreier seg bare om rekkefølgen og om hva som skal forberedes i hvert steg.

Kartlegging er ikke starten på byggingen

Nesten hvert utviklingsløp begynner med en fase som kalles kartlegging eller undersøkelse, og det er nettopp denne fasen som oftest blir misforstått, fordi bestilleren oppfatter den som en formalitet før det egentlige arbeidet. Nielsen Norman Group, som bruker begrepet profesjonelt, definerer det som en forberedende fase der man undersøker selve problemet og konteksten det står i, formulerer hva som kan løses og samler nok grunnlag til å vite hva neste steg er, og understreker nettopp at det i kartleggingen ikke testes løsninger.

I offentlig sektor er denne tanken formalisert enda strammere, for den britiske regjeringens håndbok for digitale tjenester skiller mellom fem faser, nemlig kartlegging, alfa, beta, drift og avvikling, og om kartleggingen står det der rett ut: i denne fasen begynner du ikke å bygge tjenesten. Ved slutten av fasen avgjør teamet om de går videre eller stopper, og selve håndboken setter ingen fast frist, selv om den peker på at fasen i praksis vanligvis varer fire til åtte uker.

Her må det straks gjøres et forbehold, for ellers oppstår et feilaktig inntrykk: den nevnte håndboken beskriver livsløpet til en statlig digital tjeneste, ikke et bedriftsnettsted på ti sider, og å overføre fristene derfra til et vanlig utviklingsprosjekt ville være villedende. Det verdifulle i den er prinsippet, ikke kalenderen: før byggingen kommer en fase hvis mål er å forstå oppgaven, og utfallet av denne fasen kan også være beslutningen om ikke å bygge i det hele tatt.

I et praktisk prosjekt tar denne fasen vanligvis form av en samtale om prosesser, brukerroller og omfang, og resultatet er en skriftlig plan, ikke en designskisse, selv om bestilleren ofte vil se nettopp det andre. For bestilleren følger det to direkte konsekvenser av det, og den første er at uten et skriftlig kartleggingsresultat er det senere rett og slett ingenting å sammenligne det som ble bygd, med, så en tvist om omfanget blir stående uten bevis for begge parter. Den andre er at det nettopp i denne fasen er billig å ombestemme seg, mens etter at byggingen er i gang koster hver endring også det som allerede er bygd og som må gjøres om.

Prototypen er det billigste stedet å ombestemme seg

Mellom planen og byggingen ligger en fase som bestillere av og til ser på som en unødvendig utgift, og det er nettopp den fasen som oftest sparer penger. En prototype er en klikkbar versjon av nettstedet uten den egentlige koden, der du kan gå gjennom de viktigste løpene og se hvor noe mangler, og det eneste målet er å la deg ombestemme deg mens ombestemmelsen ennå er billig.

Den britiske regjeringens håndbok sier dette uten omsvøp, når den skriver om alfa-fasen at du må regne med at all koden som skrives i denne fasen, og en stor del av ideene som testes, blir kastet ved fasens slutt, og det er ikke i strid med godt arbeid, men er poenget med det: å kaste en prototype er billig, å kaste et ferdigbygd system er det ikke. På skalaen til et bedriftsnettsted virker det samme prinsippet i mindre omfang, og nettopp derfor lager vi prototypen før den første linjen med produksjonskode.

For bestilleren følger det et praktisk krav av dette, som det er verdt å si høyt: godkjenning av prototypen er ikke å sette et formelt kryss, men den eneste gangen da endringer bare koster tid, så det er nettopp da det er verdt å kalle til bordet de menneskene som senere vil si at ingen spurte dem om noe. Etter at prototypen er godkjent, koster hver slik samtale allerede det som er bygd.

Det andre som er verdifullt i denne fasen, er innhold i utkast, for en prototype med fylltekst er lett å godkjenne, og etterpå viser det seg at de ekte tekstene ikke får plass, eller at en seksjon som var tenkt som ett avsnitt, i virkeligheten trenger tre. Hvis tekstene ennå ikke er ferdige, er det verdt å legge inn utkast av omtrent riktig lengde i prototypen, for lengden endrer layouten mer enn noen farge.

Det meste av ventingen skjer på kundesiden

Prosjektets frist avgjøres oftest ikke av hvor fort utviklingen går, men av hvor raskt bestilleren leverer innhold, og i vår erfaring er det den vanligste årsaken til forsinkelse. I bransjen finnes det ingen uavhengig undersøkelse med metode og dato om dette, så vi sier det som vår erfaring og later ikke som om det står prosenter bak.

Her er det verdt å gjøre ett forbehold til, for ellers ville denne delen høres ut som å legge skylden over: i offentlig sektor er innholdsarbeid et eget yrke og en egen rolle i teamet, og i regjeringens håndbok står innholdsdesigner oppført blant de nødvendige ferdighetene, men av det følger det ikke at utvikleren skriver tekstene i et vanlig utviklingsprosjekt. Hvem som skriver dem, er et avtalespørsmål, og det eneste gale svaret er at ingen har avklart det før arbeidet starter.

Konkret ligger det vanligvis fem leveranser på bestillerens side, og hver av dem er det verdt å sette en konkret dato på allerede i avtalen, ikke å la det bli stående på samtalenivå. Den første er tekstene, og de er den tyngste av alle, for de kan ikke skrives på én kveld, og de skrives vanligvis av et menneske som ikke har skriving som en del av hovedjobben, og som må klemme den inn mellom de øvrige oppgavene. Den andre er fotografier og logoer i vektorformat, den tredje er tilganger til eksisterende systemer hvis noe skal flyttes derfra, den fjerde er godkjenninger på bestemte punkter i prosjektet, og den femte, som ikke er et dokument men et menneske, er én godkjenner som på vegne av bedriften har lov til å si ja.

Denne femte er den som oftest mangler, og mangelen koster mer enn hvilken som helst teknisk komplikasjon: et prosjekt der godkjenningen gis av en komité, trekker ut ikke fordi noen jobber dårlig, men fordi hver godkjenning krever et møte, møtene skjer annenhver uke, og mellom dem står arbeidet rett og slett stille. Hvis bedriften har flere interessenter, er den riktige løsningen ikke å prøve å holde dem utenfor, men å avtale hvem av dem som er den endelige beslutningstakeren, og innen hvilken frist svaret ventes.

I offentlig sektor er dette ansvaret i noen land skrevet inn hos institusjonslederen. I Norge finnes det ingen tilsvarende regel som peker ut virksomhetslederen som den som eier innholdet på det offisielle nettstedet: forskrift om universell utforming av IKT-løsninger § 5 krever at virksomheten dokumenterer «ansvarsforhold i virksomheten», og likestillings- og diskrimineringsloven § 18 legger IKT-plikten på «offentlige og private virksomheter», ikke på en navngitt leder. For en privat bedrift er det uansett ikke bindende som innholdseierregel, men tanken er den samme og kan tas inn frivillig: ansvaret for innholdet ligger hos bestilleren, og det må legges på et konkret menneske med navn.

Bilder er et rettighetsspørsmål, ikke et filspørsmål

Fotografier er stedet der bestillere handler med de beste intensjoner og likevel skaper risiko, fordi det blir antatt at en fil som ligger på datamaskinen, også er en fil du har lov til å bruke. Etter åndsverkloven er et fotografisk verk et vernet åndsverk, opphavsretten oppstår i det øyeblikket verket skapes uten noen registrering, og opphaveren er mennesket som tok bildet; også et fotografisk bilde uten verkshøyde har en nærstående rett etter § 23.

Av det følger en slutning som overrasker nesten hver bedrift: betaling for en fotoseanse betyr i seg selv ikke at bestilleren har fått opphavsretten. Fotografen forblir opphaver, de ideelle rettighetene, deriblant retten til å bli navngitt, kan ikke fraskrives med mindre det gjelder en bruk avgrenset etter art og omfang, og de økonomiske rettighetene går over bare ved opphavsrettslig lisens eller overdragelse, og for en bedrift som planlegger å bruke fotografiene på nettstedet, i sosiale medier og i trykk, betyr det at lisensen må liste nettopp disse bruksformene. Overdragelse av filene innbefatter ikke overdragelse av opphavsretten, etter § 67.

Med bildebanker er det akkurat likeså, bare at vilkårene der er skrevet klart og offentlig, så de kan leses før kjøpet: Shutterstocks standardlisens gir en ikke-eksklusiv og ikke-overdragbar rett til å bruke bildet, blant annet på nettsteder, og på den samme siden står det at kunden ikke får eiendomsrett eller eksklusive rettigheter. Der står det også begrensninger som ofte brytes ved et uhell: bildet må ikke gis videre, må ikke brukes som logo eller varemerke, og bilder merket som kun til redaksjonell bruk må ikke brukes kommersielt. En bedrift som har kjøpt en standardlisens, har fått rett til å bruke bildet på nettstedet, ikke en fil den kan overlevere til utvikleren som sin eiendom.

Det er også et tilfelle som nesten alltid blir misforstått. Åndsverkloven § 31 lar et verk avbildes når det varig er plassert på eller ved offentlig plass eller vei, men ikke når verket klart er hovedmotivet og gjengivelsen brukes ervervsmessig. Byggverk kan likevel fritt avbildes, også kommersielt på et bedriftsnettsted. En skulptur som hovedmotiv på et bedriftsnettsted dekkes derfor ikke; en skulptur som tilfeldig inngår i et gatebilde, dekkes. Et bilde av en fremmed skulptur som hovedmotiv trenger fortsatt tillatelse; et bilde av en fremmed bygning gjør det ikke.

Til slutt er mennesker på bilder et spørsmål om personopplysninger, ikke bare et spørsmål om høflighet: personvernforordningen gjelder i Norge gjennom EØS og personopplysningsloven, og Datatilsynet skriver at bilder der personer er hovedmotivet, som hovedregel krever samtykke før de publiseres. Behandlingsgrunnlaget kan etter forordningen være samtykke eller avtale, og samtykket skal være gitt fritt, være spesifikt, informert og utvetydig. Det viktigste praktiske er at samtykket kan trekkes tilbake, og etter tilbaketrekking skal bildene fjernes fra det offentlige rommet, så teamfotografier på nettstedet må ordnes slik at en ansatt som slutter, ikke blir et problem.

Utviklingsmiljøet og feilen som gjøres med gode intensjoner

Før publisering skjer arbeidet i et eget miljø, og det trengs av en enkel grunn: bestilleren må se en ekte side i en ekte nettleser, ikke et bilde fra et designverktøy, og feil må fanges der kundene ikke ser dem. Spørsmålet er bare hvordan dette miljøet skal stenges, og det er nettopp her det gjøres en feil som ser riktig ut.

Den vanlige løsningen er å skrive et forbud i robots.txt, og det gjør ikke det folk tror, for i Googles dokumentasjon står det rett ut: denne filen forteller søkerobotene hvilke adresser de får hente, og den tjener først og fremst til å unngå at nettstedet overbelastes med forespørsler, men den er ikke en mekanisme for å holde en side utenfor Google. For at siden ikke skal vises i søkeresultatene, må du bruke en noindex-regel eller beskytte miljøet med passord.

Deretter kommer detaljen som gjør at de to metodene sammen virker dårligere enn hver for seg. En noindex-regel virker bare hvis siden er tilgjengelig for søkeroboten, fordi søkeroboten må lese den; hvis siden er stengt i robots.txt, ser søkeroboten aldri regelen, og siden kan likevel vises i resultatene, for eksempel hvis lenker fra andre steder peker dit; dessuten støtter Google ikke noindex i robots.txt i det hele tatt.

Det er også en annen grunn til at dette ikke er et teoretisk problem, nemlig at hvis utviklingsmiljøet inneholder det samme innholdet som det ferdige nettstedet, kan søkemotoren ta nettopp det som hovedversjon og vise det i resultatene i stedet for nettstedet ditt, som betyr at besøkende lander på en uferdig side med testdata. Denne feilen er vanskelig å oppdage, for selve nettstedet virker feilfritt, og problemet synes bare i søkeresultatene.

Det praktiske svaret er derfor enkelt, og det er verdt å be om det uttrykkelig: beskytt utviklingsmiljøet med passord. Det er den eneste løsningen som uavhengig av søkerobotenes atferd sørger for at et uferdig nettsted ikke dukker opp noe sted, og samtidig fjerner den den andre risikoen, som det tenkes sjeldnere på, nemlig at et utviklingsmiljø med det samme innholdet kan bli tatt som hovedversjon og begynne å konkurrere med det ekte nettstedet.

Hvilke valg etter lanseringen koster mest

De fleste beslutningene i et nettsideprosjekt kan endres også etter lanseringen, og det er verdt å si klart, for bestillere bekymrer seg ofte nettopp for de tingene som senere er lettest å endre. Farger, layout, mal, tekster og til og med plasseringen av sider i menyen kan endres praktisk talt når som helst, og det koster bare arbeidstimer, ikke ombygging, men to ting er likevel annerledes, og det er nettopp dem det er verdt å tenke på før lanseringen, mens endringen ennå ikke koster noe.

Den første er adressestrukturen, og den blir en beslutning i det øyeblikket sidene er indeksert og fremmede lenker peker dit, for fra da av er en adresseendring ikke lenger et visuelt valg, men en flytting av nettsted, som Google beskriver som en egen prosedyre med egne krav. Du skal bruke permanente omdirigeringer på serversiden, og de skal beholdes i minst ett år; Google advarer også mot å endre i samme runde både adresser, innholdssystem og layout, og for et vanlig bedriftsnettsted anbefaler de å flytte alle adresser i én omgang, ikke stykkevis. Der står det også et nyttig tillegg som demper frykten: permanente omdirigeringer gir i seg selv ikke tap av rangering, selv om plasseringene en stund kan svinge.

Den andre er selve domenet, for et domeneskifte er den samme flyttingen med alle dens krav, bare i større skala, og til den kommer alt som allerede er trykt på visittkort og brevark. Om hvem domenet skal registreres på, har vi skrevet i artikkelen om ti feil når du skal bestille nettside, og her gjentar vi det ikke; her er det bare verdt å si at valg av domene er en av de få beslutningene der det senere koster mer å endre enn å gjøre det riktig med en gang.

Det er én prosedyredetalj som er verdt å kjenne, så du ikke ber om den uten grunn: søknad om adresseendring i Search Console sendes bare inn når domenet eller underdomenet endres; overgang fra usikker til sikker tilkobling, eller valget mellom adresse med og uten prefiks på samme domene, er den ikke ment for, og der holder det med riktige omdirigeringer. For bedriften betyr det at de fleste endringene ordnes på serversiden, ikke i et skjema.

Praktisk følger det ett råd av dette før lanseringen: hvis det gamle nettstedet allerede finnes og har besøkende fra søkemotorer, skal listen over adresser med omdirigeringer til de nye adressene være ferdig før publisering, ikke etter at noen oppdager fallet i trafikken. Denne listen er også en av de oppgavene bestilleren kan forberede selv, og som, hvis ingen forbereder den, etter lanseringen blir en uke med letearbeid.

Universell utforming: hvem som har plikt, og hvem som ikke har

Offentlige virksomheter har hatt plikt til universell utforming av IKT i flere år; private virksomheter har den også, når nettstedet er en hovedløsning rettet mot eller stilt til rådighet for brukere. Et informativt bedriftsnettsted som ikke selger noe, er ikke unntatt av den grunn. I markedet blandes ofte EUs tilgjengelighetsdirektiv med det norske regelverket, og det er en feil som koster.

Det første gjelder offentlig sektor, og det har vært i kraft i flere år, så for virksomhetene er det ikke nytt. Direktivet om tilgjengelighet til nettsteder i offentlig sektor er i Norge tatt inn i forskrift om universell utforming av IKT-løsninger, som for offentlige virksomheter krever at nettløsninger er mulige å oppfatte, mulige å betjene, forståelige og robuste, og at virksomheten avgir en tilgjengelighetserklæring. Plikten til erklæring etter § 4e gjelder offentlige virksomheter og ikke en alminnelig privat bedrift, selv om markedet av og til selger den som et allment krav.

Det andre er nyere, og det er nettopp det som skaper de fleste misforståelsene, fordi ikrafttredelsesdatoen er blitt bredt omtalt, men virkeområdet ikke: EUs tilgjengelighetsdirektiv er ennå ikke vedtatt inn i EØS-avtalen. Bufdir og Uu-tilsynet skriver at «Det er ennå ikke vedtatt at Tilgjengelighetsdirektivet (EAA) skal inn i EØS-avtalen», så pliktene som i EU-landene følger av 28. juni 2025, gjelder ikke i Norge. Det betyr ikke at et norsk bedriftsnettsted er uten krav, og nettopp den for vide påstanden gjentas oftest i markedet, av og til sammen med et tilbud om å fikse den.

Det som binder i Norge, er ikke en liste over tjenester, men hovedløsningen. Likestillings- og diskrimineringsloven § 18 legger plikt til universell utforming av hovedløsninger for IKT på offentlige og private virksomheter, og forskriften § 4 krever at private virksomheters nettløsninger minst oppfyller WCAG 2.0 på nivå A og AA, med opplistede unntak. Forskriften gjelder på alle samfunnsområder unntatt familieliv, og et informativt bedriftsnettsted som er hovedløsningen virksomheten informerer brukerne med, er inne. Et bedriftsnettsted som ikke selger noe og ikke er bank, transportør eller bokplattform, er likevel omfattet hvis det er en slik hovedløsning.

Det finnes ingen unntak for mikrovirksomheter av den typen tilgjengelighetsdirektivet gir. Unntaket i direktivet for tjenester levert av virksomheter med færre enn ti personer og omsetning eller balansesum på høyst to millioner euro, finnes ikke i norsk rett, fordi direktivet ikke er innlemmet. Det som finnes, er en sikkerhetsventil for uforholdsmessig stor byrde i likestillings- og diskrimineringsloven § 18, der størrelse og ressurser er ett moment, ikke et unntak etter hodetall, og forskriften § 10 åpner for dispensasjon når byrden er uforholdsmessig stor. Setningen om at små virksomheter er fritatt, er derfor ikke riktig i Norge.

Den praktiske slutningen for bestilleren er kort: hvis du lager et nettsted som er virksomhetens hovedløsning mot brukere, skal kravene til universell utforming inn i kravspesifikasjonen allerede, for senere betyr de omarbeiding. Hvis du er en offentlig virksomhet, kommer tilgjengelighetserklæringen i tillegg. At siden kan brukes med tastatur og leses med skjermleser, er uansett et argument, fordi en del av kundene dine bruker det uavhengig av loven.

Hvor lang tid alt dette tar

Fristspørsmålet er det bestilleren vil ha svar på først, og det er også det det er vanskeligst å gi et ærlig svar på. Fristene som publiseres i bransjen, kommer nesten alltid fra utviklernes egne sider, der de tjener som et løfte om hastighet, så de kan ikke brukes som et uavhengig datapunkt, og en uavhengig undersøkelse med metode fant vi ikke.

Derfor er det riktigere å tale om det som avgjør fristen, enn å lete etter et gjennomsnittstall som likevel ikke passer noe konkret prosjekt: fristen avgjøres av omfang, av hvor raskt godkjenningene kommer, og av om innholdet er klart, og i de to siste av disse tre ligger den avgjørende innflytelsen på bestillerens side. Et prosjekt der tekstene er ferdige før starten og beslutningene tas av ett menneske, går betydelig raskere enn et prosjekt av samme omfang uten disse to vilkårene, og det er en forskjell som kan måles i uker.

Vår egen publiserte frist på siden for WordPress-utvikling er fire til ti uker, og den gjelder et vanlig bedriftsnettsted, mens den for mer kompliserte prosjekter er lenger, og for nettbutikk enda lenger, men for et konkret prosjekt er den eneste nyttige fristen den som følger av omfanget, ikke av et gjennomsnitt.

Det er også en annen måte å se på dette spørsmålet på, og for bestilleren er den vanligvis mer nyttig enn ethvert tall: spør utvikleren ikke hvor lang tid det vil ta, men hvilke uker som avhenger av deg, og hvilke som avhenger av ham. Svaret på det spørsmålet kan etterprøves, og det viser med en gang hvor stor del av fristen du selv styrer.

Og én ting til, som påvirker fristen mer enn det ser ut som, er at omfanget vokser underveis: hvert nytt forslag er lite og begrunnet hver for seg, men sammen flytter de overleveringsdatoen, og det skjer umerkelig, fordi ingen av dem noensinne ser ut som en beslutning om å forlenge prosjektet. Det eneste som hjelper mot det, er en avtale om at endringer utenfor det opprinnelige omfanget skrives ned separat sammen med virkningen på fristen, ikke tas inn i stillhet.

Hva du skal avtale før arbeidet starter

Før den første fakturalinjen er det verdt å snakke gjennom og skrive ned en innholdsplan med datoer: hvem som skriver tekstene, innen hvilken dato de er i utviklerens hender, og hva som skjer hvis de blir forsinket, for uten dette punktet ser en forsinkelse alltid ut som utviklerens feil.

Det andre er bildenes opphav og rettigheter, nemlig hvor fotografiene kommer fra, hvilken lisens de har, om lisensen nevner bruk nettopp på nettstedet, og om menneskene på bildene har gitt samtykke som de senere kan trekke tilbake. Det tredje er én godkjenner med fornavn og etternavn, og en avtale om hvor mange virkedager det ventes svar på en godkjenningsforespørsel, for uten frist er en godkjenning ikke en planleggbar størrelse.

Det fjerde er et utviklingsmiljø beskyttet med passord, ikke med et forbud i robots.txt, og det femte er en omdirigeringsliste fra de gamle adressene til de nye, hvis det gamle nettstedet allerede finnes og har besøkende. Det sjette er universell utforming: hvis nettstedet er virksomhetens hovedløsning mot brukere, skal kravene inn i kravspesifikasjonen, og for en offentlig virksomhet kommer tilgjengelighetserklæringen i tillegg; det er langt billigere å avklare det når spesifikasjonen skrives enn etter overleveringen.

Denne listen er verdt å gå gjennom i én samtale, ikke stykkevis, for det er nettopp samlet at den viser hvor stor del av prosjektet som avhenger av bestilleren, og den er vanligvis større enn bestilleren ventet. Ingen av disse kravene er dyre, og ingen av dem krever teknisk kunnskap; de krever bare at noen stiller dem før arbeidet starter.

Og det sjuende, som ikke er teknisk, men avgjør mer enn de øvrige seks: en avtale om hva som er det minste omfanget nettstedet kan publiseres med. Et prosjekt der publisering skjer bare når alt er ferdig, pleier aldri å bli publisert, mens et prosjekt med et klart minste omfang publiseres i tide og vokser etterpå. Hvis du vil at vi skal snakke denne samtalen gjennom sammen med deg, ta kontakt med oss.