En prosjektveiledning til UX-design - PDF gratis nedlasting (2023)

UX EN PROSJEKTGUIDE TIL

DESIGN

FOR BRUKERERFARINGSDESIGNERE PÅ FELT ELLER UNDER LAGE

RUSS UNGER OG CAROLYN CHANDLER

PEACHGIT PRESS

En prosjektguide til UX-design: For designere av brukeropplevelser i feltet eller i utviklingen Russ Unger og Carolyn Chandler

New Riders 1249 Eighth Street Berkeley, CA 94710 (510) 524-2178 (510) 524-2221 (faks) Finn oss på nettet på: www.newriders.com For å rapportere feil, vennligst send en melding til[e-postbeskyttet]New Riders er et avtrykk av Peachpit, en avdeling av Pearson Education. Copyright © 2009 av Russ Unger og Carolyn Chandler Oppkjøpsredaktør: Michael J. Nolan Prosjektredaktør: Becca Freed Produksjonsredaktør: Tracey Croom Development Redaktør: Linda Laﬂamme Kopiredaktør: Leslie Tilley Korrekturleser: Suzie Nasol Komponist: Danielle Foster Indekser: Valerie Perry Omslagsdesign: Mimi Heft Omslagsproduksjon: Andreas deDanaan Interiørdesign: Mimi Heft

Merknad om rettigheter Alle rettigheter forbeholdt. Ingen del av denne boken kan reproduseres eller overføres i noen form på noen måte, elektronisk, mekanisk, fotokopiering, opptak eller på annen måte, uten skriftlig forhåndstillatelse fra utgiveren. For informasjon om å få tillatelse til opptrykk og utdrag, kontakt[e-postbeskyttet].

Ansvarserklæring Informasjonen i denne boken distribueres på "som den er"-basis uten garanti. Selv om alle forholdsregler er tatt under utarbeidelsen av boken, skal verken forfatterne eller Peachpit ha noe ansvar overfor noen person eller enhet med hensyn til tap eller skade forårsaket eller påstått å være forårsaket direkte eller indirekte av instruksjonene i denne boken eller av dataprogramvaren og maskinvareproduktene som er beskrevet i den.

Varemerker Mange av betegnelsene som brukes av produsenter og selgere for å skille produktene deres hevdes som varemerker. Der disse betegnelsene vises i denne boken, og Peachpit var klar over et varemerkekrav, vises betegnelsene som forespurt av eieren av varemerket. Alle andre produktnavn og tjenester som er identifisert i denne boken, brukes kun på redaksjonell måte og til fordel for slike selskaper uten intensjon om å krenke varemerket. Ingen slik bruk, eller bruk av noe handelsnavn, er ment å formidle støtte eller annen tilknytning til denne boken. ISBN-13 978-0-321-60737-9 ISBN-10 0-321-60737-6 987654321 Trykt og innbundet i USA

Ros for en prosjektguide til UX-design Hvis Russ Unger og Carolyn Chandler var tryllekunstnere, ville Alliansen være etter dem for å avsløre deres beste hemmeligheter. Heldigvis for deg er de ikke det. Russ og Carolyn har samlet visdomsvisdom som tidligere bare var kjent for de mest erfarne UX-prosjektlederne og kodifisert den for alle å se. Nå kan du lære hemmelighetene som er nødvendige for å kjøre flotte brukeropplevelsesprosjekter. Jared M. Spool, administrerende direktør og grunnlegger av User Interface Engineering

Er det én bok som kan fortelle deg alt du trenger å vite om å designe brukeropplevelser? Nei. Er det en bok som tar deg det meste av veien dit? Det er nå. Carolyn og Russ har lagt et solid grunnlag for planlegging og ledelse av designprosjekter. Dette er en viktig håndbok for alle som er fast i de konkurrerende metodikkene, de endeløse møtene og alle de bevegelige delene av brukeropplevelsesdesign. Dan Brown, forfatter av Communicating Design

Denne boken er en fantastisk introduksjon til hvordan du kan designe flotte produkter for ekte mennesker. Men det dekker mye mer enn bare design – det inkluderer også alle tingene rundt design: administrere prosjekter, jobbe med mennesker og kommunisere ideer. En flott allrounder. Donna Spencer, forfatter av "Card Sorting: Designing Usable Categories"

Dette er en praktisk, tilgjengelig og veldig menneskelig guide til en veldig menneskelig aktivitet: å jobbe sammen med mennesker for å lage gode ting for andre mennesker. Steve Portigal, Portigal Consulting

Hvis du har hørt om forfatteren Wil Wheaton, forstår du hvorfor jeg setter så stor respekt for Russ Unger. Russs erfaring og veiledning var grunnleggende for konstruksjonen og designen av Monolith Press, og han har vært en av de mest verdifulle samarbeidspartnerne jeg noen gang har jobbet med. Wil Wheaton, forfatter av Dancing Barefoot, Just a Geek og The Happiest Days of Our Lives

iii

Anerkjennelser Russ Unger Denne boken ville aldri vært i nærheten av å bli fullført uten støtte fra min familie, venner, kolleger og en rekke mennesker som var helt ukjente for meg før jeg skrev de første tastetrykkene. Min vakre kone, Nicolle, som villig og bevisst giftet seg med en nerd med en overpresterende feil, klarte å doble opp foreldrepliktene gjennom det meste av skrivingen av denne boken. Døtrene våre, Sydney og Avery, pirket og pirret ofte faren deres som var nesten i koma for å få ham til å danse, synge og spille Spore. Jeg trodde uforvarende at det ikke ville være en så stor utfordring å skrive en bok med en nyfødt i huset. Jeg lærte fort noe annet. Og Nicolle gikk opp for å slå, gang på gang, for å redde meg og la meg ha fokuset jeg trengte for å fullføre dette prosjektet. Hun er helten jeg stoler mest på; hun holder huset vårt i orden midt i kaoset. Hun er sentrum av vår verden her, og hun slipper oss alle for lett. Nicolle, sammen med Sydney og Avery, klarer å få meg til å se ut som en ganske god far, og det er jeg takknemlig for. Jeg bor i et hus med tre jenter, og jeg kunne ikke tenke meg å elske noen av dem med noe mindre enn alt jeg har å gi. Carolyn holdt meg på sporet. Det var tider da det så ut til at dette prosjektet aldri ville begynne eller slutte. Hun holdt alltid ting i bevegelse, utforsket ideer og flyttet oss i riktig retning. Samarbeidet har vært kjempebra, og jeg har lært mye gjennom dette! Hun er definitivt en flott UX-yin til UX-yangen min. Michael Nolan var vår oppkjøpsredaktør, og han har vært den perfekte guiden. Michael er ærlig og snill, og han har virkelig bidratt til å holde ting i gang. Rebecca Freed har vært gjøgleren, administrert alle aspekter av boken, holdt oss på oppgaven og ofte sendt e-poster til oss sent, sent på kvelden. Dessverre fikk hun ofte nesten umiddelbare svar fra meg! Linda Laﬂamme var utviklingsredaktøren vår, og når jeg ble vant til Red Pen of Doom, var det ganske tydelig at hun styrte meg i riktig retning, uansett hvor hardt jeg prøvde å drukne henne i ufullstendige tanker og løpende setninger. Leslie Tilley ga ordene en siste polering; Tracey Croom brakte produksjon, layout og grafiske elementer sammen; og en ekte bok dukket opp. Steve «Doc» Baty leste hvert kapittel før det noen gang så dagens lys på Peachpit-kontorene. Jeg sendte ofte Steve kapitler rundt klokken 02.00, og han iv

TAKK

ville sende tilbakemeldingen sin innen kl. 05.00, noe som ikke er lite. Merk deg, Steve er i Australia, men det er imponerende likevel. Uten Steves konstante vilje til å hjelpe og hans raske behandlinger, er det vanskelig å tro at denne boken ville ha funnet veien til en hylle. Brad Simpson (www.i-rradiate.com) tok all grafikken jeg kastet på ham og forvandlet den til vakre, trykkklare bilder, ofte mens han sjonglerte sitt eget liv med to tenåringssønner og en travel arbeidsplan. Det ville vært lett for Brad å gå bort når som helst, men han er en ekte venn som var interessert i prosjektet og ønsket å støtte meg. Jeg er ikke sikker på at det blir nok biffmiddager til å betale tilbake denne innsatsen, men jeg kommer til å jobbe hardt for å komme dit. Takk, Brad, for at du ga opp mange av dine fridager og sene kvelder for å støtte dette. Mark Brooks fant meg i panikkmodus noen ganger mens jeg prøvde å formidle meldinger som krevde en visuell komponent utover min tid og/eller evner. Mark hoppet inn og reddet dagen ved mer enn én anledning, og jeg er takknemlig for dette. Talentfull og gir av seg selv til en feil, Mark er den typen person jeg ønsker å være. Jonathan Ashton skrev hele kapittelet om søkemotoroptimalisering for oss. Etter 5 minutter med å snakke med Jonathan, visste jeg at han var den rette personen for jobben. Kapittelet hans alene er en god grunn til å kjøpe denne boken, og det har vært flott å ha ham om bord. Jono Kane hoppet inn i siste liten og med et øyeblikks varsel. Jono er en webutvikler, interaksjonsdesigner og prototyper hos Yahoo og var uvurderlig i sin støtte og assistanse med å skrive kapittel 12. Lou Rosenfeld hjalp virkelig med å få denne ballen til å rulle. I tillegg til å være medforfatter av den berømte "Polar Bear Book" (O'Reillys informasjonsarkitektur for World Wide Web), er Lou strålende, snill, imøtekommende og alltid villig til å hjelpe andre i vårt felt. Du vil bli hardt presset for å finne mange mennesker som er så sjenerøse med seg selv som Lou er. Christina Wodtke var med på å lage introduksjoner og forbindelser for meg. Uten Christina er jeg ikke sikker på hvor vi ville vært i dag, men det ville sannsynligvis ikke vært «på trykk». Foruten å være en "forfatter du bør lese", er hun en som alltid har vært tilgjengelig for å gi råd og innsikt. Mange i UX-designfeltet skylder mye av det de vet til Christinas utrettelige innsats for å utvide horisonten vår ved å kontinuerlig innovere. TAKK

Will Evans og Todd Zaki Warfel leverte sjenerøst leveranser av høy kvalitet som du kan bruke som maler for dine egne leveranser. De var ekte brødre, og ga av sin tid og talenter uten spørsmål eller bekymring, ofte med et øyeblikks varsel. De er gode medlemmer av UX-fellesskapet vårt – de du vil kjenne og jobbe med – og jeg er velsignet over å være venner med dem. Jeg kan absolutt ikke yte rettferdighet til den takknemlighetsgjelden jeg skylder disse to. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky (og gjengen på crowdSPRING) og Wil Wheaton tjente meg godt som gode venner og sanne støttespillere og troende. Jeg er heldig bare som kan skrive disse navnene sammen som en liste over folk jeg kjenner, og jeg er en stor fan av alt de gjør. Deres støtte har vært en umåtelig fordel for meg i alt jeg gjør. Disse flinke menneskene gjorde alt de kunne for å hjelpe meg, og bidro sjenerøst med innspill, anekdoter og tilgang til ressursene deres, og jeg takker dem helhjertet: Tonia M. Bartz (www.toniambartz.com), kapittel 7; Steve “Doc” Baty, (www.meld.com.au), kapittel 3, 11, 14 og “A Brief Guide to Meetings”; Mark Brooks (www.markpbrooks.com), kapittel 3 og 11; Leah Buley (www. adaptivepath.com), kapittel 11; Dave Carlson (www.deech.com), kapittel 11; Will Evans (www.semanticfoundry.com), kapittel 7, 10 og 11; Christopher Fahey (www.behaviordesign.com), kapittel 14; Nick Finck (www.nickﬁnck.com), kapittel 10; Jesse James Garrett (www.adaptivepath.com), kapittel 10; Austin Govella (www.grafoﬁni.com), kapittel 11; Jon Hadden (www.jonhadden. com), kapittel 12; Whitney Hess (www.whitneyhess.com), kapittel 11; Andrew Hinton (www.inkblurt.com), kapittel 10; Gabby Hon (www.staywiththegroup.com), kapittel 3 og 11; Kaleem Khan (www.uxjournal.com), "A Brief Guide to Meetings"; Ross Kimbarovsky (www.crowdspring.com), kapittel 14; Livia Labate (www.livlab.com), kapittel 7; Michael Leis (www.michaelleis.com), kapittel 11; Troy Lucht (www.ascendrealtysolutions.com), kapittel 14; James Melzer (www. jamesmelzer.com), kapittel 10; Matthew Milan (www.normativethinking.com), kapittel 7; Chris Miller (www.hundredfathom.com/blog), "A Brief Guide to Meetings,"; Maciej Piwowarczyk (www.linkedin.com/pub/3/a74/a66), kapittel 11; Stephanie Sansoucie (www.linkedin.com/in/smsansoucie), kapittel 11; Kit Seeborg (www.seeborg.com), kapittel 3, 11 og "En kort veiledning til møter"; Josh Seiden (www.joshuaseiden.com), kapittel 7; Jonathan Snook (www. snook.ca), kapittel 12; Joe Sokohl (www.sokohl.com), kapittel 12 og "A Brief Guide to Meetings"; Samantha Soma (www.sisoma.com), "A Brief Guide to

TAKK

Møter"; Donna Spencer (www.maadmob.net), kapittel 7; Jared M. Spool (www.uie.com), kapittel 7; Keith Tatum (www.slingthought.com), kapittel 12; Todd Zaki Warfel (www.messagerst.com), kapittel 7, 12 og 14. Jeg vil også takke Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, Hugh Forrest fra SXSW, Peter Ina, Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw og Paula Thornton – så vel som Manifest Digital-folkene og alle på Draftfcb. Det er uunngåelig at jeg har savnet noen, og jeg håper det ikke blir tatt personlig. Det er en overflod av folk i "mengden" som ble hentet, og jeg har prøvd å holde styr på alle. Hvis jeg har savnet deg, gi meg beskjed, så skal jeg finne en måte å gjøre det riktig på! Til slutt er det viktig å merke seg at uten organisasjoner som Information Architecture Institute, Interaction Design Association og andre, ville det vært umulig for meg å knytte forbindelsene til mange av de nevnte personene. Hvis du i det hele tatt er nysgjerrig på feltet UX-design, kan du utforske disse organisasjonene, bli med og engasjere deg!

Carolyn Chandler Mange av oss drømmer om å skrive en bok på et tidspunkt i livet. Uten Russ vet jeg ikke om jeg noen gang ville ha fått motivasjonen til å hoppe inn og gjøre det. Hans energi og entusiasme hjalp oss med å finne de rette menneskene til rett tid, fra Peachpit-teamet til ledere i UX-industrien, som alle har hatt en enorm innvirkning på det du ser på disse sidene. Han er virkelig en av de store kontaktene i vårt felt, og han trives med å bringe mennesker sammen dag og natt. Dessuten tror jeg han legger ut flere tweets på en enkelt dag enn jeg har gjort siden jeg ble med på Twitter! Russ har takket mange av menneskene som hjalp oss begge enormt. Jeg vil ikke gjenta alle disse navnene bortsett fra Steve Baty, som leste alle kapitlene våre i hvilken som helst rå form vi kunne kaste på ham og fortsatt klarte å høres entusiastisk ut klokken 02.00 (tiden hans). John Geletka ga også gjennomtenkte tilbakemeldinger og spennende diskusjoner med en gnist og et perspektiv som krysser flere disipliner. Og selvfølgelig, Peachpit-teamet; Jeg vil aldri glemme å få tilbake mitt første kapittel fra Linda Laﬂamme. Det var ikke pent (selv om hun leverte forslagene med god takt). Hun tålmodig

TAKK

vii

tok meg gjennom redigeringene og hjalp meg med å forbedre flyten min, som opprinnelig var mer egnet til å skrive engangsoppgaver enn en bok i full lengde. Nå synes jeg til og med at jeg legger til overganger til mine tilfeldige samtaler med kolleger! Apropos … Christine Mortensen, a.k.a. Morty, var min partner in crime når det kom til de visuelle elementene. Ikonene og diagrammene du ser i kapitlene mine er et resultat av hennes harde arbeid – og jeg vet hvor hardt, fordi hun og jeg jobbet med mange av de samme kundeprosjektene samtidig som vi prøvde å overholde kapittelfristene. Morty er en av de visuelle designerne som kan plante sine føtter solid i både visuell design og interaksjonsdesign, muntert samarbeide med alle på prosjektet og bringe konsepter til liv. Hun har en integritet og et fokus på kvalitet som gjør henne til en fornøyelse å jobbe med, og det har vært en ære å ha henne som partner på dette. Tusen takk går også til alle folkene på Manifest Digital, som har vært så støttende de siste månedene. Jim Jacoby brakte en spesiell blanding av forretningskunnskap og UX-perspektiv, med sin varemerke zen-lignende ro, som fikk meg gjennom noen stressende øyeblikk. Jason Ulaszek er en av de mest entusiastiske menneskene jeg kjenner innen UX-feltet, og han har en uendelig kunnskap om verktøy og teknikker; Jeg aner ikke hvor han gir plass til det hele! Brett Gilbert og Jen O'Brien ga også verdifulle innspill til noen av de mange rollene som samarbeider med UX-designere. Jeg vil også takke medlemmene av Manifest UX-teamet, som har gitt inspirasjon og som har vært så tålmodige med mine konstante referanser til fremgang på "boken": Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne og Santiago Ruiz. Du er en konstant glede å jobbe med. Hver dag setter jeg pris på din humor og innsikt. Til mine medmedlemmer i Interaction Design Association, takk for at du deler dine erfaringer og for at du er aktive medlemmer av UX-fellesskapet som jeg elsker. Spesielt vil jeg takke Janna Hicks DeVylder og Nick Iozzo, som var nøkkelen i utviklingen av Chicago-kapittelet og som fortsetter å finne nye måter å utvikle et levende nettverk av smarte mennesker på. Sist, men ikke minst, vil jeg takke familien min, vennene mine og Anthony, som alle tålmodig har båret på forsvinningshandlingen min og stadig sjekket inn for å forsikre meg om at jeg fortsatt var i live. Du har mange regnsjekker å innløse, og jeg ser frem til å bruke dem sammen med deg!

viii

TAKK

Innhold INNLEDNING

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

KAPITTEL 1: Den

Tao av UXD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Hva er brukeropplevelsesdesign? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Den brede definisjonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Ikke glem det håndgripelige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Vårt fokus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Om UX-designere. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Hvor UX-designere bor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 La oss komme i gang! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 KAPITTEL 2: Den

Prosjekt økosystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Identifiser typen nettsted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Merkevaretilstedeværelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Markedsføringskampanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Innholdskilde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Oppgavebaserte applikasjoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 e-handelssider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 E-læringsapplikasjoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Applikasjoner for sosiale nettverk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Velg dine hatter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Informasjonsarkitekt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Interaksjonsdesigner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Brukerforsker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Andre roller du kan spille eller trenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Bygge et nettverk av brukerstøtte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Forstå bedriftskulturen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Hierarki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Logistikk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Trekker det sammen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 KAPITTEL 3: Forslag

for konsulenter og frilansere. . . . . . . . . . . . . . . . . . 39 Forslag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Opprette forslaget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

INNHOLD

Tittelside. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Revisjonshistorikk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Prosjektoversikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Prosjekttilnærming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Arbeidsomfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Forutsetninger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Leveranser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Eierskap og rettigheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Tilleggskostnader og gebyrer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Prosjektprising. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Betalingsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Bekreftelse og avmelding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Arbeidserklæringer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 KAPITTEL 4: Prosjekt

Mål og tilnærming . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Befeste prosjektmål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Hvordan kan en UX-designer hjelpe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Forstå prosjekttilnærmingen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Fossefall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile tilnærminger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Modifiserte tilnærminger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Hvordan påvirker tilnærmingen meg?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 KAPITTEL 5: Næringsliv

Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Forstå gjeldende tilstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristisk analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Samle ideer fra interessenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Skissere ansvar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Samle de rette interessentene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Lag en plan for møtene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Salg: Krav-samlingsmøte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Kjør møtene effektivt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Koalesceringskrav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

INNHOLD

KAPITTEL 6: Bruker

Forskning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Grunnleggende trinn for brukerundersøkelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Definer brukergruppene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Opprette en liste over attributter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Prioriter og definer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Velge forskningsteknikker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Hvor mange forskningsaktiviteter kan jeg inkludere? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Brukerintervjuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Kontekstuell forespørsel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Undersøkelser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Fokusgrupper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Kortsortering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Brukervennlighetstesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Etter forskningen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 KAPITTEL 7: Personas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Hva er personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Hvorfor skulle jeg opprette personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Finne informasjon om personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Opprette personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Minimumskrav til innhold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Valgfritt innhold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

Avanserte personas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Siste tanker om personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 KAPITTEL 8: Bruker

Erfaring med design og søkemotoroptimalisering. . . . 126 Introduksjon til SEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Hvorfor er SEO viktig? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Viktige grunnleggende ressurser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Nettstedsteknologi, design og infrastruktur . . . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript og annet skriptinnhold . . . . . . . . . . . . . . . . . . . . . . 130 Innholdsstyringssystemer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Domener, katalog og URL-struktur betyr alt. . . . . . . . . . . . . . . . . . . . . . . . 134

Innhold: The Once (and Current) and Future King . . . . . . . . . . . . . . . 135 Navnekonvensjoner og kampen mot sjargong . . . . . . . . . . . . . . . . . . . . . 136 Metadata, topptekster og nøkkelord. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

INNHOLD

Del hårene. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Bruk områdekart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Hold innholdet ferskt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Andre innholdsproblemer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Link popularitet forklart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Typisk koblingspopularitetsdistribusjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Bunntekstlenker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Innholdskrysskobling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

Spille systemet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 White Hat Versus Black Hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Spamming med metanøkkelord. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Kloning og døråpningssider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Link spamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Noen siste tanker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 KAPITTEL 9: Overgang:

Fra definering til design. . . . . . . . . . . . . . . . . . . . 144 Ideer og visualiser funksjoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Den grunnleggende prosessen med storyboarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Tilrettelegge prioriteringsprosessen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Oppretthold en god spenning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Utviklingsadvokaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Håndtere konflikter under prioritering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Planlegg dine aktiviteter og dokumentasjon. . . . . . . . . . . . . . . . . . . . . . . . 162 KAPITTEL 10: Sted

Kart og oppgaveflyt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Hva er et nettstedskart? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Hva er en oppgaveflyt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Handelens verktøy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Grunnleggende elementer i nettstedskart og oppgaveflyt. . . . . . . . . . . . . . . . . . . . . 168 side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Sidestabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Beslutningspunkt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Koblinger og piler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Forhold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Vanlige feil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Slurvete tilkoblinger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

xii

INNHOLD

Feiljusterte og ujevnt fordelte objekter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Dårlig plassert tekst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Mangel på sidenummerering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Det enkle nettstedskartet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Avanserte nettstedskart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Bryte nettstedkartformen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Oppgaveflyter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Ta oppgaveflyt til neste nivå. . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Prosessflyt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Svømmefly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 KAPITTEL 11: Wireframes

og merknader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Hva er en Wireframe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Hva er merknader?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Hvem bruker Wireframes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Opprette Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Handelens redskaper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Start enkelt: Design en grunnleggende wireframe . . . . . . . . . . . . . . . . . . . . . . . . . .191 Komme i gang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Wireframes og merknader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

En øvelse: Design en hjemmeside Wireframe . . . . . . . . . . . . . . . . . . . 195 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Resultatene: Design en hjemmeside-trådramme . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Visuell design: Når Wireframes vokser opp og finner sin egen vei i verden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Designøvelsesoppfølging: Hvilket design er riktig? . . . . . . . . . . . . . . . . . . . . . . 201

En siste merknad om presentasjon av Wireframes. . . . . . . . . . . . . . . . . . . . . . . . . 202 KAPITTEL 12: Prototyping.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 Hva er prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Hvor mye prototype trenger jeg? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Papirprototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Digital prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Wireframe vs. realistiske prototyper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML vs. WYSIWYG-redaktører . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Ekstra verktøy for prototyping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

INNHOLD

xiii

Arbeide med en utvikler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Eksempler på prototyper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 Hva skjer etter prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 KAPITTEL 13: Design

Testing med brukere. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Konseptutforskning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 tips om å utforske visuelle designmodeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Brukbarhetstesting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Velge en tilnærming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Planlegging av forskningen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Rekruttering og logistikk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Skrive diskusjonsveiledninger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Tilrettelegging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analysere og presentere resultater. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Lage anbefalinger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 KAPITTEL 14: Overgang:

Fra design til utvikling og utover. . . . . . 247 Dette er slutten…. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Visuell design, utvikling og kvalitetssikring . . . . . . . . . . . . . 248 Designtesting med brukere (igjen). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … Lansering! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Personlig fordel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Støtte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Nettverks mening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Aktiviteter etter lansering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Analytics etter lansering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Designtesting etter lansering med brukere (igjen, igjen) . . . . . . . . . . . . . . . . . . . . . 255

Alt ferdig, ikke sant? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Akkurat som å starte på nytt... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 INDEKS

xiv

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

INNHOLD

Introduksjon Hvorfor vi skrev denne boken Velkommen til en prosjektguide for UX-design. Et sted er det en student i brukeropplevelsesdesign som mister søvn fordi han ikke vet hvordan det vil være å jobbe med et virkelig prosjekt i det nye selskapet sitt. Over hele byen er det en visuell designer med mye prosjekterfaring som lengter etter å ta på seg nytt ansvar for å definere nettstedets brukeropplevelse. Dette er to personer på forskjellige tidspunkt i livet, men med et lignende behov: å forstå hvordan man kan integrere brukeropplevelsespraksis i sammenheng med et levende, pustende prosjekt. Målet vårt med denne boken er å gi deg de grunnleggende verktøyene og konteksten som vil hjelpe deg å bruke UX-verktøy og -teknikker med arbeidslag. Som du vil se i mange av disse kapitlene, prøver vi ikke å være alt for alle mennesker, men vi prøver å gi deg kjerneinformasjonen og kunnskapen du bør ha for å utføre mange av pliktene du skal bli tildelt som UX-designer. Utover våre egne eksempler, gir vi deg eksempler som hjelper deg med å identifisere måter å sette i gang grunnleggende materiell og lar deg blande sammen informasjonen og lage noe nyere, bedre eller enda mer tilpasset dine egne formål. Vi håper vi har gjort en anstendig jobb med å artikulere at dette er en ganske god tilnærming til UX-designprosjekter. Vi er ingenting hvis ikke hele tiden prøver å lære og forbedre (hva enn vi gjør) med hver iterasjon. Det er derfor vi til en viss grad er i dette feltet. Et ord fra Russ Som mentor for Information Architecture Institute (www.iainstitute.org) har jeg lagt merke til et mønster blant menneskene jeg har jobbet med: De fleste hadde enten problemer med å få jobber eller var ikke på linje med forventningene til potensielle arbeidsgivere . Noen hadde enestående utdanning, men ikke alltid nok praktisk anvendelse av UX-designferdighetene sine i en prosjektbasert setting. De samme temaene ga gjenklang i mange av samtalene jeg hadde på Information Architecture Summit (www.iasummit.org) i 2008. Det var da

INTRODUKSJON

Ideen til denne boken – som tar opp mange av disse vanlige problemene – begynte å ta form. Jeg husker ikke om Carolyn eller jeg sendte den første e-posten, men jeg vet at i henne fant jeg en villig og dyktig medforfatter som hjalp meg med å slipe hjørnene av ideen som til slutt ble denne boken. Et ord fra Carolyn I mange år nå har jeg vært i den heldige posisjonen med å bygge og administrere UX-team. Jeg sier "heldig" fordi jeg finner ut at UX-designere generelt har en flott balanse av egenskaper som gjør dem ganske morsomme å jobbe med, og blander høyre-hjerne-intuisjon og venstre-hjerne-logikk. Ettersom jeg har gjennomført intervjuer for å bygge disse teamene, har én ting virkelig stukket seg ut: En relatert utdanningsbakgrunn, som menneskelige faktorer eller kommunikasjonsdesign, er en god indikator på at noen er forpliktet til feltet UX-design, men det er ikke antallet. en indikator på om noen ville passe godt inn i teamet eller på et prosjekt. Like viktig – om ikke mer – er personens evne til å ha en konsulents tankesett. Dette betyr en positiv holdning, en drivkraft til å forstå og inkludere andre gjennom et prosjekt, og fremfor alt et fokus på å gjøre en reell innvirkning for brukere og kunder. Denne tankegangen betyr å ta deg tid til å forstå perspektivene til andre roller på prosjektet, lage saker og inngå kompromisser der det er nødvendig. Det krever erfaring og krefter for å få denne tankegangen virkelig godt ned, men å ha et åpent sinn, et sterkt grunnlag og et godt sett med spørsmål (med mot til å stille dem) kan ta deg en lang vei. Denne boken gir kanskje ikke alle «svarene», men den vil gi deg spørsmålene du bør stille for å hjelpe deg med å finne dem.

Hvem bør lese denne boken En prosjektveiledning til UX-design gir en bred, introduksjonsoversikt over UX-design innenfor rammen av et prosjekt. Alle med interesse for UX-design bør finne noe nyttig her. Vi fokuserte spesielt på følgende grupper: Studenter som tar UX-designkurs (som menneske-datamaskin-interaksjon eller interaksjonsdesign) som ønsker å supplere kursene sine med informasjon om hvordan de kan anvende sin læring i virkelige situasjoner, der kommunikasjon og samarbeid er livsviktig.

xvi

INTRODUKSJON

Utøvere som ønsker å utdype kunnskapen om de grunnleggende verktøyene og teknikkene for UX-design og forbedre teamkommunikasjonen om rollene som er involvert. Kapittel 3 er også spesielt rettet mot frilansere som trenger å lage sine egne forslag. Ledere av UX-designgrupper som leter etter en bok som vil hjelpe teamene deres med å integrere prosjektbestemmelser med UX-designaktiviteter. Ledere for alle prosjektteam som er interessert i å lære mer om hvordan UX-design integreres i prosjektene deres, hva verdien er og hva du kan forvente av UX-designere. HVIS DU MÅ...

DA BØR DU LESE...

Definer brukeropplevelsesdesign og forstå hva som trekker folk til feltet

Kapittel 1: Tao av UXD

Still spørsmålene som er viktige å ha besvart før prosjektet starter (eller i det minste før du begynner å jobbe med det)

Kapittel 2: Prosjektøkosystemet Kapittel 3: Forslag for konsulenter og frilansere

Start ting riktig med effektive møter, klare mål og godt forståtte godkjenningspunkter

Nettkapittel: En kort veiledning til møter Kapittel 4: Prosjektmål og tilnærming

Definer prosjektkrav som er entydige og enkle å prioritere, hentet fra virksomhetens interessenter og brukere

Kapittel 5: Forretningskrav Kapittel 6: Brukerforskning Kapittel 9: Overgang: Fra å definere til å designe

Lær om brukerne dine og representer deres behov gjennom hele prosjektet

Kapittel 6: Brukerforskning Kapittel 7: Personas Kapittel 13: Designtesting med brukere

Velg og bruk verktøyene og teknikkene som gjør at du raskt kan bringe visuelle ideer til prosjektteamet ditt

Kapittel 10: Områdekart og oppgaveflyt Kapittel 11: Wireframes og merknader Kapittel 12: Prototyping

Sørg for at nettstedet ditt er enkelt å finne og søke i av brukere og søkemotorer

Kapittel 8: Design av brukeropplevelse og søkemotoroptimalisering

Kommuniser og utvikler designet ditt med prosjektteamet når utviklingen starter

Kapittel 14: Overgang: Fra design til utvikling og utover

Sørg for å besøke www.projectuxd.com for å lese bonuskapittelet "En kort veiledning til møter" og for å laste ned annet bonusmateriell som maler.

INTRODUKSJON

xvii

En merknad om metodikk Det finnes en rekke tilnærminger og metoder der ute. Vi er ikke tilhengere av en tilnærming fremfor en annen. Målet vårt for denne boken er å fokusere på trinnene som er felles for de fleste prosjekter: å definere prosjektbehovene, utforme opplevelsen og utvikle og distribuere løsningen. Mengden overlapping mellom disse trinnene vil variere sterkt avhengig av prosjekttilnærmingen du bruker (se kapittel 4 for mer detaljer). For det meste er rammeverket vårt en løs, lineær tilnærming, der definisjonstrinnet kommer først – men i hvert trinn drar vi nytte av tilrettelegging og designteknikker der de er mest nyttige.

Hva denne boken ikke er Et leksikon over alle teknikker. UX-feltet har et enormt antall kreative mennesker, og de prøver alltid nye tilnærminger til designproblemer. Å inkludere alle disse tilnærmingene her ville gjøre en mye større bok – og en som raskt ville bli utdatert. Det vi har tatt med her er de mest brukte teknikkene, mutrene og boltene til UX-design. Vi har forsøkt å gi nok informasjon til både å fascinere deg og la deg kommunisere aktivitetene til andre prosjektmedlemmer – inkludert den grunnleggende prosessen for hver teknikk og ytterligere referanser til bøker eller nettsteder som vil hjelpe deg med å implementere den når du velger din vei. En guide til å være prosjektleder. God prosjektledelse (inkludert å sette og spore prosjektmål, tidslinjer og budsjetter) er nøkkelen til ethvert prosjekts suksess. Vi dekker ikke spesifikasjoner for hvordan man skal være prosjektleder eller hvordan man velger en bestemt prosjektmetodikk. Vi diskuterer ferdighetene som en UX-designer tilfører et prosjekt som gjør at det kan kjøre effektivt, for eksempel tilrettelegging og kommunikasjon, samt evnen til å tydeliggjøre og opprettholde fokus på prosjektmål. Disse ferdighetene vil hjelpe deg å bli en partner i prosjektledelse. Den eneste eller den perfekte prosessen eller metodikken for deg å følge. Vi har ikke alle svarene – ingen har det i dag. UX-designfeltet er relativt ungt, og vi jobber alle med å forbedre oss der vi er. Du vil sannsynligvis finne den prøving og feiling, forbedringer og forbedringer og tilbakemeldinger

xviii

INTRODUKSJON

fra andre vil hjelpe deg med å skreddersy en prosess som passer dine behov. Når du finner noe som fungerer for deg – del det! Gi oss beskjed!

Slik bruker du denne boken Det er mange gode ressurser der ute for UX-designere. Vi dekker emner bredt her, men peker deg til referanser som lar deg utforske emner på et dypere nivå avhengig av hvor mye tid du vil bruke til dem. For å hjelpe deg å forstå hvor mye tid som vanligvis trengs for hver referanse, har vi delt dem inn i tre hovedkategorier:

Surfereferanser kalt ut med surfebrettet er kortere funksjoner (vanligvis online) som vil ta 5 til 30 minutter å lese.

Snorkling De som kalles ut med snorkelen er lengre nettartikler, hvitebøker eller korte bøker som det tar alt fra en time til en helg å lese.

Deep Diving De som kalles ut med dykkerhjelmen er lengre bøker som sannsynligvis vil ta mer enn én helg å lese; de gir deg en grundig dekning av emnet.

INTRODUKSJON

xix

Denne siden er tom med hensikt

Tao av UXD Nysgjerrighet møter lidenskap møter empati Det viktige er å ikke slutte å stille spørsmål. Nysgjerrighet har sin egen grunn til å eksistere. Man kan ikke unngå å være i ærefrykt når han betrakter mysteriene om evigheten, livet, om virkelighetens fantastiske struktur. Det er nok om man bare prøver å forstå litt av dette mysteriet hver dag. Albert Einstein

En følelse av nysgjerrighet er naturens opprinnelige skole for utdanning. Smiley Blanton

Lidenskap og hensikt går hånd i hånd. Når du oppdager formålet ditt, vil du normalt finne at det er noe du brenner enormt for. Steve Pavlina

Den store gaven til mennesker er at vi har empatiens kraft. Meryl Streep

Dette kapittelet handler ganske enkelt om deg – og om andre som er tiltrukket av feltet brukeropplevelsesdesign (eller UX-design, for kort).

Hvis du leser denne setningen, er du en nysgjerrig person. Du vil vite hvordan ting fungerer – alt fra dørhåndtak til fly til den tingen bak i halsen. Mest av alt vil du vite hva som får folk til å tikke. Du ser ikke ting som svart og hvitt; det er en hel masse gråtoner å utforske! Jada, noen ganger kan du gjøre dine jevnaldrende litt gale ved å alltid melde deg frivillig til å spille djevelens advokat, men det er ikke slik at du kan stoppe deg selv fra å prøve å se på den andre siden av mynten. Heldig du! Brukeropplevelsesdesignfeltet tiltrekker seg nysgjerrige folk som er komfortable med å jobbe med mange nyanser av grått. Vi oppsøker mønstre og trives med organisering og struktur. Vi kobler sammen prikkene. Vi forfølger nådeløst neste brikke i puslespillet, og når puslespillet er løst, ser vi etter måter å forbedre det på! Vi kan være analoge eller digitale. Vi er hjemme med blyant og papir, tavler og tusjer, Post-it-lapper og Sharpie-penner. Vi snakker om Visio og 'Graffle, og vi lever i en verden av bokser og piler koblet sammen på flere skjermer på datamaskinene våre. Vi er ikke bare nysgjerrige. Vi er lidenskapelige! Vi har lidenskap for idédugnad og tilrettelegging for diskusjoner. Vi har en lidenskap for å skape ting som gjør en forskjell for de som bruker dem – og de som skaper dem. Merkelig nok er vi mest stolte når noe vi lager er så bra at folk ikke skjønner hvor bra det er! Og selvfølgelig har vi empati. Vi kan føle det dypt inne i kjernen av vesenet vårt når vi møter en dårlig opplevelse. Enda verre, vi prøver umiddelbart å finne løsninger for å løse problemene. Vi vet hvordan det er å få et uventet svar på det som virker som en enkel forespørsel – og vi liker det ikke! Vi vil ikke at brukere – folk akkurat som oss – skal måtte tåle forvirringen og følelsen av utilstrekkelighet som ofte går hånd i hånd med en dårlig opplevelse. 2

KAPITTEL 1: TAO FOR UXD

Når du kombinerer den nesten konstante, barnlige nysgjerrigheten med en uovertruffen lidenskap for å "gjøre det vi gjør" og en følelse for hvordan andre har det, ender du opp med et livlig fellesskap av fagfolk som er komfortable med å si sin mening, stille spørsmål, dele løsninger, og å være feil – alt i navnet for å komme til det som er rett. Velkommen til UX-designfellesskapet.

Hva er brukeropplevelsesdesign? Det er mange definisjoner for design av brukeropplevelse. Tross alt er det et felt som trives med å definere ting. Riktignok gjør vi noen ganger ikke en så god jobb med å "definere den jævla greia" når det kommer til de ulike delene av helheten, men vi vet i det minste hva helheten er. I denne boken vil vi fokusere på to definisjoner spesielt: den bredeste betydningen av begrepet UX-design og definisjonen vi vil bruke i sammenheng med denne boken.

Den brede definisjonen brukeropplevelsesdesign er opprettelsen og synkroniseringen av elementene som påvirker brukernes opplevelse med et bestemt selskap, med den hensikt å påvirke deres oppfatninger og oppførsel.

Disse elementene inkluderer tingene en bruker kan berøre (som håndgripelige produkter og emballasje), høre (reklamer og lydsignaturer) og til og med lukte (aromaen av nybakt brød i en smørbrødbutikk). Det inkluderer de tingene som brukere kan samhandle med på andre måter enn det fysiske, for eksempel digitale grensesnitt (nettsteder og mobiltelefonapplikasjoner), og selvfølgelig mennesker (kundeservicerepresentanter, selgere og venner og familie). En av de mest spennende utviklingene de siste årene har vært evnen til å slå sammen elementene som påvirker disse forskjellige sansene til en rikere, integrert opplevelse. Smell-o-vision ligger fortsatt langt frem i tid, men ellers fortsetter produktene å viske ut de tradisjonelle linjene.

HVA ER BRUKEROPPLEVELSESDESIGN?

Ikke glem det konkrete Selv om vi fokuserer på de digitale aspektene ved brukeropplevelsen, skjer ikke denne typen interaksjoner i et vakuum. Husk å vurdere effekten av den konkrete opplevelsen når du designer dine digitale produkter. Miljøet brukerne dine arbeider innenfor har betydning, det samme gjør de fysiske produktene (skjermer, tastaturer og andre inndataenheter) som påvirker måten brukerne vil samhandle med designet ditt. Kapittel 6 tilbyr teknikker som hjelper deg å forstå konsekvensen av kontekst. Ikke glem de andre kontaktpunktene et produkt eller selskap har med de som samhandler med det. Tross alt er merkevaren til selskapet påvirket av mange ting, og merkeopplevelsen slutter ikke på skjermen til en datamaskin eller en mobiltelefon. Den best mulige nettsidedesignen kan ikke veie opp for et rykte for dårlig kundeservice eller gi tilfredsstillelsen av godt designet emballasje når et produkt blir levert.

Figur 1.1 En moderne klasseromsopplevelse blander det analoge og det digitale.

KAPITTEL 1: TAO FOR UXD

Håndgripelige opplevelser, som læring i et klasserom, blir i økende grad påvirket av digitale applikasjoner. På samme måte blir opplevelser som pleide å være individuelle, for eksempel å velge hvilken hjemmekaraokemaskin du skal kjøpe, i økende grad forbedret gjennom sosial interaksjon.

Figur 1.2 Online anmeldelser er en stor påvirkningsfaktor for forbrukere.

Vårt fokus Som du kan se, er omfanget av UX-design stort og økende. I denne bokens formål vil vi fokusere på prosjekter sentrert om utforming av digitale opplevelser – spesielt slike interaktive medier som nettsider og programvareapplikasjoner. For å lykkes, må brukeropplevelsesdesignet til disse produktene ta hensyn til forretningsmålene til prosjektet, behovene til produktets brukere og eventuelle begrensninger som vil påvirke levedyktigheten til produktfunksjoner (som tekniske begrensninger eller begrensninger rundt prosjektbudsjettet) eller tidsramme).

HVA ER BRUKEROPPLEVELSESDESIGN?

Gratis prøver av en ny ernæringsbar delt ut på et maraton

Et dørhåndtak

Emballasje til et par sko

Figur 1.3 Denne boken fokuserer på de digitale aspektene ved design av brukeropplevelse.

Håndfaste tekstfunksjoner for mobiltelefoner

Kundeservice telefonsamtale

Individuell

Sosial

Vårt fokus Lese produktanmeldelser på nett Søke i et nettarkiv Se målrettet annonsering

Digital kundeservice live chat

Om UX-designere Selv om nysgjerrighet, lidenskap og empati er egenskaper som designere av brukeropplevelser deler, er det også et ønske om å oppnå balanse. Vi søker etter en balanse, spesielt mellom logikk og følelser, som Spock og Kirk eller Data og Data i den episoden der følelsesbrikken hans overbelastet hans positroniske reléer. Du skjønner ideen. For å skape virkelig minneverdige og tilfredsstillende opplevelser, må en UX-designer forstå hvordan man skaper en logisk og levedyktig struktur for opplevelsen og trenger å forstå elementene som er viktige for å skape en følelsesmessig forbindelse med produktets brukere. Den nøyaktige balansen kan endre seg i henhold til produktet. En annonsekampanje for et barns leketøy vil ha en annen balanse enn en applikasjon for sporing av pasientinformasjon på et sykehus. Et produkt designet uten å forstå behovet for begge vil sannsynligvis gå glipp av muligheter for en virkelig minneverdig opplevelse – og de resulterende fordelene for selskapet bak produktet. Merk For ytterligere informasjon om emosjonell design, sjekk ut Donald Normans Emotional Design: Why We Love (or Hate) Everyday Things (Basic Books, 2005).

KAPITTEL 1: TAO FOR UXD

Å oppnå den balansen krever en økt følelse av empati: evnen til å fordype deg i verdenen til potensielle produktbrukere for å forstå deres behov og motivasjoner. Designere av brukeropplevelser utfører undersøkelser for å oppnå denne forståelsen (se kapittel 6) og lager slike verktøy som personas (se kapittel 7) for å hjelpe resten av prosjektteamet med å fokusere innsatsen. Husk at følelser bare er en del av helhetsbildet. Bruk den logiske siden for å bringe deg tilbake fra kanten og holde tankene dine på oppgavene du har for hånden. I de fleste tilfeller vil du jobbe mot et budsjett som er basert på tiden og materialene som kreves for å fullføre prosjektet. Du må forstå at noen ganger må du fiske eller kutte agn.

Hvor UX-designere bor Du er ikke alene om dette. Se deg rundt og du vil finne en rekke organisasjoner og fellesskap som kan fremme utviklingen din som brukeropplevelsesdesigner. I tillegg til å tilby e-postlister, nettressurser og en hel rekke virkelig smarte mennesker, sponser mange av disse organisasjonene arrangementer eller konferanser som kan hjelpe deg med å utvide horisonten og begrense karrierefokuset ditt på samme tid. En rekke selskaper arrangerer arrangementer rettet mot å tilby videreutdanning, inkludert User Interface Engineerings Web App Summit og User Interface Conference, Adaptive Paths UX Intensive og Nielsen Norman Groups Usability Week. Det er også et økende antall "unconferences" i forskjellige byer; disse er skapt av en samling motiverte individer uavhengig av et bestemt selskap eller forening.

HVOR UX-DESIGNERE BOR

Flere profesjonelle organisasjoner sponser også årlige konferanser. Tabell 1.1 gir en kort liste over noen av de mer kjente organisasjonene, deres nettsteder og arrangementer som de er vertskap for. TABELL 1.1

Et utvalg av UX-organisasjoner

ORGANISASJON

NETTSTED

STOR KONFERANSE (Typisk avholdt)

Interaction Design Association (IxDA)

www.ixda.org

Interaksjon (tidlig i februar)

Informasjonsarkitekturinstituttet (IAI)

www.iainstitute.org

IDEA-konferanse (september/oktober)

American Society for Information Science and Technology (ASIS&T)

www.asis.org

IA Summit (mars)

ACM Special Interest Group on ComputerHuman Interaction (SIGCHI)

www.sigchi.org

CHI (begynnelsen av april)

The Usability Professionals' Association

www.usabilityprofessionals.org

UPA (juni)

La oss komme i gang! Du har kommet så langt. Det er på tide å komme inn på grunnen til at du plukket opp denne boken i utgangspunktet. Snu siden og ta et dykk inn i hvordan brukeropplevelsesdesign eksisterer innenfor prosjektområdet. Men ikke stopp der – denne boken er en guide for å komme i gang. Den har mange eksempler som kan hjelpe deg med å levere på mange av aktivitetene du vil få i oppgave. Vi har også prøvd å gi flere eksempler for å hjelpe deg med å utvide og finne din egen beste tilnærming for å lage leveranser som er nyttige for teamet ditt og kundene dine. Hold nysgjerrigheten, lidenskapen og empatien i live! Utfordre deg selv til å finne nye måter å inspirere andre til å bygge den ideelle brukeropplevelsen. Det er selvfølgelig før du tar sikte på å forbedre det.

KAPITTEL 1: TAO FOR UXD

Prosjektøkosystemplanlegging for prosjektbehov, roller og kultur Er du i ferd med å starte et helt nytt prosjekt? Eller er du midt i en? Uansett, ta deg tid til å vurdere dynamikken og konteksten til prosjektet – problemene som vil påvirke deg og resten av prosjektteamet. Hvilken type nettsteder eller applikasjoner er involvert? Hvilke roller og ferdigheter trengs? Hva er bedriftskulturen? Å svare på disse spørsmålene vil hjelpe deg med å definere prosjektet og til slutt bestemme verktøyene og ferdighetene du trenger å ta med til bordet for å lykkes. Carolyn Chandler

hvert prosjekt har sine egne unike utfordringer. Hvis du designer nettsider eller applikasjoner, vil mange av disse utfordringene involvere spesifikke funksjoner og funksjonalitet, for eksempel å bygge en metode for en bruker å dele bilder med venner og familie på nettet eller restrukturere informasjonen på et intranett slik at innholdet kan bli mer lett å finne og dele. Rundt disse spesifikke designmålene har imidlertid alle prosjekter en større kontekst som du trenger for å forstå og integrere i planleggingen din. Denne konteksten er prosjektets "økosystem", og den inkluderer miljøet du arbeider innenfor (bedriftskulturen), den generelle typen arbeid du alle vil være engasjert i (som typen nettsted du designer), og personene du skal samhandle med (inkludert deres roller og ansvar). Hvis du tar deg tid til å forstå prosjektets økosystem, vil du ha kunnskap som vil hjelpe deg gjennom hele prosjektet. Du kan kommunisere dine ansvarsområder og ideer mer effektivt, og du kan hjelpe andre i teamet med å forutse prosjektbehov de kanskje ikke har vurdert. For å hjelpe deg identifiserer dette kapittelet ulike typer prosjekter du kan jobbe med, så vel som rollene du kan spille, personene du kan være avhengig av og hvordan deres involvering har en tendens til å variere med typen nettsted eller applikasjon som utformes. Til slutt diskuterer kapittelet noen elementer ved bedriftskulturen som kan påvirke hvordan du jobber i løpet av prosjektet. Merk Avhengig av hvordan kundebedriften din strukturerer sine prosjekter, kan et bestemt prosjekt innebære utforming av mer enn én side eller applikasjon. For enkelhets skyld antar denne boken at et prosjekt involverer design av en enkelt type nettsted. Hvis du har mer enn ett nettsted, bør du vurdere hver enkelt for å sikre at du har de riktige rollene representert i prosjektteamet.

Identifiser typen nettsted Selv om det ikke finnes noen svart-hvitt-forskjeller mellom en type nettsted og en annen, kan noen relative forskjeller i fokus og egenskaper identifiseres. Å forstå disse likhetene og forskjellene kan hjelpe deg med å sette designmål for deg selv. Dette er de generelle problemene som må være

løst (som "forklar selskapets forretningsmodell") eller attributtene som må representeres (som "demonstrere selskapets reaksjonsevne overfor kundene") innenfor nettstedets visuelle design og interaksjonsdesign.

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

Befeste hovedmålene for prosjektet (se kapittel 4). Forstå hvilke avdelinger eller forretningsenheter som kan (eller bør) være

involvert når du samler forretningskrav (se kapittel 5). Bestem de beste metodene for å inkludere brukerundersøkelser (se kapittel 6). Still spørsmål om hvilke systemer og teknologier som kan være involvert.

Nettstedet ditt vil sannsynligvis assosieres sterkt med en av fire typer:

Merkevaretilstedeværelse – en konstant tilstedeværende nettplattform som forenkler forholdet mellom selskapet og et generelt publikum (alle som er interessert i dets produkter eller tjenester) Markedsføringskampanje – et målrettet nettsted eller applikasjon som er ment å utløse en spesifikk og målbar respons fra en bestemt målgruppe eller fra et generelt publikum over en begrenset tidsperiode Innholdskilde – en lagring av informasjon, potensielt sammensatt av flere typer medier (artikler, dokumenter, video, bilder, veiledninger) ment å informere, engasjere eller underholde brukere Oppgavebasert applikasjon – en verktøy eller samling av verktøy ment å tillate brukere å utføre et sett med nøkkeloppgaver eller arbeidsflyter

De neste avsnittene tar en nærmere titt på hver av disse typene, og diskuterer deres egenskaper og innvirkningen de vil ha på utfordringene dine under utformingen av nettstedet eller applikasjonen. Vi vil også diskutere de vanligste crossover-prosjektene – e-handel, e-læring og sosiale nettverk – som har kjennetegn på mer enn én type.

Merkevaretilstedeværelse Hva tenker du på når noen sier ordet merkevare? Ofte er det første du tenker på, et firmas logo, for eksempel Nike Swoosh eller Coca-Cola-manusemblemet. Et selskaps merke er mye mer enn logoen deres; det er hele serien av inntrykk som en bestemt person har om selskapet.

IDENTIFISERE TYPE NETTSTED

Dirk Knemeyer presenterer noen utmerkede definisjoner av merkevare i sin artikkel "Brand Experience and the Web": Brand representerer de intellektuelle og emosjonelle assosiasjonene som folk lager med et selskap, et produkt eller en person ... Det vil si, merkevare er noe som faktisk ligger innenfor hver av oss. Vitenskapen om merkevarebygging handler om å designe for og påvirke sinnet til mennesker – med andre ord å bygge merkevaren.

Surfing For mer informasjon om forskjellene mellom en kundes opplevelse av en bedrifts merkevare og en bedrifts innsats for å bygge merkevaren, les Dirk Knemeyers forklaring i "Brand Experience and the Web": www.digital-web.com/articles/brand_experience_and_the_web. For en utmerket diskusjon om hvordan et nettsteds UX-design kan påvirke en persons merkevareopplevelse, les Steve Batys artikkel "Brand Experience in User Experience Design": www.uxmatters.com/MT/archives/000111.php.

Et selskap kan gjøre mye for å påvirke assosiasjonene som knyttes til merkevaren, fra å kjøre minneverdige reklamekampanjer til å uttrykke merkeegenskaper (som «responsivitet» eller «verdi») gjennom funksjonene og utformingen av nettsidene. Alle nettsteder i et selskap vil sannsynligvis ha en viss innvirkning på et selskaps merkevare, enten direkte (ved å presentere et nettsted som kunder kan besøke) eller indirekte (ved å aktivere en nøkkeltjeneste som kundene stoler på, for eksempel kundestøtte). Nettsteder for merkevaretilstedeværelse er imidlertid mest fokusert på å presentere selskapets merkevaremeldinger og verdier. De tilbyr kanaler som har direkte grensesnitt med kunder og fungerer som en bred netttrakt for de som er interessert i å finne ut mer om selskapet eller dets tilbud. Et nettsted for merkevaretilstedeværelse er ofte selskapets primære .com- eller .org-nettsted, for eksempel GE.com, eller for større og mer distribuerte selskaper er de primære nettstedene for forretningsenheter av varierende størrelse, for eksempel GEhealthcare.com. Distinkte produktlinjer har også ofte sin egen unike merkevaretilstedeværelse på nett. For eksempel har Pepsico.com én merkevaretilstedeværelse, mens Pepsi.com har sin egen distinkte tilstedeværelse.

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

Hvis du jobber med et nettsted for merkevaretilstedeværelse, vil du sannsynligvis designe for en rekke brukergrupper, inkludert nåværende og potensielle kunder, investorer, partnere, media (som nyhetsorganisasjoner og forfattere av fremtredende blogger) og jobb søkere.

Vanlige nettsteder for merketilstedeværelse Et selskaps hovedhjemmeside (company.com, company.org, company.net, etc.) Et nettsted for en primær forretningsenhet i selskapet (ofte et unikt nettsted for en

bestemt bransje, region eller stor serie med produkter) Nettsteder for fremtredende undermerker i et selskap

Designmål for merketilstedeværelse Designmålene som ofte er av størst betydning i et merketilstedeværelsesprosjekt er disse: Formidle merkeverdiene og merkevarebudskapene til selskapet,

enten eksplisitt (kanskje en uttalelse om hvor viktig det er å være lydhør overfor kundenes behov) eller gjennom den generelle opplevelsen når du går inn på nettstedet (som for eksempel å sikre at det fungerer godt og fremtredende tilbyr funksjoner som oppmuntrer kunder til å kommunisere med selskapet). Gi rask og enkel tilgang til bedriftsinformasjon. Vil du

svar på spørsmålene "Hva gjør selskapet?" og "Hvordan kontakter jeg noen for mer informasjon?" Presenter eller forklar bedriftens forretningsmodell og verdiforslag:

"Hva kan selskapet gjøre for meg?" og "Hvordan gjør selskapet det?" Engasjer et sett med primære brukergrupper og veileder dem til relevant interaksjon

sjoner, funksjonalitet eller innhold. Hjelp selskapet med å oppnå mål som settes opp mot nøkkeltall, som f.eks

antall unike besøkende. Ofte er dette en del av en overordnet markedsføringsstrategi. Senere, i delen "Velg hattene dine", vil du lære de ulike rollene som kan være involvert i utformingen av et nettsted for merkevaretilstedeværelse. For nå, la oss ta en titt

IDENTIFISERE TYPE NETTSTED

1. 3

på andre typer nettsteder du kanskje jobber på, inkludert en som har et nært forhold til nettsteder for merkevaretilstedeværelse: nettstedet for markedsføringskampanjer.

Markedsføringskampanje Nettsteder for markedsføringskampanjer ligner på nettsteder for merkevaretilstedeværelse, siden begge er fokusert på å engasjere brukere med en opplevelse som påvirker deres oppfatning av selskapets merkevare. Markedsføringskampanjesider har imidlertid en tendens til å bli evaluert på deres evne til å oppnå svært spesifikke handlinger innenfor et bestemt fokus (for eksempel innenfor en bestemt tidsramme eller med et målrettet publikum). I stedet for å tjene som en trakt for å kanalisere interesse, er de ment å være motorene som genererer interesse. Fra et online ståsted betyr dette generelt at de er på linje med en overordnet markedsføringsstrategi og kan kjøres i forbindelse med andre markedsføringstiltak ved bruk av forskjellige kanaler, for eksempel TV- eller radioreklamer, trykte annonser og andre kampanjer.

Vanlige markedsføringskampanjesider En landingsside som promoterer et spesifikt tilbud. Siden nås via a

bannerannonse fra en annen side. Et lite nettsted (eller mikronettsted) som promoterer en bestemt begivenhet. Et spill eller verktøy som er laget med det formål å generere buzz

eller trafikk.

Hovedformålet med et nettsted for markedsføringskampanjer er å lage en smalt fokusert kampanje som vanligvis er målrettet mot et spesifikt sett med beregninger. Fokuset begrenses ofte av ett eller flere av følgende: Tid – for eksempel en kampanje sentrert rundt en hendelse (som f.eks.

konferanse) eller en sesong (for eksempel julehandelsesongen) Brukergruppe – for eksempel en kampanje målrettet mot tenåringer eller lærere Produkt, produktpakke og/eller en spesifikk bruk for det produktet – for

for eksempel et nettsted som fremhever kjøkkenutstyr ved å vise virtuelle kjøkken med matchende ovner, oppvaskmaskiner og komfyrer

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

En kampanje som bruker en blanding av disse strategiene vil være en vårkampanje rettet mot salg av terrasseutstyr, som kombinerer tid og produktpakke. Se figur 2.1 for et eksempel som viser en blanding av produktpakke og brukergruppe. Et nettsted for markedsføringskampanjer kan være så enkelt som en bannerannonse som fører til en destinasjonsside på selskapets .com-nettsted, eller det kan være et mikronettsted, et lite nettsted som ofte vender bort fra merkevarebyggingen som er synlig på .com-nettstedet for å gi en skreddersydd opplevelse etter ett eller flere av satsingsområdene. "Liten" er relativt her – noen mikronettsteder er bare én side og andre har mange, men uansett er mikronettstedet mindre og mer fokusert enn selskapets hovednettsted for merkevaretilstedeværelse.

Figur 2.1 Texas Instruments bruker dette utdanningsfokuserte mikronettstedet, http://timathrocks.com/index.php, for å presentere informasjon om selskapets grafiske kalkulatorer. Produktpakken brukes først og fremst av elever på videregående skoler og høyskoler i algebraklasser. Mikronettstedet opprettholder generelle bånd til merkevaren Texas Instruments, men er med vilje distinkt for å tiltrekke seg et yngre publikum og organisere innhold og funksjoner i henhold til deres behov.

Designmål for markedsføringskampanjer For personen eller teamet som er ansvarlig for å designe og implementere en markedsføringskampanjeside, er designmålene som ofte er av størst betydning disse: Generer interesse og spenning, ofte ved å presentere en klar og umiddelbar

verdiforslag (verdien som et produkt eller en tjeneste tilfører brukeren, for eksempel muligheten for kvalifisering av hurtiglån) eller et slags insentiv (et spesialtilbud, deltakelse i en konkurranse eller underholdning som et nettspill).

IDENTIFISERE TYPE NETTSTED

Engasjere et sett med primære brukergrupper for å ulovliggjøre en bestemt handling,

som å klikke seg videre til et spesifikt sted på et nettsted for merkevaretilstedeværelse, registrere deg for et nyhetsbrev eller søke om lån. Når denne handlingen utføres av en bruker, kalles den en konvertering. Hjelpe selskapet med å nå mål som settes opp mot nøkkelberegninger, som tall-

en rekke unike besøkende. Ofte er dette en del av en overordnet markedsføringsstrategi.

Deep Diving For mer om utforming av sider for å støtte markedsføringskampanjer, se Landing Page Optimization: The Definitive Guide for Testing and Tuning for Conversion, av Tim Ash (Sybex, 2008).

Innholdskilde En innholdskildeside inneholder et lager av informasjon, potensielt i flere typer medier (artikler, dokumenter, video, bilder, opplæringsprogrammer), og er ment å informere, engasjere og/eller underholde brukere.

Vanlige innholdskilder Et firmas intranett Et nettbibliotek eller ressurssenter for medlemmer av en organisasjon Nettsteder eller områder av nettsteder som er fokusert på å levere nyheter eller ofte

oppdaterte innlegg (store kommersielle blogger kan falle inn i denne kategorien) Kundestøttesentre

Alle nettsteder og applikasjoner har selvfølgelig noe innhold, men noen nettsteder legger spesiell vekt på presentasjonen og strukturen til innholdet. Vekten kan komme fordi nettstedet har så mye innhold at det utgjør sin egen utfordring eller fordi spesifikke typer innhold har en høy grad av betydning; de kan for eksempel støtte kritiske beslutninger eller trekke brukere tilbake til nettstedet ofte.

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

Hovedformålet med et innholdskildenettsted er å øke brukerkunnskapen og selvforsyningen ved å tilby relevant innhold (for eksempel et intranett). De oppfordrer ofte også til en slags handling, for eksempel å dele informasjon eller kjøpe et produkt etter å ha gjennomgått beskrivelsen. Innholdskildedesignmål Et innholdskildenettsted må ofte gjøre ett eller flere av følgende: Presentere innhold som er hovedtrekket for første og gjentatte besøk til nettstedet. Demonstrere et selskaps evne til tankelederskap, for eksempel

ved å gi tilgang til ideer og perspektiver inneholdt av administrerende direktør eller andre fageksperter i selskapet. Støtt kritiske beslutninger blant brukerbasen. Øk bedriftens bedriftskunnskap ved å få frem ideer som

kan begraves innenfor enkelte avdelinger. Dette kan være en del av et større mål om å identifisere flere muligheter for innovasjon. Støtt brukere som søker informasjon på forskjellige måter. For eksempel,

noen vet ikke hvilket spesifikt produkt de trenger ennå (og er mer sannsynlig å bla), mens andre kanskje vet nøyaktig hva de leter etter (og er mer sannsynlig å bruke et søkefelt).

Surfing For mer informasjon om de forskjellige måtene brukere har en tendens til å søke informasjon på, les «Four Modes of Seeking Information and How to Design for Them» av Donna Spencer: http://boxesandarrows.com/view/four_modes_of_seeking_ information_and_how_to_design_for_them

Når det gjelder UX-design, er noen av oppgavene som er mest vanlige i et innholdskildeprosjekt: Lage en kategoriseringsstruktur som passer til brukernes mentale modeller. Bestemme hvordan man skal inkorporere et system for organisk vekst av innhold

(for eksempel funksjoner som merking og ﬁltrering) Utforme et effektivt søkeverktøy IDENTIFISERE TYPE NETTSTED

Oppgavebaserte applikasjoner Oppgavebaserte applikasjoner kan variere fra en enkel kalkulator innebygd i et boliglånsområde til et komplett system som håndterer flere kritiske arbeidsflyter. Hvis prosjektet ditt involverer sistnevnte, vil det være flere roller involvert og, mest sannsynlig, en betydelig kravinnsamlingsprosess (for mer om denne prosessen, se kapittel 5).

Vanlige oppgavebaserte applikasjoner En programvareapplikasjon som støtter oppretting av en bestemt type

element (som et regneark eller et utskriftsstykke) Et nettverktøy eller applikasjon som støtter en kritisk arbeidsflyt i en kom-

selskap (som en billettadministrasjonsapplikasjon for en IT-støttegruppe eller en kundesporingsapplikasjon for et kundesenter) Et nettsted som gir tilgang til og administrasjon av personopplysninger

(som Flickr)

Hovedmålet med en oppgavebasert applikasjon er å tillate brukere å utføre et sett med oppgaver som er på linje med deres behov og, til syvende og sist, med kundens forretningsmål. Oppgavebaserte applikasjonsdesignmål De fleste oppgavebaserte applikasjoner må gjøre det mulig for brukere å gjøre noe de ikke kunne gjøre andre steder – eller hvis de kan,

å gjøre det bedre («bedre» kan bety mer effektivt, mer effektivt, med en høyere grad av tilfredshet, eller mer praktisk) Støtt nybegynnere med lett tilgjengelige instruksjoner og visuelle prioriteringer

sering av nøkkeloppgaver Støtt middels og avanserte brukere med tilgang til snarveisfunksjoner

og dypere funksjonalitet Reduser belastningen på brukeren og utnytte systemressursene best mulig

(for eksempel gjenbruk av data versus å kreve dupliserte oppføringer)

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

Bli utformet og distribuert med oppmerksomhet til graden av endring som kreves

av applikasjonens brukere – ideelt sett med et design som letter læring og en kommunikasjonsplan som viser verdien for brukeren. En av de største utfordringene med å designe en oppgavebasert applikasjon er å holde "funksjonskryp" under kontroll. Når et prosjekt utvikles, er det veldig vanlig at gode ideer dukker opp på senere stadier av designet, eller til og med under utvikling. Brukeropplevelsesdesign er godt egnet til å beskytte mot funksjonskryp fordi brukermodeller som personas kan brukes til å identifisere funksjoner med høy verdi og for å holde fokus gjennom hele prosjektet. Hvis en virkelig god idé dukker opp senere i prosessen, og den oppfyller behovene til en høyprioritert brukergruppe, og den er i tråd med forretningsmålene til nettstedet, kan teamet ditt være i stand til å bygge en sak for å endre retning. Hvis en idé ikke kommer seg gjennom den vrien, er den kanskje ikke verdt forsinkelsen og kostnadene.

E-handelsnettsteder E-handelsnettsteder kan inneholde elementer fra alle fire prosjekttyper, fordi et nettsted som primært er beregnet på e-handel, må ha sin egen merkevaretilstedeværelse, gi innhold (vanligvis produktspesifikasjoner eller beskrivelser av produktbruk), og legge til rette for oppgaver (søke, sammenligne, skrive anmeldelser, kasse). Markedsføringskampanjer er ofte også nært knyttet til disse nettstedene og kan involvere flere markedsføringsgrupper i organisasjonen. Vanlige ekstra designmål for e-handelssider er Forklar modellen for nettstedet, hvis det ikke er standard. Som online markedsplasser

blir stadig gjenskapt, vil denne forklaringen bidra til å sette forventninger (for eksempel eBay, Amazon og Craigslist har svært forskjellige modeller). Støtt beslutningstaking når brukeren går fra læring til å vurdere-

sammenligning med kjøp, med nyttig innhold og funksjoner. Benytt deg av punkter i opplevelsen hvor kryss- og mersalg er

mulig, og plasser disse forslagene på en måte som er iøynefallende uten å være forstyrrende. Lag en kommunikasjonsflyt fra kjøpsstedet gjennom

leveringssted. Kommunikasjon må skje ikke bare innenfor nettstedet, men også med andre kanaler, for eksempel integrasjon med leveringssporingssystemer og e-postkommunikasjon om ordrestatus. IDENTIFISERE TYPE NETTSTED

E-læringsapplikasjoner E-læringsapplikasjoner er kryssinger mellom en innholdskilde og en oppgavebasert applikasjon. Innhold for leksjoner må genereres, noe som ofte krever at teamet legger til rollene som læringsspesialist og fagekspert (SME) for emnet som dekkes. Produktet er oppgavebasert ved at brukeren vanligvis følger en flyt gjennom leksjonen og kan også trenge å spore fremgang eller utforske relaterte emner. Noen praktiske leksjoner kan også kreve at oppgaver fullføres. Vanlige designmål er Sett en forståelse av den grunnleggende kunnskapen som trengs for å starte et kurs

og hvem det er rettet mot. Gi innhold i håndterbare biter som er tempoet for

forståelse. Engasjer eleven i aktiviteter som simulerer praktisk læring. Kommuniser ytelse og fremgang og, hvis aktuelt, foreslå

neste trinn for å fortsette utdanningsprosessen, for eksempel mer avanserte kurs.

Sosiale nettverksapplikasjoner En sosial nettverksapplikasjon er først og fremst en oppgavebasert applikasjon, fordi brukere må kunne finne og legge til venner, administrere profilen deres, koble til, legge ut og søke. De inneholder også utfordringer knyttet til innholdskilder, men spesielt behovet for et organisk rammeverk som kan håndtere en potensielt svært stor mengde brukergenerert innhold. Hvis nettstedet i hovedsak gis sin egen identitet, vil det også ha egenskapene til et nettsted for merkevaretilstedeværelse.

Snorkling Hvis du jobber med et sosialt nettverksprogram eller prøver å integrere sosiale funksjoner i en annen type nettsted, vil denne boken hjelpe deg på vei: Designing for the Social Web, av Joshua Porter (New Riders, 2008).

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

Vanlige designmål for sosiale nettverksapplikasjoner er Fokuser potensielle brukere på formålet og verdiene til nettverket. Legg til rette for meningsfulle interaksjoner mellom brukere som støtter og er

støttet av funksjonene som presenteres (som bildedeling, videodeling og diskusjoner). Beskytt nettstedets integritet ved å sikre at de innenfor nettverket under-

forstå hvordan de skal kontrollere informasjonen deres og reagere på upassende oppførsel. Utnytt og vis fellesskapets kraft for å bringe frem fea-

turer som bare er mulig med aktive medlemmer, for eksempel populære funksjoner og anmeldelser. Å identifisere typen nettsted eller applikasjon du kanskje jobber med i løpet av et prosjekt er bare det første trinnet. Deretter bør du vurdere de forskjellige rollene som ofte er nødvendig og hvordan deres involvering kan variere basert på type prosjekt.

Velg hattene dine Når du blir UX-designer på et prosjekt, ender du ofte opp med å spille flere roller. Enten de er formelt definert i din kundeorganisasjon eller ikke, avhenger rollene du vil spille av typen prosjekt og sammensetningen til resten av teamet, samt en klients erfaring med hver. Det er godt å vite hvilke roller du allerede er komfortabel med å ta på deg og hvilke du tror du kan lære på jobben. Det er også nyttig å finne ut hvilke forventninger andre kan ha til ansvaret som dekkes av disse rollene. Med denne forståelsen kan du representere deg selv tydeligere fra begynnelsen av prosjektet. Hva er de vanligste rollene som forventes av en UX-designer? Hvert kundeselskap du jobber for kan ha forskjellige titler for disse rollene (eller ikke noe navn i det hele tatt, hvis det ikke er en formell jobb i organisasjonen). Generelt kan du forvente å møte de tre store: informasjonsarkitekt, interaksjonsdesigner og brukerforsker. Merk Få selskaper har størrelsen eller budsjettet til å dele disse vanlige rollene mellom ulike individer. Ha rollenavnene i tankene dine når du definerer et prosjekt, men snakk om behov og ansvar når du snakker med kunden – ellers kan de tro at du bygger et veldig stort team! Dette fokuset på ansvar i stedet for titler vil også bidra til å holde deg tilregnelig: Hvis du utfører flere av disse rollene, betyr det ikke nødvendigvis at du gjør jobben til mange mennesker, fordi ansvar ebber og flyter gjennom ulike deler av prosjekt.

VELG DINE HATER

Informasjonsarkitekt En informasjonsarkitekt er ansvarlig for å lage modeller for informasjonsstruktur og bruke dem til å designe brukervennlig navigasjon og innholdskategorisering. Under utformingen av nettsteder og applikasjoner inkluderer felles ansvar å lage detaljerte nettstedskart (diskutert i kapittel 10) og å sikre at kategorier og underkategorier av informasjon er distinkte og brukervennlige. Forstå forventninger Innenfor UX-feltet skilles det mellom rollene til informasjonsarkitekten og interaksjonsdesigneren (diskutert neste). Hos en bestemt bedrift er det imidlertid sjelden et felles skille mellom de to rollene, i hvert fall når det gjelder hva som oppgis som behov for et bestemt prosjekt. For eksempel kan du ende opp i et team med tittelen informasjonsarkitekt fordi det er den historiske betegnelsen for rollen, uansett om det virkelig passer dine ansvarsområder eller ikke. Bør du korrigere prosjektteamet hvis tittelen du får ikke samsvarer med hovedrollen du tar på deg? Hvis dette er et kortsiktig prosjekt (f.eks. fire måneder eller mindre) og tittelen du har er allment akseptert i organisasjonen, med klare ansvarsområder skissert, er det kanskje ikke verdt den potensielle forvirringen du vil introdusere for å prøve å endre den . Hvis det imidlertid ikke er noen allment akseptert tittel, og du tror det er en sjanse for at du trenger begge rollene for å bli representert – potensielt av forskjellige personer – så er det verdt å skille tidlig i prosjektet når du planlegger involvering og kommunikasjon ditt ansvar. I hovedsak, for mer oppgavebaserte applikasjoner er det fornuftig å understreke rollen som interaksjonsdesigner, og for mer innholdsbaserte prosjekter er det fornuftig å understreke rollen som informasjonsarkitekt. Men det som kanskje gir mest mening av alt, er å bruke begrepet som er kjent for kundeorganisasjonen og sikre at teamet forstår hvordan du definerer rollen med hensyn til ansvaret du tar på deg. Denne definisjonen er noe du vil gjøre klart i arbeidsoppgaven (se kapittel 3). Ansvaret til en informasjonsarkitekt kan også utviskes med det som en innholdsstrateg har (se nedenfor, under "Andre roller"). Hvis disse rollene er

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

representert av forskjellige personer i prosjektteamet, sørg for å diskutere hvordan du vil samarbeide i begynnelsen av prosjektet.

Interaksjonsdesigner En interaksjonsdesigner er ansvarlig for å definere atferden til et nettsted eller en applikasjon i samsvar med brukerhandlinger. Dette inkluderer flyter på nettstedet på tvers av flere visninger og interaktivitet i en bestemt visning. Under utformingen av nettsteder eller applikasjoner er vanlige aktiviteter å lage oppgaveflyter som viser interaksjon på tvers av sider eller komponenter på nettstedet (se kapittel 10) og å lage wireframes som viser interaksjoner på siden som dynamiske menyer og utvidbare innholdsområder (se kapittel 11). Forstå forventninger Hvis du jobber i et lite team eller på et prosjekt som ikke er sterkt fokusert på å skape ny oppgavebasert funksjonalitet (hvis du for eksempel jobber med et nettsted for merkevaretilstedeværelse som hovedsakelig inkluderer enkelte innholdskategorier, en kontaktskjema, og et påmeldingsskjema for et nyhetsbrev) kan interaksjonsdesigner være hovedrollen som er ansvarlig for å fange opp prosjektkravene (se kapittel 5). Hvis du jobber som interaksjonsdesigner på et prosjekt med et høyt nivå av ny funksjonalitet, vil du mest sannsynlig ha en egen person på teamet som er ansvarlig for å skissere detaljerte krav (for eksempel en forretningsanalytiker eller produktsjef). Prosessen med å samle og detaljere funksjonelle krav kan hjelpes i stor grad av ferdighetene til en UX-designer, og dokumenter som funksjonelle spesifikasjoner og brukstilfeller påvirkes av opplevelsesdesign. Sørg for å sette deg ned med personen som er ansvarlig for å samle krav for å diskutere hvordan dere best kan samarbeide.

Brukerforsker En brukerforsker er ansvarlig for å gi innsikt angående behovene til sluttbrukere, basert på informasjon som er generert fra, eller validert med, forskningen vedkommende utfører med brukere. Det er mange typer aktiviteter som kan falle inn under kategorien brukerforskning, og de kan forekomme på flere punkter i prosjektets tidslinje. (Se kapittel 6 for en beskrivelse av vanlige teknikker, som brukerintervjuer, undersøkelser og brukervennlighetstesting.)

VELG DINE HATER

Forstå forventninger Kundebedriftens appetitt på brukerundersøkelser kan variere enormt, basert på hvor viktig det er lagt på det av prosjektteamet eller prosjektsponsoren. Det faktum at du snakker med en prosjektsponsor om UX-design før et prosjekt starter viser at noen i kundeteamet vet at det er en prioritet å sikre at brukernes behov er representert. Men som de som har jobbet med sin del av databaserte prosjekter vet, kan introduksjon av forskning også introdusere angst blant prosjektteammedlemmer – utløst av bekymring for at brukerforskning vil skape en flaskehals, øke risikoen (Hva om vi finner noe galt og trenger å gjøre store endringer for å fikse det?), eller motbevise verdien av en bestemt idé som har fått mye fart. Forventningene til brukerforskning kan variere mellom virksomhetens interessenter og prosjektteamet, så sørg for å avklare forventninger til rollen med begge grupper. Klienten kan også forvente at brukerforskeren gir innsikt basert på nettstedsanalyse – verktøy og rapporter som kommuniserer bruksmønstre på nettstedet, for eksempel ofte besøkte sider og vanlige punkter der brukere forlater nettstedet. Noen av de vanligste analyseverktøyene er fra Google (www. google.com/analytics), WebTrends (www.webtrends.com) og Omniture (www.omniture.com/en/products/web_analytics). Du kan finne deg selv i å påta deg alle disse tre rollene: informasjonsarkitekt, interaksjonsdesigner og brukerforsker. Kan du balansere alle tre, eller biter du mer enn du kan tygge? Det avhenger delvis av størrelsen og tidslinjen til prosjektet, men typen prosjekt har også innvirkning på hvor mye involvering hver rolle sannsynligvis vil ha. Tabell 2.1 beskriver hvordan UX-designroller kan variere etter prosjekttype.

Surfing Trenger du å lage etui for UX-design? Disse artiklene tilbyr tilnærminger som kan hjelpe: "User Experience as Corporate Imperative," av Mir Haynes: www.hesketh.com/publications/user_experience.pdf "Evangelizing User Experience Design on Ten Dollars a Day," av Louis Rosenfeld: http:/ /louisrosenfeld.com/home/bloug_archive/000131.html

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

TABELL 2.1

Felles ansvar for UX-designrollen

Informasjonsarkitekt

MERKE-NÆRVAR

MARKEDS KAMPANJE

INNHOLDSKILDE

OPPGAVEBASERT APPLIKASJON

Middels engasjement.

Lavt engasjement for mindre nettsteder (som én enkelt landingsside). Middels engasjement hvis du arbeider med større mikronettsteder.

Meget høyt engasjement. Innholdskilder krever en informasjonsarkitektur som har en passende balanse mellom struktur og ﬂeksibilitet, for å gi brukerne en solid base å stå på og tillate planlagt vekst.

Middels til høyt engasjement, hovedsakelig fokusert på å lage navigasjonsrammeverket, med mindre det er større innholdsområder som må refereres under noen arbeidsflyter.

Lav involvering for mindre nettsteder, middels til høy involvering for større mikronettsteder eller advergames (sponsede nettspill ment å generere spill og buzz).

Middels til høyt engasjement.

Meget høyt engasjement. Denne typen prosjekt krever ofte de tyngste løft, ettersom interaksjonsdesignleveranser (som brukerprosessflyter og wireframes) er nøkkelen til å kommunisere krav visuelt.

På grunn av den ofte midlertidige karakteren til kampanjer, er brukerinvolvering ofte lett. Mer permanente løsninger kan bruke forskning som ligner på nettsteder for merkevaretilstedeværelse. Det er også vanlig å bruke analyseverktøy for å presentere to eller flere varianter av en bestemt side for å se hvilken som fører til flest konverteringer. Dette kalles A/B-testing.

Feltundersøkelser som kontekstuelle undersøkelser kan hjelpe teamet til å forstå hvordan ulike brukere for tiden jobber med informasjon.

Jo større innholdsutfordringen er, jo mer lik en innholdskilde vil prosjektet bli.

Interaksjonsdesign

Middels engasjement. Jo flere oppgaver, jo mer likt en oppgavebasert applikasjon vil prosjektet bli.

User Researcher involvering vil variere basert på budsjett og tilgang til brukere. Oppført her er vanlige teknikker for hver prosjekttype. For mer om hver av disse teknikkene, se kapittel 6.

Forskningsinnsats kan fokusere på å forstå behovene til prioriterte brukergrupper (gjennom undersøkelser eller intervjuer) eller designforskning som tester effektiviteten til et bestemt visuelt design for å formidle riktig merkevarebudskap.

Søke-, tagging- og ﬁltreringsfunksjoner krysser grensen mellom informasjonsarkitektur og interaksjonsdesign. Innholdskilder kan også ha arbeidsflyter som involverer innholdsskaping og -administrasjon.

Kortsortering er en utmerket måte å forstå hvordan brukerne dine kan gruppere informasjon og vanlige mønstre og mentale modeller.

Feltundersøkelser som kontekstuelle undersøkelser kan gjøres for å forstå oppgaver ettersom brukere fullfører dem. Den mest brukte og best forståtte teknikken for å involvere brukere i utformingen av en oppgavebasert applikasjon, er imidlertid brukervennlighetstesting.

Når et rammeverk er satt, kan brukervennlighetstesting validere strukturen.

VELG DINE HATER

Andre roller du kan spille eller trenger Flere roller faller vanligvis ikke inn under rollen som UX-designer, men deres ansvar overlapper ofte med UX-designrollen – spesielt hvis du jobber med et prosjekt der ingen offisielt spiller rollen og du har ferdigheter å bringe til bordet. Noen av de mer vanlige overlappende rollene inkluderer: merkevarestrateg eller steward Forretningsanalytiker Innholdsstrateg Copywriter Visuell designer Front-end-utvikler

De følgende delene ser på hver av disse rollene mer detaljert og diskuterer hvordan de kan variere avhengig av typen nettsted som utformes. Merkestrateg og merkevareansvarlig En merkevarestrateg er ansvarlig for å bygge et forhold til nøkkelmarkeder gjennom definisjon og konsistent representasjon av selskapets merkevareelementer, som kan omfatte alt fra merkeverdier (som «responsivitet») til retningslinjer for kopiering og meldinger til spesifikasjoner for logobehandlinger, farger og layout. Denne rollen innebærer ofte å lage eller representere retningslinjer for merkevarebygging og å forstå hvordan de gjelder for ulike prosjekter. Det kan også innebære å kjenne eller definere målgruppene som er viktige for prosjektet du jobber med. For det meste vil du sannsynligvis jobbe med en merkevarestrateg, men vil ikke ta ansvaret på deg selv. Merkevareforvalteren setter ikke nødvendigvis retningslinjene, men er ansvarlig for å sikre at de følges på riktig måte under prosjektet. Dette ansvaret kan gis til UX-designeren eller visuell designer på et prosjekt. Hvis selskapets merkeegenskaper, verdier og retningslinjer allerede er godt definert og nettstedet forventes å følge dem, vil din rolle som prosjektets merkevareansvarlig hovedsakelig være å sikre at resultatet er i tråd med disse retningslinjene. Berøringspunktet ditt utenfor prosjektet vil mest sannsynlig være et

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

medlem av markedsavdelingen som er tilgjengelig på konsultasjons- eller gjennomgangsbasis, men som ikke er på teamet på heltid. Rollen som merkevareansvarlig kan være mer aktiv hvis nettstedet er ment å utvide merkevaren på en eller annen måte – for eksempel rettet mot et nytt marked. Det er mest involvert når en helt ny merkevaretilstedeværelse skapes eller når selskapet gjør en dramatisk endring i merkevaren sin, og rebrander seg selv. For eksempel endret CellularOne seg fullstendig til å bli Cingular, en stor innsats for et etablert selskap. I den situasjonen bør du enten være svært erfaren innen merkevareutvikling eller etablere et tydelig og nært forhold til personen i bedriften som er det. Nøkkelspørsmål som vil hjelpe deg å forstå forventningene rundt en merkerelatert rolle er disse: Finnes det allerede retningslinjer for merkevare? I så fall, hvor tett må de følges for dette prosjektet? Hvem er ansvarlig for å sette eller vedlikeholde merkevaremeldinger, merkevare

utseende og tone i innholdet (for eksempel uformell eller profesjonell)? Vil nye målgrupper bli målrettet som ikke dekkes av tidligere

merkevaredefinisjoner? Hvis ja, hvem er ansvarlig for å sikre at merkevareretningslinjene fortsatt er passende for disse målgruppene? Vil det være navne- eller omdøpningsaktiviteter? I så fall, hvordan bør jeg planlegge å være

involvert? (Et eksempel kan være å lage et navn for et nytt verktøy som vil bli kraftig promotert.) For prosjekter som ikke har en stor potensiell innvirkning på kundenes oppfatning av merkevaren, for eksempel utvikling av en intern applikasjon, involvering av merkevareansvarlig kan være like lett som en sporadisk innsjekking for å sikre at merket blir godt representert. Forretningsanalytiker En forretningsanalytiker (noen ganger referert til som en forretningssystemanalytiker på IT-prosjekter) er ansvarlig for å identifisere sentrale forretningsinteressenter, drive kravinnsamlingsprosessen (se kapittel 5), og fungere som det primære bindeledd mellom forretningsinteressenter og teknologien team. Han eller hun er også hovedeier av detaljert kravdokumentasjon, for eksempel funksjonsspesifikasjoner og brukstilfeller, om nødvendig.

VELG DINE HATER

Rollen som forretningsanalytiker eller produktsjef eksisterer kanskje ikke på prosjektet ditt i det hele tatt, eller det kan være en av de viktigste rollene gjennom designprosessen. Oppgavebaserte applikasjoner og innholdskilder har ofte denne typen rolle; merkevaretilstedeværelsesprosjekter og markedsføringskampanjer kanskje ikke. En oppgavebasert applikasjon vil mest sannsynlig trenge denne rollen. Jo flere funksjoner og jo større kompleksitet prosjektet har, desto større behov vil det være for en dedikert person og for dokumentasjon av funksjonalitet. Selv om en forretningsanalytiker vanligvis ikke anses som et medlem av UX-teamet, blir små UX-team ofte bedt om å fylle rollen, så det er viktig å forstå hvor dette ansvaret ligger. Forretningsanalytikere driver innhenting av forretningskrav, og fungerer som bindeleddet mellom teknologiteamet og de viktigste forretningsinteressentene. Hvis det er en forretningsanalytiker på et prosjekt, blir denne personen og interaksjonsdesigneren ofte slått sammen på hoften. Hvis det er samme rolle, kan den ansvarlige ha mye dokumentasjon å holde tritt med! For å forstå forventningene på dette området, spør hvem som skal være ansvarlig for å skissere omfanget av prosjektet, lette diskusjonene rundt krav og dokumentere krav gjennom hele prosjektet. For små prosjekter eller de som ikke er tunge i funksjonalitet, vil prosjektlederen noen ganger ta på seg dette ansvaret. Uansett, hvis det ikke er deg, vil du fortsatt vite hvem du trenger å holde deg i nærheten av for å sikre at leveransene dine er synkronisert. Innholdsstrateg En innholdsstrateg er ansvarlig for å forstå forretnings- og brukerkrav til innhold i ulike medier (artikler, dokumenter, bilder og video), identifisere hull i eksisterende innhold, og legge til rette for arbeidsflyt og utvikling av nytt innhold. Innholdsrelatert innsats blir ofte undervurdert. En klient kan ha en stor mengde innhold som er fantastisk i ett medium (for eksempel trykte brosjyrer eller videoer), men det kan hende at innholdet ikke passer for prosjektet du jobber med. Noen ganger er det også uuttalte forventninger om at folk i kundeorganisasjonen vil generere innhold – forventninger som kan komme som en overraskelse for disse menneskene når tiden er inne for å fylle produktet med beskrivelser, nyheter og hjelpeemner! Hvis innhold av høy kvalitet er en

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

viktig forretningsdriver i prosjektet ditt, sørg for at du vet hvem som er ansvarlig for følgende: Sette retningslinjer for innhold for det nye produktet (type innhold,

tone, mengde). Vurdere hensiktsmessigheten av eksisterende innhold i forhold til disse

retningslinjer. Utvikle nytt innhold. Dette vil variere basert på generell prosjekttype. Til

oppgavebaserte applikasjoner, kan det inkludere instruksjonskopi, feilmeldinger og hjelpeemner. For innholdskilder kan det inkludere artikler, nyheter og blogginnlegg. Fungerer som forbindelsen mellom interessenter og teknisk team for å kommunisere

innholdsstyringssystemets begrensninger og muligheter. Deﬁnere ulike innholdstyper så vel som hver enkelts metadata (den

informasjon som til slutt gjør søk og kryssreferanser mer effektivt). Planlegging for migrering av innhold, som innebærer å lage maler

for ulike innholdstyper og sørge for at innhold er merket og lastet inn på riktig måte når det flyttes inn i nettstedets innholdsstyringssystem. (Dette er et annet område hvor innsatsen som kreves ofte blir undervurdert.) Tekstforfatter En tekstforfatter er ansvarlig for å skrive teksten på nettstedet som rammer inn helhetsopplevelsen. I noen tilfeller forblir denne kopien ganske uendret fra dag til dag. Det inkluderer vanligvis nettsted- og sideintroduksjoner eller instruksjoner på siden. En tekstforfatter kan også være involvert i den pågående opprettelsen av dynamisk innhold, for eksempel nyhetsartikler eller kopi for markedsføringskampanjer. Copywriting er en av de gråsonene som ofte faller for en UX-designer, spesielt hvis wireframes blir opprettet (se kapittel 11). Du kan til å begynne med sette inn eksempeltekst for å tjene som plassholder for kopi, for eksempel en områdebeskrivelse eller instruksjoner på siden, men noen må til slutt fylle den med den endelige teksten som vil bli sett av brukerne – og fordi mange prosjekter ikke har en dedikert tekstforfatter, kan denne oppgaven være standard for deg. Det er mindre sannsynlig at du blir bedt om å ta på deg rollen som tekstforfatter for høyprofilerte områder av nettsteder for merkevaretilstedeværelse eller markedsføringskampanjer; i de situasjonene

VELG DINE HATER

hvert ord kan granskes nøye. Men hvis du jobber med et oppgavebasert program som trenger korte instruksjonsmeldinger, feilmeldinger eller andre typer informasjon som ikke nødvendigvis faller inn i en oversiktlig innholdsbøtte, kan du ende opp med å arve den skriveoppgaven (eller det vil faller til utvikleren som standard). Spør på forhånd om en tekstforfatter vil være tilgjengelig, og spør igjen når du wireframing hvis en ikke er funnet. Hvis jobben faller på deg, sørg for å inkludere den innsatsen når du planlegger aktivitetene dine under prosjektet. Og vær oppmerksom: Dette er et ansvar som ofte blir utelatt eller undervurdert. Visuell designer En visuell designer er ansvarlig for elementene på nettstedet eller applikasjonen som brukeren ser. Denne innsatsen inkluderer å designe et utseende og en følelse som skaper en følelsesmessig forbindelse med brukeren som er i tråd med merkevareretningslinjene. For eksempel må en bankside ofte fremstå som stabil, pålitelig og tilgjengelig. Det visuelle designet kan gi denne sikkerheten gjennom visuelle elementer som farger og bilder. Dette løftet vil da bli holdt (eller brutt) av interaksjonsdesignet til nettstedet og andre kontaktpunkter med selskapet (for eksempel et kundesenter). La oss være ærlige: Mange mennesker der ute kaller seg visuelle designere, webdesignere eller grafiske designere, og mange nettsteder har dårlige eller bare akseptable visuelle design. Det er en stor forskjell mellom å skape en effektiv, oppslukende og emosjonell visuell design og å bare klare seg. Noen ganger er det nok å klare seg for å nå prosjektmålene, og noen ganger fører det til prosjektfrustrasjoner og forsinkelser når prosjektsponsoren er misfornøyd, eller tidlige brukere ikke er engasjert i designet. På den annen side kan det også være lett å fokusere for sterkt på å skape effekt med det visuelle designet, slik at brukervennligheten til designet blir dårligere. Hvis du blir bedt om å ta på deg denne rollen og er usikker på dine evner til å skape den rette innvirkningen for kunden, ta en titt på selskapets nåværende nettsted og nettstedene eller produktene kundene beundrer fra et visuelt ståsted for å vurdere komforten din nivå. Visuelle designere tar ofte en veldig sentral rolle i prosjekter for merkevaretilstedeværelse og markedsføringskampanjer, og har hovedrollen ansvarlig for å kommunisere selskapets merkevare effektivt.

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

For innholdskildeprosjekter kan de fokusere på å lage innholdsmaler som kan brukes på mange sider (for eksempel en mal for en artikkel). For oppgavebaserte applikasjoner kan de gi en stilguide som kan brukes på vanlige interaksjonselementer, for eksempel navigasjonsområder og verktøy (noe som krever en høy grad av samarbeid med interaksjonsdesigneren). Front-end-utvikler En front-end-utvikler er ansvarlig for å bygge den tekniske strukturen bak sidedesignene og -flytene, så vel som interaktive elementer på nettstedet, for eksempel overrullingsmenyer, utvidbare innholdsområder, interaksjoner med multimedieelementer som video. Dette arbeidet bruker ofte teknologier som XHTML, CSS, Flash, JavaScript, Ajax og Silverlight. Frontend-utvikling fokuserer på elementene på nettstedet som knytter seg direkte til det brukeren ser, i motsetning til systemene på baksiden som gir den underliggende plattformen (som databaser, innholdsstyringssystemer og koden som trengs for å bygge funksjonalitet bak komplekse funksjoner). Hvis du eller medlemmer av teamet ditt tar på deg rollen som front-end-utvikler, er nært samarbeid med resten av utviklingsteamet viktig for å forstå forventninger og ansvar. Andre viktige spørsmål inkluderer hvilke back-end-systemer som må integreres med, metoden som brukes for å generere HTML, behovet for ﬂeksibilitet i sidestrukturen for å imøtekomme tilpassede "skins" og forventningene til teknologier som Flash. Hvis en prototype planlegges (se kapittel 12), spør hvem som er ansvarlig for å utvikle prototypen og hvilket funksjonsnivå som forventes. En prototype som er ment å enkelt kommunisere muligheter kan opprettes raskt i en applikasjon som Flash, men en fullt fungerende prototype som trenger å trekke reelle data (for eksempel kontoinformasjonen en bruker nettopp skrev inn i et skjema) må gjøres på nært hold. samarbeid med medlemmer av back-end utviklingsteamet. Bekymret for å ta på seg alle disse rollene? Med mindre du jobber med et veldig lite prosjekt - eller i et veldig lite selskap - vil du sannsynligvis ikke ta alt på deg selv. Nøkkelen er å forstå hvilke av rollene du er i stand til og villig til å ta på deg, etter behov, for det bestemte prosjektet du jobber med. For resten kan du få støtten du trenger i prosjektteamet ved å bygge et nettverk i kundebedriften eller ved å anbefale flere personer for å dekke behovene. La oss ta et øyeblikk til å snakke om måter du kan gjøre dette på.

VELG DINE HATER

Bygge et nettverk av brukerstøtte For de områdene du ikke er sikker på om du kan eller ønsker å ta på deg, er det på tide å begynne å lete etter hjelp. Det er tre hovedmåter du kan gå frem for å gjøre dette: Anbefal at flere teammedlemmer legges til hvis behovet er

tydelig nok. Utdan deg selv på nøkkelområder der det er hull – hvis det nye ansvaret

egenskaper er håndterbare og du har tid til å dedikere til dem. Bygg et støttenettverk i selskapet for å hjelpe deg på viktige tidspunkter.

La oss se nærmere på hvordan du kan bygge et støttenettverk. Det er mest sannsynlig noen nøkkelressurser i andre avdelinger i selskapet som kan hjelpe deg å lykkes. Du må måle hvor mye tid du kan stole på fra disse menneskene, fordi å be om tid fra utenforstående kan være en vanskelig forespørsel med prosjekter som hovedsakelig eies av én avdeling. Hvis du ikke vil be om en stor del av tiden deres utenfor porten, bare spør om du kan samarbeide med (eller rådføre deg med) dem for å sikre det beste resultatet for hovedansvaret for den rollen. Når du har gjort noe samarbeid, vil du ha en bedre forståelse av mengden interaksjon du kan trenge og om du trenger å komme med en mer formell forespørsel om hans eller hennes tid. Hvert selskap vil ha en annen struktur og forskjellige navn på avdelingene sine, men her er noen vanlige steder å se etter partnere: Spør om det er noen i markedsføringen for rollen som merkevarestrateg

avdeling som kan fungere som kontaktpunkt. Dette kan også være en kilde for visuelle designere og innholdsstrateger. Partnere for visuell design og innholdsstrategi kan også finnes i

program- eller produktledelse eller i avdelingen for forskning og utvikling, drift eller bedriftsstrategi, hvor du ofte kan finne forretningsanalytikere og produktledere. IT- eller ingeniøravdelingen er ofte det beste alternativet for front-end

utviklere og andre som kan hjelpe deg med å få tilgang til og innsikt i verktøy for nettstedsanalyse.

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

Hvis du nylig har blitt ansatt i et nytt selskap og forventer å jobbe på tvers av avdelinger, er en av de beste tingene du kan gjøre utenfor porten å identifisere nøkkelpersoner som kan være partnere og planlegge litt intervjutid med dem for å forstå rollene deres. og erfaring. Det starter deg med et nettverk som du ofte kan stole på i lang tid og gir deg muligheten til å forklare ditt ansvar (og brukeropplevelsesdesign generelt). Du kan også stille et godt spørsmål på slutten av intervjuet: "Hvem andre synes du jeg burde snakke med?" Svaret kan hjelpe deg med å finne personer som kanskje ikke er synlige for hovedprosjektlederen eller kundekontakten din. Hvis du har vært i en bedrift en stund, kan du fortsatt sette i gang en intervjuplan som dette. I den situasjonen er det best å knytte det til en bestemt milepæl (for eksempel starten på et nytt prosjekt) eller et bedriftsmål som har noe presserende kraft bak seg, for å sikre høy deltakelse. Sørg for at lederen din vet hva du gjør for å unngå å se ut som om du går rundt ham eller henne. God kommunikasjon er nøkkelen til å forstå forventninger til roller og bygge tillit. En annen nøkkel for å oppnå tillit i bedriften er å forstå dens kultur, de ofte uuttalte forventningene til hvordan en bedrift fungerer, slik som de skapt av tidligere prosjekterfaringer (positive eller negative), etikette angående organisasjonshierarki og akseptabel arbeidslogistikk (som f.eks. jobber hjemmefra).

Forstå bedriftskulturen Kultur er litt som å slippe en Alka-Seltzer i et glass – du ser den ikke, men på en eller annen måte gjør den noe. —Hans Magnus Enzensberger

En bedrifts kultur er kanskje ikke konsistent på tvers av alle dens regioner, forretningsenheter eller avdelinger, men du kan vanligvis identifisere nøkkelegenskaper som vil påvirke deg og prosjektet eller prosjektene du gjennomfører. Følgende er noen aspekter som er gode å huske på når du ser på prosjekter og navigerer i potensielt vanskelige politiske situasjoner.

FORSTÅ BEDRIFTSKULTUREN

Historie Vi kjenner alle sitatet om at de som ikke kan huske fortiden er dømt til å gjenta den, og prosjektarbeid er intet unntak. Å forstå hvordan et prosjekt eller team har kommet til sin nåværende behov kan hjelpe deg med å forstå utfordringene du kan møte i løpet av prosjektet. La oss dekke noen av spørsmålene du kan stille for å forstå historien som kan påvirke et prosjekt. Selv om noen av svarene på disse spørsmålene kan virke forferdelige, husk at noe har utløst behovet for å ta deg med på prosjektet, slik at et prosjekt kan ha en steinete historie og fortsatt være vellykket. Kanskje du vil være en nøkkelkomponent i denne suksessen! Men hvis mange av problemene diskutert nedenfor ser ut til å gjelde, og du ikke føler at du vil være i stand til å løse dem, kan det være et rødt flagg. Vurder i så fall en samlet vurdering av om dette prosjektet er posisjonert for å lykkes. Hva er et eksempel på et tidligere prosjekt som ser ut til å ha blitt vurdert-

ble en suksess, og hva ser ut til å ha gjort det slik? Hva er et tidligere prosjekt som ser ut til å ha vært en fiasko (eller spesielt smertefullt), og hvorfor mislyktes det? Å stille disse spørsmålene (enten direkte eller på en mer subtil, samtale måte) kan hjelpe deg å forstå et par ting: hvordan personen som svarer definerer suksess, potensielle risikoer for prosjektet ditt, og eventuelle skjevheter eller forventninger som vil bli gjennomført i dette prosjektet , samt tilnærminger som fungerte bra. Har selskapet jobbet med og gitt ut en designer på det samme

prosjekt eller team? I så fall, prøv å finne ut hva som ikke så ut til å fungere og hvordan klienten forventer at din tilnærming skal være annerledes. Hvis du kan stille mer enn én person i selskapet dette spørsmålet, vil det hjelpe deg å forstå mye om uuttalte forventninger. Hvis du får to svært forskjellige svar, kan det bety at designerens ansvar ikke var godt definert, og du må kanskje sørge for at det er mye kommunikasjon om dine ansvarsområder gjennom hele prosjektet. Har prosjektteamet jobbet med prosjektet (eller relatert materiale)

for det som virker som en uvanlig lang tid uten å bli ferdig?

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

I så fall kan dette være et tegn på at nøkkelkundeinteressenter ikke er på samme side eller ikke blir involvert på passende tidspunkter, noe som forårsaker flere stall, retningsendringer eller tapt tid på grunn av flere iterasjoner. Det kan også bety at det ikke er en tydelig leder, noen som kan si nei (eller i det minste effektivt prioritere) for å holde fokus på forretningsmål. Hvis du er i en posisjon til å påvirke kommunikasjonen om prosjektet, kan det hjelpe å lage retningslinjer for deltakelse for å hjelpe prosjektet videre. Har selskapet laget design uten tidligere deltagelse av

en UX-designer? Dette kan være en blandet velsignelse. På den ene siden har du å gjøre med et team som forstår behovet for design og har forsøkt å fylle gapet. På den andre kan du få et design som du føler ikke oppfyller prosjektmålene for brukeropplevelsen. Dette kan være en vanskelig situasjon å navigere i. Det er ofte best å henvende seg til skaperen av disse designene med tonen som en respektfull mentor eller hjelpsom konsulent, påpeke de gode sidene ved designet først, deretter diskutere brukeropplevelsesmål og hvordan de kan oppnås bedre med en annen tilnærming. Skaperen vil sannsynligvis være et verdifullt medlem av støttenettverket ditt, så det er viktig å ikke brenne broen her, men å redefinere rollene dine på en samarbeidsmåte for å holde entusiasmen i live. Virker hovedsponsor eller prosjektleder spesielt engstelig

om prosjektet? Det er mange grunner til at dette kan skje, spesielt hvis noen av faktorene ovenfor spiller inn. Angst kan også skyldes markedspress som det vil være nyttig for deg å forstå. Har selskapets aksjekurs for eksempel sunket? Har en bestemt konkurrent gjort de siste alarmerende fremskritt? Går virksomheten i minus? Igjen, disse situasjonene betyr ikke nødvendigvis at du ikke bør ta prosjektet videre; det er tross alt den typen situasjoner som ofte får et prosjekt finansiert i utgangspunktet. Men hvis du har en betydelig bekymring for at selskapet ikke vil være i stand til å betale sine fakturaer, er det en risiko du bør veie.

FORSTÅ BEDRIFTSKULTUREN

Hierarki Geert Hofstede har en utmerket modell som skisserer forskjeller i kultur, det han kaller «kulturelle dimensjoner», som ofte påvirker måten folk samhandler og kommuniserer på. En av dem er begrepet maktavstand, som er i hvilken grad medlemmer av et samfunn (i vårt tilfelle en bedrift) forstår og aksepterer avstanden mellom mennesker med ulike maktnivåer. For eksempel, hvis medlemmer av et selskaps ledergruppe blir sett på som spesielt mektige og potensielt utilnærmelige, kan et selskap ha en stor maktavstand og dets ansatte kan være mer fokusert på hierarkiet. Dersom selskapet oppfordrer til demokratisk deling av ideer og spørsmål ved visjon, kan det ha en relativt liten maktavstand.

Maktavstand er "... i hvilken grad de mindre mektige medlemmene av organisasjoner og institusjoner (som familien) aksepterer og forventer at makt er ulikt fordelt. Dette representerer ulikhet (mer versus mindre), men definert nedenfra, ikke ovenfra. Det antyder at et samfunns nivå av ulikhet støttes like mye av tilhengerne som av lederne." Geert Hofstede kulturelle dimensjoner www.geert-hofstede.com

Ingen av ytterpunktene kan betraktes som gode eller dårlige i seg selv, selv om de fleste ansatte generelt i USA ser ut til å foretrekke utseendet til en liten maktavstand på arbeidsplassen sin. Det som er interessant å merke seg er at dette ikke nødvendigvis er en indikator på hvor vellykket et selskap er. Apple har en relativt stor maktdistanse (hvis du tar i betraktning auraen rundt Steve Jobs), og Google har en relativt liten maktdistanse som en del av sin kultur, men begge selskapene er kjent for å være innovative ledere. Det som er viktig å merke seg er at maktavstanden i klientbedriften vil ha innvirkning på hvordan du lykkes med å navigere i det politiske farvannet i løpet av prosjektet. Dette aspektet vil bli spesielt viktig på sentrale punkter i prosjektet: under kravinnsamling (diskutert i kapittel 5) og ved viktige milepæler som avtegningspunkter (diskutert i kapittel 4). Hvis du jobber i et selskap med stor kraftavstand, ta litt ekstra

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

tid til å forstå rapporteringsforhold før du planlegger møter som interessentintervjuer og vurderinger, og vurder å involvere flere personer på mellomnivå under kommunikasjonen.

Logistikk I tillegg til de større aspektene ved kulturen nevnt ovenfor, er det også nyttig å forstå noen av elementene som er mer logistiske, slik at du bedre kan integrere med gjeldende arbeidsmetoder eller introdusere endringer på en gjennomtenkt måte. For eksempel er det nyttig å forstå det generelle tempoet som forventes i selskapet, inkludert viktige utgivelsesdatoer eller tidsfrister som vil påvirke prosjektet (å lage en programvareapplikasjon på en årlig utgivelsesplan vil sannsynligvis ha et annet tempo enn en mikroside som støtter en sesongbasert kampanje, for eksempel). Vil teamet ditt forventes å jobbe sent for å overholde truende tidsfrister? Forventninger til fjernarbeid kontra arbeid på stedet er også gode å forstå. Hvis det forventes mye tid på stedet, må du planlegge for reise og ressursoppsett der. Hvis fjernarbeid er akseptabelt (eller oppmuntret, noe som er vanlig når man jobber med globale selskaper), er det viktig å forstå metoder og verktøy for kommunikasjon. Er for eksempel bruk av direktemeldingsapplikasjoner akseptabelt? Hvilke webkonferanseverktøy er i bruk? Finnes det metoder for å inkludere internasjonale interessenter som har vist seg effektive tidligere? Det er også interessant å forstå "papirkulturen" i et selskap. Noen selskaper foretrekker elektroniske medier for det meste, i så fall er en god projektor og en konsekvent Ethernet-tilkobling viktig. Andre er veldig papirsentriske, i så fall må du sørge for at du tar med nok kopier til et møte for å gjøre det produktivt. Du kan kanskje endre kulturen i prosjektet hvis du tror en annen måte er mer effektiv. Men det er godt å vite at du ber folk om å endre seg slik at du kan jevne overgangen – og potensielt forstå hvorfor en bestemt tilnærming ikke fungerer slik du forventet.

FORSTÅ BEDRIFTSKULTUREN

Pulling It Together Nå som du har utforsket terrenget til prosjektet, bør du ha en bedre forståelse av prosjektets økosystem: miljøet du arbeider innenfor (bedriftskulturen), den generelle typen arbeid dere alle vil være engasjert i (for eksempel typene nettsteder du designer), og personene du vil samhandle med (inkludert deres roller og ansvar). Denne informasjonen vil være verdifull når du skisserer din rolle i prosjektet og gjør deg klar til å begynne for alvor. Hvis du jobber som frilanser eller underleverandør, vil det gi grunnlag for å skrive et forslag som dekker arbeidet ditt med prosjektet (se neste kapittel, som diskuterer UX-forslag). Hvis du jobber som medlem av et større team og ikke er direkte involvert i å skrive forslaget, kan du ta med deg den nye kunnskapen din inn i prosjektets kickoff – det første møtet i teamet ditt. For en grunnleggende veiledning for å gjennomføre et godt møte, se nettkapittelet "En kort veiledning til møter", eller hvis du ønsker å komme rett inn i hva slags spørsmål du bør stille når prosjektet starter, se kapittel 4, "Prosjektmål og tilnærming.»

KAPITTEL 2: PROSJEKTET ØKOSYSTEM

Forslag for konsulenter og frilansere En veiledning for de i virksomheten som også styrer sin egen virksomhet Det kan være utfordrende nok å administrere prosjekter og kundenes forventninger, men hvis du ikke har en passende avtale på plass, kan du finne deg selv på det tapende slutten av ethvert prosjekt du tar på deg. Forslag og arbeidserklæringer er avgjørende for å beskytte virksomheten din – og deg selv – mot økonomiske og juridiske problemer. Etter at du har godtatt et prosjekt og håndhilser, sørg for at du bruker riktig tid på å lage en avtale som beskriver vilkårene for forholdet ditt og betalingsplanen for klienten din. Russ Unger

Forslag Det er et gammelt ordtak som sier at «ingen god gjerning går ustraffet», og det samme gjelder generelt for å lande ethvert prosjekt – high-fives og feel-good-øyeblikkene blir raskt erstattet med «Oh, crap! Det er på tide å skrive forslaget!" Den største utfordringen med å skrive forslaget er å skrive ditt aller første. Det er nesten umulig å vite hvor du skal begynne hvis du aldri har vært nødt til å skrive en selv, og det er her dette kapittelet bør komme godt med. Hver type prosjekt du møter vil ha forskjellige smaker som vil holde deg på tærne når det er tid for å skrive forslaget. Heldigvis er det noe av en kjerne som er felles for alle forslag og kan gjenbrukes fra prosjekt til prosjekt. (For en detaljert omtale av prosjekttyper, se kapittel 2.) Når bør du skrive et forslag? Alltid. Hvorfor skal du skrive et forslag? Gjennom historien med å jobbe med prosjekter, har de som har satt folk i de mest ubehagelige situasjonene vært de der det ikke var noen avtale på plass mellom klienten og leverandøren. Du kan bli veldig fristet til å hoppe over dette trinnet når du oppretter den første forbindelsen med en potensiell kunde og ting ser ut til å klikke. Selv om du har en tilsynelatende forståelse av kundens behov og er i stand til å artikulere det på en måte som de forstår, er du egentlig ikke helt klar til å begynne å jobbe ennå. Faktisk er dette akkurat det punktet hvor du må bremse ned og trekke pusten. I stedet for å gå rett på jobb, ta deg tid til å definere ditt profesjonelle forhold og reglene for engasjement med din nye klient. Jean Marc Favreau fra advokatfirmaet Peer, Gan & Gisler, LLP, i Washington D.C., sier: Altfor ofte tror entreprenører og deres klienter at det er et møte mellom sinnene i begynnelsen av forholdet deres, mens uklarheter faktisk bare lyver. på vent. Selv om det er nesten umulig å forberede seg på alle mulige situasjoner, er en omfattende skriftlig kontrakt ditt beste forsvar og den smarteste måten å sikre at du ikke senere finner deg selv i en rettssal som krangler om vilkårene for forholdet ditt. Jo tydeligere du definerer vilkårene og parametrene for forholdet ditt til en klient i en skriftlig kontrakt på forhånd, jo mindre sannsynlighet vil du ende opp med å kjempe om hver parts forpliktelser i ettertid.

KAPITTEL 3: FORSLAG TIL KONSULENTER OG FRILANSERE

Nye prosjekter og nye mennesker er spennende. Det er ofte et ønske om ikke å "drepe avtalen" ved å kaste et forslag inn i blandingen, men, som i ethvert forhold, kan bryllupsreisefølelsen til slutt avta. Løfter kan brytes på begge sider av forholdet. En klient kan ikke gi deg tilgang til innhold i tide. (Jeg vet at dette er nesten uhørt, men tro det eller ei, det skjer! Det er sarkasme, i tilfelle du gikk glipp av det.) Finansiering som en gang var tilgjengelig for prosjektet, kan flyttes andre steder – og deretter du, den som er engasjert i arbeidet, kan bli stående og holde posen. Bedrifter innser også at de tar risiko med å samarbeide med eksterne leverandører – spesielt de som er svært små bedrifter eller uavhengige entreprenører. Velskrevne forslag gir kundene en følelse av stabilitet og beskyttelse, noe som kan bidra til å lindre mange av bekymringene som kan oppstå. Et forslag lar deg også definere begreper som beskytter begge sider i tilfelle noe endres. Hvis klienten ikke gir deg rettidig tilgang til ressursene sine, kan tidslinjen din glippe; du må gjøre dem oppmerksomme på deres forpliktelser for prosjektets suksess. Hvis en klient mister finansiering og dreper prosjektet – og du ikke har et forslag eller annen form for kontrakt på plass – kan du risikere å ikke få betalt for arbeid du allerede har fullført. Poenget bør være krystallklart: Skriv alltid et forslag.

Opprette forslaget Etter at du har landet prosjektet, er det på tide å få forslaget ferdig. Jo raskere et forslag blir godkjent og signert, desto raskere kan du begynne arbeidet og – viktigst av alt – begynne å få betalt for arbeidet. Kjernekomponentene i et godt forslag er Tittelside Revisjonshistorikk Prosjektoversikt Prosjekttilnærming

OPPRETTING AV FORSLAGET

Arbeidsomfang Forutsetninger Leveranser Eierskap og rettigheter Tilleggskostnader og gebyrer Prosjektprising Betalingsplan Bekreftelse og påtegning

La oss ta et dypere dykk inn i hver del av forslaget.

Tittelside Tittelsiden er den enkle siden som introduserer dokumentet ditt. Tittelsider er et interessant beist: det er en rekke måter du kan lage dem fra et stil- og informasjonsperspektiv. Hvordan du gjør det er opp til deg. En typisk tittelside består av følgende elementer: Kundens firmanavn Kundens firmalogo (hvis du har tillatelse til å bruke den) Prosjekttittel Dokumenttype (forslag) Versjon av forslaget Innleveringsdato Ditt firmanavn Forslagsforfattere Prosjektreferansenummer Kostnad Konfidensialitet

For ditt første forslag inkluderer alt – bortsett fra kundens firmalogo, kostnaden og (potensielt) prosjektets referansenummer. Hvorfor ikke inkludere disse elementene på tittelsiden?

KAPITTEL 3: FORSLAG TIL KONSULENTER OG FRILANSERE

Din klient vet hvem de er. Det er sannsynligvis ikke verdt tiden og innsatsen å be om tillatelse til å bruke firmalogoen, og det er heller ikke verdt den mulige ubehageligheten hvis du utilsiktet misbruker den. Kostnaden er best plassert etter at du har identifisert de ulike komponentene i prosjektet i kroppen, og kostnadsinformasjonen leder fint inn i betalingsplanen. Prosjektets referansenummer er noe å være oppmerksom på. Mange selskaper vil ikke bruke en i det hele tatt; Noen offentlige etater er imidlertid kjent for å stole på dette bestemte elementet, og hvis det ikke finnes på tittelsiden din, kan forslaget ditt bli avvist.

Figur 3.1 Eksempel på tittelside for forslag

I figur 3.1 ble den (fiktive) klientlogoen brukt. I tilfelle tillatelse ikke ble gitt eller et forhold ikke ble etablert, er det best å ikke vise logoen til klientselskapet.

OPPRETTING AV FORSLAGET

Revisjonshistorikk Revisjonshistorikken er sin egen del av forslaget og brukes til å identifisere hvor mange ganger du har oppdatert forslaget siden den opprinnelige versjonen. Generelt er det best å oppgi versjonsnummer, dato, forfatter og eventuelle kommentarer knyttet til versjonen, for eksempel hva som ble modifisert, for å gi leseren kontekst med hensyn til modifikasjonene (tabell 3.1). TABELL 3.1 REVISJON

Eksempel på revisjonshistorikk DEL

BESKRIVELSE

REDAKTØR

DATO

Originaldokument

REU

8-jan-09

Antagelser

Oppdatert for å gjenspeile programvarekrav

REU

11-jan-09

1.0 1.1

Noen ganger vil klienter signere et forslag og deretter be deg om ytterligere revisjoner. Hvis du velger å gå videre med klienten og gjøre disse endringene, bør du benytte anledningen til å oppdatere dokumentet ditt fra versjon 1.x til 2.0. I hovedsak, når en klient godkjenner et forslag og begge parter er enige om vilkårene, er du klar til å begynne å jobbe. Så når ytterligere modifikasjoner blir bedt om, må du gjennomgå dem veldig nøye. Dette sikrer at kostnadene dine fortsatt gir mening og at det er en klar forståelse fra begge sider om modifikasjonene og på hvilket stadium prosjektet starter på nytt (om nødvendig). Du bør også alltid gi en passende forklaring på hvorfor revisjonen utgjør en fullstendig ny versjon i revisjonshistorikken.

Prosjektoversikt Oversiktsdelen er en beskrivelse av prosjektet du skal jobbe med – med dine egne ord. Denne beskrivelsen skal gi kunden et klart bilde av hva du ser for deg at produktet deres vil innebære, samt en forklaring på hva de kan forvente å finne i resten av forslaget. Her er et eksempel på begynnelsen av en oversikt: [Client Company Name] søker å opprette en ny nettbasert tilstedeværelse. Denne netttilstedeværelsen gir kunder med [Client Company Name] muligheten til å undersøke og kjøpe produkter online, samt andre tjenester og fordeler som er tilgjengelige gjennom selskapet. Målene med tilstedeværelsen på nettet er å...

KAPITTEL 3: FORSLAG TIL KONSULENTER OG FRILANSERE

Du bør være i stand til å gi en solid oversikt i ett eller to avsnitt, og gi et meget høyt nivå av detaljer om hva kunden kan forvente av deg. Det er en god idé å avslutte oversikten med en god forklaring på anbefalingene dine og den foreslåtte tilnærmingen til å fullføre prosjektet: Dette forslaget vil detaljere [Ditt firmanavn]s anbefalinger og tilnærming for design og utvikling av [kundefirmanavn]' s online tilstedeværelse på Internett. Gitt fristen [fristdato], foreslås det at...

Prosjekttilnærming Tilnærmingen til prosjektet vil variere avhengig av hvilken type prosjekt du gjennomfører. Dette er din mulighet til å identifisere for kunden din hvordan du planlegger å jobbe med prosjektet med dem. Du får definere dine engasjementsregler og sette forventninger til arbeidet som ligger foran deg. Mange enkeltpersoner og selskaper opererer med svært like metoder - men bruker forskjellige navn eller smarte akronymer som samsvarer med deres generelle merkevarebygging. En gang i tiden ble det laget en mytologisk metodikk for å vise til (potensielle) kunder, og den fant veien inn i mange forslag. Prosessen ble kalt The PURITE Process™ (uttales "renhet"), og ved å dele dette med deg, har et mytologisk vesen nettopp dødd litt på innsiden, så vær så snill å lese dette som et stykke ﬁksjon. Navnet på prosessen er litt cheesy, og prosessen er tydelig noe ufullstendig. Etterlanseringsanalyse ble utelatt fra denne metodikken (en forglemmelse), men den bør selvfølgelig inkluderes for alle klienter. Uten ytterligere forsinkelse, her er PURITE-tilnærmingen: [Ditt firmanavn] har identifisert en standardprosess for prosjektsuksess med våre kunder. Selv om hver av disse fasene kanskje ikke gjelder for [Prosjekttittel], er hele prosessen definert som følger: PURITE-prosessen™ er [Ditt firmanavn]s interne metodikk for å sikre suksess over hele linjen for alle initiativer. Ved å bruke PURITE har [Ditt firmanavn] et velprøvd sett med retningslinjer for å jobbe tett med kunder og brukere/publikum for å pålitelig opprettholde og overgå leveringsforventninger. P – Forbered deg. Vi dedikerer en del av hvert initiativ til å forstå din bransje og konkurrentene dine og hvordan de driver forretninger for å være så informert som mulig før du begynner å samle inn krav. Du forstår. Vi jobber tett med dine fageksperter og/eller brukere for å definere kravene for å bygge prosjektet riktig.

OPPRETTING AV FORSLAGET

R – Render. Gjennom Render-fasen skaper og utvikler vi alle delene av prosjektet/produktet. Vår erfaring er at enhver utviklingsfase krever mye heads-down, fokusert arbeidsinnsats, men også rettidig, åpen kommunikasjon med teamet ditt. Det krever også at vi... Jeg – Itererer. Iterate-fasen gjentas gjennom hele prosjektets livssyklus. Vi beveger oss så raskt som mulig for å bringe prosjektet til live, og dette krever ofte å lage flere iterasjoner i raske tidslinjer. Dette krever direkte og rettidig involvering fra deg og dine dedikerte ressurser. Sluttresultatet er produktet du har spesifisert – og vært med på å lage. T – Test. Vi tester hvert prosjekt i løpet av vår Render-fase; Vi krever imidlertid også et ekstra sett med øyne – fra vårt eget testteam og fra din utpekte brukergruppe/publikumsgruppe for å utføre målbasert testing. Denne ekstra runden med testing bidrar til å sikre at så få steiner som mulig blir stående uvendt for å levere et prosjekt som har blitt grundig evaluert fra flere nivåer. E – Aktiver. Etter vellykket gjennomføring av de fem foregående fasene og din signerte godkjenning, vil vi aktivere løsningen og ta den live. PURITE Process™ slutter ikke der. Etter ferdigstillelse av prosjektet kommuniserer vi jevnlig med våre kunder. Vi vil fortsette å måle tilfredshetsnivåene dine, forstå dine endrede mål eller prosjektforbedringer, og hjelpe deg med å definere den beste tilnærmingen for fremtidig utvikling av prosjektet ditt.

Du er velkommen til å bruke så lite eller så mye av dette som er aktuelt eller nyttig for deg. Den mytologiske forfatteren som skapte prosessen har ikke noe imot at du heller ikke krediterer kilden. Å definere prosessen kan være så detaljert som ovenfor eller så enkelt som følgende: Planlegg, definer, utvikle, forleng Planlegg den overordnede strategien Definer de detaljerte prosjektkravene Utvikle, test, avgrens og lanser arbeidsproduktet. Utvid prosjektet ved å anbefale forbedringer og forbedringer basert på informasjon lært under utvikling, testing og etterlansering

Etter at du har definert prosessen din, har du muligheten til å detaljere de ulike innsatsene som vil finne sted i hver fase av tilnærmingen din, samt hva hver av disse innsatsene betyr for deg og din klient. Tilnærmingsdelen av forslaget ditt vil variere i lengde avhengig av prosjektet, prosessen din og aktivitetene som finner sted innenfor hvert trinn i prosessen. Prøv å holde det til maksimalt to til tre sider, og

KAPITTEL 3: FORSLAG TIL KONSULENTER OG FRILANSERE

sørg for at du bare inkluderer utdataene du vil være i stand til å levere til kunden din – for å forhindre ytterligere oppdatering av dokumentet eller gjensyn med prosjektprisene.

Arbeidsomfang Arbeidsomfangsdelen er der du identifiserer arbeidsfordelingen for prosjektet. Det vil si at du identifiserer hvilke komponenter i prosjektet du har ansvar for og hvilke byggherre har ansvar for. Les det på nytt. Tenk på det et øyeblikk. La det synke inn. Så går vi. Det er riktig. Dette er den delen av forslaget der du skriftlig forteller klienten at vi skal gjøre dette og du skal gjøre det. Så senere, når klienten signerer forslaget ditt, samtykker de i denne ordningen, og du har et papirspor for å sikkerhetskopiere deg i tilfelle misforståelser. Hensikten her er å tydelig identifisere hvem som skal håndtere hvilke aspekter av prosjektet, samt hvilke aspekter av prosjektet som er inkludert i forslaget ditt og til prisen du har estimert. Hvis du ikke finner noen annen virkelig overbevisende grunn til å skrive et forslag, bør dette være grunn nok. Her er et veldig kort eksempel på et arbeidsomfang: Vi ble kontaktet av [Client Company Name] for å tilby alle tjenester som kreves for å bygge [Project Type]. [Ditt firmanavn] vil fokusere utelukkende på [User Experience Design Aspect(s)] på [Client Company Name]s nettsted. [Client Company Name] vil gi detaljert tilbakemelding om alle aspekter ved [Project Type] i samsvar med prosjektplanen. [Client Company Name] vil gi alle nødvendige eiendeler for bruk i prosjektet, inkludert fonter, fargeskjemaer, merkestandarder, etc.

Forutsetninger Forutsetningsdelen av forslaget er et godt sted å stave ut, uten å gi rom for debatt, hva som er nødvendig fra klienten din for å sikre din suksess. Det vil si at dette er de tingene du antar – og kommuniserer til kunden – som du vil ha tilgang til eller som vil bli levert til deg for å gjøre prosjektet til en suksess.

OPPRETTING AV FORSLAGET

Det du kaller forutsetninger i denne delen er virkelig forventninger. Det er bare mye mer høflig å anta. Du kan lage så mange prosjektplaner du vil, men hvis verken du eller klienten forplikter seg til å møte milepæler og mål, forplikter begge sider seg til en viss prosjektsvikt. Generelt er forutsetningene en forventning om ressurser og eiendeler, samt rettidig (oversettelse: rask, umiddelbar) tilgang til begge disse. Her er et eksempel på hvordan du skriver forutsetninger: Forutsetninger Det er nødvendig at [Klientfirmanavn] oppgir følgende eiendeler og ressurser. En manglende evne til å levere disse eiendelene og ressursene på en rettidig og fullstendig måte kan bidra til mislykket eller forsinket levering av dette prosjektet. Følgende eiendeler og ressurser forventes: Rettidig tilgang til alle nødvendige ansatte i [Klientfirmanavn]. Rettidig tilgang til alle nødvendige eiendeler til [Prosjektet] i gjeldende tilstand, inkludert eventuelle kildeﬁler, hvis tilgjengelig. Innhold, etter behov og inkludert, men ikke begrenset til, kopiering, bilder, lyd osv. for alle aspekter av [Prosjekt].

Leveranser Leveranser er arbeidsproduktet du skal lage og overføre til kunden. Denne delen er din mulighet til å detaljere overfor kunden hva slags arbeidsprodukt de kan forvente av deg i løpet av prosjektet. Det anbefales at du håndterer statusrapportering separat, nærmere slutten av prosjektet, men legg det gjerne til denne delen av prosjektet. Gi beskrivelser av ethvert arbeidsprodukt du kan inkludere, selv om arbeidsproduktet ikke blir produsert. Dette kan virke som om det kan være overdrevet eller har potensial til å åpne "Jeg leste om [leverbar type] i forslaget, men jeg ser det ikke her"-boks med ormer, men ett lite ord, kan, kan gjøre forskjellen. Leveranser [Ditt firmanavn] gir en rekke leveranser i løpet av et prosjekt. For [Client Company Name] har vi identifisert følgende leveranser:

KAPITTEL 3: FORSLAG TIL KONSULENTER OG FRILANSERE

Creative Brief Creative Brief er det første trinnet i prosjektet. Dette dokumentet vil hjelpe oss å skape en rask og effektiv oversikt over prosjektet på høyt nivå. Formålet med Creative Brief er å klargjøre målene og behovene til brukerne og å definere noen av de spesielle ressursene og/eller begrensningene knyttet til prosjektet. Og så videre…

Eierskap og rettigheter Det er viktig å vurdere i hvilken grad du vil tillate din klient å bruke arbeidsproduktet du produserer. Disse rettighetene kan defineres på mange forskjellige måter, men mesteparten av arbeidet ditt vil falle inn i to kategorier: Arbeid for leie Lisensiert arbeid

Arbeid for utleie (kjent i den juridiske verden som "arbeid laget for utleie")-prosjekter anses å være opprettet av og under opphavsrett av den parten som betaler for arbeidet - ikke den part som er ansvarlig for å utføre selve arbeidet. Dette betyr at når du utfører arbeid på et prosjekt som er arbeid for utleie, har du absolutt ingen rettigheter til arbeidet og alt du lager knyttet til prosjektet eies av oppdragsgiver. Denne situasjonen er vanskelig for mange bedrifter og enkeltpersoner å håndtere: Det betyr ofte at det ikke er noe nedstrøms "vedlikeholdsarbeid" (med tilleggsinntekter), ettersom kunder kan bestemme seg for å vedlikeholde prosjektet på egen hånd når det er fullført. Ikke la deg påvirke av et prosjekt der en klient tvinger kravet; det er ikke uvanlig. Når du setter arbeid for ansettelsesprosjekter i sammenheng med heltidsarbeid i et selskap, er dette ganske standard for et arbeidsgiver-ansatt-forhold. Det er også en mulighet til å besøke prismodellen din – mange prosjekter faktureres til en noe høyere rate for å kompensere for potensielt tapte inntekter i fremtiden. Husk at alt avhenger av forholdet du har til kunden din og hvordan du velger å gjøre forretninger. Tid og erfaring vil hjelpe deg med å bestemme deg for den type arbeid du gjør og prismodellene du velger. Lisensierte arbeidsprosjekter gjør at du kan beholde opphavsretten til verket, men gir andre parter rett til å kopiere og/eller distribuere det. Du kan bygge et hvilket som helst antall bestemmelser inn i lisensavtalen. Du vil mest sannsynlig LAPE FORSLAGET

dra nytte av å lisensiere arbeidet ditt når du beholder eierskapet til alt kildematerialet til arbeidet ditt og leverer kun arbeidsprodukter med begrenset bruk til kundene dine (som PDF-er i stedet for originale, redigerbare Word-, Visio-, Axure-, OmniGraffle- eller andre dokumenter ). Du kan ta mange forskjellige tilnærminger til å lisensiere arbeidet ditt, inkludert lisensiering av arbeid som skal brukes uten modifikasjoner, ikke-kommersielt eller en rekke andre måter som kan passe din situasjon. Creative Commons (http://creativecommons.org/about/licenses) gir enkle å forstå forklaringer på en rekke lisenstyper som du kan bruke, men de er bare en liten del av lisensieringsverdenen. Hvis du kommer i en situasjon hvor du kommer inn i svært detaljerte og spesifikke behov, er det alltid best å kontakte en opphavsrettsadvokat for å hjelpe deg med å lage den best mulige løsningen.

Ytterligere kostnader og gebyrer Det er viktig at klienten din forstår om prosjektprisene du vil gi for dem tar (eller ikke) hensyn til eksterne ressurser. For eksempel kan noen prosjekter kreve kjøp av arkivfotografi fra en leverandør. Du kan enten kjøpe bildet (med de riktige bruksrettighetene) og inkludere det som en del av gebyret ditt, eller du kan tydelig identifisere kjøp av bilder som en ekstra kostnad som overføres til kunden din. Du kan også tilby tjenester som du ønsker å gjøre kunden oppmerksom på – dette er en god mulighet til å markedsføre disse tjenestene. Her er et eksempel på hvordan man forklarer hvordan tilleggskostnader og gebyrer vil bli håndtert: Tilleggskostnader og gebyrer I tilfelle det kreves eksterne ressurser (som innhold, bilder, fonter osv.), skal disse identifiseres, godkjennes av og fakturert til [kundeselskapsnavn]. I tillegg kan [Ditt firmanavn] tilby hostingtjenester til våre kunder med svært lave kostnader. Vi tilbyr vertstjenester – inkludert konfigurerbar, nettbasert e-post – fra så lavt som $25 per måned, med en $25 oppsettsavgift. I tilfelle [Client Company Name] ønsker å kjøpe en "vedlikeholdspakke", vil [Ditt firmanavn] arbeide for å lage en pakke som er gjensidig akseptabel og fordelaktig for begge parter.

KAPITTEL 3: FORSLAG TIL KONSULENTER OG FRILANSERE

Prosjektprissetting Etter at du har dokumentert detaljene om hvordan du skal utføre arbeidet for prosjektet, er det en ganske god idé å gi kunden beskjed om kostnadene. Hvordan du kommer frem til prisen er i stor grad opp til deg, men her er et tips: Estimer hvor lang tid du tror det vil ta deg å gjennomføre prosjektet – inkludert et spesifikt antall revisjoner, estimer en rimelig tid for prosjektledelse, som kan være rundt 25 prosent; Bestem deretter den fakturerbare timeprisen du vil belaste, og regn ut alt. Det finnes en rekke formler for å hjelpe deg med dette, for eksempel å bruke vanskelighetsgrader på hver del av prosjektet, for å hjelpe deg med å komme opp med et kostnadsintervall å gi kunden din. I de fleste tilfeller vil erfaring være nøkkelen til å hjelpe deg med å anslå prosjektene dine på riktig måte – fra et tids- og materialperspektiv. Hvordan bestemmer du faktureringssatsen din? Undersøk hva andre krever, for sammenligning, ved å finne lønnsundersøkelser og entreprenørpriser. For eksempel utfører organisasjoner som Information Architecture Institute (www.iainstitute.org), AIGA (www.aiga.com), Coroﬂot (www.coroot.com) og talentbyrået Aquent (www.aquent.com) lønn og entreprenørtakstundersøkelser. Du kan få et godt inntrykk av prisene du kan kreve ved å ta hensyn til din erfaring, hva andre i markedet krever, og hva du føler er litt rettferdig. Husk: Du kan alltid senke prisen. Det er mye vanskeligere å be kunden din om å betale deg mer penger når de har sett tall på en side! Det er mange forskjellige måter å strukturere prisene for prosjektet på. Avhengig av prosjektets art, kan det hende du ønsker eller trenger å gi flere estimater som tillater en rekke prisalternativer. Anta for eksempel at du gir en klient to alternativer: et statisk HTML-nettsted og et nettsted med et innholdsstyringssystem (CMS) som vil tillate dynamisk innhold (som klienten deretter kan administrere uten dedikerte ressurser). Slik kan du formulere prosjektestimatene: Prosjektestimat [Ditt firmanavn] har foreslått flere estimater for [kundeselskapets navn], for å gi de best mulige alternativene for dine umiddelbare og/eller fremtidige behov. [Ditt firmanavn] forutsetter at alt innhold vil bli levert av [kundens firmanavn]. I tilfelle [Ditt firmanavn] blir bedt om å tilby innholdstjenester, må estimatene omdefineres.

OPPRETTING AV FORSLAGET

[Ditt firmanavn] sine estimater gir mulighet for fleksibilitet fra et kostnads- og behovsperspektiv. Anslagene er som følger: Estimat 1 [Ditt firmanavn] anslår at [Prosjektet] for [kundeselskapets navn], uten noe interaktivt innhold...

Husk at det ikke er noen virkelig feil måte å sette sammen prosjektestimatet ditt på – med mindre du setter deg selv i en negativ kontantstrømposisjon!

Betalingsplan Det er en myte som flyter rundt at alle frilansprosjekter betales 50 prosent på forhånd, før arbeidet begynner, og 50 prosent ved ferdigstillelse, når prosjektet avsluttes. Denne myten må avlives – akkurat nå! Dette er ingen måte å gjøre forretninger på, og det er ingen måte å sikre rettidig, konsistent inntekt mens du utfører arbeidet. Du ønsker ikke å sette deg selv i en posisjon hvor du må gjøre endring etter endring for en klient bare fordi du ønsker å få prosjektet ferdig og få betalt, i stedet for å jobbe gjennom en endringsordreprosess. Du kan prissette prosjekter på flere måter – fra innsendte fakturaer i en forhåndsbestemt tidsramme til milepælbaserte betalinger. En klokere tilnærming er å styre prosjektene dine til en tilbakevendende betalingsplan med vanlige, detaljerte fakturaer. Denne tilnærmingen bør også gi kundene en klar forståelse av hva som er oppnådd og hvilket arbeid som gjenstår på prosjektet. Følgende eksempel er én måte å strukturere betalinger for arbeidet ditt på: Betalingsplan [Ditt firmanavn] typisk betalingsplan er å motta en retainer-avgift på XX % av den totale estimerte prisen på prosjektet før oppstart. [Ditt firmanavn] skal sende inn fakturaer den 1. og 15. i hver måned; betaling forfaller i sin helhet innen 14 dager. Etter fullføring av prosjektet skal [Ditt firmanavn] levere alt arbeidsprodukt til [kundeselskapsnavn]. Når materialet er tilfredsstillende godkjent, skal [Ditt firmanavn] refundere eventuelle overskytende betalinger fra beholderen, eller [Ditt firmanavn] skal sende inn en endelig faktura for beløp som ikke dekkes av beholderen. Merk: Hvis [Prosjekt] settes på vent i en periode på mer enn 14 dager uten at det er gjort fremdrift, skal [Ditt firmanavn] sende inn en endelig faktura for eventuelle gebyrer som ikke dekkes av beholderen og skal ha rett til å førsteavslag i tilfelle prosjektet gjenåpnes.

KAPITTEL 3: FORSLAG TIL KONSULENTER OG FRILANSERE

Selv om det ikke er nødvendig, er det nyttig å inkludere et notat om hvordan prosjektet vil bli håndtert hvis det blir satt på vent i en lengre periode. Denne bestemmelsen kan hjelpe deg med å holde prosjektet på rett spor og komme videre – og det gir deg et diskusjonspunkt med kundene dine. Hvis du ikke skal gjøre tilleggsarbeid for dem på lang tid, vil du kunne gå videre og se etter arbeid for å fylle tomrommet.

Anerkjennelse og påmelding Selv om det er veldig viktig å sikre at du har et forslag på plass, er det i seg selv ikke nok. Forslaget betyr egentlig ikke så mye før den rette personen i ditt kundeselskap har godkjent og signert det. Det er viktig å sørge for at alle har en klar forståelse av hva som kommer til å finne sted og hvor mye som forventes fra hver side. Det er like viktig at du beskytter deg mot "iterasjonsmotorveien" og reduserer risikoen for å tillate en klient å engasjere deg i "funksjonskryp": kontinuerlig ber om "bare en ting til" som må inkluderes. Sign-offs er ganske enkle og klare. Når du har opprettet forslagsdokumentet, vil du gi kunden din en bekreftelse og sign-off som vil godkjenne avtalen mellom de to selskapene dine. Forbered alltid to eksemplarer – en for hver part – og sørg for at begge kopiene er signert. Her er et eksempel på en bekreftelse du kan bruke: Bekreftelse Dette forslaget er bekreftet og godkjent i sin helhet av [Klientens firmanavn]. Dette forslaget må være signert og datert av en autorisert representant for [Client Company Name] for å være i kraft. Alternativt vil en signert innkjøpsordre som refererer til dette forslaget utgjøre aksept i stedet for dette signerte dokumentet (forutsatt imidlertid at eventuelle forhåndstrykte vilkår på en slik innkjøpsordre skal anses som ugyldige og uten effekt). Dette forslaget utgjør hele avtalen mellom partene med hensyn til emnet for dette forslaget. Dette forslaget slår sammen og erstatter alle tidligere muntlige eller skriftlige avtaler, diskusjoner, forhandlinger, forpliktelser, skrifter eller forståelser. Dette inkluderer uten begrensning eventuelle representasjoner i salgslitteratur, brosjyrer eller annet skriftlig beskrivende eller reklamemateriale og er den fullstendige og eksklusive erklæringen om vilkårene i partenes avtale. Hver av partene erkjenner og godtar at de ikke har stolt på dette forslaget, og de fraskriver seg uttrykkelig enhver tillit til, enhver representasjon eller uttalelse som ikke er angitt her eller i avtalen.

OPPRETTING AV FORSLAGET

Godkjent av autoriserte representanter for: [Ditt firmanavn]

[Klientbedriftsnavn]

Av: ________________________________

Navn: _____________________________

Navn:_____________________________

Tittel: __________________________________________

Tittel: ______________________________

Dato: ______________________________

Gjør alle sjekker utbetalt til: [Ditt firmanavn]

Arbeidserklæringer En arbeidserklæring (SOW) er en definisjon på høyt nivå av prosjektmålene dine som du skal kunne sette sammen i et to- til tre-siders dokument (ikke inkludert omslag). SOW-en skrives vanligvis før du går inn i detaljerte krav, men avhengig av klienten og prosjektbehovene dine, kan du velge å lage et hybriddokument som passer best til dine behov. Generelt bør SOW-er brukes til å bygge konsensus mellom teamet ditt og kundens interessenter tidlig. SOW vil definere input og output fra prosjektet, samt forutsetninger og begrensninger. På dette tidspunktet er det ikke uvanlig at klienter ber deg om å gi en "ballpark-figur" for arbeidet du skal gjøre for dem. Det kan være litt risikabelt å svare på det på dette tidspunktet. Det anbefales at du gjør ditt beste for å unngå spesifikasjoner eller forpliktelser uten å definere detaljene. Det er bare ikke mulig å vite hvor mye et prosjekt kommer til å koste når du ennå ikke har skrevet forslaget og/eller kravdokumentet. Når det er sagt, må du foreta en vurdering på dette tidspunktet. Hvis du jobber med et prosjekt som et grunnleggende nettsted, og du har fullført flere lignende prosjekter før og/eller har jobbet med samme klient før, så har du litt slingringsmonn. Husk at å feile på siden av forsiktighet er alltid bedre enn en ubehagelig situasjon senere i prosjektet. En arbeidsoppgave bør være på omtrent to til tre sider og minst inneholde følgende:

KAPITTEL 3: FORSLAG TIL KONSULENTER OG FRILANSERE

Tittelside Revisjonshistorikk Prosjektreferansenummer Prosjektoppsummering Startdato Sluttdato Takst/pris Prosjektforklaring Aktiviteter og leveranser Spesifiserte kostnader og betalingsplan Kvittering og avtegning

Ser elementene kjente ut? De bør - du kan sette sammen en SOW ved å bruke en nedskåret versjon av forslaget. Du har nå lært hvordan du setter sammen to typer dokumentasjon som lar deg identifisere arbeidet du utfører for en klient. Disse dokumentene bør være grunnlaget for ethvert prosjektarbeid du gjør for en klient, og vil gi deg og dine klienter et veldefinert sett med marsjordre for prosjektene dine.

ARBEIDSUTTALELSER

Prosjektmål og tilnærming Vet hvilken stjerne du skal navigere etter En av nøklene til et godt prosjekt er å starte teamet med klare prosjektmål og en godt forstått tilnærming. Ideelt sett vil prosjektledelsen ha dette definert for deg – men hvordan vet du om de ikke gjør det? Dette kapittelet snakker om å danne prosjektmål og tilbyr noen spørsmål som vil hjelpe deg å fastsette disse målene. Vi vil også diskutere noen vanlige prosjekttilnærminger (eller metoder) og hvordan de kan påvirke måten du jobber på. Carolyn Chandler

du er i prosjektets kickoff, med hele teamet for første gang. Prosjektleder deler ut noe materiell og gir deg en oversikt over prosjektet. Ved slutten av møtet bør du ideelt sett ha følgende informasjon:

Hvorfor er prosjektet viktig for bedriften? Hvordan vil interessenter avgjøre om prosjektet var en suksess? Hvilken tilnærming eller metodikk vil prosjektet følge? Hva er de viktigste datoene eller milepælene for viktige punkter, for eksempel å få

godkjenning fra næringslivets interessenter? Alle disse spørsmålene gjelder forventningene som interessentene har til prosjektet: hva prosjektet vil oppnå og hvordan de vil bli involvert i det. De to første spørsmålene gjelder prosjektets mål og de to siste til prosjektets tilnærming. Et prosjektmål er en uttalelse av et målbart mål for prosjektet. La oss snakke om mål mer detaljert.

Solidify Project Objectives Mål er en viktig fokuslinse som du vil bruke gjennom hele prosjektet. De bør springe ut av klientbedriftens overordnede forretningsstrategi, så prosjektmålene bør være i tråd med de strategiske initiativene i selskapet. For eksempel, hvis det er et strategisk initiativ for å appellere til en ny gruppe potensielle kunder (kalt et marked), kan nettstedet eller applikasjonen du oppretter være et forsøk på å gi det markedet tilgang til produkter og tjenester som er relevante for dem. . Målet for det prosjektet ville da være fokusert på å nå og engasjere det markedet. Et klart mål gir gjenklang gjennom et prosjekt. Det hjelper deg Still de riktige spørsmålene mens du samler ideer fra forretningsinteressenter Planlegg undersøkelser med brukere og fokuser analysen din av resultatene. Detaljer ideene samlet fra interessenter og brukere og konverter dem

inn i en konsolidert liste over prosjektkrav. Prioriter disse prosjektkravene basert på deres verdi for selskapet

STYRK PROSJEKT MÅL

Lag effektive interaksjonsdesign Administrer forespørsler om endringer i designet når utviklingen starter Fokuser innsatsen under distribusjonsaktiviteter (som opplæring og kom-

kommunikasjon til brukere om det nye nettstedet eller applikasjonen før og under lanseringen) Finn ut om du har møtt behovene til kundebedriften en gang

prosjektet er lansert Når du starter et nytt prosjekt, har du sannsynligvis prosjektmål fra prosjektets sponsor (bedriftens interessent som har direkte ansvar for at prosjektet lykkes), samt et sett med prosjektrelaterte forespørsler som kommer fra forretningsinteressenter og fra kunder, men de kan alle være litt uklare (Figur 4.1). Målet ditt er å tydeliggjøre disse til solide utsagn som du kan bruke som en målestokk for prosjektets suksess.

Prosjektrelaterte forespørsler

Selskapets strategi Fuzzy Mål

Brukerbehov interessenter idé

Fuzzy mål

Interessentidé for brukerklage

Figur 4.1 Uklare mål, ideer og behov

Et solid mål er lett å forstå. Unngå innsideterminologi. Distinkt. Unngå vage utsagn; bruk i stedet ordlyd som virker slik

vil være nyttig når du prioriterer krav. Målbare. Kom med konkrete utsagn om at du kan sette en uavhengig

måling mot for å bestemme din suksess. Når du definerer et uklart mål, gjør det klart og målbart, blir det et solid mål som du kan basere beslutninger på.

KAPITTEL 4: PROSJEKTMÅL OG TILNÆRING

Figur 4.2 Mål som fastsettes

Selskapets strategiprosjektmål

Du vil høre mange utsagn som kan betraktes som mål. Å analysere uklare slike som de nedenfor vil hjelpe deg med å styrke målene dine og kommunisere mer effektivt i prosjektteamet. Forretningsadvokat

"Vårt mål er å bli markedsleder i industri x."

Dette er et mål for hele selskapet, men er for bredt for et spesifikt prosjekt. Flere initiativer i selskapet må komme sammen for å få dette til; et hvilket som helst nettsted eller applikasjon kan hjelpe med dette, men det vil være svært usannsynlig å kunne håndtere hele byrden – med mindre hele selskapet handler om denne ene siden eller applikasjonen og det ender opp med å bli veldig vellykket. Forretningsadvokat

"Vårt mål er å skape begeistring blant kundebasen vår."

Denne er bedre, fordi et nettsted eller en applikasjon kan ha innvirkning på dette, men det er fortsatt for vagt. Hvorfor er det viktig å skape begeistring? Hvordan oversettes den spenningen til å møte et forretningsbehov? Og hvordan kan du vite om du har lykkes? Forretningsadvokat

"Vårt mål er å øke mengden trafikk på nettstedet vårt."

Nå kommer vi dit. Denne er lett å måle, men den er for fokusert på et mellomtrinn. Anta at du genererer mer trafikk: Det hjelper deg kanskje ikke hvis folk ikke utfører handlingene du vil når de kommer dit.

STYRK PROSJEKT MÅL

Uklare mål kan gi deg en følelse av kundens ønsker og større mål. Fra disse kan du lage mer solide prosjektmål, som å øke inntektene fra nettsalg med 10 prosent. Øk inntektene fra nettannonsering med 20 prosent. Øk antallet nåværende og potensielle kunder i vår kunde

database til minst 20 000. Lever høyt rangert og høyt referert innhold til våre primære brukere.

(Merk at denne krever litt arbeid for å bestemme hvordan man skal måle "høyt vurdert" og "høyt referert", men elementene er der å bygge fra.)

Hver av disse kan måles og påvirkes av prosjektet ditt. De kan også kartlegge ganske nært designene dine og funksjonene som tilbys. For eksempel er det veldig vanlig å tilby et elektronisk nyhetsbrev som en måte å nå et mål om å utvide kundedatabasen: For å levere nyhetsbrevet må du fange opp kundenes e-postadresser, som vil bli lagt til databasen. Mål kan også bringe frem nye krav. Hvis du for eksempel måler suksess ved gjennomsnittlig vurdering gitt til artikler på nettstedet ditt, trenger du en funksjon som lar brukere gi vurderinger. På disse måtene hjelper målene deg med å fokusere når du samler ideer til nettstedet, og disse kan senere bli prosjektkrav. Hvis det er flere mål, sørg for å lage en prioritert liste med bedriftens sponsor og prosjektteam. Mål er noen ganger i konflikt med hverandre under design, og teamet må vite hva som har forrang. Den endelige prioriterte listen over mål bør komme fra prosjektsponsoren din, men du kan være en sentral del av diskusjonen. La oss snakke om hvordan.

Hvordan kan en UX-designer hjelpe? Hvis du finner ut at prosjektmålene er uklare i begynnelsen av et prosjekt, kan du ta med deg tilretteleggingsferdighetene dine. Hjelp prosjektteamet til å forstå den forretningsrelaterte konteksten til prosjektet ved å holde en workshop med sentrale interessenter (se neste kapittel for mer om å identifisere de rette interessentene). Målet ditt i denne økten, som vanligvis varer to til fire timer, er å få frem informasjon om selskapets styrker, svakheter,

KAPITTEL 4: PROSJEKTMÅL OG TILNÆRING

muligheter og trusler. Kalt en SWOT-analyse, er dette en vanlig forretningsanalyseteknikk og en måte å diskutere en bedrifts posisjon i markedet på. Du kan også bruke denne tiden til å diskutere selskapets konkurranse. Forstå styrker og svakheter SW i en SWOT-analyse er selskapets nåværende styrker og svakheter når de gjelder prosjektet. Styrker og svakheter kan inkludere interne prosesser så vel som ytre oppfatninger – og ofte påvirker de hverandre. For eksempel kan et selskap med en stor forsknings- og utviklingsavdeling (FoU) ha tilgang til en stor kilde med original forskning som er publisert (en styrke), men det er kanskje ingen som hjelper til med å gjøre innholdet mer tilgjengelig for den gjennomsnittlige brukeren , som fører til oppfatningen om at selskapet er "for akademisk" (en svakhet). Identifiser muligheter og trusler OT er den fremtidsrettede halvdelen av SWOT. Med tanke på de tingene som skiller selskapet fra konkurrentene, hvilke fremtidige initiativer kan det ta som vil åpne opp en ny nisje eller styrke en nåværende? Hvilke situasjoner kan true disse planene? For eksempel kan vårt FoU-selskap bestemme seg for å ansette skribenter for å publisere mer tilgjengelige funksjonsartikler rundt sin opprinnelige forskning (en mulighet), men hvis det nåværende nettstedets verktøysett ikke har robuste innholdsstyringsfunksjoner, kan publiseringsprosessen være uoverkommelig treg. Det kan gi konkurrenter en sjanse til å svare raskere (en trussel). Sammenlign konkurrenter Hva er selskapets viktigste konkurranse? Hvem er konkurrentene for nettstedet som utvikles? De kan være forskjellige, spesielt for store selskaper eller helt nye nettsteder. Er det nettsteder som ikke er direkte konkurrenter, men som representerer interessante modeller å vurdere? Du kan lære mye av å gå gjennom andre e-handelssider for å se om og hvordan de selger det du selger. Pull It Together SWOT- og konkurrentdiskusjonene er gode temaer å diskutere samtidig fordi de samhandler med hverandre. Det er vanskelig å snakke om

STYRK PROSJEKT MÅL

fremtidige trusler uten å vite hvem konkurrentene dine er – og når du begynner å snakke om fremtidige muligheter, kan det dukke opp nye konkurrenter. Når du har et fullstendig bilde her av selskapets konkurrenter og SWOT, bør prosjektmålene dine – så vel som den overordnede tilpasningen til prosjektet ditt innenfor selskapets strategi – bli lettere å definere, og prioriteringene blant dem bør bli klare. Å solidisere prosjektmålene hjelper deg med å forstå forventningene til hva prosjektet skal oppnå. La oss deretter snakke om forventninger til hvordan prosjektet skal drives. Å forstå prosjekttilnærmingen vil hjelpe deg med å samarbeide effektivt og involvere de riktige personene til rett tid.

Forstå prosjekttilnærmingen Å kjenne den overordnede tilnærmingen, eller metodikken, til et prosjekt er en viktig del av å forstå når og hvordan du vil bli involvert og hvordan du bør involvere andre, for eksempel prosjektteamet og forretningsinteressenter. Noen ganger ser det ut til at det er like mange prosjekttilnærminger som det er prosjekter. Hvordan velge riktig tilnærming for et prosjekt er et stort tema i seg selv. Metoden du velger kan avhenge av mange ting, inkludert strukturen og plasseringen av prosjektteamet, teknologiene som brukes på prosjektet, og i hvilken grad samarbeid er en del av bedriftens kultur. I denne bokens formål antar vi at du har blitt med i et prosjekt der tilnærmingen i stor grad har blitt bestemt av de ansvarlige for prosjektets suksess, for eksempel prosjektsponsoren og prosjektlederen. I denne situasjonen vil hovedmålet ditt være å forstå tilnærmingen og bidra til å gjøre den effektiv for virksomhetens interessenter og brukerne dine. Her vil vi fokusere på to av de vanligste typene tilnærming, samt en tredje som viser en mulig variasjon du kan møte på et prosjekt. Det som er viktig å merke seg er at de fleste tilnærminger innebærer de samme trinnene: Planlegg den overordnede strategien, tilnærmingen og teamstrukturen. Deﬁner prosjektkravene. Design interaksjon og visuelle konsepter og utvikler dem til detaljerte

spesifikasjoner. Utvikle, test og avgrens løsningen.

KAPITTEL 4: PROSJEKTMÅL OG TILNÆRING

Distribuer løsningen via meldinger, opplæring og en planlagt lansering. Utvid prosjektet ved å komme med anbefalinger til forbedringer.

Navnene på disse trinnene kan variere, det samme kan i hvilken grad de overlapper og måten informasjon dokumenteres på. Men de generelle aktivitetene i hvert trinn er felles for de fleste prosjekter og for alle tre modellene som presenteres her.

Foss-tilnærming En foss-tilnærming innebærer å behandle trinnene i et prosjekt som separate, distinkte faser, der godkjenning av én fase er nødvendig før neste fase begynner. For eksempel starter ikke designfasen for alvor før krav er godkjent av virksomhetens interessenter, som signerer på ett eller flere kravdokumenter på slutten av Deﬁneringsfasen. Godkjenning

Plan

Godkjenning

Definer Design Utvik Deploy Utvid

Figur 4.3 Eksempel på en fossefallstilnærming, hvor hver fase «faller» inn i den neste

Problemet med en ren fossefallstilnærming er at den forutsetter at hver fase kan gjennomføres med minimale endringer i fasen før den. Så hvis du kommer med nye krav i Design-fasen, som er vanlig, må du foreslå endringer i dokumenter som ble godkjent på slutten av Deﬁner-fasen, noe som kan kaste ut planen og tidsplanen.

Agile tilnærminger Fordi endring er konstant, leter prosjektteam kontinuerlig etter mer fleksible tilnærminger enn fossefallsmodellen. Mange metoder følger en mer flytende tilnærming, med noen trinn som skjer ved siden av hverandre; for eksempel kan versjoner av nettstedet bli utgitt på en rask, iterativ tidsplan ved bruk av en smidig eller rask utviklingstilnærming. En smidig tilnærming har generelt større fokus på raskt samarbeid og redusert fokus på detaljert dokumentasjon og formell sign-off. FORSTÅ PROSJEKT-TILNÆRING

Iterasjon 1

Utvikle

Iterasjon 2

Utvikle

Iterasjon 3

Utvikle

Deploy Design Deploy Design Deploy Design Definer

Definer

Definer godkjenning

Plan

Distribuer utgivelsesutvidelse

Figur 4.4 Eksempel på en smidig tilnærming

En ekte smidig tilnærming (som følger beste praksis utviklet av medlemmer av Agile Alliance, for eksempel) krever små team der medlemmene befinner seg ved siden av hverandre fysisk, med lite fokus på å definere formelle roller mellom teammedlemmer. Å jobbe på denne måten tillater en svært høy grad av samarbeid, noe som reduserer behovet for tung dokumentasjon mellom stadier av design, utvikling og testing. Et teammedlem kan stille et spørsmål, komme til svaret sammen med andre teammedlemmer under en rask tavleøkt, og implementere en løsning uten forsinkelsen med detaljert dokumentasjon og godkjenning. Interessentgjennomganger skjer med et fullt fungerende system når en av de mange iterasjonene er utgitt, og de resulterende innspillene tas i betraktning når neste iterasjon planlegges. (Iterasjoner er utkastversjoner av et bestemt nettsted eller applikasjon.) Når en smidig tilnærming fungerer slik den er designet for, er det en vakker ting. Hos de fleste selskaper og innenfor de fleste konsulentoppdrag følger imidlertid team sjelden en ren smidig tilnærming. Delvis skyldes dette at bedrifter i økende grad bruker distribuerte team og fjernarbeidere, noe som gjør det vanskelig å opprettholde den høye graden av samarbeid som trengs for å utnytte den rene smidige tilnærmingen best mulig.

Modifiserte tilnærminger De fleste prosjekter prøver å følge en tilnærming som kombinerer det beste fra begge verdener, med nok struktur og dokumentasjon til å redusere risikoen ved distribuerte team og utskifting av teammedlemmer, men nok samarbeid og iterasjon til å svare på endringer på en relativt smidig måte . For eksempel kan et prosjekt følge en fossefallsmodell, men inkludere en overlapping i faser slik at det er viktige samarbeidspunkter fra lag til lag. Dette tillater

KAPITTEL 4: PROSJEKTMÅL OG TILNÆRING

potensielle endringer til overflaten tidligere i hver fase. Dette kan også inkludere en tidlig utgivelse (for eksempel en beta-utgivelse til en bestemt brukergruppe) med en kortere iterasjonssyklus. Tilbakemeldinger fra den utgivelsen kan deretter inkluderes før den fullstendige distribusjonen av det nye nettstedet. Plan

Definer

Utvikle design

Design

Definer

Utvikle Deploy Beta

Distribuer utgivelsesutvidelse

Figur 4.5 Modifisert foss med beta-utgivelse

Legg merke til de mindre iterasjonene i designfasen i figur 4.5. Det er en av de største verdiene du tilfører teamet ditt som UX-designer. Verktøy som wireframes (kapittel 11) og prototyper (kapittel 12) lar deg samle tilbakemeldinger på raske gjentakelser av ideer, før mye utviklingstid er lagt ned. En modifisert fossefallstilnærming som den i figur 4.5 er blant de mest populære vanlige metoder, så det er tilnærmingen som danner rammen for denne boken. Imidlertid vil mange av temaene som dekkes her gjelde for prosjektet ditt uavhengig av spesifikasjonene til tilnærmingen din, fordi de grunnleggende aktivitetene bak dem – for eksempel å definere og designe – fortsatt er nødvendige.

Deep Diving Hvis prosjektet ditt bruker en smidig tilnærming, vil du ha unike behov under kravinnsamling, for eksempel skriving av "brukerhistorier" som en måte å fange opp krav. Vi anbefaler User Stories Applied: For Agile Software Development av Mike Cohn (Addison-Wesley Professional, 2004).

FORSTÅ PROSJEKT-TILNÆRING

Hvordan påvirker tilnærmingen meg? Å kjenne tilnærmingen din hjelper deg å forstå en rekke ting: Hvilke spørsmål du bør stille, og når. For eksempel hvis du er

Når du arbeider med en ren fossefallstilnærming, må du anstrenge deg ekstra for å sikre at kravene i Deﬁneringsfasen inneholder all informasjonen du trenger for designfasen. (Vi skal diskutere krav i neste kapittel.) Forventninger til hvordan prosjektteammedlemmer vil samarbeide og hvordan

tett at samarbeidet blir. For eksempel krever en smidig tilnærming svært tett samarbeid. En fossefallstilnærming kan involvere individuelt arbeid mesteparten av tiden, med berøringspunkter en eller flere ganger i uken. Detaljnivået som trengs i dokumentasjonen og nivået på

formalitet. Dokumenter som sendes inn ved påmeldingspunkter må være formelle, nesten som juridiske kontrakter. Vanligvis trenger du mer formelle dokumenter i en fossefallstilnærming, der avmelding er nødvendig før du går videre til neste fase. Imidlertid kan du også ha noen formelle sign-off-dokumenter når du bruker en smidig tilnærming – for eksempel for å fange informasjon ved viktige beslutningspunkter, for eksempel når en bestemt iterasjon er forberedt for full utgivelse og distribusjon. Viktige milepæler som innebærer godkjenning fra interessenter og

distribusjon til ulike grupper. Tilnærmingen vil avgjøre hva ulike målgrupper trenger å gi på ulike punkter i prosjektet, inkludert godkjenninger fra interessenter ved sign-off-punkter og tilbakemeldinger fra potensielle brukere under en betaversjon. Nå som du har befestet prosjektmålene dine og fått en forståelse av prosjekttilnærmingen, starter vi i neste kapittel med hovedarbeidet i Deﬁnerfasen: å samle krav.

KAPITTEL 4: PROSJEKTMÅL OG TILNÆRING

Forretningskrav Kjenn problemet før du lager løsningen Innen prosjektteamet kommer sammen, har du sannsynligvis hørt, eller kommet opp med, mange ideer om hva som må gjøres. Det kan allerede være lister over funksjoner levert av noen fremtredende medlemmer av selskapet (bedriftens interessenter), sammen med deres meninger om hvilke funksjoner som er viktigst. Dette er elementer av forretningskravene til prosjektet, og de er en god start. For å sikre at du har en komplett løsning på slutten av prosjektet, må du generere og avklare krav fra flere synspunkter. I dette kapittelet vil vi fokusere på å samle inn og detaljere krav fra bedriftens interessenter. Carolyn Chandler

Kapittel 4 dekket uklare mål og diskuterte noen måter du kan hjelpe med å klargjøre for deg selv og prosjektteamet. I de tidlige stadiene av et prosjekt vil du sannsynligvis også ha et sett med forespørsler som er relativt uklare. Dette kan være ideer fra interessenter, brukerklager eller brukerforespørsler. For å gjøre disse nyttige og sporbare komponentene i prosjektet ditt, må du kombinere disse ideene til krav. Krav er erklæringer som definerer hva nettstedet eller applikasjonen må gjøre. Ideelt sett gir et forretningskrav innsikt i det overordnede behovet som må dekkes Representerer og konsoliderer behov levert av ulike interessenter. Gir retning for design, uten å være for spesifikt om hvordan det vil bli

fullført Fungerer som en distinkt arbeidsenhet for prioritering og sporing

Her er et eksempel på en idé for en funksjon på et e-handelsnettsted. Du kan motta den samme ideen fra et par forskjellige forretningsinteressenter tidlig i Deﬁneringsfasen: "Kunder kan spore bestillingene sine på nettet." Dette er et godt utgangspunkt for et krav, men det er uklart. Begynn å stille spørsmål som kommer til detaljene i kravet, for eksempel hvorfor er det viktig for virksomheten at kunder kan spore deres

bestillinger på nett? Er det for eksempel for å kutte ned på antall anrop til kundestøtte? Har selskapet for øyeblikket muligheten til å spore pakker på nettet?

Hvis ikke, må nye krav registreres for sporingsfunksjonene, eller selskapet må kanskje samarbeide med en tredjepart. Hvor nøyaktig må sporingen være? Hva slags informasjon

bør inkluderes i sporingsdetaljene? For eksempel, må nettstedet gi et oppdatert estimat for leveringstid? Å stille slike spørsmål vil hjelpe deg å kombinere uklare ideer til solide krav. Det vil også gjøre det tydelig at samme utsagn kan bety forskjellige ting for forskjellige mennesker.

KAPITTEL 5: VIRKSOMHETSKRAV

En interessent kan for eksempel tro at sporing av pakker innebærer å motta en bekreftelse på e-post med interessentidé med et sporingsnummer, som kan legges inn på UPS.com eller et annet nettsted slik at kundens interessent kan se det siste stoppet pakken har nådd. Idé En annen interessent tror kanskje at selskapet må presse konvolutten på pakkesporing og investere i å utvikle muligheten for kunder til å spore pakker via GPS, se den nøyaktige plasseringen i sanntid ved hjelp av et online kart. Som du kan forestille deg, er det en betydelig forskjell her i brukeropplevelse og omfang! Det er viktig å skissere disse forskjellene tidlig i prosjektet. Ellers vil du ende opp med å utvikle en løsning som går glipp av intensjonen til forretningsinteressenten – og som potensielt går glipp av prosjektmålene. Det fører til misfornøyde interessenter og, hvis funksjonen må redesignes, tapt tid og penger. Så klare og detaljerte krav er en sentral del av det totale prosjektet ditt. Å komme til en konsolidert liste over prosjektkrav innebærer følgende trinn: 1. Forstå den nåværende tilstanden til nettstedet eller dets konkurrenter. 2. Samle behov og ideer fra virksomhetens interessenter så vel som nåværende og potensielle brukere. (Se kapittel 6 for detaljer om å jobbe med brukere.) 3. Sammenslå ideer til krav. 4. Prioriter krav basert på prosjektmål. (Se kapittel 9 for forslag til prioritering.)

Forretnings- og brukerprosjektkrav Krav Bedriftsstrategi

Figur 5.1 Koaleser ideer fra virksomhetens interessenter til forretningskrav, og ideer fra forskning med brukere til brukerkrav. Bruk deretter prosjektmål til å fokusere prioriteringsinnsats og lage en konsolidert liste over prosjektkrav.

VIRKSOMHETSKRAV

Først, la oss snakke om å få en forståelse av den nåværende tilstanden til nettstedet ditt, slik at du har en kontekst for ideene som vil dukke opp under kravsamlingen.

Forstå gjeldende tilstand Når du dykker inn i spesifikasjonene til nettstedet eller applikasjonen du designer, er det viktig å jorde deg selv ved å forstå den nåværende tilstanden til nettstedet (hvis du redesigner en som allerede eksisterer) eller ved å forstå nøkkelkonkurrenter mer grundig (hvis du designer et nytt nettsted eller en ny applikasjon). Du kan lære mye om den nåværende tilstanden gjennom interessentintervjuer (mer om dette på noen få sider). Du kan også få mye forståelse på egenhånd, og dette kan tjene som en sterk base for interessentintervjuer og brukerforskningsinnsats. En fin måte å få bakgrunnsinformasjon og generere ideer som kan bli krav er å gjennomføre en heuristisk analyse.

Med et hvilket som helst annet navn... Ordet heuristisk betyr en tommelfingerregel eller beste praksis. En heuristisk analyse har kommet til å bety en gjennomgang av et produkt mot et sett med regler (heuristikk) for brukbart design, vanligvis utført av en UX-designer. Brukervennlige nettsteder vil følge de fleste eller alle heuristikkene du bruker i analysen din. Du kan også høre denne teknikken kalt en heuristisk evaluering, ekspertvurdering eller en kombinasjon av disse begrepene.

Heuristisk analyse En heuristisk analyse er en teknikk du kan bruke til å evaluere brukervennligheten til et eksisterende design, basert på beste praksis innenfor brukeropplevelsesfeltet. Du kan utføre en slik analyse på det gjeldende nettstedet i begynnelsen av et redesignprosjekt eller analysere konkurrerende nettsteder for å forstå mulighetene for å tilby en bedre brukeropplevelse enn andre selskaper. Resultatet er et dokument som beskriver styrker og svakheter ved siden, inkludert anbefalinger for forbedringer. Etter at den er fullført, vil du ha en dypere

KAPITTEL 5: VIRKSOMHETSKRAV

forståelse av det analyserte nettstedet og en liste over ideer for å bidra til kravene til det nye nettstedet. For eksempel er en vanlig brukt heuristikk denne, fra Jakob Nielsens liste over ti bruksheuristikk (se den fullstendige listen på Jakob Nielsens nettsted, på www.useit.com/papers/heuristic/heuristic_list.html):

Synlighet av systemstatus. Systemet skal alltid holde brukerne informert om hva som skjer, gjennom passende tilbakemeldinger innen rimelig tid.

Det er mange situasjoner på et nettsted der denne heuristikken kanskje ikke følges. La oss for eksempel si at brukeren klikker på en Last ned-knapp og ikke får noen melding om at filen hans blir lastet ned. Systemet har ikke informert brukeren om at filen er i ferd med å bli lastet ned, selv om nedlastingen har startet. Så brukeren kan klikke på knappen igjen, og tenke at han savnet knappen første gang...og deretter klikke igjen... Dette kan føre til flere nedlastinger – potensielt forårsake problemer for både ytelsen til nettstedet og brukeren, som nå har flere nedlastinger på gang uten å være klar over det. Under den heuristiske analysen kan du notere dette som et problemområde, beskrive det og vurdere virkningen. Du kan også dele en idé som kan løse problemet, som kan legges til kravlisten. Hvorfor utføre en heuristisk analyse? Å gjennomføre denne typen analyser er en relativt rask og rimelig måte å få tilbakemelding på et design på. En heuristisk analyse kan gi en generell forståelse av designkvaliteten og bidra til å identifisere potensielle designproblemer. Husk at denne aktiviteten ikke direkte involverer sluttbrukere og bør ikke være en erstatning for ekte brukerundersøkelser. For eksempel er det mulig at bare 50 prosent av dine heuristiske funn faktisk kan valideres av senere forskning. Analysen gir imidlertid teamet et godt grep om sannsynlige bekymringsområder. Hvis du jobber med å redesigne et eksisterende produkt eller nettsted, kan det også være bra for å identifisere åpenbare hurtigreparasjoner som kan føre til umiddelbare forbedringer ettersom redesignarbeidet fortsetter bak kulissene.

FORSTÅ DEN NÅVÆRENDE TILSTAND

Hvordan gjør jeg det? De spesifikke heuristikkene du bruker kan variere fra prosjekt til prosjekt, men prosessen for å gjennomføre analysen vil generelt forbli den samme: 1. Samle produkt- og prosjektbakgrunnskunnskap. Sørg for at du har målene for nettstedet, en liste over de viktigste brukergruppene som må støttes, informasjon om hva slags miljø brukerne sannsynligvis vil jobbe i, og en grunnleggende forståelse av all spesialkunnskap som brukerne sannsynligvis vil ha. ha. (Analysen din vil være annerledes for et nettsted bygget for generelle forbrukere enn et nettsted bygget for farmasøyter, for eksempel.) Hvis du trenger hjelp med den siste, kan besøk på en rekke konkurrerende nettsteder eller applikasjoner hjelpe deg med å forstå den vanligste terminologien og interesseområder. 2. Velg heuristikk som skal brukes. Det er mange heuristikker der ute å referere til. I tillegg til Jakob Nielsens liste, refererer mange UX-designere til Bruce Tognazzinis liste over designprinsipper: www.asktog.com/basics/rstPrinciples.html. Når du er kjent med emnet på nettstedet, kan det være lurt å legge til noen av dine egne - spesielt hvis du analyserer mer enn ett nettsted. Sørg for å holde listen til en håndterlig størrelse (for eksempel 8 til 12); for mange heuristikk kan gjøre teknikken uhåndterlig for deg og leserne dine. 3. Gå gjennom prioriterte områder på stedet, identifiser områder der heuristikkene følges godt eller savnes. Hver observasjon du gjør bør ha følgende informasjon: Den generelle observasjonen. En kort uttalelse som oppsummerer funnet. Ideelt sett vil disse være nummerert slik at du raskt kan referere til dem mens du leder folk gjennom rapporten. En kort beskrivelse. Et avsnitt eller to som beskriver konteksten til observasjonen – for eksempel punktet i en bestemt prosess hvor du la merke til et problem. En innvirkningsrangering. Denne vurderingen kan være høy, middels eller lav for observasjoner av problemer, eller den kan være et notat om et positivt funn hvis du deler noe som nettstedet gjorde bra. Generelt er problemer med stor innvirkning de du tror vil føre til at mange brukere mislykkes med en bestemt oppgave eller

KAPITTEL 5: VIRKSOMHETSKRAV

permanent miste informasjon (for eksempel et problem som får en bruker til å miste endringer i et dokument hun har jobbet med). Problemer med middels innvirkning er de som forårsaker frustrasjon og feil, men som ikke forårsaker irreversible problemer. Problemer med lav innvirkning er mindre problemer som kan forårsake litt forvirring, men som vanligvis ikke fører til tapt tid eller frustrasjon. Anbefalinger. Dette er neste trinn eller ideer som du deler, som kan tjene som en løsning på problemet du støtt på. Figur 5.2 viser et eksempel på disse elementene sammen, slik de kan vises i din heuristiske analyse. Observasjon #4 Søkefunksjonen ser ikke ut til å bringe tilbake alle mulige resultater.

HØY bekymring

En prøvetest av søkefunksjonen ga blandede resultater. Søk med et navn i et relativt nytt innlegg, med et mindre ofte dekket emne, ga noen ganger ingen resultater. Det ser også ut til at primærsøk bare returnerer lenker til nye historier, ikke videoer. Anbefalinger 1. Sørg for at nylig lagt til innhold er indeksert og søkbart før, eller kort tid etter, blir offentlig tilgjengelig. 2. Vurder å vise relatert innhold når søkeresultater bringes tilbake – for eksempel historier i lignende kategorier eller med lignende tagger – slik at brukere som utforsker har flere tråder å følge. 3. Vurder universelt søk som presenterer resultater organisert etter kategori. 4. Bruk søkeordlogger for å forstå gjenstander du ofte søker etter. Dette kan også gi innsikt i elementer som brukere har problemer med å finne.

Figur 5.2 En prøveobservasjon i en heuristisk analyserapport

4. Presenter funnene dine for prosjektteamet og primære interessenter. Gå dem gjennom dine observasjoner og anbefalinger. Diskuter hvorfor du ga vurderingene du gjorde. (Dette er også et flott tidspunkt å ha en forberedt anbefaling om hvordan du kan validere funnene dine, ved å bruke en av teknikkene som er diskutert i kapittel 6.) Hvordan hjelper en heuristisk analyse med kravsamling? Når du har fullført den heuristiske analysen din, vil du ha en dypere forståelse av den nåværende tilstanden til nettstedet (eller dets konkurrenter), og en liste over ideer som kan bidra til å samle krav. Du vil også ha noen ideer om hvordan du strukturerer emnene du må dekke under kravsamlingsøktene – noe som fører oss til neste trinn i denne prosessen.

FORSTÅ DEN NÅVÆRENDE TILSTAND

Samle ideer fra interessenter Som vi så i eksemplet vårt i begynnelsen av dette kapittelet, hvis du ikke får kontekst for en idé, for eksempel "Kunder kan spore bestillingene sine på nettet", risikerer du å gå glipp av forskjellene i forventninger mellom interessenter, som de av vår venn som vil at pakker skal spores med GPS. En av de vanligste feilene som gjøres i et prosjekt er å gripe en funksjon og kalle det et krav uten først å forstå problemet og forventningene rundt en løsning. Så hvorfor blir kravinnsamlingsprosessen forkortet så ofte? Å samle ideer – og samle dem til krav – kan ta ganske lang tid. Det er lett å undervurdere antall spørsmål du må stille for å skissere krav slik at de kan prioriteres. Og hvis prosessen ikke er godt strukturert eller deltakelsen er ufullstendig, kan det være mye churn som kan vare gjennom hele prosjektet. (Churn er bortkastet tid på ekstra møter og arbeidsiterasjoner forårsaket av mangel på kommunikasjon og involvering. Disse er forskjellige fra de mer produktive arbeidsiterasjonene som er en del av å designe og teste gyldige løsninger i et forsøk på å finne den beste.) Så hvordan gjør man oppmuntrer du til en velbalansert kravprosess som er fokusert på forretningsbehov, men som unngår å være en pirrende tidssukker? Her er noen trinn for en effektiv prosess: 1. Skisser roller og ansvar. Sørg for at medlemmer av prosjektteamet forstår rollene de bør fylle etter hvert som kravene samles. 2. Samle de rette interessentene, i de riktige gruppene, for å sikre at tiden brukes på best måte under kravfokuserte intervjuer eller møter. 3. Lag en plan for møtene, inkludert temaer som skal dekkes og spørsmål som skal stilles under møtene. 4. Kjør møtene effektivt, fange ideer og få avklaringer. Undersøk ideer for å grave ned til behovene bak hver enkelt. Når møtene dine er ferdige, ikke glem å takke de involverte interessentene og holde dem oppdatert om fremdriften når du flytter til en konsolidert, prioritert liste. La oss undersøke hvert av disse trinnene mer detaljert.

KAPITTEL 5: VIRKSOMHETSKRAV

Skissere ansvar Handlingen med å samle forretningskrav innebærer vanligvis at medlemmer av prosjektteamet intervjuer viktige forretningsinteressenter for å samle ideer. Forretningsinteressenter er de i selskapet som har en forretningsorientert eierandel i prosjektets suksess eller har fagkompetanse å bidra med, eller begge deler. Disse menneskene er ikke med på prosjektet på heltid, men de må være involvert på nøkkelpunkter i prosessen, og kravinnsamling er ett av disse punktene. Husk at de også har dagjobber (så å si), så tiden deres er verdifull og ofte vanskelig å få, med mindre du planlegger på forhånd. Prosjektsponsoren (eller sponsorene) er forretningsinteressenten som også har direkte ansvar for at prosjektet lykkes, ofte på et relativt høyt nivå i selskapet, for eksempel direktør. Han eller hun vil ikke være med i prosjektet på daglig basis i hele prosjektets livssyklus, men vil sannsynligvis være aktivt involvert i kravinnsamling og sikre et høyt nivå av deltakelse fra forretningsinteressenter. Sponsoren kan også delta på noen eller alle økter. Prosjektteamet inkluderer personer som er offisielt tildelt prosjektet som pågående ressurser. De kan være involvert som prosjektleder, UX-designer, forretningsanalytiker, teknisk leder, visuell designer, leder for kvalitetssikring og så videre. Avhengig av størrelsen på prosjektet kan dette være deres primære jobb. Innenfor selve prosjektgruppen er ansvar under kravinnsamling ofte uklart. Å ta seg tid til å definere ansvar tidlig vil bidra til å sikre en effektiv innsamlingsprosess. Her er noen spørsmål å stille når du bestemmer det spesifikke ansvaret hvert teammedlem skal påta seg under kravinnsamlingen: Hvem er hovedansvarlig for å samle inn og planlegge riktig virksomhet.

ness interessenter i de mest produktive gruppene? Dette kan inkludere både interne og eksterne interessenter (som partnere, leverandører og så videre). Hvem lager strukturen for emner og spørsmål for virksomheten-

holdermøter? Dette er en flott samarbeidsøvelse for teamet, hvis tiden tillater det. Hovedtilretteleggeren kan deretter arrangere dem i en struktur som flyter godt i et møte. Hvem legger til rette for møtene? Hvem tar notater, og hvordan deles de?

SAMLE IDÉER FRA INTERESSENTER

Hvem følger opp med hvem etterpå? Vil noen fra teknologiteamet være tilstede på alle møtene?

Hvis ja, hvordan er den personen involvert (lytter de, gir innspill eller noe annet)? Som UX-designer, uansett om du er hovedansvarlig for ett eller flere av disse områdene, har du viktige ferdigheter å ta med i prosessen. Å lage en struktur for emner og spørsmål krever evner til tydelig kategorisering (noe som høres ut som en god crossover med informasjonsarkitektur), og selvfølgelig er tilretteleggingsevner viktige for å holde møtet ved temaet, med deltakelse fra alle deltakere.

Samle de rette interessentene Hovedformålet med å intervjue interessenter er å få en forståelse av relevante prosjektrelaterte ideer, behov, kunnskap og frustrasjoner fra ulike synsvinkler, som deretter kan inngå i prosjektkravene. Det er også den noen ganger ubeskrivelige fordelen ved å involvere mange forskjellige grupper, slik at hver enkelt føler at den har sagt sitt i prosjektet – og som et resultat vil kjøpe seg inn i den endelige løsningen. Selv om det å involvere folk for å få deres buy-in kan virke mer politisk enn praktisk, er det ofte et nøkkeltrinn som setter deg i kontakt med et nettverk som vil støtte deg gjennom hele prosjektet. Det kan også hjelpe deg å unngå endringer i ellevte time, som kan oppstå når noen du ikke snakket med tar opp et problem sent i prosessen. Så det er ofte en god idé å involvere et stort utvalg mennesker. På den annen side må tidsplaner og budsjetter huskes. Å involvere et stort antall mennesker tar tid, fra deres ståsted og fra ditt ståsted, for møtene alene – for ikke å snakke om tiden med å sortere gjennom notater for å identifisere trender og konsolidere oppsigelser. For effektivitet og din egen fornuft er det fornuftig å prioritere gruppene å snakke med og velge nøkkelpersoner fra disse gruppene til å tjene som tankeledere for teamet deres. Hvem er mulige interessenter du kan involvere? Disse gruppene er ofte gode kilder for ideer: Grupper med initiativ som er avhengig av nettstedet (for eksempel de med

markedsføringskampanjer som må ha informasjon presentert på nettstedet)

KAPITTEL 5: VIRKSOMHETSKRAV

Grupper som trenger å støtte prosessene rett bak siden eller

applikasjon, for eksempel å gi innhold, legge inn og administrere data, og svare umiddelbart på informasjon som samles inn. Frontlinjen til kundeservice, for eksempel telefon- eller onlinesupport eller

alle som handler med kunder ansikt til ansikt (for eksempel på et butikksted eller via leveranser) Salg, produktadministrasjon eller konsulenttjenester for å representere

produkter og tjenester som presenteres Menneskelige ressurser, for å nå rekrutteringsmål PR, for å presentere informasjon til investorer og media Eventuelle grupper som er ansvarlige for andre relasjoner som må utvikles

som en del av prosjektet, og som vil påvirke utformingen, for eksempel forhold til partnere eller leverandører. Når du velger de personene som skal inkluderes, kan du få hjelp fra prosjektsponsoren din og eventuelle prosjektteammedlemmer som er kjent med de involverte gruppene til å velge den rette mennesker. Lag grupper som vil få en god diskusjon i gang. Det er ingen riktig måte å gjøre dette på, men en vanlig måte er å gruppere interessenter etter avdeling, som dette: Markedsføring (fem personer) Produktledelse (fire personer) Kundestøtte (to personer) Salg (fire personer)

Et mindre prosjekt kan inkludere én person fra hver av disse gruppene, i en serie med to eller flere samarbeidsøkter der alle møtes. Når du har dine interessenter i tankene, samt en generell struktur for møtene (diskutert i neste avsnitt), kan du begynne å planlegge møtene. Prøv å begynne å planlegge minst et par uker på forhånd; det kan være vanskelig å få alle sammen i et rom.

SAMLE IDÉER FRA INTERESSENTER

Lag en plan for møtene Parallelt med din innsats for å velge de riktige interessentene, sett sammen en liste over emner som skal dekkes og spørsmål som må stilles (dette vil også hjelpe deg med å avgrense listen over interessenter). Du bør ha en annen plan for hver gruppe du møter, selv om flere av spørsmålene dine kan være de samme fra gruppe til gruppe. Du må også bestemme deg for detaljnivået du sikter på i møtene. Hvis du møter et stort antall mennesker bare én gang (for eksempel medlemmer av forskjellige avdelinger, som foreslått ovenfor), vil du gjerne samle ideer, men du vil sannsynligvis ikke bruke for mye tid på å dykke ned i grove detaljer under møtet. I så fall, hvis en av interessentene dine gir deg ideen «Kunder kan spore bestillingene sine på nettet», kan det være lurt å spørre hvorfor denne funksjonen er viktig og om interessenten kan tenke direkte på et nettsted som gjør dette bra. Disse spørsmålene bør bidra til å få frem de store forskjellene mellom interessentenes forventninger til funksjonen uten å bruke hele møtet på én uttalelse. Du kan deretter utarbeide de spesifikke detaljene for ideen med prosjektteamet, sirkle tilbake med interessenten for å sikre at kravene du genererte fortsatt representerer hans eller hennes opprinnelige idé. La oss si at du redesigner en e-handelsside og møter et stort utvalg av interessenter, og holder ett møte med hver gruppe. Her er et eksempel på en plan for møte med en gruppe fra en salgsavdeling.

Salg: Krav-samling Møtedeltakere Innesalg: Jenny Bee, Tracy Kim, Joseph Arnold Lead Management: Kevin Abernathy, Cat Parnell Tidsramme: 2 timer Mål: Forstå gjeldende salgsprosess og identifisere problemer og muligheter for hvordan nettet kan støtte bedre den prosessen. Bakgrunn: Vi har gjennomgått en PowerPoint-presentasjon om kjøpsprosessen, som ga en god bakgrunn for hvordan kjøpsbeslutninger tas. Vi planlegger også å snakke med kundeserviceteamet.

KAPITTEL 5: VIRKSOMHETSKRAV

Salg: Krav-Innsamling Møte fortsetter Spørsmål Salgsprosess: Hvordan er salgsprosessen forskjellig for ulike produktlinjer? Er det regionale forskjeller? Er noen forskjeller basert på kundestørrelse (f.eks. små selskaper versus store selskaper)? Hvordan har denne prosessen utviklet seg de siste to årene, og hvordan forventes den å utvikle seg i løpet av de neste tre til fem årene? Hvordan forstår en potensiell kunde alle tingene som må kjøpes og hvordan de fungerer sammen?

Helhetsinntrykk: Hvem tror du er de primære besøkende på det nåværende nettstedet? Hvorfor? Hvordan er de? Hva prøver de å oppnå på siden? Hvordan bidrar nettet til salgsprosessen og/eller salgsnedleggelsesraten i dag? Hvilken informasjon trenger kundene for å ta en kjøpsbeslutning? Er denne informasjonen tilgjengelig på nettstedet i dag? Er det lett å finne? Er det nøyaktig? Hvor vanskelig er det å opprettholde innhold på nettstedet i dag? Hvilke beregninger får du fra nettstedet? Hvilke ekstra beregninger vil du finne verdifulle? Hvorfor?

Ser for deg fremtiden: Når du tenker på et fremtidig nettsted, hva kan vi gjøre for å støtte salgsprosessen bedre? Hvilke nåværende funksjoner og funksjoner på nettstedet er kritiske for salg? Hva er ikke nødvendig? Hva mangler?

Sammendrag: Er det noen andre tanker, forslag eller bekymringer som vi ikke har tatt tak i? Hvilke nettsteder synes du gjør en utmerket jobb med å støtte salg? Hva er den viktigste tingen selskapet kan gjøre for å forbedre kundetilfredsheten?

SAMLE IDÉER FRA INTERESSENTER

Kjør møtene effektivt Her er noen fremgangsmåter som vil hjelpe deg med kravsamlingsmøter. Sørg for at et delt ordforråd brukes Mye forvirring kan unngås hvis teamsamlingskravene blir enige om en felles liste over termer og definisjoner. Vil for eksempel personene som bruker systemet bli kalt brukere, kunder eller klienter? Er folk mer kjent med begrepet interaksjonsdesigner eller informasjonsarkitekt? For å unngå forvirring, bruk litt tid i begynnelsen av hvert møte for å angi hvilket begrep som brukes og hva det betyr. Du kan også ha nytte av å lage noen visuelle elementer som hjelper til med å forklare sammenhenger mellom ulike termer eller roller (se figur 5.3). Kategori

Kategori

Underkategori

Emne

Artikkel

Figur 5.3 Diagram som viser prosjektledd og sammenhenger

Et felles vokabular for leveransene som skal brukes i prosjektet vil også hjelpe interessenter til å forstå prosessen og typen produksjon de kan forvente å se. Dette kan bygge tillit til at deres tid og innsats ikke kommer til å gå inn i et svart hull av ideer. Vanligvis, hvis du finner deg selv i å definere de samme ordene mer enn én eller to ganger (spesielt hvis du finner ut at definisjonene endres subtilt hver gang), bør du vurdere å sette dem inn i en prosjektordliste og dele den med prosjektteamet. Andre eksempler på terminologi det er greit å rydde opp i i starten av prosjektet inkluderer

KAPITTEL 5: VIRKSOMHETSKRAV

Roller som vil samhandle (for eksempel jobbsøker versus klient eller kon-

teltprodusent versus redaktør) Primære leveranser som vil bli referert til (funksjonelle spesifikasjoner)

sjon, wireframes, nettstedskart) og en kort beskrivelse av hvordan de skiller seg. Distinksjoner mellom ulike nivåer av informasjon (som vår kategori

informasjon i figur 5.3) Skille mellom behov og ideer

Lytt til ideer og grav ned etter behov Interessenter kan komme med uttalelser som ser ut til å være behov. Tenk på et eksempel. Forretningsadvokat

"Vi trenger en blogg på siden."

Dette er egentlig en idé, ikke et behov. Hvis bloggfunksjonaliteten da er ferdig designet og implementert, blir det en løsning, men det er ikke nødvendigvis den løsningen som best dekker kjernebehovet til interessentene som ber om det. Ved å spørre hvorfor en blogg er viktig, kan du få en lang rekke behovsuttalelser, for eksempel «Vi må fremstå som relevante og i kontakt. Alle snakker om blogger, og jeg føler at vi vil ligge bak tiden hvis vi ikke inkluderer dem.» "Vi trenger en måte å få folk til å komme til nettstedet gjentatte ganger for å generere mer annonseinntekter, og blogger betyr nylig publisert innhold med følgere." "Vi må posisjonere oss som tankeledere, og blogger er en mer personlig måte å vise vår ekspertise på." "Vi må ha en bedre måte å kommunisere og innovere med kundene våre, og blogger får oss kommentarer slik at vi kan høre deres tanker." Hver av disse utsagnene beskriver gyldige behov. Ved å bringe dem ut, vil du lære om driverne bak forespørsler om bestemte funksjoner, som vil hjelpe deg å bygge konsensus når du konsoliderer og prioriterer krav.

SAMLE IDÉER FRA INTERESSENTER

Koalescerende krav Når møtene er over, ta ideene du har samlet og sorter dem i generelle funksjonsområder. Du vil begynne å legge merke til mange overlappinger; dette er et godt tegn på at en bestemt idé har mye støtte fra interessentene dine. Fjern redundanser og prøv å konsolidere en liste med ideer som effektivt fanger intensjonene til interessentene dine. For å gjøre ideene du har samlet til nyttige og sporbare komponenter i prosjektet ditt, må du kombinere disse ideene til krav. Tenk på regndråper som dannes fra en sky: Du beveger deg fra en stor og udefinert sky til et større antall veldefinerte regndråper. Så når du får en idésky som «Kunder kan spore bestillingene sine på nettet», må du konvertere den til distinkte utsagn som definerer hva systemet må gjøre. De resulterende kravene skal gi innsikt i det overordnede behovet som må dekkes. Representere og konsolidere behov levert av ulike interessenter. Gi retning for design, uten å være for spesifikt om hvordan det vil bli

fullført Tjen som en distinkt arbeidsenhet for prioritering og sporing

Når du begynner å gå fra ideer til krav, sørg for at den tekniske lederen din (eller en annen person som kan representere utviklingsteamet i prosjektet ditt) er involvert for å stille spørsmålene som vil hjelpe til med å anslå innsatsen som kreves når du prioriterer senere. Hvis du har et dedikert medlem av kvalitetssikringsteamet, kan denne personen også gi noen gode detaljerte spørsmål for å hjelpe til med å samle kravene. For å detaljere sporingsideen i krav, still spørsmål som Hvor nøyaktig må sporingen være? Hva slags informasjon skal inkluderes i sporingsdetaljene; til

må vi for eksempel gi et oppdatert estimat for leveringstid? Slike spørsmål kan stilles og utdypes med interessentene som ga deg den opprinnelige ideen, hvis de har mye tid dedikert til prosjektet. Hvis du ikke har så mye tilgang til disse interessentene, kan du finne ut detaljene selv ved å ha diskusjoner i prosjektgruppen

KAPITTEL 5: VIRKSOMHETSKRAV

og deretter gjennomgå kravene med prosjektsponsoren din for å sikre at valgene dine gir mening for virksomheten. Tabell 5.1 viser hvilke typer krav som kan smelte sammen fra sporingsideen og hvordan du kan fange dem. TABELL 5.1

Et eksempel på forretningskrav

OMRÅDE

Ordresporing

KRAV

VIRKSOMHETENS BEHOV

Bestillinger kan spores av

Oppmuntre til selvbetjening

angi en sporingskode

under levering (Support

på nett

fordel)

Brukere kan spore pakken deres-

Vis innovasjon innen effi-

alder med GPS, følge lastebiler

cient levering (Konkurransedyktig

eller fly

fordel)

Brukere kan se alle tidligere bestillinger Oppmuntre til ombestilling og gjort i løpet av de siste 365 dagene

selvbetjening (salg, støttefordeler)

Legg merke til at kravene i noen tilfeller overlapper hverandre, som i tilfellet med de to første kravene i tabellen – begge er metoder for sporing. De kan bo sammen i samme system fordi du kan taste inn en kode for å finne pakken din gjennom GPS-visningen. De er imidlertid atskilt fordi det GPS-relaterte kravet sannsynligvis er en større innsats og bør prioriteres uavhengig av de andre funksjonene. Når du konsoliderer erklæringene, legg merke til forretningskravene du tror kan komme i konflikt med brukerbehov. Et forretningskrav kan for eksempel være å samle inn personlig informasjon fra potensielle kunder, for eksempel deres e-postadresser. Men kunder kan ha forbehold om å gi informasjon. Tross alt tar det tid å fylle ut skjemaer, sikkerhet og personvern er en bekymring, og dette trinnet kan forstyrre den større oppgaven de prøver å oppnå. Når du identifiserer konflikter som disse, vil de begynne å gi deg ideer som kan hjelpe deg med å møte både forretnings- og brukerbehov. For sporingseksemplet kan du foreslå å bruke en "Send til en venn"-funksjon for å fange opp e-postadressen og gi brukeren en bekvemmelighet. Dette betyr at Send til en venn kan bli et krav du legger i miksen for prioritering. Ideer som dette

SAMLE IDÉER FRA INTERESSENTER

man kan bidra til å møte både forretnings- og brukerkrav, så de er flotte å fange opp. De bor også i det overlappende området mellom Deﬁnerings- og Designfasene (se kapittel 4), fordi du begynner å tenke på designløsninger på forretningsproblemer.

Definer designutvikling Potensielle konflikter mellom forretnings- og brukerbehov er gode ting å utforske under brukerundersøkelser, som vi vil diskutere i neste kapittel. Brukerundersøkelser vil også tillate deg å utvide tabell 5.1 til et komplett sett med potensielle krav, som vil bli prioritert i en liste over prosjektkrav (vist i figur 5.1, og diskutert videre i kapittel 9). Husk at innhenting av forretningskrav vanligvis skjer parallelt med utforskning av tekniske muligheter og innhenting av brukerkrav. Neste opp: på tide å snakke om brukere!

KAPITTEL 5: VIRKSOMHETSKRAV

Brukerforskning Bli kjent med gjestene du inviterer til festen Det er mange brukerforskningsteknikker som kan brukes gjennom hele prosjektets livssyklus, enten for å bedre forstå brukerne dine eller for å teste ut deres oppførsel på versjoner av et nettsted. Dette kapittelet vil fokusere på noen av metodene som er mest brukt i begynnelsen av prosjektet. Disse teknikkene vil hjelpe deg med å definere brukergruppene som bør ha høyest prioritet i løpet av prosjektet, sette deres behov og frustrasjoner i sammenheng, og vurdere ytelsen til det nåværende nettstedet (hvis en finnes) ved å bruke beste praksis innen design av brukeropplevelse . Carolyn Chandler

Grunnleggende trinn for brukerundersøkelse 1. Definer dine primære brukergrupper. Dette innebærer å lage et rammeverk som beskriver hovedtypene brukere du designer for – slik at du kan fokusere innsatsen på å rekruttere brukere til forskning. 2. Plan for brukerinvolvering. Dette inkluderer å velge en eller flere teknikker for å involvere brukergrupper i forskning, basert på behovene til prosjektet ditt. 3. Gjennomfør forskningen. Vi vil dekke de grunnleggende teknikkene her, for eksempel intervjuer og undersøkelser, og gi tips om hvordan du kan gå frem. 4. Bekreft brukergruppedefinisjonene. Ved å bruke det du har lært fra forskningen, kan du styrke brukergruppemodellen din. Denne modellen vil da fungere som en plattform for utvikling av mer detaljerte verktøy, som for eksempel personas (diskutert i kapittel 7). 5. Generer brukerkrav. Dette er uttalelser om funksjonene og funksjonene som nettstedet kan inneholde. Du legger til disse utsagnene til forretningskravene dine (diskutert i kapittel 5) og prioriterer dem til å bli prosjektkrav (diskutert i kapittel 9). Dette kapittelet vil dekke de tre første trinnene, og starter med det første: å definere brukergruppene dine.

Definer brukergruppene dine Planlegging av brukerundersøkelser i begynnelsen av et prosjekt kan føles som et kylling-eller-egg-dilemma (hvilket kommer først?). Hvordan sørger du for at du snakker med de rette menneskene, hvis du ennå ikke vet hvem de trenger å være? En måte å komme i gang på er å lage en innledende eller foreløpig definisjon av brukerne du skal designe for. Dette beskriver nettstedets primære brukergrupper, som kan hjelpe deg med å fokusere forskningsinnsatsen din for de riktige rollene, demografien eller andre variabler som kan ha innvirkning på hvordan brukerne vil oppleve nettstedet ditt. Brukergruppedefinisjoner kan være på høyt nivå (en liste som definerer hver av målbrukergruppene dine) eller detaljerte og visuelle (et diagram som viser flere typer brukere, samt hvordan de samhandler med hverandre).

KAPITTEL 6: BRUKERFORSKNING

En definisjon på høyt nivå for et selskaps primære .com-nettsted kan inkludere følgende brukergrupper: potensielle kjøpere, nåværende kjøpere, partnere og jobbsøkere Når du begynner å definere grupper for brukerundersøkelser, vil du begynne å prioritere brukergrupper mer detaljert. Dine første definisjoner er basert på den kollektive kunnskapen til forretningsinteressenter og prosjektteammedlemmer angående potensielle typer brukere som kan samhandle med nettstedet. Disse definisjonene kan bygges ved å samle noen av målene og egenskapene som ulike brukergrupper kan ha. Her er de grunnleggende trinnene for å definere brukergruppene dine: 1. Lag en liste over attributter som vil hjelpe deg med å definere de forskjellige brukerne på nettstedet ditt (neste seksjon vil dekke noen av de vanligste). 2. Diskuter attributtene med de ved bedriften som har kontakt med relevante typer brukere (for eksempel kunder). 3. Prioriter attributtene som ser ut til å ha størst innvirkning på hvorfor og hvordan en potensiell bruker vil bruke nettstedet eller applikasjonen din. 4. Definer brukergruppene du vil fokusere på i forskning og design. De neste avsnittene tar en nærmere titt på noen idédugnadsteknikker for å hjelpe deg med å samle disse attributtene og hvordan du kan prioritere og modellere dem (lage representasjoner av de forskjellige brukertypene som vil hjelpe deg å fokusere forskningsinnsatsen din).

Lag en liste over attributter En god start for attributtlisten din er å samle og absorbere all forskning eller annen dokumentasjon organisasjonen har som kan gi veiledning med hensyn til brukere. Her er noen potensielle kilder: Dokumenter som forklarer selskapets strategier, for eksempel selskapets mål, kom-

petitiv informasjon, markedsføringsstrategier og forretningsplaner Markedssegmenteringer av nåværende kunder og andre demografiske data

samlet av markedsavdelingen. Tidligere utført brukerundersøkelser (se tabell 6.1 for noen eksempler)

DEFINER DINE BRUKERGRUPPER

Undersøkelser, som brukertilfredshetsundersøkelser og tilbakemeldingsskjemaer Kundeservicerapporter som dekker ofte forekommende problemer

Deretter identifiserer du personer i organisasjonen som har innsikt i nåværende eller potensielle brukere. Antall og variasjon av personer du bør inkludere avhenger av typen prosjekt og omfanget og tidslinjen. Hvis du vet at den første definisjonen av brukergruppene dine kan ha en kort levetid (for eksempel er den i bruk i bare en måned eller to mens brukerundersøkelser planlegges), kan du inkludere bare to eller tre deltakere. Hvis du tror den første definisjonen kan trenge å holde deg gjennom en god del av designprosessen (for eksempel hvis du bare har denne å jobbe med til du gjennomfører brukervennlighetstesting, etter at noe design er utført), inkluderer flere deltakere og sikre at du har et tverrsnitt av perspektiver. Noen mulige deltakere inkluderer markedsføringsmedarbeidere som er ansvarlige for merkevarerepresentasjon, segmentering og kampanjer; selgere; produktledere; kundeservice eller støtterepresentanter; og trenere. Det er også bra å inkludere prosjektteamledelse og andre forretningsinteressenter i denne øvelsen. Be gruppen tenke på de ulike typene potensielle brukere de pleier å samhandle med. Be dem så liste opp noen av de vanlige egenskapene de har møtt. Her er noen eksempler på hva som kan variere: Primære mål, ettersom de er relatert til emnet på nettstedet ditt. Hvorfor er

brukere som kommer til det, og hva prøver de å oppnå? For eksempel, å kjøpe en vare, handle en aksje eller få svar på et spesifikt spørsmål er vanlige mål. Roller. Dette kan defineres på mange måter, men en måte er å knytte roller til

brukerens primære mål: jobbsøker, støttesøker, potensiell klient og så videre. Når du har mer brukerinformasjon, kan roller deles inn etter ulike behov eller stiler; for eksempel på en e-handelsside kan kjøpere inkludere røverkjøpere og kjennere. Demografi, inkludert alder, kjønn, familie (single, gift, barn),

inntektsnivå og region. Erfaring inkludert utdanningsnivå, kjennskapsnivå med relevant

teknologier (ofte referert til som teknisk kunnskapsrike), nivå av fagkompetanse og bruksfrekvens (engangs, sporadisk, hyppig). 88

KAPITTEL 6: BRUKERFORSKNING

Organisatoriske attributter, inkludert størrelsen på bedriftens brukere arbeider

for, deres avdeling, type jobb (inngangsnivå, frilanser, mellomleder, leder), ansettelse (langsiktig eller høy turnover?), og arbeidsmønstre (fjernarbeid, mengde reiser). Når du har en liste over noen av egenskapene som dukker opp oftest når interessenter beskriver potensielle brukere, kan du begynne å prioritere dem etter deres viktighetsnivå og deretter bruke det hierarkiet til å begynne å definere og modellere brukergrupper.

Prioriter og definer Hvilke av egenskapene som er oppført ovenfor tror du har størst innflytelse på hvordan og hvorfor ulike brukergrupper kan bruke nettstedet? Fokuser på de du tror vil ha størst innvirkning på en brukers mål eller atferd. Prioriter disse egenskapene, og husk målene du opprettet i kapittel 4 – de vil også hjelpe deg med å gjøre valgene dine. Et eksempel illustrerer best hvordan du prioriterer attributter. La oss si at du jobber med et selskap som tilbyr verktøy for online handel med aksjer, opsjoner og futures. Dette bestemte selskapet har bestemt at en del av strategien vil være å engasjere ikke-profesjonelle som handler aksjer på egen hånd, på nettet, og å oppmuntre dem til å prøve å handle nye typer produkter som opsjoner og futures. Selskapet planlegger å gjøre dette ved å tilby handelsverktøy som er enkle å bruke og målrettet mot de som ønsker praktisk læring i et trygt miljø. Når du diskuterer attributter med forretningsinteressenter, kan du finne ut at følgende ser ut til å ha størst innvirkning på hvordan enkeltpersoner kan bruke disse verktøyene: Nåværende handelsfrekvens, nærmere bestemt hyppigheten av direkte netthandel.

ing (for eksempel en gang i kvartalet, en gang om dagen, flere ganger om dagen). De som bare driver med handel (for eksempel en gang i måneden) er kanskje ikke seriøse med å prøve noe nytt, mens de som allerede handler på heltid kanskje ikke finner mye verdi i verktøy rettet mot nyere handelsmenn. Men de som er aktive deltidshandlere kan ha en sterk interesse for selskapets verktøy. Antall produkttyper som handles: bare aksjer eller aksjer, opsjoner og

futures. De som allerede handler alle typer produkter kan allerede ha en preferanse for sine egne verktøy, men de som bare handler med én type kan være klare til å forgrene seg til andre. DEFINER DINE BRUKERGRUPPER

Nivå av fagkompetanse (for eksempel kjennskap til handel

vilkår). Dette vil bidra til å avgjøre hvor mye hjelp de trenger underveis, med opplæringsprogrammer og ordlister. Nivå av teknisk kunnskap (for eksempel kjennskap til å foreta kjøp

nett- og nettbank og handel). Dette vil påvirke hvor mye trygghet de trenger om personvern for informasjon og hvor avansert eller enkelt det elektroniske grensesnittet må være. Du kan prioritere disse attributtene fordi de kan påvirke brukertypene du vil målrette mot for forskning. Hvis hvor handelsmenn bor ikke ser ut til å ha en reell innvirkning på hvordan eller hvorfor de handler, kan Region-attributtet falle av listen som en vurdering for forskningsdeltakere. På den annen side, hvis viktigheten av en bestemt egenskap vekker mye diskusjon, kan det være et godt emne for et spørreundersøkelsesspørsmål eller intervjuspørsmål (vi skal diskutere undersøkelser senere i dette kapittelet).

Høy

Sammenligning av to eller flere attributter kan hjelpe deg med å prioritere også. Hvis du for eksempel lager et diagram med to attributter for netthandlere, kan du begynne å se hvordan grupper faller innenfor noen av områdene. Figur 6.1 er et eksempel på en grov brukermodell du kan lage ved å bruke de to attributtene Frekvens for direkte handel og antall omsatte produkttyper; den viser også de resulterende brukergruppene som kan dannes ut av diskusjonen.

Heltidsansatte produktspesialister

Erfarne generalister på heltid

Hyppighet av direkte handel

"Andre jobb"-handlere

Traders med tilleggsinntekt

Aktive utforskere

Langsiktige investorer

Lav

Dabblers

Lav

Høy

Antall produkttyper som handles (aksjer, opsjoner, futures)

KAPITTEL 6: BRUKERFORSKNING

Figur 6.1 Et diagram med to attributter, som representerer en grov brukermodell. Å lage denne modellen i samarbeid kan lette diskusjon om potensielle forskjeller i brukermotivasjon og opplevelse.

Denne brukermodellen gir en måte å diskutere ulike brukertyper på på høyt nivå. Det er ikke ment å være den endelige modellen, og det merker ikke brukergrupper utelukkende (en bruker kan være en langsiktig investor i aksjer og også aktivt utforske andre muligheter i opsjoner eller futures). Men det begynner å uttrykke din forståelse av ulike brukergrupper og hvordan de kan være motivert til å bruke nettstedet ditt. Denne diskusjonen om viktige attributter hjelper deg også med å finne ut hvilke du vil fokusere på når du rekrutterer brukere til forskning. Hvis du fastslår at handelsfrekvens er viktig, og at prioriteringen vil være å engasjere de som for øyeblikket har et middels frekvensnivå, vil du definere hva middels frekvens betyr (for eksempel én til tre ganger i uken) og rekruttere forskningsdeltakerne dine deretter. Når vi snakker om forskning, la oss snakke om teknikker du kan bruke for å involvere brukere i prosjektet ditt.

Kan du designe fra brukermodeller alene? Det er debatt innenfor brukeropplevelsesfeltet om å lage brukermodeller før forskning utføres, fordi det kan farge tankegangen din før du har reelle brukerdata, og fordi prosjektteamet eller prosjektsponsoren kan se modellen som en erstatning for brukerforskning. Å bruke en uvalidert modell introduserer mer risiko for at antakelsene dine blir feil. I prosjekter hvor du ikke har noen kontakt med brukere i det hele tatt, er en gjennomtenkt modell (verifisert med kilder utenfor prosjektteamet, for eksempel en kundeservicegruppe eller opplæringsgruppe) bedre enn å ikke ha noen modell å bruke under design.

Velge forskningsteknikker Nå som du har en grov ide om brukergruppene du vil inkludere, er det på tide å planlegge neste trinn: dine anbefalinger for mengden og typen brukerforskningsaktiviteter som skal utføres i løpet av prosjektet. Tabell 6.1 presenterer litt informasjon om de mest brukte forskningsteknikkene og når de ofte er mest nyttige. Bruk denne tabellen som referanse for å hjelpe deg med å velge hvilke som passer best for prosjektet ditt. Den neste delen beskriver hver teknikk mer detaljert.

VELG FORSKNINGSTEKNIKK

TABELL 6.1

Vanlige brukerforskningsteknikker

AKTIVITET

HVA DET ER

NÅR DET ER NYTTIG

UTFORDRINGER

TYPISK TIDSRAMME *

Brukerintervjuer

En en-til-en samtale med en deltaker som tilhører en av nettstedets primære brukergrupper.

Det er tilgang til brukere, men typen tilgang (personlig, via telefon osv.) varierer.

Får klare meninger. Det kan være vanskelig å samle informasjon om holdninger og kontekst, spesielt hvis intervjuer gjennomføres eksternt.

2–4 uker for 12 intervjuer: Opptil en uke å planlegge, 1–2 uker til intervju og opptil en uke for å kompilere resultater.

Kontekstuell forespørsel

Et besøk på stedet med deltakere for å observere og lære om hvordan de jobber i sitt vanlige hverdagsmiljø.

Prosjektgruppen Å få tilgang til har få informasjonsdeltakere. Går på målbrukere. til brukernes miljø kan øke. Brukere arbeider i et unikt miljø bekymringer om sikkerhet, intellektuell (f.eks. et sykehus). eiendom, og inntrengende brukere jobber siveness. For virksomheter med ganske komplekse applikasjoner, er det oppgaver eller arbeidsflyter. kan være lettere å besøke på en arbeidsdag.

3–4 uker for 12 henvendelser: 1 uke til å planlegge, 1–2 uker til å observere, 1 uke til å analysere og rapportere resultater.

Undersøkelser

En serie spørsmål som hovedsakelig består av lukkede svar (flervalg) som brukes til å identifisere mønstre blant et stort antall mennesker.

Du vil oppgi resultater i mer kvantitative termer (f.eks. "80 % av målbrukergruppen sa at de aldri kjøper biler på nettet").

3–4 uker for en korttidsundersøkelse: 1 uke til å planlegge og skrive undersøkelsen, 1–2 uker til å kjøre undersøkelsen, 1 uke til å analysere og rapportere resultater.

Du ønsker å få kontekst, men kan ikke gå til brukeren.

Du er mer interessert i å samle informasjon om preferanser enn faktisk ytelse.

KAPITTEL 6: BRUKERFORSKNING

Få en passende prøve. Sørg for at spørsmålene er velskrevet slik at du får nøyaktige svar uten å lede respondentene til et bestemt svar.

TABELL 6.1

Vanlige brukerforskningsteknikker (fortsatt)

AKTIVITET

HVA DET ER

NÅR DET ER NYTTIG

UTFORDRINGER

TYPISK TIDSRAMME *

Fokus gruppe

En gruppediskusjon der en moderator leder deltakerne gjennom spørsmål om et spesifikt emne. Fokuserer på å avdekke deltakernes følelser, holdninger og ideer om emnet.

Teamet tror at brukernes holdninger vil ha stor innflytelse på deres bruk av løsningen (f.eks. hvis det har vært problemer med den historisk sett).

Forstå hvordan du målretter spørsmålene dine for å få ut riktig informasjon.

3–4 uker: 1 uke til å planlegge og skrive spørsmål, 1–2 uker til å gjennomføre fokusgrupper, 1–2 uker til å analysere og rapportere resultater.

Sortering av kort

Deltakerne får gjenstander (som emner) på kort og blir bedt om å sortere dem i grupper som er meningsfulle for dem.

Du jobber med et innholdskildenettsted med mange elementer og ønsker en effektiv struktur for brukergruppene dine.

Bestemme hvilke emner som er best å inkludere.

3–4 uker: 1 uke til å planlegge og forberede, 1 uke til å utføre forskning, 1–2 uker til å analysere og rapportere resultater.

Brukbarhetstesting

Brukere prøver å utføre typiske oppgaver på et nettsted eller en applikasjon mens en tilrettelegger observerer og, i noen tilfeller, stiller spørsmål for å forstå brukernes oppførsel.

En eksisterende løsning er under forbedring.

Velge passende oppgaver å fokusere på.

3–4 uker for 10 brukere og middels formalitet: 1 uke til å planlegge og skrive oppgavene, 1 uke til å kjøre testene, 1–2 uker til å analysere og rapportere resultater.

Konkurransedyktige løsninger er tilgjengelige for testing. Du har en prototype som lar brukere fullføre (eller simulere) oppgaver.

Tilrettelegge gruppen effektivt.

Bestemme hvor formell testen skal utføres.

* Typisk tidsramme representerer tiden som ofte trengs fra det tidspunktet brukerne er planlagt. Det forutsettes to grupper på seks til åtte brukere (bortsett fra undersøkelser, hvor antall brukere bør være større). Dette inkluderer ikke tid for rekruttering, som kan ta en til to uker etter opprettelse av screeningsspørreskjemaet.

Hvor mange forskningsaktiviteter kan jeg inkludere? Før du velger blant aktivitetene, spør deg selv hvor mye penger og tid teamet kan dedikere til brukerforskning. Vurder følgende situasjoner for å forstå hvor stor appetitt kundebedriften din har på brukerundersøkelser. Hvis prosjektledelse og prosjektsponsorer er komfortable med brukerforskning og er interessert i å bruke den til kjente mål, for eksempel å sikre at nettstedet oppfyller spesifikke prosjektmål, vil du sannsynligvis ha større spillerom TIL Å VELGE FORSKNINGSTEKNIKK

i planlegging for to eller flere aktiviteter, eller for én aktivitet som du gjennomfører flere ganger (for eksempel testing av et design, endre det basert på resultatene og testing av det nye designet på nytt). Hvis ingen i organisasjonen er kjent med brukerforskning og det er en viss motstand mot det, kan det være bedre å foreslå en runde med forskning og velge den teknikken du tror vil gi mest verdi for deg, prosjektteamet og virksomhetens interessenter. Når du har resultatene av forskningen, vil prosjektteamet ha en bedre ide om hva som er involvert og hvordan prosjektet kan dra nytte av det. Du vil da ha gode argumenter for å inkludere mer forskning senere, hvis nødvendig. Hvis du har plass til minst to runder med forskning, er en god tilnærming å inkludere én runde under Deﬁneringsfasen, eller tidlig i Designfasen, for å bedre forstå brukerne. Ta deretter med en runde til før utviklingen starter, for å validere designet. For en oppgavebasert applikasjon kan du for eksempel gjennomføre brukerintervjuer før du designer og deretter utføre brukervennlighetstesting på en prototype senere i prosessen. Eller for en innholdskilde kan du starte med kontekstuell forespørsel og deretter inkludere en kortsorteringsøvelse.

Hensyn når du planlegger forskning Når du planlegger for forskningsteknikker, bør du vurdere følgende: Hvorfor du utfører forskningen: hva du ønsker å lære av den Hvem du inkluderer: de primære brukergruppene du skisserte ovenfor Hvordan du får deltakere: rekruttere folk til å delta og screene dem (det vil si stille spørsmål for å sikre at de faller inn i brukergruppene du målretter mot) Hvordan du vil kompensere deltakerne Hvilken plass og utstyr du trenger Hva du dekker: hovedemnene Hvordan du fanger informasjon: antall involverte personer og verktøyene de bruker Kapittel 13 vil dekke hver av disse vurderingene som en del av en detaljert titt på en av de vanligste teknikkene som brukes av UX-designere: brukervennlighetstesting.

KAPITTEL 6: BRUKERFORSKNING

Merk Se kapittel 2 for mer om oppgavebaserte applikasjoner og innholdskilder.

Surfing Steve Baty skrev en artikkel som beskrev ulike metoder og hvordan du kan velge blant dem basert på utviklingsfasen, informasjonsbehovene dine og fleksibiliteten du har for å innlemme brukerforskning. Den har tittelen "Bite-Sized UX Research," av Steve Baty, UXmatters: http://uxmatters.com/MT/archives/000287.php.

La oss se nærmere på hver av disse teknikkene og måtene de ofte brukes på.

Brukerintervjuer Brukerintervjuer er strukturerte samtaler med nåværende eller potensielle brukere av nettstedet ditt. Disse kan utføres over telefon, personlig på et nøytralt sted (som et konferanserom), eller ideelt sett i miljøet der brukeren sannsynligvis vil bruke nettstedet. (Denne siste situasjonen er også flott for å gjennomføre en kontekstuell undersøkelse, dekket nedenfor.) Intervjuer hjelper deg med å forstå deltakernes preferanser og holdninger, men de bør ikke brukes til å komme med formelle uttalelser om faktisk ytelse. Hvis du leter etter spesifikk informasjon om hvordan folk samhandler med et nettsted, er det bedre å observere at de bruker det (for eksempel i en kontekstuell forespørsel) eller be dem utføre oppgaver på nettstedet (under brukervennlighetstesting). Nettstedsanalyse kan også gi deg litt innsikt i noe ytelsesinformasjon som kan være spesielt sterk når den er parret med intervjuer eller henvendelser som gir kontekst for dataene. Grunnprosessen For brukerintervjuer lager UX-designeren en liste med spørsmål som tar sikte på å få frem informasjon som følgende: Relevant erfaring med nettstedet eller med emnet

VELG FORSKNINGSTEKNIKK

Selskapets merkevare, slik det oppleves av deltakerens holdninger, for eksempel til fagkategoriene som dekkes (for en kon-

teltkilde), prosessen som utformes (for en oppgavebasert applikasjon), eller markedsføringsmetoder (for en markedsføringskampanje) Vanlige mål eller behov som driver brukere til nettstedet ditt eller

konkurrent Vanlige neste skritt brukere tar etter å ha besøkt selskapets nettsted Andre personer som er involvert i opplevelsen. Gjør for eksempel en

bruker en tendens til å samarbeide med noen andre som en del av det større målet de prøver å oppnå? Er det sannsynlig at de deler informasjon eller spør andres meninger underveis? All annen informasjon som vil hjelpe deg med å validere forutsetningene du har

gjort om brukergrupper frem til dette punktet – for eksempel om variablene du diskuterte da du opprettet en provisorisk brukermodell virkelig ser ut til å påvirke måten brukerne opplever nettstedet ditt. Hvis mer enn én person gjennomfører intervjuer, er det en god idé å ha en satt liste med spørsmål og en introduksjon med manus som kan brukes til å opprettholde konsistens på tvers av intervjuer. Velg på forhånd hvor strukturert du vil at intervjuene skal være. Hvis du går for en formell rapport, vil du sannsynligvis ha en høy grad av struktur, der spørsmålsrekkefølgen ikke varierer mye og hvert spørsmål stilles, med få tillegg. Hvis rikdom av data er viktigere enn konsistens, kan du velge å velge semistrukturerte intervjuer, der du starter med en liste med spørsmål, men lar samtalen følge en naturlig vei, hvor intervjueren stiller spørsmål for å utforske interessante kommentarer (kalt sondering) ). Lengden på intervjuet ditt kan variere; 45 til 60 minutter er ofte den beste banen å skyte etter. Det gir deg nok tid til å bygge en rapport og dekke et bredt spekter av spørsmål uten å trette deltakeren din. Brukerintervjuer gir et rikt sett med data som du kan bruke til å skrive personas, som er dekket i kapittel 7.

KAPITTEL 6: BRUKERFORSKNING

Intervjutips Kvaliteten på informasjonen du får ut av et intervju har mye å gjøre med kvaliteten på spørsmålene du stiller. Fokuser på deltakernes personlige opplevelser. Ikke be dem spekulere i hva de kan gjøre i fremtiden eller hva andre kan gjøre. Denne typen informasjon forutsier sjelden hva de faktisk vil gjøre. Ikke still spørsmål som innebærer et spesifikt svar eller leder en deltaker i en positiv eller negativ retning. Ideelt sett er spørsmål enkle, nøytrale og åpne. Noen eksempler på ledende spørsmål er Hva liker du med PseudoCorporation.com?

Dette forutsetter at brukeren liker å bruke nettstedet. Bruk dette spørsmålet bare hvis du også spør hva de misliker med det. Oppfyller PseudoCorporation.com dine forventninger?

Dette kan besvares med et enkelt ja eller nei, som ikke gir deg mye detaljer for å hjelpe deg med designarbeidet. Vil du heller bruke PseudoCorporation.com eller CompetitorVille.com

og hvis sistnevnte, hvorfor tror du de er bedre enn Pseudo? Dette har et par problemer: Det stiller to spørsmål i en uttalelse, og det tvinger deltakeren en underforstått mening. Bedre spørsmål å stille er disse: Fortell meg om ditt siste besøk på PseudoCorporation.com. Hvorfor gikk du dit? Hva husker du fra besøket ditt?

Hvis du gjør et større, mer formelt sett med intervjuer, kan det være lurt å inkludere noen flervalgsspørsmål. For det meste gir disse deg imidlertid ikke veldig rik informasjon. De kan være vanskelige for deltakerne å følge når de blir spurt muntlig, og de tillater ikke brukere å utdype dem. Generelt, lagre den typen spørsmål for screeners eller for undersøkelser. Utfør en testkjøring med noen, kanskje noen i organisasjonen som ikke er medlem av kjerneteamet. Dette vil hjelpe deg med å finne spørsmål som kanskje ikke er klare, og vil også hjelpe deg med å avgrense timingen og flyten. Hvis det er mulig, og deltakeren samtykker til det, ta opp intervjuet slik at andre kan ha nytte av å høre svar rett fra deltakerens munn.

VELG FORSKNINGSTEKNIKK

Kontekstuell undersøkelse Kontekstuell undersøkelse kombinerer brukerobservasjon med intervjuteknikker. UX-designeren går til deltakerne, ideelt sett til miljøene der de sannsynligvis vil bruke nettstedet. For en kontorapplikasjon vil kontekstuell forespørsel for eksempel innebære å sitte ved deltakerens skrivebord. Denne metoden gir deg rik informasjon om konteksten en deltaker arbeider innenfor, inkludert de virkelige problemene brukere står overfor. Hva slags utstyr de jobber med Rommet de jobber innenfor – spesielt hvor mye plass de jobber med

har, hvor mye (eller lite) privatliv, hvor ofte de blir avbrutt, og hvordan de bruker telefonen og papiret (vær spesielt oppmerksom på utskrifter de har lagt ut eller notater de har tilgjengelig). Deres preferanse i å bruke en mus kontra tastatur. Dette kan påvirke i stor grad

designvalgene dine, spesielt hvis du designer et verktøy som krever mye dataregistrering. Hvordan de jobber med andre, både når det gjelder samarbeid og deling

ing ressurser. Hvis mer enn én person bruker samme datamaskin, for eksempel, vil det påvirke hvordan du designer påloggings- og sikkerhetsfunksjoner. Andre verktøy de bruker, både online og utenfor. Hvordan folk bruker papir er

spesielt interessant – for noen oppgaver kan det være vanskelig å designe en nettløsning som konkurrerer med papir! Forespørsler kombinerer observasjonstid og intervjutid. De kan vare alt fra noen timer til flere dager. Hvis deltakerne ikke kan dedikere minst 2 timer, bør du vurdere å bare utføre et intervju. Under en observasjon tar det litt tid før deltakeren tilpasser seg din tilstedeværelse og oppfører seg litt naturlig, og dette skjer ikke etter bare 15 minutter. Grunnprosessen Forbered en 10- til 15-minutters introduksjon du kan bruke med hver deltaker. Den bør inkludere hensikten med henvendelsen, en beskrivelse på høyt nivå av hva dere skal gjøre sammen (observasjonen og intervjuet), og hvordan de 98

KAPITTEL 6: BRUKERFORSKNING

informasjon vil bli brukt. Dette er også et godt tidspunkt å få signaturer på samtykkeskjemaer og for å forsikre deltakerne om at det de deler vil bli holdt konfidensielt. Begynn med noen spørsmål på høyt nivå om deltakerens typiske prosesser, spesielt de som er relevante for utformingen av nettstedet. Gi deltakeren beskjed når du er klar til å slutte å snakke og begynne å observere. Observasjon kan variere fra aktiv til passiv. Ved aktiv observasjon er en vanlig tilnærming å la deltakeren ta rollen som mester mens du tar på deg rollen som lærling. Mesteren forklarer hva han gjør som om han lærte deg prosessen hans. Aktiv observasjon gir deg ofte mer bakgrunn om årsakene til deltakerens oppførsel, men det kan påvirke hvordan deltakeren jobber. Ved passiv observasjon oppfordrer du deltakeren til å oppføre seg som om du ikke engang er der. Målet ditt er å observere atferd som er så naturlig som mulig. For eksempel, hvis en deltaker snakker til deg, kan det være mindre sannsynlig at hun tar en samtale eller går og spør noen et spørsmål om et problem hun prøver å løse, men hvis du observerer passivt, er det mer sannsynlig at du ser dette skje. Du kan deretter følge opp under intervjudelen for å spørre om årsakene bak noen av atferdene du observerte. Begge tilnærmingene kan fungere bra. Generelt, hvis du ikke har mye tid med deltakere (la oss si, bare 2 til 4 timer hver), kan du bestemme deg for å bruke aktiv observasjon for å sikre at du får den dybden av informasjon du trenger. Hvis du har en hel dag eller mer, gir passiv observasjon en god balanse mellom naturlig atferd og diskusjon. Når du først har fått informasjon fra henvendelsene dine, vil du ha mye rik data å sortere gjennom! Så hvordan identifiserer du mønstre eller trender i resultatene dine? En måte som er nyttig er en teknikk som kalles affinitetsdiagrammer. Det er mange gode ressurser tilgjengelig om dette emnet, men her er en kort beskrivelse. En hurtigveiledning til tilhørighetsdiagrammer Affinitetsdiagrammer er teknikken for å ta en rekke distinkte og separate elementer (som utsagn fra brukere eller observasjoner gjort av en forsker) og gruppere dem sammen for å danne mønstre og trender. Her er trinnene som er involvert i en enkel tilhørighetsdiagramsøkt: 1. Samle teamet som utførte forespørslene, med notatene deres.

VELG FORSKNINGSTEKNIKK

2. Gi hver person en pakke med Post-it-lapper og be dem skrive en erklæring på hver enkelt, sammen med en kort kode som lar deg spore setningen tilbake til en deltaker, for eksempel initialene deres. Fokuser på utsagn som ser ut til å ha relevans for nettstedets design, enten spesifikt (en funksjonserklæring) eller på en mer generell måte (en uttalelse som representerer deltakerens holdning til selskapet eller emnet). 3. La alle sette post-itsene sine opp på veggen. Du trenger en stor tom vegg hvis du jobber med store studier; prøv å få en som du vil ha tilgang til i minst et par dager. 4. Når alle notatene er oppe, begynn å gruppere lignende utsagn ved siden av hverandre. Denne delen av øvelsen kan inkludere det større laget. Det er en fin måte å begynne å dele resultater på. 5. Når grupper begynner å dannes naturlig, begynner du å merke gruppene for å gi ytterligere struktur. Hvis noen Post-its tilhører mer enn én gruppe, kan du skrive duplikater og plassere dem i hver passende gruppe. Merk Denne metoden fungerer godt for kontekstuell undersøkelse, men kan brukes i mange andre situasjoner. For eksempel er det en fin måte å samarbeide om å lage kategorier for usorterte emner, slik at det kan hjelpe deg med å flytte kortsorteringsresultater til flere strukturnivåer.

Mønstre kan dukke opp på mange måter, så det er best å la dem danne seg selv. Her er imidlertid eksempler på typene kategorier du kan se, inkludert hva slags utsagn du finner i dem: Mål: «Jeg prøver å fjerne alle åpne gjenstander her før jeg drar for dagen.» Mentale modeller (inkluderer utsagn som viser hvordan brukere er

kartlegge eksterne erfaringer til intern tenkning): «Jeg bruker dette nettbaserte verktøyet som koffert, for ting jeg refererer mye til, men ikke vil ha med meg.» Ideer og funksjonsforespørsler: «Jeg skulle ønske dette ville tillate meg å angre. jeg beholder

flytte hele mappen ved et uhell, og det tar meg en evighet å kansellere ut av den." Frustrasjoner: «Jeg ville spurt brukerstøtten om dette, men halvparten av tiden gjør de ikke det

vet hva problemet er heller."

100

KAPITTEL 6: BRUKERFORSKNING

Løsninger: "Dette tar så lang tid å gjøre her at jeg bare ender opp med å skrive ut

listen og jobbe med den gjennom dagen. Så på slutten av dagen legger jeg inn resultatene.» Verdisetninger: «Dette verktøyet her sparer meg for mye tid, så hvis du

endringer tar det ikke bort!»

Deep Diving Den essensielle ressursen for kontekstuell undersøkelse er Contextual Design, av Hugh Beyer og Karen Holtzblatt (Morgan Kaufmann, 1997). Boken inneholder også detaljert informasjon om tolkning av resultater gjennom teknikker som tilhørighetsdiagrammer. For mer informasjon om mentale modeller og hvordan du kan forstå dem, ta en titt på Mental Models: Justing Design Strategy with User Behavior, av Indi Young (Rosenfeld Media, 2008). Dette er spesielt nyttig når du jobber med informasjonsarkitekturen for en innholdskilde.

Undersøkelser Undersøkelser involverer en sett samling av veldefinerte spørsmål distribuert til et stort publikum. De består oftest av lukkede spørsmål (som flervalgsspørsmål) som enkelt kan samles inn med et verktøy som kan vise mønstre blant svar. Undersøkelser er gode verktøy når du ønsker å kunne angi resultater på mer kvantitative måter (for eksempel «Av de spurte, 82 prosent av de som jobber hjemmefra oppgir at de har en eller annen form for høyhastighets Internett-tilkobling») enn du ville gjort. få med den typen åpne spørsmål som brukes i intervjuer. Men du kan også samle kvalitativ informasjon fra dem, om brukervaner og holdninger. I brukeropplevelsesfeltet brukes undersøkelser ofte for å måle brukertilfredshet (med eksisterende nettsteder eller applikasjoner) eller for å bygge eller validere brukermodeller som segmenteringer eller personas.

VELG FORSKNINGSTEKNIKK

101

Grunnprosessen Som med brukerintervjuer, ønsker du ikke å stille spørsmål som krever at brukere spekulerer. Ikke spør "Hvis du fikk Feature X, ville du brukt den?" I motsetning til med intervjuer, i undersøkelser multiple choice eller Ja/Nei, er Sant/False-spørsmål best og enklest å analysere i etterkant. De er også raskere for deltakerne å svare. Bruk spørreundersøkelser når du har spørsmål som er faktiske forespørsler om demografiske data, for eksempel disse: Av enhetene som er oppført nedenfor, hvilke eier du personlig? Velg alt som passer. Datamaskin Mobiltelefon Spillsystem, for eksempel Xbox, Playstation eller Wii

eller for spørsmål som er holdningsmessige med en rekke forskjellige valg: Les følgende utsagn og velg i hvilken grad du er enig eller uenig med hver av dem. Kundeservicen hos Pseudo Corporation er lydhør for mine behov. Helt enig Enig Verken enig eller uenig Uenig Helt uenig

Spesielt blir spørsmål som det andre eksemplet ofte brukt for å supplere brukertestingsoppgaver. Du kan bruke denne typen som et oppfølgingsspørsmål for å finne ut om deltakerne var frustrerte da de fullførte en oppgave. Deltakerne liker ikke alltid å si en negativ mening høyt, men de er ofte villige til å uttrykke en når de står overfor et rangeringssystem. Dette får frem et annet poeng: Undersøkelser er et utmerket supplement til andre former for forskning du kan gjøre, for eksempel brukerintervjuer eller kontekstuelle undersøkelser. Å kombinere to forskningsmetoder gir et rikere bilde av brukeren enn en metode kan gi alene.

102

KAPITTEL 6: BRUKERFORSKNING

Surfing Hvis du ønsker høy grad av tillit til resultatene og har budsjett til det, finnes det formelle verktøy tilgjengelig for å måle brukertilfredshet med hensyn til brukervennlighet. Disse verktøyene inkluderer spørsmål som har blitt testet for å sikre at de ikke leder eller forvirrer et bredt publikum. Noen av de mest brukte er ACSI (American Customer Satisfaction Index): www.theacsi.org/ WAMMI (Website Analysis and MeasureMent Inventory): www.wammi.com SUMI (Software Usability Measurement Inventory): http://sumi.ucc .dvs

Når du planlegger en undersøkelse, bør du vurdere følgende: Hvem retter du mot?

Bruk din foreløpige modell for å bestemme dette. Det vil utgjøre en forskjell i hvordan du svarer på resten av spørsmålene her. Hvilken metode for å distribuere undersøkelsen vil gi deg de beste resultatene?

Hvis de primære brukergruppene har en tendens til å samles på et bestemt sted, kan du få flere resultater hvis du går dit og setter opp en tabell der folk kan fylle ut undersøkelsen på papir. Hvis brukergruppene dine er aktive Internett-brukere, kan det å ha en nettbasert spørreundersøkelse være det beste valget for et stort antall deltakere. Eller du kan bestemme at brukergruppen din vil bli best funnet med telefonundersøkelser ved å bruke en liste over nåværende kunder. Hvor mye tid vil deltakerne sannsynligvis være villige til å bruke på å fylle ut

undersøkelsen? Hvis du gir en form for kompensasjon eller de får en annen fordel ved å fylle den ut, kan du vanligvis lage et lengre spørreskjema – et som tar kanskje en halvtime å fylle ut. Hvis ikke, må du holde den kort for å sikre at folk fullfører den - tenk 5 til 10 minutter. Uansett, sørg for at deltakerne får et estimat på hvor lang tid det vil ta, og oppdater dem om fremgangen deres mens de går gjennom det (bruk for eksempel sidetall som "2 av 4", eller vis prosentandelen fullført).

VELG FORSKNINGSTEKNIKK

103

Hvordan vil du vite når du skal begynne å analysere dataene?

Du kan velge å kjøre undersøkelsen til du når et visst antall deltakere eller til du når en viss tidsfrist, avhengig av hva som prioriteres. Hvilket verktøy vil du bruke for å samle inn og analysere dataene?

Hvis du kjører undersøkelsen på nettet, kan verktøyet du bruker til å samle inn dataene ha alternativer for å se og analysere resultatene. Hvis ikke, trenger du en metode for å legge inn dataene i verktøyet du velger. For papirbaserte undersøkelser betyr dette mye dataregistrering, så vær sikker på at du planlegger for den tiden.

Fokusgrupper Fokusgrupper innebærer å bringe sammen en rekke mennesker innenfor en målgruppe og legge til rette for en diskusjon med dem. Vanlige mål er å få frem meninger om emner som er relevante for organisasjonen eller dens merkevare, som tidligere erfaringer, relaterte behov, følelser, holdninger og ideer til forbedring. En fokusgruppe er en god teknikk for flere formål: Å høre en rekke brukerhistorier. Åpen diskusjon er en fin måte å bringe

ut historiefortelleren i oss alle. Når en fokusgruppe går bra, bygger individer på hverandres historier og ideer og husker situasjoner de kanskje ikke i et mer strukturert en-til-en-intervju. Gruppeformatet og energien kan gi folk den tiden de trenger til å huske disse historiene og dele dem. Forstå relevante forskjeller i erfaringer. De fleste er na-

ural informasjonsdelere og ønsker å sammenligne favorittverktøy med andre i interessegruppen deres. Ofte kan du lære om konkurrerende nettsteder eller tjenester, eller du vil høre tips om løsninger, ressurser og støtte. Generer ideer. Selv om du ikke vil gjøre selve gruppen til

designer, får du ofte noen gode ideer til nye funksjoner eller design, enten direkte fra gruppen eller fra å høre om arbeidsprosessene eller frustrasjonene deres. Som med interessentideer, sørg for å spore disse tilbake til kjernebehovet (se kapittel 4) slik at du kan være sikker på at det blir løst. Forstå flere punkter i en samarbeidsprosess. Hvis du er

utforming av en prosess som involverer flere relaterte roller og samarbeid, kan grupper være en fin måte for deg å fylle hullene i din forståelse

104

KAPITTEL 6: BRUKERFORSKNING

hvordan folk samhandler. Hvis du for eksempel jobber med en innholdskilde som et intranett, kan det være nyttig å samle en blanding av de som genererer innholdet, redigerer innholdet og bruker innholdet for å identifisere punktene hvor prosessen kan forbedres. Det er mye debatt om bruken av fokusgrupper i UX-forskning. Det er ikke en god teknikk for å teste brukervennlighet (siden brukere oftest jobber individuelt, i stedet for i grupper), og noen ganger kan gruppeinnstillingen på urimelig måte påvirke deltakernes uttalelser. Hvis de planlegges og tilrettelegges godt, kan imidlertid fokusgrupper få frem mange innsikter som vil være verdifulle for deg mens du designer. Kapittel 13 diskuterer dette videre i sammenheng med konsepttesting. Den grunnleggende prosessen Når du skriver spørsmål til fokusgrupper, bør du vurdere de samme tipsene du ville brukt for å skrive spørsmål til brukerintervjuer (dekket tidligere). Begynn med noen av de enklere spørsmålene, for eksempel "Fortell meg om ditt siste besøk på PseudoCorporation.com. Hvorfor gikk du dit?" Lagre spørsmål som er fokusert på idégenerering i den midtre delen av gruppen, når deltakerne føler seg komfortable med deg, hverandre og emnet. Tildel tidsblokker til hvert emne og hold deg til dem; det er lett for diskusjoner å virkelig komme i gang og at tiden slipper forbi! Hvis du er bekymret for tid, stiller du de viktigste spørsmålene dine midt på emnelisten, etter at folk har varmet seg opp til aktiviteten, men før noen potensielle tidsklemme som kan oppstå mot slutten. Mye av logistikken for fokusgrupper vil være den samme som for brukervennlighetstesting. (Kapittel 13 gir forslag om screening, rekruttering og planlegging.) Den primære forskjellen med fokusgrupper er at du trenger et større rom med et bord slik at deltakerne enkelt kan samhandle med hverandre. Ta bilder for seks til åtte personer per 1- til 2-timers gruppeøkt. Gi hver person et navneskilt eller et stedskort ved sin plass, slik at alle kan tiltale hverandre ved navn. Formatet på selve diskusjonen bør inkludere en introduksjon, som ofte treffer disse nøkkelpunktene: Din rolle som moderator, og hva du forventer å få ut av dis-

cussion (for eksempel noen av punktene ovenfor).

VELG FORSKNINGSTEKNIKK

105

Hvorfor deltakere ble valgt til å delta (for eksempel "Dere er alle

nåværende brukere av Pseudo Corporation-nettstedet, og vi har samlet deg for å finne ut om dine erfaringer"). Hvordan denne informasjonen vil bli brukt – både i utformingen og fra

ståsted om konfidensialitet. At du som moderator er der for å høre om deres meninger og

opplevelser. Du vil at de skal føle at de kan dele ærlig, så be enkeltpersoner om å være greie, men også respektere andre i gruppen. At det er mange emner å dekke, så på et tidspunkt vil du avslutte en dis-

diskusjon om ett emne for å være sikker på at du kan dekke dem alle. Dette kan deretter gå inn i en introduksjonsrunde for gruppemedlemmer, ofte inkludert en slags isbryterspørsmål. Målet ditt er å få alle til å snakke om det første spørsmålet, selv om de bare forteller en novelle. Du kan enten starte med én person og jobbe rundt bordet eller la folk svare naturlig og deretter ringe opp de som ennå ikke har svart med navn. Ofte vil du ende opp med å gå rundt bordet for de første spørsmålene, og så, når du føler at gruppen er klar, kan du med kroppsspråk åpne spørsmålene for alle.

Snorkling: Kroppsspråk En god forståelse av kroppsspråk kan være et fantastisk verktøy når man modererer fokusgrupper eller brukerundersøkelser utført personlig. Det kan hjelpe deg å forstå når noen føler seg frustrert, spent, sint eller truet, slik at du kan identifisere når du bør prøve å gjøre noen mer komfortabel eller undersøke en bestemt kommentar. Følgende bok om emnet kan ta mer enn en helg å lese fullstendig, men den er designet for å være lett å bla i: The Definitive Book of Body Language, av Allan Pease og Barbara Pease (Bantam, 2006).

Når du ringer noen som ikke har svart ennå, sørg for å gjenta spørsmålet i tilfelle de ikke forsto det eller ikke hørte på det siste

106

KAPITTEL 6: BRUKERFORSKNING

få utsagn i diskusjonen. Unngå også at en meningsforskjell virker som en uenighet mellom to individer. Ikke si: "Bob, vi har ikke hørt fra deg ennå. Hva synes du om det Chris nettopp sa?» men heller (ser på Bob), "Hva med deg, Bob? Hva slags erfaringer har du hatt med Pseudo Corporations kundeservice?» Som moderator kontrollerer du flyten i diskusjonen og sender den virtuelle mikrofonen rundt. Du beholder kontrollen ved hjelp av øyekontakt, talevolum, armbevegelser og orientering av kroppen din. De fleste vil være veldig bevisste på kroppsspråket ditt, og disse signalene kan være nyttige signaler hvis noen dominerer samtalen. Hvis en altfor vokal deltaker ikke får disse hintene, bruk en mild, men bestemt uttalelse som "OK, flott, jeg vil gjerne åpne den tanken for andre. Har noen andre vært borti noen av de samme problemene som Theresa har?» Når du går videre til et nytt større emne, gi muntlig beskjed om at den forrige diskusjonen er avsluttet og at en ny begynner, slik at folk kan rense tankene for neste emne. Til slutt, når aktiviteten nærmer seg slutten, kan et enkelt blikk på klokken og skifte i kroppsorienteringen signalisere at samtalen bør avsluttes. Som med alle andre aktiviteter, husk å takke gruppen for tiden deres. Å dele resultater med teamet ditt tar vanligvis en av to former: funnene deles enten i henhold til hovedemnene som dekkes, eller grupperes i relevante kategorier omtrent som de er for kontekstuelle undersøkelser. Affinitetsdiagram kan være en annen effektiv måte å samle ulike trender og holdninger for illustrasjon til prosjektteamet.

Kortsortering I en kortsorteringsaktivitet får deltakerne (som arbeider enten individuelt eller i små grupper) gjenstander trykt på kort og blir bedt om å sette dem inn i grupper som gir mening for dem. Enten grupperer de dem i kategorier som er gitt på forhånd (kalt en lukket sortering), eller de lager sine egne grupper og gir hver gruppe navn selv (kalt åpen sortering). På slutten av runden med kortsortering bør du begynne å se vanlige mønstre dukke opp i hvordan folk sorterer gjenstandene, samt vanlige områder med forvirring eller uenighet.

VELG FORSKNINGSTEKNIKK

107

En vanlig grunn til å gjøre dette er å lage et områdekart for et nettsted eller å lage et hierarki av innhold, kategorier og underkategorier som inneholder elementer som artikler, dokumenter, videoer eller bilder. Dette gjør kortsortering til en utmerket teknikk hvis du jobber med en innholdskilde. Merk Se kapittel 2 for mer om innholdskilder.

La oss si at du jobber med en vanlig type innholdskilde: selskapets intranett. Mange intranett har en tendens til å kategorisere informasjonen sin etter avdelingen som eier den, med navigering til menneskelige ressurser, drift, juridisk, markedsføring og så videre. For mange ansatte er dette kanskje ikke et åpenbart problem, fordi de sannsynligvis har lært ansvarslinjene til hver avdeling og bygget opp en forståelse av hvor de kan finne informasjon. Men for nyansatte, eller for de som trenger informasjon som de vanligvis ikke refererer til, kan det være vanskelig å finne informasjon som kan falle innenfor mer enn én avdeling (eller ikke ser ut til å falle inn under noen). Hvor vil du for eksempel gå for å finne en policy for signering av kontrakter med nyansatte? Det kan falle inn under lov, eller det kan falle inn under menneskelige ressurser. Med kortsortering kan du finne vanlige mønstre i hvordan potensielle brukere vil kategorisere informasjon, uavhengig av avdelingslinjer. Grunnprosessen Samle elementene du vil inkludere i kortsorteringen; 40 til 60 er vanligvis et godt område. Du trenger nok til å tillate at et potensielt stort antall kortgrupper kan opprettes, men ikke så mange at du overvelder deltakerne med alternativer (eller overvelder deg når du trenger å analysere resultatene). Velg elementer som du tror vil være enkle å forstå og fri for unødvendig sjargong. Du kan inkludere noen emneord som du tror brukergruppene dine sannsynligvis kjenner til, men unngå å inkludere for mange "insider"-termer. Hvis du inkluderer for mange bedriftsspesifikke termer eller akronymer (som "SUCCES-kampanjen" for økende salg), vil du teste effektiviteten til selskapets markedsføring og kommunikasjon, i stedet for å bygge et felles informasjonshierarki. For eksempelet på intranettet kan du inkludere feriepolicyen, 401(k) planinformasjon, nyansatt kontrakt, leverandørkontrakt, taushetserklæring,

108

KAPITTEL 6: BRUKERFORSKNING

orientering om nye ansatte, informasjon om helseforsikring og datasikkerhetspolicy. Denne listen representerer en blanding av klart formulerte elementer som kan kategoriseres på flere måter. Du kan ha en deltaker som grupperer ny medarbeiderorientering og feriepolitikk sammen under menneskelige ressurser, og du kan ha en annen som grupperer ny medarbeiderorientering og ny ansettelseskontrakt sammen og kaller det "ansatt ombordstigning." Når du har en liste over elementer, legg dem på kort som enkelt kan grupperes og deles opp. Du kan skrive ut etiketter og feste dem på kartotekkort eller skrive ut direkte på ark med kartong som er perforert for å separeres i individuelle kort. Utfør en testkjøring ved å be noen sortere kortene i grupper og gi gruppene navn – for eksempel ved å legge en Post-it på bunken og skrive navnet på den med en penn. Ideelt sett er testdeltakeren en som ikke er kjent med elementene og aktiviteten. Dette vil hjelpe deg å få en grov ide om hvor lang tid aktiviteten kan ta. Hvis prøvekjøringen tar over en time, må du kanskje kutte ut noen kort! Når du har en ferdig kortstokk, kan du ta med en ekte deltaker og gi disse grunnleggende instruksjonene: 1. Ordne disse kortene i de gruppene som er fornuftige for deg. 2. Prøv å ha minst to kort i en gruppe. Hvis et kort ser ut til å ikke tilhøre noen gruppe, kan du legge det til siden. 3. Når som helst mens du sorterer, kan du navngi en gruppe. Ved slutten av aktiviteten, vennligst navngi så mange grupper du kan. Noen trender vil bli tydelige bare ved å observere øktene. Andre kan ta litt mer analyse for å få frem. Det finnes flere verktøy for å legge inn og analysere resultatene av kortsorteringer; mange av dem kommer med verktøy som lar deg kjøre kortsortering eksternt (se delen "Variasjoner på kortsortering" nedenfor for mer om dette). Spesielt gir OptimalSort (www.optimalsort.com/pages/default.html) og WebSort (http://websort.net) både fjernsorteringsmuligheter og nyttige analyseverktøy. Eller, hvis du vil gjøre din egen sortering på en mer manuell måte, ta en titt på Donna Spencers utmerkede regneark, komplett

VELG FORSKNINGSTEKNIKK

109

med instruksjoner, tilgjengelig på www.rosenfeldmedia.com/books/cardsorting/ blog/card_sort_analysis_spreadsheet. Variasjoner på kortsortering Diskusjonen så langt har fokusert på en kortsortering utført med en person, personlig, hvor deltakeren blir bedt om å navngi kategoriene han opprettet. Dette er en åpen sortering, noe som betyr at hovedkategoriene ikke er gitt til deltakeren – i stedet er de åpne for å bli navngitt. Dette er en god tilnærming når du skal bestemme en ny navigasjonsstruktur eller gjøre betydelige endringer i en eksisterende. For andre situasjoner kan du vurdere disse vanlige kortsorteringsvariasjonene: Lukkede sorteringer. I en lukket sortering gir du kategoriene på høyt nivå

og deltakerne legger til dem. Resultatene er relativt enkle å analysere, fordi du har et lite sett med mulige kategorier og kan fokusere på å forstå hvilke varer som oftest faller inn i hvilke kategorier. Hvis du legger til store mengder innhold til en eksisterende informasjonsarkitektur eller du validerer et eksisterende nettstedskart, kan en lukket sortering gi rask og handlingskraftig informasjon for å hjelpe deg med kategoriseringsbeslutningene dine. Gruppe sorterer. I stedet for å ha en individuell sortering av elementer i grupper, kan du

la kortsortering være en del av en fokusgruppeaktivitet, der deltakerne jobber sammen for å sortere gjenstander. Selv om resultatene ikke nødvendigvis gjenspeiler hvordan en person vil gruppere elementene, kan du få mye innsikt i hvordan folk tenker om elementene og deres organisasjon ved å høre dem jobbe gjennom aktiviteten sammen, og diskutere begrunnelsen for hver plassering. Ekstern sortering. Sortering med fysiske kort kan være en morsom aktivitet, spesielt

for gruppesorteringer. Men det finnes mange gode verktøy for å utføre sorteringer på nettet med enkeltpersoner. Dette lar deg også nå et større antall deltakere eller bestemte deltakere som kan være vanskelig å møte fysisk. OptimalSort og WebSort, nevnt ovenfor, er to av verktøyene som gjør denne typen online sortering enkel.

Brukervennlighetstesting Brukervennlighetstesting innebærer å be deltakerne om å utføre spesifikke tester på et nettsted eller en applikasjon (eller en prototype av den) for å avdekke potensielle brukervennlighetsproblemer og samle ideer for å løse dem.

110

KAPITTEL 6: BRUKERFORSKNING

Du kan utføre brukervennlighetstesting under Deﬁneringsfasen hvis du ønsker å samle informasjon om hvordan det nåværende nettstedet kan forbedres. Eller du kan utføre det på lignende nettsteder (for eksempel konkurrerende nettsteder) for å forstå noen av de potensielle mulighetene for en mer brukervennlig løsning. Oftest utføres brukervennlighetstesting som en del av designfasen, ideelt sett i iterative runder (hvor et design lages, testes, foredles og testes på nytt). Vi vil diskutere brukervennlighetstesting igjen i full detalj i kapittel 13, "Designtesting med brukere"; det kapittelet inneholder tips for rekruttering og planlegging som kan hjelpe deg med å gjennomføre aktivitetene som er diskutert tidligere i dette kapittelet.

Etter undersøkelsen Når du har fullført en eller flere av disse brukerforskningsaktivitetene, er det på tide å gå tilbake til forutsetningene du opprinnelig gjorde om brukergruppene dine. Legg bort disse antakelsene et øyeblikk, og spør deg selv hvilke brukergrupper du ville opprettet nå som du har mer informasjon. Hvis noen av dine tidligere antakelser ikke var gyldige, bør du vurdere eventuelle hull du kan ha i brukerundersøkelsen din fordi en nøkkelgruppe ikke var inkludert. Hvis dette gapet blir identifisert tidlig nok i forskningsaktiviteten din, kan det hende du har tid til å justere og legge til et annet sett med deltakere til forskning som pågår, for å sikre at du får et fullstendig bilde. Med den nye kunnskapen din kan du revidere brukerdefinisjonene dine for mer nøyaktig å reflektere gruppene som bør være i fokus. Dette vil hjelpe deg med å lage mer detaljerte verktøy som personas (diskutert i kapittel 7) og vil hjelpe deg med å lage brukerkrav for listen vi startet i kapittel 5. I det kapittelet diskuterte vi prosessen med å ta uttalelser fra forretningsinteressenter og avgrense dem til krav. Du vil følge en lignende prosess med brukere – arbeidet ditt stopper ikke når du fanger ideen eller forespørselen. Grav ned til rotbehov og mål for å sikre at du forstår dem. Dette vil til syvende og sist hjelpe deg med å designe en løsning som best dekker det behovet for alle relevante brukergrupper. I neste kapittel lærer du hvordan du bruker innsikten du får i å utføre brukerundersøkelser til å lage verktøy som kan sette fokus til brukergruppene dine gjennom design og utvikling: personas.

ETTER FORSKNING

111

Personas Finn den beste måten å sette ditt team – eller din klient – i brukernes sko Personas er ofte et tema for debatt blant brukere som utøver erfaring. Meningene varierer fra hvor mye innhold som trengs til hvor mye forskning som trengs til om de gir noen verdi til prosjekter. Noen stiller spørsmål ved om de hører hjemme i prosessen eller ikke. Uavhengig av hvor du plasserer deg selv, kan personas brukes til å hjelpe prosjektteamet ditt og kunden din med å føle empati med brukerne deres. Personas kan levere en magesjekk til mange deler av prosjektet ditt – forretningskrav, visuell design eller kvalitetssikring – ved å gi innsikt i hvem publikumet ditt er og hva deres forventninger og oppførsel er. Russ Unger

Hva er personas? Personas er dokumenter som beskriver typiske målbrukere. De kan være nyttige for prosjektteamet ditt, interessenter og kunder. Med passende forskning og beskrivelser kan personas male et veldig klart bilde av hvem som bruker nettstedet eller applikasjonen, og potensielt til og med hvordan de bruker den. Designere av brukeropplevelser ser ofte på å skape personas som en god øvelse i empati. Godt utformede personas brukes ofte som et berøringspunkt når det oppstår spørsmål eller bekymringer om hvordan aspekter ved prosjektet skal utformes. Du kan ta ut personasene dine og spørre: Hvordan ville du prestere? eller Hva skal se etter i ? Selv om denne prosessen kanskje ikke er så nøyaktig som å teste funksjonalitet og design med faktiske brukere, kan den hjelpe deg med å flytte prosjektet ditt til du kan utføre mer omfattende tester. Josh Seiden (www.joshuaseiden.com) påpeker at det er to forskjellige typer personas: Markedsføringsmålrettede personas som modellerer kjøpsmotivasjoner Interaktive personas som er modellert mot bruksatferd

Dette kapittelet fokuserer på interaktive personas.

Hvorfor skulle jeg lage personas? I designprosessen for brukeropplevelse hjelper personas deg med å fokusere på representative brukere. Ved å gi innsikt i "ekte" atferd til "ekte" brukere, kan personas bidra til å løse konflikter som oppstår når du tar design- og utviklingsbeslutninger, slik at du og teamet ditt kan fortsette å gjøre fremskritt. Hvor ekte trenger personas å være? Svaret varierer mye. Et enkelt persona-dokument kan være nok for ett team, mens et annet kan skape fulle "livsrom" for brukerpersonas for å forstå hvordan de "lever". Du kan til og med gå til det ytterste av å skape individuelle tilstedeværelser på nettet som kan samhandles med for å gi innsikt i atferd på nettet. Hvordan du velger å utvide personasene dine er opp til deg. Personas kan være konstante påminnelser om brukerne dine. En nyttig teknikk er at teammedlemmene dine kan beholde personas på arbeidsplassene sine; slik er de

HVORFOR SKAL JEG SKAPE PERSONAS?

113

stadig minnet om hvem brukerne deres er. Når du deler en kube med «Nicolle», den 34 år gamle sertifiserte håndterapeuten fra West Chicago, Illinois, for en stund, begynner du å se deg selv tvunget til å gi en opplevelse som fungerer bra for henne. Hvis det hjelper deg, kan du gjerne ha med deg trykte kopier mens du sover og la osmose-feen formidle empati fra sidene gjennom puten og inn i din slumrende underbevissthet. Hensikten med personas er å hjelpe deg, teamet ditt og/eller kundene dine med å fjerne noe av forvirringen som kan dukke opp når du kommer til et veiskille for beslutninger.

Finne informasjon for personas Effektive personas må avbilde et antall spesifikke brukere av ditt produkt eller nettsted nøyaktig. For å nå det målet må personas støttes av forskning. Kapittel 6 presenterer teknikker for å undersøke og modellere potensielle brukere for å gi et solid grunnlag for personasene dine. Ikke se etter én metode for å være svaret; det er best å finne så mye data du kan og blande det med en blanding av observasjons- og intervjudata – dette kan også inkludere bruk av nettbaserte spørreundersøkelser og analyse av atferd i sosiale nettverk. Det er et vanlig tema for å lage personas: Få ekte data, men gjør personas til virkelige mennesker på sidene. For å finne ut hvordan ett selskap oppnår dette, se sidefeltet "Case Study: Messageﬁrst Personas."

Lage personas Når du har identifisert publikummet ditt og akkumulert data for å støtte personasene dine, er neste skritt å sette blyant på papir og begynne å bringe dem til live. Hvor mange personas du trenger for å lage varierer. Generelt er minimum tre, men oppover syv er ikke uvanlig. I stedet for å sikte på et spesifikt antall, bør du vurdere antall målsegmenter du har og hva du føler er den beste måten å få en rettferdig representasjon av dem på.

114

KAPITTEL 7: PERSONER

Kasusstudie: Messageﬁrst Personas For å skape effektive, datadrevne personas, bruker Messageﬁrst (www.messageﬁrst.com) ikke mindre enn tre forskjellige datainndatakilder, hentet fra følgende: Interessenter. Vi intervjuer dem for å finne ut hvem de tror personasene er og hva de tror atferden deres er. Dette er alltid inkludert. Kundeadvokat. Vi intervjuer personer i bedriften som snakker direkte med kunder, som typisk betyr Salg/Markedsføring og Kundeservice. Hver av disse har sin skjevhet, som vi sørger for å huske på når vi dokumenterer funnene våre. For eksempel er de som oftest kontakter kundeservice de som har for mye tid på seg (ofte pensjonert eller arbeidsledig), eller noen som er så opprørt over et produkt eller en tjeneste at de faktisk vil ta tid å kontakte deg. Kunder. Vi snakker direkte med de faktiske personene som skal bruke eller for øyeblikket bruker produktet eller tjenesten. Dette er inkludert når det er mulig. Kundedatakilder. Vi gjennomgår all tilgjengelig webloggtrafikk, undersøkelser og e-poster som er tilgjengelige for oss. Noen vi kjenner. Vi velger noen vi kjenner som passer til den opprinnelige profilen til personaen. Dette bidrar til å holde oss jordet, og sikrer at personen er troverdig og realistisk, og gir en ekte person å kontakte hvis vi har flere spørsmål. Dette er veldig viktig for validering, og alltid inkludert. Fordi hver datainndatakilde vi bruker har en spesiell skjevhet, bruker vi flere kilder for å normalisere dataene. Det som er viktig for datadrevne personas er ikke å gå inn med en forventning om hvor mange personas du vil ha, men å la dataen avsløre hvor mange personas det skal være. Når jeg analyserer dataene, ser jeg etter hull i atferden og aktivitetene. Disse hullene avslører den enkelte personas. Todd Zaki Warfel, president, Messageﬁrst

Dette kapittelets eksempelpersona er Nicolle, en 34 år gammel sertifisert håndterapeut fra West Chicago, Illinois. Hun er tilfeldigvis en ikke-kjørende pendler som bruker 2 til 3 timer per dag på å reise til og fra jobben sin. Den fiktive klienten er et selskap kalt ACMEblue, en produsent av Bluetooth-hodesett for Apples ikke-så-fiktive iPhone.

SKAPE PERSONER

115

Det korte avsnittet forteller deg mye om Nicolle, men som du kan se i figur 7.1, inneholder den faktiske persona en mye mer grundig historie om Nicolle. Merk at innholdet er skrevet om Nicolle, ikke "av" Nicolle. Det er best å skrive personasene dine fra tredjepartsperspektivet og ikke slite med å skrive med deres distinkte stemmer, spesielt når du akkurat har begynt. Når du utvider opplevelsen din, bør du naturligvis utforske og finne stilen som passer deg best og gir mest verdi.

Figur 7.1 Persona for den fiksjonelle klienten ACMEblue

Hva slags informasjon går inn i personas? Den typen informasjon som publikum vil finne relevant og troverdig, det er den typen. Basert på forskningsdataene du har samlet inn, bør du kunne finne ut hva som er viktig for kunden, merkevaren og prosjektet. Flertallet av personasene du lager vil dele et felles sett med nødvendig innhold blandet med en hvilken som helst mengde data, statistikk og annen relevant informasjon som kan betraktes som valgfri, fordi det vil variere fra klient til klient, om ikke prosjekt til prosjekt.

116

KAPITTEL 7: PERSONER

Minimumskrav til innhold Når du lager personas, må du gi nok informasjon til å trekke folk inn og få dem til å forholde seg til personen de leser om på siden. For å hjelpe publikum med å forstå hvordan personligheten din oppfører seg og tenker, sørg for å inkludere seks viktige opplysninger: bilde, navn, alder, plassering, yrke og biografi. De neste avsnittene tar en nærmere titt på å fylle ut detaljene for hvert element. Foto Et bilde er det første (og det virkelige) trinnet for å sette et ansikt til personligheten din. Når du velger et bilde for personligheten din, prøv å sørge for at bildet ikke ser for posert eller polert ut. Bilder som ser ut til å være poserte har ikke samme effekt som de som er i mer naturlige omgivelser. Personas ser ut til å være mer effektive med bilder tatt i mer naturlige omgivelser, slik som bildet til høyre i figur 7.2, der motivet står ute i vinterfrakken, muligens mens hun pendler. Sørg for at bildet passer til personlighetens livsstil! Stillte

Naturlig Figur 7.2 Naturlige bilder er mer effektive.

Det finnes en rekke online fotoressurser. Noen av de bedre alternativene er iStockphoto (www.istockphoto.com), Getty Images (www.gettyimages.com) og Stock.XCHNG (www.sxc.hu).

SKAPE PERSONER

117

Å finne det riktige bildet kan være en fullstendig tidssukker hvis du ikke er forsiktig. Hvis alt annet mislykkes (eller du har tid og budsjett), ta din egen! Navn Enkelt sagt, du må sette et navn til ansiktet. Bildet du bruker vil humanisere blandingen av forskningsdata og personlighetstrekk, og navnet vil være hvordan alle refererer til din persona under diskusjoner. Ikke bare høres Nicolle bedre ut enn «Mid-30s Blonde Professional Mom», men det er mye lettere å huske og assosiere med en spesifikk persona. Prøv å unngå at navnene du bruker for ulike personas på et prosjekt høres for like ut. Nicolle og Noelle kan for eksempel lett forveksles, så se etter forskjellige navn. Og selv om det kan være fristende å bruke navnene på kollegaer eller klienter, ikke gjør det. Når du bruker navn som er like eller de samme som navnene til personer som er involvert i prosjektet, er det lett for dem å prøve å identifisere seg i personasene dine. Å velge forskjellige navn unngår ubehagelige situasjoner eller sårede følelser. Hvis du opplever at du har problemer med å velge navn, kan noen nettressurser hjelpe deg med dette: nettsteder for navngivning av babyer! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Social Security Administrations populære babynavn: www.ssa.gov/

OACT/babynames Generator av tilfeldig navn: www.kleimo.com/random/name.cfm

En siste ting om navn: Sørg for at navnet ditt er troverdig for personaen. Nicolle fungerer helt fint for en mor fra Midtvesten, men Nicola eller Natalia kan være et mye bedre navn for en italiensk mor. Det er heller ikke navn som ser ut til å være litt morsommere eller mer livlige, for eksempel Byggeren Bob. De har en tendens til å få personasene dine til å se dumme ut og kan redusere verdien deres. Alder Selv om forskningen din bør identifisere aldersgruppen til forbrukerne dine, hjelper det å gi en spesifikk alder for personligheten din til å gi autentisitet til biografien du skriver. Atferden til en 21 år gammel høyskolestudent og en 34 år gammel profesjonell mor er betydelig forskjellig!

118

KAPITTEL 7: PERSONER

Plassering I utgangspunktet kan det hende at plassering ikke er viktig informasjon; Det er imidlertid viktig å huske at kulturelle og atferdsmessige endringer kan forekomme fra sted til sted. I Italia, for eksempel, snakkes det forskjellige dialekter i forskjellige regioner i landet. I USA vil en person som bor i Chicago mest sannsynlig ha en annen levekostnad enn en person i Savannah, Georgia. Yrke Å vite hva din persona lever av hjelper deg å identifisere deg med dem ved å forholde deg til mønstrene i deres daglige liv. En persona som jobber i terapi møter mange mennesker på daglig basis, mens en vindebrooperatør kanskje ikke samhandler mye med andre. Biografi Biografien er den overbevisende historien som gjør personen virkelig. Det er her du oppgir detaljer som du henter fra forskningsdataene dine og tilfører dem litt "ekte mennesker". Det vil si at dataene er veldig viktige for persona, men du vil ikke bare sitere den informasjonen i hakkete setninger. I stedet vil du veve data, anekdoter og observasjoner inn i en historie som publikum kan relatere seg til. Det kan virke litt rart, men biografien må være troverdig, og det er absolutt ikke juks å bringe aspekter av en ekte person inn i personligheten din. Nicolle, for eksempel, er basert på både statistiske data og den virkelige oppførselen til en person som deler lignende aktiviteter, tro og ønsker. Avhengig av prosjektet ditt, må du kanskje gå ganske dypt inn i biografien - noen ganger jo flere detaljer du har, jo bedre. Ikke føl deg som om du må presse personligheten din på ett enkelt ark. Gå med det som fungerer best for å gjøre din personlighet virkelighetsnær og så meningsfull som mulig for prosjektet du jobber med.

Valgfritt innhold Når du jobber med personas, vil du oppdage at ulike prosjekter vil kreve ulike sett med informasjon for å gjøre personas mer anvendelige. Minimumskravene til innhold kan også anses som de minst vanlige

SKAPE PERSONER

119

nevnere fra de fleste personas du vil lage. I de fleste tilfeller vil du blande noen av disse valgfrie innholdselementene med kjernen i personasene dine. Valgfritt innhold som kan tilføre verdi til personasene dine inkluderer utdanningsnivå. Å vite hvor utdannet en person er kan gi litt

mer innsikt i noen av deres vaner. En person med videregående vitnemål kan ha vesentlig andre kjøpsvaner og merkeoppfatninger enn en person med en mastergrad, og denne informasjonen kan påvirke hvordan personligheten din oppfattes. Lønn eller lønnsspenn. Penger snakker, og i mange tilfeller mengden av

inntekt en person har påvirker deres levestandard og disponibel inntekt i vesentlig grad. Denne informasjonen kan gi betydelig innsikt når du retter deg mot visse nivåer av velstand. Personlig sitat. Hva ville være mottoet din persona ville hevde

som sine egne? Noen ganger kan dette gi en rask oversikt over kjernen i din personas måte å tenke på. Online aktiviteter. Dette kan bli vanskelig; det er mange måter folk bruker på

tiden deres på nett. Noen betaler regningene sine, noen liker blogging og sosiale nettverksaktiviteter, og noen bruker ganske enkelt datamaskinen som et apparat som slås på når de skal utføre en oppgave. Gitt at så mange prosjekter har en nettkomponent, er dette elementet litt av en dømmekraft. Du må støtte deg på forskningen din for å hjelpe deg med å male bildet. Offline aktiviteter. Har din person en hobby? Er det tillegg

informasjon om hvordan livet til din person er når de ikke er online? Dette elementet kan være like vanskelig som nettaktiviteter, og kan være like viktig for å påvirke personligheten din. Nøkkelinngang eller triggerpunkt til klient, merke eller prosjekt. Ofte er det viktig

for å forstå hvordan en persona samhandler med kunden, merkevaren eller prosjektet. Hører personen om det via jungeltelegrafen, anmeldelser på nettet, en reklametavle, TV eller radio, eller fra en popup-annonse på nettet? Er din person på jakt etter å løse et problem som kan løses gjennom klienten, merkevaren eller prosjektet? Å bruke de statistiske dataene dine til å forstå dette punktet, og skrive det inn i din persona, kan bidra til å legge grunnlaget for din tilnærming til å engasjere brukere.

120

KAPITTEL 7: PERSONER

Teknisk komfortnivå. Bruker personligheten din en PC eller Mac? Gjør hun

eier en datamaskin i det hele tatt? Bruker hun direktemeldinger, Flickr, eller skriver hun en blogg? Er hun veldig komfortabel med den aktiviteten, eller er hun forvirret av den? Ville hun bli hjulpet av en veldig enkel løsning rettet mot en nybegynner? Har hun en MP3-spiller eller annen bærbar enhet? Bruker hun en DVR eller AppleTV eller on-demand programmering for å se på TV? Listen kan fortsette og fortsette. Og på. Avhengig av din klient, merke eller prosjekt, kan disse forestillingene – og en rekke andre – være viktige å identifisere. Sosialt komfortnivå. Gitt veksten av sosiale medier og sosiale nett-

fungerer, kan det være viktig å identifisere veldig spesifikt hvordan din persona engasjerer seg i det aktuelle rommet. Har hun en Twitter-konto? I så fall, hvor mange følgere har hun? Hvor aktiv er hun? Er hun en leder? Bruker hun MySpace, Facebook, LinkedIn eller andre aggregatorer eller nettsamfunn? Mobil komfortnivå. Etter hvert som bruken av mobile enheter blir mer

utbredt, er det viktig å vurdere å inkludere hvordan personasene dine finner seg selv i det mobile rommet – hvis i det hele tatt. Motivasjoner for å bruke klient, merke eller prosjekt. I noen tilfeller vil du kanskje

å inkludere årsakene til at personen ønsker å bruke klienten, merket eller prosjektet. Hvis hun stadig får ledningen til hodetelefonene viklet inn i frakken og drar dem av hodet, kan det være en god grunn for henne til å vurdere nye hodetelefoner. Ekte scenarier basert på forskningsdata kan bidra til å avdekke viktige motivatorer for å inkludere i personasene dine. Brukermål. Det kan også være lurt å identifisere hva personen håper på

oppnå ved å bruke klienten, merkevaren eller prosjektet. Dette kan bidra til å gi innsikt i personas drivere for å bruke den. Dette er bare datapunkter for å komme i gang. Du kan strukturere dine personas og presentere dem på en uendelig rekke måter. Hvis du er interessert i å ta et dypdykk inn i personas verden, er et flott sted å begynne The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web, av Steve Mulder med Ziv Yaar (New Riders, 2006) ).

SKAPE PERSONER

121

Avanserte personas Når du har en forståelse av det grunnleggende om å lage personas, er det uendelig mange måter du kan utvide dokumentene dine på. En enkel persona kan ofte dekke de fleste behovene dine, spesielt når prosjektteamet ditt bare prøver å få en empatisk forståelse av brukerne dine. Ting har en tendens til å bli mer interessant når du presenterer personas for kundene dine. I disse tilfellene vil du ofte oppdage at du trenger å gi mye mer enn informasjonen du setter sammen for den grunnleggende persona. Figurene 7.3 til 7.7 illustrerer noen av måtene du kan utvide personas på. Lån gjerne fra disse eksemplene, remiks og bland dem sammen for å lage noe enda bedre for prosjektet ditt!

Merkenavn

Møt merkevareforbrukerne

PERSONER OG SCENARIER (basert på etnografiske studier) Personas er sammensatte karakterer basert på data om målforbrukerne: i dette tilfellet etnografi, eksisterende segmenteringer og kundedatabasedata.

Scenarier er hypotetiske, men realistiske fortellinger som beskriver hvorfor disse personaene kan besøke merkevarenettstedet og hva de ville gjort der.

Joan, 32. Forbrukerinnsikt hjelper oss å forstå brukere – deres motivasjoner, mål og ønsker. For å bruke denne innsikten på nettsteddesign, utvikler vi brukerpersonas og scenarier som er forankret i virkelige kontekster. Denne designtilnærmingen hjelper til med å lage omfattende opplevelser basert på en forståelse av kunder, deres motivasjoner, ønskede resultater og atferd. Scenarier svarer spesifikt på tre grunnleggende spørsmål som må løses før et nettsted kan organiseres ordentlig: Ŕ8IPBSFZPVSSFQSFTFOUBUJWFVTFST Ŕ8IBUBSFUIFVTFSōTTQFDJţDHPBMT Ŕ)PXDBOVTFSTBDIJFWFUIFJSHPBMTBO å ha erfaring på hele nettstedet ditt

Fornøyelsessøkende afficionados "Jeg liker dette virkelig" "Young Sophisticate"

START

BEGYNNE Å UTE

BYGG ERFARING

“Aspirerende nybegynner”

"$)*&7&-&7&- AV KOMFORT

"Aktiv svar"

FØL 5)&365

UTFORSK IGJEN

"Etablert utforsker"

STREAMLINE OG FORENKLE

“Voksen opp i en rille”

Praktisk få ting gjort «Det må bare fungere»

Alice, 26

Rachel, 42

Erica, 47

Greta, 59

Figur 7.3 Persona oversikt masterark (liggende orientering). Gir en samlet oversikt over flere personas, sammen med segmentene de representerer, i sammenheng med en organisasjonsstrategi på høyt nivå. Med tillatelse fra Will Evans.

122

KAPITTEL 7: PERSONER

Merkenavn

PERSONER OG SCENARIER (basert på etnografiske studier) Alice er en nybegynner kokk som ønsker å utforske matens verden,

MÅL

spesielt barnevennlig mat, med venner og ved å lete etter nye oppskrifter på nett og i magasiner. Utforskningen hennes handler mer om

mat familien hennes uten mye omtanke eller innsats

fantasi enn virkelighet, skjønt. Hun er fortsatt skremt og gjør det ikke

finn raske, enkle oppskrifter med grunnleggende ingredienser

prøv for mange nye oppskrifter. Moren hennes ga ikke for mange matlagingsferdigheter til henne, og vennene hennes er ikke særlig erfarne

(ofte) lage to typer måltider: for voksne, for barn

kokker heller. Alice er en travel mor til en datter i Chicago. Både hun og mannen hennes jobber utenfor hjemmet – hun leder kontoret til et lite forsikringsselskap.

Alice, 26 "Aspiring Novice" gen x gift

1 datter, 5 slitne, ambisiøse

inntekt

utdanning

Hun er travel, praktisk og bruker ikke mye tid på å lage mat. Alice vil bare få det gjort raskt og enkelt – selv om hun ofte må tilberede forskjellige måltider for seg selv og mannen sin siden hun startet treningsregimet etter å ha hatt Sophie for to år siden og prøver å komme tilbake i maratonform. Hun jobber ut fra et lite sett med vellykkede oppskrifter hun føler seg komfortabel med, og mange av måltidene hun lager er basert på pakket og tilberedt mat.

SCENARIO Alice ser på Cartoon Network med Sophie under frokosten. Det kommer en merkereklame som viser et merkenavn her. Alice bruker merkevare, og tror Sophie ville gått for den retten. Hun bestemmer seg for å sjekke ut siden fra jobben. Alice besøker nettstedet i løpet av en gratis halvtime før et møte. Hjemmesiden er oversiktlig og organisert. Hun ser hovedsidene og linker til interessante ting som dagens oppskrift.

internettbruk

helsebevissthet

kostnadssensitivitet

Hun klikker på dagens oppskrift. Hun liker tipsene som følger med den – de får henne til å føle at hun kan takle denne oppskriften. Hun er fornøyd med den klare navigasjonen, i motsetning til andre nettsteder hvor hun har en tendens til å gå seg vill. Hun liker de nyttige funksjonene som går utover det hun ser i kokebøker, som muligheten til å finne oppskrifter basert på hva som finnes i pantryet hennes, og tips om hvordan du bruker produktene. Alice oppdager at hun kan motta nyhetsbrev om oppskrifter og klikker på "Registrer deg". Registrering er så enkelt! Hun fyller ut litt grunnleggende informasjon og velger nyhetsbrevet "Mat som barna dine vil elske".

Hun vil gjerne legge til mer av sitt eget preg, og gjenskape retter hun liker på restauranter, som hennes all-time favoritt, jerk chicken. Hun vil også legge til flere ferske grønnsaker til måltidene sine, fordi hun vet at det er sunnere. Hun setter sin ære i at hun er en grundig planlegger og i stand til å drive husholdningen sin på et stramt budsjett. Kjøleskapet og pantryet hennes er alltid på lager. Hun planlegger shopping for å dra nytte av salg og kuponger.

finn barnevennlige oppskrifter og mataktiviteter finn måter å "kle på" favorittmaten sin PROSJEKTER OG INITIATIV forbedret navigasjon og informasjonsarkitektur forbedret registrering

En uke senere ved lunsjtid finner Alice sitt første Brand e-nyhetsbrev: "Pizza, lett som 1, 2, 3." Perfekt – barna hennes elsker pizza, og hun kjøper vanligvis frossenpizza til dem. Det er en lenke til «Pizza for nybegynnere» som inspirerer henne til å se om hun kan lage pizza selv. Linken tar henne til en oppskrift på pepperoni pizza på noe som kalles "Pizza Wizard". Hun skanner oppskriften og ser at den er ganske enkel; kun 25 minutter og 4 ingredienser. Hun sjekker kjøkkenet sitt for å se hva hun har. Hun har ikke pepperoni eller pizzasaus, men "Pizza Wizard" foreslår å erstatte dem med ting hun har på sitt velfylte kjøkken: pølse og tomatsaus. Og perfekt! Det er en lenke til en kupong. Neena skriver ut oppskriftens handleliste, legger til et par varer hun også trenger og drar til butikken. Tilbake fra butikken setter Alice i gang. Hun ser trinnvise instruksjoner om hvordan du ruller ut deigen og tilsetter ingrediensene. Det er bilder ved siden av hvert trinn. Det er lett å forstå og følge. Hun lurer på om hun bør lage pålegget først, men de vanlige spørsmålene om pizza svarer på det for henne.

kontekstualisert perifer informasjon mer målrettede nyhetsbrev oppskriftsveiviser bedre kupongintegrering MÅLTIDSPLANLEGGING "få det gjort"-holdning er sterkt avhengig av ferdigmat, med relativt få tilsatt fersk frukt og grønnsaker bruker mer tid på å bla gjennom oppskrifter enn å faktisk lage dem

Figur 7.4 Målgruppepersona (landskapsorientering). Denne detaljerte visningen av en persona inkorporerer et bredere spekter av data og gir et mer omfattende perspektiv av brukernes mål, behov og atferd – alt satt i et større økosystem. Med tillatelse fra Will Evans.

Figur 7.5 Måloversikt og målgruppepersona (portrettorientering). Måloversikten til venstre gir oppsummeringsinformasjon på høyt nivå og viser merkevarene de tre personaene samhandler med og forholder seg til. Den detaljerte beskrivelsen til høyre presenterer en oversikt og biografi av en enkelt persona, sammen med informasjon om hennes oppførsel og motivasjon.

AVANSERTE PERSONER

123

Paul og Helen «Jeg antar at vi kan legge inn hva som helst der. Jeg er bare ikke sikker på hvor mye som vil passe.»

5 4

Helens mor døde for noen uker siden, og de er akkurat nå i ferd med å tømme huset. De planlegger å selge huset, men det er ganske mye de må rydde opp først. Huset trenger også noe oppussingsarbeid på hovedbadet.

- av de Kjelleren er fylt med ting Helens mor har samlet i løpet av de siste par årene. Hun kastet aldri noe. Hun har aviser og Time-magasiner fra de siste 20 årene. Det er et par ting Helen ønsker å beholde. Det meste av klærne - "college og møbler vil bli donert til Goodwill. Dessverre har det meste av morens leketøy blitt ødelagt av vann og mugg. Hun har også malingsbokser, men Paul og Helen vet ikke om malingen inneholder bly eller ikke.

2 1

ain

Know Ex led pe geri nc e C on Pric ve e Senior tunc pe sp Re e M pu e dult type Tim tion C on eline t Main ss ajo er r L Størrelser D E ecven lu tte t År Re rding pe Wast Sats i Buars dsine Pris og O Rec am nlin ycli ne ac g teller

Dette er første gang Paul og Helen har gått gjennom noe slikt. De vet ikke engang hvor de skal begynne. De vil bare at dette skal være så enkelt som mulig. De vet at de trenger en søppelcontainer, men er ikke sikre på hvor mye den vil holde. Og de antar at omtrent alt kan gå i søppelcontaineren, med mindre noen forteller dem noe annet. Deres eneste andre bekymring er at søppelcontainere har en tendens til å være stygge. De håper å finne et selskap som ikke vil få forgården til å se ut som en byggesone eller ødelegge gården når de leverer eller henter søppelcontaineren.

Alder: 24-65

Livssyklus Jan

jul

des

Måned

1.0 Livsbegivenhet

Nøkkelegenskaper Ŕ Ŕ

Enkelthendelse som anskaffelse av en familieeiendom eller en liten ombyggingsjobb (f.eks. bad). Lite om noen tidligere erfaring med å anskaffe en søppelcontainer.

Mål Ŕ Ŕ Ŕ Ŕ Ŕ

Få en søppelcontainer raskt. Bli kvitt alt de ikke beholder eller donerer. Unngå ødeleggelse av eiendommen under prosessen. Unngå en stygg søppelcontainer. Bli kvitt søppelcontaineren raskt når den er fylt.

Frustrasjon og smertepunkter Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Spørsmål Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Ŕ ŕ

Tilgjengelig ved behov Pris Leverandøren forlater eiendommen slik de fant den Å ha den nødvendige containerstørrelsen tilgjengelig Hastighet for oppsett og henting etter kontakt Online kontotilgang for planlegging og betaling Kvalitet og renslighet av utstyr Kjent merkevare

Ŕ ŕ ŕ ŕ

Innledende klistremerkesjokk Ukjent med prosessen Vet ikke hva de ikke vet Å gjøre en epler til epler sammenligning mellom leverandører

Er det noe som ikke kan gå inn? Hvor raskt kan de levere og hente? Vil de forlate eiendommen i den tilstanden den opprinnelig var? Hvordan virker dette? Er det nødvendig med tillatelse? Hvor mye vil det koste? Hvor lett kan jeg få tak i noen hvis jeg trenger det?

Figur 7.6 Målgruppepersona. Denne personaen presenterer et aldersgruppemål, hentet fra forskningsdata. Informasjonen den inneholder er bred og taler til publikumsgruppering, ikke spesifikke individer. Denne tilnærmingen kan være nyttig når du lager en forretningspitch eller når kundens budsjett tillater detaljert utforskning av personas. Med tillatelse fra Todd Zaki Warfel.

The Jill of All Trades

Amanda Stone

"Jeg må administrere flere programmer for kundene mine."

AMANDA DELER INSENTIVPROGRAMANSVARET MED NOEN ANDRE kolleger. De deler tilgang og administrerer flere programmer for klienter. Dette kan være spesielt utfordrende å sørge for at hun betaler de riktige personene på riktig program. Hun må kunne bytte mellom de forskjellige programmene og vite hvor hun er til enhver tid.

Livssyklus

Nøkkelegenskaper Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Administrerer flere programmer Middels til stort selskap Moderat volum (50-2000+ bestillinger om gangen) Flere personer som deler en enkelt rolle 70/30 Quick Pay og Admin Sjekker Ukentlig til annenhver måned bruk Hele året Veldig interessert i rapportering Ønsker å kjøre rapporter på tvers programmer Heavy Excel bruker tilpasset internt system å grensesnitt med

Mål Ŕ Ŕ Ŕ Ŕ

Integrasjon med dagens system. Evne til å betale ansatte raskt og enkelt. Kostnad (for det meste tid). Veiledet hjelp.

Andre programmer Ŕ Excel Ŕ PowerPoint Hvordan kjører jeg rapporter på tvers av alle programmene mine? Ŕ Internet Explorer Er det en måte å få påloggingsinformasjonen min uten å måtte ringe Ecount? Kan vi integrere med ClientZone på en eller annen måte slik at vi ikke trenger å gå så mye frem og tilbake mellom ulike applikasjoner. Gjør jeg det riktig?

Ac FT N c ew ou P n C ar t Zo d Rene qu es t E A asy s m Pa in y C he c R Cu ep ks or n rting tB al Peace Cu opl e st om S o f t Sy st em Ex ce l

nc e

Jan

Påvirkere

Betal ansatte raskt og enkelt. Ŕ Forhindre duplisert innsats. Se hva deres gjeldende saldo er for å vite om de trenger å overføre penger. Ŕ Spor transaksjoner ukentlig, annenhver måned, måned, kvartal og år.

rie

på eks

dg og ow Kn

Kn y

og ol

Hun bruker Account Zone ganske regelmessig – flere dager i uken. Og siden hun administrerer flere programmer, er hun ganske aktiv hele året.

Aktiviteter og interesse

Te c

Alder: 28-55

Kunnskap

ain

Account Zone hjelper henne virkelig med å utstede nye kort og sørge for at programdeltakerne får betalt raskt. Det eneste hun mangler er muligheten til å se på hvert enkelt program så vel som på tvers av alle programmene hun kjører for å se hvordan ting går. Kundene hennes liker å følge med på hvordan programmene fungerer. Akkurat nå sporer hun det i Excel. Hun ender opp med å enten sende Excel-filen til kundene sine, eller noen ganger eksportere dem og sende en PowerPoint med noen fine diagrammer. Hvis Account Zone hadde en måte å la henne kjøre rapporter om individuelle programmer og på tvers av flere programmer, ville det vært virkelig fantastisk.

jul

Ŕ ŕ ŕ ŕ ŕ ŕ

Måned

Frustrasjoner og smertepunkter

Spørsmål –

des

Kan ikke se på flere programmer samtidig. Kan ikke kjøre rapporter på tvers av flere programmer samtidig. Å rette feil i mottaksfilen "stinker". Å vite hva det eksakte problemet er og hvordan det skal løses er ikke klart. Flere trinn med flere applikasjoner er ikke effektivt og gjør det enkelt å "gå seg vill" der hun er. Flere bekreftelsesskjermer. Et annet brukernavn og passord å huske. Finner e-post med påloggingsinformasjonen hennes.

Figur 7.7 Målgruppe individuell persona. Denne personaen er en tungt datadrevet modell. Mens historien om dagen i livet er en fortelling, er resten gitt i punkt for å tjene som en designsjekkliste. Diagrammet brukes til å kommunisere en betydelig mengde informasjon på et lite rom. Med tillatelse fra Todd Zaki Warfel.

124

KAPITTEL 7: PERSONER

Som du kan se, kan du kombinere data på mange forskjellige måter for å presentere personas, skreddersy dem til en rekke situasjoner. Start med den grunnleggende personligheten og utvid den for å passe dine behov.

Siste tanker om personas Mange utøvere i brukeropplevelsesdesignverdenen tror ikke at personas gjør en god jobb med å artikulere brukernes behov, mål og holdninger. De tror at personas kan hindre kreativitet, innovasjon eller god design av en rekke årsaker. Andre praktikere mener at personas møter et spesifikt behov som påvirker designprosessen på en veldig positiv måte – når de er basert på solide forskningsdata og blandet med en dose personalisert virkelighet. Hvilken side av mynten du lander på er helt opp til deg. Dette kapittelet er ikke ment å påvirke avgjørelsen din på den ene eller den andre måten. Mange artikler om emnet er tilgjengelige på nettet, og mange fagfolk er klare til å gi deg sitt syn. Alle disse ressursene kan hjelpe deg med å finne ut hvordan personas vil fungere best for prosjektene dine, så søk etter dem. Jared Spool, administrerende direktør og grunnlegger av User Interface Engineering (www.uie.com), gir også litt innsikt i emnet: Denne verdien kommer når teamet besøker og observerer målgruppen deres, absorberer og diskuterer observasjonene deres, og reduserer kaoset. inn i mønstre, som så blir personas. Det som sitter i teamets hode, mens de designer, er det som vil utgjøre en forskjell i det endelige designet. Personabeskrivelsene er bare der for å minne alle om hva som skjedde.

Jareds poeng er enkelt: Ved å se på målgruppen din, tilføre forskningsdata det du lærer og syntetisere alt dette i segmenter, bør du være i stand til å skape personas som trigger den typen empati som holder teamet ditt på sporet og bygger det beste. mulig applikasjon, nettsted eller produkt. Til syvende og sist kommer personasene dine til å være mye som julenissen: De vil bare være verdifulle så lenge folk tror på dem.

ENDELIG TANKER OM PERSONAS

125

Brukeropplevelsesdesign og søkemotoroptimalisering User Experience Designs grunnleggende rolle i vellykket SEO Søkemotorer er hjørnesteinen i den interaktive økonomien. Alt vi gjør som "interaktivister" er til syvende og sist knyttet til verden for øvrig gjennom Google, Yahoo, MSN, Ask og de utallige mindre motorene som utgjør infrastrukturen for å finne ting på nettet. Informasjonsarkitektur er en kritisk komponent i hvordan nettsteder tolkes av søkemotorer. Dette kapittelet er utformet for å gi deg en grunnleggende forståelse av hvorfor UX-design er avgjørende for søkemotoroptimalisering og hva du må ta hensyn til for at miljøene du lager skal ha en sjanse til å kjempe på Google. Jonathan Ashton

Introduksjon til SEO Enkelt sagt er søkemotoroptimalisering prosessen med å utvikle og vedlikeholde et nettaktivum med den hensikt å oppnå og beholde toppplassering på offentlige søkemotorer for spesifikt målrettede søkeordsetninger. Søkemotoroptimalisering (SEO) er som en kampsport, en prosess med å lære og gjøre som aldri blir fullført. Selv en mester kan komme videre ved å bruke observert atferd eller innlært metode. Så lenge det er søkemotorer og nettsteder som er interessert i å selge noe til folk som søker, vil det være en rolle for søkemotoroptimalisering. SEO er avhengig av tre grunnleggende områder for forbedring og innflytelse: Den kritiske gruppen av ting som den profesjonelle brukeropplevelsesdesigneren

kan påvirke nettstedets infrastruktur, teknologi og organisasjonsprinsipper Innhold og alle nøkkelordspørsmål som er relatert til optimaliserte ord som

søkemotorene kan se koblinger, eller lenkepopularitet – mengden og kvaliteten på lenker som peker på deg

nettsted fra andre nettsteder, samt organisasjonsstrukturen til lenkene inne på nettstedet. Vi vil ta fra hverandre hvert av disse tre områdene og undersøke dem fra UX-designerens perspektiv, for å bedre ruste deg for optimaliseringsutfordringene som ligger foran deg.

Hvorfor er SEO viktig? Det er interessant at vi selv i dag må forklare relevansen av søkemotoroptimalisering. Kunder har en tendens til å forstå på et eller annet nivå at det er viktig for nettstedene deres å tiltrekke seg målrettede besøkende fra de naturlige søkeresultatene til hovedsøkemotorene, men utover det er det vanskelig for de fleste interaktive markedsførere å forstå hvilken effekt SEO kan ha. Data om globalt søkevolum er tilgjengelig fra en rekke kilder, men det som er viktigst å forstå er at, uansett kilde, er tallene ganske enkelt enorme, og økningen fra år til år er alltid tosifret. For det meste øker det globale volumet av søk hvert kvartal. Da Google ble lansert for første gang i 1998, var 10 000 søk om dagen et enormt volum og la en utrolig belastning på betaversjonen av systemet.

INTRODUKSJON TIL SEO

127

Hitwise (www.hitwise.com) rapporterer at Google og dets tilknyttede selskaper (inkludert AOL og YouTube) eier brorparten av søkene globalt, med nesten 72 prosent av amerikanske søk utført i november 2008. Yahoo er et fjernt nummer to, med nesten 18 prosent , og MSN og Ask.com ligger på henholdsvis 4 prosent og 3 prosent. Internasjonalt er Google enda mer dominerende: Markedsandelen når mer enn 80 prosent i mange markeder. Merk For mer bakgrunn om Googles tidlige dager, se The Google Story, av David A. Vise og Mark Malseed (Delta, 2008). I følge comScore (www.comscore.com) var det i 2008 lett mer enn 60 milliarder søk per måned utført globalt av 750 millioner mennesker, med over 18 milliarder søk utført i USA alene. For å si det på en annen måte, bruker 95 prosent av Internett-brukere en søkemotor minst en gang i måneden, med et globalt gjennomsnitt på mer enn 80 søk per måned.

Bortsett fra disse bemerkelsesverdige volumtallene, hva betyr dette egentlig på et praktisk nivå for interaktive markedsførere? Enkelt sagt, hvis du ikke når målkundene dine når de søker etter produktene eller tjenestene dine, får konkurrentene dine muligheten til å selge til dem. Se på nettstedets analyse og tenk på problemet på denne måten: Hvor mye mer inntekt ville nettstedet generere hvis det var en 10 prosent økning i strategisk målrettet trafikk? Hva med en 100 prosent økning? Eller 1000 prosent? Hvis nettstedet ditt ikke genererer meningsfylt trafikk gjennom naturlig søk, er SEO et krav. En liten investering i SEO kan gå veldig langt, spesielt hvis den interaktive markedsføringsinnsatsen til dags dato har fokusert på å kjøpe klikk gjennom sponsoroppføringer. Vi har sett nettsteder oppnå en avkastning på investeringen på 35 til 1 på månedlige SEO-utgifter. Hvis du betaler søkemotorselskapene for trafikk fra sponsede oppføringer, men du ikke investerer i naturlig trafikk, begrenser du deg egentlig til omtrent 10 prosent av muligheten. Tenk på din egen søkeatferd: Når var siste gang du klikket gjennom mer enn én eller to av de betalte sponsoroppføringene i et søkeresultat? Enhver diskusjon om hvorfor SEO er viktig og hvorfor den er kommet for å bli kan fortsette i kapitler. Det er nok å si at Google ikke går andre steder enn opp, og at effektiv interaktiv markedsføring må inkludere søkemotoroptimalisering som en kjernekomponent i kompetent utførelse.

128

KAPITTEL 8: BRUKEROPPLEVELSE DESIGN OG SØKEMOTOROPTIMERING

Viktige grunnleggende ressurser Kompetanse kommer fra en godt avrundet utdanning. Den profesjonelle som rett og slett fokuserer på sin spesialitet mister perspektivet på alt annet rundt. Det er derfor det er viktig at hver interaktivist bruker minst noen få minutter på å lære om SEO. Selv om det ikke finnes noen offisielle retningslinjer, har Google vært snill nok til å tilby noen svært fremtredende ressurser. Hvis du i det hele tatt er interessert i å få bedre søkemotorytelse fra innsatsen din, sjekk ut disse koblingene: Hjelp til nettredaktører/sideeiere: Søkemotoroptimalisering:

www.google.com/support/webmasters/bin/ answer.py?hl=no&answer=35291 Hjelp for nettredaktører/nettstedeiere: Retningslinjer for nettredaktører: Kvalitetsretningslinjer:

www.google.com/support/webmasters/bin/ answer.py?hl=no&answer=35769 Startveiledning for søkemotoroptimalisering:

www.google.com/webmasters/docs/ search-engine-optimization-starter-guide.pdf Hvis det ikke er nok, drukne deg selv i nyhetsbrev og blogger. Start på SEOmoz.org og grav ned. Bare husk, som i alle andre ting i livet, hvis det høres for godt ut til å være sant, så er det sannsynligvis det.

Nettstedteknologi, design og infrastruktur Søkemotorer er i hovedsak Web 1.0.5-teknologi som er godt implantert i Web 2.0+-verdenen. Den grunnleggende forutsetningen for søkemotoren har endret seg lite siden World Wide Web Wanderer ble lansert i 1993 for å gjennomsøke nettet og bygge den første nettsøkemotoren. I hovedsak har hver søkemotor en applikasjon som vekselvis kalles en crawler, edderkopp eller bot som finner og følger koblinger, og sender tilbake til databasen en kopi av ressursene den kan se. Databasen blir deretter analysert i henhold til søkemotorens proprietære algoritme. Ved å bruke disse reglene indekseres et nettelement og rangeres deretter i henhold til hvor godt det scorer på søkemotorens spesielle resultatkort. I denne ganske enkle prosessen er en myriade av fallgruver for UX-designeren.

STEDETEKNOLOGI, DESIGN OG INFRASTRUKTUR

129

Å forstå disse kjerneforholdene vil gjøre det mulig for deg å se nettstedet ditt gjennom søkemotorenes øyne. Et optimalisert nettsted er avhengig av en struktur og teknologi som letter bevegelsen av søkemotoredderkoppene. På samme måte bestemmer mange beslutninger om håndtering av innhold hvor godt søkemotorene rangerer den resulterende innsatsen. Som et resultat av dette er mye av dette forhåndsbestemt av beslutningene som tas i wireframes og i diskusjonene som finner sted rundt hvordan man skal style og administrere innhold.

Flash, Ajax, JavaScript og annet skriptinnhold Dagens dynamiske og interaktive webdesign er avhengig av teknologier som slett ikke er tilpasset behovene til søkemotorene. Det er et økende gap mellom hva søkemotorer kan se og hva designere kan gjøre. Det er opp til UX-designeren å være sikker på at de strategiske planene for dynamiske, designintensive nettsteder blir distribuert slik at både søkemotorene og brukerne får best mulig opplevelser. Å ha en grunnleggende forståelse av hvordan søkemotorer samhandler med denne typen innhold, vil hjelpe deg med å bestemme når du skal distribuere det og hvor du skal kompensere for svakhetene. Det er fullt mulig å bygge et optimalisert nettsted som er sterkt avhengig av skriptinnhold hvis de riktige kompensasjonene er på plass i begynnelsen av prosessen. Det er betydelig vanskeligere å bygge statisk eller indekserbart innhold når siden først er bygget og live. Så kom med et kraftfullt argument for statisk innhold, på grunnlag av brukervennlighet og av hensyn til søkemotorenes crawlere. Det kan virke som ekstra arbeid i forkant, men avkastningen på investeringen er eksponentiell. Flash Flash-innhold er teknisk sett "indekserbart". Det har vært noen nyere fremskritt i søkemotorenes evne til å se inn i Flash-filer for å finne teksten og koblingene som er innebygd i disse ressursene. Selv om dette innholdet er indeksert, har du noen gang sett en all-Flash-aktiva vinne toppplassering i søkeresultatene? Du har sannsynligvis ikke gjort det fordi det er risikabelt for søkemotorer å åpne seg for full kompatibilitet med Flash. La oss anta at søkemotorene fullstendig kan se alle koblingene og tekstinnholdet som er innebygd i SWFobject. Hva hindrer en uetisk (eller "svart hatt") optimizer fra å legge epler i tekstlagene til objektet mens den viser

130

KAPITTEL 8: BRUKEROPPLEVELSE DESIGN OG SØKEMOTOROPTIMERING

appelsiner til den menneskelige brukeren som ser på de fullstendig kompilerte ressursene gjennom en nettleser? Hvordan kan du dyplenke til et Flash-element uten at det er fullstendig kompilert? Disse grunnleggende sårbarhetene vil forbli til søkemotorene kan nå et visst nivå av kunstig intelligens som kan fortelle at et bilde er et bilde av en hest uten en tilknyttet tekst som sier «dette er et bilde av en hest». For å bygge et Flash-nettsted som er kompatibelt med søkemotorer, må du legge til et statisk lag med innhold som dupliserer Flash-innholdet. Ser man bort fra behovene til søkemotorer for øyeblikket, er et statisk lag med innhold en nøkkel for å overholde brukervennlighetskravene. Tenk på søkemotoren som personen som ser på nettinnhold over en oppringt tilkobling eller bruker en skjermleser. Disse menneskene kan være den laveste fellesnevneren, og det er mulig at strategien bak webutviklingen din gir rabatt på denne svært lille prosentandelen av menneskelige brukere. Men når du gir rabatt på denne håndfullen, gir du også rabatt på GoogleBot og Yahoo Slurp – de to viktigste besøkende på nettstedet ditt, siden de er søkerobotene som vil gjøre det mulig for de store søkemotorene å indeksere nettstedet ditt. Hvis ingen tekstord eller spiderable lenker er synlige for søkemotorene, vil innholdet ditt uunngåelig ikke være ﬁnbart gjennom meningsfulle søkeresultater. Et statisk lag kan oppnås på en rekke måter. For å overholde søkemotorkravene, må det statiske innholdslaget speile Flash-innholdet. Dette er ikke en mulighet til å vise søkemotorene noe annet enn det som er distribuert i Flash; hvis du gjør det bryter du med spillets ånd og står på den mørke siden. Den ideelle måten å bygge inn Flash-innhold i et statisk lag er å bruke SWFobject slik at både Flash og statisk innhold kan leve på samme URL. Dette vil tillate søkemotoren å finne det statiske innholdet og den Flash-aktiverte nettleseren for å vise animasjonen i stedet for det statiske innholdet. Hvis det er mulig, ikke bruk omdirigering slik at du kan bevare populariteten til lenken som peker til Flash-innholdet. Google Code gir et enkelt sett med instruksjoner for implementering av denne enkle JavaScript-delen på http://code.google.com/p/swfobject. Det er et annet alternativ som kjører på den grå siden av SEO. Tilsløring kan være et skittent ord for SEO-purister, men hvis du nærmer deg følgende utfordringer fra høyre side, kan du ha litt kake og spise den også.

STEDETEKNOLOGI, DESIGN OG INFRASTRUKTUR

131

Tilsløring utnytter brukeragentdeteksjon, oppdager søkemotorsøkeprogrammer når de besøker et nettsted og dirigerer dem til statiske sider som skal indekseres. Men når en menneskelig besøkende ser den samme siden i søkeresultatene og klikker på koblingen, oppdager nettstedet at brukeragenten er et menneske med en Flash-aktivert nettleser og viser vedkommende den dynamiske opplevelsen på en helt egen URL. Problemets kjerne forblir den samme som med SWFobject-metoden: Du må vise søkemotorene nøyaktig de samme tingene i det maskerte innholdet ditt som du gjør i Flash-innholdet. Ajax, JavaScript og annet skriptinnhold Ajax er en kraftig driver for Web 2.0-innhold, og gir webutviklere muligheten til å bygge sideløst innhold. Problemene som søkemotorer har med Ajax er imidlertid flerfoldige og krever god planlegging for å unngå store feil. Ajax står for Asynchronous JavaScript And XML, som antyder vanskelighetene søkemotorer har med denne teknologien. Søkemotorer kan i hovedsak ikke håndtere JavaScript; effektiviteten som JavaScript gir utviklere er problemene søkemotorene har med dynamisk innhold. Et ekstra problem søkemotorer har med Ajax er teknologiens asynkrone natur. En søkemotor kan bare se innholdet av den første sideinnlastingen, og alt innhold som lastes gjennom et skript som finner sted etter de første skallinnlastingene, vil ikke være synlig for indeksering. Fordi Google ikke kan forlenge en økt utover den første sideinnlastingen og ikke har en mus eller ekstern agent for å aktivere et skript, vil alt sideløst innhold som aktiveres av brukeren være usynlig med mindre tekstinnholdet er inkludert i det forhåndslastede skallet . Det er opp til UX-designeren å være sikker på at den tredimensjonale modelleringen som er nødvendig for å strukturere sideløs design også inkluderer kravet om at tekst og lenker alle forhåndsinnlaster i sideskallet. Alt annet, og det kule designet ditt er usynlig. Skriptnavigering Et av de vanligste problemene som vil hemme optimalisering er bruken av JavaScript i kjernen av nettstednavigering. Dette er en svært vanlig tilstand og er et resultat av måten mange nettstedsutviklings- og innholdsstyringsverktøy fungerer på. Den skriptede navigasjonen ser kulere ut, så folk har en tendens til å være interessert i å bruke den. Men hvis JavaScript er teknologien som driver nettstedets navigering, er resultatet at søkemotorer ikke kan bygge en modell av koblingen på riktig måte

132

KAPITTEL 8: BRUKEROPPLEVELSE DESIGN OG SØKEMOTOROPTIMERING

relasjoner på nettstedet: De kan ganske enkelt ikke se lenkestrukturen til nettstedet. Og hvis søkemotorene ikke kan modellere koblingsforholdene på nettstedet, vil dypt innhold være usynlig eller vil ikke bli tildelt riktig lenkepopularitet.

Innholdsstyringssystemer Innholdsstyringssystemer er bygget for å gjøre det lettere for mennesker – men mange av disse systemene gjør det vanskelig for søkemotorer å håndtere resultatene deres. Følgende er noen typiske problemer som må unngås, enten ved å bruke løsninger eller velge et innholdsstyringssystem som er mer søkevennlig: Dynamiske URL-er. Søkemotorer forstår ikke en "side" med innhold; den

forstår veien til det innholdet. En endring i banen, eller URL-en, som fører til det innholdet, fører til at søkemotorene ved et uhell kloner innholdet flere ganger. Denne tilstanden svekker i betydelig grad et nettsteds evne til å gjøre det bra. Hvis innholdsstyringssystemet har et system som oppretter økt-ID-er i URL-er, kan du være i virkelig trøbbel. Spor med moden analyse, ikke økt-ID-er. Flere URL-baner. Et typisk problem med e-handelsinnhold

alder er at etter hvert som et produkt utvikler seg gjennom livssyklusen, samler det seg flere nettadresser. Igjen, siden søkemotoren bare kan forstå en side med innhold basert på nettadressen der den finner innholdet, når et produkt vises i en kategori og er en del av en gavekurv og er en ukentlig spesialitet (og videre og videre), ganske snart har søkerobotene fulgt en haug med forskjellige lenker for å finne det samme innholdet. Gjør alt du kan for å sikre at hvert innhold bare finnes på én URL og at flere stier faktisk er avhengige av én URL, uavhengig av hvor koblingene er distribuert. Stol på modne analysesystemer for å analysere kanaler. Utilsiktet kloning. Når du kommer til erkjennelsen av at et stykke

innhold skal bare være tilgjengelig via en enkelt URL-bane, det er lett å se andre forhold i innholdsstyringssystemer som gjør at innhold utilsiktet klones. Det er nok å si at arkitekturen bare må ha en enkelt URL-bane til et enkelt innhold. Uendelige løkker. En konsekvens av problemet med utilsiktet kloning er inﬁ-

natt løkke. Pass på at du ikke legger søkemotoredderkoppene inn

STEDETEKNOLOGI, DESIGN OG INFRASTRUKTUR

133

en potensielt uendelig oppgave med å følge «neste»-lenker i en kalender eller lignende situasjon. Hvis søkemotoredderkoppen kan krysse en neste lenke til neste dag i en kalender hvor den kan finne en annen neste lenke, vil den følge den lenken til neste side, og videre og videre. Forhindre denne typen situasjoner ved å bruke en skriptet lenke som søkemotorene ikke kan følge, slik at robotsøkerne kan bruke tiden sin på innholdet du vil ha indeksert. Gamle URL-strukturer. Det første som mange ombyggingsprosjekter

ects er å erstatte den gamle URL-strukturen. Problemet er at søkemotorene sannsynligvis allerede har indeksert innholdet på disse gamle URL-ene, og så snart du endrer dem alle, sender du i hovedsak indekseringen tilbake til utgangspunktet. I tillegg peker eventuelle dyplenker som nettstedet har samlet over tid, mot den gamle URL-strukturen. Ta vare på så mange av de gamle nettadressene som mulig for enhver pris. Det er sannsynlig at når du erstatter innholdsstyringssystemet, må du endre alle URL-ene, så hvis dette er uunngåelig, sørg for å anbefale at de gamle URL-ene får statuskoden "301 Moved Permanently" og omdirigeres på en oneto -ett grunnlag fra de gamle URL-ene til de nye URL-ene. 301-viderekoblingen er den eneste akseptable viderekoblingen for søkemotorformål.

Domener, kataloger og URL-struktur er viktig Hvis du starter fra bunnen av, og hvis restriksjonene for merkevarebygging tillater det, kan du prøve å velge et domene som inneholder et nøkkelord eller to. Det er vanskelig i disse dager å få et .com-domene som har kvalitetssøkeord, men hvis du gjør det, skille disse søkeordene med bindestreker. En viktig del av hvordan UX påvirker SEO er i et nettsteds katalogstruktur. Den har en kritisk innflytelse på hvordan lenkepopulariteten fordeles over hele nettstedet. Enkelt er bedre. Unngå å ha overflødige filer i katalogstrukturen for enhver pris. Noen innholdsstyringssystemer vil automatisk sette inn en underkatalog; forhindre dette hvis det er mulig. Denne tilstanden fortynner relevansen til hele nettstedet. Søkemotorene forstår hierarkiet til nettstedet basert på måten nettstedkatalogene er strukturert på, så vær sikker på at de viktigste katalogene er øverst i arkitekturen. Hvis miljøet ditt tillater det, bruk søkeord i URL-strukturen som er relevante for delen av nettstedet. Skill søkeord med en bindestrek, og

134

KAPITTEL 8: BRUKEROPPLEVELSE DESIGN OG SØKEMOTOROPTIMERING

ikke bruk for mange nøkkelord i ett filnavn. Gå for noe som dette: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. I tillegg må du sørge for at du har omdirigeringer satt opp for http://site-in-question. com til 301 flyttet Omdiriger permanent til http://www.site-in-question.com. Hvis et nettsted vil løse seg med og uten www, vil søkemotorer (spesielt Yahoo) indeksere innhold på begge URL-ene, og åpne hele nettstedet for utilsiktet duplisering. Denne tilstanden har en tendens til å forplante seg når en tredjepart linker til nettstedet uten www og nettstedet inneholder en dynamisk lenkestruktur.

Innhold: The Once (and Current) and Future King Selv om det å generere innhold er andres problem, har grunnlaget som legges i nettstedsarkitektur mye å gjøre med å gjøre riktig innhold tilgjengelig for søkemotorer. Som med alle former for søkeorddrevet søk, må du forstå den faktiske søkeatferden til personene du vil se en ressurs. Søkemotorer er fortsatt veldig "primitive" ved at de er avhengige av at brukere skriver inn søkeord for å koble dem til eiendeler som er mer eller mindre relevante for disse ordene. Å velge de riktige frasene har alt å gjøre med om nettstedet ditt er relevant i riktig kontekst. I en perfekt verden vil SEO-partneren din gi deg et sett med søkeordsetningsmål før du begynner og vil samarbeide med deg gjennom wireframing-prosessen. Hvis det ikke er en slik kompetent partner involvert i prosessen din, kan du lese deg opp på Google AdWords søkeordundersøkelsesverktøy (https://adwords.google.com/select/KeywordToolExternal) og undersøke den faktiske søkeatferden til folk som utforsker kategorien din. Bruk deretter litt tid på disse innspillene for å finne ut setningene som potensielle kunder søker, og bruk disse setningene etter behov på hele nettstedet. Søkemotorer ser etter søkeord på en rekke steder gjennom analysen av et nettsted. Optimalisering er avhengig av å sørge for at de riktige ordene er på de riktige stedene. Ved å forstå nøkkelordenes rolle i UX-designprosessen, vil du etablere rammeverket som er nødvendig for å muliggjøre fremtidig suksess.

INNHOLD: DEN ENGÅENDE (OG NÅVÆRENDE) OG FREMTIDIGE KONGE

135

Så hvorfor er innhold konge? Det er selve kjernen i hva et nettsted er designet for å levere. Søkemotorer trenger tekstinnhold som de kan se og indeksere. Besøkende på nettstedet trenger engasjerende innhold som er verdig oppmerksomheten deres. Bloggere og webansvarlige trenger innhold som er koblingsverdig. Uten riktig innhold på de riktige stedene kan ikke søkemotorer koble de riktige besøkende til nettstedet ditt.

Navnekonvensjoner og kampen mot sjargong Det er viktig at søkeordmål gjenspeiles i taksonomien utviklet for et nettsted. Å bruke søkeordsetninger i hovednettstedets struktur gjør hele nettstedet mer relevant for tingene du selger. Hvis du selger widgets, ikke kall den elektroniske produktlisten katalogen, kall den widget-katalogen. På samme måte kan du bruke søkeordundersøkelsen din til å ta avgjørelser mot sjargong. Bruk for eksempel ordene bærbare datamaskiner i motsetning til bærbare datamaskiner i strukturen din fordi folk søker etter bærbare datamaskiner 10 000+ prosent oftere enn de søker etter bærbare datamaskiner.

Metadata, overskrifter og nøkkelord Det er ganske bemerkelsesverdig at vi har kommet så langt inn i kapittelet før vi graver tilbake i grunnleggende problemer med metadata. Et mylder av metakoder er tilgjengelige, men bare en håndfull har virkelig stor innflytelse fordi alle de andre er mottakelige for spamming. Relevante tagger er disse: Sidetittel. Vær oppmerksom på at dette ikke er -taggen, men er

faktisk tag i sideoverskriften. Denne taggen inneholder sidens faktiske tittel, og det er de viktigste 65 tegnene på siden. Tenk på tittelen som den lille fanen som stikker opp i den gammeldagse bibliotekskortkatalogen, som sier "Clements, Samuel" og indikerer at alle kortene bak den fanen er bøker av Mark Twain. Hver side på nettstedet må ha en unik sidetittel. Ikke legg inn nøkkelord i tittelen, og sørg for å forhåndsinnlaste tittelen med ordene som betyr mest. Meta nøkkelord. Denne taggen har praktisk talt ingen innflytelse på søket

motorer fordi den er så sårbar for spamming. Unntakene ser ut til å være at Google AdSense-syndikering ser på metanøkkelord-taggen og at Yahoo er påvirket på en veldig tertiær måte av den. Meta nøkkelord

136

KAPITTEL 8: BRUKEROPPLEVELSE DESIGN OG SØKEMOTOROPTIMERING

må samsvare med innholdet på siden, og denne taggen er faktisk et godt sted å sette inn potensielle feilstavinger. Det bør være forskjellig for hver side. Metabeskrivelse. Som med sidetittelen og metanøkkelord, vær sikker

at metabeskrivelsen er unik for hver side. Denne beskrivelsen er nettopp det: et sammendrag av hva som finnes på den aktuelle siden. Fortell det, ikke selg det, med omtrent 150 til 160 tegn. Dette innholdet er kritisk fordi det sannsynligvis er det søkemotorene vil vise under lenken til siden din. Hvis siden ikke inneholder en metabeskrivelse, vil søkemotoren lete etter en tekstbit eller annet innhold som inneholder søkeordene som er søkt på, og vise det i resultatene. Metabeskrivelsen handler mer om brukervennlighet enn SEO, så vær sikker på at hver side er riktig tagget. "Noindex" metatag. Hvis du har noen sider du ikke vil ha med

i søkemotorresultater, bruk noindex-metakoden. Bare vær sikker på at sider du ønsker å bli indeksert ikke utilsiktet inneholder denne taggen. Overskrifter. Søkemotorer gjenkjenner overskriftene , og så videre

som påvirkningsfaktorer så lenge du ikke spammer med dem. Pass på å tillate deloverskrifter som både er beskrivende og inneholder relevante søkeord for den siden. Link ankertekst. Linkankertekst er en viktig påvirkning av hva

søkemotorer tenker på siden på den andre siden av lenken. Dette er faktoren som skaper "GoogleBomb". Hvis nok lenker peker på en side med samme lenkeankertekst, tolker Google destinasjonen som relevant for frasen i ankerteksten. For eksempel, hvis du søker på Google etter "klikk her", vil Adobe-nettstedet vises i toppresultatene. Det er hundretusenvis av lenker som peker på Adobe og leser "klikk her for å laste ned Adobe Reader" eller noe lignende. Bruk dette til din fordel; ankertekst skal ikke være "Mer" eller "Klikk her." I stedet bør den inneholde søkeord som er relevante for destinasjonssiden.

Del hårene Det er til din fordel å ha separat indekserte sider for både venstrehendte bølgede widgets og høyrehendte bølgede widgets. Dette granularitetsnivået gir sidene dine en bedre sjanse til å være en eksakt match for de legendariske long-tail-søkene. En side som handler om én ting har en

INNHOLD: DEN ENGÅENDE (OG NÅVÆRENDE) OG FREMTIDIGE KONGE

137

bedre sjanse for å vinne for den ene tingen enn en side som handler om flere ting (alle andre faktorer er like selvfølgelig). Og hvem er interessert i å lese en side som er hundrevis av ord lang uansett?

Bruk Site Maps De siste årene har det blitt populært å utelate den klassiske sidekartsiden. Dette er en feil for brukervennlighet og en feil for SEO. Finn veien til det faktum at ethvert nettsted trenger et nettstedskart. Det er kanskje ikke kult, men det er nødvendig. Inkluder også nettstedskartfiler på /sitemap.xml og /sitemap.txt. Selv om denne strukturen ikke hjelper nettstedet til å rangere bedre, hjelper den søkemotorene med å forstå katalogstrukturen og finne nytt og oppdatert innhold.

Hold innholdet friskt En nøkkelkomponent for å oppnå og beholde toppplassering i søkeresultater er å kontinuerlig oppdatere innholdet på nettstedet. Dette betyr ikke å redigere alt innholdet på nettstedet hele tiden; det betyr at siden må vokse hele tiden. Bygg katalogstrukturen slik at det blir enkelt og intuitivt å legge til innhold, og forutse at nettstedet vil vokse over tid.

Andre innholdsproblemer En grunnleggende utfordring i å håndtere brukeropplevelsen til et innholdsrikt nettsted er å forhindre kloning eller duplisert innhold. Se opp for å lage dupliserte sider med tilsynelatende ufarlige bekvemmeligheter som "utskriftsvennlig" innhold som er et eksakt duplikat av en side i en PDF eller lignende dokumenttype. Beskytt denne typen sider med skriptede lenker eller bruk koblingsattributtet rel=”nofollow”. Ikke gi rabatt på optimalisering for det store utvalget av digitale eiendeler som søkemotorer kan indeksere. Dette emnet vil utgjøre nesten et annet kapittel i seg selv, men det er nok å si at PDF-er, videoer, bilder og andre ikke-websider er en del av naturlige søkeresultater. Å strukturere innpakningene rundt disse eiendelene er kritisk, fordi søkemotorer trenger pekepinner til denne typen innhold. Søkemotorer kan for eksempel ikke fortelle at et innholdselement er en hesteveddeløpsvideo med mindre det er en lenke som peker til videoen med ankertekst som lyder "video av et hesteveddeløp" plassert i nærheten av tekst om hesteveddeløpsvideoer på siden kode.

138

KAPITTEL 8: BRUKEROPPLEVELSE DESIGN OG SØKEMOTOROPTIMERING

Å bruke alt-attributter er en annen måte å identifisere ikke-tekstlige eiendeler til søkemotorene og er alltid en god idé for brukervennlighetens skyld. Ikke lag blindveis innholdssider. Sørg for at selv bunnen av strukturen har lenker tilbake til hovedsiden, slik at søkemotoredderkoppene ikke blir sittende fast i en blindvei. Brødsmulekoblinger er en enkel måte å oppnå dette på hvis en sidetype ikke inneholder hovednettstednavigasjonen.

Link popularitet forklart Hvis det er en hellig gral av SEO, er det link popularitet. Det er hjørnesteinen i hvorfor Google fungerte så mye bedre enn de andre søkemotorene da det dukket opp på scenen. Linkpopularitet er en bestemmelse av kvaliteten og mengden av lenker som peker på et nettelement fra andre websider. Google bruker begrepet PageRank, og det er overfaktoren som kan overvinne mange andre mangler. Lenker er i hovedsak stemmer for et nettobjekt, og det antas generelt at noe som er interessant eller verdifullt for andre vil ha lenker som peker på det fra andre pålitelige nettressurser. Over tid har dette konseptet vist seg uvurderlig for å overvinne spamming, og er i sin kjerne et grunnleggende prinsipp for kvalitetssøkeresultater. Dette prinsippet er avgjørende for UX-designeren å forstå på grunn av måten koblingspopulariteten vil fordele seg på strukturen til et nettsted.

Typisk koblingspopularitetsfordeling I likhet med Richter-skalaen som brukes til å måle styrken til seismisk aktivitet, er Googles PageRank-system (oppkalt av Larry Page for seg selv) en logaritmisk skala som varierer fra 0 til 10. Dette betyr (i vilt generelle termer) at hvis én side har en PR på 4 og en annen har en PR på 5, PR 5-siden har 10 ganger lenkepopulariteten til siden med de 4. Det er viktig å forstå dette fordi PageRank distribuerer gjennom et nettsted basert på hierarkiet av lenker og strukturen til katalogene. Generelt sett, hvis hjemmesiden din har en siderangering på 5, bør primærsidene dine ha en PR på 4, sekundærsidene PR 3, tertiære sidene PR 2, og så videre.

LINKPOPULARITET FORKLART

139

Sider med flest interne lenker som peker på dem har en tendens til å ha størst lenkepopularitet. Sidene som er viktigst å vinne, må ha flest interne lenker som peker på dem. Dette inkluderer lenker i hovednettstedets navigering, nettstedskart, bunntekst og innebygde koblinger innebygd i tekst. Fordi koblingspopularitet er avgjørende for å rangere godt i søkeresultater, må du være så bevisst som mulig for å få så mye av den som mulig inn på sidene som inneholder "kjøpsforslaget". Hver side har en begrenset mengde lenkepopularitet som den kan bidra med til de andre sidene på nettstedet. En side som har en lenke på den som peker på en annen side, sender 100 prosent av den tilgjengelige verdien til mottakeren. En side som har hundre linker til hundre andre sider, sender 1 prosent av verdien til hver av disse hundre sidene. Hjemmesiden har en tendens til å ha størst koblingspopularitet, fordi hjemmesiden til et nettsted har en tendens til å ha flest koblinger som peker på den fra tredjeparts nettsteder. Dette betyr at hjemmesiden har mest verdi for å bidra til andre sider på nettstedet. Hvis det er en kritisk side som er en del av "salgsforslaget", legg inn en direkte lenke til den fra hjemmesiden slik at søkemotorene kan forstå hvor viktig denne siden er i forhold til resten av nettstedet. Hvis mulig, bygg en funksjon som kan rotere lenker til dypt innhold fra hjemmesiden.

Bunntekstkoblinger Når vi ser etter måter å organisere og kontrollere fordelingen av lenkepopularitet på hele nettstedet, husk at tekstlenker i bunnteksten på hver side er både en velsignelse og en forbannelse, og de vil ha en viss betydning for fordelingen av lenkepopularitet. på hele nettstedet. Typiske bunntekstlenker peker på personvernreglene og andre ikke-transaksjonelle sider, så hvis det kreves at disse lenkene er i bunnteksten, gjem dem bak en slags skripting, eller enda bedre, «nofollow» disse koblingene ved å bruke rel=”nofollow” link attributt. Dette vil forhindre at lenkepopulariteten til hver side lekker ut til sider som egentlig ikke trenger å rangeres i søkeresultatene. Det er også bedre å forhindre at koblingspopulariteten går over enn å fullstendig ekskludere sidene som bruker robots.txt.

140

KAPITTEL 8: BRUKEROPPLEVELSE DESIGN OG SØKEMOTOROPTIMERING

In-Content Cross-Linking Søkemotorer spiser opp lenker som er innebygd i tekst. Bare ikke overdriv. Noen skoler hevder at etter de første par lenkene i en tekstblokk gir ikke søkemotorene fordelaktig vekting. Sett de viktigste koblingene dine i begynnelsen av teksten og bruk lenkeankertekst som inneholder nøkkelord som er relatert til målsiden.

Spille systemet Hvem sier at søkemotoroptimalisering er alt arbeid og ikke moro? Søkemotorer kan bidra med ekte dollar til eiere av nettsteder, og i visse miljøer er det en reell tilnærming uten sperringer for å oppnå topprangeringer for enhver pris. Mer enn noen få søkemotoroptimaliserere har utnyttet kundene sine og belastet store penger for falske teknikker som kan ha positive resultater på kort sikt, men en ødeleggende effekt over tid. Gjennom årene har en rekke optimaliseringsteknikker blitt brukt av webmastere på jakt etter toppresultater. En av kjerneutviklingen innen søkemotorteknologi har vært arbeidet med å utvikle de smarte måtene som har blitt funnet å spille systemet på. Fra søkemotorenes perspektiv blir brukernes beste tjent med rene, svært relevante resultater øverst i alle søk. Fra perspektivet til mange søkemotoroptimaliserere er alt rettferdig i kjærlighet og SEO.

White Hat Versus Black Hat Det er enkelt og morsomt å karakterisere SEO-metoder som «hvit hatt» eller «svart hatt», men det er langt vanskeligere å skjelne hva som er hva. Mange white hat-optimalisatorer er purister, og sier i sterke, deklarative termer at viss teknisk administrasjon, innhold og koblingsmanipulasjon og andre tilnærminger rett og slett er forbudt. De svarte hattene ser på saken som en konkurranse som ikke har noe med juks å gjøre: Hvordan kan noe være juks hvis det ikke finnes en spesifikk skriftlig regelbok eller domstol? Tilnærmingen deres er mer på linje med et spill med katt og mus der katten har alle kortene og musen tåler å tjene noen seriøse penger: Ta en risiko, få en gevinst, og utbetalingen er stor. Men når søkemotorene fanger opp til deg (og de nesten

SPILLER SYSTEMET

141

alltid) vær forberedt på at nettstedet ditt blir utestengt eller i det minste ute av stand til å utføre når metodene oppheves.

Spamming med metanøkkelord Mange av "jukse"-teknikkene har vært basert på prinsippene for UX. En tidlig metode for å spille systemet var fylling av metanøkkelord – i hovedsak å fylle metanøkkelord-taggen med hundrevis av forekomster av epler når innholdet på nettstedet handler om appelsiner. Ved roten ble meta-nøkkelord-tilnærmingen laget for å hjelpe med taksonomien til det tidlige nettet. I dag, på grunn av all søkeordspammen, har denne delen av en nettside praktisk talt ingen innflytelse på søkeplassering. Søkemotorene oppdaget enkelt denne teknikken og var raskt i stand til å konstruere rundt den. Neste generasjon spam var litt vanskeligere å nøste opp, og hadde også sine røtter i UX-problemer.

Kloning og døråpningssider Både kloning og døråpningssider er metoder som brukes til å få et nettsted til å se større eller annerledes ut enn søkemotorene. Ved å klone en side om og om igjen, kan webmastere i hovedsak produsere svært målrettet innhold som raskt kan dominere for en spesifikk søkefrase. På grunn av denne praksisen er det viktig å være sikker på at arkitekturen din forhindrer utilsiktet kloning, siden søkemotorer er følsomme for duplikasjoner, med vilje eller på annen måte. Døråpningssider er en annen metode for å påvirke søkeresultater som strekker seg over det grå rommet mellom metodene for hvit hatt og svart hatt. På den ene siden sier Googles kvalitetsretningslinjer for nettredaktører at «døråpningssider … bryter med våre retningslinjer for nettredaktører» (www.google.com/support/ webmasters/bin/answer.py?answer=66355). Retningslinjene identifiserer døråpningssider som sider av dårlig kvalitet som er spesifikt optimalisert for et sett med søkeord som kanskje ikke er relevante for det faktiske nettstedet, eller som er nettsøppel. På den annen side, hvordan hjelper du søkemotorer med å få tilgang til innhold som er fanget i en ikke-spiderbar database eller er skjult på grunn av en teknologi som søkemotorer ikke liker? I sin positive definisjon er en døråpningsside statisk innhold av høy kvalitet som søkemotorer kan se og forstå samtidig som den gir besøkende en dør inn til dynamisk innhold. Dagens innholdsstyringssystemer blir bedre på kjerneproblemene som

142

KAPITTEL 8: BRUKEROPPLEVELSE DESIGN OG SØKEMOTOROPTIMERING

har nødvendiggjort denne tilnærmingen, men det kan likevel være svært nyttig å lage ekstra sider med det uttrykkelige formålet å vise søkemotorene en statisk representasjon av innhold som de ellers ikke ville vært i stand til å håndtere.

Link Spamming Nye metoder for spilling av systemet har sentrert seg om manipulering av linkpopularitet, et konsept som er kjernen i måten de moderne nettsøkemotorene fungerer på. Som diskutert ovenfor, bestemmer søkemotorer relevansen til et bestemt nettelement ved å analysere mengden og kvaliteten på lenker som peker på den siden fra andre steder. Søkemotoroptimaliserere har jobbet for å manipulere denne delen av puslespillet gjennom snikomdirigering, overbruk av underdomener, å gjøre hver side på et nettsted til «/index.html» og en rekke andre subtile manipulasjoner.

Noen endelige tanker Det er tvilsomt at dette er din første utforskning av søkemotoroptimaliseringsproblemer. Nå er det klart hvor mye et nettsteds arkitektur og relaterte problemer påvirker søkemotorytelsen. Det nåværende søkemiljøet er et kvantesprang foran enkel taksonomi eller struktur. Gjennomtenkt søkemotoroptimalisering starter med kvalitets-UX. Arkitekteringen av et nettsted er det kritiske punktet i dets livssyklus der det enten kan være bestemt for søkemotorsuksess eller satt opp for snarlig fiasko. Søkemotoroptimalisering er en strategi som aldri tar slutt, men kvalitets-SEO kommer aldri i gang uten den nøye oppmerksomheten til UX-designeren. Jonathan Ashton er visepresident for SEO og nettanalyse for Agency.com og driver dets Center of Excellence for SEO. Teamet hans leverer SEO-tjenester for hele selskapet, og sikrer at prosessen med å designe og bygge rike interaktive opplevelser resulterer i nettsteder som kan bli funnet på søkemotorer. Hans månedlige spalte, "Industrial Strength SEO," finner du på http://searchengineland.com/lands/columns/industrial-strength.php.

NOEN AFSLUTTENDE TANKER

143

Overgang: Fra å definere til å designe tid til å visualisere, prioritere og planlegge Du har nå en fin liste over forretningskrav og brukerkrav. Og du har informasjon fra brukerne dine for å fokusere diskusjonene dine. Så hva nå? Med mindre du er på Shangri-la av prosjekter, vil du ha et budsjett (trangt), en tidslinje (knust), eller begge deler som forteller deg at du må fokusere og administrere den listen på en eller annen måte. Dette kapittelet diskuterer noen av måtene du kan gå over fra definisjon til design, inkludert taktikk for å hjelpe teamet ditt med å visualisere løsningen som må utformes, prioritere funksjoner for å lage et enhetlig sett med krav, og planlegge designaktivitetene som vil følge i neste fase av prosjektet. Carolyn Chandler

kapittel 4 berørte ulike prosjekttilnærminger, eller metoder, og hvordan de påvirker måten du samarbeider med prosjektteamet og forretningsinteressenter. Den sammenlignet en fossefallstilnærming, som har definisjons- og designfaser atskilt med et godkjenningstrinn, med en modifisert fossefallstilnærming som har en viss overlapping i faser. Dette kapittelet diskuterer aktivitetene som kan oppstå i overlappingen mellom Deﬁnerings- og Designfasen.

Definer Design Utvikle

Dette punktet i prosessen er det rette tidspunktet for å ideisere og visualisere funksjoner som ikke dukket opp under interessenter

intervjuer eller brukerundersøkelser. Hvis du gjør dette med prosjektteamet før du prioriterer, kan du vurdere og planlegge for innovative funksjoner som møter både forretnings- og brukerbehov. Prioritere prosjektkrav. Dette innebærer å ta den integrerte listen

av forretningskrav, brukerkrav og prosjektteamideer og bestemme deres relative betydning for å oppfylle prosjektmålene. På dette tidspunktet vil du jobbe med utviklingsteamet for å forstå det generelle innsatsnivået som kreves for å oppfylle hvert krav. Planlegg aktivitetene og dokumentasjonen du skal bruke under utformingen. Dette

planlegging avgjør hvordan du vil jobbe med andre teammedlemmer og hvilke typer verktøy eller dokumenter de vil motta fra deg, for eksempel nettstedskart og wireframes (diskutert i kapittel 10 og 11). Dette kapittelet dekker hvert av disse tre områdene, og begynner med en metode for ideer og visualisering som er enkel for en UX-designer å bruke i samarbeid med prosjektteammedlemmer.

OVERGANG: FRA DEFINERING TIL DESIGNING

145

Et vanlig scenario Kravene er definert og godkjent, og du er midt i utformingen av funksjonene i planen. Midt i designprosessen innser du at å gi et bestemt verktøy vil være veldig nyttig for brukerne dine. Det er en spennende idé, men det er ingen krav som beskriver det nye verktøyet, så å inkludere det nå krever en endring av de prioriterte kravene. Du må argumentere for å endre kravlisten, spesielt hvis det betyr at noe annet må falle av listen (det vil ta tid å bestemme hva det er) – eller at prosjektplanen kan glippe. Det er en mulighet for at ideen ikke blir inkludert bare fordi den kom for sent i spillet. Selv om nye ideer kan komme når som helst i prosjektet, hjelper det deg å generere disse ideene tidligere og øke sannsynligheten for at de blir inkludert ved å sette av litt tid til å tenke ut funksjoner etter at kravinnsamlingen er fullført, men før prioritering. Det sikrer også at du tar deg litt tid til å vurdere innovative funksjoner som kanskje ikke har skjedd med bedriftens interessenter eller brukere.

Ideer og visualiser funksjoner UX-designere har et unikt sett med ferdigheter som bidrar til å bygge bro over det mentale gapet mellom ord (som krav) og bilder (som nettstedskart og wireframes). Så mye som folk snakker om krav og krangler om språk, vil de ofte ikke komme inn på samme side før de kan se konseptet representert visuelt. På den annen side, hvis du går inn i spesifikke visuelle detaljer for raskt, risikerer du å fokusere samtalen på mindre detaljer (f.eks. om et valg i et skjema skal være en alternativknapp eller et rullegardinalternativ) før du løser de store spørsmålene (som for eksempel om brukerne dine skal måtte fylle ut det aktuelle skjemaet i utgangspunktet). Det er mange konseptuelle designteknikker du kan bruke gjennom hele prosessen som hjelper til med å visualisere kontekst, flyt og historie på en måte som engasjerer andre før detaljert design begynner for alvor. Disse teknikkene vil også

146

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

få frem behovet for funksjoner som kan legges til kravdokumentet ditt før prioritering skjer. En slik teknikk er å lage storyboards i samarbeid: visualiseringer av bestemte brukerscenarier skissert på papir eller en tavle under et idédugnadsmøte. UX-designeren jobber deretter ut fra disse skissene for å legge til detaljer.

Den grunnleggende prosessen med storyboarding Forbered deg på storyboarding-økten ved å lage en liste over scenarier du ønsker å utforske. For å bygge scenariet, vurder følgende spørsmål og ta med svarene til økten: Hvem er hovedbrukeren i dette scenariet? Hvilken rolle spiller han? Dette er

hvor din brukermodell eller dine personas vil komme godt med. Hvis du har dem, ta dem med til møtet – de vil både fokusere samtalen og sikre at prosjektteamet ditt har en bedre forståelse av hvordan de kan bruke brukermodelleringsverktøy gjennom designfasen. Er den valgte brukeren en førstegangsbruker av nettstedet? Hvis ikke, er han en sporadisk

bruker, eller bruker han det ofte? Dette vil påvirke nivået på funksjonene du vil diskutere; en førstegangsbruker kan bli overveldet av antall valg som en hyppig bruker kanskje liker. Det kan være lurt å snakke gjennom scenariet to ganger for å avsløre ulike funksjoner som kan være nødvendig for hver gruppe, for eksempel hjelp i konteksten for nye brukere eller tilpasningsfunksjoner for hyppige brukere. Hvilket umiddelbart behov har ført denne brukeren til nettstedet? Hva prøver han på

oppnå, og hvorfor? Du kan generere tanker om dette ved å se på oppgavene på høyt nivå som dekkes i bedriftens eller brukerkravene dine, for eksempel «finn produktanbefalinger». Kanskje brukeren ønsker å finne produktanbefalinger fordi han trenger et par snøstøvler og vil sørge for at de ikke lekker og blir våte. Samle brainstorming-teamet ditt til økten. Dette teamet kan bare være deg og én annen person, eller det kan være en liten gruppe på tre eller fire andre personer. (Mer er mulig, men det kan være vanskelig å samle alle effektivt rundt en tavle og holde dem fokusert på oppgaven.)

IDÉER OG VISUALISER FUNKSJONER

147

Ideelt sett vil minst én person i gruppen være ansvarlig for å representere brukerens synspunkt. En annen bør representere forretningssynspunktet (for eksempel en forretningsinteressenter eller en forretningsanalytiker hvis denne rollen er representert i prosjektet). Dette betyr ikke at du ikke kan bytte perspektiv; du kan, og bør, vurdere både bruker- og forretningsbehov så mye som mulig under diskusjonen. Se avsnittet "Oppretthold en god spenning" for mer om balansering av bruker- og forretningsbehov. Når du har samlet teamet ditt, fortell dem formålet med aktiviteten: å forstå noen av funksjonene som kan være nødvendige for å møte forretnings- og brukerbehov og fokusere fremtidig designarbeid. Presenter svarene på spørsmålene ovenfor og listen over scenarier som skal diskuteres. Gå deretter opp til tavlen (eller legg blyanten på papiret) og still gruppen spørsmål om scenariet, for eksempel Hvordan er det sannsynlig at denne brukeren kommer til nettstedet? Vurder online søk, banner

annonser, jungeltelegrafen og andre veier. Hvis nettsøk dukker opp, reflekterer kravene nøyaktig

hvilke typer funksjoner eller aktiviteter (som tagging for SEO-behov) for å støtte dette søket? Når du først er på siden, hva ser brukeren som vil være relevant for deres behov? Hvilken vei vil brukeren ta for å fullføre oppgaven? Skisser dette med

detaljer på høyt nivå. Er andre involvert i oppgaven? I så fall, hvordan kan de være involvert

(telefon, e-post, samarbeidssidefunksjoner), og hvordan kan de påvirke beslutningene eller atferden til hovedbrukeren? Hvor er det sannsynlig at en bruker trenger hjelp underveis? Hvordan skal han få det? Hva skjer når brukeren fullfører oppgaven sin? En vanlig designfeil-

ta er å tro at du er ferdig når brukerens oppgave er fullført, men det er et flott tidspunkt å oppmuntre brukeren til å utforske andre områder av nettstedet eller vurdere å kjøpe relaterte produkter. Tenk på et eksempel fra et vanlig forretningsscenario: behovet for å legge ut en ny jobb på selskapets .com-side. Av hensyn til dette scenariet, si at du har gjennomført interessentintervjuer og funnet ut at ansettelsesprosessen primært styres av én person, kall ham Jeff, i personalavdelingen, som jobber med de som trenger å ansette. 148

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

Jeff er ganske kjent med stillingsbeskrivelsene som eksisterer for øyeblikket. Når det trengs en ny, finner han vanligvis ut når den potensielle lederen for den nye stillingen ber ham om å legge ut en jobb. Det er deretter en samarbeidsprosess mellom Jeff og lederen (la oss kalle henne Emily) for å skrive opp og legge ut stillingsbeskrivelsen. Figur 9.1 illustrerer hvordan storyboardet for dette scenariet kan se ut. Figuren viser bare én del av storyboardet du kan lage her. Du vil kanskje starte tidligere i scenariet for å vise godkjenningsprosessen Emily måtte gjennom, eller du vil kanskje fortsette storyboardet for å vise en jobbjeger som finner og søker på jobben. Det som er viktig å merke seg her er at et storyboard som dette lar deg og prosjektteamet ditt se arbeidsflyten som mer enn en rekke sider. Det bringer inn det menneskelige elementet og konteksten. Og uten det menneskelige elementet av en persona (Jeff), kan det hende at teamet ditt ikke har tenkt på å inkludere funksjonen med å trekke inn en eksisterende stillingsbeskrivelse å starte fra – selv om vi alle har gjort dette som en måte å spare tid og sikre at vi inkluderer alt vi trenger.

Figur 9.1 Et storyboard som opprinnelig ble opprettet på en tavle, deretter skissert og detaljert i Microsoft Visio ved hjelp av et Wacom-nettbrett

IDÉER OG VISUALISER FUNKSJONER

149

En ting å huske på når du bruker storyboards og andre typer skisser (som brukerflyter og konseptuelle wireframes) er at de først og fremst er ment å være idédugnadsverktøy. Selv om noen gode ideer kommer ut av øvelsen, er ikke disse skissene ment å være detaljerte design. Dette faktum kan være tydelig fra skisseskjemaet deres (i motsetning til prototypeskjemaet), men det er fortsatt et viktig poeng å gjøre med forretningsinteressenter, fordi det å se funksjoner visualisert selv i en skisse noen ganger kan føre til forventninger om at de vil eksistere i sluttprodukt. En annen risiko her er at deltakerne kan komme på sidespor i debatter om brukergrensesnittelementer, for eksempel om noe skal være på siden eller i en pop-up. Det er veldig lett å komme inn i de detaljerte diskusjonene fordi slike problemer ofte er lettere (eller mer kjente) å løse enn de større problemene som scenarier er ment å løse. For å holde ting strømlinjeformet og bruke tid effektivt, be deltakerne om å lagre den typen diskusjoner til det punktet der du designer mot den prioriterte listen over krav. Og det tar oss til neste trinn i prosessen: den ofte livlige, noen ganger smertefulle prosessen med å prioritere de vakre kravene du har brukt så mye tid på å samle!

Legg til rette for prioriteringsprosessen Du har sett med forretningskrav som er utdypet med funksjoner basert på brukerkrav og idéarbeid. Nå kommer en av de vanskeligste delene: å redusere det hele til en prioritert liste med høyverdikrav. Når du går gjennom kravene som må prioriteres, ha prosjektmålene tilgjengelig, samt brukermodellen din, for å hjelpe deg med å fokusere diskusjonen på dine målgrupper. I tillegg til deg, i din rolle som brukeradvokat, bør prioriteringsprosessen også omfatte: Noen som representerer synspunktet til virksomheten (virksomheten

advokat). Noen som representerer synspunktet til utviklingsteamet (den

utviklingsforkjemper).

150

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

Noen som representerer prosjektets behov (for eksempel prosjektet

sjef). Denne personen trenger kanskje ikke å være i prioriteringsmøtene, men vil sette eventuelle begrensninger som påvirker prioritering (som tidsfrister eller budsjett) og sørge for at den endelige listen passer innenfor dem.

UX-designerens rolle i prioritering Det kan være fristende å vurdere prioritering som et delt ansvar mellom prosjektsponsoren, prosjektlederen og lederen av utviklingsteamet i stedet for et problem for en UX-designer. Det er ingenting lenger fra sannheten. Prioriteringsdiskusjoner er der vellykkede løsninger lages eller brytes. Designere av brukeropplevelse har et ansvar for å ta med sine ferdigheter til disse viktige samtalene. Hvis du allerede er en del av prioriteringsprosessen, vil denne delen gi deg tips om å delta. Hvis du ikke er det, gjør det du kan for å engasjere deg selv. Dette betyr at du må informere prosjektteamet om ferdighetene du bringer til bordet – for eksempel tilrettelegging – og det balanserte perspektivet du kan ta med. Det er viktig å demonstrere at du kan forstå ulike teammedlemmers perspektiver og arbeide sammen mot en enhetlig forståelse. Se avsnittet "Oppretthold en god spenning" for mer om hvordan du oppnår denne balansen.

Prioriteringsteamet går gjennom hvert av kravene for å svare på følgende spørsmål: Hva er nivået av betydning for virksomheten? Hvor viktig er

krav for å nå ett eller flere prosjektmål? Hvor stor er virkningen hvis dette kravet utelates? Hva er nivået av betydning for brukeren? Oppfyller kravet

et felles brukerbehov (eller store behov for prioriterte brukergrupper)? Hvordan påvirker det brukeropplevelsen hvis dette utelates? Er det andre krav som er veldig like og kan konkurrere? For dette siste spørsmålet, husk at flere løsninger på det samme problemet kan konkurrere med hverandre og forårsake brukerforvirring (samt kreve mer innsats for å støtte). For eksempel kan New York Times ha en stor nok utviklingsstab til å støtte alle delingsfunksjonene

TILLETT PRIORITERINGSPROSESSEN

151

på nytimes.com (kalt ut i blått i figur 9.2), men noen av brukerne kan være forvirret over om de skal klikke på Anbefal, E-post eller Del for å sende artikkelen til en venn. Hvis brukerne dine kanskje ikke er kjent med alle delingsalternativene som har eksplodert de siste årene, bør du sannsynligvis starte med et mindre sett med funksjoner. Hva er den tekniske muligheten for å utvikle kravet? Hva

er det nødvendig med tid for å utvikle det? Hvis du jobber med en relativt ny teknologi, vil tidsestimatet være høyere her. Hva er ressursgjennomførbarheten for å utvikle den? Gjør prosjektet

har teamet folkene, ferdighetene og pengene som kreves for å utvikle funksjonen? (Vurder kostnadene ved å kjøpe og lære nye teknologiske verktøy.)

Figur 9.2 Et bilde av www.nytimes.com, som fremhever de mange delingsfunksjonene nettavisen tilbyr

152

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

Lag et regneark som fanger opp beslutningene dine for hvert krav. Dette kan inkludere en lav, middels eller høy vurdering basert på spørsmålene ovenfor, eller du kan bruke en numerisk skala slik at du kan legge sammen tallene for sorteringsformål. Når du jobber nedover listen, vil du kanskje finne ut at du må konsolidere lignende krav eller dele opp et stort krav i en rekke mindre krav som representerer potensielt uavhengige arbeidsenheter. Husk at dette systemet rett og slett er ment å hjelpe til med sortering og prioritering; den er ikke basert på en vitenskapelig analyse av kravets gjennomførbarhet. Det er imidlertid veldig nyttig for å administrere en stor liste, inspirerende diskusjon og fange relativ betydning. Figur 9.3 viser et eksempel på et prioriteringsregneark som bruker høynivåkategorier av viktighet og gjennomførbarhet (lav, middels og høy) for å tilordne relative verdier til hvert krav. Arbeidsark for prioritering

Krav

Beskrivelse

Forretningsmessig betydning

Brukerviktighet

&%**%&

&($

)()$+)*'(&,! &%**!%&($*!&% &()!%#!)*& !)*(!+*&()

)()%#&!%*& )##')*&(() $!%* #)* /)

(( ("!%

(()% *("/%*(!% *("!%&!,% &%%&(( ) ) !''

("!%

)()%*("* !( '"/ #&-!%*(+")&( !('#%)

$!# &%2($*!&%

((!)*&(/

%$!#!))%**& &%2($%&(( ) %$

((

+#2##$%* ,!-)

)()%( &* (+)*&$()1 (,!-)&* &$'%/0)+#2##$%* '(&))

((

+#2##$%* *

)()% *-!* &* (+)()&+* * !(&((+#2##$%* .'(!%

Teknisk gjennomførbarhet

Ressursgjennomførbarhet

!+$

Figur 9.3 Et eksempel på et arbeidsark for kravprioritering

TILLETT PRIORITERINGSPROSESSEN

153

Å tildele verdier til hver av kategoriene vil inspirere til mange samtaler blant prioriteringsteamet. Hvordan kan du bidra til å lette diskusjon og beslutningstaking? To av de viktigste tingene du kan gjøre er å forstå (og noen ganger representere) de forskjellige synspunktene som er nøkkelen til å definere en balansert løsning, og å hjelpe til med å løse konfliktområder i prosjektgruppen. La oss først snakke om å representere det riktige settet med synspunkter under prioritering. Dette innebærer å skape og opprettholde spenningen mellom brukeradferd, virksomhetsadvokat og utviklingsadvokat – en god form for spenning, fordi den sikrer en balansert løsning som gir en god brukeropplevelse, møter prosjektbegrensninger og er i tråd med forretningsmål.

Oppretthold en god spenning Når du samler krav, og gjennom resten av prosjektet også, kan du legge merke til tre roller som trekker mot hverandre under teamdiskusjoner:

154

Forretningsadvokat: Teammedlemmet som representerer virksomhetens behov og krav og sikrer at de blir fanget opp og møtt så trofast som mulig. Primære bekymringer for forretningsadvokaten inkluderer å møte strategiske mål for selskapet og avdelingen, sikre at forretningsvisjonen ikke går tapt under prosjektet, og å sette og opprettholde fokus på prosjektmål. Brukeradvokat: Teammedlemmet som representerer behovene og perspektivene til de primære brukerne som vil oppleve nettstedet. Primære bekymringer for brukeradvokaten inkluderer å sikre at nettstedet oppfyller forventningene til brukervennlighet, gi en tilfredsstillende og engasjerende opplevelse og oppmuntre til atferd som støtter prosjektmålene. Utviklingsadvokat: Teammedlemmet som representerer behovene og begrensningene til teknologi- og kvalitetssikringsteam. Primære bekymringer inkluderer å sikre at utviklingsteamet fungerer effektivt og innenfor rekkevidde, og at det leverer et produkt som oppfyller kvalitetsstandardene som forventes av brukere og virksomhetens interessenter.

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

Se for deg dette som en treveis dragkamp blant talsmennene. Hvis spenningen er respektfullt godt vedlikeholdt blant de tre (som betyr at ingen talsmann dominerer), kan de tre sidene jobbe mot en velbalansert løsning som oppfyller prosjektmålene. Hvert teammedlem bør være klar over at de har en interesse i å opprettholde en balanse gjennom hele prosjektet. Hvis den ene siden dominerer, taper de andre rollene terreng og prosjektet risikerer å gå glipp av sine mål – eller oppnå dem til en mye høyere pris enn forventet. Se figur 9.4 for eksempler på hva som kan skje når spenningen ikke er balansert.

Figur 9.4 Konsekvenser når en god spenning ikke opprettholdes

HOLDE EN GOD SPENNING

155

Kan du spille mer enn én av disse rollene på et prosjekt? Absolutt! Ideelt sett har forskjellige teammedlemmer hovedansvaret for hver rolle, men det betyr ikke at du ikke kan bytte plass en gang i blant. Faktisk kan du bytte roller fra diskusjon til diskusjon – eller til og med fra emne til emne. Som UX-designer vil du oftest spille brukeradvokaten, men du må forstå synspunktene til alle tre rollene og sikre at de er konsekvent representert for å skape vellykkede design. Selv om det er sunt å bytte rolle fra tid til annen, vær forsiktig med å utpeke deg selv som hovedpersonen som er ansvarlig for mer enn én av disse rollene. Du kan begynne å inngå uimotsagte kompromisser etter hvert som prosjektet skrider frem fordi du ikke vil ha en konsekvent tilstedeværende "djevelens advokat" til å stille deg de ubehagelige, men viktige spørsmålene. Hvis du må ta på deg mer enn én rolle, prøv å finne en deltidsressurs som kan spille de andre rollene for deg av og til, for å sikre at god spenning opprettholdes. Fram til dette punktet har vi i stor grad fokusert på rollene som forretningsadvokat (spesielt i kapittel 4 og 5) og brukeradvokat (spesielt i kapittel 1 og 6). La oss ta et øyeblikk for å diskutere den tredje primære rollen i våre prioriteringsdiskusjoner: utviklingsforkjemperen.

Utviklingsadvokaten Hvis du er en UX-designer i hjertet, trives du når du setter deg selv i andres sko for å forstå deres behov og mål. Denne ferdigheten er uvurderlig både for å utføre rollen din som brukeradvokat og for å sikre effektiv kommunikasjon og samarbeid med de i organisasjonen din. La oss ta et øyeblikk til å bruke den ferdigheten til å skissere målene til utviklingsforkjemperen. En av de store designdebattene dreier seg om i hvilken grad utviklingsforkjemperen skal delta i, og påvirke, kravinnsamlingsprosessen – og hva hans eller hennes rolle er under den. Hvis utviklingsforkjemperen presenterer tekniske muligheter og begrensninger for tidlig, kan det begrense noe av idédugnaden som kan føre til noen svært innovative løsninger. Tross alt kan dagens blå himmel-ide være mulig med noen ekstra tekniske utforskninger. Selv om ideen ikke er gjennomførbar, kan det å diskutere den bringe frem et underliggende behov som du kan løse. (Kartlegging av funksjonsforespørsler til behov behandles senere i dette kapittelet.)

156

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

Dette er målene og relaterte ansvar for utviklingsadvokaten: Oppfylle kravene i tide og innenfor budsjett Sikre teameffektivitet (unngå overflødig arbeid, sikre god

kommunikasjon) Utnytt de tilgjengelige verktøyene og plattformene på best mulig måte Velg kostnadseffektive tilleggsverktøy Sørg for at fremtidige endringer ikke krever mye ekstra arbeid Gjør løsningen skalerbar, for å imøtekomme vekst Gjør løsningen modulær, slik at enkeltdeler enkelt kan modifiseres Gjør løsningen så standardisert som mulig: Jo færre modifikasjoner

gjort til et innkjøpt system, jo mindre ombyggingsarbeid vil være nødvendig nedover veien. Sørge for at utviklingsteamet fungerer godt Begrens omsetningen ved å yte relativt interessant og givende arbeid Begrens utbrenthet som kan skje med press i siste liten

Arbeide qmed arvede krav Trinn 4

Trinn 1

Gjennomgå krav og merk de med uklare behov eller tvilsom brukerverdi.

Arv bunke krav og foreta en første gjennomgang.

Trinn 2 Samle informasjon som gir kontekst om mulige brukere.

"Brukere er..."

Trinn 5 Gjennomgå markerte krav med teamet for å undersøke behov og konflikter. "Her er hvorfor."

B U

Trinn 3 Opprett en provisorisk brukermodell.

Trinn 6 Prioriter eventuelle endringer du mener må gjøres. Lag din sak for dem og presenter dem for prosjektteamet. Vær både grei og pragmatisk.

B C

"Godt poeng!"

"Hmm..."

HOLDE EN GOD SPENNING

157

Hvis utviklingsadvokaten ikke er involvert tidlig nok, kan teamet imidlertid gå langt nedover veien til et bestemt alternativ bare for å finne ut at det er for dyrt å inkludere - eller utviklingsadvokaten ender opp med å gå glipp av ett eller flere av sine egne mål. Og sist, men ikke minst, er utviklingsforkjemperen en god kilde for å få frem noen av egenskapene i teknologien som virkelig kan få løsningen din til å synge, for eksempel nye teknologier eller underutnyttet funksjonalitet. En effektiv tilnærming er å planlegge nøkkelgjennomganger med utviklingsadvokaten når idédugnaden er fullført, krav på høyt nivå er tatt opp, og prioriteringsprosessen er i ferd med å begynne. Dette gjør at utviklingsadvokaten kan bruke den første delen av prosessen til å utforske de valgte verktøyene for å få mer detaljer om hva som kan eller ikke er mulig, og deretter delta sterkere i selve kravprosessen når visse temaer og ideer har større vekt. Hvis du føler at noen kravsamlingsøkter er nøkkelen for utviklingsadvokaten å delta på, sørg for at dere begge er på samme side på forhånd angående hans eller hennes rolle i møtet og hvordan dere vil fange opp eventuelle bekymringer advokaten måtte ha. etter å ha lyttet. Du kan også ta opp denne typen økter for å gjennomgå med utviklingsadvokaten senere. Du kan trenge dem selv når du er i gang med å designe! Denne typen tydelig kommunikasjon og oppfølging under informasjonsinnhenting er avgjørende for å bygge sterke relasjoner mellom teammedlemmer, noe som kan utgjøre en stor forskjell i hvor smidig prioriteringstrinnet går senere i prosessen. Men noen ganger, til tross for din beste innsats, oppstår det konflikter når du prøver å prioritere krav. La oss snakke om hvordan du kan hjelpe prosjektteamet med å håndtere denne konflikten.

Håndtere konflikt under prioritering Hvis det er store områder med uenighet, kan prioritering være en lang prosess. Og hvis disse uenighetene ikke blir løst, vil de fortsette å dukke opp under design og utvikling. Disse konfliktene kan ha mange forskjellige grunnårsaker; her er noen av de vanligste:

158

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

Teamet er ikke på samme side om prosjektmålene eller under-

løgnaktige forretningsstrategier (enten å misforstå, glemme eller være uenige om dem). Motstående teammedlemmer er nært knyttet til et visst sett med funksjoner.

(Kanskje funksjonene begeistrer dem, eller de har lovet dem til et sett med innflytelsesrike kunder eller interessenter). Det er konflikter mellom forretningsbehov og brukerbehov som ikke er det

lett løses. Teknologiene som brukes er relativt nye for utviklingsteamet,

så de er ukomfortable med anslag. La oss ta et par av situasjonene ovenfor og diskutere hvordan du som brukeropplevelsesdesigner kan være med på å løse dem.

Velge dine kamper Under prioriteringsprosessen kan noen av favorittfunksjonene dine være på hugget. Det er lett å begynne å føle seg misfornøyd med dette, spesielt hvis det ser ut til at brukerkravene er de som oftest blir slettet fra listen. Hvis du lidenskapelig forsvarer alle krav likt, risikerer du å ha prioritert beslutninger tatt for deg. Her er noen spørsmål du kan stille deg selv når du bestemmer deg for når du skal presse på for et bestemt krav og når du skal gå på akkord: Hvordan støtter kravet prosjektmålene? Reduserer det en spesiell risiko betraktelig? Reduserer det for eksempel brukernes eksponering for spam, og reduserer negative meninger om nettstedet? Er andre foreslåtte nettstedskrav avhengige av at denne fungerer som den skal? Hva er virkningen hvis funksjonen ikke er inkludert? Er verdien av funksjonen verdt innsatsen som trengs for å utvikle den (selv på bekostning av andre funksjoner du setter pris på)? Hvis du har et sterkt svar på alle disse, ta dem med til prioriteringsbordet for å gjøre din sak. Hvis ikke, vurder å la det gå, men sørg for å dele grunnene dine slik at andre ser at du går på akkord for prosjektets generelle beste. Det vil demonstrere din evne til å vurdere den større forretningskonteksten og styrke ditt engasjement i fremtidige prioriteringsdiskusjoner og endringsforespørsler.

HOLDE EN GOD SPENNING

159

Mangel på justering på prosjektretning Teamet er ikke på samme side om prosjektmålene eller underliggende forretningsstrategier. La oss dele denne kilden til konflikt i to områder: kommunikasjon og konsensus. Hvis kommunikasjon av prosjektmål eller forretningsstrategier er problemet, spør deg selv hvordan du personlig kan bidra til å forbedre kommunikasjonen. Er det et spørsmål om å legge ut målene eller strategiene der alle teammedlemmer vil se dem (for eksempel i et krigsrom eller online samarbeidsområde, eller øverst på agendaen for hvert møte)? Eller kanskje det som trengs er en visuell representasjon av målene eller strategiene som vil bidra til å bringe dem i fokus for teamet og få teammedlemmene begeistret over visjonen de jobber mot. Husker du visualiseringsferdighetene som ble diskutert i begynnelsen av dette kapittelet? Bruk dem til å lage et bilde som enkelt kan skrives ut og legges ut eller raskt skisseres på en tavle for å fokusere samtaler. Hvis konsensus er problemet, spør deg selv hvordan du kan bidra til å bringe alle sammen. Er konflikten forårsaket av angst for risikoen som er forbundet med å gi brukerne et helt annet funksjonssett? Kanskje det er forskning du kan utføre for å hjelpe til med å løse noen av uenighetene, for eksempel undersøkelser, intervjuer eller kontekstuelle henvendelser (se kapittel 6). Eller kanskje du kan bruke tilretteleggingsferdighetene dine ved å holde en strukturert diskusjon om uenigheter, jobbe gjennom problemer punkt for punkt til de er løst. Konﬂikt over favorittfunksjoner Motstående lagmedlemmer er knyttet til sine egne sett med funksjoner. Anta at direktøren for opplæringsavdelingen ønsker integrerte, temabaserte veiledninger og salgssjefen ønsker en spennende demo å sende ut for å skape interesse. I mellomtiden har du ti andre forretningsinteressenter i forskjellige roller – og de har alle presserende behov. Hvordan bidrar du til å bygge konsensus? En metode er å bruke en variant av en metode du leste om i kapittel 6: affinitetsdiagrammer. Med denne metoden kan du jobbe ut fra et eksisterende sett med krav eller få interessentene til å brainstorme sine egne krav (spesielt nyttig hvis det fortsatt er tidlig i kravinnsamlingsprosessen). Hvis du jobber ut fra eksisterende krav, kan du skrive dem ut på

160

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

individuelle sider og tape dem alle til veggen. Ellers, be interessenter om å skrive sine top-of-mind-krav på et sett med Post-it-lapper. Hva du trenger: Et rom som er stort nok til at interessentgruppen din kan bevege seg rundt i og

som har en eller flere store tomme vegger kan du bruke Post-it-lapper på En blokk med store Post-it-lapper, minst én for hver interessent Klistremerkeprikker (du kan finne disse i kontorrekvisitabutikker; de kommer i forskjellige

ous colors), ett sett med ti prikker per interessent Samle de primære interessentene dine sammen i et rom og be hver enkelt om å bruke litt tid på å skrive ned nøkkelkravene, en til et notat. Gi dem 15 til 20 minutter til å gjøre dette. (Ingen titting!) Be alle om å sette sine krav opp på veggen. Be så hver person gå opp og beskrive hva de har lagt ut. Når du går rundt i rommet, begynn å gruppere lignende krav sammen (hvis interessentene er enige om at de er like). Når kravene er forklart og gruppert, deler du ut klistremerkeprikkene. Fortell interessentene at de kan indikere hvilke krav som har høyest prioritet for dem ved å fordele prikkene deres blant Post-it-lappene. De kan velge å plassere alle ti prikkene sine på ett krav, for eksempel hvis de føler det er så viktig, eller de kan velge å sette en prikk på ti forskjellige krav. Du vil begynne å se noen klare favoritter når folk plasserer prikkene sine. Når de er ferdige med å plassere prikkene, gå gjennom resultatene sammen. Når de blir tvunget til å velge denne måten, vil interessentene bringe frem sine egne interne prioriteringer, og samtalen vil trolig bli mye lettere.

Surfing For mer om en variant av denne teknikken som skal brukes i prioritering, se denne artikkelen "The KJ-Technique: A Group Process for Establishing Priorities," av Jared M. Spool: www.uie.com/articles/kj_technique.

HOLDE EN GOD SPENNING

161

Denne typen teknikk kan hjelpe deg med å sette i gang prioriteringsprosessen eller tilbakestille en prosess som har stoppet opp på grunn av uenighet. Når du har oppnådd fart og en felles forståelse, vil det bli mye enklere å fullføre prioriteringsdokumentet (som det vi så i figur 9.3). Parallelt med prioriteringsaktivitetene dine bør du forberede deg på hele designarbeidet som snart vil følge. Å ha en plan for arbeidet ditt vil hjelpe deg med å beregne innsatsen som vil være involvert i å lage detaljerte design, integrere arbeidet med andre i prosjektteamet ditt og koordinere innsatsen for å tilpasse seg prosjektmilepæler. Den neste delen dekker noen av hensynene som vil hjelpe deg å planlegge.

Planlegg aktivitetene og dokumentasjonen Når du har en prioritert liste over krav og, ideelt sett, noe tidlig konseptarbeid fullført (som storyboardene illustrert tidligere i kapittelet), vil prosjektlederen sannsynligvis begynne å spørre deg om detaljer om hva du skal å gjøre som du designer. Det finnes flere typer designaktiviteter, og hver av dem vil ha en annen innvirkning på hvordan du designer, hvor lang tid det vil ta og hvilken type dokument du ender opp med. Dette er et "dokument" i generell forstand; det kan variere fra en tavleskisse, til en wireframe, til en prototype. Vi skal dekke noen interaksjonsdesignaktiviteter i de neste tre kapitlene. Når du planlegger aktivitetene som skal brukes, husk disse spørsmålene: Hvor iterativ vil den generelle prosessen være? Ideelt sett kan du begynne med

utforske flere forskjellige konsepter raskt (for eksempel gjennom skisser), for så å bli enige om et som skal utvikles mer detaljert. Denne tilnærmingen kan også innebære å ta ett eller flere designkonsepter til brukere (se kapittel 13 for mer om designtesting). Hvordan vil samarbeid skje under design? Hvis du jobber tett

med et team på samme sted, kan du inkludere flere samarbeidende tavleøkter. Hvis teamet er spredt, bør du vurdere nettkonferanseøkter med verktøy som tillater en høy grad av samarbeid til tross for avstanden.

162

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

Hvordan vil designdokumentene dine bli delt med det større teamet? Are

sender du dem på e-post til et lite team eller legger dem ut på et nettbasert samarbeidssted? Hva betyr det når det gjelder størrelsesbegrensninger og prosessen med å spore versjoner? Hvor mye detaljer trenger designene dine å bære, senere i utviklingen

prosess? Hvis dokumentene dine er en del av en formell kvalitetssikringsprosess (QA), bør du sørge for at du involverer noen fra QA-teamet tidlig slik at de forstår hva slags detaljer de vil motta fra deg. Hvor lenge trenger dokumentene dine for å "leve"? Med komplekse prosjekter,

i det øyeblikket du slutter å oppdatere et dokument, for eksempel et sett med wireframes, begynner det å "dø" – detaljene blir mer unøyaktige ettersom tiden går. (Dette er ikke alltid en dårlig ting, så lenge du er involvert i diskusjonen om disse endringene.) Dokumenter som er fokusert på å gi generelle retningslinjer, for eksempel et merkevaredokument eller et bibliotek med interaksjonsdesignmønstre, har en tendens til å lev lenger. Hvem er hovedbrukerne av hver type dokumentasjon? Dette svaret

kan være forskjellig på ulike punkter i prosjektet. De primære brukerne av dine konseptuelle designdokumenter er vanligvis forretningsinteressenter og designteamet, som bruker dem til å kommunisere og sosialisere ideer. Detaljerte designdokumenter er først og fremst for utviklerne som skal implementere designene; disse dokumentene gir spesifikk retning. Hvilke andre typer dokumentasjon må din samsvare med? Du vil

må gi en slags sammenheng mellom den prioriterte listen over funksjoner du opprettet ovenfor og designene du lager. Du må kanskje holde et øye med flere andre typer dokumenter også for å sikre at alle er på samme side. Disse dokumentene kan inkludere merkevareretningslinjer, innholdsutviklingsplaner, funksjonelle spesifikasjoner eller brukstilfeller (se kapittel 2 for en oversikt over ulike roller og typen dokumentasjon de kan produsere). Hvordan kan du anslå innsatsen som trengs for hver type dokument? Dette

en er vanskelig siden det er mange variabler på et prosjekt som kan påvirke tiden. Men ved å sette en grunnlinje for et grovt estimat, har du et sted å starte, og du kan validere tallene etter hvert som du får mer informasjon. Du kan for eksempel angi et basisestimat som hver detaljert wireframe vil ta deg omtrent 6 timer å lage. Hvis du anslår en bestemt funksjon

PLANLEGG DINE AKTIVITETER OG DOKUMENTASJON

163

vil kreve omtrent fem sider (for eksempel basert på resultatene av storyboarding-øktene beskrevet tidligere i dette kapittelet), vil du ha et innledende estimat på 30 timer for den funksjonen. Hvis det ender opp med å ta deg åtte sider per wireframe, prøv å finne ut hvorfor. Hvis det er noe du tror vil fortsette, må du revidere anslaget ditt og eventuelt omprioritere. Hvilke tilleggsfaktorer vil påvirke tidspunktet for dokumentet? Total

tiden inkluderer gjennomgangstid med teamet og med interessenter, samt tiden for antall revisjoner du tror du må gjøre. For detaljerte nettsteder kan det også inkludere tid som trengs for å forene designdokumentene dine med andre dokumenter, for eksempel detaljerte funksjonelle krav (som brukstilfeller). Skriv ned disse forutsetningene for deg selv, slik at du kan sjekke mot dem senere. Vil du jobbe med flere designere, og i så fall hvordan har du det?

skal du dele opp arbeidet? Hvis du jobber med parallelle, men distinkte områder på nettstedet, kan du jobbe ganske uavhengig med dokumentene du lager. Hvis du deler opp arbeidet på en måte som er veldig avhengig av hverandre, må du planlegge for tid for å avstemme designene dine, og du kan også trenge en måte å spore og slå sammen ulike versjoner på dokumenter. Spar deg selv en stor hodepine senere ved å utarbeide en prosess i begynnelsen, og angi noen designretningslinjer tidlig slik at du er på samme side om slike nøkkelelementer som navigasjon. Nå som vi har snakket om noen av tingene du bør vurdere når du velger designaktiviteter, la oss utforske disse aktivitetene. I de neste tre kapitlene vil vi diskutere en rekke dokumenter, inkludert nettstedskart, oppgaveflyt, skisser, wireframes og prototyper.

164

KAPITTEL 9: OVERGANG: FRA DEFINERING TIL DESIGNING

Nettstedskart og oppgaveflyt Strukturering av prosjektet ditt fra her til dit og tilbake igjen Nettstedskart hjelper deg med å identifisere strukturen til nettsteder og applikasjoner. De kan vise hierarkier og forbindelser som lar publikum få en forståelse av hvor brukere kan finne innhold. Oppgaveflyter tar nettstedskart et skritt videre ved å identifisere de ulike handlingsforløpene en bruker kan gå gjennom innenfor en del av nettstedet. Oppgaveflyter trekker også forbindelsene til feiltilstander, innhold eller sidevisninger basert på beslutningspunkter gjennom hele prosessen. Når de brukes sammen, kan nettstedskart og oppgaveflyter gi publikum et klart bilde av innholdsstrukturer og hvordan brukere kan navigere gjennom dem. Russ Unger

165

Hva er et nettstedskart? 1.0

1.0.1 Vilkår og betingelser

Hjemmeside

2,0 – 2,x

3.0

Blogg

4.0

5.0

Arbeid

Kontakt

Figur 10.1 Et nettstedskart for et grunnleggende nettsted med bloggfunksjonalitet

Fra og med de mest grunnleggende definisjonene, er et nettstedskart ganske enkelt en visuell måte å vise representative sider på et nettsted (Figur 10.1). Et enkelt nettstedskart passer vanligvis på ett enkelt ark og ligner en arbeidsgivers organisasjonskart. Områdekart er imidlertid ikke bare for nettsteder; du kan bruke dem for alle typer applikasjoner som vil ha nytte av å identifisere sider, visninger, tilstander og forekomster av det som vises. I de fleste tilfeller vil du bruke et nettstedskart for å vise lagkamerater og klienter hvordan innholdet vil bli organisert for et nettsted. Den vil gi en oversikt over navigasjonen på nettstedet, og i noen tilfeller vil den vise alle forbindelsene hver side kan ha.

Hva er en oppgaveflyt? Figur 10.2 En grunnleggende oppgaveflyt som viser banen for en bruker avhengig av påloggingsstatus

Hjemmeside

Er brukeren pålogget? Ikke pålogget side

Nei

Pålogget side

Oppgaveflyter identifiserer stier eller prosesser som brukere (og noen ganger et system) vil ta når de går gjennom nettstedet eller applikasjonen din (figur 10.2). Selv om nettstedskart og oppgaveflyt kan se like ut til å begynne med, tjener de to typene diagrammer forskjellige formål: Et nettstedskart forteller deg det visuelle hierarkiet til et nettsteds eller applikasjons layout, mens en oppgaveflyt gir deg detaljer om brukernes alternativer og stier de vil kunne ta. 166

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

Bransjeverktøy Hvis du akkurat har begynt på designfeltet for brukeropplevelse og trenger et verktøy for å begynne å lage arbeidsprodukt, har du mange alternativer: Microsoft Visio (http://office.microsoft.com/visio) Axure RP Pro (www.axure.com) OmniGraffle (www.omnigroup.com/applications/OmniGraffle) Adobe InDesign (www.adobe.com/products/indesign) Adobe Illustrator (www.adobe.com/products/illustrator) Microsoft PowerPoint (http: //office.microsoft.com/powerpoint) OpenOffice Draw (www.openoffice.org) HTML Blueprint CSS (www.blueprintcss.org)

Så hvordan velger du? Du kan spørre andre designere; alle har en favoritt, og de er vanligvis glade for å nevne den. Bare ikke bli overrasket om de, i likhet med forfatterne dine, svarer «bra gammel blyant og papir». Du kan også teste ut gratis prøveversjoner online eller velge en gratis løsning, for eksempel OpenOffice Draw, som er en del av OpenOffice.org-pakken med verktøy og gir ut de samme formatene som populære kontorpakker. Hva bruker vi utover blyant og papir? Mange av eksemplene i denne boken ble generert med Microsoft Visio 2003, ved bruk av sjablonger laget av Nick Finck, direktør for brukeropplevelse hos Blue Flavor (www.blueflavor.com) og utgiver av Digital Web Magazine (www.digital-web.com) . Du kan laste ned Nicks enestående sjablonger fra www.nicknck.com/stencils.html. Slike ferdiglagde sjablonger, former og prøver er uvurderlige for både nye og erfarne utøvere. I tillegg til Nicks, sjekk ut tilbudene til Information Architecture Institute, som inneholder mange av disse verktøyene på sin Learning IA-side: http://iainstitute.org/en/learn/tools.php. Merk Microsoft tilbyr for øyeblikket en 2007-versjon av Visio; Imidlertid har mange selskaper fortsatt ikke oppgradert til produktet, og for å ikke håndtere versjonsforskjeller anbefaler vi for øyeblikket Microsoft Visio 2003.

HANDELENS VERKTØY

167

Uansett hvilke verktøy du velger å bruke, finnes det utallige eksempler på nettet fra andre fagfolk som gjerne deler dem og hjelper deg videre i karrieren. Disse er stort sett gratis og kan gi deg rammeverket du trenger for å lage – i det minste – dokumentasjon som ser veldig profesjonelt ut. Dessverre er det mange som ikke utnytter disse ressursene. Ikke vær som de menneskene!

Grunnleggende elementer i områdekart og oppgaveflyt De mest grunnleggende elementene i tegneprogrammet ditt vil være mer enn nok til å komme i gang med å lage områdekart og oppgaveflyter. For å sikre at kreasjonene dine enkelt kan tolkes av et bredt publikum, er det imidlertid best å bruke et standard sett med former. Visual Vocabulary for Information Architecture er en slik standard, og den som brukes i denne boken. Laget av Jesse James Garrett, en av grunnleggerne av Adaptive Path (www.adaptivepath.com), er den tilgjengelig online på www.jjg.net/ia/visvocab. Nettstedet inneholder mange elementer for å hjelpe deg med å artikulere nettstedskart og oppgaveflyt, som alle er tilgjengelige med detaljerte beskrivelser og som nedlastbare sjablonger for mange av de populære tegne- og skisseprogrammene (mer om disse om litt). For å hjelpe deg med å komme i gang og bli kjent med det grunnleggende, tar de neste avsnittene en titt på Visual Vocabularys kjernesett med elementer og hva de representerer. Figur 10.3 Sideelement fra Jesse James Garretts Visual Vocabulary

Figur 10.4 Pagestack-element fra Jesse James Garretts Visual Vocabulary

Side I følge Jesse James Garrett er en side "den grunnleggende enheten for brukeropplevelse på nettet." «Forekomster» eller «visninger» av innhold kan være mer realistiske i dag, men en side er fortsatt veldig meningsfull. Det finnes en rekke måter å tegne disse sidene på, men det enkleste, mest brukte formatet er et vanlig format

168

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

rektangel (Figur 10.3). Etter hvert som du går videre med å lage nettstedskart og oppgaveflyter, vil du finne stilen som passer best for deg for merking og nummerering av sidene dine.

Pagestack En sidestack representerer flere sider med lignende innhold (Figur 10.4). En enkel måte å forstå pagestacks på er å tenke på dynamisk innhold, for eksempel en vanlig bloggside opprettet ved hjelp av et publiseringssystem. Disse sidene er utformet én gang og er i en designmal, men du har muligheten til å klikke deg gjennom mange forskjellige sider med innhold – uten å forlate det originale maldesignet.

Decision Point Figur 10.5 Decision Point-element fra Jesse James Garretts Visual Vocabulary

Logg Inn

(10a)

feil

medlem hjem

Et beslutningspunkt brukes for å vise veien en bruker kan ta avhengig av svaret på et spørsmål (Figur 10.5). Avgjørelsespunkt 10a kan være "Er brukerens påloggingsinformasjon riktig?" Svaret på det spørsmålet vil avgjøre hvilken side (eller innholdsvisning) som skal vises. En mislykket pålogging resulterer i en feilmelding, mens en vellykket pålogging tar brukeren til nettstedets medlemmers hjemmeside. Ta deg tid til å merke beslutningspunkter på riktig måte; du vil være glad du gjorde det, spesielt når du deler arbeidsproduktet ditt med lagkamerater eller kunder.

GRUNNLEGGENDE ELEMENTER I NETTEKART OG OPPGAVEFLØTER

169

Koblinger og piler Figur 10.6 Koblings- og pilelementer fra Jesse James Garretts visuelle ordforråd

Koblinger og piler brukes til å vise bevegelse eller fremgang mellom sider, sidestabler, beslutningspunkter og så videre. Koblinger vises vanligvis der det er et oppfordring til handling fra en side til en annen. For eksempel kan en kobling til Om oss-siden fra hjemmesiden være koblingen mellom de to sidene. Piler (øverst i figur 10.6) indikerer "nedstrøms" bevegelse mot fullføring av oppgaven. Koblinger med tverrstangen (nederst i figur 10.6) kan brukes til å identifisere når bevegelse tilbake til siden du kom fra («oppstrøms»-bevegelse) ikke lenger er tilgjengelig. For eksempel, når en bruker er logget inn på et nettsted, kan det som var innholdet på hjemmesiden nå tilpasses brukeren, og den generelle siden, eller påloggingssiden, vil ikke lenger være tilgjengelig for brukeren fra banen de nettopp fulgte.

Betingelser A

Figur 10.7 Tilstandselement fra Jesse James Garretts Visual Vocabulary

En stiplet linje er en ganske vanlig måte å vise en tilstand på. Det kan vises i nettstedskart, oppgaveflyter og andre arbeidsprodukter du kan lage eller finne på. Du kan bruke en stiplet linje som en kobling (som i figur 10.7) eller som en boks rundt et område for å markere at en kobling til en side – eller en hel del av sider – er betinget basert på en annen handling eller hendelse.

170

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

Vanlige feil Du vil ikke gå inn i en presentasjon med en klump peanøttsmør på haken eller en kaffefarget skjorte. Ikke bare ville en slik tabbe undergrave alt det harde arbeidet ditt, det kan også hindre deg i å lande et godt prosjekt. Et slurvete nettstedskart eller en oppgaveflyt som ser uprofesjonell ut kan gjøre like mye skade. For å hjelpe deg å gjenkjenne de små forfallene med store konsekvenser, tar de neste avsnittene en nærmere titt på noen dårlige design. Lær å oppdage disse vanlige feilene – og unngå dem.

Slurvete tilkoblinger Figur 10.8 En tapt forbindelse mellom to sider

Slurvete forbindelser er nettopp det: Slurvete. De er dårlig tegnet. De ser veldig amatøraktige ut, og de gir deg – forfatteren – inntrykk av å ikke ha mye oppmerksomhet på detaljer i arbeidet ditt, for å si det mildt. De fleste verktøyene har en metode for å hjelpe deg med å koble linjene til boksene dine. Vennligst dra nytte av det. Ikke bli lat, uavhengig av tidsbegrensninger og presset du kan være under. I de fleste applikasjoner lar bruk av en kombinasjon av Shift og andre taster deg dra elementer fra et startpunkt i trinn på 45 grader. Dra nytte av denne innebygde funksjonaliteten og sørg for at tilkoblingene dine er tilkoblet. Hvis du viser blyantskisser, bør du ha et viskelær for hånden i tilfelle. Gjør det til en regel: Sørg alltid for at alle linjer som berører et annet objekt er koblet med nøyaktighet.

VANLIGE FEIL

171

Feiljusterte og ujevnt fordelte objekter

Figur 10.9 Sider som ikke er justert og er ujevnt fordelt

Avhengig av verktøyet du bruker, kan det være vanskelig å sikre at objektene dine er nøyaktig justert eller jevnt plassert fra hverandre på områdekartet eller oppgaveflyten. Det er noen ganske enkle måter å sikre at du får ned denne grunnleggende regelen. For det første, slå på rutenettet i det programmet du bruker. På den måten, uavhengig av om verktøyet tilbyr alternativer som sikrer jevnt fordelte, passende justerte objekter, kan du alltid telle antall rutenett mellom objektene dine. Heldigvis, når du bruker blyant og papir, kan du bruke millimeterpapir og bruke det samme grunnleggende prinsippet. Det er så enkelt å få dokumentene dine til å se profesjonelle ut. Dessverre er det også så enkelt å få dokumentene dine til å se ut som om du egentlig ikke bryr deg om kvaliteten på arbeidet ditt.

Dårlig plassert tekst Figur 10.10 Inkonsekvent plassert tekst

Trinn 1 Trinn 2

Uforsiktig tekstplassering (som i figur 10.10) virker enkelt å unngå, men det er en annen vanlig feil. Finn en måte å få teksten til å passe godt inn i formen du har laget, og sørg for at alle etiketter som er plassert utenfor elementene har passende koblinger (Figur 10.11). 1.0 Hjemmeside

172

1.0.1 Vilkår og betingelser

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

Figur 10.11 Velplassert tekst

Det kan virke grunnleggende, men riktig plassering av teksten – sammen med passende skriftstørrelse og bruk – vil gjøre dokumentene lettere å lese og bruke.

Mangel på sidenummerering Det er på tide å etablere en annen regel: Nummerer hver side på hvert nettstedskart du lager. Ikke lag et vagt, tallløst kart som figur 10.12. Vilkår &

Hjemmeside

Blogg

Forhold

Arbeid

Kontakt

Figur 10.12 Områdekart uten nummereringsstruktur

Enhver side du identifiserer på nettstedskartet ditt må gis et nummer, og nummereringssystemet ditt må tillate nedstrømsendringer når nye iterasjoner og versjoner av prosjektet ditt opprettes. Du kan bruke en rekke tilnærminger for å nummerere sider; det vanligste er å identifisere hjemmesiden din som enten 1.0 eller 0.0.0.0 (Figur 10.13). Over tid vil du kunne finne ut hvilken av disse som fungerer best for deg, men inntil du blir komfortabel og forstår fordelene og ulempene ved begge tilnærmingene, start med å identifisere hjemmesiden din som 1.0. Denne metoden lar deg gjøre rede for eventuelle avgjørelser og sider som kan skje før startsiden din – for eksempel en Flash-forhåndslaster, en påloggings- eller registreringsskjerm, eller en rekke andre sidetyper – som 0.X. Et nummereringssystem på nettstedskartene gjør at annen dokumentasjon kan synkroniseres med den. Nummereringssystemet kan spre seg til andre dokumenter, for eksempel innholdsmatrise. Innholdsskapere kan kartlegge sin kopi og annet innhold til

spesifikke sider (og til et spesifikt element i en wireframe; mer om det senere). Oppgaveflyter. Oppgaveflyter kan bruke samme nummereringssystem for å vise hvordan

en bruker vil fortsette gjennom sidene til en spesifikk oppgave. Wireframes (se kapittel 11). Sidene til wireframes skal dele

samme nummereringssystem som sidene på nettstedskartet for å gi en klar sammenheng mellom de to dokumentene.

VANLIGE FEIL

173

Visuell design. Visuelle designere kan synkronisere designsider og -elementer til

spesifikke sider på nettstedskartet. Dette lar dem segmentere beholdningen sin når det er på tide å levere designene sine til utviklere. Kvalitetssikringsdokumenter. Kvalitetssikringsteam kan forfattertest-

skript som er dedikert til en eller flere spesifikke sider på nettstedskartet. Din oppmerksomhet på detaljer og struktur på dette tidspunktet hjelper til med å holde alle andre som berører prosjektet på sporet og gir dem struktur for oppgavene sine. 1.0

1.0.1 Vilkår og betingelser

Hjemmeside

2.0 – 2.x Blogg

3.0 Om

4.0 Arbeid

5.0 Kontakt

Figur 10.13 Områdekart som kobler sider på riktig måte, med elementer som er justert, jevnt fordelt og riktig nummerert

Kort sagt, nummerering av sidene på nettstedskartet ditt vil gjøre alle andres liv enklere – og det betyr at livet ditt også blir enklere.

Det enkle nettstedskartet I tillegg til å inneholde sidetall, er figur 10.13 en god modell for å lage kartet over et grunnleggende nettsted som har begrenset dynamisk funksjonalitet og for det meste statisk. Sidene som ble identifisert for dette nettstedet var Hjem Blogg Om Eksempler på arbeid Kontakt

Som du kan se, inneholder dette enkle nettstedskartet kjerneelementene fra det visuelle vokabularet og opprettholder en profesjonell stil og utseende. Det viktigste er at det gir et veldig klart bilde av navigasjonen, sidene og forholdene som er tilgjengelige for brukere av nettstedet.

174

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

Avanserte nettstedskart Et enkelt nettstedskart kan vanligvis passe på ett enkelt ark, og mest sannsynlig ser det ut som en arbeidsgivers organisasjonskart. Mer avanserte nettstedskart kan imidlertid utvides til flere sider. 1.0 Lorem Ipsum Dolor-hjemmeside

La smerten være veldig god

9. februar 2008

s. 3/9

Figur 10.14 Avansert sidevisning av nettstedskart

Når du lager nettstedskart som er mer avanserte eller for webområder og applikasjoner i større skala, er en tilnærming å bruke den første siden din til å identifisere trinnene som kreves for å nå nettstedets hjemmeside. (Det er riktig, vi foreslår at du bruker en oppgaveflyt som en del av det avanserte nettstedskartet ditt.) I tillegg bør du identifisere alle toppnivåsidene dine, globale navigasjonselementer og bunntekstelementer. Dette lar deg vise en oversikt over nettstedet på et veldig høyt nivå på forhånd og gir teamet ditt og kundene et klart bilde av prosjektet. Den første siden er også et passende sted å inkludere en forklaring eller nøkkel for å hjelpe deg med å lese nettstedskartet (se figur 10.14). Teamet ditt og kundene dine trenger en. Ikke hopp over dette trinnet!

AVANSERTE SITEKART

175

La smerten være veldig god

19. februar 2008

s. 4/9

Figur 10.15 Avansert områdekartsnittvisning

Sider du oppretter etter den første siden din, bør i hovedsak kartlegges tilbake til den. For hver side på toppnivå bør du ha minst én side etter som identifiserer alle sidene, sidestablene og eksternt innhold som kreves for nettstedet eller applikasjonen (Figur 10.15). Om nødvendig, ikke vær redd for å koble undersider sammen. Områdekart kan vokse til å bli mer ekspansive enn et enkelt ark med standardstørrelse tillater. Dette er ingenting å bekymre seg for, så lenge nettstedskartet ditt er godt organisert og forbindelsene er tydelig dokumentert for publikum. Disse eksemplene er mer enn nok til å komme i gang med å lage nettstedskart. Når du begynner å komme deg gjennom en rekke prosjekter og du oppdager at ferdighetene dine – og ofte team- eller klientbehovene dine – vokser, vil du oppdage at det er vidt forskjellige tilnærminger og metoder du kan bruke for å levere nettstedskart.

176

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

Å bryte mønsteret for nettstedskart Du har nå sett solide eksempler på nettstedskart som burde passe de fleste behovene dine for å få utført hovedoppgavene dine. Ikke la disse modellene hindre deg i å utforske måter som fungerer bedre for deg – og del dem gjerne med oss! Ulike tilnærminger kan fremheve informasjon utover grunnleggende nettstedsarkitektur. Vurder for eksempel områdekartet i figur 10.16, som ble levert av Andrew Hinton, senior informasjonsarkitekt hos Vanguard. Overvåk ny forskning

Abonnere

Støtt bc.org

Logg Inn

Oppdater profil

Finn lignende personer

"Akademisk" interesse (medisinsk, student, generelt)

Bidra

Samtale Få trykte Mtrls

Lær om bc.org

Ny bekymring

Administrer risiko

Bekymret kjære

Sosialisere

Ekspertkonf. Delta Lær

Ny Diag Ny Stage / Sit.

Figur 10.16 Avansert områdekart. Med tillatelse av Andrew Hinton.

Dette nettstedskartet viser ikke bare de forskjellige sidene på nettstedet, det tjener også til å gi innsikt i brukerstier og prioriteringer. Andrew (www.inkblurt.com) sier at han laget nettstedskartet etter å ha sett et eksempel fra Wolf Noeding som utløste hans kreative flamme. Andrew bruker dette nettstedskartet til å vise ulike brukerscenarier og mentale modeller relatert til nettstedet. De større sirklene på kartet har en tilleggsfunksjon: De fremhever toppnivåområder på nettstedet som mottar mest trafikk. Som alle utøvere av god brukeropplevelse, lånte Andrew – men ga også kreditt. Det er ubegrensede måter du kan utvide nettstedskartene dine på etter hvert som du begynner å bli mer komfortabel med å bruke verktøyene og identifisere arbeidsprodukt- og klientbehovene dine. La inspirasjonen slå deg der du finner den! Ikke vær redd for å prøve noe nytt, men ta deg tid til å sørge for at tiden du bruker er nyttig og verdifull.

BRUKE SITEKARTSFORMEN

177

Oppgaveflyter Ved å bruke mange av de samme grunnleggende elementene som nettstedskart, er oppgaveflyter diagrammer som identifiserer en bane eller en prosess som brukere (og noen ganger et system) vil ta etter hvert som de går gjennom nettstedet eller applikasjonen. Du kan bruke oppgaveflyt på en rekke forskjellige måter. Når de brukes sammen med et nettstedskart, kan de vise hvordan en bruker kommer til en side med et spesifikt sett med informasjon vist. Noen ganger brukes de til å vise hvordan en spesifikk brukertype (en persona) ville forvente å krysse et nettsted og hva den persona ville forvente å se basert på deres personlige mentale modell. Du kan også bruke oppgaveflyt til å identifisere komplekse prosesser som må forstås tydelig før prosjektet sendes til utviklingsteamet. Du bruker kanskje ikke oppgaveflyt på hvert prosjekt du jobber med, og de ender kanskje ikke alltid opp som et arbeidsprodukt du presenterer for kundene dine, men det er alltid en god idé å bruke dem – selv om det bare er i en blyant- og -papirformat til din egen fordel. Litt klarhet kan gå langt. For å lage en oppgaveflyt må du ha en forståelse av brukerens mål. I noen tilfeller vil du motta et kravdokument, og i andre tilfeller kan du motta (eller forfatter) en use case. Selv om en brukstilfelle bare består av noen få setninger som oppsummerer oppgaver og mål, vil den tillate deg å syntetisere brukerens syn på opplevelsen. Brukstilfellet for scenariet i figur 10.17 kan se slik ut: Systemet viser prosjektliste. Brukeren velger et prosjekt. Systemet viser grunnleggende prosjektinformasjon i skrivemodus. Bruker endrer status for prosjektet til Stengt. System sjekker for ventende oppgaver. Hvis det er ventende oppgaver, viser systemet feilmelding. Hvis det ikke er noen ventende oppgaver...

178

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

System sjekker for ventende betalinger. Hvis det er ventende betalinger, viser systemet feilmelding. Hvis det ikke er noen ventende betalinger... Systemet viser sammendragssiden.

Hjem [Min kravliste] Velg Krav

Informasjon [Skrivemodus]

Kravstatus endret: Stengt

Ventende oppgaver?

Feilmelding

Nei

[Vis ventende oppgaver og forespørsler] Ja

Venter på betalingsforespørsel?

Nei

Informasjon [Skrivebeskyttet modus]

Figur 10.17 Denne oppgaveflyten identifiserer hvordan et system viser informasjon til en bruker basert på svar på flere forhold.

Oppgaveflyten i figuren viser sekvensen av informasjon som vises til en bruker basert på om en rekke betingelser fra brukssaken er oppfylt. Hvis et av spørsmålene i senteret ("Ventende oppgaver?" eller "Venter på betalingsforespørsel?") blir besvart med et ja, viser systemet en feilmelding, som potensielt kan levere tilleggsinformasjon for å hjelpe brukeren med å fullføre de nødvendige oppgavene før det går videre . Hvis begge forholdene besvares nei, gir systemet brukeren et display som identifiserer suksess. Oppgaveflyten i figur 10.18 viser banene som en bruker kan ta fra en kalenderapplikasjon gjennom en reiseshoppingside. Oppgaveflyten er svært høy ved at den identifiserer tre svært forskjellige baner som krever testing av brukere for å sikre at den detaljerte flyten for hver sti oppfyller brukerbehovene.

OPPGAVEFLØTER

179

Kalender S100 Kalender Shopping Fare Finder

S10 Detaljert prissøker

Søk

Søk etter pris (prismatrisevisning)

Søk etter tidsplan

Fleksible datoer

velg R20 søkeresultater (etter pris) - Viser reiseruter -Rediger søk

P30 Setevelger

anmeldelse

R60 Fleksibel Datoer Søkeresultater (etter pris)

R10 søkeresultater (etter tidsplan) Viser segmenter - Rediger søk

P10 Se gjennom reiserute/ passasjerinformasjon – velg seter

Kjøp

P20 Betalings- og faktureringsinformasjon

Nøkkel

Side

Flere sider

bekrefte

P50 Bekreftelse

Beslutningspunkt Kobling

Betinget kobling

Figur 10.18 Oppgaveflyt som brukes til å demonstrere veien til en bruker gjennom fasene i en kjøpsprosess

Brukere av denne applikasjonen kan legge inn et sett med datoer for deres reise og deretter foreta kjøp basert på deres egne prioriteringer. Etter at brukerne har angitt datoene sine for å søke etter reiser, kan de prioritere resultatene i henhold til det som er viktigst for dem: pris, ﬂeksibilitet for reisedatoer eller reisetider (plan). Oppgaveflyten identifiserer veier på høyt nivå som en bruker kan ta for å gi veiledning til personene som legger til rette for testingen. Detaljerte oppgaveflyter kan opprettes for hver av banene i grupperingene og deretter gis til utviklingsteamet for å lage sidene som er nødvendige for testing.

180

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

Ta oppgaveflyt til neste nivå Som med alle emnene i denne boken, ikke føl at det du ser her er begynnelsen og slutten på universet av oppgaveflyt. Utforsk nye bruksområder og utvid din bruk av det grunnleggende skissert her så mye som mulig – så lenge det er en god hensikt med det. Ettersom ferdighetene dine med å lage oppgaveflyt fortsetter å vokse, kan du finne deg selv å lage et arbeidsprodukt som er litt mer fargerikt, har flere alternativer, inkluderer modifiserte eller forbedrede språkregler, og så videre.

Prosessflyt Figur 10.19 viser en oppgaveflyt Will Evans (www.semanticfoundry.com) tok til neste nivå og ble omgjort til et prosessflytdiagram. Prosessflyten hans er på et meget høyt nivå og ﬂeksibel og brukes her for å vise at i de mange trinnene i en prosjektprosess, ser den første fasen av prosjektet ut til å være et enkelt trinn, men i dette spesielle tilfellet er det viktig å forstå at fasen ikke består av en enkelt hendelse. I stedet er den første fasen av prosjektet, i dette tilfellet, faktisk sammensatt av mange forskjellige aktiviteter: Brukerundersøkelse Markedsundersøkelse Etnografi og kontekstuell undersøkelse Brukerbarhetstesting Konkurranseanalyse Markedsanalyse Kulturanalyse Loggfilanalyse

Å TA OPPGAVEFLØTER TIL NESTE NIVÅ

181

Figur 10.19 Dette prosessflytdiagrammet tar oppgaveflytene til neste nivå for å artikulere komplekse scenarier. Med tillatelse fra Will Evans.

For hver av disse aktivitetene genereres det rapporter som føres inn i andre ulike dokumenter før prosjektet starter, hvor de nødvendige interessentene vil samles for å bestemme omfanget, prioriteringen og datoer. Alt dette er vist i prosessflytdiagrammet. Som du kan se fra dette eksemplet, er himmelen grensen når det gjelder å lage oppgaveflyter. Se på eksemplet ovenfor og vurder måter å ta leveransene dine til neste nivå. Det kan ta litt øvelse, men med litt finesse kan du lage oppgaveflyter som vil blåse bort kundene dine!

Swimlanes James Melzer (www.jamesmelzer.com), hovedinformasjonsarkitekt ved SRA International Inc. (www.sra.com), har laget en rekke diagrammer som strekker seg langt utover de grunnleggende oppgaveflytene. Diagrammet i figur 10.20 viser en oppgaveflyt som ble utvidet til å vise "svømmebaner" av handlinger, varslinger og så videre i en prosess som hadde mange hendelser som skjedde samtidig – med dette prosjektet kunne en tradisjonell tilnærming til oppgaveflyter har vært et mareritt!

182

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

I stedet utforsket James å utvide den grunnleggende oppgaveflyten til å omfatte alle de ulike trinnene og handlingene som fant sted i et format som var mye lettere å forstå.

Figur 10.20 Dette svømmebanediagrammet er et eksempel på utvidelse av oppgaveflyt for å illustrere komplekse scenarier med flere handlinger mange steder. Med tillatelse fra James Melzer.

James beskrev prosjektet og svømmebanene som følger: Systemet lar folk administrere informasjon om bygninger de eier. Denne utvidelsen vil gjøre det mulig for byggetjenestepartnere å levere datasystem-til-system på vegne av kundene sine, noe som reduserer nødvendig dataregistrering fra eierne. Prosjektet hadde tre deler: partnere som konﬁgurerte presentasjonen og driften av datatjenestene sine, kunder som registrerer seg og bruker partnerdatatjenestene, og pågående partnerdataadministrasjon og feilsøking på baksiden. Vi planla en større utvidelse av et eksisterende system. Vi visste tidlig at nesten alle tjenestescenarioene involverte flere brukere og flere systemer. Det var en rekke varslinger, og mange av prosessene var asynkrone. Dette diagrammet hjalp oss med å identifisere, designe og forklare tjenestescenarioene som trengs for prosjektet. I den fullstendige versjonen av dette arbeidsproduktet hadde vi faktisk detaljerte wireframes arrangert under strømmene i dette diagrammet. Det hele dekket en vegg. Når vi var ganske sikre på designkonseptet, kuttet vi det opp i en mer tradisjonell flersides spesifikasjon.

Å TA OPPGAVEFLØTER TIL NESTE NIVÅ

183

Det som er viktig å huske her er å ikke begrense deg selv i bruken av oppgaveflyt eller nettstedskart. Strekk grensene for det grunnleggende som du har blitt vist i dette kapittelet. Hvis du virkelig trenger noe for å teste evnen din, bruk litt tid på å lage en oppgaveflyt for hvordan du skal knyte skoene dine. Lykke til!

184

KAPITTEL 10: STEDKART OG OPPGAVEFLØTER

Trådrammer og merknader Design og retning – før den visuelle utformingen begynner Trådrammer og merknader er måter å identifisere det foreslåtte innholdet og strukturen på, så vel som funksjonell atferd, til en visning av en webside eller en applikasjon. Når de kombineres med nettstedskart og oppgaveflyt, er disse dokumentene også svært nyttige for å identifisere prototyping-scenarier og bevis på konsepter. Wireframes presenteres vanligvis i gråtoner, uten grafiske elementer eller ferdigstilt innhold; i stedet bruker de plassholderinnhold for å fremheve representative steder som kan brukes som veiledning i det visuelle designet. Russ Unger

Hva er en Wireframe? I utgangspunktet en lavfidelitetsprototype av en webside eller applikasjonsskjerm, en wireframe brukes til å identifisere elementene som vil bli vist på siden eller skjermen, for eksempel navigasjonsinnholdsseksjoner Bilder og/eller mediebehov Skjemaelementer Handlingsoppfordringer (CTAer) )

Trådrammer er vanligvis laget i svart-hvitt eller gråtoner, bruker plassholdere for bilder og kommer ikke inn på skriftspesifikasjoner (selv om mange bruker skriftstørrelse for å formidle separasjoner av kopityper). De kommer i alle former og størrelser – fra de helt grunnleggende til så avanserte at de nesten gjenskaper fullskjermdesign. Wireframes utvikler seg; ikke lenger er de bare gitt til designere og utviklere som skisser for deres oppgaver. Wireframes brukes nå til å representere nettstedet eller applikasjonen for kunder, designere, utviklere og andre teammedlemmer som har en eierandel i det på dets kjernenivå. Det er vanlig å vise dem til kunder for å få validering på "designtenkingen" før de visuelle design- og utviklingsfasene startes. Ofte jobber personene som lager wireframes hånd i hånd med de som lager forretningskravene (i noen tilfeller er de de samme personene). Det bør også bemerkes at noen av de beste wireframes og merknader er resultatet av direkte interaksjon og samarbeid mellom de ulike arbeidspartnerne – fra forretningsanalytikere til utviklere og andre designere. Noen selskaper går over til å bruke wireframes og merknader i stedet for forretningskravdokumenter (BRDs). Selv om verden er langt fra å hevde at BRD-er er utdødd, er begynnelsen på dette skiftet nok til å vise hvor viktig det er å være veldig grundig og gjennomtenkt mens du lager wireframes og merknader. I mange tilfeller vil brukere bli vist wireframes for å få tilbakemeldinger som kan validere sideelementene eller for å be om modifikasjoner. Wireframes det

186

KAPITTEL 11: WIRERAMMER OG ANNOTER

er plassert foran brukere har vanligvis et annet navn: prototyper. (For mer informasjon om prototyping, se kapittel 12.) For å hjelpe deg med å identifisere tilnærmingen som fungerer best for deg, diskuterer dette kapitlet det grunnleggende om å lage wireframes og viser eksempler fra designere i feltet. Som resten av denne boken er disse eksemplene bare begynnelsen – ikke vær redd for å utforske og innovere på egen hånd.

Hva er merknader? Merknader er ganske enkelt forklaringer og notater om et element eller en interaksjon på en wireframe. De inneholder vanligvis informasjon som innholdsidentifikasjon eller merking Innholdskilde(r) Visningsregler Interaksjonsregler Interaksjonsdestinasjoner Prosessregler Feilinnhold/meldinger

Det er best å skrive kommentarer med veldig direkte – om ikke kortfattet – tone og klare forklaringer. Ikke overlat noe til tilfeldighetene i en merknad; det er veldig stor forskjell på bør og skal. Dårlig: "Å utløse denne oppfordringen til handling (CTA) bør resultere i visning av hjemmesiden." Bra: "Å utløse denne oppfordringen til handling (CTA) vil resultere i visning av hjemmesiden." OK, for å være rettferdig, det første eksemplet er ikke akkurat fryktelig, men ordet burde kunne gi rom for forvirring for en utvikler nedstrøms i prosessen, som kanskje ikke har luksusen til sin favoritt UX-designer som står klar til å svare på spørsmål. Sørg for at kommentarstilen din er kortfattet og etterlater null tvetydighet for alle som trenger å lese – og stole på – instruksjonene dine.

HVA ER ANNOTER?

187

Hvem bruker Wireframes? Med sine klare, konsise merknader er wireframes veldig fine, men hvem er egentlig publikum for disse utgangene? Dessverre er det ikke noe enkelt svar på det. Fra prosjekt til prosjekt kan publikumet ditt variere fra en enkelt person til en kombinasjon av flere grupper. Tabell 11.1 skisserer de potensielle målgruppene for wireframes. TABELL 11.1

188

Wireframe-publikum

PUBLIKUM

HENSIKT

Prosjektledelse

Prosjektledere kan bruke wireframes som diskusjonspunkter i teamet for å fremheve strategi, teknologibehov og en brukeropplevelse på svært høyt nivå.

Forretningsanalytikere

Forretningsanalytikere kan bruke wireframes for å sikre at kravene deres blir oppfylt og for å validere at de ikke har gått glipp av krav som må inkluderes.

Visuelle designere

Visuelle designere kan bruke wireframes som en blåkopi for produksjonen deres. Wireframes gir dem en regnskapsføring av sideelementer og atferd som må inkluderes.

Innholdsskapere

Tekstforfattere, innholdsstrateger, redaktører og andre personer som er ansvarlige for kopiering kan bruke wireframes for å kartlegge til en innholdsmatrise og identifisere innholdsbehov gjennom et prosjekt.

Spesialister på søkemotoroptimalisering (SEO).

SEO-spesialister kan bruke wireframes for å identifisere passende navneskjemaer, kopibehov og forbedringer av den generelle SEO-strategien. (For mer informasjon om SEO, se kapittel 8.)

Utviklere

Utviklere bruker ofte wireframes i forbindelse med (og noen ganger i stedet for) forretningskrav for å forstå de forventede funksjonene og oppførselen til designet. I noen tilfeller kan wireframes brukes som grunnlag for et proof of concept.

Kvalitetssikring

Et QA-team kan bruke wireframes som grunnlag for å skrive testskriptene sine. Når wireframes er godkjent av klienten, bør variasjonen være minimal, og dette gjør at QA-teamet kan begynne å jobbe med oppgavene sine tidligere.

Brukere

Brukere kan se wireframes i veldig tidlige stadier, noen ganger i form av "papirprototyper," som en mekanisme for å teste designretningen. (Se kapittel 12.)

Kunder

Kunder er i økende grad involvert i gjennomgangen av wireframes for å validere om forretningskravene, målene og målene er oppfylt og for å gi godkjenning for å gå videre inn i den visuelle designfasen.

KAPITTEL 11: WIRERAMMER OG ANNOTER

Opprette Wireframes For å lage en wireframe trenger du vanligvis et sett med krav. Disse kan komme i form av et formelt forretningskravdokument fra en klient, en kreativ brief eller prosjektbrief, møtenotater, et velartikulert nettstedskart eller oppgaveflyt, eller til og med notater på en serviett som gir veiledning. På en eller annen måte trenger du en forståelse av hva det er du prøver å skape for en bruker, hvilke sammenhenger det er, og en generell forståelse av de teknologiske begrensningene og forventningene. Merk For mer informasjon om å definere forretningskrav, se kapittel 4 og 5. For forslag til effektive møtenotater, se online bonuskapittelet, "A Brief Guide to Meetings," på www.projectuxd.com.

Etter at du har samlet den nødvendige informasjonen, ta deg tid til å lese nøye gjennom alle kravene, stille spørsmål og vurdere svarene for å få ytterligere klarhet, er du klar til å begynne å lage wireframes!

Verktøy for handel Kapittel 10s "Tools of the Trade"-seksjon listet opp de mange designverktøyene du kan bruke til å lage nettstedskart og oppgaveflyter. Den gode nyheten er at du i utgangspunktet kan bruke de samme applikasjonene for wireframes og merknader. Den dårlige nyheten er at hvis dette er din første erfaring med å lage wireframes, kan du føle deg litt fortapt om hvor du skal begynne. Men vent – det er fortsatt flere gode nyheter. Nesten alle erfarne brukererfaringer kommer i gang med blyant og papir, så du bør ikke føle at du umiddelbart trenger å velge en teknologiløsning (selv om det er fullt mulig at du må oversette fra skisser til noe digitalt ganske raskt). Leah Buley, erfaringsdesigner ved Adaptive Path, fremhever viktigheten av å bruke blyant og papir (på samme måte som forfatterne) i sin "How to Be a UX Team of One"-presentasjon. Leah sier: Når du først begynner å skissere ideer til en wireframe, er det dette som ofte skjer: Du har en eller to gode ideer, og så treffer du en vegg. Disse ideene vil sannsynligvis komme fra noe du har sett og likt, eller fra noe du har designet tidligere. Det er ikke et sluttpunkt; det er et godt utgangspunkt.

HVEM BRUKER WIRERAMES?

189

Sinnet har en tendens til å rase mot det som er kjent, men det som er kjent er kanskje ikke alltid den beste løsningen på problemet. Når du tvinger deg selv til å søke mer varierte ideer, ofte ved idé 4 eller 5, har du kommet opp med noe nytt og interessant. Jeg vet ikke hvorfor det skjer på den måten. Det bare gjør det. Maler kan være nyttige for å veilede deg selv gjennom denne prosessen. Hos Adaptive Path bruker vi en seks-opp-mal, som ganske enkelt gir plass til å lage seks små miniatyrbilder. Antall skisser er faktisk ikke så viktig. Det som er viktig er å tvinge deg selv til å gå utover de første åpenbare ideene. Seks er et magisk tall (for meg) fordi seks-opp-malen, med sine seks små bokser, oppmuntrer meg til å fortsette til alle de små miniatyrbildene er fylt ut.

Figur 11.1 Adaptive Paths seks-opp-mal

Dette er gode ord å leve etter - spesielt hvis du bare blir kjent med arbeidet du gjør i UX-designverdenen. Etter hvert som tiden går, vil du begynne å identifisere en tilnærming som fungerer best for deg, men det er ikke mye bedre råd enn Leahs. For ytterligere innsikt i tilnærmingen hennes, er hele presentasjonen "How to Be a UX Team of One" tilgjengelig online på www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one. Ikke vær redd for å komme i gang med blyant og papir – bare sørg for å ta med mange viskelær. Feil er en del av prosessen, og du bør forvente at selv etter at du har forpliktet deg til en blyantskisse, vil du gjøre modifikasjoner etter hvert som du går over til digitalt.

190

KAPITTEL 11: WIRERAMMER OG ANNOTER

Få yrker opererer innenfor området for iterasjoner så ofte og konsekvent som UX-designere. Svært sjelden, om noen gang, blir designarbeid akseptert ved første pass, og noen ganger kan du bare håpe på å være "feil i riktig retning." På grunn av dette, start i det små: Ta en enkelt side eller en liten del av en del av et prosjekt, gjennomgå den først med det interne teamet ditt, og deretter med kundeteamet ditt for å sikre at forståelsen din er på rett spor. Å få designene dine i tråd med kundens måte å tenke på forretningsmålene deres på forhånd sparer deg for mye omarbeid fremover. Den samme tilnærmingen kan gjelde for designtesting med brukere – søk validering tidlig!

Start enkelt: Design en grunnleggende wireframe I denne delen vil du se hvordan du lager en wireframe på et veldig grunnleggende nivå. Ofte starter du kanskje med noe mer enn et enkelt nettstedskart og noen tilleggskrav, men med disse kan du bygge en wireframe for hjemmesiden til et nettsted. Husker du det grunnleggende nettstedskartet fra kapittel 10, som viste hvordan et veldig enkelt nettsted kan være strukturert? Figur 11.2 presenterer en oppfriskning – som du kan se er det vist en grad av navigasjonshierarki. Hver X.0-side som identifiseres er mest sannsynlig en topp- eller primærside. Du kan bruke dette som et startpunkt for å definere en del av forretningskravene og en wireframe. 1.0

1.0.1 Vilkår og betingelser

Hjemmeside

2.0 – 2.x Blogg

3.0 Om

4.0 Arbeid

5.0 Kontakt

Figur 11.2 Et nettstedskart for et grunnleggende nettsted med bloggfunksjonalitet

START ENKELT: DESIGN EN GRUNNLEGGENDE WIRERAMME

191

Komme i gang Det er ikke uvanlig at du kan være forfatteren av ditt eget forretningskravdokument, og det kan være en velsignelse og en forbannelse. Når du er forfatteren av kravene, har du i hovedsak bare deg selv – eller klienten din – som du kan diskutere betydningen av noe vagt eller relativt udefinert med. Ofte kan det føles som om du finner på det mens du går – men ikke la det avskrekke deg. I mange tilfeller vil wireframes hjelpe deg med å identifisere hull i informasjonen du jobber med. Dette kan hjelpe deg med å lage den beste løsningen – til slutt. Husk at brukere av brukeropplevelse jobber for å legge frem den best mulige løsningen for brukerne, og de første versjonene dine av ethvert prosjekt vil alltid bli brukt til å be om tilbakemelding og påvirke neste gjentakelse av design. Designet ditt trenger ikke å være perfekt, men du vil sørge for at det ser rent og profesjonelt ut, og at det i verste fall er feil i riktig retning. Kravene til denne hjemmesidedesignen er begrensede og veldig korte. Heldigvis gir nettstedskartet i figur 11.2 nok informasjon til å formulere navigasjonen som kan brukes for nettstedet: Hjemmesiden (nummerert 1.0) er det øverste navigasjonsnivået. Vilkår

& Betingelser (1.0.1) er mest sannsynlig et vanlig bunntekstelement, eller i det minste bør det ikke betraktes som en del av den primære navigasjonen. De andre primære navigasjonselementene er About (3.0), Work (4.0), Con-

tact (5.0) og Blog (2.0–2.x) – som er avbildet som en sidestabel, slik at du kan forsikre deg om at den vil bli sett på som flere dynamiske sider og kan ha en "forrige" og "neste" form for navigering. Disse primære navigasjonselementene gir deg ganske mye informasjon å komme i gang med – men det er ikke i nærheten av nok til å effektivt lage en hjemmeside for et nettsted. Så, for å hjelpe til med å gi veiledning, ga kunden litt tilleggsinformasjon: Selskapet er et boutique-designfirma for brukeropplevelse som har fått eksponering på grunn av bloggingen sin og utvalget av prosjekter det har jobbet med. Det er viktig at besøkende på nettstedet raskt kan lære hva selskapet/nettstedet handler om gjennom begrenset tekst og sterke, stemningsfulle bilder som fungerer sammen med design av brukeropplevelse. I tillegg er det viktig at navigasjonen er tydelig (foretrekker gjenbrukbar topp- og bunntekst, hvis mulig) og

192

KAPITTEL 11: WIRERAMMER OG ANNOTER

at det er en oppfordring til handling til de siste blogginnleggene slik at besøkende raskt kan lese et sammendrag av vår siste versjon av aktuelle problemer i brukeropplevelsesverdenen. Hvis det er mulig, ville det være fint å kunne fremheve nyere arbeid på hjemmesiden, men dette er sekundært, siden mye av arbeidet vårt ofte er under utvikling eller strengt taushetsplikt.

Wireframes og merknader Det er en rekke måter å tolke disse kravene på, og den første wireframe-presentasjonen til klienten kan være veldig lik figur 11.3. WIRERAMME MED ANNOTER Hjemmesidekommentarer 1

Logo 2

Hjem

Blogg

Vårt arbeid

Om oss

Kontakt

1 · Logobilde.· Logo skal fungere som lenke til hjemmesiden til

nettstedet fra et hvilket som helst sted på nettstedet. 2 · Hjemnavigasjon.· Skal lenke til hjemmesiden til nettsiden

fra et hvilket som helst sted på nettstedet. 3 · Bloggnavigering.· Skal lenke til bloggens landingsside fra hvilken som helst

plassering på nettstedet. 4 · Our Work Navigation.· Skal lenke til Our Work-landingssiden

fra et hvilket som helst sted på nettstedet. 5 · Om oss-navigering.· Skal lenke til landingssiden Om oss 6 7

7 8 9 10 11

Velkommen Tittel Goes Here

Lorem ipsum smerte sit amet, consectetuer adipiscing elite, sed diam nonummy nibh euismod tincidunt ut laoreet 9 smerte magna aliquam erat volutpat.

Lorem ipsum pain sit amet, consectetuer adipiscing elit, 15 sed diam nonummy nibh euismod tincidunt ut laoreet pain magna aliquam erat volutpat.

1. 3

Som jeg har sett, vil jeg komme til et minimum, hvem som ikke utøver den fysiske avstraffelsen av spillerne som noen av dem. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Jeg er veldig lei meg for smerten, consectetuer adipiscing 12

13 Mer > 17

Varenummer

15 16 17 18 19

fra et hvilket som helst sted på nettstedet. · Kontaktnavigering.· Skal lenke til kontaktsiden fra et hvilket som helst sted på nettstedet. · Roterende heltebilder.· Bilder skal rotere gjennom flere bilder som er estetisk tiltalende og i tråd med merket. · Velkommen Tittel.· Tittel for den generelle nettsidens oversiktstekst. · Velkomstinnhold. · Generell oversikt innhold for nettstedet. · · Tittel.· Tittel på det tilfeldige eksemplet som vises fra arbeidsporteføljen. · · Bildekobling.· Bilde av det tilfeldige eksemplet vist fra arbeidsporteføljen. Skal lenke for å se detaljene i det tilfeldige eksemplet som vises fra arbeidsporteføljen. · · Sammendrag. · Kort oppsummeringstekst av det tilfeldige eksemplet vist fra arbeidsporteføljen (anbefalt maksimalt 1-2 linjer med tekst). · · More Link.· Skal lenke for å se detaljene i det tilfeldige eksemplet som vises fra arbeidsporteføljen. · · Tittel.· Tittel på det siste liveblogginnlegget. · · Introinnhold.· De første 200 tegnene i det siste liveblogginnlegget. · · Mer lenke.· Skal lenke for å se hele blogginnlegget av det siste liveblogginnlegget. · Opphavsrettsinnhold.· Opphavsrett og inneværende år sammen med navn på selskapet. · Vilkår · &· Betingelseslenke.· Skal lenke til vilkårene · &· Betingelser-siden fra et hvilket som helst sted på nettstedet. · Kontaktkobling.· Skal koble til kontaktsiden fra et hvilket som helst sted på nettstedet.

8 · Velkommen Tittel.· Tittel for den generelle nettsidens oversiktstekst. 9 · Velkomstinnhold. · Generell oversikt innhold for nettside. 10 · · Tittel.· Tittel på det tilfeldige eksemplet

vist fra arbeidsporteføljen. 11 · · Bildekobling.· Bilde av den tilfeldige

nt bloggtittel>

smerte sit amet, consectetuer a 15 ummy nibh euismod tincidunt aliquam erat volutpat.

Jeg skal fortelle deg hvem vi er

1. 3

15 16 17 18

Merknad 19

eksempel vist fra arbeidsporteføljen. Skal lenke for å se detaljene i det tilfeldige eksemplet som vises fra arbeidsporteføljen. · · Sammendrag. · Kort oppsummeringstekst av det tilfeldige eksemplet vist fra arbeidsporteføljen (anbefalt maksimalt 1-2 linjer med tekst). · · More Link.· Skal lenke for å se detaljene i det tilfeldige eksemplet som vises fra arbeidsporteføljen. · · Tittel.· Tittel på det siste liveblogginnlegget. · · Introinnhold.· De første 200 tegnene i det siste liveblogginnlegget. · · Mer lenke.· Skal lenke for å se hele blogginnlegget av det siste liveblogginnlegget. · Opphavsrettsinnhold.· Opphavsrett og inneværende år sammen med navn på selskapet. · Vilkår · &· Betingelseslenke.· Skal lenke til vilkårene · &· Betingelser-siden fra et hvilket som helst sted på nettstedet. · Kontaktkobling.· Skal koble til kontaktsiden fra et hvilket som helst sted på nettstedet.

Figur 11.3 Wireframes med merknader sendt inn for hjemmesidedesign

START ENKELT: DESIGN EN GRUNNLEGGENDE WIRERAMME

193

Trådrammen med merknader beskriver hvert element på siden, samt forventede oppfordringer til handling og handlingsresultatene (som lasting av en spesifikk side). Dette spesielle eksemplet fungerer veldig bra på grunn av det begrensede antallet elementer og den begrensede detaljmengden som kreves.

Figur 11.4 Live hjemmesidedesign for www.userglue.com

Som figur 11.4 viser, er live-versjonen av denne hjemmesiden i dag bare litt annerledes enn den originale wireframe i figur 11.3. Fordi tidslinje og innhold ble problemer, ble for eksempel delen Porteføljeeksempler fjernet. Legg også merke til forskjellen i navnekonvensjoner for navigasjon og oppfordringer til handling: Trådrammen fungerte som en rettesnor, det var ikke det siste ordet. Sluttresultatet ditt vil også ofte ha en rekke mindre endringer og oppdateringer sammenlignet med innholdet i wireframe.

194

KAPITTEL 11: WIRERAMMER OG ANNOTER

En øvelse: Design en hjemmeside Wireframe Du har sett et eksempel, nå er det på tide å dykke rett inn og lage en wireframe på egen hånd. Oppdraget ditt er å redesigne hjemmesiden til Global Cruises, et fiktivt internasjonalt cruiseselskap. Global Cruises ønsker at hjemmesiden deres skal bli mer effektiv som et salgsverktøy og informasjonsressurs for tilbakevendende besøkende – som ofte ser ut til å være de som har bestilt et cruise og er interessert i å lære mer om andre muligheter og tillegg, oppdateringer av reiseforhold , og så videre. Øvelsen går ut på å bruke kravene nedenfor for å lage én hjemmeside wireframe med merknader på dokumentet eller i et eget dokument (ditt valg). Ikke noe mer.

Krav Hovedkravet er at den globale toppteksten og bunnteksten (figur 11.5) forblir de samme – absolutt uendret. GLOBAL HEADER Logo Destinasjoner

Nåværende reiseopplevelse med kampanjelogo

Planlegg en tur

Søk

Før turen

Globale cruise

VIP-klubb

Spesialtilbud

Gå

Mine globale cruise

Velkommen tilbake, N ( eller ?) | XX dager til neste cruise – Administrer reservasjon | BookTravel-tillegg| Online innsjekking

Figur 11.5 Eksisterende Global Cruises global topp- og bunntekst

EN ØVELSE: DESIGN EN HJEMMESIDE WIRERAMME

195

Bunnteksten må være Registrer deg for å motta Global Cruises e-poster Om Global Cruises | Kontakt oss | Vanlige spørsmål | Reisebyråsøker | Nettstedskart | Juridisk informasjon | Prisbetingelser | Retningslinjer for personvern Opphavsrettsinformasjon I tillegg må nettstedet ha evne til å inneholde flere kampanjer Evne til å vise overskrifter/nyheter CTA for kundeservice CTA for Travel Agent Finder CTA for å bla gjennom populære reiseruter

"Nice to haves" er Evne til å vise de nyeste, mest populære og/eller salgsreiser. Evne til å vise reiseruteplasseringer og turpunkter Evne til, hvis du er logget inn, se reiserute (MIN REISERYE/IES) Evne til å se mersalgsvarer, f.eks. som ekstra stopp (for eksempel hvis du skal

til Hawaii, bestill en øytur), matopplevelser ombord, og så videre Alt annet du kan tenke deg å legge til som kan være av verdi for

Global Cruises Og nå begynner arbeidet. Begynn å skissere trådrammen din – og ikke glem å kommentere deretter! Når du har fullført wireframe, se på neste side for å se eksempler fra andre topp fagfolk som har mottatt det samme settet med krav.

196

KAPITTEL 11: WIRERAMMER OG ANNOTER

Resultatene: Design en hjemmeside Wireframe Will Evans, en brukeropplevelsesarkitekt ved Semantic Foundry (www .semanticfoundry.com) var snill nok til å lage wireframes basert på Global Cruise-øvelseskravene. Sammenlign ditt eget arbeid med designene hans i figur 11.6 og 11.7 for å se hvordan hans tilnærming er sammenlignet med din. En forklaring på hvordan han satte sammen wireframe og merknader følger. 990px brede reisevarsler

FINN ET CRUISE

LOGO

5.0

4.0

3.0

2.0

1.0

Bahamas

Nye reiseruter

GÅ

Kommenterte notater

Populære reiseruter

11 1

Destinasjoner

| Reiserfaring

Planlegg en tur

Før turen

Global Cruises VIP Club

Velkommen tilbake, W iMMŔLogg ut

6.0

7,0

8.0

Spesialtilbud

se reiserute | Min globale

15 dager til ditt neste cruise -

9,0 13

1.0

Reisevarsler: lenke til 0.2.0.0

2.0

Merkevarebygging/logo-lenker Hjemmeside

3.0

Søk med prediktivt forslag definert brukerscenario 3.X

4.0

6.0

Nye reiseruter rullegardinmenyen med lenke: vis reiserute m/lenke til seksjon 4.x Populære reiseruter - rullegardin som viser topp 5 mest populære reiseruter Destinasjoner Link: går til seksjon X.0

7,0

Travel Experience Link: går til seksjon X.0

8.0

Planlegg en tur Link: går til seksjon X.0

9,0

Før reisen din: går til seksjon X.0

Global Cruises VIP Club Link: går til seksjon X.0 Spesialtilbud Link: går til seksjon X.0

Min globale 12

5.0

Media/Flash/Hedonisk bilde

Tittel for Hero Shot 17 Global Headlines | Lag din egen hovedrolle

Trenger du hjelp til å planlegge cruiset ditt

Header Consectetut Adipisicing Clarity er selve tauet til huset eller smerten i irettesettelse i nytelsen ønsker å være et hår i smerten av eu

HEDONISK BILDE

Header Consequent Adipisicing

Ikke vær sint på smerten i irettesettelse i gleden han ønsker å være et hår fra smerten i håp om at det ikke er noen avl.

Idéoverskrift nummer 1

Idéoverskrift nummer 3

Idéoverskrift nummer 2

Idéoverskrift nummer4

Klarhet er Herrens tøyler, eller smertens vrede i irettesettelse, i nytelse vil han være en fjær i smerte

Idéoverskrift nummer 3

8. oktober 2008 18:46

Markedsføring

Men for at dere skal se hvorfra all denne fødte villfarelse kommer fra dem som anklager fornøyelse og priser smerte, vil jeg åpne hele saken og de samme tingene som den oppfinneren har gjort.

Legg ut ditt eget

Jeg er veldig lei meg for tapet av consectateur nonummy lorenzino. Noen ganger ser den vanlige mannen, det er der han gjør en feil.

25 Registrer deg for å motta globale e-poster.

Ikke fra? Klikk her

My Global Cruises Link: går til seksjon X.0 Logout Link: logger brukeren ut av økten

Vis reiserutelink: Går til My Global/ Se mine reiseruter-siden. Min globale lenke: Går til personlig tilpasset side Karusell av spesialtilbud/pakker-bilde

Starring You Moment Crowdsource-lenke

Link til boktilbud knyttet til bildet i det store heltebildet.

Trenger du hjelp til å planlegge cruiset ditt

20/21

Promotional CT As/Partner-kampanjer

Del Your Moments Call Out, medlemsprofil Legg ut din egen Starring Your Moments-lenke til croudsourcing-siden.

Men for at dere skal se hvorfra all denne fødte villfarelse hos dem som anklager glede og hyller smerte, vil jeg åpne opp hele saken og forklare akkurat det som ble sagt av den som oppdager sannheten og så å si arkitekten. av et lykkelig liv.

1. 3

Kampanje/nyheter

HEDONISK BILDE

IMG

Kampanje/nyheter

Starring You Moments

Bestill denne spesialpakken

Du øyeblikk nå! Gå

Registrer deg for å motta e-poster

Endre land-lenke

Globale bunntekstlenker

Side: 2

Figur 11.6 Global Cruises hjemmeside wireframe av Will Evans

EN ØVELSE: DESIGN EN HJEMMESIDE WIRERAMME

197

990px brede reisevarsler

FINN ET CRUISE

LOGO

Destinasjoner

5.0

4.0

3.0

2.0

1.0

Bahamas

Nye reiseruter

GÅ

OK, Vil "Bahamas" | Reiserfaring | for Planlegg en tur vi| funnet før reisen din

18|

Kommenterte notater

Populære reiseruter 1

Global Cruises VIP Club 6.0

Spesialtilbud

Cruise spesialtilbud

Velkommen tilbake, W iMMŔLogg ut

7,0

$279

Bahamas og Florida

$279

Bahamas og Florida

$279

Bahamas og Florida

$279

Bahamas og Florida

Charleston Freeport

15 dager til ditt neste cruise -

7 netter

Great Stirrup Cay (vår private øy) Port Canaveral Charleston

Nassau

Great Stirrup Cay (vår private øy) Port Canaveral Charleston

Nassau

Media/Flash/Hedonisk bilde

Filtrer globale overskrifter | Lag din egen hovedrolle Trenger hjelp til å planlegge cruiset

Charleston Freeport

Great Stirrup Cay (vår private øy) Port Canaveral Charleston

IMG

6.0

Rask forslag: bufrede resultater viser samsvarende streng

7,0

Cruise Billet med følgende metadata: 1. Pris 2. Gjennomsnittlig vurdering 3. Tittel: Cruise Tittel 4. Varighet 5. Anløpssteder 6. Detaljer Link 7. Bestill denne cruiselinken 8. Husk/Favorit dette cruiset

8.0

Fasettnavigasjon lar brukeren dynamisk endre havn, reisemåned, skip eller prisklasse og vil dynamisk sortere/ﬁ ltrere samsvarende resultater. Enhver av disse kan reverseres når brukeren ser hele resultatene på søkeresultatskjermen

9,0

Etter at bruk har justert ﬁ ltrene for prediktivt søk, kan de klikke for å se alle søkeresultater som vil bruke Ajax til å laste inn komplette resultater i en javascript-matrise for rask sortering.

Del Your Moments Call Out, medlemsprofil Legg ut din egen Starring Your Moments-lenke til croudsourcing-siden.

detaljer

Tittel for Shot FridayHero Saturday

Bestill denne spesialpakken

-Alle skipskampanjer/nyheter

$190 til $1650

Header Adipisisic Duis vil bli fulgt, eller smerten vil bli irettesatt i nytelsen, han ønsker å være et hår fra smerten, og det vil ikke være noen fødsel.

Klarhet er Herrens tøyler, eller smertens vrede i irettesettelse, i nytelse vil han være en fjær i smerte

Starring You Moments

detaljer

Pris: HEDONISK BILDE

Klarhet er Herrens tøyler, eller smertens vrede i irettesettelse, i nytelse vil han være en fjær i smerte

Nye reiseruter rullegardinmenyen med lenke: vis reiserute m/lenke til seksjon 4.x Populære reiseruter - rullegardin som viser topp 5 mest populære reiseruter

5.0

Nassau

Skip:

-Hvilken måned -

HEDONISK BILDE

Header Consequent Adipisicing

Søk med prediktivt forslag definert brukerscenario 3.X

4.0

detaljer

Dine resultater You Y Moment now! Gå

Måned:

Merkevarebygging/logo-lenker Hjemmeside

3.0

Fredag Lørdag 7 netter

Great Stirrup Cay (vår private øy) Port Canaveral Charleston

Hjemmehavn/by: Kampanje/nyheter Washington, D.C. 8.0

Nassau

se reiserute | Min globale

Fredag Lørdag 7 netter

Reisevarsler: lenke til 0.2.0.0

2.0

detaljer

Fredag Lørdag 7 netter

1.0

Min globale

HEDONIC IMAGE 9.0 Se alle søkeresultater

Header Adipisisic Duis vil bli fulgt, eller smerten vil bli irettesatt i nytelsen, han ønsker å være et hår fra smerten, og det vil ikke være noen fødsel.

Idéoverskrift nummer 1

Idéoverskrift nummer 3

Idéoverskrift nummer 2

Idéoverskrift nummer4

Idéoverskrift nummer 3

8. oktober 2008 18:46

Markedsføring

Men for at dere skal se hvorfra all denne fødte villfarelse kommer fra dem som anklager nytelse og hyller smerte, vil jeg åpne opp hele saken og forklare akkurat det som ble sagt av den som oppdager sannheten og så å si arkitekt for et lykkelig liv. Men for at dere skal se hvorfra all denne fødte villfarelse kommer fra dem som anklager fornøyelse og priser smerte, vil jeg åpne hele saken og de samme tingene som den oppfinneren har gjort.

Legg ut ditt eget

11 1 12

Registrer deg for å motta e-poster

1. 3

Endre land-lenke

Globale bunntekstlenker

Jeg er veldig lei meg for tapet av consectateur nonummy lorenzino. Noen ganger ser den vanlige mannen, det er der han gjør en feil.

13 12

Registrer deg for å motta globale e-poster.

Ikke fra? Klikk her

Side: 3

Figur 11.7 Will Evans's Global Cruises hjemmeside wireframe med søk aktivert

Wireframe Creation in Will's Words For meg fungerer wireframes som en form for "tenkeanordning" for innstilling og utforskning av et gitt problemområde – i dette eksemplet, en hjemmeside for en cruiserederi. Design gjennom bruk av wireframes er et søk i et problemrom av alternativer; det er en prosess med problemstilling like mye som det er en prosess med problemløsning, noe som betyr at jeg alltid starter med konteksten. I dette tilfellet ønsker primærpublikummet å enkelt finne det beste cruiset, til rett tid, til riktig pris. For å forenkle velger jeg mitt primære publikum og den ene aktiviteten som lar dem løse ett mål raskt, uanstrengt og elegant. Ved å skissere en rekke wireframes kan jeg utforske alternativer, og både umulige og tenkelige ideer presenteres, testes og i mange tilfeller kastes bort. Jeg visste allerede at jeg ønsket å designe det beste søkegrensesnittet for cruiserederiene som mulig, og jeg ønsket at aktiviteten skulle settes i sentrum i designet. Det var her jeg skisserte konseptet med å gi umiddelbare foreslåtte cruise selv før brukeren hadde forpliktet seg til å se

198

KAPITTEL 11: WIRERAMMER OG ANNOTER

en fullstendig søkeresultatskjerm. Jeg ønsket at brukeren skulle bli dratt inn i en samtale og engasjert i prosessen med å finne et flott cruise. FINN ET CRUISE

Bahamas

OK, Will for "Bahamas" fant vi

GÅ

18 cruisetilbud

$279

Bahamas og Florida

$279

Bahamas og Florida

$279

Bahamas og Florida

$279

Bahamas og Florida

Charleston Freeport

7 netter

Great Stirrup Cay (vår private øy) Port Canaveral Charleston

Nassau

7 netter

Great Stirrup Cay (vår private øy) Port Canaveral Charleston

Nassau

detaljer

Fredag Lørdag 7 netter

Great Stirrup Cay (vår private øy) Port Canaveral Charleston

detaljer

Fredag Lørdag 7 netter

Great Stirrup Cay (vår private øy) Port Canaveral Charleston

detaljer

fredag Lørdag

detaljer

fredag Lørdag

Filtrer resultatene dine Y Hjemmehavn/by: Måned:

Washington DC.

Skip:

-Hvilken måned -

Pris:

- Hvilket som helst skip

$190 til $1650

Se alle søkeresultater

Figur 11.8 Will Evans sin forside cruise-søkeresultatfunksjon

Når det gjelder cruiserederioperatøren, skisserte jeg topptekst, bunntekst, statisk innhold og behovet for å blokkere områder i designet for innholdsmoduler som CTAer og kampanjer. Jeg deler resultatet fra dette stadiet med de viktigste interessentene, men jeg henter også inn den visuelle designeren og utviklingslederen, samt kvalitetssikringen, slik at de kan bidra til prosessen, komme med flere ideer og begynne å dokumentere fallgruver og begrensninger. Til slutt, som designer, måtte jeg ta beslutningen om å implementere designet i en spesifikasjon. Jeg opprettet to eller tre kandidater for endelig vurdering, og ved bruk av merknader ga jeg wireframen makt til å forsvare sin sak til interessenter og målrettede testere. Trådrammene du ser i figur 11.6 og 11.7 er nå på dette stadiet, hvor designendringene er små og detaljene poleres.

EN ØVELSE: DESIGN EN HJEMMESIDE WIRERAMME

199

Sammenlign og kontrast Det er viktig å merke seg at eksemplet i figur 11.3 og arbeidet til Will Evans er ganske like – men likevel forskjellige – stiler for å lage wireframes. Det er lett å se på både nå og stolt kunngjøre: "Dette er wireframes!" De har begge elementer av sin egen stil og tilnærming, men kjernen er veldig lik. Eksemplene i dette kapittelet er gode steder å begynne å finne stilen for wireframing som fungerer best for deg.

Bilder med tillatelse av Maciej Piwowarczyk

Visuell design: Når Wireframes vokser opp og finner sin egen vei i verden

Figur 11.9 Visuell design av Global Cruises hjemmeside av Mark Brooks

200

KAPITTEL 11: WIRERAMMER OG ANNOTER

Ut fra kravene og Will Evans sin wireframe, skapte Mark Brooks (www .markpbrooks.com) et hjemmesidedesign for de fiktive Global Cruise Lines. Når du gjennomgår den visuelle utformingen i figur 11.9, legg merke til hvordan han stod for layout og innhold på siden. Når designet beveger seg gjennom prosessen og inn i utviklingen, vil interaksjonsmodellene begynne å komme til live.

Oppfølging av designøvelser: Hvilket design er riktig? Det er ikke noe riktig – eller galt – design, så lenge kravene er oppfylt. Noen ganger kan du føle deg tvunget til å lage flere wireframes for en enkelt side for å utforske ulike tilnærminger, jobbe gjennom detaljene og presentere for potensielle brukere, lagkamerater og muligens dine kunder. Dette er helt akseptabelt. Husk at dette er en øvelse i iterasjoner. Arbeidet du presenterer for en klient er nesten alltid garantert å ikke anses som "riktig" eller "endelig" ved første forsøk. Oftere enn ikke vil du finne deg selv å jobbe gjennom minst én runde med iterasjoner og oppdateringer. Dessverre kan det noen ganger strekke seg til flere runder – men det er typen av prosjekter, og det bør til slutt føre til mindre leting for dine nedstrøms arbeidspartnere. Mens du sammenligner wireframe og merknader med de to eksemplene som er gitt, undersøk forskjellen i tilnærming og presentasjonsstil. Sammenlign disse med eksempelet på hjemmesiden tidligere i kapitlet og med arbeidet du gjorde. Finn likhetene og forskjellene og lag den tilnærmingen som fungerer best for deg, med mindre det allerede er en etablert mal på plass for deg. I mange tilfeller er den vanskeligste delen med å lage en trådramme å få blyanten til papiret for første gang. Følg Leah Buleys råd og begynn å skissere flere ideer – dodle og tegne, utforsk ulike tilnærminger og test designene dine med kolleger, jevnaldrende og familiemedlemmer til du føler deg trygg på at du kan forsvare designet ditt (uten å være defensiv), og du vil finne at du beveger deg i riktig retning.

EN ØVELSE: DESIGN EN HJEMMESIDE WIRERAMME

201

En siste merknad om presentasjon av wireframes Når du begynner å lage wireframes og blir mer komfortabel med arbeidsproduktet – og forstår hvor verdifulle de er for arbeidsflyten din – er det lett å glemme at ikke alle forstår mengden av tanker og tid som går med til å lage dem. Ofte kan klienter og arbeidspartnere ha blitt utsatt for wireframes av et helt annet kvalitetsnivå, kompleksitet eller med en annen stil av merknader. Faktisk kan du finne ut at mange av dine arbeidspartnere og klienter aldri har sett en wireframe før (selv om de sier at de har det). Det er heller ikke uvanlig at kunder og arbeidspartnere blir forvirret over forskjellene mellom nettstedskart og wireframes, og formålet med hver. Med andre ord, din første wireframe kan potensielt også være din klients første wireframe! Dette gjør det ekstremt viktig å nøyaktig sette scenen for det du skal presentere. Før du presenterer wireframes, må du tydelig forklare hva de er, hvordan de vil se ut sammenlignet med et endelig visuelt design, og hva deres formål er. Her er noen tilleggsråd for presentasjon av wireframes: Hvis mulig, engasjer kundens team under oppdagelsen; prøv å få dem

med på å aktivt tegne på en tavle. Forklar at de bidrar til wireframing-prosessen og at sluttresultatet vil se likt ut, men det vil bli produsert i et elektronisk format. Det er veldig viktig å forklare at dette er en aktivitet som vil føre til wireframes som kan se helt annerledes ut mens du utforsker designalternativer. Finn sterke metaforer for å formidle forskjellene mellom ledningene dine

rammer og den endelige utformingen av prosjektet. En populær metafor er "Wireframes er for applikasjoner/nettsteder hva tegninger/planplaner er for et hus." Wireframes gjør at endringer kan implementeres enklere og mer effektivt, og på et tidspunkt da endringer generelt er rimeligere (før man engasjerer byggeteamene og legger grunnlaget). Fortell møtedeltakerne at wireframes ikke er en endelig representasjon.

tasjon av den grafiske behandlingen av nettstedet. Trådrammene blir presentert for å ta hensyn til innhold, generell layout og interaksjon

202

KAPITTEL 11: WIRERAMMER OG ANNOTER

elementer på sidene. Når wireframes er godkjent, kan bygget starte. (Åh, og subtile endringer kan fortsatt forekomme!) Engasjer dine visuelle designere – hvis det er tid og budsjett – for å gi

design mock-ups for å vise forskjellene mellom wireframes og et endelig design. Hvis mulig, vis kunden eksempler fra andre prosjekter som viser hvordan wireframes og endelige design er like og forskjellige på samme tid. Forklar hvordan andre medlemmer av prosjektteamet ditt vil bruke ledningen-

rammer – det skader aldri for en klient å forstå viktigheten av deres gjennomgang og godkjenning av denne milepælen, samt hvordan wireframes informerer resten av prosjektet. Når dine kunder og arbeidspartnere begynner å forstå og verdsette verdien av wireframes og hvor de bor i designprosessen, blir det lettere å flytte prosjektene dine videre. Hvorfor? Fordi wireframes bidrar til å skape visuell klarhet og retning gjennom resten av prosjektet. I mange tilfeller kan arbeidspartnere og klienter til og med evangelisere nytten av wireframes på dine vegne. Dette lar deg bruke mer tid på å fokusere på design av brukeropplevelsen og mindre tid på å selge det!

EN SISTE MERKNAD OM PRESENTERING AV WIRERAMES

203

Prototyping Puster (en slags) liv i designene dine Prototyping er en effektiv måte å teste og validere foreslått funksjonalitet og design før du investerer i utvikling. Du kan bruke en rekke verktøy og tilnærminger for å lage prototyper, fra de raske og skitne (men vi foretrekker raske og rene) til de interaktive og robuste. Metoden du bruker vil i stor grad bestemmes av to faktorer: tiden og materialene du har tilgjengelig for å dedikere til prototypeutvikling. Russ Unger og Jono Kane

Hva er prototyping? I sammenheng med design av brukeropplevelse er prototyping handlingen (og i mange tilfeller kunsten å) lage og teste hele eller deler av funksjonaliteten til en applikasjon eller et nettsted med brukere. Prototyper kan lages med analoge verktøy (som tavler eller blyant og papir) eller digitalt med PowerPoint, Acrobat, Visio, OmniGraffle, HTML eller andre teknologibaserte verktøy. Prototyping kan være en iterativ prosess, da prototyper vanligvis lages for å identifisere problemer med – eller validere – brukeropplevelsen. Når du har samlet tilbakemeldinger, kan du gjøre modifikasjoner på prototypen for ytterligere testing. I andre tilfeller kan en vellykket (nok) prototype holde et prosjekt videre i andre faser av utviklingslivssyklusen. Husk at prototyping er en prosess og ikke en artefakt. Du kan ende opp med å lage skjermer og (noen ganger hånlig) funksjonalitet som du kaller en prototype, men disse er en del av prototyping, og ikke sluttresultatet. Resultatet av prototypingsprosessen er handlingsdyktig tilbakemelding fra konsepter som kan brukes til å forbedre og forbedre designet. Dette kapittelet fokuserer imidlertid kun på å lage prototypen, og overlater detaljene om testing til kapittel 13.

Hvor mye prototype trenger jeg? Enhver designprosess for brukeropplevelse bør inkludere en viss grad av prototyping – enten den er formell eller uformell, interaktiv eller statisk. Prototyping trenger ikke å utføres for en hel nettside eller applikasjon. Faktisk kan prototyping være svært effektiv når den bare bruker et representativt utvalg av et system – med andre ord, du trenger ikke å lage en simulering av hele systemet, men bare nøkkeldeler. I de fleste tilfeller vil du teste en håndfull konsepter, og prototypen din bør inkludere disse konseptene og litt mer. Du kan lage prototyping ved å bruke en rekke metoder som er lett tilgjengelige for deg: tavle, blyant-og-papir-skisser, storyboarding, papputskjæringer og så videre. I tillegg er en rekke digitale verktøy tilgjengelig som lar deg lage interaktive prototyper og engasjere testbrukerne dine i et mer realistisk miljø.

HVOR MYE PROTOTYPE TRENGER JEG?

205

Metoden for prototyping du velger vil i stor grad avhenge av tiden og materialene som er tilgjengelige for deg. Følgende er noen av de mer populære metodene som er tilgjengelige for å møte mange av dine prototypingsbehov.

Papirprototyping Få aktiviteter kan ta deg tilbake i de første årene som den praktiske, kunst- og håndverkstilnærmingen til papirprototyping. De eneste verktøyene som trengs er blyanter og penner, papir, saks og alt du kan sveipe fra kunstavdelingen eller kjøpe i en lokal kontorrekvisitabutikk. Papirprototyper er ﬂeksible. Så lenge du har et viskelær eller flere materialer, kan du lage så mange scenarier du trenger. Du kan også revidere raskt fra test til test – det vil si at hvis en potensiell bruker roper ut en åpenbar feil i noe du har laget, er det ikke en kompleks prosess å oppdatere designet før det vises til neste potensielle bruker. Det er også billig. Utover tiden du investerer i papirprototyping, kan du generelt lage et hvilket som helst scenario for mye mindre enn kostnaden for et par høybrynede latte. Papir, Post-it-lapper, kartotekkort, blyanter og lignende bør allerede være til din disposisjon, og hvis de ikke er det, vil du ikke bryte banken ved å fylle opp. Prosessen er enkel: Skisser delen av funksjonaliteten du vil teste. Presenter funksjonaliteten for brukeren(e). Dokumenter tilbakemeldingen (det er papir, så snu prototypen din og begynn å skrive). Gå deretter videre til neste bruker, eller foreta oppdateringer og start på nytt. Enkel. Moro. Effektiv. Brukt tidlig i prosessen, kan papirprototyping bidra til å avdekke designrelaterte problemer før du har blitt tungt investert. Endringer på dette stadiet kan gjøres raskt og effektivt, noe som reduserer risikoen. Dette lar deg gjøre effektive endringer før du investerer for mye i designet. Ved å bruke tre ark med forskjellig farget papir ble hver fane i figur 12.1 skissert slik den skulle vises på nettstedet og stablet oppå hverandre. Global Now-fanen er plassert øverst for å vise innholdet som om brukeren nettopp hadde besøkt hjemmesiden for første gang. Hver fane viser navigasjonen som er tilgjengelig for brukerne og lar dem velge et annet visningsalternativ.

206

KAPITTEL 12: PROTOTYPING

Figur 12.1 Papirprototype av en vertikal, fanebasert navigasjon

Figur 12.2 Papirprototype av en vertikal fanebasert navigasjon med fanen Min reiserute aktivert

Når en bruker velger en annen fane, flyttes den bestemte fanen til forsiden av stabelen for å vise den nylig aktive fanens visning av innholdsområdet, for eksempel fanen Min reiserute vist i figur 12.2. Papirprototyping er omtrent så lavbudsjett som du kan få, og kan være like enkelt som øvelsen ovenfor. Når du begynner å utforske komplette systemer, kan timene du investerer bli betydelige (selv om materialkostnadene bare øker litt). Hvis du trenger å endre den primære navigasjonen på hundre sider med papirprototyper, blir denne metoden kostbar. Selv om papirprototyper i hovedsak er lave kostnader, skalerer det ikke godt for gjenbruk når deler må oppdateres. Da bør du vurdere om det vil være mer fordelaktig å gå over til digitale verktøy.

Digital prototyping Hvis prototypingbehovet ditt er større enn papiret kan håndtere, kan du finne ut at en teknologibasert løsning fungerer bedre for deg og publikummet ditt. Disse verktøyene kan gjøre deg i stand til å vise nøyaktig hvordan interaktive deler av nettstedet eller applikasjonen vil se ut for brukerne. Digital prototyping trekker fra mange andre aspekter av designprosessen. Du vil kunne referere til personasene dine når du presenterer eller tester din digitale prototype, til wireframes for blokkering og visuell behandling av prototypen, og til visuelle designelementer (hvis de er tilgjengelige på dette tidspunktet i prosessen) for en realistisk ﬁnt og ﬁnish til prototypen din.

Wireframe vs. realistiske prototyper Akkurat som med metoder for papirprototyping, kan kjørelengden din variere med digitale prototyper. Avhengig av verktøyene, ressursene og ferdighetene du har

DIGITAL PROTOTYPING

207

avhending, så vel som kravene du har å gjøre med, kan du finne ut at det å ha prototypen din til å se ut som wireframes er godt nok for prosjektet ditt. Faktisk kan det være å foretrekke. Wireframes kan vise publikum at prosjektet fortsatt er et arbeid som pågår og ikke det endelige, produksjonsklare stedet. På den annen side, noen ganger under designtesting med brukere, vil du finne ut at det viktigste aspektet ved prototypen er hvor realistisk den representerer det endelige systemet. Resultatet av din digitale prototype hviler på tre faktorer: Hvordan ser tidslinjen din ut?

Har du tid til å samle et team og bygge en fantastisk, nesten produksjonsklar prototype som vil vise brukerne som sitter foran den en krystallklar visjon av det produksjonsklare nettstedet? Har du noen timer på å eksportere wireframes som HTML eller bygge et veldig enkelt Flash-prosjekt for å vise sideflyten og grunnleggende interaktive elementer i prosjektet? Begge typer digitale prototyper kan være svært nyttige. Men akkurat som med ethvert reelt prosjekt med en tidsfrist på vei, er det viktig å sette forventninger basert på tiden og materialene som er tilgjengelige for deg. Hvem bygger du denne prototypen for, og hvorfor?

Det er avgjørende for suksessen til prototypen din å vite hva du gjør med den før du går for dypt inn i prosjektet. Bygger du en prototype for designtesting med brukere? Hva er i så fall viktig å fokusere på for testingen? Spiller det noen rolle om prototypen er en svart-hvitt wireframe, eller trenger den å ligne på et live-nettsted? Tester du for synligheten av knapper og lenker? Bygger du prototypen for en forretningspitch som trenger buy-in fra et team av ledere, ledere, investorer eller andre som kanskje signerer sjekken din på slutten av dagen? Hvis ja, hva prøver du å kommunisere til dem? Hva må være funksjonelt og hva må rett og slett se funksjonelt ut? Disse spørsmålene kan bidra til å bestemme kravene til din digitale prototype.

208

KAPITTEL 12: PROTOTYPING

Hvilke typer ressurser, verktøy og ferdigheter har du tilgjengelig?

Hvis du ikke er en HTML- eller Flash-ekspert, og ikke har budsjettet til å engasjere noen som er det, kan du fortsatt bygge en veldig funksjonell prototype ved å bruke et enkelt presentasjonsverktøy som PowerPoint eller Keynote, eller et wireframing-verktøy som Visio eller OmniGraffle. Selv en enkel PDF kan gjøre det.

HTML vs. WYSIWYG Editors HTML er den digitale ekvivalenten til en papirprototype. Det er (noen ganger) gratis og (noe) enkelt. Hvis du ikke er en HTML-veiviser eller en grensesnittkodeekspert, kan du fortsatt være en HTML-prototypeveiviser med bare noen grunnleggende kunnskaper om HTML. Det er i hovedsak to måter å bygge en HTML-prototype på: enten ved å håndkode HTML-en eller ved å bruke et WYSIWYG-redigeringsprogram, for eksempel Adobe Dreamweaver, Realmacs RapidWeaver eller Microsoft Visual Studio. Disse verktøyene har en kodevisning så vel som en layoutvisning som lar deg visualisere kodeinnsatsen din uten å åpne en nettleser. Lage en prototype med et WYSIWYG-redigeringsprogram Det fine med å bruke layoutvisningen i et WYSIWYG HTML-redigeringsprogram er at du kan bygge et sideoppsett med omtrent samme innsats som det ville kreve å legge ut en side i Microsoft PowerPoint, Apples Keynote , eller andre enkle grafiske layoutapplikasjoner (mer om disse senere). Og det er like enkelt å legge til interaktivitet som lenker, musehendelser og så videre. En av de mest imponerende aspektene ved Dreamweaver CS4 (Figur 12.3) er at den har det Adobe kaller Live View, som er basert på åpen kildekode WebKit-gjengivelsesmotoren. Hva betyr dette? Ganske enkelt betyr det at det du ser i Live View er akkurat det du får i Apples Safari og Googles Chrome-nettlesere – forutsatt at du har vært nøye med detaljene i prototypen din. Dreamweaver CS4 er et veldig kraftig prototypeverktøy, spesielt når det brukes sammen med Adobe Fireworks CS4.

DIGITAL PROTOTYPING

209

Figur 12.3 En enkel eksempelprototype laget i Dreamweaver CS4

Lage en grunnleggende HTML-prototype Muligens den billigste måten å bygge en enkel, rask og skitten HTML-prototype på er å gjøre det "for hånd" - å skrive inn koden manuelt i et tekstredigeringsverktøy. En av de vanligste årsakene til å overføre et design fra wireframe til prototype er kravet om å vise eller teste den foreslåtte flyten og navigasjonen på nettstedet. Ved å ta blokker med elementer eller til og med hele sider fra wireframe (eller designmock-up) og sette dem opp som klikkbare bilder i HTML-prototypen din, kan du veldig raskt og enkelt bygge en fungerende prototype. En veldig enkel prototype som lar deg klikke helsidesbilder i en nettleser og deretter laste inn forskjellige sider er ganske grei. I den følgende øvelsen må du ha en hjemmeside og en wireframe for søkeresultater til din disposisjon, eller du kan laste ned eksempelbilder fra www.projectuxd.com. Merk Skrivefeil er de vanligste feilene som gjøres i HTML-koding, så vær nøye med å skrive nøyaktigheten.

210

KAPITTEL 12: PROTOTYPING

1. Eksporter startsiden wireframe fra ditt foretrukne verktøy (som Visio eller OmniGraffle) eller designkompet ditt fra ditt visuelle designverktøy. Du bør lagre hele siden som et GIF-bilde kalt homepage.gif; opprette en ny mappe kalt Prototype og lagre homepage.gif der. Merk JPEG-formatet fungerer utmerket for raster- og fotolignende bilder; GIF fungerer bedre for wireframes og strektegninger.

2. I WYSIWYG HTML-redigeringsprogrammet eller et enkelt tekstredigeringsprogram, for eksempel Notisblokk (Windows) eller TextEdit (Mac), opprett et nytt dokument og lagre det som homepage.html i samme Prototype-mappe. Hvis du bruker TextEdit, sørg for at du velger HTML som filformat. 3. I det nye dokumentet setter du inn følgende HTML-kode: 1]iba3 1]ZVY3

1i^iaZ3=dbZeV\Z1$i^iaZ3

1$]ZVY3 1WdYn3 1$WdYn3 1$]iba3

4. Lagre dokumentet, og åpne deretter filen i nettleseren. Du skal se en tom side, men legg merke til tittellinjen i nettleseren. Det skal stå "Hjemmeside." 5. I tekstredigeringsprogrammet endrer du koden homepage.html. Mellom taggene og, skriv inn følgende HTML: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

Denne koden vil gjøre hele homepage.gif-bildet om til en klikkbar knapp som laster siden searchresults.html (som du må opprette for å se om funksjonaliteten fungerer). 6. Lagre dokumentet og last inn siden på nytt i nettleseren din. Du bør se den nye hjemmesiden du nettopp opprettet i nettleseren din, i all sin prakt (Figur 12.4). Når du klikker på bildet i nettleseren vil nettleseren prøve å laste siden searchresults.html (som ikke eksisterer ennå).

DIGITAL PROTOTYPING

211

7. Gjenta trinn 1 for wireframe-innholdet i søkeresultatene. Lagre denne siden som et GIF-bilde, navngi den searchresults.gif, og lagre den i Prototype-mappen. Lagre en ny kopi av det gjeldende homepage.html-dokumentet som searchresults.html. Velg «Lagre som» for gjeldende «homepage.html»-side, og lagre den i stedet som «searchreseults.html». Oppdater deretter HTML-koden for å vise den og lenke tilbake til hjemmesiden (homepage.html). Du må erstatte denne kodelinjen: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

Med denne: 1V]gZ[2]dbZeV\Z#]iba31^b\hgX2hZVgX]gZhjaih#\^[WdgYZg2%31$V3

8. Når denne siden er opprettet, vil du ha en helt grunnleggende HTML-prototype som viser hvordan to sider kan lenke frem og tilbake til hverandre.

Figur 12.4 HTML-prototype av hjemmesiden, sett i en nettleser

212

KAPITTEL 12: PROTOTYPING

Bryte ned koden Nå som du har laget en grunnleggende prototype med en svært begrenset mengde HTML, la oss kort gå gjennom koden eller HTML-taggene du brukte, slik at du kan få en bedre forståelse av det du nettopp gjorde. HTML-, head- og titteltaggene 1]iba3 1]ZVY3

1i^iaZ36Wdji1$i^iaZ3

1$]ZVY3

er grunnleggende koder som kreves i ethvert HTML-dokument. Det viktige elementet å merke seg her er tittelkoden, som lar deg spesifisere navnet på siden. En bildekode 1^b\hgX2]dbZeV\Z#\^[3

er også en enkel tag; det er alt du trenger for å se et bilde i en nettleser. Ankertagger, som denne, 1V]gZ[2hZVgX]gZhjaih#]iba31$V3

brukes til å sette opp lenker i HTML-dokumentet ditt. For enkelhets skyld bruker eksemplets ankertag en relativ bane - "relativ" fordi opplæringsprosjektet er i samme mappe. En absolutt bane ser slik ut: 1V]gZ[2]iie/$$lll#jhZg\ajZ#Xdb$XdciVXi#e]e31$V3

Selv om denne HTML-koden ikke er stilisert eller standardkompatibel (ikke vis dette til en utvikler – han kan bli bedt om å gi deg en hard leksjon i kodeutviklingspraksis!), er det mer enn nok til å få prototypen din til å fungere i en nettleser. Husk at denne prototypen ikke trenger å være perfekt: Målet er ganske enkelt å kommunisere ideene dine til publikum. Dette enkle markeringseksemplet skapte koblede HTML-filer som gir mulighet for side-til-side-klikk, men hva om du ønsker å bli mer detaljert med de klikkbare områdene i oppsettet? Svaret: bildekart. Med bildekart kan du angi områder av et bilde som skal kobles til og vise forskjellige sider når du klikker på det. Den enkleste måten å lage bildekart på er å bruke et WYSIWYG-verktøy som Dreamweaver for å tilordne deler av et bilde som kan kobles til, uten noen reell kunnskap om hvordan man lager HTML-koden. For mer informasjon om hvordan du lager bildekart, se "Hvordan lager jeg et bildekart for

DIGITAL PROTOTYPING

213

min webside»-veiledning av Dave Taylor på: www.askdavetaylor.com/ how_do_i_create_an_image_map_for_my_web_page.html. HTML-prototyper er bare én tilnærming til digital prototyping. Mange forskjellige rammeverk og dynamiske kodespråk kan brukes til å lage svært robuste prototyper for å dekke nesten alle behov. Hvis HTML-prototyping er et område du ønsker å utforske og utvide, kan det være lurt å oppsøke opplæringsprogrammer og andre ressurser for mer dypdykk i det området. For å komme i gang kan det være lurt å undersøke JavaScript, PHP (eller andre dynamiske kodespråk), jQuery (http://jquery.com) eller Yahoo! Grensesnittbibliotek (http://utvikler .yahoo.com/yu). Merk For en dypere utforskning av HTML, se HTML Dog: The Best-Practice Guide to XHTML and CSS, av Patrick Griffiths (New Riders, 2006).

Ytterligere verktøy for prototyping Du har nå utforsket praktiske alternativer som kan hjelpe deg med å lage prototyper i både analoge og digitale rom. I tillegg til disse metodene finnes det en rekke andre programvareverktøy som du kan bruke til å lage prototyper som spenner fra det grunnleggende "å få jobben gjort" til de som er mer robuste og fylt med interaksjon og intelligens. Følgende liste er langt fra inkluderende, men den vil gi deg en rekke alternativer for å lage den riktige prototypen for din situasjon. PowerPoint og Keynote En PowerPoint- eller Keynote-prototype faller inn i kategorien raskt og skittent, og noen ganger er det alt du trenger. Du kan bygge PowerPoint- eller Keynote-prototypen din som om du skulle bygge en grunnleggende lysbildefremvisning, med enkle interaksjoner. Begge verktøyene lar deg lage interaksjoner for å simulere gjennomklikk av en flyt som du ønsker å validere med brukerne dine. Hvis du er en PowerPoint- eller Keynote-“power-bruker”, kan du bygge inn animasjon og andre elementer for å gjøre prototypen din litt mer interaktiv. Adobe Acrobat PDF-er Å eksportere wireframes eller visuelle designsammensetninger som en flersidet PDF kan være alt du trenger for å vise hvordan produktet kan se ut og hvordan det kan navigere i et lineært side-til-side-format. Husk at mange applikasjoner 214

KAPITTEL 12: PROTOTYPING

eksporter til PDF, og hvis du er på en Mac, kan du velge Skriv ut til PDF for stort sett alle dokumenter eller ﬁler i et hvilket som helst program som tillater en utskriftsfunksjon. Mange applikasjoner, inkludert Visio og OmniGraffle, lar deg spesifisere hot spots og handlinger, for eksempel koblingsplassering, for interaktivitet. Visio og OmniGraffle Både Microsoft Visio og Omni Groups OmniGraffle er velkjente verktøy for å lage wireframes. Begge lar deg lage klikkprototyper via deres evne til å eksportere til HTML- og PDF-formater. I OmniGraffle kan du enkelt tilordne handlinger og spesifisere et hopp-til-punkt i en PDF eller til en URL, hvis du eksporterer som HTML. Visio har prototyping-sett tilgjengelig for nedlasting på nettet som muliggjør enkel eksport til HTML eller PDF med klikkbare områder, for side-til-side-navigering. Visio og OmniGraffle kan også eksportere populære vektor- og rasterformater, som EPS, GIF og JPEG, som lar deg enkelt importere bildene dine til Flash, bruke dem som bilder for HTML-prototyper, og så videre. Axure RP "RP" i Axure RP står for rapid prototyping, som er det som gjør verktøyet populært blant mange designere av brukeropplevelse. Verktøyet tilbyr tegnefunksjoner som ligner på de i Visio og OmniGraffle, men det legger til et sett med verktøy som er relativt enkelt å lære som lar deg lage en rekke navigasjonsstiler, skjemaer, popup-vinduer og annen typisk sidebasert interaktivitet . I tillegg gjør dens ﬂeksible integrasjon av spesifikasjoner, kommentarer, oppgaver og fremdriftsmarkører deg i stand til å produsere dokumentbaserte spesifikasjoner direkte fra prototypen. Axure er imidlertid et Windows-verktøy, noe som kan være en utfordring hvis du jobber med en Mac og ikke bruker noen applikasjoner som lar deg starte Windows. Fireworks CS4 Adobes Fireworks CS4 har nylig blitt mer populært som et verktøy for å lage en rekke designkomponenter fra wireframes til visuelle design. Den har et standardsett med Windows- og Mac-skjemaelementer og kontroller som muliggjør lett definerte interaksjoner som kan fremheve funksjonalitet uten å kreve en ekstern utvikler. Fellesbiblioteket lagrer elementer som kan legges til og deles på tvers av flere dokumenter, slik at du kan gjenbruke

DIGITAL PROTOTYPING

215

komponenter. Fireworks har også en Pages-funksjon som lar deg lage sett med elementer som er felles for alle sider i et spesifikt dokument – på samme måte som utviklere bruker «inkluderer» eller hvordan noen dokumentasjonssystemer lar deg lage bakgrunner for gjenbruk på dokumentsider. Denne funksjonen er nyttig for å identifisere repeterbare innholdsområder på sidenivå som topptekst, bunntekst og navigasjon, samtidig som den opprettholder unike innholdsområder på hver side. Balsamiq Mockups Balsamiq Studios’ Mockups er et wireframing- og prototypingverktøy som gir en opplevelse som ligner på å skissere wireframes med blyant og papir – bare du bruker en datamaskin. En rekke forhåndsdesignede vanlige brukergrensesnittkontroller er tilgjengelige (over 60 i skrivende stund) som du kan dra og slippe til en skjerm og tilpasse for prosjektet ditt. Mockupene dine er stylet som om de var håndtegnet, noe som gir en litt mer organisk følelse til de digitalt lagde skjermene, men den digitale plattformen lar deg raskt endre designene for raske gjentakelser. Flash og Flash Catalyst Prototyping med Adobe Flash er en flott måte å kommunisere interaktive konsepter på utover bare en grunnleggende klikkprototype. Flash lar deg enkelt bygge gjennomklikk-prototyper, men det lar deg også legge til andre elementer av interaktivitet, inkludert museover- eller svevehendelser, klikkhendelser, video og animasjon. Hvis du har muligheten til å utforske Flash mer detaljert, har den også et kjernesett med brukergrensesnittkomponenter som kan programmeres til å svare på brukerinteraksjoner og vise et ønsket resultat. For en primer om prototyping i Flash, søk Alexa Andrzejeskis artikkel "Quick and Easy Flash Prototypes" på Boxes and Arrows: www.boxesand arrows.com/view/quick-and-easy-flash. Da denne boken skulle trykkes, annonserte Adobe et nytt prototypverktøy kalt Flash Catalyst. Flash Catalyst er et utviklingsmiljø som fungerer sammen med de andre Adobe CS4 suite-applikasjonene for å fungere som en kanal mellom design og utviklingsprosessen. Dette lar deg eksportere designene dine til nettleserklart format med liten innsats. For mer informasjon, besøk www. adobe.com.

216

KAPITTEL 12: PROTOTYPING

Arbeide med en utvikler Hvis du har ressursene tilgjengelig for deg, kan det være lurt å engasjere en utvikler for å lage en prototype for deg basert på wireframes eller design. Merk at utvikleren må ha en solid forståelse av hva du prøver å oppnå, så denne tilnærmingen kan kreve at du også oppretter utviklingsspesifikasjoner og krav for at prosessen skal være effektiv. Hvis prototypen din brukes til iterativ testing, sørg for at du kommuniserer hvilke deler av prototypen du fokuserer på for testing og vil derfor kreve at endringer implementeres raskt. Det er tilrådelig å bruke tid med utvikleren under utviklingsprosessen og identifisere nøkkelområder i koden som bør flagges (med kommentarer i koden) som mottakelige for endringer. Sørg for å forbli engasjert med utvikleren din under prototypeutviklingen for å holde kommunikasjonslinjene åpne og sikre nøyaktigheten av utdataene. Merk For mer detaljer om en rekke prototyping-tilnærminger, se den kommende boken, A Practitioner’s Guide to Prototyping, av Todd Zaki Warfel (Rosenfeld Media, som skal publiseres i 2009: www.rosenfeldmedia.com/books/prototyping).

Prototypeeksempler De enkle, enkle å utføre eksemplene på prototyping i dette kapittelet er langt fra et komplett sett med tilnærminger som du bør bruke for enhver situasjon. For å fremheve noen virkelige bruksområder for prototyping, delte Keith Tatum og Jon Hadden sjenerøst fra sine erfaringer. Keith Tatum, senior brukeropplevelsesstrateg hos Slingthought (www .slingthought.com), laget papirprototypen i figur 12.5 for å forklare navigasjonslenkene til venstre og identifisere navigasjonshierarkiene og kategoriseringene til samarbeidspartnerne hans på Align Interactive (www .aligninteractive). .com). I tillegg tillot papirprototypeprosessen ham å omgå wireframe-fasen og gå over til visuell design og layout (Figur 12.6).

PROTOTYPE EKSEMPLER

217

Figur 12.5 Papirprototype som brukes til å forklare navigasjonskonsepter til utviklingsteamet

Figur 12.6 Live-nettsteddesign basert på papirprototype

Keith utnyttet teamets felles forståelse av design- og utviklingsoppgavene til raskt å lage et design innen to arbeidsdager. Dette tillot teamet å fortsette utviklingen raskt etter godkjenning av det visuelle designkonseptet.

Figur 12.7 Funksjonell prototype av et kalenderverktøy, etterlignet ved hjelp av XHTML, CSS og JavaScript med høy ﬁdelity; med tillatelse av Jon Hadden

218

KAPITTEL 12: PROTOTYPING

Jon Hadden (www.jonhadden.com), en senior visuell designer hos Yahoo, laget en prototype av kalenderfunksjonaliteten for et verktøy han bygger kalt Project Manager. Project Manager er en samarbeidende, nettbasert applikasjon for å administrere prosjekter. Den begynte som OmniGraffle wireframes og ble deretter bygget som en XHTML-prototype med høy ﬁdelity for å hjelpe med å avgjøre om funksjonaliteten var både brukbar og rimelig. Rimelighet er et viktig poeng: I noen tilfeller kan deler av en applikasjon eller et prosjekt settes på prototypetesting for å se om funksjonaliteten er kostnadseffektiv. Hvis kostnadene ved å lage funksjonalitet blir et problem og prototypeutviklingen overgår forventningene til tid og materialer, må du kanskje vurdere levedyktigheten til prosjektet ditt.

Hva skjer etter prototyping? Når du har fullført prototypeprosessen, må du syntetisere resultatene dine og gjøre dem om til noe handlingskraftig. Hvis du var papirprototyping, må du kanskje begynne å lage digitale wireframes basert på tilbakemeldingene du mottok. Hvis du allerede er i en digital wireframe-modus, må du kanskje oppdatere wireframes og fortsette gjennom prosjektprosessen. Eller du må kanskje ta tilbakemeldingen din og oppdatere prototypen din for en ny runde med anmeldelser. Todd Zaki Warfel, president for Messageﬁrst (www.messageﬁrst.com), delte følgende: Prototyper er en måte å oppnå ett eller flere av følgende mål på: Arbeid deg gjennom et design Lag en felles kommunikasjonsplattform Selg designideene dine internt ( for eksempel til sjefen din, andre designere osv.) Test teknisk gjennomførbarhet Test designkonsepter med sluttbrukere/kunder Prototyping fungerer som en tilbakemeldingsmekanisme. Gjennom prototyping kan du bestemme om du vil fortsette med en bestemt designretning eller utforske en annen, før du går videre til de neste fasene av prosjektet.

Husk: Uansett hvor du er i prosessen, er prototyping bare en del av prosessen, og som med alle andre deler, må du være klar over når du har nådd punktet for maksimal effektivitet og er klar til å gå videre til neste trinn i brukeropplevelsesprosessen. HVA SKJER ETTER PROTOTYPING?

219

1. 3

Designtesting med brukere Bryt deg bort fra det du tror du vet – og finn ut hvordan de tenker I kapittel 6 dekket vi flere UX-designteknikker som kan hjelpe deg å forstå brukergruppene dine – deres behov, holdninger og preferanser når de er relatert til det generelle emnet representert av nettstedet ditt. Dette kapittelet diskuterer teknikker som vil hjelpe deg å samle brukerinformasjon om bestemte design eller elementer i design. Vi vil fokusere på utforskende teknikker som ofte brukes tidlig i designfasen og på brukervennlighetstesting, som kan brukes på mange punkter i prosjektet ditt. La oss først snakke om å utforske designkonsepter med brukerne dine. Carolyn Chandler

Konseptutforskning Konsept er generelt ordet som brukes for å beskrive en abstrakt idé, som lykke, samarbeid eller effektivitet. Innenfor UX-design brukes konsept også for å referere til designelementer som er ment å representere en eller flere abstrakte ideer for prosjektteamet eller en potensiell bruker. I denne betydningen av ordet kan et konseptuelt designelement være visuelt (for eksempel et bilde av en maskin for å representere konseptet effektivitet) eller det kan være tekstbasert (for eksempel en kort samling setninger skrevet for å uttrykke en selskapets fokus på effektivitet, ved å bruke ord som tidsriktig og responsiv). Konsept kan også bety utforskning av wireframes, visuelle designmodeller eller grove prototyper som er ment å uttrykke de generelle budskapene på nettstedet (se kapittel 12 for mer om prototyping). Konseptutforskning skjer vanligvis tidlig i designprosessen, etter at du har definert brukergruppene dine, men før du har kommet inn i detaljene på hver side eller skjerm. Forskningen kan gi inspirasjon for designere og redusere noe av risikoen for å bringe et nytt produkt til markedet, fordi du vil kunne høre (og deretter planlegge for) hva slags reaksjoner du kan få fra potensielle brukere.

Hovedformålet med konseptutforskning er å forstå hva slags svar og ideer som fremkalles fra brukergruppene dine når de står overfor et sett med designelementer.

Konseptutforskning kan bestå av en-til-en-diskusjoner eller kan foregå i en gruppe, men inkluderer noen individuelle aktiviteter rettet mot å samle og diskutere en rekke synspunkter. Sistnevnte kan settes opp som en fokusgruppe, med en del av tiden dedikert til konsepttesting, etterfulgt av en gruppediskusjon (se kapittel 6 for mer om fokusgrupper). La oss se på et eksempel på konseptutforskning som ble utført for en ideell mikrofinansorganisasjon.

KONSEPTUTLETNING

221

Potensielle fallgruver ved konseptutforskning Henry Ford sa en gang: "Hvis jeg spurte kundene mine hva de ville ha, ville de ha bedt om en raskere hest." Selv om du kan få noen gode ideer ut av å utforske konsepter med potensielle brukere, ønsker du ikke å stole på at de står for designere. Tross alt er de mest minneverdige designene ofte svært forskjellige fra det som har gått før, og forskningsdeltakere er kanskje ikke komfortable med en stor grad av endring. Deltakernes svar vil være forankret i deres nåværende forståelse. Det du samler inn er reaksjoner, ikke spådommer om hva de vil eller ikke vil ha i fremtiden. Husk også at mange andre faktorer utenfor selve designet vil påvirke fremtidig atferd (som f.eks. positiv jungeltelegrafen). Unngå å be deltakerne ta direkte valg (som "Hvilket konsept er bedre, A eller B?"); i stedet lytte til hvordan de bruker sine egne ord for å beskrive konseptene som presenteres. Resultatene bør betraktes som input til designprosessen, ikke et mandat til designere. For en utmerket oversikt over de potensielle fallgruvene ved å teste designkonsepter og for anbefalinger om hvordan du bruker teknikken godt, ta en titt på denne artikkelen på AIGAs nettsted: "Design Meets Research," av Debbie Millman og Mike Bainbridge: http: //www.aiga.org/content.cfm/design-meets-research

Mikrofinans er finansieringen av svært små lån til gründere i fattige land. Disse lånene kan tillate låntakerne å bygge virksomheter og som et resultat forbedre livene til familiene og lokalsamfunnene deres. Lånemidlene kommer fra enkeltpersoner som går sammen for å låne ut eller donere små beløp for å utgjøre et større lån (for eksempel $25 hver for å finansiere et lån på $800 som en butikkeier i Kenya trenger). Entreprenørene betaler tilbake lånet etter hvert som virksomheten vokser. Finansieringsmodellen er veldig kraftig, men organisasjonen opplevde det noen ganger som utfordrende å forklare konseptet på en enkel måte. I tillegg til å ha utfordringen med å beskrive mikroﬁnans, var organisasjonen også usikker på hvordan de skulle håndtere budskap og design med tanke på religion. Denne spesielle mikrofinansorganisasjonen var inspirert av troen til grunnleggerne og ansatte. Mange i organisasjonen ønsket å lage

222

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Denne inspirasjonen var tydelig i utformingen av nettstedet, men de var usikre på hvordan de skulle finne den rette balansen: Hvis presentasjonen av religiøse budskap var for sterk, kunne det fremmedgjort potensielle givere som ikke var medlemmer av den troen. For subtil, og organisasjonen ville ikke virkelig representere sine verdier. UX-designerne på prosjektet bestemte seg for å utforske de mulige måtene bilder og tekst kan brukes til å både forklare mikrofinansmodellen og representere organisasjonens religiøse inspirasjon uten å fremmedgjøre potensielle givere. For å gjøre dette, valgte de bilder og ord som kunne brukes til å forklare konsepter knyttet til modellen (som selvhjulpenhet og investering), og andre som representerte ulike grader av religiøse budskap (for eksempel tro og spiritualitet). Fokusgrupper ble deretter planlagt med deltakere som falt inn i sidens målbrukergrupper. To brukergrupper ble inkludert: de som oppga at de donerer som et uttrykk for sin religiøse tro, og de som ikke gjorde det. For hver gruppe forklarte tilretteleggeren donasjonsmodellen (sa ingenting om religion). Deretter fikk hver deltaker et ark med plakat, et sett med bilder og et sett med ord som de kunne bruke, pluss flere tomme kort for å fylle ut sine egne ord hvis de ville. De ble bedt om å lage en collage som viste bildene og ordene de ville bruke for å forklare modellen til venner og familie. Da de var ferdige, kom deltakerne sammen igjen for å presentere collagene sine, og forklarte hvorfor de valgte bestemte bilder og tekst og hvorfor de valgte å ikke inkludere andre. Figur 13.1 viser et eksempel på en collage laget i denne øvelsen. Figur 13.1 Et eksempel på en collage laget av en deltaker under konsepttesting

Prosjektteamet fikk verdifull innsikt fra disse collagene og diskusjonen som fulgte. Innsikt inkluderte deltakere som vek unna bilder som representerte suksess i «Vest-

ern»-begreper (for eksempel forretningsdresser og kofferter). De ønsket å forbedre livene til gründere uten å endre kulturen deres.

KONSEPTUTLETNING

223

Alle brukergruppene var enige om at sidens fokus skulle være på målet

av organisasjonen (å gi gründere midler til å vokse og blomstre) i stedet for motivasjonen bak (religiøs inspirasjon). Deltakerne mente det var viktig at organisasjonen forblir tro mot hvem de var, men at disse meldingene kunne gis i et område som var avsatt for å beskrive selve organisasjonen (for eksempel et Om oss-område). Holdningene og interessene som dukket opp, hjalp teamet med å bestemme en retning for meldinger på nettstedet – og ga et godt eksempel på verdien av konsepttesting!

Tips om å utforske mock-ups for visuell design På et tidspunkt i prosjektet kan du ha modeller som representerer den potensielle utformingen av sidene på nettstedet. Hvis du bestemmer deg for å utforske design sammen med deltakerne, er det best å ha to eller flere varianter tilgjengelig slik at de kan sammenligne og kontrastere. Med bare én, er det mer sannsynlig at du får den "fine" skjevheten: folk vil ikke høres altfor kritiske ut til modellen fordi de ikke vil såre designerens følelser. Men med to eller flere modeller, vil de generelt føle seg mer komfortable med å være kritiske fordi de er mer fokusert på å sammenligne design enn å kritisere dem direkte. Du kan gi deltakerne hvert design separat (enten på en skjerm eller som papirutskrift) og stille et sett med spørsmål. Du kan for eksempel be deltakerne om å se på hvert design i et minutt og deretter velge minst tre termer fra en liste som best beskriver designet. De kunne sirkle inn valgene sine på et ark med 20 ord som kjedelig, trendy, konservativ, høyt, trygt og så videre i tilfeldig rekkefølge. Svar på åpne spørsmål kan også samles inn. Du kan for eksempel gi deltakerne fem tomme linjer for å skrive ned deres generelle inntrykk av designet. Noe av informasjonen du kan samle inn inkluderer vanlige merkeassosiasjoner laget av deltakerne:

"Pseudo Corporation er Rolls Royce av widget-produsenter: Det ser bra ut, men du har sannsynligvis ikke råd til det."

224

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Design og livsstilstilpasning:

"Jeg tror ikke jeg ville la sønnen min gå til denne siden. Han er bare 8 år, og disse bildene ser for voksne ut for ham.» Effektiviteten til en bestemt mock-up for å forklare et nytt konsept:

"Å, jeg skjønner det - denne siden er som et bryllupsregister, men du registrerer deg for donasjoner til veldedighet i stedet for servise." Måter deltakerne definerer noen av nøkkelbegrepene du bruker på:

"Når jeg ser ordet løsning på denne siden, får det meg til å tro at jeg kommer til å finne alle produktene og tjenestene jeg trenger for å spore forsendelsene mine." Spørsmål eller bekymringer om hvordan et bestemt sett med verktøy vil bli brukt

eller virkningen av å introdusere dem (den følgende delen illustrerer flere eksempler på deltakernes bekymringer). Designere kan bruke disse svarene til å vurdere om reaksjonene de får er på linje med det de hadde til hensikt, eller om de kanskje må prøve en annen tilnærming. Husk at deltakere (og prosjektinteressenter, for den saks skyld) ofte velger forskjellige elementer fra forskjellige design: "Jeg liker denne delen av konsept A, og jeg liker denne delen av konsept B." Dette er en naturlig reaksjon, men den bør ikke tas for bokstavelig. Du vil ikke ha en unaturlig blanding av to forskjellige designretninger. Hvis den visuelle designeren føler at de populære elementene passer godt sammen, så gå for det. Men gi rom for henne til å fortelle deg at det er mindre "sjokolade-og-peanøttsmør" enn "sjokolade-og-pickle." Totalt sett er det ingen harde og raske regler for aktivitetene som inngår i konsepttester eller hvilke typer elementer du kan teste. Nøkkelen er heller å sørge for at du setter de riktige forventningene med prosjektteamet om hva slags informasjon som vil komme ut av testene og hvordan denne informasjonen vil bli brukt til å informere designbeslutninger uten å kvele kreativiteten.

Brukervennlighetstesting Brukervennlighetstesting er en av de mest brukte testmetodene for UX-design. Det er også den mest kjente blant de som ikke er UX-designere selv, så bedriftens interessenter og prosjektteam er kanskje allerede kjent med det. Selve konseptet er elegant enkelt: lag et prioritert sett

BRUKERHETSTEST

225

av oppgaver for nettstedet ditt, be noen brukere om å utføre dem, og noter hvor de har problemer og suksesser.

Brukervennlighetstesting vs. brukeraksepttesting Noen personer i organisasjonen din kan ha misforståelsen om at brukervennlighetstesting bare skjer nær slutten av utviklingen eller begynnelsen av distribusjonen, når det er en fungerende versjon av nettstedet eller applikasjonen – kanskje noe i betamodus. Dette inntrykket kan også ha sammenheng med den vanlige praksisen med å gjennomføre brukeraksepttesting (UAT) på dette senere tidspunktet. Likheten mellom navnene kan føre til at de to blir forvirret. For applikasjoner som går gjennom en formell QA-prosess, er UAT en av de senere stadiene av testing, og utføres sjelden av faktiske brukere. Hovedformålet med UAT er ofte å tjene som en sluttsjekk av om applikasjonen har oppfylt funksjonskravene som er satt av interessenter; den kan også fange opp eventuelle feil eller feil som deltakerne rapporterer. Selv om UAT kan bringe ut brukervennlighetsproblemer, bør det ikke stoles på som den eneste metoden for å fange dem på et prosjekt. Fordi det skjer så sent i prosessen, er endringer basert på tilbakemeldinger fra UAT mye mer kostbare. Det er langt bedre å fange opp store problemer tidligere i prosessen, før det brukes mye tid på utvikling. Brukervennlighetstesting er designet for å gi mer realistisk ytelsesinformasjon tidligere i prosessen.

De følgende avsnittene diskuterer vanlige trinn involvert i brukervennlighetstesting, for eksempel Velge en tilnærming Planlegging av forskningen Rekruttering og logistikk Skrive diskusjonsguider Tilrettelegge Analysere og presentere resultater Lage anbefalinger

226

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Før du begynner, vurder prosjektmålene dine. De vil hjelpe deg å holde fokus hele veien, men vil være spesielt nyttige i de tidlige stadiene når du velger en tilnærming og planlegger testen.

Velge en tilnærming Forskningstilnærminger beskrives ofte som enten kvantitative eller kvalitative. Kvantitativ forskning er fokusert på numeriske data og er ment å gi pålitelige, repeterbare resultater blant målgruppen din. Den er avhengig av din inkludering av et stort nok sett med brukere i den gruppen (kalt prøvestørrelsen) til at du kan ta funn fra det mindre settet og trekke slutninger om måten brukergruppen som helhet vil svare på, innenfor et visst område av feil. Totalt sett er det en mer vitenskapelig tilnærming til forskning, med en formalitet for testdesign og analyse. Fokuset er på å vurdere den nåværende designen - spesielt mot andre gjentakelser av nettstedet, mot konkurrenter eller mot et sett med benchmarks. Å utføre kvantitativ forskning betyr å involvere et høyere antall deltakere for å ta hensyn til variasjoner du vil finne fra individ til individ, som hastighet på å skrive, kjennskap til lignende nettsteder og så videre. Undersøkelser er et eksempel på en metode for informasjonsinnhenting som kan utvides til et større publikum, noe som resulterer i kvantitative data – hvis du stiller de riktige spørsmålene, det vil si (se kapittel 6 for mer om undersøkelser). Kvalitativ forskning er derimot ikke like fokusert på konﬁdensnivåer og repeterbarhet, men snarere på å få kontekst og innsikt angående brukeratferd. Den er avhengig av designerens tolkning av funn, intuisjon og sunn fornuft. (Kontekstuell undersøkelse, diskutert i kapittel 6, er et eksempel på kvalitativ forskning.) En kvalitativ tilnærming tillater en åpenhet for testingen som bidrar til å utforske ideer og få innsikt; diskusjonen med brukeren er like viktig som ytelsen hennes, om ikke mer. Fokuset er på å forbedre dagens design – å få innsikt og reaksjoner på det som presenteres for å generere ideer. Så er brukstesting en kvantitativ metode eller en kvalitativ metode? Det er en av de lengste diskusjonene innen UX-design. Begge tilnærmingene er mulige og kan gi nyttige resultater. Tilhengere av en mer kvantitativ tilnærming sier:

BRUKERHETSTEST

227

Det gir mulighet for innstilling av målbare standarder som kan testes mot

i senere iterasjoner, viser fremgang mot et mål (for eksempel redusere tiden det tar å sjekke ut med 20 prosent eller fange opp 80 prosent av brukervennlighetsproblemene på et nettsted). Dette gjør det også til en god tilnærming når du ønsker å utføre en formell sammenligning av to nettsteder eller evaluere et bestemt nettsted. Det gir resultater som kan valideres statistisk, som kan være viktige

tant når anbefalinger må forsvares overfor interessenter som stoler på datadrevne beslutninger. Det reduserer sannsynligheten for at en individuell UX-designers skjevhet påvirker

resultatene. Det gir en høyere grad av tillit til at de oppnådde resultatene vil være

reflektert av resultater blant hele brukerbasen. Den tilbyr en klar, numerisk metode for å validere et funn (f.eks.

hvor mange brukere som har opplevd det samme problemet). Tilhengere av kvalitativ brukervennlighetstesting sier: Kvalitativ forskning bygger opp erfaring og empati hos designeren,

fremme kreative løsninger med fokus på brukeren. Det er sterkt avhengig av UX-designerens intuisjon for å gi rimelige anbefalinger.

mendations, som er en stor del av hvorfor hun er med på laget. Spesielt for brukervennlighetstesting er en kvalitativ tilnærming ofte mindre

kostbart enn kvantitativt, både fordi det kreves færre brukere og fordi kvalitativ forskning ikke krever kunnskap om formell vitenskapelig design og analyse (som statistikk). Det er veldig enkelt å analysere resultatene av kvantitative studier feil, løgnaktig

(men utilsiktet) med data, så en kvantitativ tilnærming kan faktisk introdusere mer risiko enn en kvalitativ test hvis den ikke kjøres riktig. Selv om funnene ikke er validert numerisk, kan de valideres av

en designer, som vil ringe om problemets sannsynlige innvirkning ved å bruke sin informerte begrunnelse og bygge saken med brukerhistorier. Kvalitativ brukervennlighetstesting er den mer tilgjengelige tilnærmingen for de som ikke har fått opplæring i formelle vitenskapelige metoder og gir en rik kilde til data for å informere design. Av disse grunnene vil vi fokusere på utformingen av kvalitativ testing i resten av dette kapittelet.

228

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Hvor mange brukere er "nok"? Spør "Hvor mange brukere er nok?" i en gruppe UX-designere er som å ta opp religion på et politisk møte – det er et tema for het debatt. Det er også et spørsmål som ikke kan unngås, fordi du trenger et rammeverk å starte fra for å planlegge forskningen din. Det er knyttet til tilnærmingen du bruker: kvantitativ eller kvalitativ. For å gi det korte svaret, her er retningslinjene som ser ut til å ha fått mest konsensus i UX-feltet, gitt av Jakob Nielsen: For en kvantitativ test, planlegg for et høyere antall deltakere: 20 deltakere per forskningsrunde (se http ://www.useit.com/alertbox/quantitative_testing.html). For en kvalitativ test er det vanligvis tilstrekkelig med fem til åtte brukere per gruppe for hver forskningsrunde. Ideelt sett utføres mer enn én runde med forskning for å avdekke problemer som kan ha "gjemt seg" under andre problemer eller utilsiktet introdusert i det nye designet (se http://www.useit.com/alertbox/20000319.html).

Planlegging av forskningen Når du utformer en brukervennlighetstest, er det noen spørsmål du bør svare på tidlig for å gi fokus og omfang. Dette kan leveres som et dokument skrevet for og diskutert med prosjektgruppen og sentrale interessenter, ofte kalt en brukerforskningsplan. Planen bør skissere din tilnærming som valgt ovenfor. Hvorfor tester du? Skriv en klar uttalelse som skisserer målene for testen, basert på ett eller flere av målene for det overordnede prosjektet. Se kapittel 2 for eksempler på designmål og hvordan de varierer basert på prosjekttype. Hvem tester du? Når du har laget brukermodellen din (se kapittel 6 og 7) kan du bruke den som grunnlag for dine beslutninger om hvilke brukere du skal teste. Hvis du ikke allerede har gjort det, møt prosjektteamet og relevante interessenter for å prioritere brukergruppene. Denne informasjonen vil føres inn i screeneren din (diskutert under "Rekruttering og logistikk"). BRUKERHETSTEST

229

Dette punktet er også der du bør velge brukergruppene som skal representeres og antall brukere som skal inkluderes i hver gruppe. Hva tester du? Spørsmålet om hva du tester inkluderer to sammenhengende spørsmål: Hvilken metode vil du bruke for å representere nettstedet eller applikasjonen? og Hvilke oppgaver planlegger du å inkludere? Hvis du har en eksisterende applikasjon for redesign, kan du velge å kjøre hele testen på den gjeldende versjonen først for å finne store brukervennlighetsproblemer å løse. Hvis du jobber med et nytt design, kan du bruke skisser eller papirprototyper (for eksempel en pakke med trykte wireframes) for å representere nye grensesnittelementer som sider. Disse lavfidelitetsrepresentasjonene av brukergrensesnittet lar deg raskt generere og diskutere ideer blant prosjektteamet, og gjenta dem raskt med deltakerne (se kapittel 10 og 11 for mer om skisser og wireframing). Når du jobber med et nytt design som inkluderer svært interaktive elementer, kan det være bedre å lage en prototype som simulerer navigasjonsflyten til designet på en realistisk måte, men som fortsatt kan lages raskt før fullskala utvikling starter (se kapittel 12 for mer om prototyping). Sidene du inkluderer vil være nært knyttet til oppgavene du velger. Hvis du planlegger å bruke prototyper for å teste med brukere, må du planlegge for oppgavens hovedsider samt mellomsider og alternative stier. Du trenger kanskje ikke å detaljere hver enkelt, men du må planlegge for et svar hvis en bruker går i den retningen. Noen ganger kan dette være så enkelt som en side som sier at en bestemt bane ikke er tilgjengelig og ber brukeren gå tilbake til forrige side for å prøve på nytt. Spesifikasjonene for oppgavene dine vil gå inn i diskusjonsguiden (diskutert nedenfor), men fordi omfanget kan variere mye avhengig av typen oppgaver du inkluderer, er det nyttig å ha listen skissert under planleggingen.

230

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Deep Diving For mer om iterativ design og testing med skisser, samt virkelig inspirerende innsikt i kreativitet i designprosessen, les Sketching User Experiences: Getting the Design Right and the Right Design, av Bill Buxton (Morgan Kaufmann, 2007). For mer om teknikker innen papirprototyping, sjekk ut Paper Prototyping: The Fast and Easy Way to Design and Reﬁne User Interfaces, av Carolyn Snyder (Morgan Kaufmann, 2003).

Hvis listen er for lang og du ikke er sikker på hvordan du skal prioritere, er her noen mulige prioriteringer du bør vurdere: Områder der designet bryter noen etablerte konvensjoner. Er du

kaller det en "godtpose" i stedet for en "handlevogn"? Det er sannsynligvis en god idé å se om det er tydelig for brukerne dine. Områder der designbeslutninger er politisk ladet. Du kan ha en

sterk følelse av at en bestemt designretning er den rette, men du vet at det er mange uenigheter mellom interessenter eller andre medlemmer av prosjektteamet. Å se er å tro. Områder hvor brukervennlighetsproblemer kan få kritiske konsekvenser, for eksempel tapt

salg eller i verste fall tapte liv (helsesøknader som involverer medisindosering er et godt eksempel på dette). Deretter bestemmer du informasjonen han vil samle mens en bruker prøver å utføre hver oppgave. Hvilken informasjon samler du inn? Vi fokuserer på kvalitative brukervennlighetstester, som har en tendens til å ha et mindre sett med målinger. For det meste ønsker du å forstå problemene brukere kan støte på, de ulike nivåene av frustrasjon de kan oppleve, og alvorlighetsgraden av et bestemt problem. For eksempel, kanskje det er et periodisk problem (ikke oppleves av alle brukere) som resulterer i uopprettelig tap av en postet historie. Det burde definitivt være et problem med stor bekymring i rapporten din!

BRUKERHETSTEST

231

For å få litt perspektiv på tvers av brukerne du tester, eller på tvers av testrunder, er det noen målinger du bør vurdere å samle inn som en del av testen. Igjen, hvis du gjennomfører en kvalitativ test med et mindre antall brukere, ikke ta disse tallene for langt (å beregne et gjennomsnittstall gir ikke mye mening hvis du bare tester fem brukere), men følgende tiltak kan hjelpe deg å forstå alvorlighetsgraden av noen av problemene brukerne støter på. Suksess – i hvilken grad en bruker var i stand til å fullføre en oppgave. Hvis du ser på tvers av brukere, kan du også referere til "suksessrate" - antallet brukere som klarer å fullføre oppgaven. Det høres enkelt ut, men dette betyr at du må definere betydningen av suksess! For mindre formelle tester kan du si at en oppgave er vellykket hvis brukeren oppnår slutttilstanden (for eksempel en redaktør godkjenner en historie). Du kan spore suksess mer formelt ved å legge merke til de ulike nivåene av intervensjon som trengs av tilretteleggeren: Nivå 1 Spørsmål: Testtilretteleggeren svarer på en deltakers spørsmål, men gir ingen ytterligere detaljer. For eksempel spør en deltaker: "Jeg tror det ville være denne knappen, skal jeg klikke på den?" og tilretteleggeren svarer: «Fortsett og prøv det.» En forespørsel på nivå 1 alene betyr ikke en mislykket oppgave, men det er godt å merke seg fordi deltakeren sannsynligvis opplever en viss usikkerhet på det tidspunktet. (Selv om dette er den første oppgaven, kan det også bare være at han ikke er kjent med brukervennlighetstester). Hvis en bruker ikke trenger noen forespørsler for å fullføre oppgaven, eller bare trenger én eller to nivå 1-oppfordringer, kan du vurdere det trinnet som en suksess – med mindre du føler at tiden det tok brukeren var langt over tålmodighetsnivået som er sannsynlig for din brukere. Nivå 2-spørsmål: Testtilretteleggeren ser at en deltaker sliter og gir et hint som svar på et spørsmål. Dette nivået inkluderer ikke å gi svaret direkte, men svaret kan påvirke brukerens tilnærming. For eksempel kan tilretteleggeren si: "Er det noe annet på denne siden som du tror kan relatere til denne oppgaven?" Her kan du sette en grense på hvor mange nivå 2-oppfordringer som kan gis før oppgaven merkes som mislykket (for eksempel ved den andre ledeteksten) eller som "vellykket med vanskeligheter."

232

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Nivå 3 Spørring: Deltakeren har gitt opp i frustrasjon eller har slitt til et punkt hvor han sannsynligvis ville gitt opp hvis han ble møtt med oppgaven i det virkelige liv. I dette tilfellet gir tilretteleggeren et direkte svar på en del av oppgaven – for eksempel ved å si: "For å godkjenne denne historien, klikker du på Send-knappen." Hvis en deltaker krever en nivå 3-forespørsel, merkes oppgaven vanligvis som mislykket. Brukertilfredshet – Jada, han fullførte oppgaven vellykket, men hvordan følte han det? Det kan være nyttig å inkludere noen oppfølgingsspørsmål etter hver oppgave (med timeren av) slik at du kan forstå hvor glade eller frustrerte brukerne dine er etterpå. Hvis du får noen som ikke liker å snakke, kan dette være hovedvinduet du vil ha inn i sjelen deres. Tabell 13.1 viser eksempler på noen av spørsmålene etter oppgaven du kan inkludere. TABELL 13.1: 13.1 BrukerTABELL

Tilfredshetsspørsmål ER STERKT UENIG

VÆRE UENIG

HVERKEN ENIG ELLER UENIG

BLI ENIGE

HELT ENIG

Oppgaven tok lengre tid å fullføre enn jeg forventet

Oppgaven var enkel å fullføre

Jeg følte meg frustrert da jeg prøvde å fullføre denne oppgaven

Spørsmål om brukertilfredshet Brukeruttalelser – Dette er ikke en beregning, men det brukerne melder seg på frivillig er et nøkkelsett med detaljer å samle inn. Å legge til brukersitater i en rapport er en effektiv måte å bringe det menneskelige elementet til resultatene, slik at interessenter ikke bare tolker data, men forstår oppfatninger som fører til innsikt. Under testen kan du bare merke utsagn som enten spørsmål eller kommentarer; vi deler disse ut i rapporten (se den senere delen "Generere innsikt").

Rekruttering og logistikk Nå som du har oversikten over forskningen og du vet hvor mange deltakere du trenger fra hver gruppe, er det på tide å få planlagt noen tester!

BRUKERHETSTEST

233

Generere en liste Når du opprettet forskningsplanen, skisserte du hvilke typer brukere du ønsket å inkludere. Du kan bruke den disposisjonen som et fokus for å generere en liste over potensielle deltakere. Ideelt sett ser du etter navn, e-postadresser og telefonnumre. Her er noen av kildene du kan hente fra for å samle denne listen: Registrerte brukere av et relatert firmanettsted Kundekontaktinformasjon Svar på innlegg om forskningen sendt til nettsteder eller grupper relevante

til ditt forskningstema. Dette kan være bredt, for eksempel innlegg til Craigslist, eller målrettet, for eksempel diskusjonsgrupper sentrert rundt bedriftens bransje. E-post til bekjente med tilknytning til emnet for testen.

Du vil be dem om å videresende invitasjonen til andre som kan være interessert, siden bruk av emner som du kjenner personlig kan påvirke resultatene. Denne typen jungeltelegrafen er en fin måte å finne lommer med potensielle deltakere på, men husk at disse kandidatene fortsatt må screenes. (Hvis du eller andre på laget kjenner folk godt, kan det være fristende å la dem slippe igjennom.) Forespørsler i form av korte spørreundersøkelser som prekvalifiserer deltakere, enten i

annonseplass på relevante nettsteder eller på bedriftens nettsted Oppslag eller prekvalifiseringsspørreskjemaer på offentlige steder der potensielle-

kan bli funnet. For nettsteder med en sterk tilknytning til et fysisk sted, kan du også gjøre mesteparten av screeningen og planleggingen på stedet. Tredjeparts rekrutteringsfirmaer, som også kan kjøre screeneren for deg

og hjelp til å planlegge. Dette kan være et dyrt alternativ, men hvis du leter etter en spesifikk deltakertype som er vanskelig å rekruttere eller du trenger å rekruttere mange mennesker, kan du spare mye tid ved å outsource denne delen av prosessen. Noen firmaer spesialiserer seg også på visse felt (som medisinsk) og kan gi deg tips om hvordan du kan oppmuntre til en høy deltakelsesrate.

234

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Vær forberedt på å bli kreativ her. Bruk dine empatiske ferdigheter til å tenke som målbrukerne – hvor kan du finne dem og hva kan motivere dem til å bli med? Dette siste spørsmålet leder oss til neste emne. Velge kompensasjon Hva vil motivere medlemmer av brukergruppen din til å delta i forskningen? Det kan være penger eller ikke, men deltakerne vil ha noe av verdi for tiden sin. Hvis du jobber med et nettsted for interne brukere, må du demonstrere denne verdien for lederne som må godkjenne bruken av selskapets tid for deltakelse i forskning. I dette tilfellet kan du fokusere på hvordan et bedre system direkte relaterer seg til fordeler for gruppen hans eller hennes. Hvis du jobber med potensielle eksterne brukere, her er noen variabler du bør huske på når du bestemmer hvordan du skal kompensere: Hvor generelt eller spesifikt er publikum? For en mye brukt e-handelsside er publikum sannsynligvis generelt, og du kan ofte tilby en lavere kompensasjonssats i form av en sjekk eller gavekort. For en søknad brukt av advokater, vil kompensasjonen din måtte ha høy verdi, og det er ofte bedre å bruke noe annet enn penger som kompensasjon (for eksempel tilgang til en premiumtjeneste). I disse tilfellene kan en sjekk faktisk virke som en fornærmelse - noen som fakturerer $250 i timen vil sannsynligvis ikke delta for penger. Hvis du jobber med kunder med store billetter, behandle dem som et spesifikt publikum og kompenser dem godt. Hvor stor interesse vil emnet sannsynligvis generere? Noen deltakere vil bli med fordi de vil se hva som kommer i området du tester. Hvis det er et område med høy interesse, trenger du kanskje ikke å gi mye ekstra kompensasjon i det hele tatt – belønningen er å ha tilgang til noe ingen andre kan se ennå. Men vær realistisk her: Du er kanskje så begeistret for temaet, men vil brukerne dine være det? Vil folk delta hovedsakelig fordi de ønsker å bidra med noe til saken? Noen grupper vil være motivert av altruistiske formål, og kan bli slått av ved tilbud om penger for å delta. Hvis du tester noe som forbedrer fellesskapet (online eller off) kan du få mer deltakelse – og gladere deltakere – hvis opplevelsen handler om å komme sammen heller

BRUKERHETSTEST

235

enn å få betalt. I dette tilfellet kan du vise din takknemlighet med offentlig anerkjennelse og ved å fortelle dem, når siden er fullført, bidraget de var i stand til å gi ved å delta. Hvor upraktisk vil deltakelse være? Hvis deltakerne trenger å reise til nettstedet ditt, vær forberedt på å gi større kompensasjon. Hvis de deltar i fjerntesting fra komforten av sitt eget hjem eller kontor, kreves mindre. Tid kommer selvfølgelig også inn i denne ligningen, og folk vil forvente å bli mer kompensert for 2 timer enn for 30 minutter.

Mulige former for kompensasjon Situasjonen din vil variere, men her er noen ting du kan tilby: $50 for en halvtimes fjerntest med en generell brukergruppe $80–$120 for en timelang, personlig test med en generell brukergruppe $180 –$250 for en timelang test med en spesifikk brukergruppe som du bestemmer vil svare godt på økonomisk kompensasjon Gratis tjeneste i tre måneder, gratis produkter laget av selskapet (ideelt sett de som ennå ikke er tilgjengelige for alle), medlemskap til en eksklusiv gruppe i seks måneder, og lignende for en spesifikk brukergruppe som neppe vil bli imponert over en sjekk, for eksempel advokater, leger og salgsledere. Her er det igjen hvor det hjelper å være kreativ og fokusere på personasene dine. Hva vil motivere brukergruppen din?

Screening En screener er en type spørreskjema du kan bruke med potensielle deltakere før du planlegger dem. Det sikrer at de passer inn i din definisjon av en representativ bruker. Spørsmål er ment å sikre at respondenten enten er en nåværende bruker av funksjonene du tester-

eller en sannsynlig fremtidig bruker Finn ut om han passer inn i en eller flere av brukergruppene dine Hjelpe deg med å få en god blanding av deltakere innenfor den brukergruppen

236

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Ekskluder bestemte respondenter som kan ha erfaring som kan skjevt

dine resultater Samle nøkkeldetaljer du trenger å vite om før en deltaker ankommer

(valgfritt) Din screener bør inkludere et introduksjonsskript som rekruttereren din kan lese over telefonen, sammen med instruksjoner om når deltakeren skal kvalifiseres (hvis de passer) eller avslutte samtalen (hvis de ikke gjør det). Sluttbrukerne av screeneren din vil være personene som rekrutterer deltakerne dine – eller den potensielle deltakeren hvis du bruker et nettskjema for å screene. Begge kan fungere, men generelt er det best å samle en liste over de som er interessert ved å bruke et skjema eller e-post og deretter screene dem på telefon. Hvorfor? Fordi, dessverre, er det vanligvis lettere for folk å feilrepresentere seg selv på papir enn når de svarer noen direkte, og det er ikke uvanlig at noen prøver å bli med på en studie selv om de ikke kvalifiserer for det. Spesielt hvis det er snakk om erstatning! Screeneren din bør også luke ut de som har kunnskap som kan påvirke resultatene dine. Et vanlig spørsmål å stille er for eksempel om respondenten jobber innen markedsundersøkelser, fordi de sannsynligvis er for kjent med forskning generelt og som et resultat ikke er like sannsynlig å gi deg genuine reaksjoner. Det kan også være lurt å sile ut de som jobber for konkurrenter hvis det er bekymringer om å dele designinformasjon. Følgende er noen eksempler på spørsmål du kan se på en screener for en nettbestillingsapplikasjon fra bedrift til bedrift. I dette tilfellet retter vi oss mot en brukergruppe som er komfortabel med å bruke og kjøpe via nettet, og som sannsynligvis også vil gjøre det på egenhånd. Merk at noen spørsmål er ment å screene deltakere inn eller ut, mens andre (som spørsmål 4) er mer rettet mot å plassere kvalifiserte deltakere i riktig brukergruppe. 1. Hvilken aldersgruppe faller du inn i? [blanding av alder over 18] a. Under 18

TERMINERE

b. 18–24 c. 25–34 d. 35–44 e. 45–54 f. 55 eller over

BRUKERHETSTEST

237

2. Hvor ofte bruker du Internett hjemme? en. Aldri

TERMINERE

b. Mindre enn en gang i måneden

TERMINERE

c. Noen ganger i måneden d. Minst en gang i uken e. Flere ganger i uken f. En gang om dagen eller mer 3. Når var siste gang du gjorde et personlig kjøp av et produkt på nettet? en. I løpet av den siste måneden b. 1–3 måneder siden c. 3–6 måneder siden d. 6–12 måneder siden

TERMINERE

e. Over 12 måneder siden

TERMINERE

f. Jeg har aldri gjort et personlig kjøp på nettet

TERMINERE

4. Når var siste gang du besøkte pseudocorporation.com? [Gruppe A er sjeldne eller ikke-brukere; Gruppe B er hyppige brukere]

238

en. Jeg har aldri besøkt siden

SJEKK for GRUPPE A

b. I løpet av den siste måneden

SJEKK for GRUPPE B

c. 1-3 måneder siden

SJEKK for GRUPPE B

d. 3-6 måneder siden

SJEKK for GRUPPE B

e. 6–12 måneder siden

SJEKK for A eller B

f. Over 12 måneder siden

SJEKK for GRUPPE A

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

You've Been Terminated Terminate er et hardt klingende ord. Det betyr at samtalen bør avsluttes fordi respondenten ikke passer testen. Du vil ikke at respondenten skal føle seg dårlig om dette, men du skal heller ikke kaste bort tiden hennes på å stille oppfølgingsspørsmål når du vet at hun ikke passer. Det er mange måter å håndtere dette på. En favoritt er å si at gruppen hun kvalifiserer for allerede er fylt opp, og spørre om du kan kontakte henne i fremtiden hvis det er en annen test hun kunne vært interessert i.

Planlegging for plass og utstyr På dette tidspunktet vet du om du tester eksternt eller personlig og hvor lang tid du trenger for hver deltaker. Her er noen av de andre avgjørelsene du bør ﬁnne: Hvor du tester: I en leid plass med et observasjonsrom, i et konferanserom på bedriftsstedet, eller på stedet der potensielle brukere vil være? Planlegg for et rolig sted som komfortabelt har plass til to eller tre personer sammen med datamaskinoppsettet du skal teste på. Hvilket personale du trenger i tillegg til tilretteleggeren: Du kan spare tid og øke nøyaktigheten ved å ha en logginformasjon for notater under testen, for eksempel. Andre muligheter inkluderer en hilsen (for å møte innkommende deltakere, dele ut spørreskjemaer mens folk venter, og eskortere deltakere inn og ut av testrommet) og noen til å gi IT-støtte dersom noe skulle dukke opp under testen. Slik skal du ta opp testen: Du kan bruke en rekke metoder, men programvare som TechSmiths Morae og Camtasia Studio gjør skjermopptak enkelt, og Morae har ekstra funksjoner for integrering av video og lyd med webkamera.

Skrive diskusjonsveiledninger Til slutt må du sette sammen materialene du trenger for selve testen. Du har dine generelle oppgaver oppført i forskningsplanen; nå må du ferdigstille selve teksten og instruksjonene for oppgaven. Du vil ha minst to pakker her – én for testlederen og én for deltakeren (med nok kopier for hver test til å inkludere én av hver).

BRUKERHETSTEST

239

Begynn med et introduksjonsmanus som tilretteleggeren kan lese for deltakeren. Mange gode eksempler er tilgjengelige på http://usability.gov/templates.

Surfing Usability.gov er et nettsted utviklet gjennom U.S. Department of Health and Human Services som en del av et initiativ for å oppmuntre til utvikling av nettsteder som er tilgjengelige for et bredt publikum. Den har et utmerket sett med referansemateriale for å hjelpe med brukersentrert design, inkludert et eksempel på et videosamtykkeskjema (i Microsoft Word-format), som du bør få deltakerne til å signere før du tar dem opp: http://www.usability. gov/templates/docs/release.doc

Instruksjonene dine bør inneholde all den spesifikke informasjonen som deltakeren trenger for å fullføre oppgaven eller oppgavene du tester. Hvis oppgavene dine krever mye datainntasting og personalisering, sett opp litt informasjon på forhånd og gi deltakerne forhåndsbestemte data som skal brukes. For eksempel, hvis en pålogging er involvert, vil du sannsynligvis få alle deltakerne til å bruke samme sett med påloggingsinformasjon. Sørg for at instruksjonene for oppgaven inkluderer all denne informasjonen tydelig, slik at den er enkel å fylle ut. Her er et eksempel på hvordan en oppgave for en innholdsredigerer blir mer spesifikk i diskusjonsguiden. Den opprinnelige oppgaven i planen er "Finn en artikkel som er klar for redigering." I diskusjonsguiden blir dette følgende: INNLEDNING Din leder har bedt deg om å ta på deg en ny rolle: redigere og godkjenne artikler postet av skribenter som bidrar til selskapets nettsted. Når du har godkjent en artikkel, vil den bli lagt ut på nettstedet i nyhetsområdet. Du og tre andre redaktører vil godkjenne elementene for å sikre at de passer med selskapets budskap. Du har fått følgende påloggingsinformasjon for redigeringsverktøyet: Brukernavn: grobertson Passord: come2gether

240

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Les hver oppgave høyt, og fullfør den deretter med redigeringsverktøyet. Oppgave 1 Logg på verktøyet og åpne en artikkel som er klar for redigering.

Som du kan se ovenfor, har vi endret oppgaven noe for å avslutte med en klar slutttilstand - en åpen artikkel. Denne typen justeringer vil være vanlig når du går til dette detaljnivået og tenker på hvordan du vil måle suksess. Du kan også følge hver oppgave med spørsmålene om brukertilfredshet som er diskutert i planleggingsdelen. Generelt er det best å gi hver oppgave sin egen side slik at brukeren ikke blir fristet til å se fremover. Oppsummert bør testmaterialet ditt inneholde følgende: Samtykkeskjema for videoopptak (se sidefeltet for surfing på forrige side

side for mer informasjon) Diskusjonsguide for fasilitator, med introduksjonsmanus Diskusjonsguide for deltaker, med detaljerte oppgaver og brukertilfredshet

spørsmål Et format for å ta notater, hvis du har noen dedikert til det. Dette kan

variere fra et loggingsverktøy innebygd i testprogramvaren til et regneark for å skrive inn svar på en trykt mal for å krysse av nøkkelinformasjon (for eksempel typer spørsmål som kreves). Å bruke litt ekstra tid før testen på å sette opp dette vil sikre at du får konsistente resultater og spare deg for mye tid på gjennomgang av opptak. Eventuelt et spørreskjema. Noen ganger kommer deltakerne tidlig og har

litt ventetid – dette er en utmerket mulighet til å samle litt ekstra informasjon. Hvis du har laget en undersøkelse tidligere, hvorfor ikke gjenbruke den her? Metoden for kompensasjon, gis til deltakeren på slutten av

testen (penger i en konvolutt, et allment akseptert gavekort som et Visa-gavekort osv.). Hvis du har valgt kompensasjon som gratistjenester, der ingenting deles ut etter testen, forsikre deltakeren om at de vil få oppfølging senest neste dag. Hvis du bruker papirprototyping under testen, vil du også ha disse materialene å jobbe med. Sørg for at du har settene forberedt for enkel håndtering før den første testen starter.

BRUKERHETSTEST

241

Tilrettelegging Jobben til tilretteleggeren er å introdusere deltakeren til prosessen, svare på de første spørsmålene deres, og deretter skaffe deg hvilken innsikt du kan mens du fortsatt prøver å la deltakeren handle så naturlig som mulig. Sørg for å be brukere om å tenke høyt under testen, som om de snakket til seg selv (og minn dem forsiktig på å gjøre det hvis de begynner å jobbe stille). "Tenk høyt"-teknikken er måten du får mest mulig innsikt i brukernes atferd på. Du vil lære mye om deres problemløsning og tankeprosesser hvis du hører om dem under selve oppgaven, i motsetning til å be deltakerne om å gjenskape dem senere når deres erindring kanskje ikke er like nøyaktig. Vær også forsiktig så du ikke gir deltakeren det "riktige" svaret for raskt! En av de vanskeligste delene av å gjennomføre en brukervennlighetstest er å se den nøye utvalgte deltakeren din slite kraftig med en oppgave og bare la dem slite. Tross alt er du sannsynligvis i dette feltet fordi du er et empatisk individ. Du ønsker å hjelpe folk. Så det kan føles litt sadistisk å se noen bli stadig mer frustrerte, få dem til å henvende seg til deg for å få hjelp, og deretter svare: "Hva ville du gjort hvis du prøvde dette på egenhånd?" Når en deltaker stiller deg et spørsmål mens han jobber, hold tilbake noen slag før du svarer. Det er mest sannsynlig at deltakerne stiller spørsmål rett i begynnelsen av testen, spesielt hvis de føler seg vanskelige med å jobbe med deg ved siden av dem. Når de innser at du er der for observasjon mer enn for samtale, vil de ofte begynne å fokusere på oppgaven mer enn din tilstedeværelse. Her er noen eksempler på deltakerspørsmål og forslag til svar: Deltaker: «Det ser ut til at det kan være denne kategorien, bør jeg gå hit?» Tilrettelegger:

"Fortsett og prøv det."

Deltaker: "Skal jeg gå hit?" Tilrettelegger:

"Er det det du tror du vil gjøre på dette tidspunktet?"

Deltaker: "Er dette måten å sende inn kommentarer?" Tilrettelegger:

Stillhet. Har et vennlig og avslappet uttrykk mens hun smiler til deltakeren, og ser deretter forventningsfullt på skjermen hans.

Så når griper du inn?

242

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Hvis brukeren allerede har anstrengt seg mer enn du tror han ville gjort når han jobber på egenhånd, og du føler at du har lært hvorfor han havnet på feil vei, er det på tide å gå videre - spesielt hvis du har flere oppgaver å få gjennom og du vil ikke at han skal bære frustrasjonen sin videre til resten av testen. I kapittel 6 nevnte vi viktigheten av å unngå ledende spørsmål i brukerintervjuer. Det samme gjelder her også. Hvis du føler at du er for nær designet og den kritikken kan få deg til å reagere defensivt, bør du vurdere å trene noen andre til å legge til rette mens du tar notater.

Analysere og presentere resultater Du har fullført alle testene og har nå et fjell med data å gå gjennom. Men det er noen viktige funn som du allerede tror er relevante, og prosjektteamet ditt er veldig spent på å vite hvordan det gikk. Det kan være lurt å planlegge en uformell verbal oversikt over takeawayene dine for teamet. Det kan hjelpe deg med å verbalisere noen av trendene du har lagt merke til, og bidra til å sette scenen for din senere rapport. Sørg for å kommunisere at dette er førsteinntrykk, og at du trenger tid til å analysere dataene dine mer detaljert. Du vil ikke nødvendigvis hoppe inn i anbefalinger her før du har et fullstendig bilde av hvor eventuelle problemer kan ligge. Når du har tid til å sette deg ned med dataene, se gjennom dem med et par ting i tankene: Hvor lang tid du har til analyse. Det er lett å gå seg vill i detaljene og prøve å inkludere alt. Som alltid, hold øye med testen og målene dine mens du erter de viktige funnene. Hvis du har ti timer med testopptak og fem dager til å skrive hele rapporten, vil du sannsynligvis ikke ta deg tid til å se videoen av hver test. Stol på notattakeren din og gå tilbake til videoene hovedsakelig for å sikre at nøkkelsitatene du husker er tatt opp riktig. Hvordan resultatene dine vil bli brukt. Dette er en viktig detalj som ofte kan undervurderes. Du kan lage en vakker 20-siders rapport, men bare én av disse sidene vil sannsynligvis få mye kjørelengde: sammendraget.

BRUKERHETSTEST

243

Hvis bedriftens interessenter ønsker å se detaljene, kan selve rapporten være den viktigste måten å kommunisere resultater på. Hvis du tror du trenger to detaljnivåer – ett for interessenter og et annet for prosjektteamet – vurder å lage en presentasjonsversjon av rapporten også, som treffer viktige funn på en mer synlig, fordøyelig og prioritert måte. De som er interessert i mer detaljer kan da henvise til hele rapporten. Prioritering av problemer På slutten av testen vil du potensielt ha en lang liste med brukervennlighetsproblemer å forstå og prioritere. Her er noen egenskaper som vil hjelpe deg å finne ut hvor alvorlig en feil er: Konsekvenser. De negative resultatene av å møte problemet. For eksempel, hvis en deltaker mister data på grunn av et brukervennlighetsproblem, garanterer det en høy vurdering. La oss si at hun bruker ti minutter på å fylle ut et komplekst skjema og ved et uhell velger en lenke som tar henne til en annen side. Hvis hun trykker på Tilbake-knappen i en nettleser, er dataene hennes borte? Gjenvinnbarhet. I hvilken grad deltakeren kan komme seg etter å ha støtt på problemet – er han for eksempel i stand til å enkelt komme tilbake via en alternativ vei? Hyppighet av forekomst. Fordi du ikke jobber med et stort antall mennesker, står dette ikke alene som et alvorlighetsmerke. Men hvis fem personer gjør den samme feilen og det fører dem ned på en mindre optimal vei, er det et godt tegn at du bør vurdere å prioritere det høyere. Rasjonell årsak. Hvis problemet ikke ble støtt på ofte, men det ble laget av noen som passet inn i brukergruppen din, laget hun det av en rasjonell grunn, og det var en klar årsak til feilen, bør problemet vurderes når du kommer med anbefalingene dine. Generere innsikt Bortsett fra problemene du har samlet, vil du ha et vell av uttalelser fra brukere som kan bringe frem verdifull innsikt for prosjektteamet. Som beskrevet i kapittel 6, er en affinitetsdiagramøvelse en utmerket måte å samle disse utsagnene og i fellesskap identifisere mønstre.

244

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Her er noen av måtene du kan kategorisere brukeruttalelser på (se avsnittet "Kontekstuell forespørsel" i kapittel 6 for mer detaljer): Mål Mentale modeller Ideer og funksjonsforespørsler Frustrasjoner Løsninger Verdiuttalelser Gledeligheter (ikke utelat disse – det gjør du' ønsker ikke å miste de gode tingene!) Forventninger (spesielt når de er savnet)

Både i innsikt og i anbefalinger, sørg for å inkludere de positive funnene også. Usability testrapporter blir ofte sett på som for negative, hovedsakelig fordi forskeren prioriterer diskusjon om ting som må fikses fremfor ting som går bra. Å ta seg tid til å diskutere de gode tingene vil gjøre den generelle rapportopplevelsen bedre for alle. Det hjelper også designteamet å bli engasjert i resultatene – og begeistret for å gjøre designet enda bedre.

Lage anbefalinger Selv før du begynner å analysere, har du sannsynligvis allerede noen gode ideer i hodet ditt for å fikse problemene du møter i testen. Skisser dem underveis mens du identifiserer problemer og innsikt, slik at du ikke mister dem. Bare pass på at en enkelt idé ikke tar over for tidlig og påvirker ditt syn på andre potensielle tilnærminger som kan løse flere problemer. En god anbefaling bør løse mer enn ett problem, hvis mulig. Det kan være lurt å gruppere problemer

sammen under én større anbefaling, avhengig av hvor detaljert og spesifikt du blir med problembeskrivelsene dine. Vær handlekraftig og enkel – unngå for tidlig detaljerte design.

BRUKERHETSTEST

245

Bruk ordspråk som er enkelt, men ikke nedlatende. Mottar

Kritikk er en vanskelig ting, spesielt for de som var direkte involvert i designet som ble testet. Ikke underspill problemer, men husk at ordene dine må fremstå som konstruktive og respektfulle. Husk at anbefalinger må være målrettet mot sluttbrukerne like mye som systemet gjør. Når du ferdigstiller rapporten, kan du sirkle tilbake og spørre deg selv om de opprinnelige målene ble nådd og hvordan du best kan gi resultatene dine til de ulike personene som skal bruke dem: interessenter, designere og utviklere. Når vi snakker om utviklere, er det på tide å bringe dem i forkant igjen. I neste kapittel skal vi dekke tingene du bør huske på når du går fra design til utvikling og videre.

246

KAPITTEL 13: DESIGN-TESTING MED BRUKERE

Overgang: Fra design til utvikling og utover Hvor går vi herfra? Deﬁnerings- og designfasene til prosjektet ditt er over. Hva nå? En god designprosess for brukeropplevelse tar aldri slutt. Etter at du har vært gjennom så mye å definere og designe, hvordan forblir du engasjert for å sikre at den endelige prosjektleveransen er brukeropplevelsen du har designet – og hvor går du derfra? Russ Unger

247

Dette er slutten... ...på boken. Dette er det aller siste kapittelet. Det er imidlertid ikke slutten på designprosessen for brukeropplevelsen, selv om det kan virke slik på overflaten. Når du har vært gjennom alle de tidligere fasene av et prosjekt, tror du kanskje at arbeidet ditt er gjort og at du ikke har noe mer å bidra med. I mange tilfeller ender UX-designarbeid som oppgaver på noens prosjektplan et sted, og etter at arbeidsproduktet ditt er overlevert til resten av teamet, blir du alltid stokket til et annet prosjekt. På tide å lukke den døren og begynne på noe nytt, ikke sant? Veldig feil! Du kan fortsatt gjøre mye for å sikre at det produseres best mulig design for brukeropplevelsen.

Visuell design, utvikling og kvalitetssikring I noen tilfeller er det sømløst å jobbe med et design- eller utviklingsteam som mottar ditt prosjektbaserte arbeidsprodukt. Noen ganger stoler nedstrøms arbeidspartnere på at du svarer på spørsmål, gir innspill og hjelper dem med noen av designkonseptene de jobber med. (Dette kan til og med høres mye ut som prototyping for deg!) I disse arbeidsmiljøene blir brukeropplevelsesdesign allerede omfavnet, og teamet har sannsynligvis hatt framsyn til å gi deg tid til å utføre disse rådgivende oppgavene. I mange organisasjoner er rollene til designere av brukeropplevelser, informasjonsarkitekter, interaksjonsdesignere og så videre fortsatt veldig nye. Hvordan du skal administrere disse rollene kan være uklart, og beslutningen om hvor engasjert du bør være kan falle på noen som ikke fullt ut forstår design av brukeropplevelse. Det kan være opp til deg å finne måter å kontinuerlig forbli engasjert.

248

KAPITTEL 14: OVERGANG: FRA DESIGN TIL UTVIKLING OG VIDERE

Her er noen forslag: 1. Kjøp dem et eksemplar av denne boken, takk. 2. Ikke vær sjenert. 3. Les gjennom resten av dette kapittelet og se etter muligheter der du kan være engasjert og nyttig. 4. Be om å bli engasjert og vær klar til å forsvare forespørselen din. Det er andre tilfeller der du kan finne ut at det visuelle design- eller utviklingsteamet er kongen av selskapet og deres prosjekter, og du kan finne det utfordrende å forbli engasjert. Du kan finne på å prøve å bryte ned vegger bare for å kunne gjennomgå arbeidet og sikre samsvar. Dette er ikke alltid tilfelle, men det skjer. Christopher Fahey, grunnlegger av Behavior (www.behaviordesign.com), er ikke fremmed for å overvinne denne utfordringen. Han gir dette rådet: Noen organisasjoner er tett oppdelt. For å holde deg engasjert i utviklingen av prosjektet etter at de innledende designfasene er fullført, må du være proaktiv og kreve muligheten til å gi tilbakemelding og korreksjon til de visuelle design- og utviklingsteamene. De vil ofte rett og slett ikke engang tenke på å be deg om å være der. Ideelt sett vil du gjøre dette under planleggings- og budsjetteringsfasen av prosjektet. Hvis ikke, må du bokstavelig talt frivillig tilby tjenestene dine for å sikre at designet ikke forringes under påfølgende utvikling. Et triks er å ganske enkelt be om å bli lagt til, selv uformelt, til kvalitetssikringsteamet (forutsatt at du har en – hvis ikke, spør definitivt om dette til visuelle designere og utviklere!) og å få tilgang og passord til eventuelle utviklingssteder og feilsporingsverktøy. Da kan du legge til dine kritikker og avvik i den samme feilfiksingskøen utviklerne ser på hver dag.

Selvfølgelig vil mange prosjekter ikke ha luksusen til et kvalitetssikringsteam. I en perfekt verden ville hvert prosjekt ha et slikt team; i realiteten er imidlertid ikke alltid QA tilgjengelig. Noen ganger utfører utviklere QA selv mens de utvikler seg. I tillegg til å få deg til å krype, bør du vite dette få deg til å prøve enda hardere å jobbe med utviklere.

VISUELL DESIGN, UTVIKLING OG KVALITETSSIKRING

249

Kunsten å forhandle Kunsten å forhandle kan bli et kritisk aspekt av rollen din som designer for brukeropplevelser. Nedstrøms arbeidspartnere, som visuelle designere og utviklere, kan ta seg friheter med sine endringer i arbeidet ditt uten å innse hvordan det påvirker viktige deler av brukeropplevelsen. I tilfelle noen forteller deg at noe "ikke" kan gjøres, må du være forberedt på å komme opp med en plan B. Gode forhandlingsevner vil hjelpe deg med å forsvare designbeslutningen din (som bør være basert på forskningen du har gjort) ferdig) og overbevise andre om at brukeropplevelsen kan gjøres. Alternativt vil disse ferdighetene hjelpe deg å jobbe med partnerne dine for å skape en tilfredsstillende Plan B-tilnærming som oppfyller så mange av alles behov som mulig. For ytterligere innsikt om forhandling, sjekk ut Getting to Yes: Negotiating Agreement Without Giving In, av Roger Fisher, William L. Ury og Bruce Patton (Penguin, 1991) og Selling to the VP of No, av Dave Gray (XPLANE Corp. , 2003).

Det gjelder spesielt i mange små selskaper: QA er en luksus. QA "utføres av alle, men spesielt utvikleren," sier Troy Lucht, rektor og direktør for utvikling av Ascend Realty Solutions (www .ascendrealtysolutions.com). Alle prøver å – og vil – pitche, men uten ressurser dedikert til å skrive testskript, kan det være umulig å informere folk om hva de bør teste når utviklingen ofte utføres til siste mulige minutt. I mange tilfeller er vår interne designer personen som kjenner applikasjonen like godt som meg, så han kan gi mer informert tilbakemelding. Å legge til en brukeropplevelsesdesigner til blandingen ville virkelig avrunde ting for vårt lille team.

Selv om arbeidsproduktet for brukeropplevelsesdesign kanskje ikke inkluderer å lage testskript, kan du i noen tilfeller teste mot wireframes og merknader du opprettet for å sikre at alle elementene er redegjort for og at alle de definerte oppfordringene til handling fungerer som de skal. Denne situasjonen er ikke perfekt, men det er en tilnærming som kan være nyttig når QA ikke eksisterer. Det viktigste her er at brukeropplevelsesdesign ikke slutter bare fordi du har snudd arbeidsproduktet ditt og utført en kunnskapsoverføring. Din rolle kan midlertidig anta mer av konsulentkarakter, men du er langt fra ferdig.

250

KAPITTEL 14: OVERGANG: FRA DESIGN TIL UTVIKLING OG VIDERE

Designtesting med brukere (igjen) Gjorde vi ikke brukertesting allerede? Forhåpentligvis kan du svare ja på dette spørsmålet, men det skjer ikke alltid. Dessverre gjør heller ikke dette spesielle trinnet med testing, som er utpekt for å teste det endelige, designet og utviklede nettstedet med ekte brukere før lansering. Dette lar deg ta en siste titt på nettsiden og finne de siste feilene og feilene som du kanskje har oversett under QA-testing. Når du har identifisert ditt målsett med brukere, kan du teste nettstedet mot scenarier som ser ut til å være høyrisiko eller som kan ha problemer i tidligere iterasjoner av nettstedet. Denne testrunden kan gi deg informasjonen som er nødvendig for å avgjøre om nettstedet ditt er klart til lansering eller ikke. Hvis det er betydelige problemer avdekket under denne testrunden, kan det være viktig å foreta oppdateringer og teste på nytt.

10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … Lansering! "Hvis du bygger det, kommer de. …” Den teorien blir nevnt mye – og motbevist nesten like ofte. Du kan bygge den vakreste, mest tilfredsstillende, brukbare applikasjonen som er mulig, lansere den i verden og finne ut to måneder senere at nesten ingen tar den i bruk. Hva gir? Brukeradopsjon er i hvilken grad brukerbasen du målretter mot ender opp med å bruke nettstedet eller applikasjonen. Noen adopsjonsproblemer kan unngås hvis du følger gode fremgangsmåter for søkemotoroptimalisering (kapittel 8) for å sikre at brukerne dine kan finne det nye nettstedet. Brukeradopsjon betyr også at god brukeropplevelsesdesign ikke stopper når prosjektet er over – eller at det er begrenset til prosjektet du jobber med. Du kan hjelpe markedsførings-, kundestøtte-, PR- og opplæringsteamene med å sikre en jevn distribusjon og brukerbase som er begeistret for nettstedet eller prosjektet ved å hjelpe dem med tre faktorer som ofte påvirker brukeradopsjon: Personlig fordel

10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … LANSERING!

251

Support Network mening

La oss se nærmere på hver av disse etter tur.

Personlig fordel Et av de viktigste spørsmålene å svare på for brukerne vil være "Hva er det for meg?" Hvor flott nettstedet ditt enn er, hvis du ikke raskt kan forklare den unike fordelen den gir til en bestemt type bruker (eller en av personaene du har identifisert), kan du slite med å engasjere brukere. Noen fordeler er direkte: "Ved å bruke denne kamerafunksjonen kan du legge ut bilder på nettkontoen din med ett klikk på en knapp." Noen er indirekte: "Ved å bruke dette timelisteverktøyet kan selskapet lettere spore tiden du bruker på hvert prosjekt." Du har brukt verdifull tid på å få innsikt i brukerne dine; Bruk nå denne innsikten til å hjelpe markedsavdelingen med å skreddersy budskapene sine.

Support Når brukerne dine trenger hjelp med nettstedet, hvordan får de det? I tillegg til den kontekstuelle hjelpen som din utmerkede brukeropplevelsesdesign innsats vil strebe etter å gi, inkluderer svaret på dette spørsmålet også opplæring og kundestøtte. Føler du at brukerne dine kan reagere bedre på klasseromsopplæring i stedet for nettbasert opplæring? Vil noen av brukerne dine omgå opplæring og forvente å ha alt de trenger på selve nettstedet? Er live chat et viktig alternativ for brukerne dine for kundestøtte, eller vil de være fornøyd med telefon- og e-poststøtte? Støttetiltak er vanskelig, og å forstå brukerne lar deg være effektiv i å hjelpe kundestøtte- og opplæringsavdelingene dine.

252

KAPITTEL 14: OVERGANG: FRA DESIGN TIL UTVIKLING OG VIDERE

Network Opinion Muntlig tale er den viktigste påvirkningsfaktoren som finnes. Hva slags omdømme har kundens selskap og dets nåværende nettsted innenfor målgruppene for målgruppen? Selv om svaret her er positivt, betyr det ikke at det ikke kreves noen innsats – vedlikehold er alltid viktig når det kommer til omdømme. Ikke bruk et positivt svar som en unnskyldning for å hoppe til neste avsnitt: Innsatsen som er involvert i vedlikehold trenger ikke å være betydelig, men innsatsen som kreves for å komme tilbake fra et ryktedykk kan være svimlende. Litt TLC kan gå langt, så fortsett å lese. Hvis svaret er negativt, må det gjøres en seriøs innsats for å forbedre oppfatningene. Du må kanskje nå ut til brukerfellesskapet og identifisere hvem som er påvirkningsfaktorene, hvordan de foretrekker å kommunisere og hvordan de påvirker publikum – og deretter engasjere dem. Det er mange måter å engasjere brukerne dine på via sosiale nettverk og påvirke meningene du har om din klient, bedrift og nettside. Hjelp klienten din med å identifisere muligheter for å engasjere disse fellesskapene og forsøke å styre dem i en positiv retning. Hvis alle disse tre faktorene er på plass og du fortsatt merker en lav grad av bruk, bør du vurdere hvordan og hva konkurrentene dine gjør for å møte brukernes behov. Hvordan kan du skille produktet eller nettstedet?

Aktiviteter etter lansering Dette er interessante tider vi lever i: Så mange selskaper lanserer med seg selv – eller produktene sine – i en "beta"-tilstand. En beta-lansering betyr vanligvis at ekte, ufiltrerte brukere er publikum for live-testing av nettstedet for å hjelpe med å identifisere feil, feil, krasj eller andre problemer. På en gang ble betaversjoner vanligvis bare tilbudt utviklere, men det har nå blitt en vanlig praksis å åpne betaversjoner for brukerfellesskapet som helhet. I en betafase er det viktig at kommunikasjonsmetoder er satt opp for å registrere og rapportere eventuelle problemer som brukere måtte ha. Enhver type systemfeil som oppstår må registreres og gjøres tilgjengelig for prosjektet

AKTIVITETER ETTER LANSERING

253

team. Det må også være en mekanisme på plass for å la brukere rapportere problemer de møter til de aktuelle medlemmene av prosjektteamet. Hvis denne typen kommunikasjon ikke skjer – hvis designere av brukeropplevelse, visuelle designere og utviklere ikke vet hva som skjer i den ofte strenge og fartsfylte betafasen – kan nettstedet oppdateres og omdistribueres til brukere uten mye av strategien som er implementert.

Etterlanseringsanalyse Etter at du har lansert nettstedet ditt, er en av de første tingene du bør gjøre å begynne å samle data om bruk av nettstedet. Den beste kilden for dette er nettstedets loggfil. Dessverre er designere av brukeropplevelse sannsynligvis ikke øverst på listen for å motta eller gjennomgå denne informasjonen, så søk opp hvem som har ansvaret for å være vert for nettstedet og bruk dine forhandlingsferdigheter. Nettsideanalyse kan gi deg litt innsikt i de besøkende på nettstedet ditt. Blant andre aspekter kan du få en forståelse av hvem som er nye besøkende på nettstedet. Hvem gjentatte besøkende på nettstedet er Antall sidevisninger Sidevisningsvarighet Sidedybde Hvor besøkende forlater nettstedet (hvilke sider) Sesjonsvarighet Annonsevisninger Søkeord som brukes, resultater og re -søk

Denne informasjonen kan hjelpe deg å forstå hvor brukere har problemer ved å fremheve problemer på nettstedet. Selv om analyser kan fremstå som tørre og tunge tall, vil dataene og innsikten hjelpe deg med å sette sammen passende spørsmål når du tester etter lansering. Merk For mer informasjon om nettstedanalyse er Avinash Kaushiks nettanalyse: An Hour a Day (Sybex, 2007) et godt sted å begynne.

254

KAPITTEL 14: OVERGANG: FRA DESIGN TIL UTVIKLING OG VIDERE

Etterlansering av designtesting med brukere (igjen, igjen) Etter at du har akkumulert data fra analysene på nettstedet ditt og samler informasjon fra kundestøtte eller andre avdelinger som samhandler med brukere, kan du begynne å sette sammen en liste over spørsmål som skal brukes i en ny runde med designtesting med brukere. Med andre ord, bruk dataene du har samlet til å lage et nytt sett med spørsmål for å stille brukere av nettstedet, og bruk ferdighetene du lærte i kapittel 13. En av fordelene med denne testrunden er at du har en mulighet til å teste den samme gruppen med brukere som du jobbet med tidligere for å finne ut om deres meninger har endret seg etter lansering og mer bruk av nettstedet. Dette kan være ganske nyttig: Hvis du tester den samme gruppen med brukere på nytt (eller en del av den) kan du stille noen av de opprinnelige spørsmålene på nytt (meninger om funksjonalitet, evne til å utføre spesifikke oppgaver, og så videre) og analysere variansen i svar over tid. Dette potensialet for variasjon kan hjelpe deg med å avdekke nye forbedringsområder på nettstedet, samt få litt innsikt i brukernes læringskurve, basert på tidligere runder. Som en ekstra fordel kan det å analysere forskjellene i svar også hjelpe deg med å identifisere nye spørsmål som ikke ble vurdert tidligere.

Alt ferdig, ikke sant? Nei.

Just Like Starting Over… Gjennom innsamlingen av analytiske data og designtesting med forskningsdata, kan du begynne å kompilere en liste over forbedringer og forbedringer som vil være fordelaktige for nettstedet. Når du har samlet disse fullstendig, kan du sette sammen et nytt forslag (kapittel 3) basert på anbefalingene dine. Dette forslaget kan føre deg til et helt nytt prosjekt, som kan sende deg hele veien tilbake til å definere et nytt sett med prosjektmål (kapittel 4) og forretningskrav (kapittel 5). Du kan

AKKURAT SOM Å BEGYNNE PÅ NYTT…

255

deretter gå videre til ytterligere forskning (kapittel 6), lage personas (kapittel 7) for nylig identifiserte mål, forbedre SEO (kapittel 8), oppdatere eller lage nye nettstedskart og oppgaveflyt (kapittel 10), oppdatere eller lage nye wireframes og merknader (kapittel 11), lansering i ytterligere runder med prototyping (kapittel 12), og mer designtesting med brukere (kapittel 13)... Du skjønner ideen. Prosjekter bør ikke dø. De bør være springbrettet inn i nye prosjekter som er rettet mot å kontinuerlig forbedre brukeropplevelsesdesignet.

256

KAPITTEL 14: OVERGANG: FRA DESIGN TIL UTVIKLING OG VIDERE

Indeks En absolutt bane, bruker i HTML-prototype 213 bekreftelse og sign-off, inkludert i forslag 53–54 ACSI (American Customer Satisfaction Index) 103 aktiviteter, planlegging 162–164 Adaptive Path bruk av blyant og papir på 189–190 nettsted 168 ekstra kostnader og avgifter, inkludert i forslag 50 Adobe Acrobat PDFs prototyping-verktøy, funksjoner på 214–215 Adobe Illustrator-nettsted 167 Adobe InDesign-nettsted 167 talsmenn, prioriteringer på 150–151, 154 tilhørighetsdiagrammer som gjelder funksjonskonﬂikter 160–161 trinn for 99–100 ved bruk av brukervennlighetstesting 244 smidige tilnærminger oversikt over 63–64 ressurser for 65 AIGA-nettsted 51 Ajax, problemer med 132 Align Interactive-nettsted 217 alt-attributter, ved bruk av 139 American Customer Satisfaction Index (ACSI) 103 analyseverktøy tilgjengelighet fordeler med 254 merknader oversikt over 187 verktøy for 189–190 og wireframes 186–187, 193–194, 201 Aquent talentbyrås nettsted 51 piler og koblinger, definert 170 Ascend Reality Solutions nettsted 143 Ashton, Tim 160 Ashton, Jonathan Ashton .com, søk utført etter 128 forutsetninger, inkludert i forslag 47–48

attributter som sammenligner 90 prioritering og definering av Axure RP prototyping-verktøyfunksjoner på 215 nettsted 167

89–91

B Babyhold-nettsted 118 BabyNames-nettsted 118 balanse, oppnår i UX-design 6–7 Balsamiq Mockups prototypingverktøy, funksjoner til 216 Baty, Steve 12, 95 Behavior-nettsted 249 beta-lansering, definert 253–254 faktureringshastighet, 51 black hating definert 130–131 versus hvit hatt 141–142 bloggfunksjonalitet, nettstedskart for 166, 191 Blue Flavour-nettsted 167 Blueprint CSS-nettsted 167 kroppsspråk, tolking i fokusgrupper 106 bot, forklart 129 nettsteder for merkevaretilstedeværelse beskrevet 11 eksempler på 13 funksjoner av 12–13 mål for 13–14 merkevarestrateg/forvaltere, rollen som 26–27 Brooks, Mark 200–201 bygningseierskap, system for 183 Buley, Leah 189–190, 201 forretningsforkjempere bekymringer på 154 versus utvikling og brukertalsmenn 155 virksomhetsanalyse rolle for 27–28 bruk av wireframes i 188 forretningskrav 73 Se også kravsamling klargjøring 68–69 koalescing 82–84 gjennomføre heuristisk analyse for 70–73 lage planer for møter 78–79

INDEKS

257

forretningskrav (fortsettelse) lage regneark for 153 definerte 68 eksempel på 83 innsamlingsansvar for 75–76 innsamling av interessenter for 76–77 for Global Cruises hjemmeside 195–196 arv av utviklingsadvokat 157 lytte til ideer for 81 merker 84 konf. prioritering av 151–152 løpende møter effektivt 80–81 for wireframes 189 forretningsinteressenter, definert 75 Buxton, Bill 231

C kalenderverktøy, funksjonell prototype av 217, 219 kampanjer. Se markedsføringskampanjesider kortsortering lukkede sorteringer 110 forklart 93 gruppesorteringer 110 oversikt over 107–108 utfører testkjøring av 109 prosess på 108–110 gir instruksjoner for 109 fjernsortering 110 klienter, bruk av wireframes ved 188 cloaking, forklart 131–131 oversikt over 142 forebygging 138 utilsiktede 133 collager, bruk i mikrofinanseksempel 223–224 kommunikasjon, viktighet for prioritering 160 selskaper som bruker SWOT-analyse på 61–62 sammenligner konkurrenter 61 bedriftskulturhierarki på 36–37 logistiske historier på 34–35

258

INDEKS

kompensasjon, bestemmer for brukergrupper 235, 241 konkurrenter, sammenligner 61 konseptutforskning. Se også eksempel på visuelle design på 222–224 potensielle fallgruver av 222 formål med 221 forhold, definert 170 konflikt, håndtering under prioritering 158–162 tilkoblinger, slurv av 171 koblinger og piler, definert 170 konsensuskonﬂikter, håndtering av 170 konsensus, styring i prioritering, 16 5 beste fremgangsmåter for innhold for 138–139 viktigheten av å holde 135–136 ferske 138 innholdsskapere, bruk av wireframes av 188 innholdsstyringssystemer, oversikt over 133–134 innholdsmatrise, bruk av nummereringssystem på 173 innholdskildesider beskrevet 11 funksjoner i 16–17 mål for 17 oppgaver knyttet til 17 ved bruk av forretningsanalytikere for 28 ved bruk av kortsortering på 108 innholdsstrateg, rollen til 28–29 kontekstuell design, ressurs for 101 kontekstuell forespørsel forklart 92 informasjon hentet fra 98 prosesser på 98–99 ved bruk av affinitetsdiagrammer i 99– 101 tekstforfatter, rollen til 29–30 Coroﬂot-nettsted 51 kostnader og avgifter (tillegg), inkludert i forslag 50 robotsøkefunksjoner på 131 detektering via cloaking 132 forklart 129 Creative Commons-nettsted 50

D stiplet linje, som viser forhold med 170 beslutningspunkter, definerte 169 definisjons- og designfaser, overlapper mellom 145 leveranser, inkludert i forslag 48–49. Se også produktdesignmål for nettsteder for merkevaretilstedeværelse 13 for nettsteder for innholdskilde 17 for nettsteder for e-handel 19 for e-læringsapplikasjoner 20 for nettsteder for markedsføringskampanjer 15–16 innstilling 10 for applikasjoner for sosiale nettverk 21 for oppgavebaserte applikasjoner 18–19 design feil mangel på sidenummerering 173–174 feiljusterte objekter 172 dårlig plassert tekst 172–173 slurvete koblinger 171 ujevnt fordelte objekter 172 design, forbedrer 227 utviklere som oppnår prototyper fra 217 bruk av wireframes av 188 188 advokater for forretningsutvikling og 5 kommunikasjonsbrukere opp 158 bekymringer av 154 mål og ansvar på 157 arv av krav 157–158 involvering av 158 kvaliteter av 156 utviklingsteam, gir tilbakemelding til 249 digitale eiendeler, optimalisering for 138 digitale opplevelser, design av 5–6 digitale prototyper. Se også prototyping av publikum for 208 HTML versus WYSIWYG-redaktører 209–214 ressurser kreves for 209 tidslinje for 208 wireframe versus realistiske prototyper 207–209 Digital Web Magazine-nettsted 167

katalogstruktur, viktigheten av 134 diskusjonsguider, skriving for brukervennlighetstesting 239–241 dokumentasjon, planlegging av 162–164 domener, inkludert nøkkelord på 134 døråpningssider, oversikt over 142 prikker, bruk av i affinitetsdiagrammer 161 Dreamweaver CS4, Live View-funksjon i 209– 210 duplikatinnhold, forhindrer 138 dynamiske URL-er, unngår i innholdsstyringssystemer 133

E-handelssider, designmål for 19 utdanningsfokuserte mikronettsteder, eksempel på 15 e-læringsapplikasjoner, designmål for 20 følelser versus logikk 7 Aktiver-delen av PURITE Process 46-utstyr, planlegging for brukervennlighetstesting 239 Evans, Will 122, 123 , 181, 197–201 erfaring, håndgripelig versus digital 4–5

F Fahey, Christopher 249 Favreau, Jean Marc 40 har ideer og visualisering av 146–147 håndtering av konflikter relatert til 160–162 tilbakemeldingsmekanismer, prototyper på 219 avgifter og kostnader (i tillegg), inkludert i forslag 50 Finck, Nick 167 Fireworks CS4 prototyping tool funksjoner i 215–216 Flash, funksjoner i 130–132 Flash og Flash Catalyst prototypingverktøy, funksjoner i 216 Flash-innhold, innebygging i statiske lag 131 fokusgrupper diskusjonsformat for 105–106 forklart 93 tolking av kroppsspråk i 106 modererende 107 prosesser av 105 –107 bruk i mikrofinanseksempel 223 ved bruk av 104–105 bunntekst, utforming av 196

INDEKS

259

bunntekstlenker, lenkepopularitet for 140 front-end-utviklere, rollen til 31 finansieringsmodell, søknad om mikroﬁnans 222

G Garrett, Jesse James 168 Global Cruises, designer hjemmeside for 195–201 Google analytiske verktøy 24 PageRank-system 139 kvalitetsretningslinjer for webansvarlige 142 søk utført av 128 rutenett, ved bruk av i applikasjoner 172 grupper diskusjonsformat for 105–106 forklart 93 tolking av kroppsspråk i 106 modererende 107 prosess med 105–107 bruk i mikrofinans eksempel 223 ved bruk av 104–105

H Hadden, Jon 217–219 overskrift/navigasjon, utforming av 195 overskrifter metatag, muliggjør 137 heuristiske analyser fordel for krav som samler 73 oversikt over 70–71 begrunnelse for 71 trinn involvert i 72–73 hierarki, innvirkning på bedriftsprosjekter 36–37 Hinton, Andrew 177 Hofstede, Geert 36 hjemmeside designe 192 designe for Global Cruises 195–201 designe wireframe for 197–200 eksempel på 194 HTML prototype av 212 link popularitet av 140 HTML prototyper bryte ned kode for 213 for 210 skrivefeil i 2 checking skaper 210–212

260

INDEKS

I ideer, samler 82–84 ideer og visualiseringsfunksjoner 145–147 Illustrator-nettsted 167 bildekart, bruk av HTML-prototype 213-bildetag, bruker i HTML-prototype 213 InDesign-nettsted 167 indekserte sider, skiller 137–138 indekseringsnettsteder 131 sløyfe , unngå i innholdsstyringssystemer 133–134 informasjon, søker 17 informasjonsarkitekter som balanserer med andre roller 248–249 rolle 22–23, 25 Informasjonsarkitekturinstituttets nettsted 51, 167 instruksjoner, ﬁnaliserer for brukervennlighetstesting 239–241 interaksjonsdesignere som balanserer med andre roller 248–249 rolle på 23, 25 intervjuer. Se brukerintervjuer iStockphoto-nettstedet 117 Iterate-delen av PURITE Process 46 iterasjoner, wireframes som øvelse i 201 iterativ design, ressurs for 231 iterativ testing, bruk av prototyper for 217

J JavaScript, problemer med jQuery-nettstedet 214

132–133

K Keynote prototyping-verktøy, funksjoner av 214 nøkler, inkludert i nettstedskart 175 søkeordundersøkelsesverktøy, tilgjengelighet av 135 søkeorddrevne søk, oppførsel av 135 nøkkelord inkludert i domener 134 navnekonvensjoner for 136 ved bruk av URL-struktur 134–135 Knemeyer, Dirk 12

L lanserte nettsteder, analyse etter lansering av 254 venstre navigasjonslenker, prototype for 217–218 legender, inkludert i nettstedskart 175

lisensiert arbeid, definert 49–50 lenkeankertekstmetatag, forklart 137 koblingspopularitetsfordeling på 139–140 forklart 139 bunntekstlenker 140 innholdskrysskobling 141 manipulering 143 koblingssøppel 143 liste over brukerdeltakere, generering av 234–233 Live Views , bruker i Dreamweaver CS4 209 logikk versus følelser 7 logistikk, innvirkning på bedriftsprosjekter 37 logistikktrinn av brukervennlighetstesting 233–239 Lucht, Troy 250

M markedsføringskampanjesider beskrev 11 eksempler på 14 funksjoner av 14 mål for 15–16 markeder, bygge relasjoner med 26–27. Melzer, James 182 Messageﬁrst personas casestudie 115 Nettsted 219 meta description tag, forklart 137 meta nøkkelord tag forklart 136–137 spamming med 142 metakoder, tilgjengelighet av 136–137-metodikk, viktigheten av 62 mikrofinans, definert 222 mikronettsted, definert 15 Microsoft PowerPoint-nettsted 167 Microsoft Visio-nettsted 167 feil mangel på sidenummerering 173–174 feilplassert tekst 7127 dårlig plasserte objekter 173 slurvete forbindelser 171 objekter med ujevn avstand 172 modifiserte tilnærminger, etter 64–65 bevegelser, som viser 170 MSN, søk utført av 128

N navn, sørger for personas 118 negotiation, art of 250 network opinions, impact on user adoption 253 Nicolle persona, beskrevet 115–116 Nielsen, Jakob 71 nofollow-lenkeattributt, ved bruk av 140 noindex metatag, forklart 137

O-mål som anvender SWOT-analyse på 61–62 fuzzy versus solid 58–60 viktighet av 57–58 input fra UX-designere på 60–62 måler 58, 60 objekter kobler riktig sammen 171 telleritter mellom 172 feiljustering av 172 ujevn avstand av 172 observasjoner. for heuristisk analyse 72–73 OmniGraffle prototyping-verktøyfunksjoner på 215 Web-område 167 OpenOffice Draw-nettsted 167 OptimalSort-nettsted 109 oversikt, inkludert i forslag 44–45 eierskap og rettigheter, inkludert i forslag 49–50

P sidenummerering, mangel på 173–174 sidetittel metatag, forklart 136 PageRank-system, forklart 139–140 sider. Se også nettsteder kloning 142–143 definert 168 indeksering separat 137–138 sidestabel, definert 169 papir og blyant, bruker for wireframes 189–190, 201 “papirkultur”, forståelse 37

INDEKS

261

papirprototyping 206–207 eksempel på 217–218 HTML som 209 for navigasjonskonsepter 218 passiv observasjon, definert 99 baner, identifisering i oppgaveflyter 180 betalingsplan, inkludert i forslag 52–53 blyant og papir, bruk for wireframes 0,2019 personas alder av 118 biografi av 119 kasusstudie 115 definert 113 utdanningsnivå på 120 inngangs- eller triggerpunkter til klienter 120 finne informasjon for 114 informasjon inkludert i 116 plassering for 119 maksimering av bruk av 125 mobil komfortnivå av 121 klienter, motivasjoner for bruk eller prosjekter 121 navngiving 118 okkupasjon av 119 offline aktiviteter av 120 online aktiviteter av 120 oversikt master ark for 122 personlig sitat fra 120 bilder av 117–118 begrunnelse for 113–114 lønn eller lønnsområde på 120 sosial komfort nivå på 121 målgrupper målgruppegruppe for 124 målgruppe individ 124 teknisk komfortnivå på 121 typer av 113 brukermål av 121 fotokilder, innhenting for personas 117 Post-it-lapper, bruk av i affinitetsdiagrammer 161 etterlanseringsdesigntesting 255. Se også testing; brukervennlighetstesting trinn strømavstand, definert 36 PowerPoint-prototypverktøy, funksjoner på 214

262

INDEKS

PowerPoint-nettsted 167 PR (PageRank), forklart 139–140 Forbered del av PURITE Prosess 45 prissetting, strukturering for prosjekter 51–52 prioriteringsprosess som gjelder brukervennlighetstesting 244–245 balanserende roller i 154 forenkler 150–154 viktigheten av kommunikasjon til konflikt i løpet av 158–162 prosessflyt, eksempel på 181–182 produkter, suksess på 5. Se også leveranser prosjekttilnærminger smidig 63–64 betydning av 66 inkludert i forslag 45–47 modifiserte 64–65 trinn for 62–63 fossefall 63 prosjektretning , mangel på justering på 160 prosjektledelse, bruk av wireframes i 188 prosjektmål ved bruk av SWOT-analyse på 61–62 fuzzy versus solid 58–60 viktighet av 57–58 input fra UX-designere på 60–62 måler 58, 60 prosjektoversikt, inkludert i forslag 44–45 prosjektprising, inkludert i forslag 51–52 prosjektkrav, trinn involvert i 69 prosjektsponsor, definert 75 prosjektteam, definert 75 prosjektvilkår, diagram over 80 prosjekter beste praksis for 191 virkningen av selskapets historie på 34–35 prosessflyt av 181–182 forslagskomponenter bekreftelse og sign-off 53–54 tilleggskostnader og gebyrer 50 forutsetninger 47–48 leveranser 48–49 eierskap og rettigheter 49–50 betalingsplan 52–53

prosjekttilnærming 45–47 prosjektoversikt 44–45 prosjektprising 51–52 revisjonshistorikk 44 arbeidsomfang 47 arbeidsoppgaver 54–55 tittelside 42–43 forslag, viktigheten av 40–41 prototyper overkommelighet av 219 søknader av 219 av kalenderverktøy 217, 219 endring av wireframes til 210 fullføring av 219 opprettelse med WYSIWYG-redaktører 209–214 eksempler på 217–219 som tilbakemeldingsmekanisme 219 mål av 219 for iterativ testing 217 innhenting fra utviklere 217 217 realistiske wireframes207us Se også beste fremgangsmåter for digital prototyping for 205–206 oversikt over 205 papirverktøy 206–207 prototypingverktøy Adobe Acrobat PDF-er 214–215 Axure RP 215 Balsamiq Mockups 216 Fireworks CS4 215–216 Flash og Flash CatalysteGraff 21 16 KeynoteGraff 4 io 215 PURITE Prosess 45–46

Q kvalitativ forskning, bruk av brukbarhetstesting 227–229 kvalitative brukervennlighetstester, innhenting av informasjon for 231–232 kvalitetssikringsdokumenter, bruk nummereringssystem til 174 kvalitetssikringsteam alternativt til 250 som deltar på 249

kvalitetssikring, bruk av wireframes for 188 kvantitativ forskning, bruk av brukervennlighetstesting 227–229 spørreskjemaer, inkludert i diskusjonsguider 241 spørsmål. Se også screenere for aktivitetsplanlegging 162–164 for kompensasjon av brukergrupper 235–236 for dokumentasjonsplanlegging 162–164 for fokusgruppe 105 for storyboarding 148 for spørreundersøkelser 102 for brukervennlighetstesting 242 for brukerintervjuer 97 for brukertilfredshet 233

R Random Name Generator-nettsted 118 anbefalinger, oppretter for brukervennlighetstesting 245–246 rekrutteringstrinn av brukervennlighetsteste 233–239 omdirigeringer, setter opp 135 relativ bane, bruker i HTML-prototype 213 Render-delen av PURITE Process 46 krav, definerte 66 kravsamling, forkorte 74 Se også kravprosess for forretningskrav, oppmuntre 74 forskning, planlegging for brukervennlighetstesting 229–233 forskningsteknikker kortsortering 93, 107–110 kontekstuell forespørsel 92, 98–101 fokusgrupper 93, 104–107 personas 121 undersøkelser 92, 101–101 104 brukervennlighetstesting 93, 110–111 brukerintervjuer 92, 95–97 ressurser. Se også nettstedsressurser tilhørighetsdiagrammer 161 smidige tilnærminger 65 analyser 254 kroppsspråk 106 kontekstuell design 101 Google 128 HTML (HyperText Markup Language) 214

INDEKS

263

ressurser (fortsettelse) iterativ utforming 231 forhandling 250 prototyping-tilnærminger 217 sosiale nettverksapplikasjoner 20 verktøy 167 brukervennlighetstesting 231 ansvarsområder, skisserer 75–76 revisjonshistorikk, inkludert i forslag 44 roller balansering i prioriteringsprosessen 154 kombinert 1486 styring 9

S utvalgsstørrelse, definerte 227 arbeidsomfang, inkludert i forslag 47 screeners, ved bruk av brukervennlighetstesting 236–239. Se også spørsmål skriptnavigasjon, problemer med 132–133 søkeatferd, forståelse 135 Startveiledning for søkemotoroptimalisering 129 søkemotorer, utvikling av 129 søkeresultater, påvirkning av 142 søk per måned, statistikk relatert til 128 seksjonsoverskrifter, som gir rom for 137 Seiden, Josh 113 SEO (søkemotoroptimalisering) definerte 127 innvirkning av UX på 134 betydningen av 127–128 ressurser for 129 SEO-metoder, white hat versus black hat 141–142 SEO-spesialister, bruk av wireframes ved 188 sign-off og anerkjennelse, inkludert i forslag 53–54 nettstedsanalyser, verktøy for 24 nettstedskart avanserte eksempler på 175–176 for bloggfunksjonalitet 166, 191 bryte form av 177 definert 166

264

INDEKS

utelate nummereringsstruktur fra 173 enkelt eksempel på 174 versus oppgaveflyt 166 ved bruk av 138 ved bruk av kortsortering for 108 ved bruk av oppgaveflyter med 178 stedstype, som identifiserer 11 steder. Se også sider som indekserer 131 skriving av tekst på 29–30 seks-up-mal, ved å bruke 190 Slingthought-nettsted 217 sosiale nettverksapplikasjoner beskrevet 20 designmål for 21 Social Security Administrations populære babynavn 118 Software Usability Measurement Inventory (SUMI) 103 SOW (erklæring om arbeid), innhold på 54–55 plass, planlegging for brukervennlighetstesting 239 spamming med metanøkkelord 142 Spencer, Donna 17, 109 spider, forklart 129 Spool, Jared 125 SRA International Inc. Nettsted 182 interessenter definerte 75 samlinger 76–77 81 statiske lag, innebygging av Flash-innhold i 131 klistremerkepunkter, bruk i affinitetsdiagrammer 161 Stock.XCHNG-nettsted 117 storyboarding, prosess med 147–150 styrker og svakheter, forståelse 61 SUMI (Software Usability Measurement Inventory) 303– støttenettverk, bygge 147–150 styrker og svakheter 33. Se også UX-designrolleundersøkelser forklart 92 oversikt over 101 prosess på 102–104 versus brukerintervjuer 102

SWFobject, ved bruk av 131 svømmebane, eksempel på 182–184 SWOT-analyse, som gjelder prosjektmål 61–62

T-merker. Se metatagger som er målrettet mot brukere, som beskriver 113. Se også brukeroppgaveflyt som bruker nummereringssystem til 173 som lager 178 eksempler på 178–180 oversikt over 166 prosessflyt 181–182 versus områdekart 166 svømmebaner 182–184 med oppgavebaserte 178 oppgavekart applikasjonssider beskrev 11 funksjoner og mål for 18–19 ved bruk av forretningsanalytikere for 28 Tatum, Keith 217–218 Taylor, Dave 214 teknisk struktur, bygger av 31 maler, bruker med wireframes 190 spenning, balansering mellom talsmenn 154–162 oppsigelse, ved hjelp av i brukervennlighetstesting 239 testmateriale, skriving for brukervennlighetstesting 241 Testdel av PURITE Process 46 testing, brukervennlighet versus brukeraksept 226. Se også designtesting etter lansering; brukervennlighetstestingstrinn tekstfinalisering for brukervennlighetstesting 239–241 dårlig plassering av 172–173 skriving på nettsteder 29–30 tittelside, inkludert i forslag 42–43 titteltagg, ved bruk av HTML-prototype 213-verktøy, tilgjengelighet på 167–168

U UAT (brukeraksepttesting), formålet med 226 Forstå delen av PURITE-prosess 45

URL-baner, unngå i innholdsstyringssystemer 133 URL-strukturer unngå i innholdsstyringssystemer 134 ved å bruke nøkkelord i 134–135 brukervennlighetstesting velge tilnærming for 227–228 forklarte 93 oversikt over 110–111 brukervennlighetstestingstrinn 236–239. Se også designtesting etter lansering; testing analysere og presentere resultater 243–245 velge tilnærming 227–228 lage anbefalinger 245–246 evaluere 250 fasilitering 242–243 planleggingsforskning 229–233 rekruttering og logistikk 233–239 skrive diskusjonsveiledninger 239–241 innvirkning på brukeren.gov2 brukervennlighet. meninger om 253 påvirkninger på 251–252 personlig fordel av 252 å gi støtte til 252 brukeradferd som påtar seg rolle for 150–151 bygge nettverk på 32–33 versus forretnings- og utviklingsadvokat 155 angår 154 brukeregenskaper som sammenligner 90 brukerprioritering og 89–91 brukeratferd , få kontekst for 227 brukeropplevelse (UX). Se UX (brukeropplevelse) brukergrupper som definerer 87 listeattributter for 87–89 User Interface Engineering-nettsted 125 brukerintervjuer forklart 92 intervjutips 97 prosess på 95–96 versus undersøkelser 102

INDEKS

265

brukermodeller, designe fra 91 brukerforskningsaktiviteter 93–94 fullføre 111 planlegging 94 trinn for å utføre 86 teknikker 92 brukerforskningsplan, utvikle 229–233 brukerforsker, rollen til 23–25 brukertilfredshet bestemmer 233 måleverktøy 103 brukeruttalelser som kategoriserer i oss tester 245 evaluerer 233 brukersuksess, bestemmer 232–233 brukere. Se også målbrukere som velger nummer for brukervennlighetstesting 229 identifiserer typer 88–89 bruk av wireframes av 188 UX (brukeropplevelse) digitale aspekter av 6 innvirkning på SEO 134 UX-design, definerte 3 UX-designroller. Se også støttenettverk merkevarestrateg/steward 26–27 forretningsanalytiker 27–28 velge 31 innholdsstrateg 28–29 tekstforfatter 29–30 front-end utvikler 31 informasjonsarkitekt 22–23 interaksjonsdesigner 23 ansvar for 25 brukerforsker 23–24 visuell designer 30–31 UX-designere som balanserer med andre roller 248–249 empati på 156 innspill på prosjektmål 60–62 organisasjoner for 7–8 rolle i prioritering 151 egenskaper på 6–7

V-validering, søker tidlig 191 verdiforslag, presenterer 15

266

INDEKS

Visio prototyping-verktøy, funksjoner til 215 Visio-nettsted 167 visuelle designteam, gir tilbakemelding til 249 visuelle designere som engasjerer seg i å lage wireframes 203 rolle 30–31 bruk av wireframes av 188 visuelle design. Se også konseptutforskning ved bruk av nummereringssystem på 174 modeller 224 av wireframes 200–201 Visuelle ordforrådsdefinisjoner betingelser 170 koblinger og piler 170 beslutningspunkt 169 side 168–169 sidestabel 169 visualisering og ideer funksjoner 4 vocabulær krav 145–0 –81

W WAMMI (Website Analysis and MeasureMent Inventory) 103 Warfel, Todd Zaki 115, 124, 217, 219 fossefallstilnærming endret 65 faser av 63 webmastere, kvalitetsretningslinjer for 142 webmastere/sideeiere Hjelp 129 WebMI Analyse og 1M -side ressurser 28. Se også ressurser ACSI (American Customer Satisfaction Index) 103 Adaptive Path 168 Adobe Illustrator 167 Adobe InDesign 167 AIGA 51 Align Interactive 217 Aquent talent byrå 51 Ascend Reality Solutions 250 Axure RP Pro 167 BabyName eller BabyName 167 BabyName

Blue Flavor 167 Blueprint CSS 167 "Brand Experience and the Web," 12 Brooks, Mark 201 kortsorteringsregneark 109–110 Coroﬂot 51 Creative Commons 50 Digital Web Magazine 167 døråpningssider 142 Evans, Will 181 Google-kode for ﬁden hadde statisk innhold 13 , Jon 219 heuristisk analyse 71 HTML-prototyping 214 Illustrator 167 bildekart 213–214 InDesign 167 Informasjonsarkitekturinstitutt 51, 167 informasjonssøkende 17 jQuery 214 søkeordundersøkelsesverktøy 135 nettsteder for markedsføringskampanjer 16 Meldingﬁrst 2167 Microsoft PowerPoint-navn 1691 Microsoft Visio-navn for 1691 Microsoft Visio fle 167 OpenOffice Draw 167 OptimalSort 109 personatyper 113 bilderessurser 117 PowerPoint 167 Generator for tilfeldig navn 118 Startveiledning for søkemotoroptimalisering 129 SEO (søkemotoroptimalisering) 143 Slingthought 217 Social Security Administration's Populære Baby Names Inc.18 SRA21 Name International ) 103 verktøy 167 skript for brukertesting 240 Usability.gov 240

Brukergrensesnittteknikk 125 måleverktøy for brukertilfredshet 103 UX-designtilnærminger 24 UX-organisasjoner 8 UX-undersøkelser 95 Visio 167 WAMMI (Website Analysis and MeasureMent Inventory) 103 Webmastere/sideeiere Hjelp 129 WebSort 109 WebTrends 24 Yahoo! Nettsted for grensesnittbibliotek 214 WebSort-nettsted 109 WebTrends-nettsted 24 white hat versus black hat 141–142 whiteboard, storyboarding på 149 wireframes og merknader 186–187, 193–194, 201 som bruker nummereringssystem til 1703 tilnærminger til å endre 220 tilnærminger sammenligne og kontrastere 200 lage 189, 198–199 designe for hjemmeside 197–200 som øvelser i iterasjoner 201 få innspill fra klienter for 192–193 oversikt over 186–187 som presenterer 202–203 versus realistiske prototyper 1–207–207–9 starter 31920 201 som «tenkende enhet», 198 verktøy for 189–190 brukere av 188 visuell design av 200–201 arbeid til leie, definerte 49 arbeidsflyter, storyboarding 149 regneark, lage for forretningsbehov 153 WYSIWYG-redigerere, lage prototyper med 2120

Y Yahoo, søk utført av 128 Yahoo! Nettsted for grensesnittbibliotek 214

INDEKS

267

Få gratis nettilgang til denne boken i 45 dager! Og få tilgang til tusenvis til ved å registrere deg for en gratis prøveversjon av Safari Books Online! Med kjøp av denne boken har du umiddelbar online, søkbar tilgang til den i 45 dager på Safari Books Online! Og mens du er der, sørg for å sjekke ut Safari Books Onlines digitale bibliotek på forespørsel og deres gratis prøveversjon (en egen registreringsprosess). Safari Books Online-abonnenter har tilgang til tusenvis av tekniske, kreative og forretningsmessige bøker, instruksjonsvideoer og artikler fra verdens ledende utgivere.

Bare besøk www.peachpit.com/safarienabled og skriv inn koden FJGSLZG for å prøve det i dag.

En prosjektveiledning til UX-design - PDF gratis nedlasting (2023)

References