Del 2: Analytisk vinkel på design, ytelse og innhold

Som nettstedseier eller innholdsprodusent kan en stilguide være den naturlige plassen å dokumentere den kommunikative stilen man har til hensikt å bruke i digitale sammenhenger. I stilguiden finnes også andre ting, som organisasjonens webretningslinjer, designmønstre, ytelsesbudsjett og mye mer. Der den grafiske profilen slutter i digitale sammenhenger, tar stilguiden over. Som for eksempel å kravstille interaksjon, noe som kalles for et ytelsesbudsjett.

Et ytelsesbudsjett er plassen der man setter sitt minimumsnivå, altså hvilken standard man minst vil holde på nettstedet sitt. Dette nivået kan dekke hva som helst du vil definere for hvordan nettstedet skal prestere. Et fåtall overskridelser av dette budsjettet er ingenting å stresse over, men samtidig skal ikke prosjekter gjennomføres i strid med det budsjettet man har satt opp.

Jeg innser at jeg kan trenge å forklare hvordan design henger sammen med analyse, og oppfølging i største allminnelighet. Grunnen til at denne delen er verd å ta hensyn til er at hvis man ikke har en konsekvent eller bevisst design og kravstilling, blir det vanskeligere å utelukke designfaktorer som støy i sine innsamlede data. For eksempel kan man spørre seg hvor meningsfullt det er å teste en ny farge på call to action-knapper hvis man allerede er veldig inkonsekvent.

Hvis man verken følger designkonvensjoner brukerne har lært seg eller selv er konsekvent i sin egen design, gjør man ikke det meste mulige ut av brukeropplevelsen. Det blir også vanskelig å følge opp hvordan nettstedet presterer. Det er grunnen til at en webanalytiker bør interessere seg i det minste litt for designspørsmål i store trekk og iblant være litt kritisk rundt grafiske detaljer innen formgivning.

Min egen arbeidsgivers nettsted hadde frem til 2016 massevis av ulike måter å formgi lenker på. Jeg vet ikke hvor mange det var i den opprinnelige layouten, men det ble flere og flere over tid. Antagelig skyldtes dette at det manglet styring i designspørsmål. Den styringen som fantes gikk ut på at man ikke fikk lov til å plassere lenker i brødteksten. Iblant var en lenke understreket, mens lenken i kolonnen ved siden av ikke var det. Det hendte også at lenker i lister hadde et fargerikt ikon ved siden av, men iblant besto de av vanlige punktlister. Enkelte lenker var svarte, andre var blå, om de nå ikke var hvite. Det som skjedde når man dro en musmarkør over en lenke varierte også, iblant ble de lenkene som manglet understreking tildelt en slik, men det var ikke noe man kunne regne med. Utover de bildene som var klikkbare, kunne lenker ha tre ulike farger, ha fet skrift eller vanlig tekst, iblant overskrifter, eller være understreket. Lenkede bilder var også det en miks av alt mulig, dels den for tiden vanlig forekommende flate designen, men iblant en form for bilde med skyggeeffekt bak – såkalt skeumorfisk design, altså det som etterligner hvordan en fysisk motstykke kan tenkes å se ut.

: Bilde 21: Et knippe lenker fra startsiden på vgregion.se, mange ulike utseender, ikke alltid åpenbart hva som er en lenke (2015).

Ved neste redesign, i 2015, tok vi sjansen til å forsøke å begynne å styre designen, og Västra Götalandsregionens stilguide var født. I vanlig orden sluppet med fri lisens så andre kan lage en kopi og gjøre den om etter egne behov.

Det vi ofte finner i en stilguide er språkretningslinjer, som tips om lengde på setninger, hvordan ting skal se ut, såkalte designmønstre samt generelle tips. Vi skal straks gå gjennom respektive del.

: Bilde 22: Første versjon av Västra Götalandsregionens stilguide.

Et mer ekstremt eksempel nettopp når det gjelder fargevalg hørte jeg av Expressens lead frontend-utvikler. De hadde bare på startsiden av expressen.se hele 24 ulike nyanser av sin røde farge. Dette skyldtes ikke noe krav fra de som bestiller design til nettstedet, men snarere at utviklerne selv valgte en rød farge når de skulle gjøre noe rødt. Kanskje var det den innsikten som fikk Expressen til å lage en stilguide og standardisere hvilke farger som er de riktige. Med en stilguide tok de kontroll over hvordan brukerne skulle forstå og tolke nettstedet deres.

Stilguider er i seg selv ikke noe nytt. Det er imidlertid en av få ting som nettet ikke arvet fra trykksakprodusentene allerede på 1990-tallet. Stilguide kan være et paraplybegrep og samlingssted for all dokumentasjon om hvordan man bedriver sin kommunikasjon i digitale sammenhenger. Innenfor etablerte virksomheter har man sikkert allerede noen deler av det som kan utgjøre en stilguide. Muligens kalles de for retningslinjer, veiledninger, designmanualer eller lignende. Iblant gjelder disse kun den fysiske virkeligheten som skilt eller trykksaker, og iblant gjelder de mer digitale ting. Et veldig relevant og ytterst kommunikativt eksempel på innhold å tenke på til sin stilguide er New York Times' dokument med «forbudte» ord. Altså deres språklige stil.

: Bilde 23: New York Times' liste med ord å unngå.

Grunnen til at man bør samle all dokumentasjon på ett felles sted er at hvis folk slipper å lete på flere steder, vil etterlevelsen av disse dokumenterte klokskapene øke. Derfor tror jeg at det er smart å være inkluderende i hva man velger å ta med i sin stilguide, også det som ikke er så veldig digitalt kan sikkert gjøre nytte.

Det er litt merkelig at stilguider ikke ble en selvfølge samtidig som responsiv webdesign slo igjennom. I og med at man i designfasen for et responsivt nettsted er nødt til å begynne å snakke om hvordan et designelement skal se ut på ulikt store skjermer, burde behovet for en dokumentert design være nesten åpenbart. Hvordan skal man ellers vite hvordan et designmønster, som hovedmenyen, oppfører seg og ser ut på ulike skjermer? Til å begynne med, hos enkelte organisasjoner, ble disse nedtegnet i noe som kalles pattern libraries. Altså organisasjonens bibliotek av designmønstre. Nå ser det ut til at designmønstre stadig oftere er en del av de offentlig tilgjengelige stilguidene vi kan finne på nettet.

: Bilde 24: Designmønster for et søkefelt.

I 2000-tallets første tiår har nok mange organisasjoner stått og stampet litt i webarbeidet. Mange er kanskje halvveis inne i å modne i sitt webarbeid, men mangler likevel visse deler man har i det «vanlige» kommunikasjons- og markedsarbeidet. Få ser ut til å ha kommet særlig langt med en like fullendt digital del i sin grafiske manual, i det minste sammenlignet med det som gjelder trykksaker.

Ny design? Lag et designbudsjett!

Hvis du har fordelen av å kunne samkjøre jobben med å lage et nytt nettsted, eller i det minste redesigne det, og ta tak i arbeidet med en stilguides designmønstre, skal du takke din lykkestjerne. En måte å ha konkrete og forståelige begrensninger i sitt designarbeid er å jobbe med noe som kan kalles for et designbudsjett. Det er en måte å unnslippe de ofte forekommende diskusjonene om at det er vanskelig å prioritere da tydeligvis alt alltid er viktigst.

Fremvoksende praksis innen webdesign er å starte designarbeidet med å sette opp et designbudsjett. Et designbudsjett går ut på å designe sider og maler på en tilbakeholden måte. For å konkretisere denne tilbakeholdenheten har man et poengsystem som styrer hvor mange designkomponenter som havner for eksempel på en landingsside. Si at man begynner med å sette et tak om tjue poeng som budsjett for hver enkelt sidevisning. Skal du da hente inn en stor blokk med bilde og call to action-knapp? Da kommer du ha brukt opp seks poeng bare på det store bildet. Skal du så ha en bildekarusell forsvinner kanskje ti poeng til på grunn av flere tunge bilder men også en ekstra Javascript-avhengighet for selve bildebladringen.

En fordel med å lage et designbudsjett er at det er vanskelig å reparere denne typen mangler i etterkant når alle beslutninger er tatt. Samt at man nok er mer kompromissvillig i begynnelsen av et prosjekt.

Barbara Bermes har nedenstående forslag til poengsystem i sin utmerkede bok Lean Websites²⁰.

Designmønster	Poeng	Beskrivelse
Liten påvirkning	1	Små bilder, statisk innhold, enklere grafikk, knapper og tekstfelt.
Mellomstor påvirkning	2	Halvstore bilder og enklere skript.
Stor påvirkning	6	Store bilder, tredjepartstjenester, annonser fra tredjepart.

Største gevinsten med et designbudsjett er å konkretisere hvert designbeslutnings påvirkning på nettstedet, det blir konkret for dem som ikke har anledning til å snakke om dette i mer tekniske ordelag (der kommer ytelsesbudsjettet inn, noe vi straks kommer inn på).

Vil man selv spille djevelens advokat ved designbeslutninger, kan man konstant foreslå å A/B-teste brukernes aksept av respektive idé. Kanskje fungerer sider med høyere poengsum. Kanskje kan taket deres være tjuefem poeng snarere enn tjue for en landingsside og den presterer på samme nivå? Men test for all del også antakelsen om færre designpoeng gir mer nytte, og hvor grensen går.

Som Karen McGrane påpeker i sin bok Going Responsive²¹, i kapittelet Clean up your content, så er det i design- eller evalueringsfasen man har en gyllen mulighet til å sette seg ned sammen og gjøre de vanskelige prioriteringene om hvilket innhold som skal finnes, og hva som faktisk er viktigst. Det er nå man også tenker mobile first, små skjermer, treg tilkobling etc. Svar på disse spørsmålene får man ikke per e-post – man trenger å møtes. Under et slikt møte må man kunne fatte beslutninger. Det er også nå det går an å møte den manglende evnen som ofte finnes til å utpeke én eneste ting som er viktigst per side. Hvis bare én ting får plass på en skjerm, hva skal man da velge ut. Det finnes ingen delte førsteplasser i mobile first.

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

Du har nok skjønt at man med dette synet trenger å husholdere med ressursene i topptekst og bunntekst. Ellers blir det veldig lite igjen for det unike på hver nettside å bruke.

Orker man ikke holde på med poengsystemet ved designbeslutninger, kan man i stedet ha et batteri av spørsmål som reder ut hvordan design påvirker opplevelsens hurtighet, om det gjør det hele til en økt kognitiv belastning for brukeren. For eksempel kompletteres spørsmål om hvordan designforslaget påvirker merkevaren, eller krenker eksisterende designmønstre, med spørsmål som:

Kommer det å påvirke antallet filer som trenger å lastes ned?
Blir sidevisningen tyngre?
Hvordan påvirkes den opplevde ytelsen?
Kommer brukeren til å bli mentalt overbelastet eller ha vanskelig for å tolke de alternativene som finnes?

Poenget er å i større grad konkretisere design i flere dimensjoner enn det strengt estetiske. Vi er fra før vant til å stille forretningsmessige spørsmål som hva det kan tenkes å koste, hvor lang tid det tar å ferdigstille og hva man tror det har for verdi for virksomheten. Mange organisasjoner er klart dårligere på å stille designspørsmål, som hvorfor farge brukes på en bestemt måte, eller nødvendigheten i utsmykning.

Et tillegg til dette er det som Lara Hogan tar opp i sin bok Designing for Performance²³. Hun viser at man gjør sitt designbudsjett spesifikt per brytpunkt på nettstedet. For deg som ikke er bevandret i webdesign, kan det være verdt å vite at brytpunkt er de magiske breddene på nettstedet når designen endres for å gjøre det meste mulige ut av tilgjengelig plass. Det er en del av konseptet responsiv webdesign. En liten skjerm har mindre mulighet til å vise opp mye på en gang, og derfor blir det kanskje enda mer presserende å ikke være sløsaktig.

Det her med grunnleggende design er også en gyllen mulighet til å planlegge for sin kontinuerlige webanalyse. For eksempel kan flere hypoteser om hvor stor påvirkning antallet designelementer har på mobile brukere evalueres metodisk med A/B-tester når designen er ferdig og publisert. Da kan man begynne å teste hva som fungerer på faktiske brukere, om man nå ikke jobber med tidlige designprototyper allerede før det er bygget.

Å evaluere hvordan en design presterer kan være veldig teknisk. Det vil du merke straks når vi tar opp begrepet ytelsesbudsjett. Designbudsjettet er den sjansen man har til å snakke ytelse, og prestasjon, i relasjon til hvordan noe kommer til å se ut i grove trekk.

Som webanalytiker kan du bidra på mange måter til diskusjonen om et designbudsjett. Ikke minst med å planlegge for en sammenligning mellom sider som har drastisk ulikt antall designelementer, eller hvilke kontraster du finner nysgjerrighet overfor å undersøke. En interessant anekdote jeg hørte av Expressens lead frontend-utvikler var at de A/B-testet hvor godt deres besøkende konverterte, og merkelig nok var det høyere konverteringsfrekvens på de rotete sidene. Når de så gjorde de ikke fullt så rotete sidene litt «dårligere», fikk også de sidene høyere konverteringsfrekvens.

Det er viktig å utfordre sine antakelser, beviselig!

Innholdsbudsjett

Du som har lest min bok Webbstrategi för alla²⁴ eller følger bloggen min har nok merket hvor ofte jeg refererer til alt bra engelske Gov.uk gjør. Nå er de riktignok ikke alene om å ha sjekklister for hvordan man tenker rundt innholdet sitt på nettet, men de er flinke til å snakke åpent om hvorfor de gjør ting på den måten de gjør.

De fleste organisasjoner jeg har støtt på har riktignok veiledninger til hvordan man skriver, men svært få har som Gov.uk gått langt i å gjøre denne klokskapen tilpasset nettet. Slik beskriver de for eksempel hvordan en sidetittel skal formuleres²⁵:

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)

Enda mer interessant er kanskje retningslinjene for brødtekst:

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 disse eksemplene settes visse begrensninger på hvordan man jobber med innhold og dets ulike mengder. Ikke helt ulikt et budsjett. Ditt innholdsbudsjett kommer sikkert til å bli utfordret og stilt spørsmål ved. Gov.uks beslutning om å holde en brødtekst til under 500 ord er nok i skuddlinjen direkte om de tar inn en konsulent for litt søkemotoroptimalisering. SEO-praksis er på det tidspunktet denne boken skrives, at en tekst skal være minst tre hundre ord – men helst rundt tusen. Jeg kan mene at poenget med å ha et innholdsbudsjett er selve diskusjonen om hvordan man ser på sitt innhold. Man dokumenterer sin hensikt slik at alle ideer kommer til overflaten og at det ved behov går an å diskutere og revidere dem.

Nå finnes det jo alltid konkurrerende synspunkter, og ulike yrkesgrupper kommer gjerne med sine egne fakta, praksis eller underlag inn i en diskusjon. Innholdsbudsjettet er organisasjonens egne dokumenterte gode praksis i innholdsspørsmål, de skal ikke endres vilkårlig. En måte er selvfølgelig å endre seg basert på egne tester, men før det er forskning og ekstern praksis det beste man har å gå etter.

Grunnen til at Gov.uk valgte at setninger ikke skal overstige tjuefem ord²⁶ er basert på forskning. Forskning viser at når den gjennomsnittlige setningslengden er fjorten ord, forstår minst 90 % av leserne hva de leser. Ved førtitre ord per setning synker det til under 10 %. Studier viser også at ved tjueen ord per setning begynner en tekst å være litt halvveis kompleks å ta til seg. Å velge tjuefem ord per setning som grense får anses å være ganske sjenerøst, synes jeg, men tipper også at de fleste ikke har noen ambisjon i det hele tatt på dette området.

Jobber du etter mantraet content first²⁷ så er et innholdsbudsjett tilsvarende hva et designbudsjett er for de som begynner med designen. Du som lurer på hvordan pokker man følger opp at dette etterleves, får smøre seg med tålmodighet – senere i boken vil du finne tips om hvordan du jobber med innholdsanalyse, eller indeksanalyse som søkefolk ofte kaller det.

Stilguide = kommunikativ stil, mønsterbibliotek og ytelsesbudsjett

Vi har allerede i denne delen av boken gått gjennom en del av den dokumenterte ambisjonsnivået man kan ha med sin webtilstedeværelse, men det finnes selvfølgelig flere ting å sette på trykk (digitalt).

En organisasjons stilguide bør, synes jeg, være et samlenavn for all den dokumentasjonen som angår organisasjonens kommunikative stil – i bred forstand. I dette kan massevis av ulike deler inngå, der få fellesnevnere finnes. Ofte finnes det fra før tips og retningslinjer rundt det språklige, ikke sjelden noe om typografi i digitale sammenhenger, iblant designskisser som forteller nøyaktig hvordan logotypen og andre designelementer skal håndteres for å verne organisasjonens identitet.

I den senere tid har det blitt stadig vanligere å også dokumentere en mer teknisk håndbok som inneholder kodeeksempler for webutvikling, nøkkeltall for oppfølging av nettstedet og ytelsesbudsjett for de prioriterte kvalitetskriteriene som er valgt ut.

Mange kommunikative deler bør nok tas opp. Kanskje ikke ordvalg i seg selv, men snarere hvordan man finner ut hvilket språkbruk som forventes og at de ordene man faktisk har valgt har forutsetning for å nå frem. For eksempel at det finnes en begrenset plass for hvor mange ord som vises hos Google, i brukerens nettleser m.m. Stilguiden kan faktisk komme med både pisk og gulrot. Pisken bestående av retningslinjene som sier hva man har lov til å gjøre, og gulroten som er tipsene om hvordan man gjør for å lykkes godt under rådende forutsetninger på nettet.

Mønsterbibliotek

: Bilde 25: Eksempel på stilguide. Intro med tips om hvordan den brukes, deretter mønsterbibliotek for gjenbruk.

I stedet for å designe hele sider pleier man å bli anbefalt å designe sine designmønstre først, begrepet for dette er Atomic Design²⁸. Du kan ha støtt på dette konseptet under andre navn, den vanligste synonymen i Sverige er nok komponentbasert design. Det er litt som hvilke byggeklosser man trenger i sitt lager for å kunne bygge noe. Disse kalles stadig oftere på svensk for designmønster (på engelsk design patterns), og samlingen av designmønstre for mønsterbibliotek (eller pattern library).

Eksempler på designmønstre kan være hvordan søkefunksjonen ser ut, det vil si søkefeltet, knappen og slikt som er rundt. Eller hvordan et bilde ser ut sammen med dets bildetekst. Dette er nyttig, akkurat som spesialiserte Legobiter, når man vil gjenbruke noe i en annen sammenheng ved et senere tidspunkt. Da er deler av arbeidet allerede klart. Man trenger ikke fundere på hvor mange bildepunkters radius søkefeltets avrundede hjørner bør ha, det er bare å kopiere det som allerede er laget.

Hvis man ikke sammen med sitt designmønster også har bestemt nøyaktig hvilken grensesnittkode som skal brukes, har man bare gjort halve jobben. Det er ikke nødvendigvis slik at koden skal stå i fokus, men hvis ingen kode gis blir det vanskelig da alle utviklere selv må finne opp egen kode som får noe til å se ut og fungere som ønsket. Du kan trygt regne med at ikke alle er like motiverte til å velge riktig farge, eller sørge for at det skalerer godt på ulikt store skjermer, eller i det hele tatt at det blir tilgjengelig nok til å oppfylle diskrimineringslovgivningen. Det er altså anbefalt at kode finnes i tilknytning til designmønsteret og at man forsøker å sørge for at de brukes.

Hva er så poenget med å jobbe med et mønsterbibliotek av gjenbrukbare designmønstre? Jo, man skaper en organisatorisk standard for hvordan ting ser ut og fungerer. Foruten åpenbare gevinster rundt ens organisasjons identitet kan denne formen for standardisering faktisk bidra til trygghet hos brukerne. Hvis noen havner på en phisher sin nettside, får de forhåpentligvis muligheten til å innse at noe er galt, at noe i den visuelle eller funksjonelle identiteten er feil. Det er viktig å ha en tydelig identitet slik at de trofaste brukerne innser når noe ikke helt stemmer. Hvis man ikke jobber med et mønsterbibliotek, kommer man ha fullt opp med å etterligne seg selv for ikke selv å fremstå som en dårlig imitator.

: Bilde 26: Prototype av klinikksøk. En kombinasjon av flere designmønstre gir raskt prototypearbeid.

Du som er litt våken har allerede begynt å tenke på at visse av disse delene inngår i noe som iblant kalles for en organisasjons grafiske manual. Forskjellen er at en stilguide tar opp mer enn det som handler om det grafiske. Jeg ville både påstå, og anbefale, at ens stilguide erstatter ens grafiske manual. Den manualen kan faktisk inngå i stilguiden, og det man kaller for grafisk manual kan i stedet kalles for designguide. Komplettert med de dokumenterte designmønstrene har man kommet et godt stykke med en stilguide – visuelt i det minste.

Fordeler med et mønsterbibliotek (om det brukes) er i det minste at det:

Borger for et enhetlig utseende. Gjennom en redusert variasjon i hvordan noe ser ut, blir ens design mer forutsigbar for brukerne. Det går an å ha kontroll på om en ny design fungerer bedre, likt eller dårligere enn den varianten man kjørte med tidligere.
Er lettere å forvalte hvordan respektive designmønster fungerer med de kravene man har, ikke minst når man vil teste dem. For eksempel om det kommer en ny dings på markedet, kan man sjekke at alle ens designmønstre flyter fint og responsivt også på den nye dingsen.
Evaluerer prototyper enklere. Når du har standardiserte designmønstre å gjenbruke, går det fort å få frem en testbar prototype. Bare gjenbruk det som ikke er det nye du skal evaluere (se prototypen av klinikksøk her ved siden av).
Gir høyere kvalitet. Om man sørger for å holde høy klasse på sine designmønstre og at de følger gjeldende praksis, kan man regne med at nybygg kommer til å holde en høy kvalitet. Det er altså viktig at man har et høyt og forutsigbart nivå på det som tas med i mønsterbiblioteket.

En felles undertone i ovennevnte punkter er at det trolig er ressurseffektivt på sikt om man sørger for å bruke sitt mønsterbibliotek. For å lykkes kan det sikkert kreves litt oppmuntring fra de som styrer virksomheten, og en del hardt arbeid og interesse fra alle involverte.

Er ikke en stilguide det samme som en kommunikasjonspolicy?

Det er kanskje det den kunne være, men det er ikke helt samme mål. Forskjellen er i hvor aktivt bruken er og hvilken status respektive dokumentasjon har innenfor organisasjonen. En policy er trolig mer avgrenset og full av juridisk eller byråkratisk fagspråk. En stilguide, derimot, kan være en levende dokumentasjon med utførlige tips og eksempler på hvordan man går til verks ved digital kommunikasjon.

I sin stilguide kan man også ta med mykere ting. Som hvilke verdier man har. Eller som Mailchimps stilguide som har dokumentert det oppmuntrende språket som er en vesentlig del av brukeropplevelsen hos dem.

: Bilde 27: Mailchimp forklarer sin tonalitet i sin stilguide. At en del av tjenestens opplevelse kan handle om språkligheter.

En stilguide er med fordel bygget som et lite nettsted der man kan utforske alle delene, se eksempler og hente hjelp for å følge organisasjonens praksis rundt det å utforme noe.

For å komme i gang med sitt arbeid med en stilguide trenger de fleste å begynne med en inventering av hva som allerede finnes dokumentert innenfor den virksomheten man jobber i og hvordan det kan passe inn i denne nye virkeligheten. Hvis du ikke har skjønt det allerede, er en stilguide noe som primært har et ovenfra-og-ned-perspektiv, så hvis du ikke jobber i toppen av din organisasjon er det trolig slik at du trenger hjelp fra kollegaer for å etablere deres stilguide, eller få tillatelse til å lage en egen, lokal, stilguide.

Mange har sikkert allerede dokumentasjon rundt hvordan man tiltaler kunder og mottakere. Dette bør man inkludere i sin stilguide, og så kan man droppe det dokumentet. La stilguiden være startpunktet for alt som angår kommunikasjon, design for digitalt og trykksaker, samt guider til hvordan det hele foregår i praksis og hvem man henvender seg til for støtte eller spørsmål.

Stilguide er som sagt en slags paraplybegrep for flere ting. For å begynne å beskrive det litt mer «webbige» som inngår i ens stilguide kan man snakke om stilguidens basale elementer, nemlig:

Hvordan kolonne- og rutenettsystemet fungerer for mobiler og datamaskiner.
Standardutseende på vanlige HTML-elementer. Hvordan ser for eksempel lister ut, bilder og deres bildetekster?
Typografi rundt avsnitt av tekst, overskriftsnivåer, skrifttyper, etc.
Hvordan man håndterer tabeller, skjemaer og så videre.
Designspørsmål som farger, utseende på feil- og advarselsmeldinger, osv.
Hvilke ikoner bruker man til hva og hvordan plasseres de korrekt designmessig.
Hvordan bygges mediefiler inn.

En stilguide skal gå foran med godt eksempel rundt hvordan webkode håndteres. Det er et sted for de som bygger nettsteder å hente kodesnutter slik at det blir riktig, med en gang. Har man en godt utbygd stilguide blir det lettere å bygge en midlertidig mikrosite for en kampanje, eller om man av en annen grunn trenger å bygge et nytt nettsted. Da kan utviklerne hente kvalitetstestede komponenter, rammeverk og ferdige kodesnutter, som alle er robust konstruert og tilgjengelighetsgransket. Det er i alle fall tanken, at man som bestiller skal kunne levere sin stilguide som en slags referansepunkt for en leverandør å forholde seg til.

: Bilde 28: Stilguide for Bootstrap forklarer hvordan bilder blir responsive, og angir hvilken kode som skal brukes.

Stilguiden bør også forklare hvilke stillingtakinger som er gjort rundt designvalg. Blant annet hvor gamle nettlesere man tenker å støtte og eventuelle avvik man har kommet frem til. Eksempler på slike avvik er hvordan eldre nettlesere uten støtte for media-spørringer skal håndtere en responsiv virkelighet, eller om man har valgt å bruke SVG-formatet for bilder så er den støtten ikke kjempebra i gamle Internet Explorer. I stilguiden forteller man om man har tenkt å bruke noe spesielt polyfill²⁹ for å løse bakoverkompatibiliteten.

Først og fremst handler denne boken om nettet, men selvfølgelig kan en stilguide like gjerne inkludere apper, sosiale kanaler, etc.

Ærlig talt er det heller ikke i webutvikleres kretser slik at stilguider er noe nytt. Men ordvalget har ofte tidligere vært kodemanual eller lignende, dog fortsatt med målet om at man skal være enhetlig med hvordan man produserer sitt resultat. For en utvikler er det av høyeste viktighet hvordan man navngir ting i kode, dette dels for at det skal være forklarende for noen andre som senere skal fikse koden, men også for ikke å risikere å få kollisjoner mellom ting som blir døpt til samme navn. Vil du nerde deg ned i dette, sjekk ut boken Code Complete³⁰, om du nå vil gi deg i kast med teknikaliteter som navngivning av variabler for Javascript.

Litt avhengig av hvem du spør hva en stilguide er, vil du få litt ulike svar. Følger du bloggere innen webdesign, merker du fort at en stilguide faktisk kan være mange ting. Det jeg fikk igjennom på min arbeidsplass da vi laget vår stilguide handler om følgende:

Organisasjonens webstandard, verdier og ambisjon. For eksempel hvordan man ser på tilgjengelighet, hvordan kode skal skrives, med mer.
Et bibliotek av designmønstre for nettet og andre digitale kanaler. Har du byttet tema i Wordpress noen gang, har du garantert sett hvordan de velger å presentere temaet. Du får se ting som typografi, hvordan bilder vises med mer. Du får oversikt over hvordan ulike deler av et nettsted kan tenkes å se ut.
Ytelsesbudsjett, og her skal vi ikke ta ytelse bokstavelig. Den engelske termen er performance budget, så muligens skal vi også inkludere alt som har med prestasjon å gjøre.

Jeg vil presisere at ingen av ovennevnte punkter på noen måte er obligatoriske i en stilguide, man kan gjøre litt hva man vil av sin egen stilguide. Men for denne bokens argumentasjon kan du regne med at en stilguide i det minste dekker innhold, webdesign og ytelsesbudsjett. Ovennevnte punkter var det jeg fikk gehør for der jeg jobber, et sted der svært få hadde hørt om en stilguide før. Noe som kanskje kan tas for et tegn på hvilke deler som er forståelige i en større krets av mennesker som alle jobber med nettet på en eller annen måte. Det som ikke kom gjennom nåløyet i stilguidens første versjon var webredaktørenes håndbok, den ville man gjerne ha separat – muligens fordi man ikke kan se at stilguiden kommer til å bli brukt eller være av interesse lenger ut i organisasjonen.

Stilguiden er nok primært til for innholdsprodusenter og kanskje de som eier nettstedet fra en ledelsesposisjon. Den skal ta opp det som skaper forutsetninger for at et nettsted skal kunne levere resultater. Skal man peke ut en eier til stilguiden i en større organisasjon, er det nok markedssjefen eller kommunikasjonssjefen som skal bry seg mest. Og de som varter stilguidens innhold er de på tilsvarende avdeling, muligens sammen med de som utvikler nettstedet.

En stilguide bør ikke være et dokument man stuer inn i et arkiv. Snarere bør man la den være noe man jobber aktivt med. Stilguide kalles ofte for living style guide på engelsk. Det er ment å være noe levende, noe foranderlig. Poenget med ens designmønstre (som utgjør ens webdesign) er at de kontinuerlig trenger å forbedres for å leve opp til nettets stadig foranderlige krav og brukernes forventninger.

Hvis du trenger å henvise til en autoritet for å få lov til å jobbe med deres stilguide, så kjør med Brad Frost. Hans konsept med Atomic Design har vi nevnt tidligere. Det er et logisk komponentbasert synspunkt på webdesign. Det tilbyr en forklaringsmodell fra minste tenkelige komponent, som en knapp for søk, opp til hvordan en eksempelside kan se ut.

Eksempler på problemstillinger å ta opp

Det finnes en rekke spørsmål å besvare når man setter sin ambisjonsnivå i et webprosjekt. Litt avhengig av hvilken yrkesgruppe man holder seg til, kan man kalle denne ambisjonen for ulike ting.

Stilguide er kanskje nærmere innholdsprodusentens syn på ambisjonsnivå, mens ytelsesbudsjett er utviklerens vinkel (men stadig mer av interesse for de som vil konvertere sine brukere). Jeg foreslår at vi betrakter ytelsesbudsjettet som et vedlegg til stilguiden. Det handler tross alt om organisasjonens kommunikative stil i digitale kanaler, og ytelsen er i høyeste grad en viktig del.

En stilguide inneholder ofte eksempler på typografi, design, tiltale med mer, mens et ytelsesbudsjett ofte fokuserer på målbare ting som er kvantifiserbare. Slikt som kan analyseres og sendes som målbare krav til leverandører. For eksempel hvor lang tid som er akseptabel for å motta en nettside. Sammen med den visuelle identiteten, organisasjonens tonalitet i språket, hører definitivt en «teknisk» identitet hjemme for å danne en felles opplevelse. Hva man kan forvente fra din organisasjon i digitale sammenhenger, mer om det leser du i kommende avsnitt om ytelsesbudsjett.

En bonusproblemstilling vi på min arbeidsplass fikk rundt stilguide er blant annet den granskingen av integritet innen offentlig sektor, som Dagens Nyheter kjørte som en serie artikler samtidig som vi laget stilguiden høsten 2015. Det ble en diskusjon om hvilke verdier vi hadde, om vår bekvemmelighet i valg av verktøy og integrasjoner kunne veie tyngre enn brukernes integritet. Spørsmålet oppsto om man i offentlig sektor noen gang skal ha med tredjeparter på sine nettsteder om man ikke har kontroll på eventuelle følgevirkninger for sine brukere. Det kan være mye mer enn om man skal ha Google Analytics. Det gjelder jo også hvordan nettsteder designes, om man bruker eksterne skrifttype-tjenester, bygger inn Facebook-strømmen, sosiale dele-knapper, m.m.

Dessuten har nettstedets stil også med brukervennlighet rundt innholdet å gjøre. Om lengden på sidetitler fungerer i alle tenkelige sammenhenger, hvordan man ser på responsiv bildebehandling og mye mer.

Disse spørsmålene hadde vi på min arbeidsplass da vi først begynte å jobbe med vår stilguide. Noen av spørsmålene er sikkert relevante også der du jobber. En test på om et spørsmål er meningsfullt å ta med i stilguiden er «og hva så-testen», altså at man kan besvare «Og hva så, hvem bryr seg?» Man trenger å kunne ha en saklig diskusjon rundt hvert punkt man velger å ta med. For hvem den er til for og hvorfor det er viktig.

Hvordan skal vår typografi være for å garantere en god leseopplevelse på alle plattformer?
Skal vi bygge inn tredjepartstjenester som eventuelt truer brukerens integritet?
Lengde på sidetitler. Som lengst 60 tegn?
Skal bilder vises i retina-oppløsning eller «vanlig oppløsning»?
Tillate utsmykkende bilder, eller ikke?
Når er det motivert å bruke tabeller?
Skal alle viktige sider angi meta-description og minst ett nøkkelord (noe vår egen søkemotor trenger for at nettstedssøket skal fungere bra)?
Minst én call-to-action synlig uten scrolling på landingssider? Synlig for alle slags enheter som brukes?

Forvaltning av stilguiden

En utfordring man må forsøke å håndtere gjennom arbeidet med sin stilguide er hvordan den skal forvaltes over tid. Akkurat som at retningslinjer for sosiale medier, og andre hurtig bevegelige ting, kan bli komisk utdaterte ganske raskt, gjelder det at stilguiden ikke blir noe man putter i skrivebordsskuffen og titter på annethvert år. Selv om jeg mener at en person bør utpekes som stilguidens forvalter, bør stilguiden være alles anliggende. I alle fall de som jobber med en form for kommunikasjon eller utvikling i digitale kanaler.

En måte å ikke la stilguiden samle støv er å putte inn veiledning, eksempler, tips og annet som gjør at berørte titter inn i stilguiden litt oftere. Så bør nok den som er utpekt forvalter hvert kvartal sjekke gjennom alt materiale, mest for sikkerhets skyld.

Et tydelig eksempel på noe som krever oppmerksomhet litt løpende er de designmønstrene man putter inn i stilguidens mønsterbibliotek. Etterspørsel etter nye designmønstre må veies mot gjenbruk av de eksisterende, ellers blir det lett uoversiktlig rent visuelt rundt organisasjonens identitet.

Mønsterbibliotek gir tydeligere krav til leverandørene

Som leverandør kan en stilguide gjøre det lettere å forstå hvilke forventninger som finnes. Samt at man ikke trenger å gjenoppfinne ting som hvilket responsivt atferd man har kjørt med tidligere og annet som rimeligvis burde kunne standardiseres innenfor den organisasjonen som har skapt stilguiden. Dette borger også for en konsekvent opplevelse mellom ulike nettsteder fra samme organisasjon.

: Bilde 29: Webrammeverket Bootstraps stilguide er også dens dokumentasjon.

Et utrolig hyppig brukt (og forhånet) standardiserende rammeverk for nettet er Bootstrap. Deres dokumentasjon er akkurat det man kunne betrakte som en stilguide. Der kan man ta del i nøyaktig hvordan kode skal utformes for å leve opp til designkonvensjonen mobile first. Hvordan skjemaer både ser ut og skal kodes, og alt annet som har med grensesnittkode som HTML, Javascript og CSS å gjøre.

Grunnen til at Bootstrap er forhånet er at dets enorme gjennomslag har gjort at veldig mange nettsteder ser like ut. Visst, det er kanskje ikke en designers drøm å være nødt til å forholde seg til et utseende som er felles for alle mulige organisasjoner. Men denne konsekvente designen er jo nettopp det vi er ute etter når avsenderen er én og samme organisasjon.

Mest grunnleggende i ens mønsterbibliotek er hvordan de vanligste designelementene ser ut og reagerer responsivt, for eksempel hvordan toppteksten svarer på de ulike store skjermene brukerne kan tenkes å bruke. Dette er en av de største poengene med en stilguide og dens mønsterbibliotek. At man dels kan teste hvordan det fungerer i dag, men også være det stedet der man i sin aktive forvaltning av stilguiden kan utvikle nye designmønstre og sørge for at de holder mål.

Det er kanskje ikke rimelig å tro at man kommer til å ta seg tiden til å kjøre hvert eneste lille designbeslutning gjennom denne prosessen og få det dokumentert. Dessuten tar det nok en ganske stor investering i tid og penger å komme til et godt nivå. Da jeg våren 2015 sonderte markedet for å bestille dette til min arbeidsgiver, var det tydelig at ingen av leverandørene jeg snakket med syntes det var lønnsomt å legge mindre enn 200 timer på et slikt oppdrag. Deres tid altså, da som eksperter på webdesign og grensesnittprogrammering. Jeg forestiller meg at vi som bestillere nok ville måttet legge minst like mye tid selv. For de timene ville man fått de vanligste designkomponentene inn i sin stilguides del med mønsterbibliotek. Altså følgende deler av et nettsted:

Overordnet responsivitet, rutenettsystem og ytre rammer for utseendet.
Grunnleggende typografi.
Topptekst, dens deler som logotype, søkefelt og hovednavigasjon.
Noen få komponenter som er innenfor en sides unike innhold. Antagelig kan man velge å få startsiden sin velgjort, samt et eksempel på underside som er tyngre på tekst.
Bunntekst, med dens kontaktopplysninger med mer.

Det finnes ingen egentlig øvre grense for hva som skal puttes inn i mønsterbiblioteket. For å prioritere og begynne å ta fatt på dette arbeidet er Atomic design til hjelp. At man ser på de minste bestanddelene og i hvilke kombinasjoner de kan forekomme på et nettsted.

Noen eksempler på slike atomiske designmønstre kan være:

Bildekaruseller (denne styggedommen av et kompromiss for å få ro på alle de som krever at akkurat deres innhold skal finnes på startsiden).
Presentasjon av kalenderhendelser og arrangementer. Kan være dels i kompakt listeform, men også hvordan den sidemalen ser ut.
Søkeforslag som dukker opp når noen har begynt å skrive inn søkeord i et søkefelt.
Megameny. Du vet de der store utfellbare menyene som kan inneholde flere kolonner med lister av undersider, relatert innhold m.m.
Kartfunksjoner og innbygde videoklipp.
Litt mer kompliserte skjemaer, visualiseringer og tabeller, som kan inneholde finesser som filtrering og sortering.

Når et mønsterbibliotek finnes kan man kombinere disse designkomponentene til komplette eksempelsider. Da blir det enklere å få en følelse for utseendet.

: Bilde 30: Code for Americas stilguide viser eksempler på hvordan en side kan se ut, med noen utvalgte designmønstre.

Det man i tilknytning til mønsterbiblioteket trenger å dokumentere er hvordan det foregår å få med et nytt designmønster. Hvilke krav de skal leve opp til, hvordan de skal testes med mer. Forhåpentligvis åpenbare krav er at det skal være tilgjengelighetstestet, validere valgt kodestandard og være kompatibelt med mønsterbiblioteket i stort. Det som inngår i ens stilguide skal være organisasjonens beste praksis for digital kommunikasjon, så det gjelder å legge listen høyt.

: Bilde 31: Starbucks' stilguide viser designmønsteret for hvordan advarselsmeldinger skal se ut.

Et eksempel på scenario rundt dette, som jeg selv har jobbet med, er at vi prototype-bygde en liten søkefunksjon direkte i stilguiden. Alternativet ville vært å gjøre som vanlig, type sende en lang liste med krav til våre webutviklere og så hadde de bygget en prototype direkte i vårt publiseringssystem. I stedet koblet vi inn en ekspert på webdesign og utvidet vår stilguide. Det gjorde at vi kunne levere over noe veldig konkret til webutviklerne (hvis fremste styrke kanskje ikke er konseptuell design) å bygge inn i vårt CMS. Med andre ord hadde vi allerede ryddet opp i nøyaktig hvordan det skulle se ut, fungere i ulike typer enheter, nøyaktig hvordan grensesnittkoden måtte være, gjort brukervennlighetstester på levende brukere, samt testet tilgjengeligheten. Så oppdraget til våre webkyndige systemutviklere ble veldig konkret – «gjør akkurat slik som det fremgår i stilguiden, få det til å fungere i vårt nettsted». På denne måten gjør alle det de er best på.

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

Ytelsesbudsjett, tekniske verdivurderinger og kvalitetsretningslinjer

Tidligere jobbet jeg som webkonsulent. Min største forbilde i hvordan man opptrer som konsulent (og som leder i stort) er David Maister, tidligere professor ved Harvard Business School. Han har skrevet den utmerkede boken Managing The Professional Service Firm³¹. Han konstaterer ofte det åpenbare man ennå ikke selv har klart å sette fingeren på.

En ting han tar opp er ytterst relevant for ytelse, nemlig hvordan en tjeneste eller vare oppleves av sin bruker. Det hele er jo rimelig subjektivt da enhver har ulike forventninger på forhånd. Han foreslo en formel som jeg kanskje har forvansket noe i min oversettelse, nemlig:

Tilfredshet = Opplevelsen – Forventningen.

Slik jeg handlet på dette, som konsulent, var å alltid forsøke å overleverere litt. Det skulle alltid bli litt bedre enn forventet. Gi det lille ekstra (forkortet DLX). Det ble spøkt friskt om hva DLX skulle være i et spesifikt prosjekt, men at det var viktig var vi alle enige om. Utviklere begynte plutselig å snakke om våre kunders opplevelse av våre leveranser. Det var en bra greie.

Underpromising – overdelivering.

Hvis du kan påvirke forventningen, blir ikke opplevelsen i seg selv like avgjørende, men hvis forventningen er skyhøy blir det nesten umulig å gjøre en god jobb uansett innsats. Det er her et ytelsesbudsjett kommer inn – tidlig i prosessen! Hvis alle designbeslutninger allerede er tatt, hele greia er bygget og man kommer frem til at resultatet ble altfor tregt, ja, hvor sannsynlig er det at man kan løse det i etterkant? Det går sikkert, men det blir definitivt dyrere å forsøke å fikse noe som allerede er ødelagt. Smartere ville vært å tenke seg om fra begynnelsen.

Hvilket nivå skal du velge? Gjør litt etterforskning om på hvilket nivå dine konkurrenter eller tilsvarende organisasjoner holder, og så sørger du for å overgå dem litt passe. Noe nybygget skal vel rimeligvis være bedre enn det som allerede er etablert?

Å støtte noe trenger ikke innebære en vilje til å optimalisere

I fordums tid så vi ofte tekster som «Dette nettstedet fungerer best i Netscape 4.0 med en skjermoppløsning på 1024x768 bildepunkter på en 17"-skjerm».

Hvilke krav tenker du å stille til dine brukere og det utstyret de velger? Det er verdt å huske på at bare fordi man tenker å støtte et visst utstyr, nettleser eller enhet, betyr ikke det automatisk at man tenker å legge seg i selen og optimalisere den opplevelsen. Se støtten som at noe skal være mulig å bruke, men så finnes det andre tilfeller der man anser at det er verdt å jobbe med optimalisering. I ytelsesbudsjettet dokumenterer du dette minimumsnivået.

En designprinsipp som vi i den gamle garden av webutviklere har levd etter, og som er en del av konseptet å følge webstandard, det pleier å kalles for progressive enhancements. Det innebærer at en god grunnfunksjon skal tilbys alle, og om det fortsatt finnes engasjement igjen kan man begynne å optimalisere for de brukerne som er viktigst for en, eller har et visst utstyr som kan trenge litt mer omsorg for at det skal fungere optimalt.

Ytelsesbudsjettet får som sagt mer enn gjerne inkluderes i organisasjonens stilguide. Primært er ytelsesbudsjettet rettet mot utviklere. Alle andre skal slippe å snakke teknikk, men det kan også fungere bra som en avklaring om organisasjonens forventninger til sine leverandører. Streb etter at ytelsesbudsjettet skal gi svar på tiltale nok til at ikke-utviklere skal kunne stille motspørsmålet «lever det opp til ytelsesbudsjettet?» ved hver teknisk problemstilling. Man kan ikke forvente at alle har grunn til å kjenne til alle bestanddelene i ytelsesbudsjettet.

Dette dokumentet kan ses som en retningslinje rundt nettstedets kvalitet og laveste akseptable nivå innenfor en mengde områder man spesifiserer, for eksempel tilgjengelighet. Ytelsesbudsjettet bør gjerne lanseres på en høytidelig måte slik at alle involverte forstår at fra og med nå har man en målbar virkelighet å forholde seg til. At det gjelder så vel webutviklerne, IT, redaktørene og alle andre som påvirker nettstedet. Personlig synes jeg at man dessuten bør gjøre det offentlig tilgjengelig på nettet, da blir det enda vanskeligere å ignorere eller glemme.

Du lurer kanskje på hva poenget er med et ytelsesbudsjett? Ditt ytelsesbudsjett er din måte å klargjøre organisasjonens servicenivå i digitale kanaler, men også de målepunktene du kontrollerer når du gjør din tilbakevendende innholdsrevisjon. Som at sidetitler er passende lange, etc.

Hvis du lurer på om webytelse egentlig spiller noen rolle, kommer du snart til å få bevis i overflod. Men om vi for øyeblikket nøyer oss med den ytterst objektive og kvantitative måten å se på saken, kan jeg henvise til en undersøkelse som Walmart har gjort. De har funnet en veldig tydelig sammenheng mellom lastetiden for en nettside og hvor godt de brukerne konverterer, det vil si at brukerne gjør noe ønsket på nettstedet.

: Bilde 32: Walmart har funnet en sammenheng mellom ytelse og konvertering.

Det er alltid verdt å minne seg selv om at med ytelse skal man også tenke inn ordet prestasjon, i stort, det handler ikke bare om hastighet.

Eksempel på et ytelsesbudsjett

Nedenfor kan du se de punktene vi valgte ut på min arbeidsplass for vårt første ytelsesbudsjett³², som jeg utarbeidet for Västra Götalandsregionen i 2015.

Begynnelse på sitat.

Ytelsesbudsjett og målbar webkvalitet for www.vgregion.se

Dette er innledende dokumentasjon og avtale rundt prosjektet for oppgradering til Episerver CMS samt det nye grensesnittet.

Les kravene nedenfor som at de måles med representativt innhold på testsider utviklerne lager i forkant av avstemming med prosjektets utpekte webanalytiker. Disse testsidene skal ikke kunne påvirkes nevneverdig av VGRs redaktører mellom testtidspunktene, de skal være sammenlignbare over tid.

En leveranse som mislykkes med disse kravene skal ikke settes i produksjon og skal ikke aksepteres av VGR.

1. Verdier, prioriteringer og prestasjon for hele nettstedet

Følge designkonvensjonene progressive enhancement samt mobile first, det vil si fokusere på tilgjengelighet først og finesse siden, samt at det er det mobile scenarioet som setter behovene rundt design og funksjon.
Funksjon foran form, og opplevelsen fremfor teknikaliteter. Det vil si inkluderende design, både for funksjonshemmedes mulighet til å delta men også for å nå så mange typer utstyr som mulig.

2. Målbart ytelsesbudsjett

Maks 399 kb for en sidevisning.
Under 3 sekunder for komplett lasting av side, målt fra gunstig kablet tilkobling.
Under 10 sekunder for komplett lasting av side målt på 3G-tilkobling.

3. Minimumsnivå på web

Disse punktene beskriver det laveste aksepterte nivået for første iterasjon av www.vgregion.se, det nivået skal ikke forverres under kommende oppdateringer, snarere skal disse kravene skjerpes løpende i samråd med utviklerne.

Alle maler/visninger/komponenter i nettstedet skal som aller minst:

Være testet og sikret mot WCAG 2 nivå AA.
Anses å være mobilvennlige ifølge Googles mobilvennlighetstest.
Med eksempelinnhold oppvise minst 85 av 100 i Google Pagespeed med mobile innstillinger, og minst 90 for datamaskin.
Maks 2 CSS-filer lastes inn.
Maks 3 Javascript-filer lastes inn.
Bruke CSS Sprites (eller tilsvarende teknikk) for å redusere antallet bildefiler å laste ned.
Strukturell CSS-kode inkluderes i HTML-koden i henhold til god ytelsespraksis for rask innledende visning av innholdet.

Slutt sitat.

Ja, dette var hva vi før prosjektet ble enige om internt og også sammen med våre webkonsulenter. Du lurer kanskje på hvordan det gikk? Jo, den første versjonen av ytelsesbudsjett jeg har jobbet igjennom på min arbeidsplass har vi stilt det absolutte kravet om å følge tilgjengelighetsretningslinjen WCAG 2.0 som minimum på nivå AA. Det burde ikke direkte være kontroversielt med tanke på at mangelfull tilgjengelighet siden 2015 anses som diskriminering ifølge loven og siden 2016 er noe som EU har besluttet om som tvungent for alle myndigheter – da inkludert intranett og ekstranett.

Dessuten noen mål for hvor raskt det skal gå å laste ned en side. Der ble det vel en plutselig oppvåkning i designarbeidet for vårt kommende nettsted om at man ikke kan sløse som man vil med utsmykkende elementer. Vi har satt grensen ved 399 Kb, og da bør redaktøren ha i det minste 140 Kb til å kunne legge opp et tyngre bilde.

Et punkt som måtte vike i første versjon av ytelsesbudsjettet var en verdivurdering om at «Verne om besøkernes integritet. Ingen som helst tredjepartstjenester, for eksempel Google Analytics, sosiale dele-knapper, etc.» Det spørsmålet trengte å håndteres separat. Men verdivurderingen som sådan rundt integritet fantes likevel i andre dokumenter, blant annet i IT-sikkerhetspolicyen.

: Bilde 33: Grafen fra Pingdom viser at en driftsetting av ny kode midt i mars gjorde nettstedet i snitt 0,3 sekunder tregere.

Vi begynte å måle allerede under utviklingsfasen. Et interessant funn var at en oppdatering av det kommende nettstedet gjorde det i snitt 0,3 sekunder tregere ifølge Pingdoms verktøy for å måle svartid. Jeg synes det er et funn fordi man nå kan snakke tall i stedet for subjektiv magefølelse. På denne måten har man mulighet til å veie fordeler og ulemper, om de nyhetene som ble introdusert faktisk er verdt 0,3 sekunder tregere svartid. Det er de kanskje, men man kan ikke legge på 0,3 sekunder i ekstra svartid ved hver eneste oppdatering. Før eller senere kommer man til å slå i taket for den sidelastetiden man har satt opp i ytelsesbudsjettet. Ved å ha lang historikk av data kan man ha et bedre underlag enn ellers til hva man tror man trenger å rette opp for ikke konstant å forverresituasjonen.

I vårt tilfelle regner jeg kaldt med at vi kan kaste penger på problemet og kjøpe mer maskinvare, men samtidig hadde vi en storskalig cache-løsning på gang som IT-avdelingen var oppspilte rundt. Den skal som aller dårligst halvere tiden for å vise sidene.

Men det finnes selvfølgelig massevis av andre problemstillinger der man kan ha nytte av å på forhånd spesifisere sin ambisjon rundt ytelse og prestasjon. Selvfølgelig skal et nettsted av i dag anses å være mobilvennlig. I det finnes mange ting man trenger å måle, både designen i stort men også det som havner på nettstedet. Vi har presisert dette til dels at Googles testverktøy skal anse at alle typer maler i vårt publiseringsverktøy er mobilvennlige, med en form for eksempelinnhold. Dette er kravet til de som bygger vår web. Så blir det å følge opp at redaktørene ikke ødelegger den opplevelsen ved å legge inn kjempebrede tabeller og så videre.

Kontinuerlig måle kvaliteten på nettsiden

For å være tydelige og forutsigbare overfor våre leverandører har vi i fellesskap satt opp testsider. Disse testsidene skal ha som minst 85 av 100 i karakter ifølge verktøyet Google Pagespeed, da med mobile innstillinger. For en datamaskin skal det være minst 90 av 100 i karakter. Disse tallene bør de sjekke allerede før de driftsetter noe nytt. Det er ikke akseptabelt at noe forverrer karakteren. I det minste skal ingenting som ikke er begrunnet få lov til å forverre karakteren.

Grunnen til at det er akkurat 85 av 100 er fordi Google har satt det som det nivået der de anser nettstedet som velkonstruert. Vi vil gjerne leve opp til dette nivået da det ikke er helt uvesentlig hva Google mener om ens nettsted om man vil ha besøkende fra deres søkemotor.

Vi har også satt begrensning på antallet filer som kreves for å laste inn en side. Grunnen til dette er at for hver fil som skal lastes ned finnes en ventetid, jo flere filer desto lengre blir den totale ventingen på at siden blir ferdig. Dette er ikke et særlig stort problem under gunstige forhold når vi sitter på kontoret, men det merkes virkelig forskjell når man er på en ustabil 3G- eller Edge-tilkobling ute i grisgrendte strøk. Jeg som plukker masse sopp merker dette når jeg tar en pause og sløvsurfer litt. Tenk da om man har et viktigere ærend enn å lese en artikkel på The Verge. Type finne nummeret til Giftinformasjonen, eller gjøre et bildesøk for hvilke sopper man ikke skal smake på?

Plukk ikke våre tall og krav rett av til bruk på hjemmebane. Ta den dialogen med deres leverandør om hva som er en rimelig ambisjon på den plattformen dere har. Kanskje bør dere legge seg i selen ved neste litt større inngrep på nettstedet, snarere enn å pusse på det som snart skal gjøres om.

Poenget med å opprette en liste over ytelseskrav til sin stilguide er å ha en målbar måte å sikre at ens nettsted ikke forverres over tid, eller etter lansering. Snarere at det kontinuerlig forbedres for hver oppdatering.

En liste som dette ytelsesbudsjettet kan supplere de testprotokollene som webutviklerne har, i det minste for større nettsteder, for å verifisere at et webprosjekt holder riktig kvalitet. Dessuten har mange av oss sjekklister for det kommunikative, det vil si hvordan tiltalen skal være og hvilke skriveregler man skal følge, noe som innebærer at dette blir en naturlig del av den kontinuerlige oppfølgingen og refleksjonen om hvordan det går for nettstedet. Hvis det ikke finnes en utpekt webanalytiker, er det trolig en webutvikler man trenger for å sammenstille rapporten om hvordan nettstedet presterer, eller om man bare velger verktøy som Pingdom som de fleste klarer selv. Vi kommer til å snakke mer om spesifikke verktøy i neste del av boken.

Hvis du driver et større nettsted, er det en god idé å interessere seg litt for hvilke tester utviklerne har for å forsikre deg om at riktig kvalitet oppnås. Disse testene kan være alt fra helt manuelle til fullstendig automatiserte. Visse av punktene i ditt ytelsesbudsjett påvirkes nemlig av den arbeidsflyten som webutviklerne har, og visse av punktene er enkelt å løse gjennom konfigurasjon av byggeservere. Som Jenkins, eller andre verktøy, som mange bruker for kontinuerlig leveranse da mange produksjonssetter oppdateringer til nettstedet – opptil flere ganger om dagen.

: Bilde 34: Stadig flere «deployer» oppdateringer av sine websystemer daglig.

Men hvorfor er ytelse så jævlig viktig?

Det finnes mange som har forsket på ytelse (her forstått som hastighet, ikke nødvendigvis som prestasjon). Primært pleier man å henvise til Nielsen-Norman Group³³ som har delt det opp i tre deler, nemlig at brukeren ved:

0,1 sekunders svartid slutter å oppleve at svaret er umiddelbart.
1 sekunds svartid begynner tankestrømmen å hindres av en opplevd ventetid.
10 sekunders svartid har brukeren vanskelig for å være oppmerksom og vil gjøre noe annet i mellomtiden.

Med andre ord forårsaker man en kognitiv belastning hos alle brukere som har en treg opplevelse. Og som Walmart har vist, er en treg opplevelse mindre nyttig ved at brukerne i mindre grad konverterer. Flere bevis for sammenhengen mellom hastighet og nytte kommer straks.

Da Google gjorde et omtak for sitt ikke direkte verdensomveltende sosiale nettverk Google+ høsten 2015, satte de et hardt ytelsesbudsjett.

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 sider³⁴

Google+ gikk fra å ha hatt 22,6 Mb vekt på startsiden sin til 0,3 Mb (HTML og bilder). Fra 251 filer som trengte å lastes ned til kun 45 stykker. 2,77 Mb Javascript og CSS til 0,11 Mb. For lastetider gikk de fra 12 sekunder i snitt ned til 3 sekunder. Dessuten trimmet de bort fettet ved å gå fra 0,7 sekunder for brukeren å begynne å motta filer ned til kun 0,1 sekunder, såkalt time to first byte (TTFB).

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

Som om ikke det var nok, finnes det rikelig med studier som viser sammenhengen mellom ytelse og hvor nyttig brukerens sesjon har vært. Disse organisasjonene har delt med seg om hva som skjedde med deres tjenester da de forbedret hastigheten. Se ytelsesreferanser i slutten av boken, for eksempel:

Google: 2 % tregere = 2 % færre søk per bruker
Yahoo: 400 millisekunder raskere = 9 % mer trafikk
AOL: Raskere sider = flere sidevisninger
Amazon: 0,1 sekunder raskere = 1 % mer omsetning
Shopzilla: 5 sekunder raskere = 25 % flere sidevisninger, 7 til 12 % mer omsetning
Aberdeen Group: 1 sekund tregere = 11 % færre sidevisninger, 7 % færre konverteringer.
Gomez: 75 % av brukerne i nettbutikker forlot heller nettstedet til fordel for en konkurrent enn å tålmodig vente.
Tagman: For hvert sekund tregere lastetid taper man 6,7 % konvertering, interessant nok konverterer 1-2 sekunders lastetid best, ikke de raskeste (se graf nedenfor).
Etsy: 160 Kb med bilder økte avvisningsfrekvensen med 12 %.

Som prikken over i-en har Google med webytelse i sin rangeringsalgoritme, så vil du ikke sakke etter i søkeresultatene, er kanskje også det en gulrot til å kjempe litt ekstra med ytelsen.

: Bilde 35: Tagman måler konverteringsnivå basert på hvor lang lastetiden er.

For den som heller leser akademiske rapporter, sjekk ut referansene i slutten av boken for å finne eksempler helt siden 1960-tallet frem til i dag. Der finner du også lenker til ovennevnte fakta, det finnes mer interessant å hente i de skrivelsene.

Hvilke tidlige lærdommer finnes fra Västra Götalandsregionens arbeid?

På min arbeidsplass har vi gjennomført vårt første prosjekt som har måttet forholde seg til et ytelsesbudsjett, nemlig vår oppgradering av Episerver CMS. Det er et ganske omfattende og komplekst prosjekt. Det finnes massevis av interessenter høyt og lavt i organisasjonen ettersom det som lages er en felles grunnstamme for alle ulike forvaltninger innenfor denne svært store organisasjonen med mange vidt forskjellige virksomhetsretninger. Den felles webmalen skal utgjøre grunnstammen til et titalls ganske store nettsteder for våre ulike sykehusgrupper, primærhelsetjenesten, tannhelsetjenesten og noen kulturnettsteder.

Nå er jeg selvfølgelig noe partisk, men jeg opplever at kollegaer og konsulenter etter en stund har begynt å sette pris på den konkretiseringen som ytelsesbudsjettet har bidratt til i visse spørsmål. Våre webkonsulenter har til og med uttrykt at de er entusiastiske rundt dette. Det gleder meg enormt.

1. «Nå kjører vi med denne unike skrifttypen, det gjør det hele penere»

En annen nyttig konkretisering rundt design fikk vi da spørsmålet om spesielle skrifttyper var i tråd med vårt ytelsesbudsjett. Verdivurderingene rundt integritet spisset til diskusjonen rundt egne skrifttyper på en givende måte, utover det som hadde med ytelse å gjøre. Det viste seg at utover en årlig abonnementskostnad for å ha en egen skrifttype kun for overskrifter, trengte vi å inkludere en ekstern CSS-fil for å la selgeren av skrifttypen ha kontroll på hvor mange sidevisninger vi har. Fordelen med denne skrifttypen var åpenbar, at det så bra ut. Ulempene ble takket være ytelsesbudsjettet også de tydelige og kunne stå som motvekt i vår interne diskusjon, nemlig at:

Vi var nødt til å ha en tredjepartsfil med på alle våre sidevisninger. Det satte integriteten i fare at man ikke vet hvem andre som lytter inn i den kommunikasjonen. Er man ortodoks rundt cookie-loven, får vi ikke lov til å bruke tredjeparter på denne måten, i det minste ikke uten et aktivt samtykke fra hver bruker, dette før skrifttypen lastes ned og brukes.
En ekstra fil trengte å lastes ned, uten noen direkte gevinst for våre brukere. Vi hadde satt 2 stykker CSS-filer som grense, skulle vi da slippe en av de to kun fordi en ekstern part ville overvåke at vi ikke overskred antallet sidevisninger vi hadde kjøpt for en skrifttype?
For å dekke inn de ulike variantene av skrifttypen, som kursiv, fet, etc., trengtes opptil 4 stykker filer lastes ned til brukerne. Under mindre gunstige forhold kan disse filene ta noen sekunder bare i ren ventetid uansett hvor små de er. Med andre ord kunne man bare med disse filene sprenge budsjettets tenkte maksimale tid for nedlasting.
Skrifttypefilene ville totalt veie inn på omtrent 80 Kb. Totalt for en hel sidevisning hadde vi satt en grense på 399 Kb. I de fleste sidevisninger ville denne spesielle skrifttypen vist på 2-3 overskrifter på en hel side. Var det da verdt det at 20 % av den totale vekten skulle gå til dette? Fantes det andre skrifttyper som fikk jobben gjort, men med mindre påvirkning?

Så spørsmålet ble ganske tydelig. Var det verdt det for å ha en spesiell skrifttype? Innledningsvis ble svaret et rungende nei. Georgia fikk duge, det fantes tross alt allerede hos praktisk talt enhver av våre brukere i deres enheter, helt uten de ulempene som i og med ytelsesbudsjettet ble så åpenbare for de involverte. Med andre ord ble det ikke bare et spørsmål om design, typografi og om kostnaden var ok. Diskusjonen fikk høyst merkbar konsekvens overfor ytelsesbudsjettet. I en fremtidig verden om praksis endres rundt hvordan vi håndterer besøkernes integritet, er det ikke gitt at tredjepartsinvolvering i det hele tatt ville bli tillatt.

Svaret på spørsmålet var å i det minste inntil videre la være spesielle skrifttyper. Finner vi en løsning som har mindre innvirkning på ytelsen, blir kanskje beslutningen annerledes.

2. Topptekstbakgrunn vs kontrastforhold

Helt grunnleggende for god tilgjengelighet er at man har et kontrastforhold mellom forgrunn og bakgrunn. Det merker man ikke minst selv når man prøver å bruke mobiltelefonen sin i sterkt sollys utendørs.

Grunnen til at det kan være vanskelig å leve opp til god kontrast mellom tekst og bakgrunn på et responsivt nettsted skyldes at ting ikke er fiksert i sin posisjon. De liksom flytter rundt litt avhengig av hvilket rom som finnes tilgjengelig. Så i vårt første designforslag hadde vi ikke kommet frem til en løsning som ikke påvirket de med nedsatt syn negativt, dermed ble det ikke noe bakgrunnsbilde. Her kom vi også litt i konflikt med den grafiske manualen da den krevde dette bakgrunnsbildet, noe som ikke er et problem med trykksaker gjennom deres fikserte layout da man vet nøyaktig hvor ting er plassert. Dette ble en nyttig øvelse i å diskutere design og pekte kanskje på behovet for et mer digitalt syn i den grafiske manualen.

Å kombinere bakgrunnsbilder i en responsiv topptekst og garantere god kontrast viste seg å være en vanskelig nøtt å knekke. Ettersom vi ikke følte oss overbevist om at dette kunne bli både pent og tilgjengelig, forsvant topptekstens bakgrunnsbilde med henvisning til etterlevelse av tilgjengelighetsretningslinjen WCAG.

De der subtile nyansforskjellene som mange designere ofte er veldig avhengige av, fungerer ikke så bra lenger i en mobil virkelighet. Samtidig har de aldri fungert særlig bra for de med nedsatt syn, først nå oppdager også vi andre det.

En relatert anekdote var da en art director skulle vise frem det han hadde designet for oss. Da nyansene helt forsvant slik som projektoren viste det, beklaget han seg og forklarte at det var penere på skjermen hans. Det hjelper ikke. Vi kan ikke forvente at alle brukere har en sinnssykt dyr Ultra-HD-skjerm som er fargekalibrert og har perfekte kontraster. Folk sjekker inn nettstedene våre på sin halvt mishandlede mobiltelefon, utendørs midt på dagen på sankthansaften i sterkt sollys. Det er bare at vi venner oss, fortiden kommer ikke tilbake.

3. Hvordan hente inn eksterne nyhetskilder?

Jeg har mange ganger irritert utbrutt «hvor vanskelig kan det være?» når noe har føltes selvfølgelig og enkelt. Et slikt spørsmål som syntes å være enkelt løst, fremsto litt i et annet lys på grunn av ytelsesbudsjettets mål om sidelastetid.

Det finnes nemlig et behov for å samle inn en eller flere eksterne nyhetskilder (via teknikken RSS) og vise dem som en nyhetsspalte på sitt eget nettsted. Det slitte uttrykket om at ingen kjede er sterkere enn det svakeste leddet er tydelig når man blander inn flere parter for å kunne vise sin nettside. For eksempel, hvordan håndterer man om noen av de der eksterne nyhetskildene ikke er oppe, eller svarer først etter 10 sekunder? Slikt skjer. Ikke minst under en samfunnskrise kan disse problemene begynne å vise seg, men det holder jo med at enten ditt eller deres nettsted får en økt belastning for at ditt nettsted skal gå ned.

Hvis nettstedet skal vise seg på under 3 sekunder, er det bare å begynne å addere sammen svartidene på det antallet eksterne kilder man gjør seg avhengig av. Det finnes nok ingen grunn til å være sikker på at alle sammen garantert svarer på mindre enn 3 sekunder, og da har man likevel brukt nesten hele sitt budsjett for sidelasting bare på denne funksjonen.

Vi har ikke kommet frem til en klokkerent løsning ennå som er en passende stor utgift. Et alternativ som IT utredet er om man kan bruke en teknisk løsning som mellomledd mellom nettstedene og de nyhetskildene som skal overvåkes. Da kan man for eksempel forsøke å isolere venting og feilhåndtering til en programvare som er god på den oppgaven, eller i det minste bedre enn vårt CMS.

Ved å innføre et mellomledd for akkurat dette problemet, får man kanskje et mer reelt kostnadsoverslag, slik at ikke resten av nettstedet må bære den kostnaden. Den spesialiserte løsningen designes kanskje for å vente maksimalt 0,2 sekunder på å få svar fra de eksterne kildene. Og får man en isolert prislapp for akkurat denne funksjonen, kommer man kanskje frem til at nyheter er så viktig at det er verdt det.

Hvordan få aksept for et ytelsesarbeid?

Det finnes nok mange utfordringer med å selge inn behovet for et ytelsesarbeid, særlig om de det berører ikke har en kultur for målbarhet. Jeg selv har møtt en del motstand, tvilende kollegaer og deltakere på konferanser der jeg har forelest om emnet. Det er sunt å være skeptisk, også til dette. Men jeg tenkte å komme med noen tips om hvilke beveggrunder jeg tror du kan finne hos de du trenger å påvirke.

En webutviklende venn, på et ikke involvert webbyrå, kommenterte hvorfor han ville like å levere i samsvar med et ytelsesbudsjett slik:

Når noen stiller krav betyr det at de bryr seg og verdsetter resultatet.
- Filip Dalväg³⁵, frontend-utvikler på webbyrået Netrelations

Jeg tror at mange utviklere er enige med Filip, i alle fall så fort de har forstått hva det handler om. Praktisk talt alle vil gjøre en så god jobb som mulig, og dette er en målestokk for godt arbeid som utviklere har lett for å ta til seg, det er jo skrevet mest på deres språk. Så er det absolutt ikke slik at det skulle finnes en enighet om nøyaktig hva som er god praksis om man spør to forskjellige utviklere. Mange valg er slikt som er en vurdering om hva man tror gir mest nytte, og det er lett å havne i nærmest religiøse diskusjoner om rett og galt i hvordan man anser at håndverket skal gjøres.

Poenget med å ta denne diskusjonen blant utviklerne, eller med sitt byrå, er å forsøke å nå en enighet om hva som er godt, og så dokumenterer man det som utviklernes forslag til ytelsesbudsjett.

For alle som er involvert i utviklingen eller forvaltningen av et nettsted kan man trenge å sørge for at følgende aktiviteter gjøres, muligens i denne rekkefølgen:

Evangeliser budskapet om at man som gruppe kan gjøre det enda bedre, og vis til referanser om hvilken forskjell ytelse kan ha for at nettstedet skal bidra med enda mer verdi til virksomheten. Glem for guds skyld ikke kakene så folk holder seg våkne! :)
Arranger forelesninger, lunsjtreff med diskusjoner og utdann folk i emnet.
Workshop frem et første forslag til ytelsesbudsjett. Deltakere trenger å være de som kan drift, utvikling, design og de som følger opp virksomhetens nytte av nettstedet.
Kommuniser ut ytelsesbudsjettet! Hvis ikke alle berørte kjenner til det, kommer ikke mye til å skje. Sørg for at alle fra nettstedets «fra A til Å» kjenner til ytelsesbudsjettet og har fått anledning til å uttrykke eventuelle betenkeligheter med hvordan det er utformet.
Sørg for at det finnes verktøy for kontinuerlig oppfølging, det er noe vi som jobber spesifikt med webanalyse trenger å gjøre uansett om vi har kommet i gang med å aktivt forbedre ytelsen. I mitt tilfelle, som forvalter av vårt ytelsesbudsjett, planlegger jeg å sjekke vår etterlevelse én gang per kvartal, men mange ytelsesbudsjetter vil sikkert utformes slik at oppfølging kan skje automatisk hele tiden.
Gi oppmerksomhet til de personene og teamene som lykkes med å forbedre ytelsen på nettstedet. Som konsulent pleide jeg selv ofte å oppmerksamme mitt teams fremgang med å kjøpe smørbrødkake og tilegne feiringen til den som hadde gjort en innsats som imponerte meg.
Heng med i utviklingen. Hva som er praksis innen nettet endrer seg fort, og med det også hva man gjør for god ytelse. Et spørsmål er hvordan en overgang til HTTP/2 påvirker den ytelsesoptimaliseringen som er gjort. Mer om dette i del 4 av boken.
Kommuniser endringer. Ytelsesbudsjettet kommer til å trenge forvaltning og oppdateringer. Jeg selv har planlagt å årlig se over det vi har på min arbeidsplass.

På min arbeidsplass gjorde jeg alt ovennevnte selv. Som tidligere webutvikler hadde jeg kanskje det litt lettere enn mange andre webanalytikere å ta inn alle detaljer om ytelsesoptimalisering, men primært gjorde mine tidligere erfaringer det enklere å kunne forsvare og begrunne visse veivalg. Det tok noen måneder, så begynte våre webkonsulenter å belære meg om nye ting de hadde lært seg. Som roundtrips over nettet, da alt sendes i 14 Kb-store pakker, samt at de hadde forslag til hvordan vi kunne gjøre en enda bedre jobb. På et eller annet vis ble konkurranseinstinktet tent om hvordan de kunne overprestere. Slikt liker jeg.

For å få med seg beslutningstakere om at dette er verdt å legge litt anstrengelse på, kan det være vellykket å først gjøre en konkurrentanalyse. Så rapporterer du hvordan dere står dere i konkurransen og hvilke konkrete aktiviteter dere bør ta tak i for å bli (enda) bedre. Det finnes massevis av verktøy for dette, og flere av dem kommer vi til å se nærmere på i de følgende delene av boken. En visuell, og dermed veldig pedagogisk, måte å vise forskjellen mellom ens eget nettsted og noen andres er Webpagetest.orgs funksjon Visual Comparison. Der kan man legge til ett eller flere nettsteder for å se hvor visuelt komplette de er og sammenligne dem med hverandre.

: Bilde 36: Sammenligner man Aftonbladet med Expressen, er Expressen mye raskere til å vise sitt innhold på en treg mobil tilkobling.

La oss si at dere er dårligere enn verste konkurrent, det er nok motivasjon til å få et mandat til å begynne å agere og med det et passende budsjett. Det er webanalytikerens jobb å undersøke om det finnes god nok grunn til å jobbe med ytelse, men også å kunne følge opp at hver innsats er verdt anstrengelsen.

Fortsett å lese – Del 3: Webanalyse: Fordypning