Fördelar med prototypdriven design

Prototyper är något som det talas mycket om inom UX- och digitala designkretsar just nu. Men vad är meningen med prototyper? På vilket sätt kan prototyper hjälpa oss att skapa bättre produkter och användarupplevelser? Är det inte bara slöseri med tid att skapa något som sedan kastas i papperskorgen när det väl är klart?  

En prototyp är till för att underlätta kommunikation och visualisera idéer. Genom den kan vi undersöka olika lösningar - väga fördelar mot nackdelar samt att upptäcka brister och fallgropar innan produkten sätts i produktion. 

En trend eller?

Redan de gamla grekerna (äntligen får jag använda det uttrycket!) och egyptierna använde sig flitigt av prototyper för sin ingenjörskonst. The Great Pyramid of Giza stod klar år 2528 f.k vilken innebär att den klarat runt 5000 år. Konstruktionen är fortfarande stadig och lär stå i ytterligare årtusenden. Vad man ska ha klart för sig är att den stora pyramiden inte byggdes i en handvändning. Pyramiden tog århundraden att färdigställa men det var en iterativ process – ett prototypbyggande för att hitta den ultimata konstruktionen och designen. Förutom att bygga pyramiden prototypdrivet tittade man även på snarliknande konstruktioner och inspirerades, även sådant som inte fungerade togs i beaktning. Vill man förkovra sig i prototypbyggandets historia ska man snöa in på Da Vinci och andra stora konstnärer och uppfinnare genom tiderna. Det är häftig läsning! 

Med andra ord – prototyping är inte en trend. Det är ett fundament för många av de byggnader, produkter, uppfinningar och forskningsgenombrott som vi ser och får ta del av idag.

Bra för mycket!

De stora fördelarna med att arbeta prototypdrivet med design är att vi verkligen får förståelse för funktioner och innehåll, istället för att försöka tolka krav. 

Genom att få snabb feedback på en prototyp kan vi upptäcka fel och brister tidigt som helt enkelt leder oss till ett bättre resultat. Både vår kund och dess användare kan tidigt få en känsla för produkten och har möjlighet att påverka utformningen och lösningen i realtid. I praktiken kan vi redan vid sittande möte eller testsituation ändra på lösningen och få feedback tillbaka direkt. 

Det viktiga är att det blir rätt typ av feedback – det vill säga inte feedback som handlar om utseende utan istället funktion och pedagogisk utformning. De flesta av oss designers har hört feedback så som ”lite grönare”, ”gör knappen större”, ”flytta sökfältet några pixlar till höger”, ”det här känns inte som Apple” etc.  Genom att arbeta prototypdrivet med design och fokusera på koncept och idé minskar vi tyckande om färger och form. 

Exempel på prototypverktyg 

Det finns en uppsjö av prototypverktyg där alla har sina för- och nackdelar. Huvudsaken är att du hittar en process som passar ändamålet och väljer verktyg utifrån det istället för tvärt om.

Här följer några exempel på prototypverktyg. Ladda ner testversioner eller sajna upp dig på testrunda och bara kör!

https://www.uxpin.com/ 

https://www.flinto.com/ 

http://principleformac.com/ 
 
https://www.fluidui.com/ 

https://marvelapp.com/ 

http://www.invisionapp.com/ 

http://www.axure.com/ 

https://atomic.io/ 

http://www.pixate.com/ 

https://popapp.in/ 

https://prottapp.com/ 

http://www.relativewave.com/form/ 

http://www.getcomposite.com/ 

https://developer.apple.com/xcode/ 

https://webflow.com/ 

http://macaw.co/ 

http://facebook.github.io/origami/ 

http://www.justinmind.com/ 

https://proto.io/ 

https://www.sketchapp.com/ 

https://balsamiq.com/ 

https://www.omnigroup.com/omnigraffle 

Alternativ är förstås papper och penna:

https://www.smashingmagazine.com/2012/09/free-download-ux-sketching-wireframing-templates-mobile/ 


Eller att hacka lite kod: 

http://foundation.zurb.com/ 

http://getbootstrap.com/ 

http://semantic-ui.com/ 

http://purecss.io/ 

http://getuikit.com/ 

Så bygger du starka team och fantastiska produkter

Jag vill att du smakar på de här orden:

Din produkt blir aldrig bättre än hur dina teammedlemmar mår och den kvalitet de levererar.

Fundera!

Upprepa!

Din produkt blir aldrig bättre än hur dina teammedlemmar mår och den kvalitet de levererar.

 Kan det vara så enkelt tänker du? Ja, rätt så enkelt när allting kommer omkring.

Jag har varit i webbranschen sedan 1995. Det har blivit en del projekt och produktioner genom åren. Både som medlem i team men också som projektledare och produktägare.

Varje projekt (nu +700 stycken) har jag utvärderat och fört statistik över. Rätt nördigt, jag vet. På sätt och vis har det blivit en privat forskning över drivkrafter i projekt men framför allt en bra reflektion över vad det är som bygger starka team och fantastiska produkter.

En reflektion jag gjort genom åren är att man från ett ledningsperspektiv ofta väljer att arbeta med två hörn i projektpyramiden: Tid och Kostnad.

Kvalitet är ofta något som får stryka på foten.

Men vad är det som spelar störst roll för teammedlemmar? Jo, kvalitet i vårt arbete.

Självklart är vi ju inte ointresserade av att leverera i tid och att projektets budget hålls, men kvalitet i vårt arbete är det som driver oss att gå till jobbet varje dag. Att känna att det man designar och bygger har ett värde för användarna och för affären samt att vi kan sätta en kvalitetsstämpel på det vi lämnar ifrån oss. Det är viktigt på riktigt! 

I kvalitetskriteriet kan du hitta en mängd olika faktorer som spelar in. Men så länge projekten drivs med Tid och Kostnad kan du aldrig bygga starka team eller få fantastiska produkter. I varje fall inte på sikt.

Ju fler projekt, funktioner och designlösningar vi tvingas att leverera till en låg kvalitet, ju mer urvattnas vår drivkraft och vårt engagemang. Till slut går vi vidare till andra arbetsgivare och produktägare i tron om att gräset är grönare på andra sidan. Men det är ju inte det vi egentligen vill. Vi vill bygga och designa riktigt bra produkter med hög kvalitet. Som spelar roll för de som använder dem. Som är tillgängliga. Som levererar kvalitet till affären.

Istället för att fråga oss hur många features vi klarar av att få med i nästa sprint – fråga oss istället hur mycket kvalitet vi klarar av att leverera och om vi har rätt förutsättningar för att göra det.

Designa produkter och tjänster för hur vi ser världen

Jag har nyligen börjat en utbildning där vi fördjupar oss i visuell perception. Det vill säga förmågan att med hjälp av synintryck tolka yttre stimuli. I min roll som UX Designer hjälper det mig att skapa design som inte enbart tilltalar estitik utan även kommunicerar med vår hjärna och uppfattningsförmåga.

Första lektionen handlade om ögats uppbyggnad och bland annat hur tapparna i ögat får oss att se i dagsljus och uppfatta färger, något som försvinner ju mörkare det blir ute. Vi ser inte färger i mörk skymning. Kontraster på våra skärmar blir allt viktigare att hålla koll på då våra skärmar inte enbart befinner sig i vardagsljus inomhus. Vi kan surfa från mobilen i starkt solljus likväl som i totalt mörker (tänk morgonen när vi kollar Facebook och surfar in på morgonnyheterna innan vi gått upp ur sängen).

Att UX design handlar om att sätta människan i fokus och att lyfta fram hens behov och drivkrafter är det sällan någon som ifrågasätter numera. Men samtidigt vill jag i min roll kunna gå djupare än att definiera ett behov, en drivkraft och koppla det til en funktion, innehåll eller koncept.

För mig handlar det lika mycket om att lära mig om människan bakom användaren. Jag vill få en förståelse för möjligheter, begränsningar, förutsättningar och egenheter. Och för att göra det behöver jag få ännu djupare kunskap om hur vi faktiskt fungerar - på insidan.

Jeff Johnson har skrivit en bok som heter "Design with the mind in mind" som jag verkligen kan rekommendera till den som vill fördjupa sig inom området. 

Under nästa år kommer jag fokusera mycket på att designa produkter och tjänster för hur vi ser världen. Vårt beteende och möjligheter med tekniken förändras ständigt i en allt snabbare värld - men våra sinnen och visuella förmåga är intakt.

Att välja typsnitt till den responsiva webbplatsen

Typsnitt har genom alla tider väckt mycket känslor. De är en stark bärare av ett kommunikativt budskap och det är inte konstigt att kända varumärken använder typsnitt som sin främsta identitetsbärare genom sin logotyp. Ericsson gör det, IKEA gör det, Coca-Cola gör det, Disney gör det och så vidare.

Men hur ska man tänka när det kommer till typsnitt på den egna webbplatsen? Gäller fortfarande de standarder som var aktuella runt år 2000 då de flesta valde Arial eller Verdana till sin webbplats? Och hur ska man tänka kring den responsiva webbplats som ska kunna läsas från en mängd olika digitala enheter så som mobil, surfplatta, smartphone, smartTV och spelkonsollen?

En sak att fundera på vad gäller den responsiva webbplatsen är att sajten behöver ladda snabbt. Hur påverkas då den responsiva webbplatsen av olika typsnittslösningar?

Nedan redogör jag för några tankegångar, för- och nackdelar och ger förslag på olika lösningar. Jag avslutar också med ett test där jag tittar på hur snabbt en sajt laddar med olika typsnittslösningar (standard och en onlinetjänst).

STANDARDTYPSNITT FÖR DEN RESPONSIVA WEBBPLATSEN

Din webbplats ska kunna läsas från en mängd olika enheter så som mobil, desktop och surfplatta. Om du vill välja bland standardtypsnitt som kommer att finnas installerade på dessa enheter kan du välja på följande i listan:

  • Arial/Helvetica
  • Courier/Courier New
  • Georgia
  • Times/Times New Roman
  • Trebuchet MS
  • Verdana

Dessa anses vara mobilsäkra typsnitt. Äldre versioner av Android kommer dock att byta ut serif fonts till Droid Serif och sans-serif till Droid Sans.

FÖRETAGETS EGNA TYPSNITT

Med tjänster som https://typekit.com/ har vi länge kunnat erbjuda företagets egna typsnitt på webbplatsen. Typekit är en onlinetjänst där man prenumerar på ett typsnitt som då läses upp på den egna webbplatsen. På så sätt behöver besökaren inte ha det specifika typsnittet installerat på sin dator för att få se det på webben (eller i mobilen).

Ett annat alternativ är också att lägga upp det egna typsnittet på webbservern och låta webben läsa därifrån. Oavsett tillvägagångssätt finns det både för- och nackdelar.

Prenumeration på en onlinetypsnittstjänst kostar en liten summa, men du kan aldrig vara säker på att tjänsten är uppe och rullar 24-7 eller att det inte blir någon delay på typsnittsrenderingen på din webbplats. Speciellt problem med å,ä och ö kan uppstå emellanåt.

Att lägga typsnittet på sin egen webbserver är då lite säkrare men å andra sidan kan det vara kostsamt att köpa loss ett typsnitt för detta ändamål.

Ett alternativ till ovanstående är att välja ett typsnitt från http://www.google.com/fonts (en gratis prenumerationstjänst från Google) och primärt köra det som en onlineprenumeration med fallbacklösning på den egna servern. Man kan alltså ladda ner typsnittet och lägga upp det på den egna servern. Dock bör man kolla på rättigheterna och i de flesta fall kreditera fontdesignern på sin egen webbplats.

MEN TILLGÄNGLIGHETSASPEKTERNA DÅ? ”GOD LÄSBARHET PÅ WEBBEN”

Vilket typsnitt är egentligen lättast att läsa på skärmen? Detta är en omdebatterad fråga och det beror på vem du frågar, i vilket land du ställer frågan och vad läsarna är vana vid sedan tidigare. Det beror inte bara på typsnittets form utan också på storlek, avstånd mellan bokstäverna, färgval, hur lång texten är etc. Det finns många aspekter att ta hänsyn till.

Ett förslag är att välja ett vanligt standardtypsnitt till brödtexter men våga leka lite med rubrikerna. Korta rubriker kan absolut fungera med ett specifikt framtaget företagstypsnitt men det bästa är förstås att testa detta på användarna innan man bestämmer sig.

Webbriktlinjerna eller WCAG 2.0 säger inget om vilket typsnitt som ska användas mer än att det ska vara god läsbarhet.

HUR PÅVERKAS DEN RESPONSIVA WEBBPLATSEN AV OLIKA TYPSNITTSLÖSNINGAR?

Vi vet att en responsiv webbplats ska kunna besökas från många olika enheter och att laddningstiden kan ha stort effekt på upplevelsen. En webbplats har ungefär 4 sekunder på sig att väcka en besökares intresse. En webbplats som besöks via mobilen kanske mindre än så. Hur påverkas då laddningstiden beroende på vilka typsnitt vi använder? Är det skillnad på om typsnittet finns installerat i besökarens digitala enhet eller inte.

Svar ja, det är stor skillnad! Tänk på en hel webbplats med script, grafik, dataanrop etc. som allt ska summeras till den totala laddningstiden. Är det då värt det lilla extra att krångla till det med unika typsnitt? Kanske – om typsnittet är så tungt för varumärkets totala identitet. Men det tål ju att tänkas på.

Här är resultatet av mina tester: 

Test 1

Standardtypsnittet Arial på både rubrik och brödtext. Typsnittet finns installerat på besökarens enhet.

Laddningstid: 140 msk

Test 2

Googles onlinefont (som att prenumerera), Roboto Condensed på rubrik, Lato på brödtext

Laddningstid: 730 msk (!)

Test 3

Kombination av Googles onlinefont och standardtyspnitt, Roboto Condensed på rubrik och Arial på brödtext

Laddningstid: 336 msk

 

TAKE AWAYS

  •  Välj ett typsnitt som ger en skön läsupplevelse, fråga gärna användarna
  •  Egna typsnitt påverkar hur snabbt sidan kommer att ladda
  •  Välj ett standardtypsnitt som är mobilsäkert för brödtexten
  •  En kombination av eget typsnitt på rubriker och standard på brödtext kanske räcker för att ändå bära upp varumärkets identitet

BRA LÄNKAR

http://www.webpagetest.org/ (testa hur snabbt en sida laddar)

http://developers.google.com/speed/pagespeed/insights/ (få tips på vad du kan göra för att förbättra laddningstiden på din sida)

http://www.webbriktlinjer.se/r/39-ge-webbplatsen-en-god-lasbarhet/ (om riktlinjer för god läsbarhet)

Mobilanpassa din responsiva webbplats, på riktigt

Responsiv design stod högt på företag och organisationers ”att göra”-lista 2014. Enligt Web Service Awards trendrapport från 2014 fanns planerna att göra om var fjärde Svensk webbplats till responsiv design.

Med idén om responsiv design gick det en lättnadens suck genom webbsverige. Ett tämligen okomplicerat och enkelt sätt att, rent kodmässigt, anpassa innehållet efter den skärmstorlek som besökaren använde sig av för att konsumera innehållet. Addera en mobilanpassad meny och så är det klart, eller?

Hur bra blev det egentligen? Och vad var det som gick fel?

Låt oss backa bandet.

När responsiv var ungt

Att anpassa innehållet efter skärmstorlekar är ingen ny teknik. Detta gjorde vi redan runt 2000 när vi byggde intranät för företag som ännu inte hade någon policy om vilka datorer som skulle få köpas in (dvs. ingen enhetlig skärmstorlek som gällde generellt på företaget). Det vi använde oss av då var flytande innehåll som delades upp i procent. Eftersom man ännu inte hade kommit på konceptet med de fantastiska puff- och högerspaltsutfyllarna så fanns det inte så mycket layout att anpassa sig till. Därför fungerade teknik för flytande innehåll hyfsat bra.

Termen responsiv design kom 2010 när Ethan Marcotte skrev ett blogginlägg om webbtekniker för olika enheter – flytande layout, flexibla bilder och media queries. Ett bra sätt att anpassa innehåll och layout efter vilken skärmstorlek som besöken kommer ifrån.

Men det fanns redan då en omognad i sättet att se på responsiv design eller responsiv webb – det är först och främst en teknik – inte ett mål i sig.

Varför blir det fel med dagens responsiva webbplatser?

Jag har de senaste åren läst åtskilliga kravspecifikationer, anbuds- och offertförfrågningar med ett kort stycke om ”Responsiv design”.

Kravet ser ofta ut så här: ”Responsiv design – Webbplatsen ska byggas med responsiv design och fungera på mobil, surfplatta och desktop”. That´s it!

Jag vill inte raljera, jag fattar vad kunderna är ute efter, men det blir så fel redan från början när kraven ställs på det här sättet. Oftast har man heller inte budget för att titta på sitt innehåll utifrån ett mobile first-perspektiv, utan befintligt innehåll ska enligt kraven migreras över i en ny lösning. Vilka problem har vi då egentligen löst för användarna? För handen på hjärtat – det är väl för användarna vi gör det – inte för tekniken?

Vad användarna (vi) vill ha

Enligt Gartner kommer mobilsurfningen att ha gått om desktop surf 2018.
Du ser redan nu trenden i ditt eget användande – du besöker webbplatser med mobilen och använder appar för olika bankärenden och tjänster. Datorn blir allt mer ett arbetsredskap som det en gång i tiden var. En god vän till mig sa nyligen att ”jag använder mest datorn för ordbehandling och göra presentationer och tar sällan fram datorn hemma”.

Men… ”Dina användare skiter i om din webbplats är responsiv” Brad Frost

Vad våra användare vill ha är något som är snabbt och enkelt att använda oavsett vilken situation de befinner sig i och oavsett vilken skärmstorlek de vilar ögonen och fingrarna på.

Några problem med dagens responsiva webbplatser (responsiv design)

• Sajten är framtagen utifrån ett tydligt tekniskt perspektiv där målet är ”responsiv design”
• Sajten är inte testad fullt ut med olika enheter, skärmstorlekar, laddningstider, situationer etc. (Läs gärna mitt blogginlägg om att testa responsiva gränssnitt)

• Innehållet har migrerats från en gammal webbplats med totalt avsaknad av mobilt fokus

• Navigeringen är helt svettframkallande och ångestladdad – man har ingen som helst aning om var i strukturen man befinner sig på webbplatsen när man surfar på mobilen

• Tryckytor är alldeles för små liksom länkar ligger för tajt mot varandra. Man trycker fel, svettas lite till, går tillbaka till startsidan via logotypen och börjar om, trycker fel och skiter i det..

• Bilder/ikoner är tunga och äter både tålamod och skapar frustration. Jag bryr mig helt enkelt inte om stora branding bilder i motljus i karuseller med nonsens text på. Men det kanske bara är jag!

• Bilder – igen – de flesta mobiler och många datorskärmar för den delen har retina skärmar. Du vill inte ha suddiga bilder på din sajt, fixa dem men komprimera och optimera bilder för snabb laddning.

• Snabba laddningstider och tillgänglighetsfokus är något som lyser med sin frånvaro. Tänk rätt från början. Testa testa testa. Både med användare och vedertagna verktyg.

• Script och CSS:er till förbannelse – rensa upp! Mobila enheter kommer att läsa in ALLT även om detta är kodkommentrerat som ”ska ej visas på skärmstorlekar under 480”

• Inbäddat innehåll – vart ska jag börja? Har du någon gång testat att scrolla på en mobil som har en inbäddad karta från Google maps.. hur funkar det tycker du?

• Inte allt innehåll är responsivt – nä precis. Vid en test av myndigheters webbplatser ser det ganska bra ut på ytan men när man sedan försöker att ansluta till en tjänst via mobilen visar det sig att det man kom dit för att göra från första början inte alls är responsivt eller tillgängligt via mobilen.

Slutsats

Mobilanpassa din responsiva webbplats! Utgå från besökaren, din målgrupp och anpassa innehållet, funktioner och formgivning utifrån att webbplatsen kommer att konsumeras från olika skärmstorlekar, olika webbläsare, olika enheter, i olika situationer, med olika prestanda och uppkoppling, utifrån olika behov och förutsättningar.

Navigationskoncept för responsiva webbplatser

Hur svårt kan det vara? Det finns ju många snygga och responsiva navigationskoncept att inspireras av på nätet. En snabb sökning på Google ger drygt 4 miljoner träffar. Den ena vackrare än den andra. Menyer som följsamt och stilfullt animerat åker in från sidan och öppnar sig som en lotus blomma i dagsljus.

Kolla t ex in den här , den här  och den här (minska fönstret under 480 pixlar)

Problemet är just det. Att navigationskoncept ofta är sprunget ur formgivning och tekniska funktioner. Konceptet för den lilla skärmen har ofta tagits fram från hittepå innehåll och har lite förankring i verklighetens innehåll. För vad händer när du puttar in allt innehåll från en kommunwebb eller annan innehållsrik webbplats i den responsiva menyn? Hur upplever användarna att det är att navigera sig runt på webbplatsen i mobilen? Ofta ganska frustrerande.

Typiska problem som användare har när de navigerar på en webbplats i mobilen

• Hur hittar jag menyn? Alla är inte förtrogna med tre strecks-ikonen (aka hamburger-ikonen) som ska symbolisera en innehållsmeny längst upp till höger eller vänster på skärmen.

• Tryckytorna är för små och länkarna ligger för nära varandra. Användaren trycker och hamnar på helt fel sida.

• Typsnittet är inte responsivt och anpassas inte för skärmen. Texten är för liten och radbryter heller inte vid långa ord utan spänner över visuella avskärmingar. Får det att se rörigt ut.

• Var befinner jag mig i strukturen? Formgivningen tar lite hänsyn till att hjälpa användaren att förstå var hen befinner sig på webbplatsen.

• Låååååånga listor med innehållslänkar. Scrollning i långa banor innan man hittar rätt.

• JavaScript som förvisso gör menyn cool och snygg segar upp hela navigeringskonceptet och får menyn att ladda långsamt och med viss hackig fördröjning.

• Är sidan borttagen? Man har av någon anledning valt att dölja vissa sidor för mobilsurfarna som hen kommer åt via desktop.

Varför blir det så här?

När vi separerar innehåll från teknik och formgivning missar vi en stor del av användarperspektivet. Vi behöver göra användartester med målgruppen på det faktiska innehållet, veta att lösningen passar dem. Det blir också ett problem när vi ”designar som alla andra gör” – det klassiska – att titta på andra, inspireras och göra exakt samma sak utan att veta om det verkligen är den bästa lösningen.

Hur kan vi göra?

Involvera dina användare i framtagning av navigationskoncept för din responsiva webbplats. Testa, skruva, testa, skruva, arbeta med detaljerna. Tänk på tillgänglighet och prestanda. Våga designa med dina användare i fokus, jag slår vad om att ni tillsammans kommer fram till en lösning som är 10 gånger bättre än reklambyråns.

7 Tips för navigationskoncept för responsiva webbplatser

1. Använd gärna ord som Meny eller Innehåll i kombination med hamburger-ikonen (om du av någon anledning bara MÅSTE ha den).

 

2. Gör tryckytor minst 44 pixlar så att det blir tryckvänliga och öka avstånden mellan länkar till det samma.

 

3. Använd ett responsivt typsnitt och öka textstorleken i mobilen till minst 16 pixlar som standard på brödtext. Testa hur rubriker flödar på webbplatsen och att de inte sticker utanför skärmen

Läs Techniques for Responsive Typographic

4. Visa tydligt i menystrukturen var besökaren befinner sig på webbplatsen. Om användaren stängt menyn och öppnar den se då till att den scrollar ner automatiskt till den sida som användaren befann sig på, så att hen inte behöver leta.


5. Testa prestanda och komprimera JavaScript för snabb laddning.

Google Page Speed

6. Ta dig en extra funderare på varför du skulle plocka bort sidor för det lilla fönstret som återfinns på desktop.

Läs Not your only strategy

7. Testa med riktigt innehåll och tillsammans med användarna.

Läs Användningstesta responsiva webbplatser

Inkluderande design – Checklista för att skapa en webb som kan användas av alla

I mitt arbete med stora webbplatser med hög servicenivå som t ex myndigheter, tjänsteföretag, e-handlar, försäkringsbolag och mediahus stöter jag ofta på patrull när det kommer till tillgänglighet. De flesta verkar tycka att det känns krångligt och kostnadsdrivande. Vilket det inte alls behöver vara!

Att skapa en tillgänglig webbplats som kan användas av alla personer oavsett förutsättningar och funktionssvårigheter är inte speciellt avancerat. Det handlar till största delen om en inställning till användarna – dina besökare.

Vinsterna med en tillgänglig webb skulle jag våga påstå är enorma! Du kommer att öka dina affärer, kundnöjdhet, förbättra upplevelsen och dessutom få high five av både designers och utvecklare. Dessutom följer du då den uppdaterade lagen om tillgänglighet vilket ju är en fin bieffekt om något.

Nedan följer en checklista för att skapa en tillgänglig webbplats – en inkluderande webbplats som har goda förutsättningar att kunna användas och uppskattas av alla som besöker den.

Sprid och dela gärna checklistan. Sharing is caring!

CHECKLISTA FÖR ATT SKAPA EN TILLGÄNGLIG WEBBPLATS

UTFORMNING AV ANVÄNDARGRÄNSSNITT – ÄNDAMÅLSENLIGHET OCH EFFEKTIVITET

  • Bara motiverad och relevant information presenteras
  • Information presenteras utifrån relevans, oftast efterfrågad information först på sidan
  • Om en uppgift måste delas upp på två sidor klarar sig användaren i så många fall som möjligt på de uppgifter som finns på första sidan
  • Den viktigaste informationen syns tydligt
  • Relevant information i sammanhanget döljs inte av andra fönster
  • Element och upprepningar som inte tillför någon information förekommer inte
  • Det finns inga onödiga dekorationer eller ramar
  • Information är alltid placerad på samma ställe och stöder mönsterigenkänning och automatisering
  • Bara ord och koncept som användaren är väl förtrogen med används
  • Gränssnittselement har sina givna positioner på skärmen
  • Centrala uppgifter kan utföras snabbt och smidigt
  • Applikationen är självförklarande
  • Användaren får stöd för inmatning när det är lämpligt, till exempel genom förvalda värden

UTFORMNING AV NAVIGERING

  • Användaren ser hela tiden var hen befinner sig
  • Aktuell sida är markerad i menyn
  • Menyn ser likadan ut hela tiden
  • Menyval är tydliga och konsekvent namnsatta
  • Vid sidväxlingar hamnar fokus överst på sidan om den går att rulla
  • Fasta sidbrytningar används om information delas upp på flera sidor
  • Nya fönster används sparsamt
  • Länkar till sidor utanför systemet öppnas i nytt fönster

UNDVIKA FEL

  • Alla obligatoriska fält är markerade med stjärna (*) och sidan är försedd med en förklaring om vad stjärna betyder
  • Fält är utformade för att passa det format de är avsedda för
  • Fält som kräver inmatning i särskilda format är försedda med hjälptexter
  • Om användaren försöker gå vidare utan att ha fyllt i eller felaktigt fyllt i obligatoriska fält markeras de aktuella fälten och ett felmeddelande visas som förklarar vad som blivit fel eller vad användaren glömt.
  • Det går att ändra information och rätta felaktigheter utan att skriva hela texten på nytt
  • Om ett fel kan rättas automatiskt får användaren ett meddelande om den planerade ändringen
  • Konsekvenser av åtgärder beskrivs före åtgärden
  • Det går att avbryta utan att spara
  • Avbrytknapp återställer till tidigare läge
  • Om ett fönster eller hela applikationen stängs kontrolleras om modifieringar är gjorda och användaren får, om det behövs, en fråga om att spara
  • Om en operation med negativa konsekvenser inte kan ångras får användaren en varning

FELMEDDELANDEN OCH VALIDERING

  • Texten talar om vad som har hänt och hur användaren kan åtgärda problemet, till exempel så visas det korrekta formatet eller det tillåtna intervallet vid inmatningsfel
  • Texten är tydlig och specifik
  • Texten är skriven i positiv form
  • Om flera fel i inmatningsfält uppstår samtidigt presenteras de samtidigt
  • Meddelanderutor är flyttbara
  • Meddelanderutor placeras i närheten av det element som har generat dem
  • Applikationens status är tydlig
  • Fråga om att spara uppstår endast om användaren inte redan har sparat
  • Systemmeddelanden är presenterade så att de är begripliga för användaren

KNAPPAR

  • Knappar byter inte plötsligt funktion eller utseende
  • Knappar har vedertagna och beskrivande namn när sådana finns
  • Knappar som inte har text har en förklaring som visas när användaren håller musen över
  • Bilder med knappfunktion är utformade så att det syns att de är knappar
  • Knappar som inte är tillgängliga för tillfället är inaktiverade

UTFORMNING AV GRÄNSSNITT FÖR OLIKA ENHETER OCH SKÄRMSTORLEKAR

  • Systemet stöder de avsedda skärmstorlekarna och skärmupplösningarna
  • Tvinga inte användaren att använda en mobilversion men erbjud gärna en sådan om grundwebbplatsens sidor är stora eller funktionerna komplexa
  • Sträva efter att göra sidhuvudet litet.
  • Minimera användningen av script på klientsidan

UTFORMNING AV GRÄNSSNITT FÖR MINDRE SKÄRMAR

  • Högerjustera inte knappar, funktioner eller grupperingar av dessa om de inte sträcker sig minst 75% av skärmen i alla lägen.
  • Lägg inte ofta använda knappar ute vid höger-/vänsterkanten om de inte upptar minst en tredjedel av skärmbredden.
  • Skapa stora klickytor
  • Radlängder ska anpassas efter skärmbredden men alltid hålla sig till max 70 tecken per rad inklusive mellanslag.
  • Använd höga kontraster.
  • Lägg in genvägar för att låta användaren hoppa mellan delar i innehållet i långa sidor.
  • Det ska vara möjligt att använda gränssnittet i både stående och liggande visning.
  • Om gränssnittet medger styrning med gestik (touchskärm) bör detta implementeras.
  • Lägg inte funktioner som enbart går att hantera via gestik, utan komplettera alltid med en knapp/länk.
  • Gör det möjligt så långt det är möjligt att styra gränssnittet med bara ett finger.
  • Se till att det går att zooma gränssnittet om möjligt
  • Minimera textinmatning i gränssnittet
  • Ge användaren tillräckligt tid och varna innan tidsgränser uppnås.

APPLIKATIONER

  • Skapa applikationer för klart avgränsade funktioner som en användare kan behöva tillgång till ofta. (+förklaring till vad som menas med applikation)
  • Applikationen utnyttjar på ett genomtänkt sätt det stöd för navigering som terminalens gränssnitt (knappsats m m) erbjuder.
  • Signaler såsom ljud och vibration används på ett genomtänkt sätt och i tydligt syfte
  • Om du utvecklar en applikation för ett operativsystem eller en mobil enhet som kan ha styrknappar (t.ex. piltangenter och en ok-knapp) ska dessa gå att använda för att navigera i gränssnittet.
  • Om du utvecklar ett gränssnitt som kan användas av enheter där du kan koppla in ett tangentbord ska gränssnittet så långt det är möjligt gå att styra med tangentbordet.

CHECKLISTA FÖR INNEHÅLLET

Texter:

  • Bestäm målgrupp, syfte och sammanhang för texten
  • Texten består av tydliga och korta avsnitt
  • Meningarna är korta
  • Rubriker speglar textens innehåll
  • Ord upprepas inte flera gånger i ledtexter
  • Samma ord används för samma sak överallt
  • Bara ord som användaren är väl förtrogen med används
  • Meningarna är korta och det viktiga framgår tydligt tidigt i meningen

Språkanpassning:

  • Diskutera i ett tidigt stadie i projektet vilka språk innehållet ska visas på

Checklista för utformning av grafiskt gränssnitt

Typografi:

  • Typsnitten är utan serifer och bekant för användarna
  • Användarna upplever att texten har bra läsbarhet

Typsnitt och textfärger:

  • Det förekommer inte fler än fyra teckenstorlekar
  • Teckenstorleken är relativt stor
  • Texten är mörk på ljus bakgrund
  • Sidrubriker och fältrubriker är tydliga

Ikoner och symboler:

  • I första hand används standardiserade ikoner
  • Nya ikoner är utvärderade med en användargrupp
  • Ikonerna är enkla och bygger på substantiv
  • Ikonerna är utformade så att de byggs upp av få och väsentliga detaljer
  • Ikonerna är logiskt grupperade efter funktion på motsvarande sätt som för knappar
  • Ikonerna skapar omedelbar igenkänning och det är lätt att komma ihåg vad de innebär redan efter ett fåtal användningstillfällen

Utformning av utskrifter:

  • Det går att skriva ut i ett bra, läsbart format

RESURSER OCH REFERENSER

Checklista för nivå AA hos WCAG 2.0

http://www.w3.org/WAI/WCAG20/quickref/

E-delegationens webbriktlinjer för offentlig sektor

www.webbriktlinjer.se

Utformning av tillgängliga mobila gränssnitt, Funka.nu

http://www.funkanu.se/Global/Filer/design_for_alla/regler_och_riktlinjer/Riktlinjer_f%C3%B6r_tillg%C3%A4ngliga_mobilgr%C3%A4nssnitt_2012.pdf

VERKTYG

KONTAKT

Behöver du stöd och råd angående framtagning eller analys av en tillgänglig webbplats? Kontakta gärna mig kostnadsfritt för rådgivning!

Att användningstesta responsiva webbplatser

Att göra användningstest på responsiva gränssnitt innebär att testa funktion, design, innehåll, navigering och teknik på olika typer av enheter och skärmstorlekar.

Förberedelser Inför testning bör du tänka på följande:

· Identifiera målgrupper att testa på. Vilka är mest prioriterade?

· Hitta personer inom målgrupperna genom rekryteringsbyråer, egna nätverk, företagslistor eller t ex sociala medier

· Förbered någon form av ersättning till deltagarna för att visa uppskattning t ex presentkort eller biobiljetter

· Definiera omfattning av testerna, vilka delar ska vi fokusera att testa på? Förslagsvis de områden som ger mest affärsvärde och värde för besökaren.

· Identifiera vilka skärmstorlekar testarna ska utföras på samt vilka webbläsare.

Olika sätt att genomföra tester

· Mäta och observera användbarhet genom hur snabbt och effektivt nya besökare använder webbplatsen. Var och när kommer besökaren i kontakt med trösklar och var i flödet/innehållet/navigeringen uppstår problem?

· Subjektiv bedömning genom aktivitetsdriven testning som dokumenteras. Var klickar användaren någonstans? Och varför? Ställa frågor om navigering, upplevelse och funktionalitet.

· Inspelning av testning där användaren har olika uppgifter som ska utföras enligt ett givet flöde. Kan utföras lokalt eller på distans där skärmen och besökarens reaktioner spelas in.

Utformning av testplan för att få den feedback du vill ha

· Ta fram en testplan där du undviker partiskhet och förutfattade åsikter om din webbplats. Vi alla har dem!

· Utforma användningssenarios som är baserade på de kritiska affärs- och effektmål som du satt upp för din webbplats. Senarios kan t ex vara: utforskande aktiviteter med tydliga avslut eller med helt öppna avslut samt direkta uppgifter som ska utföras.

· Ta fram riktlinjer för testerna. Hur ska vi dokumentera och uppföra oss som testledare och observatörer?

Under testerna

· Testa inte isolerat, bjud in observatörer t ex från kunden som kan sitta med när testerna utförs

· Förbered användaren och introducera hen till hur du kommer att utföra testningen. Påpeka gärna en gång för mycket att det inte finns något som är rätt eller fel när testerna utförs.

· Ställ inte allt för ledande frågor under testerna. Om det dyker upp en fråga eller påstående från en användare svara: Intressant, vad tror du själv? Eller hur uppfattar du själv det med texten på den här knappen?

· Ta noteringar i strukturerad form. Skriv ner kärnfrågor och nyckelord under testningen, du behöver inte skriva ner allt. Sammanfatta testerna direkt efteråt, vi glömmer så lätt!

Analysera resultatet

· Använd kvantitativ data för att lokalisera problemområden och trösklar

· Värdera hur omfattande ett upptäckt problemområde är — Enkelt att åtgärda? Svårt, stort och komplex att åtgärda?

· Ta fram och visa exempel på hur problemen kan åtgärdas. T ex kan det vara hur andra webbplatser löst liknande problem. Du kan också ta fram rena koncept och formskisser med förslag till problemlösning.

· Iterera gärna resultatet med användarna. Har du uppfattat deras återkoppling under testerna korrekt? Något som behöver justeras?

Presentera resultatet

· Presentationen bör innehålla en beskrivning av uppdraget och dess upplägg och metodik. Vidare bör du redogöra för hur du kom i kontakt med målgruppens representanter och vad som inkluderas i testplanen och vilka frågeställningar som var aktuella under testningen.

· Visualisering från testerna — Visa med film, bilder och illustrationer hur testningen gick tillväga och reaktioner från användarna.

· Vid presentationen är det viktigt att fokusera på kärnområden som behöver extra kärlek för att leva upp till affärs- och användarmål. Visa gärna citat från användare.

· Visa förslag på lösningar och tänkbara flöden.

· Även om kunden inte efterfrågar det — ge förslag på nästa steg och hur man kommer vidare efter att leveransen är godkänd.

Var snäll

· Det finns ingen anledning att agera bad cop och utsätta användarna för tunga, svåra uppgifter på webbplatsen som ändå inte är ett tänkbart senario. Var lyhörd, nyfiken och ställ intresserade frågor. Visa att du bryr dig om din testperson och uppriktigt är spänd av förväntan på hens feedback.

Key take aways från konferens om tillgänglig webb

Vad betyder tillgänglighet? 
Det är oftast en vidare betydelse vi menar när vi pratar om digital tillgänglighet.
Det betyder att något ska vara universiellt utformat (dvs. utformning för mänskligt mångfald), användbart OCH tillgängligt.

Hur många av oss har någon form av funktionsnedsättning? 
Man pratar om ca 10-20% av den svenska befolkningen, alltså runt var 5:e användare.
Det är viktigt att komma ihåg att det som är bra för några oftast är bra för alla.
Vattenkransblandaren kom till för att göra blandning av varm och kallt vatten för personer som hade svårigheter att vrida på två kranar. Nu finns varm och kallvattenkrans blandaren i nästan varje hem och vi tänker inte på att den från början endast var för personer med fysisk funktionsnedsättning. Det som är bra för några kan vara väldigt bra för alla!

Vilka grupper pratar vi om när vi diskuterar tillgänglighet? 
Personer med:

  • Synnedsättning
  • Hörselnedsättning
  • Inlärningssvårigheter
  • Kognitiva funktionsnedsättningar
  • Begränsad rörlighet
  • Talsvårigheter
  • Ljuskänslighet
  • + kombinationer av ovanstående

Vad utmärker en tillgänglig webb?
Att alla människor ska ha möjlighet att ta del av webbplatsen.

7 tips för bättre tillgänglighet
1. Strukturerar information med rubriker (korrekt placering av H1, H2, H3 osv.)
2. Styra med tangentbordet
3. Tydliga länkar (tänk träffytor, vart länkarna går, beskriv vart de leder istället för ”Läs mer”)
4. Färger som ger bra kontraster (undvik med fördel orange.. INGA oranga knappar med vit text på). Testa bilden om den fungerar i gråskala.
5. Skapa sidor som kan ses på olika sätt – responsivt, zoomning, använd relativt stora teckensnitt
6. Kommer innehållet i rätt ordning? Gå igenom flödet. Ligger knappar, länkar etc. konsekvent i innehållet? I en köpsituation ska köpknappen alltid placeras sist, inte mitt i ett textflöde.
7. Alternativ texter – lägg dessa på bilder som förmedlar information, bilder som används för dekoration (behövs dessa bilder?), bilder som är klickbara (vart går de?).

Om kognitiva trösklar på nätet, vad ska man tänka på? 
Rent allmän kan man säga att den kognitiva belastningen ökar. Vi har mer information och fler system att ta till oss. Samhället blir mer och mer komplex.

Tänk på: 
• Ju längre tid saker tar dessto sämre kommer det att gå och man tappar användare
• Förenkla! Ingen kommer att klaga på eller kritisera att något är för lätt
• Var konsekvent, följ upp dina flöden
• Negativ feedback till användaren är bra, men ge också positiv feedback. T ex när något man klickat på hamnat i varukorgen. Dvs, ge användaren feedback även när något gått bra, inte enbart när något gått dåligt.
• Begripligt språk
• Kombinera hur vi presenterar information – text, bild, film, tal. Låt användaren avgöra hur han eller hon vill ta till sig informationen.

Det viktigaste för personer med kognitiva funktionsnedsättningar:
• Innehållet ska inte blinka eller röra sig
• En bra sökfunktion med avstavningshjälp
• Webbplatsen ska vara logiskt uppbyggd, igenkänning av vedertagna mönster från andra webbplatser
• Text ska kunna läsas upp
• Lätt att hitta kontaktuppgifter
• Ska fungera i telefonen
• Inga pop-up rutor
• Bilder ska vara relevanta och dekorativa bilder kan fungera som minnesstöd
• Enkel och ren design
• Ett tydligt språk
(Fast är inte detta punkter som egentligen gäller ALLA tänker jag 

Verktyg som togs upp under dagen: 
• https://usabilla.com/ Användartestning online
• Zooma med tangentbordet ctrl+/- eller cmd+/-
• http://www.paciellogroup.com/resources/contrastanalyser/Color Contrast Analyser
• https://addons.mozilla.org/sv-se/firefox/addon/web-developer/Add-On för att testa tillgänglighet i Firefox
• Inbyggd talsyntes i Mac, VoiceOver i iPhone