Slagord som “det enkle er ofte det beste” og “keep it simple, stupid” slenges ofte ut i webprosjekter uten å bli tatt til følge.  Det er lettere sagt enn gjort. Det finnes imidlertid noen websider som har tatt dette til seg, og som har svært begrenset funksjonalitet og innhold.

Den enkle klassikeren
Websiden www.ikke.no er en klassiker innen norsk webhumor. Siden er ufattelig enkel og har eksistert siden midten av nittitallet. Hvem som står bak siden og hva det opprinnelige budskapet var, vites ikke.

Er det fredag?
Noen har du lyst det skal være fredag, selv om det ikke er det. På www.erdetfredag.dk kan du sjekke for sikkerhets skyld.

Den som fikser alt
Noen dager er bare ikke til å holde ut. Når alt går på tverke og ingenting fungerer, kan du ønske deg en knapp som får alle problemer til å forsvinne. Personen bak www.make-everything-ok.com  har laget den for deg.

For deg som vil ha et vanlig navn
Olsen er et av Norges mest vanlige etternavn. Har du noen gang lurt på hvordan det ville ha vært å hete Olsen? Gå til www.hetolsen.no, og du får svaret.

For deg som lurer på hvor gammel du er
Nok et eksempel på en side med svært enkel og rendyrket funksjonalitet: www.hvorgammelerdu.no

Den enkle sammenhengen mellom sau, elg og ulv
Noen ganger registrerer man domener man egentlig ikke har bruk for.  Denne siden passer godt i en samling med sider som er veldig, veldig enkle. Se for eksempel www.ulv.no

Siden som ganske enkelt gjør narr av det kompliserte
At Altinn er komplisert er ingen hemmelighet. Denne tjenesten fra det offentlige er opphavet til utallige frustrasjoner, telefonhenvendelser og brukervennlighetsproblemer. Parodisiden til Altinn gjør narr av det kompliserte, se www.alt-inn.com for mer informasjon.

Mer om enkelhet
Flere enkle sider finner du på www.enklesider.com.
Trenger du et enklere liv, kan du besøke www.enklereliv.no.

Slik ser nødtelefonen på danskebåten ut. Kun knappen 9 og # skal brukes. Hva skal vi med alle de andre knappene?

 
Telefon som alarmknapp?
Her har båtselskapet utstyrt sine lugarer med en telefon som kun skal brukes til nødsamtaler. Instruksjonene forteller tydelig at bare to av de totalt tolv knappene skal brukes: 9-tasten som skal tastes 4 ganger etter hverandre ved nødsamtaler og #-tasten som kan brukes for å slå av lyset i panelet. Hvis du ikke skjønner verken norsk eller engelsk, vil du sannsynligvis ikke se at denne innretningen er en nødtelefon.

Valget av en telefon som alarmknapp får meg til å lure om det finnes noe skjult funksjonalitet her. Kan renholdspersonalet bruke den til å ringe sengetøylageret? Kan passasjerene ringe opp andre lugarer hvis de knekker en hemmelig kode?

Andre standardløsninger for alarmknapper
Om selskapet hadde valgt en annen standardløsning for alarmknapper, f.eks. slike de har på handicaptoaletter eller i heiser, kunne passasjerene hatt en enkelt nødknapp å forholde seg til , uten lys som må slåes av. I heiser er det ofte slik at en vakttelefon ringes opp når alarmknappen holdes inne i 20 sekunder. Brukergrensesnittet hadde blitt mindre komplisert ved å velge en slik løsning. Men kanskje beslutningstakene var redd for at det skulle bli for enkelt å trykke på alarmknappen hvis det bare fantes en knapp? Eller at flere ville få lyst til å trykke på alarmknappen for gøy? 

Hva kan vi lære av dette?
1. Den standardløsningen som har mest funksjonalitet er ikke alltid den beste
2. Standardløsninger passer ikke til alle formål
3. Brukergrensesnitt må motvirke feil, uten at de blir for komplisert

Ulv, ulv
Dette med alarmer som går av for ofte er en aktuell problemstilling. I bygget jeg nå jobber har alarmknappen på handicaptoalettet blitt utløst fire ganger de siste fire årene. Da klinger alarmen i hele bygningen og folk stikker hodene ut av kontorene sine og lurer på om det er brann. Ingen av gangene har den som uforvarende utløste alarmen funnet ut hvordan han eller hun kunne stoppe alarmen igjen. Likvel er det bedre at en alarm utløses en gang for mye enn en gang for lite.

En alarmknapp bør

 1. Ikke være for komplisert å bruke, sånn at mennesker i en nødsituasjon ikke skjønner hva de skal gjøre
2. Ikke være for enkel å utløse, sånn at folk slutter å reagere hvis alarmen går
3. Være plassert slik at den ikke lett forveksles med andre knapper (lysbryter, nøkkelbrytere etc)
4. Ha en utforming som gjør at det er mulig å forstå at det er en alarmknapp selv om man ikke kan det lokale språket. 

Heldigvis er det ikke alle systemer som er like kritiske som en nødtelefon, men det å fjerne funksjonalitet som ikke er i bruk, er ofte vel så viktig som å legge til nye ting.

Ønsker du å lære mer om brukervennlighet i hverdagslivet? Les også:

• Redd miljøet med bedre informasjonsdesign
• Passer ikke vår standard? Synd for deg 
• Flybussen er ikke fremme på nett

Foto: Copyright Eli Toftøy-Andersen

Annonsebestilling på FINN. De ulike kategoriene listes opp, og oppgaven til bruker er kun én ting – finne rett kategori. Å bruke tid på å fortelle fordelene med de ulike valgene er meningsløst, fordi ingen har noen grunn til å velge å selge leiligheten fremfor bilen. Dette er ikke-reelle valg.

Når jeg senere arrangerte en brukertest av abonnementsbestillingen til Aftenposten, dukket problemet opp igjen. Noe forenklet, så er Aftenposten tilgjengelig som både morgen og kveldsavis, eller som en av delene. (Den oppvakte leser oppdager umiddelbart at dette er et reellt valg). Pga. at Aftenposten lages i Oslo, er distribusjonskostnadene ulike i forskjellige deler av landet, dvs. dyrere på vestlandet enn i Oslo. For å spare et steg i bestillingsprosessen kan det være fristende å slå sammen stegene, slik at kunden kan velge mellom ulike “pakker”: morgen + kveldsutgave på østlandet, ditto for vestlandet, sørlandet, osv., og gjenta for alle kombinasjoner av morgen, aften og helg-utgaver. Problemet er åpenbart: Du kan velge om du vil ha morgen eller kveldsutgave, men du kan ikke velge hvor du bor. Å gjøre det på denne måten øker antall valg bruker må ta stilling til, noe som gir økt risiko for at bestillingen ikke fullføres, og at kunden blir usikker på om de har valgt rett.

For å bestille abonnement hos Aftenposten må du først bestemme deg for hvor du bor, deretter for hvilke aviser du vil ha, og deretter hvilken abonnementsperiode du ønsker. Valget om hvilken landsdel du tilhører kunne med fordel være flyttet til en egen side, slik at du slipper å se valg du i praksis ikke kan ta. For de som bor i Oslo er halve siden irrelevant, og for de som bor på vestlander er det enda mer de ikke kan velge.

Følg denne enkle regelen – skill alltid mellom ikke-reelle og reelle valg. Ha dem gjerne på egne sider i en kjøpsprosess, som vist i figuren under:

Brukere klikker seg gjennom ikke-reelle valg svært raskt fordi de allerede har svaret. Resten av prosessen vil oppleves som enklere, fordi alle ikke-reelle valg er tatt.

Se selv:
Sett inn annonse på finn.no
Aftenposten abonnementsbestilling
Hicks lov

Skilt-bilde lånt på Flickr, fra JMC Photos, CC-lisens

I forbindelse med vår nye bok Praktisk brukertesting har vi vært på jakt etter en forside. Selv om forlaget har det endelige ordet i slike saker, har hadde vi som designere selvsagt mange meninger og idéer om hvordan den kunne se ut. I denne bloggposten kan du lese mer om hvordan forsiden ble til og se noen av utkastene som ikke kom gjennom nåløyet. 

Det første forslaget så sånn ut: 

Så gav vi masse innspill til forlagets designer i Lativia. Om Don’t make me think og ander bøker som vi liker. Tegnet og forklarte. 

Mye bedre. Men vi lurte litt på hva de pilene skulle bety. “Kan vi få noen strekmennesker?” Spurte vi. 

I et annet land, lang nærmere oss selv, satt vår illustratør Anders Fagerhus og tenkte så det knakte. 

Slik? 

Eller slik? 

Eller slik ?

Vi synes kjøttkvernen var en artig idé, men fikk det ikke helt til å passe.
Så gikk det en stund. Så fikk vi nytt forslag fra Latvia i to varianter. Dette var fint, men ser de ikke litt nakne ut? 

Litt justering til og så er vi i havn: 

Nå har de fått klær på seg og både  vi og forlaget ble fornøyd. Som du kan se på f.eks. Tanum og Bokkilden  er forsiden allerede tatt i bruk og det er mulig å legge inn en forhåndsbestilling. 

Helt på tampen fikk vi et kreativt forslag fra Jon Gunnar Wolds tidligere kollega. Tydelig inspirert av sagaen om isfolket og annen kiosklitteratur. Dessverre kom det ikke gjennom nåløyet:) 

Konklusjon: Husk å gi innspill til forlag før de begynner å designe forsiden. Husk at det du lager må være tilpasset målgruppen. 

Tusen takk for alle bidrag. 

Les også: 

Ny bok om brukervennlighet – på norsk 

Slik prioritererer du etter endt brukertest 

5 tips for brukertesting av innhold 

Presentasjon: Kjør brukertester i Smidigland 

Hva synes du? Legg gjerne igjen en kommentar nedenfor.

Når du jobber med design er det en del av jobben din å være kreativ, men det er ikke så lett å være kreativ på kommando. I Oakland møtte jeg poeten Zach Houston som har gjort kreativitet på bestilling til en levevei.

Konseptet er enkelt; bestem tema og pris og den kreative poeten skriver et personlig dikt til deg på sin bærbare skrivemaskin. Hvis han er spesielt fornøyd med diktet ber han deg kanskje om å sende ham en kopi på e-post.

Det var noe underlig rørende ved å se den dypt konsentrerte poeten klapre i vei på den lille skrivemaskinen mens han lyttet til temaordene fra den som var først i køen. Jeg bestemte meg for å få skrevet mitt eget dikt. Det tok skrivemaskinspoeten under to minutter å hamre ordene ned på papiret og utrolig nok ble det veldig bra.

Om Zack Houston:
http://en.wikipedia.org/wiki/Zach_Houston

Flere av hans dikt:
http://zachhouston.com/poems/
 

Et dikt Zack Houston har skrevet til en annen forbipasserende:

on the way here this morning
thinking of myself as at least half wingnut
subtly different than
a nutcase because of how many of us
can fit into one
room cubicle
art fair isn't
it unjust ugly
even that oddity is so effectively
ostracized by
everyday life
  

Kanskje vi alle har godt av å presse kreativiteten til det ytterste i blant?

Praktisk brukertesting er arbeidstittelen på en fagbok som kommer i bokhandelen til våren. Jon Gunnar Wold og Eli Toftøy-Andersen er forfatterne av boken som skal utgis på Cappelen Damm forlag.  

Det er lenge siden sist det ble utgitt en bok på norsk innen fagfeltet brukervennlighet. Helt uten å vite var innholdsstrategiguruen Kristina Halvorsen  den som sparket det hele i gang. Vi fikk utdelt hennes bok på et kurs tidligere i år og Eli hvisket til Jon Gunnar: “En sånn bok burde vel vi også kunne lage”. “Det har jeg også tenkt på”, svarte han. Dermed strømmet idéene på og skrivingen begynte.

Til boken samler vi historier til kapittelet “En testleders bekjennelser”. Har du noen artige, pussige eller uvanlige historier om en brukertest? Del gjerne historiene med oss. Er du heldig, kan navnet og historien din komme med i boken.

Bilde: Flickr by See.ming Lee

Legg ikke ut på langtur uten trening. Du bør heller ikke kjøre din første brukertest uten å trene på forhånd. Foto: CC Flickr by tricky

Fjellvettreglene sier at du ikke skal legge ut på langtur uten trening. Slik er det også med brukertesting. Likevel må en gang være den første. Et godt tips er å begynne i det små og lære mens du går. Høyest læringskurve og best resultat får du ved å kjøre de første rundene ved hjelp av eller sammen med erfarne folk.

Du jobber kanskje på et sted der det ikke er tradisjon for å kjøre brukertester? Det er mest sannsynlig at det blir noe av hvis du gjør det selv eller i det minste sørger for å sette brukertesting på planen.

Brukertestvettreglene:

1. Kjør ikke brukertester uten trening

2. Planlegg testen grundig

3. Vis respekt for brukerne

4. Ha en plan B i tilfelle systemet du skal teste på ikke fungerer

5. Lytt til erfarne folk – be noen som har kjørt brukertester før om å være veileder for deg.

6. Skaff det utstyret du trenger for å gjennomføre testen

7. Litt testing er bedre enn ingen testing

8. Det er ingen skam å snu – vær villig til å innse at konseptet er helt feil for brukerne

9. Ta initativ – vent ikke til noen andre setter brukertester på prosjektplanen

Setter du i gang med brukertesting uten de nødvendige forberedelsene og forkunnskapene blir du brukertesterens svar på Severin Suveren. Ikke forvent å bli verdensmester første gang.

Har du flere tips til folk som vil begynne med brukertesting? Skriv gjerne en kommentar.

Relaterte artikler
Slik planlegger du en brukertest
Slik får du skikk på observatørene
5 tips for brukertesting av innhold
Hvordan lære bort interaksjonsdesign til 50 ungdommer på en halv dag
Få mer ut av brukertesting med barnepsykologi

Bildet er lisensiert med Creative Commons og er hentet fra Flickr: Hiking av tricky

Under Yggdrasil 2009 møttes fagfolk fra næringsliv/forvaltning og representanter fra utdanningsinstitusjonene for sammen å finne ut hva som bør kreves av morgendagens interaksjonsdesignere, informasjonsarkitekter og brukervennlighetseksperter. Sammen fant vi ut hvilke egenskaper den perfekte interaksjonsdesigner bør besitte.

Bakgrunnen for workshopen

Det er i dag en rekke forskjellige utdanningsinstitusjoner i Norge som gir utdannelser innen disse områdene. Det er viktig at disse utdannelsene til enhver tid er målrettet i forhold til det konkrete behov for kompetanse som finnes i norsk næringsliv og forvaltning. For å kunne gjøre utdannelsene oppdaterte og relevante, så er det nødvendig med kontinuerlig tilbakemelding på studietilbudene fra studentenes framtidige arbeidsgivere. Dag Svanæs og Ole Andreas Alsos inviterte derfor erfarne personer fra næringsliv og forvaltning til å gi sine anbefalinger om hva norske utdanningsinstitusjoner bør undervise sine studenter i framtiden. Til å lytte ble sentrale undervisere fra norske utdanningsinstitusjoner invitert.

Et av flere viktige bidrag som kom frem i denne debatten var egenskapene til den perfekte interaksjonsdesigner, informasjonsarkitekt og brukervennlighetsekspert.

Med bidrag fra blant annet Thor Fredrik Eie og Jostein Magnussen (Netlife Research) (se bildet øverst) beskrev workshopdeltakerne den perfekte kollega slik:

• De brenner for brukervennlighet: De har et stort bankende hjerte for brukervennlighet og et høyt nivå av usabilityhormon i kroppen. Det er en egenskap som kan være vanskelig å lære, men likevel svært viktig for en interaksjonsdesigner.
• De kan tegne: Den perfekte kollega behersker kunsten å skisse på papir. De tør å bruke penn, og tør å skrible litt på arket for å utforske løsninger. De trenger ikke være noen picasso (det trenger ikke være pent) men det er viktig å være trygg med penn og papir. Interaksjonsdesign er et håndverk og en interaksjonsdesigner må ha det i fingrene.
• De kan blogge: En interaksjonsdesigner bør vite hva en publiseringsløsning er. De må ha kjennskap til det som fines av kommersielle verktøy som brukes av norske bedrifter (for eksempel WordPress, EPIserver). Det er også en fordel å ha sett baksiden av et publiseringssystem.
• De kan presentere: De har holdt presentasjoner og er komfortabel med snakke foran folk. De er flinke å få fram et budskap (som konsulent gjør du det hele dagen) og powerpoint er deres beste venn.
• De kan konseptutvikling: De forstår viktigheten av prototyping og konseptutvikling. De har laget noe som har vært testet.
• De kan brukeranalyse: Knut Rolland (Avenir) mener at de må ha en stor verktøykasse med et bredt spekter av metoder for å innhente kunnskap om brukerne og deres behov, samt foretningsprosessene i organisasjonen . Det gjelder ikke bare klassiske metoder som brukertester og intervju, men de har vært ute å gjort observasjoner og etnografiske studier. De forstår også hva de ulike metodene ikke fanger, deres styrker og svakheter.
• De kan planlegge og kjøre brukertester: De kjenner brukertestingsmetoden i detalj og har vært med å planlegge, gjennomføre og analysere brukertester.
• De kan grunnleggende programmering: De kan grunnleggende HTML, CSS og Flash. De trenger ikke være noen topprogrammerer, men må kunne se på kode som noe mer meningsfullt enn en tilfeldig samling tegn og mellomrom.
• De er kreative: De er meget kreative – innen de rammer som prosjektet, teknologien eller organisasjonen setter.
• De har erfaring fra næringslivet: De har vært ute i den virkelige verden og har blitt “skitten på fingrene” gjennom sommerjobber eller ”internships” ute i bedrifter. Masteroppgaver og tilsvarende er forankret i reelle prosjekter – ikke dype, smale og teoretiske tema.
• De kan samarbeide: Ram Yoga (Steria) mener at de må kunne samarbeide med alle i prosjektorganisasjonen, særlig med utviklere.
• De kan selge inn brukervennlighet: Interaksjonsdesignere må være flinke til å synliggjøre sitt eget behov. Bjørn Tennøe (Fast) trekker frem viktigheten av å kunne selge seg selv. Han peker på at den norske industrien i stor grad produserer råstoff og er ikke trent til å kjøpe designekspertise. Industrien trenger utdanning i hvorfor de trenger interasjonsdesignere og hvordan de kan bruke dem. Ram Yoga (Steria) mener at interaksjonsdesignere må tenne en brukervennlighetsgnist hos utviklerne – de må evangelisere fagområdet. Dessuten må interaksjonsdesign komme som en naturlig del av utviklernes utdannelse.
• De har spisskompetanse på brukervennlighet: Gautam Ghosh (Skatteetaten) peker på at interaksjonsdesignere må være “spisse”. De oppfattes ofte som generalister som kan brukes over alt. Det kan fort undergrave deres stilling og deres entusiasme når de ikke får brukt deres kompetanse annet enn når det er rom for det. Det er alltid rom i starten av et prosjekt, så fjernes behovet på grunn av ressursmangler. Det kan være frustrerende for mange og de gir opp å sloss. Gautam ønsker seg sterkere profesjonalisering og sterkere synliggjøring av kunnskapen
• De er generalister: Knut Rolland mener på en annen side at de må ikke være for smale, da graver man sin egen grav. Man må være generalister. Trude Hole (Bouvet) peker på at industrien ansetter generalister, de vil ha ”poteter” som kan brukes til alt og tør ikke ansette ”spesialverktøy” som interaksjonsdesignere.
• De er ikke redd for teknologi: Knut Rolland mener at mange er redd for å ta i teknologi. Det skaper et kunstig skille; interaksjonsdesigneren overleverer sitt arbeid til utvikleren  og sier ”vær så god, nå kan du starte kodingen”, for deretter å nekte all nærkontakt med utvikleren og teknologien.

Men sukk - å ha en slik interaksjonsdesigner med på laget vil være en drøm for de fleste organisasjoner og bedrifter. Dessverre finnes det alt for få slike personer. Høyskoler og universiteter bør derfor ta disse ønskene inn over seg når de planlegger studieløp.

I forbindelse med en studiereise til Stanford University og Silicon Valley deltok jeg på en konferanse ved forskningssenteret til IBM i Almaden, San Jose, CA. Her hadde de en orginal og brukervennlig løsning på problemet: En trådløs mikrofon var satt inn i en lett og myk tøyball. Arrangøren kastet denne raskt til den som ønsket å stille spørsmål til foredragsholderen. Når hun var ferdig, kastet hun den videre til nestemann som hadde noe på hjertet.

Med mikrofonballen ble spørsmålsrunden aldri skjemmet av langvarige spørsmålssesjoner – på et øyeblikk hadde alle som ville fått stilt spørsmål til foredragsholderen.

1. Lær deg stammespråket. Smidige metoder inneholder begreper, artefakter og seremonier som du bør sette deg inn i
Skal du inn i et smidigprosjekt, må du forstå begrepene som brukes og finne de foraene som gjør at du får formidlet designforslag og endringer. Du vil nok kjenne igjen problemstillingene som oppstår, men de kommer gjerne i en annen rekkefølge og heter andre ting enn det du er vant til.

 
2. Bli med på de seremoniene som er nyttig for ditt arbeid og for teamfølelsen
“Du står midt i standup-en vår”, fikk jeg beskjed om en av de første dagene i prosjektet. Seremonier som ståoppmøter, scrum of scrums og retrospektiver er en del av arbeidshverdagen for medarbeidere i et smidigprosjekt. Om du skal delta på alt, får du ikke gjort stort annet, særlig hvis du skal jobbe for flere team samtidig. Her er det nyttig å prøve seg frem, slik at du får med deg det som skjer, uten at du trenger å overhøre alle tekniske eller forretningsmessige avveininger som gjøres underveis. Det er viktig at designere er med på diskusjoner rundt produktkøen for å få frem gui-relaterte oppgaver. Hvis du har en dedikert plass i et av teamene, kan det være greit å følge seremoniene til det teamet, slik at du føler at du er ordentlig med. Det er aldri gøy å føle seg utenfor.
 
3. Tolk brukerhistorier ved å tegne ut skjermbilder
I smidigprosjekter er kravene til systemet utformet som brukerhistorier. Brukerhistoriene er korte og inneholder en begrunnelse for hvorfor kravet skal gjennomføres. I foredraget GUI-prototyper er Gode på Smidig2008  snakket jeg om at enhver tekstlig beskrivelse kan tolkes på mange forskjellige måter. Det er en stor fordel å tegne ut brukerhistoriene i form av skjermbilder som kan brukes i kommunikasjon med både utviklere og forretningssiden. Skjermbildene kan også synliggjøre behovet for nye brukerhistorier som må til for å få ting til å henge sammen.

4. Lær deg å formulere nye brukerhistorier
De første gangene jeg viste nye skjermbilder fikk jeg stadig høre: “men, det er en annen brukerhistorie”. “Javel”, tenkte jeg, ”da får jeg skrive en ny historie.”
Brukerhistoriene har en enkel form, og det er lett å lære seg å skrive nye
Eksempel på mal:
Som en <bruker>
ønsker jeg <funksjon>
 slik at <verdi>
Brukerhistoriene legges inn i en produktkø som brukes til å prioritere oppgavene. Det er produkteier på forretningssiden som prioriterer, så her gjelder det å bruke sin påvirkningskraft.

5. Heng oppdaterte skjermbildeskisser opp på veggen
Fra jeg hang de første skissene opp på veggen til utviklere og arkitekter uoppfordret stod rundt dem å diskuterte GUI tok det under fem minutter. Skjermbildeskisser som blir liggende på en filserver kommuniserer ikke så bra. Det gjør heller ikke designforslag som kun finnes inne i ditt hode. Det er noe med å få skissene opp på veggen, se sammenhenger mellom dem og tegne endringsforslag rett på papiret som gir en stor ekstraverdi.

6. Utnevn en “stylist” i hvert utviklingsteam som har ansvar for GUI og stilark
Det er fornuftig at noen holder orden i stilarket og sørger for å formidle GUI-ting videre til resten av teamet. Hvis prosjektet er stort, er det viktig at dette ansvaret ikke ligger på en person alene, men at alle teamene som jobber med GUI har minst én person som kjenner stilarket og GUI-komponentene spesielt godt.

7. Bedre kommunikasjon ved avholde ståoppmøter for designere og stylister 1-2 ganger i uken
Ståoppmøter er godt egnet for kjappe avklaringer og statusoppdateringer. Å avholde ståoppmøter for alle som jobber med GUI-relaterte oppgaver, gjør informasjonsflyten bedre.
 
8. Kjør brukertester
Smidig gir deg ingen unnskyldninger for å la være.

9. Lag GUI-retningslinjer i form av sjekklister underveis
Ved å utforme GUI-retningslinjer som en sjekkliste, er det lettere å bruke denne til gjennomgang av (nesten) ferdigutviklede skjermbilder. Å få utviklere og testere til å pugge retningslinjene kan være en utfordring. Vi arrangerte kurs med quiz. Husk premier!
 
10. Sørg for at GUI-retningslinjene blir en del av Definition of Done
I store prosjekter er det ofte vanskelig å få til et konsistent grensesnitt. Smidigprosjekter er intet unntak. “Definition of Done” er en sjekkliste som brukes til å definere hva som skal til for at en utviklingsoppgave skal kunne sees på som ferdig. Som designer kan du sørge for at GUI-retningslinjene blir en del av denne definisjonen.

Tipsene er basert på arbeid i et stort smidigprosjekt med totalt 11  utviklingsteam og 3-4 dedikerte Gui-ressurser. Tusen takk til mine kolleger Ram, Johannes og Trond for verdifulle innspill til innlegget. Har du andre tips, råd eller andre erfaringer du ønsker å dele? Skriv gjerne en kommentar.

Lær mer:
Tre modeller for organisering av designere  i smidige prosjekter
3-minutters guide: Dette er Scrum (pdf)