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 det

utføre? eller hva erskal se etter inn? 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

faktiske

taggen 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øketmotorer 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økkelord136KAPITTEL 8: BRUKEROPPLEVELSE DESIGN OG SØKEMOTOROPTIMERINGmå 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 sikkerat 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 medi 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