Vad som händer mellan beslutet och publiceringen: webbplatsprojektets steg

Avtalet är påskrivet, förskottet är betalt, och sedan blir det tyst. Företaget väntar på att webbplatsen ska dyka upp, utvecklaren väntar på texter och fotografier, och ingen av dem tänker att de väntar precis samma vecka, så efter en månad är båda parter missnöjda och ingen av dem har gjort något fel; det var bara det att ingen hade skrivit ner vem som levererar vad, och till vilket datum.

Den här artikeln handlar om vad som händer mellan beslutet och publiceringen, och främst om arbetsfördelningen mellan de två parterna, eftersom det är den som avgör tidsplanen långt oftare än utvecklingshastigheten eller den valda tekniken. Vilka misstag beställare gör har vi skrivit om separat i artikeln om tio misstag när du beställer en webbplats, och här upprepar vi dem inte. Här finns inte heller några priser, och ingen jämförelse mellan att göra det själv och att beställa, eftersom båda hör till andra artiklar; det handlar bara om ordningen, och om vad som ska förberedas i varje steg.

Förstudien är inte början på bygget

Nästan varje utvecklingsprocess börjar med ett skede som kallas förstudie eller discovery, och just det skedet missförstås oftast, eftersom beställaren tar det för en formalitet före det riktiga arbetet. Nielsen Norman Group, som använder begreppet professionellt, definierar det som ett förberedande skede där man undersöker själva problemet och dess sammanhang, formulerar vad som går att lösa och samlar tillräckligt med belägg för att veta vad man ska göra härnäst, och betonar just att man i förstudien inte testar lösningar.

I offentlig sektor är tanken formaliserad ännu stramare, eftersom Storbritanniens manual för digitala tjänster (Government Digital Service Manual) skiljer ut fem skeden, nämligen förstudie, alfa, beta, drift och avveckling, och om förstudien står det enkelt: i det skedet börjar man inte bygga tjänsten. I slutet av skedet beslutar teamet om man ska gå vidare eller stanna, och själva manualen sätter ingen fast tidsram, även om den anger att skedet i praktiken oftast tar fyra till åtta veckor.

Här måste en reservation göras genast, annars uppstår en felaktig bild: den nämnda manualen beskriver livscykeln för en statlig digital tjänst, inte en företagswebbplats på tio sidor, och att föra över dess tider på ett vanligt utvecklingsprojekt skulle vara vilseledande. Det värdefulla i den är principen, inte kalendern: före bygget finns ett skede vars mål är att förstå uppdraget, och resultatet av det skedet kan också vara ett beslut att inte bygga alls.

I ett praktiskt projekt tar skedet vanligtvis formen av ett samtal om processer, användarroller och omfattning, och resultatet är en skriftlig plan, inte en designskiss, även om beställaren ofta vill se just det senare. För beställaren följer två direkta konsekvenser, och den första är att det utan ett skriftligt förstudieresultat senare helt enkelt inte finns något att jämföra det byggda mot, så en tvist om omfattningen blir utan bevis för båda parter. Den andra är att det just i det skedet är billigt att ändra sig, medan varje ändring efter att bygget har börjat också kostar det som redan är byggt och som måste göras om.

Prototypen är det billigaste stället att ändra sig

Mellan planen och bygget finns ett skede som beställare ibland ser som en onödig utgift, och det är precis det skede som oftast sparar pengar. En prototyp är en klickbar version av webbplatsen utan den riktiga koden, där man kan gå igenom de viktigaste vägarna och se var något saknas, och dess enda mål är att låta dig ändra dig medan det fortfarande är billigt att ändra sig.

Storbritanniens manual säger tanken utan skonsamhet, när den om alfafasen skriver att man ska räkna med att all kod som skrivs i det skedet och en stor del av de idéer som prövas kommer att slängas i slutet av skedet, och det strider inte mot ett bra arbete utan är poängen med det: att slänga en prototyp är billigt, att slänga ett byggt system är det inte. I skalan för en företagswebbplats gäller samma princip i mindre omfattning, och just därför tar vi fram prototypen före den första raden produktionskod.

För beställaren följer ett praktiskt krav som förtjänar att sägas rakt ut: att godkänna prototypen är inte en formell bock i kanten, utan det enda tillfället då ändringar bara kostar tid, så just då lönar det sig att kalla in de personer som senare kommer att säga att ingen frågade dem något. Efter att prototypen är godkänd kostar varje sådant samtal redan det som är byggt.

Det andra som lönar sig i det skedet är innehållet i utkast, eftersom en prototyp med utfyllnadstext är lätt att godkänna och man sedan upptäcker att de riktiga texterna inte ryms, eller att ett avsnitt som var tänkt för en enda paragraf egentligen behöver tre. Om texterna inte är klara ännu lönar det sig att lägga in utkast av ungefär rätt längd i prototypen, eftersom längden ändrar layouten mer än någon färg.

Merparten av väntan sker hos kunden

Projektets tidsplan sätts oftast inte av hur snabbt utvecklingen går, utan av hur snabbt beställaren levererar innehållet, och i vår erfarenhet är det den vanligaste orsaken till försening. Det finns ingen oberoende undersökning om saken i branschen med metod och datum, så vi säger det som vår egen erfarenhet och låtsas inte att det står procent bakom.

Här behövs ytterligare en reservation, annars skulle stycket låta som att skulden läggs över: i offentlig sektor är innehållsarbete ett eget yrke och en roll i teamet, och i den brittiska manualen räknas innehållsdesigner upp bland de färdigheter som behövs, men därav följer inte att utvecklaren skriver texterna i ett vanligt utvecklingsprojekt. Vem som skriver dem är en avtalsfråga, och det enda felaktiga svaret är att ingen har rett ut det innan arbetet börjar.

Konkret finns det vanligtvis fem leveranser på beställarens sida, och varje av dem förtjänar ett konkret datum redan i avtalet, inte att lämnas på samtalets nivå. Den första är texterna, och de är den tyngsta av alla, eftersom de inte kan skrivas på en kväll och de vanligtvis skrivs av någon för vilken skrivande inte är en del av grundjobbet och som måste klämma in det mellan övriga plikter. Den andra är fotografier och logotyper i vektorformat, den tredje är åtkomst till befintliga system om något ska flyttas från dem, den fjärde är godkännanden vid bestämda punkter i projektet, och den femte, som inte är ett dokument utan en människa, är en godkännare som får säga ja i företagets namn.

Just den femte saknas oftast, och bristen kostar mer än någon teknisk krånglighet: ett projekt där godkännandet ges av en kommitté drar ut på tiden inte för att någon arbetar dåligt, utan för att varje godkännande kräver ett möte, mötena sker varannan vecka, och mellan dem står arbetet stilla. Om företaget har flera intressenter är den rätta lösningen inte att försöka stänga ute dem, utan att avtala vem av dem som är den slutliga beslutsfattaren och inom vilken tid ett svar väntas.

Sverige har ingen regel som utpekar institutionschefen som ansvarig för innehållet på den officiella webbplatsen. Ett privat företag binds inte av någon sådan skyldighet, men tanken är densamma och kan tas över frivilligt: ansvaret för innehållet tillhör beställaren, och det ska läggas på en namngiven person.

Bilder är en rättighetsfråga, inte en fråga om filer

När det gäller fotografier handlar beställare med de bästa avsikterna och skapar ändå en risk, eftersom en fil som ligger i datorn tas för en fil som också får användas. Enligt lagen (1960:729) om upphovsrätt till litterära och konstnärliga verk är ett fotografiskt verk ett skyddat verk, upphovsrätten uppstår när verket skapas utan någon registrering, och upphovsman är den som har skapat verket, alltså den som tog bilden.

Därav följer något som överraskar nästan varje företag: betalning för en fotografering betyder inte i sig att beställaren har fått upphovsrätten. Fotografen förblir upphovsman. De ideella rättigheterna, bland annat rätten att bli namngiven i den omfattning god sed kräver, kan enligt 3 § bara efterges för en till art och omfattning begränsad användning, och de ekonomiska rättigheterna går över bara genom licens eller överlåtelse, och för ett företag som planerar att använda fotografierna på webbplatsen, i sociala medier och i tryck betyder det att licensen eller överlåtelsen måste räkna upp just de användningarna.

Med bildbanker är det precis likadant, bara att villkoren där är skrivna tydligt och offentligt, så de kan läsas före köpet: Shutterstocks Standard License ger en icke-exklusiv och icke-överlåtbar rätt att använda bilden, bland annat på webbplatser, och på samma sida står att kunden inte får äganderätt och inte ensamrätt. Där finns också begränsningar som man ofta bryter mot av misstag: bilden får inte lämnas vidare, får inte användas som logotyp eller varumärke, och bilder som är märkta för enbart redaktionellt bruk får inte användas kommersiellt. Ett företag som har köpt en standardlicens har fått rätten att använda bilden på webbplatsen, inte en fil som kan lämnas till utvecklaren som egen egendom.

Det finns ytterligare ett fall som nästan alltid missförstås. Upphovsrättslagen 24 § tillåter att konstverk avbildas om de stadigvarande är placerade på eller vid allmän plats utomhus, och byggnader får fritt avbildas. Regeln är inte begränsad till personligt bruk, nyheter eller icke-kommersiell användning, så en bild av någon annans byggnad på företagets webbplats är täckt, och det är också en skulptur som står stadigvarande utomhus på allmän plats. Däremot täcker 24 § inte tvådimensionella verk som inte är placerade så: en bild av någon annans fotografi eller målning som visas offentligt behöver fortfarande tillstånd.

Slutligen är människor på bilder en personuppgiftsfråga, inte bara en artighetsfråga: enligt dataskyddsförordningen är ett fotografi av en identifierbar person personuppgifter, och den rättsliga grunden kan vara samtycke eller avtal; samtycket ska vara frivilligt, särskilt, informerat och otvetydigt. Det som betyder mest i praktiken är att samtycke kan återkallas, och efter återkallelsen ska bilderna tas bort från den offentliga miljön, så teamfotografier på webbplatsen måste ordnas så att en medarbetare som slutar inte blir ett problem.

Utvecklingsmiljön och felet som görs med god avsikt

Före publiceringen sker arbetet i en separat miljö, och det behövs av ett enkelt skäl: beställaren ska se en riktig sida i en riktig webbläsare, inte en bild från ett designverktyg, och felen ska fångas på ett ställe där kunderna inte ser dem. Frågan är bara hur den miljön stängs av, och just här görs ett fel som ser riktigt ut.

Den vanliga lösningen är att skriva ett förbud i robots.txt, och det gör inte det människor tror, eftersom Google i sin dokumentation skriver rakt ut: filen talar om för sökmotorrobotar vilka adresser de får hämta, och den tjänar främst till att webbplatsen inte ska överbelastas med begäranden, men den är inte en mekanism för att hålla en sida utanför Google. För att sidan inte ska synas i sökresultaten ska ett noindex-direktiv användas, eller så ska miljön skyddas med lösenord.

Sedan följer detaljen som gör att de två metoderna tillsammans fungerar sämre än var och en för sig. Ett noindex-direktiv fungerar bara om sidan går att hämta, eftersom roboten måste läsa det; om sidan är förbjuden i robots.txt ser roboten aldrig direktivet, och sidan kan ändå synas i resultaten, till exempel om länkar leder dit utifrån; dessutom stöder Google inte ett noindex-direktiv i robots.txt alls.

Det finns också ett andra skäl till att detta inte är ett teoretiskt problem: om utvecklingsmiljön innehåller samma innehåll som den färdiga webbplatsen kan sökmotorn ta just den för huvudversionen och visa den i resultaten i stället för din webbplats, vilket betyder att besökaren landar på en ofärdig sida med testdata. Felet är svårt att märka, eftersom själva webbplatsen fungerar felfritt och problemet bara syns i sökresultaten.

Det praktiska svaret är därför enkelt, och det lönar sig att be om det uttryckligen: skydda utvecklingsmiljön med lösenord. Det är den enda lösningen som oberoende av robotarnas beteende ser till att en ofärdig webbplats inte syns någonstans, och samtidigt tar den bort den andra risken, som man tänker på mer sällan, nämligen att en utvecklingsmiljö med samma innehåll kan tas för huvudversionen och börja konkurrera med den riktiga webbplatsen.

Vilka val efter lanseringen som kostar mest

De flesta besluten i ett webbplatsprojekt går att ändra även efter lanseringen, och det förtjänar att sägas tydligt, eftersom beställare ofta oroas just över de saker som senare är lättast att ändra. Färger, layout, mall, texter och till och med var sidorna sitter i menyn går att ändra i praktiken när som helst, och det kostar bara arbetstimmar, inte en ombyggnad, men två saker är ändå annorlunda, och just dem lönar det sig att tänka på före lanseringen, medan ändringen fortfarande inte kostar något.

Den första är URL-strukturen, och den blir ett beslut just i det ögonblick sidorna är indexerade och främmande länkar pekar på dem, eftersom adressändring från det ögonblicket inte längre är ett visuellt val utan en flytt, som Google beskriver som ett eget förfarande med egna krav. Permanenta omdirigeringar på serversidan ska användas och behållas i minst ett år; Google varnar också för att i ett svep ändra både adresser, innehållshanteringssystem och layout, och för en vanlig företagswebbplats rekommenderar Google att flytta alla adresser på en gång, inte bitvis. På samma sida finns en nyttig upplysning som minskar rädslan: permanenta omdirigeringar leder inte i sig till att sidans vikt går förlorad, även om placeringarna kan svänga en tid.

Den andra är själva domänen, eftersom ett domänbyte är samma flytt med alla dess krav, bara i större skala, och till det kommer allt som redan är tryckt på visitkort och brevpapper. Vem domänen ska registreras på har vi skrivit om i artikeln om tio misstag när du beställer en webbplats, och här upprepar vi det inte; här ska bara sägas att valet av domän är ett av de få beslut som senare kostar mer att ändra än att göra rätt från början.

Det finns en förfarandedetalj som är bra att känna till, så att den inte begärs i onödan: en anmälan om adressändring i Search Console lämnas bara när domänen eller underdomänen ändras; den är inte avsedd för övergång från osäker till säker anslutning, eller för valet mellan adress med och utan www-prefix på samma domän, och där räcker rätta omdirigeringar. För företaget betyder det att merparten av ändringarna sköts på serversidan, inte i något formulär.

I praktiken följer ett råd före lanseringen: om den gamla webbplatsen redan finns och har besökare från sökmotorer, ska en lista över adresser med omdirigeringar till de nya adresserna tas fram före publiceringen, inte efter att någon märker de fallande besöken. Listan är också ett av de arbeten som beställaren kan förbereda själv, och som, om ingen förbereder den, efter lanseringen blir en veckas sökarbete.

Tillgänglighet: för vem det är ett krav och för vem det inte är

För offentliga aktörer har tillgänglighet varit ett krav i flera år; för ett privat företag bara om det tillhandahåller en tjänst som räknas upp i lagen, oftast e-handel, och inte är ett mikroföretag. En informativ webbplats som inte säljer något ingår inte i listan. På marknaden blandas de två lagarna ofta ihop, och det är ett fel som kostar.

Den första lagen gäller offentlig sektor, och den har gällt i flera år, så för myndigheter är den ingen nyhet. Europeiska unionens direktiv om tillgänglighet till offentliga aktörers webbplatser genomförs i Sverige av lagen (2018:1937) om tillgänglighet till digital offentlig service, och Myndigheten för digital förvaltnings föreskrifter (MDFFS 2019:2) kräver att den digitala servicen ska vara möjlig att uppfatta, hanterbar, begriplig och robust, samt att det publiceras en separat tillgänglighetsredogörelse. Reglerna binder offentliga aktörer och gäller inte ett vanligt privat företag, även om marknaden ibland säljer dem som ett allmänt krav.

Den andra är nyare, och just den skapar merparten av missförstånden, eftersom datumet då den började gälla har kungjorts brett, men inte räckvidden: Europeiska tillgänglighetsdirektivet genomförs i Sverige av lagen (2023:254) om vissa produkters och tjänsters tillgänglighet, som gäller från och med den 28 juni 2025, tillsammans med förordningen (2023:676). Det betyder inte att varje företagswebbplats från det datumet måste uppfylla en tillgänglighetsstandard, och just det alltför vida påståendet upprepas oftast på marknaden, ibland tillsammans med ett erbjudande att åtgärda det.

Lagen gäller en konkret lista över tjänster, inte vilken webbplats som helst, och i den ingår elektroniska kommunikationstjänster, tjänster som ger åtkomst till audiovisuella medietjänster, vissa inslag i passagerartransport med flyg, buss, tåg och fartyg, de uppräknade banktjänsterna för konsumenter, e-böcker och e-handelstjänster. En informativ företagswebbplats som inte säljer något och inte är en bank, en transportör eller en bokplattform ingår inte i den listan.

Det finns också ett undantag för små företag, och det ska formuleras precist, eftersom det ofta återberättas för brett. Ett mikroföretag, det vill säga ett företag med färre än tio anställda och som har en årsomsättning eller en årlig balansomslutning som inte överstiger två miljoner euro, och som tillhandahåller en tjänst inom lagens område, behöver inte uppfylla tillgänglighetskraven för tjänster. Undantaget gäller tjänster; skyldigheterna som hör till produkter är lättare för mikroföretag, men inte upphävda, så meningen att mikroföretag är undantagna från lagen är inte riktig.

Den praktiska följden för beställaren är kort: om du bygger en webbutik och inte är ett mikroföretag, ska tillgänglighetskraven skrivas in redan i kravspecifikationen, eftersom de senare betyder omarbetning. Om du bygger en informativ webbplats finns det sannolikt inget juridiskt krav, men det är fortfarande ett argument för att sidan ska gå att använda med tangentbord och läsas med skärmläsare, eftersom en del av dina kunder använder dem oberoende av lagen.

Hur länge allt det här tar

Tidsfrågan är den som beställaren vill ha svar på först, och det är också den som det är svårast att ge ett ärligt svar på. De tider som publiceras i branschen kommer nästan alltid från utvecklarnas egna sidor, där de tjänar som ett löfte om hastighet, så de kan inte användas som en oberoende datapunkt, och någon oberoende undersökning med metod fann vi inte.

Därför är det riktigare att tala om vad som sätter tidsplanen, inte att leta efter ett medeltal som ändå inte passar något konkret projekt: tidsplanen sätts av omfattningen, hastigheten i godkännandena och hur redo innehållet är, och i de två sista av de tre ligger det avgörande inflytandet på beställarens sida. Ett projekt där texterna är klara före starten och besluten fattas av en person går betydligt fortare än ett projekt av samma omfattning utan de två villkoren, och det är en skillnad som går att mäta i veckor.

Vår egen publicerade tid på sidan för WordPress-utveckling är fyra till tio veckor, och den gäller en vanlig företagswebbplats, medan den för mer komplicerade projekt är längre, och för e-handel ännu längre, men för ett konkret projekt är den enda användbara tiden den som följer av omfattningen, inte av ett medeltal.

Det finns ett annat sätt att se på frågan, och för beställaren är det vanligtvis mer användbart än någon siffra: fråga utvecklaren inte hur länge det tar, utan vilka veckor som beror på dig och vilka på utvecklaren. Svaret på den frågan går att kontrollera, och det visar genast hur stor del av tidsplanen du själv styr.

Och ytterligare en sak som påverkar tidsplanen mer än det ser ut är att omfattningen växer under arbetets gång: varje nytt förslag är litet och sakligt för sig, men tillsammans flyttar de överlämningsdatumet, och det sker omärkligt, eftersom inget av dem någonsin ser ut som ett beslut att förlänga projektet. Det enda som hjälper mot det är en överenskommelse att ändringar utanför den ursprungliga omfattningen skrivs upp separat tillsammans med deras verkan på tidsplanen, inte tas in i tysthet.

Vad som ska avtalas innan arbetet börjar

Före den första fakturaraden lönar det sig att tala igenom och skriva ner en innehållsplan med datum: vem som skriver texterna, till vilket datum de är i utvecklarens händer och vad som händer om de dröjer, eftersom förseningen utan den punkten alltid ser ut som utvecklarens fel.

Det andra är bildernas ursprung och rättigheter, nämligen varifrån fotografierna kommer, vilken licens de har, om licensen nämner användning just på webbplatsen och om människorna på bilderna har gett ett samtycke som de senare kan återkalla. Det tredje är en godkännare med för- och efternamn, samt en överenskommelse om inom hur många arbetsdagar ett svar på en begäran om godkännande väntas, eftersom ett godkännande utan tidsfrist inte är en planerbar storhet.

Det fjärde är en utvecklingsmiljö som skyddas med lösenord, inte med ett förbud i robots.txt, och det femte är en omdirigeringslista från de gamla adresserna till de nya, om den gamla webbplatsen redan finns och har besökare. Det sjätte är frågan om tillgänglighet, vars svar beror på vad din webbplats gör, och som är mycket billigare att ställa i det ögonblick kravspecifikationen skrivs än efter överlämningen.

Den här listan lönar det sig att gå igenom i ett samtal, inte i bitar, eftersom den just tillsammans visar hur stor del av projektet som beror på beställaren, och det är vanligtvis större än beställaren väntade. Inga av kraven är dyra, och inga av dem kräver tekniska kunskaper; de kräver bara att någon ställer dem innan arbetet börjar.

Och det sjunde, som inte är tekniskt men avgör mer än de övriga sex: en överenskommelse om vad som är den minsta omfattning med vilken webbplatsen kan publiceras. Ett projekt där publicering bara sker när allt är klart tenderar att aldrig publiceras, medan ett projekt med en tydlig minsta omfattning publiceras i tid och sedan växer. Om du vill att vi går igenom det här samtalet tillsammans med dig, kontakta oss.