Del 2: Analytisk vinkel på design, prestanda och innehåll

Som webbplatsägare eller innehållsproducent kan en stilguide vara den naturliga platsen att dokumentera den kommunikativa stil man har för avsikt att använda i digitala sammanhang. I stilguiden ryms även andra saker, som organisationens webbriktlinjer, designmönster, prestandabudget och mycket mer. Där den grafiska profilen tar slut i digitala sammanhang tar stilguiden över. Som exempelvis att kravställa interaktion, något som kallas för en prestandabudget.

En prestandabudget är platsen där man sätter sin lägsta-nivå, alltså vilken standard man minst vill hålla på sin webbplats. Denna nivå kan täcka in vad som helst du vill definiera för hur webbplatsen ska prestera. Ett fåtal övertrasseringar av denna budget är inget att jaga upp sig över, men samtidigt ska inte projekt genomföras i strid med den budget man satt upp.

Jag inser att jag kan behöva förklara hur design hänger ihop med analys, och uppföljning i största allmänhet. Anledningen till att denna del är värd att beakta är för att om man inte har en konsekvent eller medveten design och kravställning blir det svårare att utesluta designfaktorer som brus i sin insamlade data. Exempelvis kan man fråga sig hur meningsfullt det är att testa en ny färg på call to action-knappar om man redan är väldigt inkonsekvent.

Om man varken följer designkonventioner användarna lärt sig eller ens själv är konsekvent i sin egen design gör man inte mesta möjliga av användarupplevelsen. Det blir också svårt att följa upp hur webbplatsen presterar. Det är anledningen till varför en webbanalytiker ska intressera sig åtminstone lite grand i designfrågor i stora drag och ibland vara lite ifrågasättande kring grafiska detaljer inom formgivning.

Min egen arbetsgivares webbplats hade fram till 2016 massor av olika sätt att formge länkar. Jag vet inte hur många det var i den ursprungliga layouten men det blev fler och fler över tiden. Antagligen berodde detta på att det saknades styrning i designfrågor. Den styrning som fanns gick ut på att man inte fick lov att placera länkar i brödtexten. Ibland var en länk understruken, medan länken i kolumnen bredvid inte var det. Det hände också att länkar i listor hade en färggrann ikon intill, men ibland bestod de av vanliga punktlistor. Vissa länkar var svarta, andra var blå, om de nu inte var vita. Det som hände när man drog en musmarkör över en länk varierade också, ibland blev de länkar som saknade understrykning tilldelade en sådan, men det var inte något man kunde räkna med. Utöver de bilder som var klickbara kunde länkar ha tre olika färger, ha fetstil eller vanlig text, ibland rubriker, eller vara understrukna. Länkade bilder var även det en mix av allt möjligt, dels den för tiden vanligt förekommande platta designen, men ibland någon form av bild med skuggeffekt bakom - så kallad skeumorfisk design, alltså det som efterliknar hur en fysisk motsvarighet kan tänkas se ut.

: Bild 21: Ett axplock av länkar från startsidan på vgregion.se, många olika utseenden, inte alltid uppenbart vad som är en länk (2015).

Vid nästa redesign, under 2015, tog vi chansen att försöka börja styra designen, och Västra Götalandsregionens stilguide var född. I vanlig ordning släppt med fri licens så andra kan göra en kopia och göra om den efter egna behov.

Det vi ofta finner i en stilguide är språkriktlinjer, som tips på längd på meningar, hur saker och ting ska se ut, så kallade designmönster samt generella tips. Vi ska strax gå igenom respektive del.

: Bild 22: Första versionen av Västra Götalandsregionens stilguide.

Ett mer extremt exempel just när det gäller färgval hörde jag av Expressens lead frontend-utvecklare. De hade bara på startsidan av expressen.se hela 24 olika nyanser av sin röda färg. Detta berodde inte på något krav från de som beställer design till webbplatsen utan snarare på att utvecklarna själva valde en röd färg när de skulle göra något rött. Kanske var det den insikten som fick Expressen att ta fram en stilguide och standardisera vilka färger som är de rätta. Med en stilguide tog de kontroll över hur användarna skulle förstå och tolka deras webbplats.

Stilguider är i sig inget nytt. Dock är det en av få saker som webben inte ärvde från trycksaksproducenterna redan under 1990-talet. Stilguide kan vara ett paraplybegrepp och samlingsplats för all dokumentation om hur man bedriver sin kommunikation i digitala sammanhang. Inom etablerade verksamheter har man säkert redan några delar av det som kan utgöra en stilguide. Möjligen kallas de för riktlinjer, handledningar, designmanualer eller liknande. Ibland gäller dessa endast den fysiska verkligheten som skyltar eller trycksaker och ibland gäller de mer digitala ting. Ett väldigt relevant och ytterst kommunikativt exempel på innehåll att fundera på till sin stilguide är New York Times dokument med ”förbjudna” ord. Alltså deras språkliga stil.

: Bild 23: New York Times lista med ord att undvika.

Anledningen till att man bör samla all dokumentation på en gemensam plats är för att om folk slipper leta på flera platser lär följsamheten till dessa dokumenterade klokskaper öka. Därför tror jag att det är smart att vara inkluderande i vad man väljer att ta med i sin stilguide, även det som inte är så värst digitalt kan säkert göra nytta.

Det är lite underligt att stilguider inte blev en självklarhet samtidigt som responsiv webbdesign slog igenom. I och med att man i designskedet för en responsiv webbplats är tvungen att börja prata om hur ett designelement ska se ut på olika stora skärmar borde behovet av en dokumenterad design vara nästan uppenbart. Hur ska man annars veta hur ett designmönster, likt huvudmenyn, beter sig och ser ut på olika skärmar? Till en början, hos vissa organisationer, nedtecknades dessa i något som kallas pattern libraries. Alltså organisationens bibliotek av designmönster. Nu tycks designmönster allt oftare vara en del av de publikt tillgängliga stilguider vi kan finna på webben.

: Bild 24: Designmönster för en sökruta.

Under 2000-talets första årtionde har nog många organisationer stått och stampat lite i webbarbetet. Många är kanske halvvägs in i att mogna i sitt webbarbete, men saknar ändå vissa delar man har i det ”vanliga” kommunikations- och marknadsarbetet. Få tycks ha kommit särskilt långt med en lika fulländad digital del i sin grafiska manual, åtminstone jämfört med det som gäller trycksaker.

Design på nytt? Skapa en designbudget!

Om du har förmånen att kunna samköra jobbet med att ta fram en ny webbplats, eller åtminstone designa om den, och ta tag i arbetet med en stilguides designmönster ska du tacka din lyckliga stjärna. Ett sätt att ha konkreta och begripliga begränsningar i sitt designarbete är att jobba med något som kan kallas för en designbudget. Det är ett sätt att undkomma de ofta förekommande diskussionerna om att det är svårt att prioritera då tydligen allt alltid är viktigast.

Framväxande praxis inom webbdesign är att påbörja designarbetet med att sätta upp en designbudget. En designbudget går ut på att designa sidor och mallar på ett återhållsamt sätt. För att konkretisera denna återhållsamhet har man ett poängsystem som styr hur många designkomponenter som hamnar exempelvis på en landningssida. Säg att man börjar med att sätta ett tak om tjugo poäng som budget för varje enskild sidvisning. Ska du då lyfta in ett stort block med bild och call to action-knapp? Då kommer du ha förbrukat sex poäng bara på den stora bilden. Ska du sedan ha en bildkarusell försvinner kanske tio poäng till på grund av fler tunga bilder men också ett extra Javascript-beroende för själva bildbläddrandet.

En fördel med att göra en designbudget är för att det är svårt att laga den här typen av brister i efterhand när alla beslut är tagna. Samt att man nog är mer kompromissvillig i början av ett projekt.

Barbara Bermes har nedan förslag till poängsystem i sin utmärkta bok Lean Websites²⁰.

Designmönster	Poäng	Beskrivning
Liten påverkan	1	Små bilder, statiskt innehåll, enklare grafik, knappar och textfält.
Medelstor påverkan	2	Halvstora bilder och enklare skript.
Stor påverkan	6	Stora bilder, tredjepartstjänster, annonser från tredjepart.

Största vinsten med en designbudget är att konkretisera varje designbesluts påverkan på webbplatsen, det blir konkret för dem som inte har anledning att prata om detta i mer tekniska ordalag (där kommer prestandabudgeten in, något vi strax kommer in på).

Vill man själv spela djävulens advokat vid designbeslut så kan man konstant föreslå att A/B-testa användarnas acceptans av respektive idé. Kanske fungerar sidor med högre poäng. Kanske kan ert tak vara tjugofem poäng snarare än tjugo för en landningssida och den presterar på samma nivå? Men testa för all del också antagandet om färre designpoäng ger mer nytta, och var gränsen går.

Som Karen McGrane påpekar i sin bok Going Responsive²¹, i kapitlet Clean up your content, så är det i design- eller utvärderingsskedet man har ett gyllene tillfälle att sitta ned tillsammans och göra de svåra prioriteringarna om vilket innehåll som ska finnas, och vad som faktiskt är viktigast. Det är nu man också tänker mobile first, små skärmar, långsam uppkoppling etc. Svar på dessa frågor får man inte per e-post – man behöver träffas. Under ett sådant möte måste man kunna fatta beslut. Det är också nu det går att bemöta den oförmåga som ofta finns till att utse en endaste sak som är viktigast per sida. Om bara en sak får plats på en skärm, vad ska då det vara man väljer ut. Det finns inga delade förstaplatser i mobile first.

We’ve remade the Internet in our own image, which, in the United States, is obese.
- Jason Grigsby²²

Du har nog listat ut att man med detta synsätt behöver hushålla med resurserna i sidhuvud och sidfot. Annars blir det väldigt lite kvar för det unika på varje webbsida att använda sig av.

Orkar man inte hålla på med poängsystemet vid designbeslut kan man istället ha ett batteri av frågor som reder ut hur design påverkar upplevelsens snabbhet, ifall det gör det hela till en ökad kognitiv börda för användaren. Exempelvis kompletteras frågor om hur designförslaget påverkar varumärket, eller inkräktar på befintliga designmönster, med frågor som:

Kommer det påverka antalet filer som behöver laddas ner?
Blir sidvisningen tyngre?
Hur påverkas den upplevda prestandan?
Kommer användaren att bli mentalt överbelastad eller har svårt att tolka de alternativ som finns?

Poängen är att i större utsträckning konkretisera design i fler dimensioner än det strikt estetiska. Vi är sedan tidigare vana vid att ställa affärsmässiga frågor så som vad det kan tänkas kosta, hur lång tid det tar att färdigställa och vad man tror det har för värde för verksamheten. Många organisationer är klart sämre på att ställa designfrågor, som varför färg används på ett visst sätt, eller nödvändigheten i utsmyckning.

Ett tillägg till detta är det som Lara Hogan tar upp i sin bok Designing for Performance²³. Hon visar på att man gör sin designbudget specifik per brytpunkt på webbplatsen. För dig som inte är bevandrad i webbdesign kan det vara värt att veta att brytpunkt är de magiska bredderna på webbplatsen när designen förändras för att göra mesta möjliga av tillgängligt utrymme. Det är en del av konceptet responsiv webbdesign. En liten skärm har mindre möjlighet att visa upp mycket på en gång och därför blir det kanske ännu mer angeläget att inte vara slösaktig.

Det här med grundläggande design är också ett gyllene tillfälle att planera för sin kontinuerliga webbanalys. Exempelvis kan flera hypoteser om hur stor påverkan antalet designelement har på mobila användare utvärderas metodisk med A/B-tester när väl designen är klar och publicerad. Då kan man börja testa vad som funkar på faktiska användare, om man nu inte jobbar med tidiga designprototyper redan innan det byggts.

Att utvärdera hur en design presterar kan vara väldigt tekniskt. Det kommer du märka strax när vi tar upp begreppet prestandabudget. Designbudgeten är den chans man har att prata prestanda, och prestation, i relation till hur något kommer se ut i grova drag.

Som webbanalytiker kan du bidra på många sätt till diskussionen om en designbudget. Inte minst med att planera för en jämförelse mellan sidor som har drastiskt olika antal designelement, eller vilka kontraster du finner nyfikenhet inför att undersöka. En intressant anekdot jag hörde av Expressens lead frontend-utvecklare var att de A/B-testat hur väl deras besökare konverterade, och knepigt nog var det högre konverteringsfrekvens på de röriga sidorna. När de sedan gjorde de inte fullt så röriga sidorna lite ”sämre” fick även de sidorna högre konvertingsfrekvens.

Det är viktigt att utmana sina antaganden, bevisligen!

Innehållsbudget

Du som läst min bok Webbstrategi för alla²⁴ eller följer min blogg har nog märkt hur ofta jag refererar till allt bra engelska Gov.uk gör. Nu är de visserligen inte ensamma om att ha checklistor för hur man tänker kring sitt innehåll på webben, men de är bra på att tala öppet om varför de gör på det sätt de gör.

De flesta organisationer jag stött på har visserligen handledningar till hur man skriver, men väldigt få har likt Gov.uk gått långt i att göra denna klokskap anpassad till webben. Så här beskriver de exempelvis hur en sidtitel ska formuleras²⁵:

clear and specific
optimised for search
under 65 characters (including spaces)
unique within the site (check search results on GOV.UK)
in sentence case
written in plain English (no jargon)

Än mer intressant är kanske riktlinjerna för brödtext:

begin with what’s most important to users (not to government)
be concise and easy to scan (with sub-heads every 3-5 paragraphs)
be written in plain English (no jargon) and easy to understand
use short sentences (around 25 words)
define acronyms and abbreviations the first time they’re used (with Markdown)
explain any technical terms
be shorter than 500 words, if possible

Som du ser i dessa exempel sätts vissa begränsningar på hur man jobbar med innehåll och dess olika mängder. Inte helt olikt en budget. Din innehållsbudget kommer säkerligen att utmanas och ifrågasättas. Gov.uks beslut om att hålla en brödtext till under 500 ord är nog i skottlinjen direkt om de tar in en konsult för lite sökmotoroptimering. SEO-praxis är vid tillfället då denna bok skrivs, att en text ska vara minst trehundra ord - men helst runt tusen. Jag kan tycka att poängen med att ha en innehållsbudget är själva diskussionen om hur man ser på sitt innehåll. Man dokumenterar sin avsikt så att alla idéer kommer till ytan och att det vid behov går att diskutera och revidera dem.

Nu finns det ju alltid konkurrerande synsätt, och olika yrkesgrupper kommer gärna med sina egna fakta, praxis eller underlag in i en diskussion. Innehållsbudgeten är organisationens egna dokumenterade goda praxis i innehållsfrågor, de ska inte förändras godtyckligt. Ett sätt är förstås att ändra sig baserat på egna tester, men innan dess är forskning och extern praxis det bästa man har att gå efter.

Anledningen till att Gov.uk valde att meningar inte ska överstiga tjugofem ord²⁶ är baserat på forskning. Forskning visar att när den genomsnittliga meningslängden är fjorton ord så förstår minst 90% av läsarna vad de läser. Vid fyrtiotre ord per mening sjunker det till under 10%. Studier visar också att vid tjugoen ord per mening börjar en text vara lite halvt komplex att ta till sig. Att välja tjugofem ord per mening som gräns får anses vara rätt generöst, tycker jag, men tippar också på att de flesta inte har någon ambition alls på detta område.

Jobbar du enligt mantrat content first²⁷ så är en innehållsbudget motsvarande vad en designbudget är för de som börjar med designen. Du som undrar hur tusan man följer upp att detta efterlevs får ge dig till tåls, senare i boken kommer du hitta tips om hur du jobbar med innehållsanalys, eller indexanalys som sökfolk ofta kallar det.

Stilguide = kommunikativ stil, mönsterbibliotek och prestandabudget

Vi har redan i denna del av boken gått igenom en del av den dokumenterade ambitionsnivå man kan ha med sin webbnärvaro, men det finns förstås fler saker att sätta på pränt (digitalt).

En organisations stilguide bör, tycker jag, vara ett samlingsnamn för all den dokumentation som rör organisationens kommunikativa stil – i bred bemärkelse. I detta kan massor av olika delar ingå, där få gemensamma nämnare finns. Ofta finns sedan förut tips och riktlinjer kring det språkliga, inte sällan något om typografi i digitala sammanhang, ibland designskisser som talar om exakt hur logotypen och andra designelement ska hanteras för att värna organisationens identitet.

På senare tid har det blivit allt vanligare att även dokumentera en mer teknisk handbok innehållandes kodexempel för webbutveckling, nyckeltal för uppföljning av webbplatsen och prestandabudget för de prioriterade kvalitetskriterierna som valts ut.

Många kommunikativa delar bör nog tas upp. Kanske inte ordval i sig utan snarare hur man får reda på vilket språkbruk som förväntas och att de ord man faktiskt valt har förutsättning att nå fram. Exempelvis att det finns en begränsad plats för hur många ord som visas hos Google, i användarens webbläsare m.m. Stilguiden kan faktisk komma med både piska och morot. Piskan bestående av riktlinjerna som säger vad man får lov att göra, och moroten som är tipsen på hur man gör för att lyckas bra under rådande förutsättningar på webben.

Mönsterbibliotek

: Bild 25: Exempel på stilguide. Intro med tips på hur den används, sedan mönsterbibliotek för återanvändning.

Istället för att designa hela sidor brukar man rekommenderas att designa sina designmönster först, begreppet för detta är Atomic Design²⁸. Du kan ha stött på detta koncept under andra namn, vanligaste synonymen i Sverige är nog komponentbaserad design. Det är lite som vilka byggklossar man behöver i sitt förråd för att kunna bygga något. Dessa kallas allt oftare på svenska för designmönster (på engelska design patterns), och samlingen av designmönster för mönsterbibliotek (eller pattern library).

Exempel på designmönster kan vara hur sökfunktionen ser ut, det vill säga sökfältet, knappen och sånt som är runt omkring. Eller hur en bild ser ut tillsammans med dess bildtext. Detta är användbart, precis som specialiserade Legobitar, när man vill återanvända något i ett annat sammanhang vid ett senare tillfälle. Då är delar av arbetet redan klart. Man behöver inte fundera på hur många bildpunkters radie sökfältets rundade hörn borde ha, det är bara att kopiera det som redan tagits fram.

Om man inte tillsammans med sitt designmönster även bestämt exakt vilken gränssnittskod som ska användas har man bara gjort halva jobbet. Det är inte nödvändigtvis så att koden ska stå i fokus, men om ingen kod ges blir det svårt då alla utvecklare själva måste uppfinna egen kod som får något att se ut och fungera som önskat. Du kan lugnt räkna med att inte alla är lika motiverade till att välja rätt färg, eller se till att det skalar bra på olika stora skärmar, eller ens att det blir tillgängligt nog för att uppfylla diskrimineringslagstiftningen. Det är alltså rekommenderat att kod finns i anslutning till designmönstret och att försöka se till att de används.

Vad är då poängen med att jobba med ett mönsterbibliotek av återanvändbara designmönster? Jo, man skapar en organisatorisk standard för hur saker ser ut och fungerar. Förutom uppenbara vinster kring ens organisations identitet kan denna form av standardisering faktiskt bidra till trygghet hos användarna Ifall någon hamnar på en nätfiskares webbplats får de förhoppningsvis möjligheten att inse att något är på tok, att något i den visuella eller funktionella identiteten är fel. Det är viktigt att ha en tydlig identitet så de trogna användarna inser när något inte riktigt stämmer. Om man inte jobbar med ett mönsterbibliotek så kommer man ha fullt upp med att efterlikna sig själv för att inte själv framstå som en dålig imitatör.

: Bild 26: Prototyp av kliniksök. En kombination av flera designmönster ger snabbt prototyparbete.

Du som är lite vaken har redan börjat tänka på att vissa av dessa delar ingår i något som ibland kallas för en organisations grafiska manual. Skillnaden är att en stilguide tar upp mer än det som handlar om det grafiska. Jag skulle både vilja påstå, och rekommendera, att ens stilguide ersätter ens grafiska manual. Den manualen kan faktiskt ingå i stilguiden, och det man kallar för grafisk manual kan istället kallas för designguide. Kompletterat med de dokumenterade designmönstren har man kommit en bra bit med en stilguide – visuellt åtminstone.

Fördelar med ett mönsterbibliotek (om det används) är åtminstone att det:

Borgar för ett enhetligt utseende. Genom en minskad variation i hur något ser ut blir ens design mer förutsägbar för användarna. Det går att ha koll på ifall en ny design fungerar bättre, samma eller sämre än den variant man kört med tidigare.
Är lättare att förvalta hur respektive designmönster fungerar med de krav man har, inte minst när man vill testa dem. Exempelvis om det kommer ut en ny pryl på marknaden så kan man kolla så alla ens designmönster flyter bra och responsivt även på den nya prylen.
Utvärderar prototyper enklare. När du har standardiserade designmönster att återanvända går det fort att få fram en testbar prototyp. Bara återanvänd det som inte är det nya du ska utvärdera (se prototypen av kliniksök här intill).
Ger högre kvalitet. Om man ser till att hålla hög klass på sina designmönster och att de följer gällande praxis så kan man räkna med att nybyggnationer kommer att hålla en hög kvalitet. Det är alltså viktigt att man har en hög och förutsägbar nivå på det som tas med i mönsterbiblioteket.

En gemensam underton i ovanstående punkter är att det troligen är resurseffektivt på sikt om man ser till att använda sitt mönsterbibliotek. För att lyckas kan det säkert krävas lite uppmuntran från de som styr verksamheten, och en del hårt jobb och intresse från alla inblandade.

Är inte en stilguide samma sak som en kommunikationspolicy?

Det kanske det skulle kunna vara, men det är inte riktigt samma mål. Skillnaden är i hur aktivt användandet är och vilken status respektive dokumentation har inom organisationen. En policy är troligtvis mer avgränsad och full av juridiskt eller byråkratiskt fikonspråk. En stilguide, däremot, kan vara en levande dokumentation med utförliga tips och exempel på hur man går tillväga vid digital kommunikation.

I sin stilguide kan man också ta med fluffigare saker. Som vilka värderingar man har. Eller som Mailchimps stilguide som har dokumenterat det uppmuntrande språk som är en väsentlig del av användarupplevelsen hos dem.

: Bild 27: Mailchimp förklarar sin tonalitet i sin stilguide. Att en del av tjänstens upplevelse kan handla om språkligheter.

En stilguide är med fördel byggd som en liten webbplats där man kan utforska alla delarna, se exempel och hämta hjälp för att följa organisationens praxis kring att utforma något.

För att komma igång med sitt arbete med en stilguide behöver de flesta börja med en inventering av vad som redan finns dokumenterat inom den verksamhet man jobbar inom och hur det kan passa in i denna nya verklighet. Om du inte listat ut det redan är en stilguide något som primärt har ett uppifrån-ner-perspektiv, så om du inte jobbar i toppen av din organisation är det troligen så att du behöver hjälp av kollegor för att etablera er stilguide, eller få tillåtelse att göra en egen, lokal, stilguide.

Många har säkert redan dokumentation kring hur man tilltalar kunder och mottagare. Detta bör man inkludera i sin stilguide och sedan kan man strunta i det dokumentet. Låt stilguiden vara startpunkten för allt som rör kommunikation, design för digitalt och trycksaker, samt guider till hur det hela går till i praktiken och vem man vänder sig till för stöd eller frågor.

Stilguide är som sagt någon form av paraply-begrepp för flera saker. För att börja beskriva det lite mer ”webbiga” som ingår i ens stilguide kan man prata om stilguidens basala element, nämligen:

Hur kolumn- och rutsystemet fungerar för mobiler och datorer.
Standardutseende på vanliga HTML-element. Hur ser exempelvis listor ut, bilder och deras bildtexter?
Typografi kring stycken av text, rubriknivåer, teckensnitt, etc.
Hur man hanterar tabeller, formulär och så vidare.
Designfrågor som färger, utseende på fel- och varningsmeddelanden, osv.
Vilka ikoner använder man till vad och hur placeras de korrekt designmässigt.
Hur bäddas media-filer in.

En stilguide ska föregå med gott exempel kring hur webbkod hanteras. Det är en plats för de som bygger webbplatser att hämta kodsnuttar så det blir rätt, direkt. Har man en väl utbyggd stilguide blir det lättare att bygga en tillfällig mikrosajt för en kampanj, eller om man av någon annan anledning behöver bygga en ny webbplats. Då kan utvecklarna hämta kvalitetstestade komponenter, ramverk och färdiga kodsnuttar, som alla är robust konstruerade och tillgänglighetsgranskade. Det är i alla fall tanken, att man som beställare ska kunna lämna sin stilguide som någon slags referenspunkt för en leverantör att förhålla sig till.

: Bild 28: Stilguide för Bootstrap förklarar hur bilder blir responsiva, och anger vilken kod som ska användas.

Stilguiden bör också förklara vilka ställningstaganden som gjorts kring designval. Bland annat hur pass gamla webbläsare man tänker stödja och eventuella avsteg man kommit fram till. Exempel på sådana avsteg är hur äldre webbläsare utan stöd för media-frågor ska hantera en responsiv verklighet, eller om man valt att använda SVG-formatet för bilder så är det stödet inte jättebra i gamla Internet Explorer. I stilguiden talar man om ifall man tänkt använda något särskilt polyfill²⁹ för att lösa bakåtkompatibiliteten.

Främst handlar denna bok om webben, men självklart kan en stilguide lika gärna inkludera appar, sociala kanaler, etc.

Ärligt talat är det inte heller i webbutvecklares kretsar så att stilguider är något nytt. Men ordvalet har ofta tidigare varit kodmanual eller liknande, dock fortfarande med målet att man ska vara enhetlig med hur man producerar sitt resultat. För en utvecklare är det av högsta vikt hur man namnger saker i kod, detta dels för att det ska vara förklarande för någon annan som senare ska fixa koden, men också för att inte riskera att få krockar mellan saker som blir döpta till samma namn. Vill du nörda ner dig i detta så kolla in boken Code Complete³⁰, om du nu vill ge dig i kast med teknikaliteter som namngivning av variabler för Javascript.

Lite beroende på vem du frågar vad en stilguide är kommer du få lite olika svar. Följer du bloggare inom webbdesign märker du fort att en stilguide faktiskt kan vara många saker. Det jag fick igenom på min arbetsplats när vi gjorde vår stilguide handlar om följande:

Organisationens webbstandard, värderingar och ambition. Exempelvis hur man ser på tillgänglighet, hur kod ska skrivas, med mera.
Ett bibliotek av designmönster för webben och andra digitala kanaler. Har du bytt tema i Wordpress någon gång har du garanterat sett hur de väljer att presentera temat. Du får se saker som typografi, hur bilder visas med mera. Du får koll på hur olika delar av en webbplats kan tänkas se ut.
Prestandabudget, och här ska vi inte ta prestanda bokstavligt. Den engelska termen är performance budget, så möjligen ska vi också inkludera allt som har med prestation att göra.

Jag vill förtydliga att ingen av ovan punkter på något sätt är obligatoriska i en stilguide, man kan göra lite vad man vill av sin egen stilguide. Men för denna boks argumentation kan du räkna med att en stilguide åtminstone avser innehåll, webbdesign och prestandabudget. Ovan punkter var det jag fick gehör för där jag jobbar, ett ställe där väldigt få hade hört talas om en stilguide innan. Vilket kanske kan tas för ett tecken på vilka delar som är begripliga i en större krets av människor som alla jobbar med webben på ett eller annat sätt. Det som inte kom genom nålsögat i stilguidens första version var webbredaktörernas handbok, den ville man gärna ha separat – möjligen för att man inte kan se att stilguiden kommer användas eller vara av intresse längre ut i organisationen.

Stilguiden är nog främst till för innehållsproducenter och kanske de som äger webbplatsen från en ledningsposition. Den ska ta upp det som skapar förutsättningar för att en webbplats ska kunna leverera resultat. Ska man peka ut en ägare till stilguiden i en större organisation så är det nog marknadschefen eller kommunikationschefen som ska bry sig mest. Och de som vårdar stilguidens innehåll är de på motsvarande avdelning, möjligen tillsammans med de som utvecklar webbplatsen.

En stilguide bör inte vara ett dokument man stuvar in i något arkiv. Snarare bör man låta den vara något man jobbar aktivt med. Stilguide kallas ofta för living style guide på engelska. Det är tänkt att vara något levande, något föränderligt. Poängen med ens designmönster (som utgör ens webbdesign) är att de kontinuerligt behöver förbättras för att leva upp till webbens ständigt föränderliga krav och användarnas förväntningar.

Om du behöver hänvisa till en auktoritet för att få lov att jobba med er stilguide så kör med Brad Frost. Hans koncept med Atomic Design har vi nämnt tidigare. Det är ett logiskt komponentbaserat synsätt på webbdesign. Den erbjuder en förklaringsmodell från minsta tänkbara komponent, som en knapp för sök, upp till hur en exempelsida kan se ut.

Exempel på frågeställningar att ta upp

Det finns ett antal frågor att besvara när man sätter sin ambitionsnivå i ett webbprojekt. Lite beroende på vilken yrkesgrupp man tyr sig till kan man kalla denna ambition för olika saker.

Stilguide är kanske närmre innehållsproducentens syn på ambitionsnivå, medan prestandabudget är utvecklarens vinkel (men allt mer av intresse för de som vill konvertera sina användare). Jag föreslår att vi betraktar prestandabudget som en bilaga till stilguiden. Det handlar trots allt om organisationens kommunikativa stil i digitala kanaler och prestandan är i högsta grad en viktig del.

En stilguide innehåller ofta exempel på typografi, design, tilltal med mera, medan en prestandabudget ofta fokuserar på mätbara saker som är kvantifierbara. Sånt som går att analysera och skicka som mätbara krav till leverantörer. Exempelvis hur långt tid som är acceptabelt för att ta emot en webbsida. Tillsammans med den visuella identiteten, organisationens tonalitet i språket hör definitivt en ”teknisk” identitet hemma för att bilda en gemensam upplevelse. Vad man kan förvänta sig från din organisation i digitala sammanhang, mer om det läser du i kommande avsnitt om prestandabudget.

En bonusfrågeställning vi på min arbetsplats fick kring stilguide är bland annat den granskning av integritet inom offentlig sektor, som Dagens Nyheter körde som en serien av artiklar samtidigt som vi tog fram stilguiden hösten 2015. Det blev en diskussion om vilka värderingar vi hade, ifall vår bekvämlighet i val av verktyg och integrationer kunde väga tyngre än användarnas integritet. Frågan uppstod om man i offentlig sektor någonsin ska ha med tredjeparter på sina webbplatser om man inte har koll på eventuella följdverkningar för sina användare. Det kan vara mycket mer än utifall man ska ha Google Analytics. Det gäller ju även hur webbplatser designas, ifall man använder externa teckensnittstjänster, bäddar in Facebook-flödet, sociala dela-knappar, m.m.

Sedan har webbplatsens stil också med användbarhet kring innehållet att göra. Om längden på sidtitlar funkar i alla tänkbara sammanhang, hur man ser på responsiv bildhantering och mycket mer.

Dessa frågor hade vi på min arbetsplats när vi först började arbeta med vår stilguide. Några av frågorna är säkert relevanta även där du jobbar. Ett test på om en fråga är meningsfull att ta med i stilguiden är ”än sen-testet”, alltså att man kan besvara ”Än sen, vem bryr sig?” Man behöver kunna ha en saklig diskussion kring varje punkt man väljer att ta med. För vem den är till för och varför det är viktigt.

Hur ska vår typografi vara för att garantera en bra läsupplevelse på alla plattformar?
Ska vi bädda in tredjepartstjänster som eventuellt hotar användarens integritet?
Längd på sidtitlar. Som längst 60 tecken?
Ska bilder visas i retina-upplösning eller ”vanlig upplösning”?
Tillåta utsmyckande bilder, eller ej?
När är det motiverat att använda tabeller?
Ska alla viktiga sidor ange meta-description och minst ett nyckelord (något vår egen sökmotor behöver för att webbplatssöken ska fungera bra)?
Minst en call-to-action synlig utan skrollning på landningssidor? Synlig för alla sorters prylar som används?

Förvaltning av stilguiden

En utmaning man måste försöka hantera genom arbetet med sin stilguide är hur den ska förvaltas över tid. Precis som att riktlinjer för sociala medier, och andra snabbrörliga ting, kan bli komiskt utdaterade ganska snabbt gäller det att stilguiden inte blir något man stoppar i skrivbordslådan och tittar på vartannat år. Även fast jag tycker att en person ska utses som stilguidens förvaltare så bör stilguiden vara allas angelägenhet. I alla fall de som jobbar med någon form av kommunikation eller utveckling i digitala kanaler.

Ett sätt att inte låta stilguiden samla damm är att stoppa in handledning, exempel, tips och annat som gör att berörda tittar in i stilguiden lite oftare. Sen bör nog den som är utpekad förvaltare varje kvartal kolla igenom allt material, mest för säkerhets skull.

Ett tydligt exempel på något som pockar på uppmärksamhet lite löpande är de designmönster man stoppar in i stilguidens mönsterbibliotek. Efterfrågan på nya designmönster måste vägas mot återanvändning av de befintliga, annars blir det lätt vildvuxet rent visuellt kring organisationens identitet.

Mönsterbibliotek ger tydligare krav på leverantörerna

Som leverantör kan en stilguide göra det lättare att förstå vilka förväntningar som finns. Samt att man inte behöver återuppfinna saker som vilket responsivt beteende man kört med sedan tidigare och annat som rimligen borde kunna standardiseras inom den organisation som skapat stilguiden. Detta borgar också för en konsekvent upplevelse mellan olika webbplatser från samma organisation.

: Bild 29: Webbramverket Bootstraps stilguide är också dess dokumentation.

En otroligt frekvent använt (och bespottat) standardiserande ramverk för webben är Bootstrap. Deras dokumentation är precis vad man skulle kunna betrakta som en stilguide. Där kan man ta del av exakt hur kod ska utformas för att leva upp till designkonventionen mobile first. Hur formulär både ser ut och ska kodas, och allt annat som har med gränssnittskod som HTML, Javascript och CSS att göra.

Anledningen till att Bootstrap är bespottat är att dess enorma genomslag gjort att väldigt många webbplatser ser snarlika ut. Visst, det är kanske inte en designers dröm att tvingas förhålla sig till ett utseende som är gemensamt för alla möjliga organisationer. Men denna konsekventa design är ju precis vad vi är ute efter när avsändaren är en och samma organisation.

Mest grundläggande i ens mönsterbibliotek är hur de vanligaste designelementen ser ut och reagerar responsivt, exempelvis hur sidhuvudet svarar på de olika stora skärmar användarna kan tänkas använda. Detta är en av de största poängerna med en stilguide och dess mönsterbibliotek. Att man dels kan testa hur det fungerar idag men också vara den plats där man i sin aktiva förvaltning av stilguiden kan utveckla nya designmönster och se till att de håller måttet.

Det är kanske inte rimligt att tro att man kommer ta sig tiden till att köra varenda litet designbeslut genom denna process och få det dokumenterad. Dessutom tar det nog en ganska stor investering i tid och pengar att komma till en bra nivå. När jag under våren 2015 sonderade marknaden för att beställa detta till min arbetsgivare var det tydligt att ingen av de leverantörerna jag pratade med tyckte det var lönt att lägga mindre än 200 timmar på ett sådant uppdrag. Deras tid alltså, då som experter på webbdesign och gränssnittsprogrammering. Jag föreställer mig att vi som beställare nog skulle fått lägga minst lika mycket tid själva. För de timmarna skulle man få de mest vanliga designkomponenterna in i sin stilguides del med mönsterbibliotek. Alltså följande delar av en webbplats:

Övergripande responsivitet, rutsystem och yttre ramar för utseendet.
Grundläggande typografi.
Sidhuvud, dess delar som logotyp, sökfält och huvudnavigering.
Några få komponenter som är inom en sidas unika innehåll. Antagligen kan man välja att få sin startsida välgjord, samt ett exempel på undersida som är tyngre på text.
Sidfot, med dess kontaktuppgifter med mera.

Det finns ingen egentlig bortre gräns för vad som ska stoppas in i mönsterbiblioteket. För att prioritera och börja ta sig an detta arbete är Atomic design till hjälp. Att man tittar på de minsta beståndsdelarna och i vilka kombinationer de kan förekomma på en webbplats.

Några exempel på sådana atomiska designmönster kan vara:

Bildkaruseller (denna styggelse till kompromiss för att få tyst på alla de som kräver att just deras innehåll ska finnas på startsidan).
Presentation av kalenderhändelser och evenemang. Kan vara dels i kompakt listform med också hur den sidmallen ser ut.
Sökordsförslag som dyker upp när någon börjat skriva in sökord i ett sökfält.
Megameny. Du vet de där stora utfällbara menyerna som kan innehålla flera kolumner med listor av undersidor, relaterat innehåll m.m.
Kartfunktioner och inbäddade videoklipp.
Lite mer komplicerade formulär, visualiseringar och tabeller, som kan innehålla finesser som filtrering och sortering.

När ett mönsterbibliotek finns kan man kombinera dessa designkomponenter till kompletta exempelsidor. Då blir det enklare att få en känsla för utseendet.

: Bild 30: Code for Americas stilguide visar exempel på hur en sida kan se ut, med några utvalda designmönster.

Det man i anslutning till mönsterbiblioteket behöver dokumentera är hur det går till att få med ett nytt designmönster. Vilka krav de ska leva upp till, hur de ska testas med mera. Förhoppningsvis uppenbara krav är att det ska vara tillgänglighetstestat, validera vald kodstandard och vara kompatibel med mönsterbiblioteket i stort. Det som ingår i ens stilguide ska vara organisationen bästa praxis för digital kommunikation, så det gäller att lägga ribban högt.

: Bild 31: Starbucks stilguide visar designmönstret för hur varningsmeddelanden ska se ut.

Ett exempel på scenario kring detta, som jag själv jobbat på, är att vi prototyp-byggde en liten sökfunktion direkt i stilguiden. Alternativet vore att göra som vanligt, typ skicka en lång lista med krav till våra webbutvecklare och så hade de byggt en prototyp direkt i vårt publiceringssystem. Istället kopplade vi in en expert på webbdesign och utökade vår stilguide. Det gjorde att vi kunde lämna över något mycket konkret till webbutvecklarna (vars främsta styrka kanske inte är konceptuell design) att bygga in i vårt CMS. Med andra ord hade vi redan rett ut exakt hur det skulle se ut, fungera i olika sorters prylar, exakt hur gränssnittskoden behövde vara, gjort användbarhetstester på livs levande användare, samt testat tillgängligheten. Så uppdraget till våra webbkunniga systemutvecklare blev väldigt konkret – ”gör precis så som det framgår i stilguiden, få det att fungera i vår webbplats”. På detta sätt gör alla det de är bäst på.

Browsing should be as simple and fast as turning a page in a magazine.
- Larry Page, grundare av Google

Prestandabudget, tekniska värderingar och kvalitetsriktlinjer

Tidigare jobbade jag som webbkonsult. Min största förebild i hur man agerar som en konsult (och som ledare i stort) är David Maister, tidigare professor vid Harvard Business School. Han har skrivit den utmärkta boken Managing The Professional Service Firm³¹. Han konstaterar ofta det uppenbara man ännu inte själv lyckats sätta fingret på.

En sak som han tar upp är ytterst relevant till prestanda, nämligen hur en tjänst eller vara upplevs av sin användare. Det hela är ju hyggligt subjektivt då var och en har olika förväntan på förhand. Han föreslog en formel som jag kanske vanskapt något i min översättning, nämligen:

Nöjdhet = Upplevelsen – Förväntan.

Så som jag agerade på detta, som konsult, var att alltid försöka överleverera lite grand. Det skulle alltid bli lite bättre än förväntat. Ge det lilla extra (förkortat DLX). Det skojades friskt om vad DLX skulle vara i ett specifikt projekt, men att det var viktigt var vi alla överens om. Utvecklare började plötsligen prata om våra kunders upplevelse av våra leveranser. Det var en bra grej.

Underpromising – overdelivering.

Om du kan påverka förväntan så blir inte upplevelsen i sig lika avgörande, men om förväntan är skyhög blir det nästan omöjligt att göra ett bra jobb oavsett insats. Det är här en prestandabudget kommer in – tidigt i processen! Om alla designbeslut redan tagits, hela klabbet är byggt och man kommer fram till att resultatet blev alldeles för långsamt, ja, hur troligt är det att man kan lösa det i efterhand? Det går säkert, men det blir definitivt dyrare att försöka fixa något som redan är trasigt. Smartare vore att tänka till från början.

Vilken nivå ska du välja? Gör lite efterforskning om på vilken nivå som dina konkurrenter eller motsvarande organisationer håller, och så ser du till att överträffa dem lite lagom. Något nybyggt ska väl rimligen vara bättre än det som redan är etablerat?

Att stödja något behöver inte innebära en vilja att optimera

I forntiden såg vi ofta texter som ”Denna webbplats fungerar bäst i Netscape 4.0 med en skärmupplösning på 1024x768 bildpunkter på en 17”-skärm”.

Vilka krav tänker du ställa på dina användare och den utrustning de väljer? Det är värt att komma ihåg att bara för att man tänker stödja en viss utrustning, webbläsare, eller pryl, betyder inte det automatiskt att man tänker lägga manken till och optimera den upplevelsen. Se stödjandet som att något ska vara möjligt att använda, men sedan finns det andra fall där man anser att det är värt att jobba med optimering. I prestandabudgeten dokumenterar du denna lägstanivå.

En designprincip som vi i gamla gardet av webbutvecklare levt efter, och som är en del av konceptet att följa webbstandard, det brukar kallas för progressive enhancements. Det innebär att en god grundfunktion ska erbjudas till alla och om det fortfarande finns engagemang kvar så kan man börja optimera för de användare som är viktigast för en, eller har en viss utrustning som kan behöva lite mer omsorg för att det ska fungera optimalt.

Prestandabudgeten får som sagt mer än gärna infogas i organisationens stilguide. Främst är prestandabudgeten riktad till utvecklare. Alla andra ska slippa snacka teknik, men den kan också fungera bra som ett klargörande om organisationens förväntan på sina leverantörer. Sträva efter att prestandabudgeten ska ge svar på tal nog att icke-utvecklare ska kunna ställa motfrågan ”lever det upp till prestandabudgeten?” vid varje teknisk frågeställning. Man kan inte förvänta sig att alla har anledning att känna till alla beståndsdelarna av prestandabudgeten.

Detta dokument kan ses som en riktlinje kring webbplatsens kvalitet och lägsta acceptabla nivå in om en mängd områden man specificerar, exempelvis tillgänglighet. Prestandabudgeten får gärna lanseras på ett högtidligt sätt så att alla inblandade förstår att från och med nu har man en mätbar verklighet att förhålla sig till. Att den gäller såväl webbutvecklarna, IT, redaktörerna och alla andra som påverkar webbplatsen. Personligen tycker jag att man dessutom bör göra den publikt tillgänglig på webben, då blir den ännu svårare att ignorera eller glömma bort.

Du kanske undrar vad poängen är med en prestandabudget? Din prestandabudget är ditt sätt att klargöra organisationens servicenivå i digitala kanaler, men också de mätpunkter som du kontrollerar när du gör din återkommande innehållsrevision. Som att sidtitlar är lagom långa, etc.

Om du undrar ifall webbprestanda egentligen spelar någon roll kommer du snart få bevis i överflöd. Men om vi för stunden nöjer oss med det ytterst objektiva och kvantitativa sättet att se på saken så kan jag hänvisa till en undersökning som Walmart gjort. De har hittat ett mycket tydligt samband mellan laddningstiden för en webbsida och hur bra de användarna konverterar, det vill säga att användarna gör något önskvärt på webbplatsen.

: Bild 32: Walmart har hittat ett samband mellan prestanda och konvertering.

Det är alltid värt att påminna sig om att med prestanda ska man också tänka in ordet prestation, i stort, det handlar inte bara om hastighet.

Exempel på en prestandabudget

Nedan kan du se de punkter vi valde ut på min arbetsplats för vår första prestandabudget³², som jag tog fram för Västra Götalandsregionen 2015.

Början på citat.

Prestandabudget och mätbar webbkvalitet för www.vgregion.se

Detta är inledande dokumentation och överenskommelse kring projektet för uppgradering till Episerver CMS samt det nya gränssnittet.

Läs nedan krav som att de mäts med representativt innehåll på testsidor utvecklarna tar fram inför avstämning med projektets utsedda webbanalytiker. Dessa testsidor ska inte kunna påverkas nämnvärt av VGR:s redaktörer mellan testtillfällena, de ska vara jämförbara över tid.

En leverans som misslyckas med dessa krav ska inte sättas i produktion och ska inte accepteras av VGR.

1. Värderingar, prioriteringar och prestation för hela webbplatsen

Följa designkonventionerna progressive enhancement samt mobile first, det vill säga fokusera på tillgänglighet först och finess sen, samt att det är det mobila scenariot som sätter behoven kring design och funktion.
Funktion före form, och upplevelsen framför teknikaliteter. Det vill säga inkluderande design, både för funktionsnedsattas möjlighet att delta men också för att nå så många sorters utrustning som möjligt.

2. Mätbar prestandabudget

Max 399kb för en sidvisning.
Under 3 sekunder för komplett laddning av sida, mätt från gynnsam trådad uppkoppling.
Under 10 sekunder för komplett laddning av sida mätt på 3G-uppkoppling.

3. Lägstanivå på webb

Dessa punkter beskriver den lägsta accepterade nivå för första iterationen av www.vgregion.se, den nivån får inte försämras under kommande uppdateringar, snarare ska dessa krav skärpas till löpande i samråd med utvecklarna.

Alla mallar/vyer/komponenter i webbplatsen skall som allra minst:

Vara testade och säkrade mot WCAG 2 nivå AA.
Anses vara mobilvänliga enligt Googles mobilvänlighetstest.
Med exempelinnehåll uppvisa minst 85 av 100 i Google Pagespeed med mobila inställningar, och minst 90 för dator.
Max 2 CSS-filer laddas in.
Max 3 Javascript-filer laddas in.
Använda CSS Sprites (eller motsvarande teknik) för att minska antalet bildfiler att ladda ner.
Strukturell CSS-kod inkluderas i HTML-koden enligt god prestanda-praxis för snabb initial visning av innehållet.

Slut citat.

Ja, detta var vad vi innan projektet kom överens om internt och även tillsammans med våra webbkonsulter. Du kanske undrar hur det gick? Jo, den första versionen av prestandabudget jag jobbat igenom på min arbetsplats har vi ställt det absoluta kravet om att följa tillgänglighetsriktlinjen WCAG 2.0 som minst på nivå AA. Det borde inte direkt vara kontroversiellt med tanke på att bristfällig tillgänglighet sedan 2015 anses vara diskriminering enligt lag och sedan 2016 är något som EU beslutat om som tvingande för alla myndigheter - då inkluderande intranät och extranät.

Dessutom några mål för hur snabbt det ska gå att ladda ner en sida. Där blev det väl ett plötsligt uppvaknande i designarbetet för vår kommande webbplats att man inte kan slösa hur man vill med utsmyckande element. Vi har satt gränsen vid 399 Kb och då bör redaktören ha åtminstone 140 Kb till att kunna lägga upp en tyngre bild.

En punkt som fick stryka på foten i första versionen av prestandabudgeten var en värdering om att ”Värna om besökarnas integritet. Inga som helst tredjepartstjänster, exempelvis Google Analytics, sociala dela-knappar, etc.” Den frågan behövde hanteras separat. Men värderingen som sådan kring integritet fanns ändå kvar i andra dokument, bland annat i IT-säkerhetspolicyn.

: Bild 33: Grafen från Pingdom visar att en driftsättning av ny kod i mitten av mars gjorde webbplatsen i snitt 0,3 sekunder långsammare.

Vi började mäta redan under utvecklingsfasen. Ett intressant fynd var att en uppdatering av den blivande webbplatsen gjorde den i snitt 0,3 sekunder långsammare enligt Pingdoms verktyg för att mäta svarstid. Jag tycker det är ett fynd på grund av att man nu kan prata siffror istället för subjektiv magkänsla. På detta sätt har man möjlighet att väga för- och nackdelar, ifall de nyheter som introducerades faktiskt är värda 0,3 sekunder långsammare svarstid. Det kanske de är, men man kan inte lägga på 0,3 sekunder i extra svarstid på varenda uppdatering. Förr eller senare kommer man slå i taket för den sidladdningstid man satt upp i prestandabudgeten. Genom att ha lång historik av data kan man ha ett bättre underlag än annars till vad man tror sig behöva åtgärda för att inte konstant försämra situationen.

I vårt fall räknar jag kallt med att vi kan kasta pengar på problemet och köpa mer hårdvara, men samtidigt hade vi en storskalig cache-lösning på gång som IT-avdelningen var uppspelta kring. Den ska som allra sämst halvera tiden för att visa upp sidorna.

Men det finns förstås massor med andra frågeställningar där man kan ha nytta av att på förhand specificera sin ambition kring prestanda och prestation. Självklart ska en webbplats av idag anses vara mobilvänlig. I det finns många saker man behöver mäta, både designen i stort men också det som hamnar på webbplatsen. Vi har preciserat detta till dels att Googles testverktyg ska anse att alla typer av mallar i vårt publiceringsverktyg är mobilvänliga, med någon form av exempelinnehåll. Detta är kravet på de som bygger vår webb. Sedan blir det till att följa upp att redaktörerna inte sumpar den upplevelsen genom att lägga in jättebreda tabeller och så vidare.

Kontinuerligt mäta kvaliteten på webbsidan

För att vara tydliga och förutsägbara gentemot våra leverantörer har vi gemensamt satt upp testsidor. Dessa testsidor ska ha som minst 85 av 100 i betyg enligt verktyget Google Pagespeed, då med mobila inställningar. För en dator ska det vara minst 90 av 100 i betyg. Dessa siffror bör de kolla redan innan de driftsätter något nytt. Det är inte acceptabelt att något försämrar betyget. Åtminstone ska inget som inte motiverats få lov att försämra betyget.

Anledningen till att det är just 85 av 100 är för att Google satt det som den nivå när de tycker webbplatsen är välkonstruerad. Vi vill gärna leva upp till denna nivå då det inte är helt oväsentligt vad Google anser om ens webbplats om man vill ha besökare från deras sökmotor.

Vi har också satt begränsning på antalet filer som krävs för att ladda in en sida. Anledningen till detta är för att för varje fil som ska laddas ner finns en väntetid, ju fler filer desto längre blir den totala väntan på att sidan blir färdig. Detta är inte ett särskilt stort problem under gynnsamma förhållanden när vi sitter på kontoret, men det märks verkligen skillnad när man är på en svajig 3G eller Edge-uppkoppling ute i glesbygd. Jag som plockar hur mycket svamp som helst märker detta när jag tar en paus och slösurfar lite. Tänk då om man har ett viktigare ärende än att läsa en artikel på The Verge. Typ ta reda på numret till giftinformationsupplysningen, eller göra en bildsökning för vilka svampar man inte ska smaka på?

Plocka inte våra siffror och krav rakt av för användning på hemmaplan. Ta den dialogen med er leverantör om vad som är en rimlig ambition på den plattform ni har. Kanske ska ni lägga manken till vid nästa lite större ingrepp på webbplatsen snarare än att putsa på det som snart ska göras om.

Poängen med att upprätta en lista över prestandakrav till sin stilguide är att ha något mätbart sätt att säkerställa att ens webbplats inte försämras över tid, eller efter lansering. Snarare att den kontinuerligt förbättras för varje uppdatering.

En lista som denna prestandabudget kan komplettera de testprotokoll som webbutvecklarna har, åtminstone för större webbplatser, för att verifiera att ett webbprojekt håller rätt kvalitet. Dessutom har många av oss checklistor för det kommunikativa, det vill säga hur tilltalet ska vara och vilka skrivregler man ska följa, vilket innebär att detta blir en naturlig del av den kontinuerliga uppföljningen och reflektionen om hur det går för webbplatsen. Om det inte finns en utsedd webbanalytiker är det troligtvis en webbutvecklare man behöver för att sammanställa rapporten om hur webbplatsen presterar, eller om man bara väljer verktyg likt Pingdom som de flesta klarar av själva. Vi kommer prata mer om specifika verktyg i nästa del av boken.

Om du driver en större webbplats är det en bra idé att intressera dig lite för vilka tester utvecklarna har för att försäkra dig om att rätt kvalitet uppnås. Dessa tester kan vara allt från helt manuella till fullständigt automatiserade. Vissa av punkterna i din prestandabudget påverkas nämligen av det arbetsflöde som webbutvecklarna har och vissa av punkterna är enkelt att lösa genom konfiguration av byggservrar. Likt Jenkins, eller andra verktyg, som många använder för kontinuerlig leverans då många produktionssätter uppdateringar till webbplatsen - upp till flera gånger om dagen.

: Bild 34: Allt fler ‘deployar’ uppdateringar av sina webbsystem dagligen.

Men varför är prestanda så jäkla viktigt?

Det finns många som har forskat i prestanda (här läst som i hastighet, inte nödvändigtvis som i prestation). Främst brukar man hänvisa till Nielsen-Norman Group³³ som delat upp det i tre delar, nämligen att användaren vid:

0,1 sekunders svarstid slutar uppleva att svaret är omedelbart.
1 sekunds svarstid börjar tankeflödet hindras av en upplevd väntan.
10 sekunders svarstid har användaren svårt att vara uppmärksam och vill göra något annat under tiden.

Med andra ord orsakar man en kognitiv börda hos alla användare som har en långsam upplevelse. Och som Walmart visat så är en långsam upplevelse mindre nyttig genom att användarna i mindre utsträckning konverterar. Fler bevis för sambandet mellan hastighet och nytta kommer strax.

När Google gjorde ett omtag för sitt inte direkt världsomvälvande sociala nätverk Google+ under hösten 2015 så satte de en hård prestandabudget.

We hit our goal of never downloading more than 60k of HTML, 60k of JavaScript and 60k of CSS at any one time!
- Googles Developer sidor³⁴

Google+ gick från att ha haft 22,6 Mb tyngd på sin startsida till 0,3 Mb (HTML och bilder). Från 251 filer som behövde laddas ner till endast 45 stycken. 2,77 Mb Javascript och CSS till 0,11 Mb. För laddtider så gick de från 12 sekunder i snitt ner till 3 sekunder. Dessutom trimmade de bort fettet genom att gå från 0,7 sekunder för användaren att börja ta emot filer ner till endast 0,1 sekunder, så kallad time to first byte (TTFB).

Speed is irrelevant if you are going in the wrong direction.
- Mahatma Gandhi

Som om inte det var nog så finns det gott om studier som visar på sambandet mellan prestanda och hur nyttig användarens session varit. Dessa organisationer som delat med sig om vad som hänt med deras tjänster när de bättrat på hastigheten. Se prestandareferenser i slutet av boken, exempelvis:

Google: 2% långsammare = 2% färre sökningar per användare
Yahoo: 400 millisekunder snabbare = 9% mer trafik
AOL: Snabbare sidor = fler sidvisningar
Amazon: 0,1 sekunder snabbare = 1% mer omsättning
Shopzilla: 5 sekunder snabbare = 25% fler sidvisningar, 7 till 12% mer omsättning
Aberdeen Group: 1 sekund långsammare = 11% färre sidvisningar, 7% färre konverteringar.
Gomez: 75 % av användarna i webbshoppar lämnade hellre webbplatsen för en konkurrent än att tålmodigt vänta.
Tagman: För varje sekunds långsammare laddningstid tappar man 6,7 % konvertering, intressant nog konverterar 1-2 sekunders laddtid bäst, inte de snabbaste (se graf nedan).
Etsy: 160 Kb med bilder ökade avvisningsfrekvensen med 12 %.

Som grädde på moset har Google med webbprestanda i sin rankningsalgoritm, så vill du inte halka efter i sökresultaten kanske även det är en morot till att kämpa lite extra med prestandan.

: Bild 35: Tagman mäter konverteringsnivå baserat på hur lång laddningstiden är.

För den som hellre läser akademiska rapporter så kolla in referenserna i slutet på boken för att finna exempel ända sedan 1960-talet fram till idag. Där hittar du även länkar till ovan fakta, det finns mer intressant att hämta i de skrivelserna.

Vilka tidiga lärdomar finns från Västra Götalandsregionens arbete?

På min arbetsplats har vi genomfört vårt första projekt som behövt förhålla sig till en prestandabudget, nämligen vår uppgradering av Episerver CMS. Det är ett rätt omfattande och komplext projekt. Det finns massor av intressenter högt och lågt i organisationen eftersom det som tas fram är en gemensam grundstomme för alla olika förvaltningar inom denna mycket stora organisation med många vitt skilda verksamhetsinriktningar. Den gemensamma webbmallen ska utgöra grundstommen till ett tiotal ganska stora webbplatser för våra olika sjukhusgrupper, primärvården, tandvården och några kulturwebbplatser.

Nu är jag förstås något partisk, men jag upplever att kollegor och konsulter efter ett tag börjat uppskatta den konkretisering som prestandabudgeten bidragit till i vissa frågor. Våra webbkonsulter har till och med uttryckt att de är entusiastiska kring detta. Det gläder mig enormt.

1. ”Nu kör vi med det här unika teckensnittet, det gör det hela snyggare”

En annan nyttig konkretisering kring design fick vi när frågan om särskilda teckensnitt var i linje med vår prestandabudget. Värderingarna kring integritet spetsade till diskussionen kring egna teckensnitt på ett givande sätt, utöver det som hade med prestanda att göra. Det visade sig att utöver en årlig prenumerationskostnad för att ha ett eget teckensnitt enbart för rubriker behövde vi inkludera en extern CSS-fil för att låta säljaren av teckensnittet att ha koll på hur många sidvisningar vi har. Fördelen med detta teckensnitt var uppenbar, att det såg bra ut. Nackdelarna blev tack vare prestandabudgeten även de tydliga och kunde stå som motvikt i vårt interna resonemang, nämligen att:

Vi var tvungna att ha en tredjeparts fil med på alla våra sidvisningar. Det äventyrar integriteten att man inte vet vem mer som lyssnar in i den kommunikationen. Är man ortodox kring cookie-lagen så får vi inte lov att använda tredjeparter på detta sätt, åtminstone inte utan ett aktivt samtycke från varje användare, detta innan teckensnittet laddas hem och appliceras.
En extra fil behövde laddas hem, utan någon direkt vinst för våra användare. Vi hade satt 2 stycken CSS-filer som gräns, skulle vi då släppa en av de två enbart för att en extern part ville övervaka att vi inte övertrasserade antalet sidvisningar vi köpt för ett teckensnitt?
För att täcka in de olika varianterna av teckensnitt, som kursiv, fet, etc., behövdes upp till 4 stycken filer laddas ner till användarna. Under mindre gynnsamma förhållanden kan dessa filer ta några sekunder bara i ren väntetid oavsett hur små de är. Med andra ord kunde man bara med dessa filer spräcka budgetens tänkta maximala tid för nedladdning.
Teckensnittsfilerna skulle totalt väga in på cirka 80 Kb. Totalt för en hel sidvisning hade vi satt en gräns på 399 Kb. I de flesta sidvisningar skulle detta udda teckensnitt visats på 2-3 rubriker på en hel sida. Var det då värt det att 20 % av den totala tyngden skulle gå åt till detta? Fanns det andra teckensnitt som fick jobbet gjort fast med mindre påverkan?

Så frågan blev rätt tydlig. Var det värt det för att ha ett udda teckensnitt? Inledningsvis blev svaret ett rungande nej. Georgia fick duga, det fanns trots allt redan hos praktiskt taget varenda en av våra användare i deras prylar, helt utan de nackdelar som i och med prestandabudgeten blev så uppenbara för de inblandade. Med andra ord blev det inte enbart en fråga om design, typografi och ifall kostnaden var ok. Diskussionen fick högst påtaglig konsekvens gentemot prestandabudgeten. I en framtida värld om praxis ändras kring hur vi hanterar besökarnas integritet är det inte givet att tredjepartsinblandningen ens skulle tillåtas.

Svaret på frågan var att åtminstone tills vidare låta bli udda teckensnitt. Hittar vi en lösning som har mindre inverkan på prestandan så kanske beslutet blir annorlunda.

2. Sidhuvudsbakgrund vs kontrastförhållande

Högst grundläggande för god tillgänglighet är att man har ett kontrastförhållande mellan förgrund och bakgrund. Det märker man inte minst själv när man försöker använda sin mobiltelefonen i starkt solljus utomhus.

Anledningen att det kan vara svårt att leva upp till god kontrast mellan text och bakgrund på en responsiv webbplats beror på att saker inte är fixerade i sin position. De liksom flyttar runt lite beroende på vilket utrymme som finns till godo. Så i vårt första designförslag hade vi inte kommit fram till en lösning som inte påverkade de med nedsatt syn negativt, därmed blev det inte någon bakgrundsbild. Här kom vi också lite i konflikt med den grafiska manualen då den krävde denna bakgrundsbild, något som inte är ett problem med trycksaker genom deras fixerade layout då man vet exakt var saker är placerade. Detta blev en nyttig övning i att diskutera design och kanske pekade på behovet av en mer digital syn i den grafiska manualen.

Att kombinera bakgrundsbilder i ett responsivt sidhuvud och garantera god kontrast visade sig vara en svår nöt att knäcka. Eftersom vi inte kände oss övertygade om att detta kunde bli både snyggt och tillgängligt försvann sidhuvudets bakgrundsbild med hänvisning till efterlevnad av tillgänglighetsriktlinjen WCAG.

De här subtila nyansskillnaderna som många designer ofta är väldigt beroende av fungerar inte så bra längre i en mobil verklighet. Samtidigt har de aldrig fungerat särskilt bra för de med nedsatt syn, först nu upptäcker även vi andra det.

En relaterad anekdot var när en art director skulle visa upp det han designat åt oss. Då nyanserna helt försvann så som projektorn visade det beklagade han sig och förklarade att det var snyggare på hans skärm. Det hjälps inte. Vi kan inte förvänta oss att alla användare har en tokdyr Ultra-HD-skärm som är färgkalibrerad och har perfekta kontraster. Folk kollar in våra webbplatser på sin halvt misshandlade mobiltelefon, utomhus mitt på dagen på midsommar i starkt solsken. Det är bara att vi vänjer oss, dåtiden kommer inte tillbaka.

3. Hur hämta in externa nyhetskällor?

Jag har många gånger irriterat utbrustit "hur svårt kan det vara?" när något känts självklart och simpelt. En sådan fråga som tycks vara simpelt löst framstod lite i annan dager på grund av prestandabudgetens mål om sidladdningstid.

Det finns nämligen ett behov att samla ihop en eller flera externa nyhetskällor (via tekniken RSS) och visa upp dem som en nyhetsspalt på sin egen webbplats. Det slitna uttrycket att ingen kedja är starkare än den svagaste länken är tydlig när man blandar in flera parter för att kunna visa upp sin webbsida. Exempelvis, hur hanterar man om någon av de där externa nyhetskällorna inte är uppe, eller svarar först efter 10 sekunder? Sånt händer. Inte minst under en samhällskris kan dessa problem börja visa upp sig men det räcker ju med att antingen din eller deras webbplatser får en ökad belastning för att din webbplats ska gå ner.

Om webbplatsen ska visa upp sig på under 3 sekunder så är det bara att börja addera ihop svarstiderna på det antal externa källor man gör sig beroende av. Det finns nog ingen anledning att vara säker på att alla tillsammans garanterat svarar på mindre än 3 sekunder, och då har man ändå spenderat nästan hela sin budget för sidinladdning bara på denna funktion.

Vi har inte kommit fram till en klockren lösning ännu som är en lagom stor utgift. Ett alternativ som IT utredde är om man kan använda någon teknisk lösning som part mellan webbplatserna och de nyhetskällor som ska bevakas. Då kan man exempelvis försöka isolera väntan och felhantering till en programvara som är bra på den uppgiften, eller åtminstone bättre än vårt CMS.

Genom att införa en mellanpart för just detta problem kanske man får en mer sann kostnadsuppskattning, så inte resten av webbplatsen får bära den kostnaden. Den specialiserade lösningen kanske designas för att vänta maximalt 0,2 sekunder på att få svar från de externa källorna. Och får man en isolerad prislapp för just denna funktion så kanske man kommer fram till att nyheter är så viktigt att det är värt det.

Hur få acceptans för ett prestandaarbete?

Det finns nog många utmaningar med att sälja in behovet av ett prestandaarbete, särskilt om dem det berör inte har en kultur av mätbarhet. Jag själv har stött på en del motstånd, tveksamma kollegor och deltagare på konferenser där jag föreläst om ämnet. Det är sunt att vara skeptisk, även till detta. Men jag tänkte komma med lite tips på vilka bevekelsegrunder jag tror du kan hitta hos de du behöver påverka.

En webbutvecklande vän, på en ej inblandad webbyrå, kommenterade varför han skulle gilla att leverera i enlighet med en prestandabudget så här:

När någon ställer krav betyder det att de bryr sig och värnar om resultatet.
- Filip Dalväg³⁵, frontend-utvecklare på webbyrån Netrelations

Jag tror att många utvecklare håller med Filip, i alla fall så fort de förstått vad det handlar om. Praktiskt taget alla vill göra ett så bra jobb som möjligt och det här är en måttstock för gott arbete som utvecklare har lätt att ta till sig, det är ju skrivet mestadels på deras språk. Sedan är det absolut inte så att det skulle finnas en samsyn kring exakt vad som är god praxis om man frågar två olika utvecklare. Många val är sådant som är en bedömning om vad man tror ger mest nytta och det är lätt att landa i nästintill religiösa diskussioner om rätt och fel i hur man anser att hantverket ska göras.

Poängen med att ta denna diskussion bland utvecklarna, eller med sin byrå, är att försöka nå en samsyn om vad som är gott, och sedan dokumenterar man det som utvecklarnas förslag till prestandabudget.

För alla som är inblandade i utvecklandet eller förvaltandet av en webbplats kan man behöva se till att följande aktiviteters görs, möjligen i denna ordning:

Evangelisera budskapet om att man som grupp kan göra ännu bättre ifrån sig, och visa på referenser om vilken skillnad prestanda kan ha för att webbplatsen ska bidra med ännu mer värde till verksamheten. Glöm för gud skull inte fikat så folk håller sig vakna! :)
Ordna med föreläsningar, lunchträffar med diskussioner och utbilda folk i ämnet.
Workshoppa fram ett första förslag till prestandabudget. Deltagare behöver vara de som kan drift, utveckling, design och de som följer upp verksamhetens nytta med webbplatsen.
Kommunicera ut prestandabudgeten! Om inte alla berörda känner till den kommer inte mycket hända. Se till att alla av webbplatsens ”från ax till limpa” känner till prestandabudgeten och ha fått tillfälle att uttrycka eventuella tveksamheter till hur den är utformad.
Se till att det finns verktyg för kontinuerlig uppföljning, det är något vi som jobbar specifikt med webbanalys behöver göra oavsett om vi har kommit igång med att aktivt förbättra prestandan. I mitt fall, som förvaltare av vår prestandabudget, planerar jag att kolla vår efterlevnad en gång per kvartal, men många prestandabudgetar kommer säkert utformas så uppföljning kan ske automatiskt hela tiden.
Ge uppmärksamhet till de personer och team som lyckas förbättra prestandan på webbplatsen. Som konsult brukade jag själv ofta uppmärksamma mitt teams framgångar med att köpa smörgåstårta och tillägna firandet till den som gjort en insats som imponerat på mig.
Häng med i utvecklingen. Vad som är praxis inom webben ändras fort, och med den även vad man gör för god prestanda. En fråga är hur en övergång till HTTP/2 påverkar den prestandaoptimering som gjorts. Mer om detta i del 4 av boken.
Kommunicera ändringar. Prestandabudgeten kommer att behöva förvaltas och uppdateras. Jag själv har planerat att årligen se över den vi har på min arbetsplats.

På min arbetsplats gjorde jag allt ovan själv. Som före detta webbutvecklare kanske jag hade det lite lättare än många andra webbanalytiker att ta in alla detaljer om prestandaoptimering, men främst gjorde mina tidigare erfarenheter det enklare att kunna försvara och motivera vissa vägval. Det tog några månader, sedan började våra webbkonsulter läxa upp mig om nya saker de lärt sig. Som roundtrips över nätet, då allt sänds i 14 Kb-stora paket, samt att de hade förslag på hur vi kunde göra ett ännu bättre jobb. På något sätt tändes tävlingsinstinkten om hur de kunde överprestera. Sånt gillar jag.

För att få med sig beslutsfattare om att detta är värt att lägga lite ansträngning på så kan det vara framgångsrikt att först göra en konkurrensanalys. Sedan rapporterar du hur ni står er i konkurrensen och vilka konkreta aktiviteter ni bör ta tag i för att bli (ännu) bättre. Det finns massor med verktyg för detta och flera av dem kommer vi titta närmare på i de följande delarna av boken. Ett visuellt, och därmed mycket pedagogiskt, sätt att visa på skillnaden mellan ens egen webbplats och någon annans är Webpagetest.orgs funktion Visual Comparison. Där kan man lägga till en eller flera webbplatser för att se hur visuellt kompletta de är och jämföra dem med varandra.

: Bild 36: Jämför man Aftonbladet med Expressen så är Expressen mycket snabbare på att visa sitt innehåll på en trög mobil uppkoppling.

Låt säga att ni är sämre än värsta konkurrenten, det lär vara motivation nog för att få ett mandat att börja agera och med det en lämplig budget. Det är webbanalytikerns jobb att undersöka om skäl nog finns att jobba med prestanda, men också att kunna följa upp att varje insats är värd ansträngningen.

Fortsätt läs – Del 3: Webbanalys: Fördjupning