Alternativ till den platta backloggen

I agila utvecklingsprojekt som jag varit med i har man jobbat med en backlog som består av User stories. En User story uttrycker vad en användare ska kunna göra med tjänsten som utvecklas, och tanken är att backloggen ska vara en samarbetsyta mellan utvecklarna (som har koll på vad som byggs) och produktägarna (som ska prioritera vad som byggs). User storyn följer formatet ”Som en … vill jag … för att …”, t.ex. ”Som en kund vill jag kunna lägga en vara i varukorgen för att kunna köpa plagget”. En bra user story kan innehålla mycket information. Här får vi reda på att det finns en, visserligen vag, målgrupp (kunden) som har en drivkraft (vill köpa plagget) vilken kan tillgodoses med en åtgärd (kunna lägga en vara i varukorgen).

Men det finns problem med user stories och det finns alternativ till den ”platta” backloggen.

User Story Map

Kunden i exemplet kommer inte nöja sig med att lägga varan i varukorgen för att få sin drivkraft tillgodosedd. Denna user story är en del av något större. Vi behöver kanske produktinformation, något sätt att fylla i sina uppgifter och betala. Det blir svårt att titta på denna user story och förstå var den hör hemma i ett större sammanhang utan någon sorts kontext. Och är det ens möjligt att prioritera storyn? Att kunna lägga en vara i varukorgen är ju superviktigt men det blir värdelöst utan produktinformation eller betalningsmöjlighet.

Jeff Patton beskriver ett alternativ till den platta backloggen, som kallas User Story Map. Det handlar om att abstrahera och gruppera stories i ”aktiviteter” som är stora saker folk gör, där flera steg ingår. Aktiviteten i exemplet skulle kunna vara ”Som en kund vill jag kunna köpa ett plagg på webbsidan för att slippa gå till butiken”, som består av flera sekventiellt ordnade ”uppgifter” där en skulle kunna vara ”Lägga vara i varukorgen”. Under varje uppgift finns uppgifter av lägre prioritet, t.ex. ”Få förslag på liknande varor”:

När sedan tjänsten ska utvecklas börjar man beta av stories uppifrån och arbetar sig nedåt. Ingen behöver inte fundera på vad som är mest prioriterat av ”Lägga i varukorg” och ”Visa produktinformation” – de är båda uppgifter på högsta nivån. Och eftersom man har abstraherat backloggen i aktiviteter med sekventiella uppgifter blir det lättare för alla inblandade att förstå hur tjänsten ska hänga ihop – inga fler kontextlösa stories.

Effektbackloggen

Jag är ett stort fan av effektkartan. Kort är effektkartan en modell som visar kopplingen mellan affärsmål (t.ex. ”Få folk att köpa mer klädesplagg”), potentiella målgrupper (t.ex. ”Kunder som köper i butik idag”), användningsmål (t.ex. ”Vill slippa gå till butiken”) och åtgärder (t.ex. ”Köpa plagg på webbsidan”). Effektkartan illustreras som ett träd och dess grenar skulle kunna bli basen för en backlog:

Tanken med effektkartan är att allt som utvecklas ska kunna kopplas till affärsmålet, via målgrupper och användningsmål. Den är ett stöd för att prioritera åtgärder, då prioriteringen kan lyftas till att handla om prioriterade målgrupper snarare än funktionalitet. Dessutom kan den erbjuda en bra översikt över vad man vet om målgrupperna och vad som ska utvecklas.

Idén att knyta user stories i en backlog till effektkartans användningsmål är inte dum, det blir liksom i en User Story Map lättare att förstå kontexten, fast på ett annat sätt. I effektkartan (eller effektbackloggen) är storyns kontext är inte hur aktiviteter utförs i sekvens utan snarare vilka användningsmål, målgrupper och vilket effektmål en User Story ska tillgodose. Effektkartan kan svara på frågor som ”Varför och för vem utvecklar vi varukorgen egentligen?” medan en User Story Map kan hjälpa oss med frågor som ”Hur hänger den här varukorgen ihop med de andra user stories vi utvecklar?”.

Mer läsning

The UX of User Stories av Anders Ramsay – om stories och story maps

The new user story backlog is a map av Jeff Patton – om story maps

Presentation om Agile product management with effect maps

The Effect Backlog av Martin Christensen

Annonser

Det bästa av två världar – användarcentrerad Scrum

Jag skrev för ett tag sedan lite om kombinationen användarcentrerad och agil utvecklingsmetodik. Nu har jag haft turen att få jobba i ett sådant projekt, tänkte skriva lite om fördelarna jag ser med denna kombination.

Projektet började med en tre veckors förstudie. Den bestod av:

  • Effektkartläggning – ett antal workshops med beställarna för att förstå deras syfte med projektet och hur de såg på sina målgrupper och deras behov. En effektkarta producerades.
  • Målgruppsanalys – målgruppsintervjuer med framtida användare ur olika målgrupper, som blev input till effektkartan.
  • Design – designprinciper, övergripande utkast till en interaktionsdesign utifrån effektkartan.
  • Teknisk analys – förberedelse för implementation, teknisk genomförbarhet.

Efter förstudien satte utvecklingen igång och projektet började följa den agila utvecklingsmetoden Scrum i tre veckors-sprintar. Utvecklarna kunde sätta igång direkt eftersom det fanns tillräckligt mycket design från förstudien. Under tiden fortsätter jag som interaktionsdesigner designa vad som ska finnas med i nästa sprint, i tight samarbete med beställarna. Jag jobbar samtidigt med att stödja utvecklarna och förklara hur jag tänkt.

Hittills har projektet fungerat riktigt bra och jag gillar det här arbetssättet skarpt:

Samarbete och kommunikation

Istället för att designen är helt klar innan utvecklingen börjar jobbas den fram efter hand. När man sitter i ett tvärfunktionellt team med både utvecklare och designers finns det möjlighet att samarbeta. Designern kan ta hjälp av utvecklarna för att avgöra hur svår en designlösning är att implementera. Utvecklarna kan ta hjälp av designern för att förstå hur denne tänkt. Bättre förståelse mellan designers och utvecklare.

Användningstester

Det kan ibland vara svårt att göra användningstester på en prototyp, speciellt om man utvecklar något komplext och dynamiskt. Enligt Scrum ska en fungerande version av produkten levereras i varje sprint. Jättebra, då kan vi göra tester på den fungerande produkten för att rätta till mindre designproblem som vi inte upptäckte i prototyptesterna. Och eftersom Scrum uppmuntrar föränderliga krav är det inga problem att implementera en korrigering i nästa sprint.

Kortare förstudie

Det är inte alltid lätt att sälja in en lång förstudie, beställare förstår inte alltid vikten av interaktionsdesign. Lägger man in stora delar av designtiden i utvecklingsfasen av projektet kan det bli lättare att sälja in och beställaren kan få en första fungerande version av produkten snabbare.

Det bästa av två världar

Agila och användarcentrerade utvecklingsmetoder har egentligen samma mål; att åstadkomma en bättre slutprodukt. Agila metoder genom förändring och bättre kommunikation mellan projektmedlemmar, UCD genom att fokusera på användare och behov.

Mer läsning

Clash of the Titans: Agile and UCD av Richard F Cecil på UXMatters

Bringing User Centered Design to the Agile Environment av Anthony Colfelt på boxesandarrows

dConstruct – Questions on Agile UCD av Leisa Reichelt på disambiguity

God Jul!

Boktips: A Project Guide to UX Design

På kurserna i Människa-Dator Interaktion på Umeå Universitet lärde man sig en massa teorier och filosofier. Jag kände redan då att något fattades och det blev riktigt uppenbart senare när man fick för sig att jobba med användbarhet ”på riktigt”. Boken Användbarhet i praktiken (som nu finns som wikibok) blev en ögonöppnare men det skulle lika gärna kunna varit den här boken, A Project Guide to UX Design, som handlar om hur man jobbar användarcentrerat i projekt. I motsats till Don’t Make Me Think som jag skrev om här innehåller den inga design-guidelines, istället handlar den om best practices för hur man kan arbeta. Den handlar om hur du fångar upp behov från beställare och användare, hur du använder dessa behov och landar i en prototyp via Personas, Site maps och Wireframes och hur du testar designen på dina användare.

Boken är släppt 2009 vilket är skönt. Innehållet känns aktuellt både i exemplen och i metoderna, man pratar aktuella designverktyg och agila projektmetodologier.

Det märks att författarna har stor erfarenhet. Boken tar ofta upp sådant som kan vara svårt i arbetet och i kommunikationen med andra projektmedlemmar. Den presenterar ofta många olika arbetssätt och listar för- och nackdelar, många böcker framför bara ett arbetssätt. I metoder för användarresearch presenteras t.ex. sex olika metoder.

A Project Guide to UX Design är som titeln antyder en guide till användarcentrerade projekt, ovärderlig för en nybakad interaktionsdesigner. För den som redan hittat ett arbetssätt man trivs med innehåller den dels alternativa arbetssätt och dels har den en massa bra insikter när det gäller relationen och kommunikationen mellan projektmedlemmar.

Är det något jag saknar så är det kopplingen mellan affärsnytta och användarnas behov, och mer om hur man prioriterar. Effektkartan skulle göra den här boken ännu bättre!

Funktionella krav och interaktionsdesign

Funktionella krav är intressanta. Krav på en produkts funktionalitet. I de flesta projekt jag jobbat med, där man inte haft användaren i fokus, har det funkat så att beställaren dikterar vad som ska finnas med i produkten. Det här kanske stöts och blöts lite i brainstorming-workshops med intressenter, utvecklare och säljare. Sedan sätter man igång med systemdesign och börjar koda. På ett av mina jobb kallades detta arbetssätt Rock ‘n’ Roll.

Resultatet blir oftast en bristfällig produkt full av komplicerade funktioner som ingen använder. Det här känner fler och fler till. Man känner också till att det inte finns någon enkel lösning, någon magisk aktivitet som kan föras in någonstans, utan hela utvecklingsprocessen måste förändras. Inte krav utan behov måste inhämtas från de som faktiskt ska använda produkten och utifrån detta måste produkten designas av någon som både förstår behoven och har en känsla för hur man skapar en bra produkt. En interaktionsdesigner.

Så var kommer traditionella funktionella krav in i bilden?

Funktionella krav specificerar vad en produkt ska kunna göra. Problemet är att funktionerna i sig inte räcker för att produkten ska bli bra. Funktionerna kan utformas på en mängd olika sätt varav vissa är bättre och vissa sämre för slutprodukten. De ska in i ett gränssnitt någon stans och hur de kommer användas kommer till hög grad påverkas av hur de exponeras. En bra funktion som aldrig exponeras för användaren är värdelös.

När man jobbar med interaktionsdesign blir det naturligt att istället för att skriva en lista med krav istället ge sin interaktionsdesign (pappersprototyper, mockups, wireframes eller motsvarande) till utvecklaren. Att skriva en lista med funktionella krav känns bara onödigt, allt finns ju där. Dessutom på ett sätt som är svårare att misstolka. För det är ett annat problem med funktionella krav, de är ofta svårtolkade.

Interaktionsdesignen har även fördelen att den kan förstås av andra än utvecklingsteamet. Den går att diskutera med beställare och – kanske bäst av allt – testas på användare!

Visst, många beställare vill ha hårda fakta i form av en textuell specifikation. Men istället för att skriva en funktionell kravlista utifrån dina designer, försök få dem att förstå att du istället levererar en mer komplett specifikation i form av något de kan titta och känna på.

Lite vidare läsning:

Användbarhet i praktiken: Traditionell kravhantering

Getting Real: There’s nothing functional about functional requirements