Skip to content
juni 29, 2011 / Dan Kindeborg

Lärdomar från ett agilt UX-projekt

Jag avslutade nyligen ett webbprojekt där vi jobbade enligt projektmetodiken Scrum. Tidigare har jag berättat lite om hur vi arbetade. Den här gången kommer det handla om lärdomar jag tar med mig från detta projekt till nästa.

Designa för nästa sprint, inte längre

UX-nissen (jag) arbetade med interaktionsdesign för nästa sprints funktionalitet samtidigt som utvecklarna implementerade nuvarande sprints funktionalitet, vilket fungerade bra. Men ofta blir frestelsen att designa för senare sprintar för stor. Resultatet blev att det ofta fanns interaktionsdesign färdig för senare sprintar vilket blev problematiskt. Dels hade mycket av den designen inte behövt göras alls eftersom den senare prioriterades bort. Dels flyttades fokus från det viktigaste, nämligen nästa sprints design.

Anders Ramsay har skrivit om design på rätt nivå här

Kommunikation med utvecklare – User stories på rätt nivå

Utvecklare är olika. Vissa kräver väldigt detaljerade User stories och tycker ”GUI:t” ska specificeras av någon annan. Andra har inga problem med att göra grova estimat baserat på något luddig och är duktiga designers som gärna är med och påverkar.

I det här projektet lät jag mig påverkas lite för mycket av den första typen. Resultatet blev User stories som var väldigt detaljerade. Det ledde till att utvecklarna i vissa fall slutade reflektera över vad de implementerade och det finns ju alltid rum för feltolkningar i textuella specifikationer så i många fall blev det fel. Vi försökte lösa problemet genom att införa en princip. Innan man börjar implementera en User story ska man alltid ta en diskussion kring den med UX-nissen. Det gjorde saken bättre men jag tror man skulle vunnit på att hålla nere detaljerna och ta den detaljerade interaktionsdesignen i diskussion med utvecklaren. En User story ska ju trots allt inte vara något mer än en överenskommelse om ett framtida samtal.

Alltså: De svåra och övergripande delarna av interaktionsdesignen, t.ex. navigationsmönster eller auto-completion, förbereds. Detaljerna, t.ex. exakt hur en formulärvalidering ska ske, tas fram i samarbete mellan utvecklare och designer innan utvecklaren börjar implementera User storyn.

Anders Ramsay har skrivit om kommunikation i agila projekt här

Testa ofta

Tanken var att vi skulle göra ett användningstest varje sprint, och sprintarna var tre veckor långa. Testerna gjordes på föregående sprints resultat (implementerad funktionalitet) eller designskisser och skedde oftast i början av sprinten. Här fanns två problem. Dels var det svårt att få tag på testpersoner, dels var trögheten stor. Det tog ju tre veckor att utveckla en funktion, tre att testa och sedan tre för att implementera en åtgärd.

Man skulle kort sagt testat oftare och mer. Usabilla publicerade nyligen en artikel om testning i agila projekt där det pratas om att testa varje vecka. Man låter en dag i veckan vara test-dagen och gör testerna tillräckligt begränsade för att klaras av på en dag inklusive förberedelse, åtgärdsförslag och allt. Det låter inte helt dumt.

Bestäm en formell produktägare

I mitt projekt fanns ingen formell produktägare, vilket var ett problem. Jag var oftast den tillgängliga resursen som hade bäst koll på funktioner och prioriteringar. I praktiken var jag som UX-nisse produktägare men ibland när diskussioner uppstod kring designdetaljer tyckte utvecklarna inte att jag hade tillräckligt mandat.

Det bästa hade varit om beställaren alltid hade haft en respresentat tillgänglig och det funnits ett produktägarteam bestående av den personen och mig.

Förmedla visionen till teamet

Det är viktigt att hela teamet kan skriva under på att projektmetoden och projektets riktning är bra. I det här projektet var det inget större problem, de flesta utvecklarna var väldigt intresserade av användarna, efter varje användningstest bombarderades man med frågor om hur det gick och vad man kom fram till.

Vi satte upp bilder på Personas och på Wire frames i rummet vilket jag tror hjälpte. Men effektkartan som togs fram i förstudien hamnade lite i skymundan, jag tror man skulle kunnat koppla till den oftare för att ge en ännu tydligare bild av målgruppernas och det övergripande syftet med projektet.

Hugg i där det behövs

Oavsett om man är utvecklare, testare, projektledare eller UX-nisse är det bra att kunna ta arbetsuppgifter man inte normalt har när det behövs. Speciellt i ett agilt projekt är det en grym fördel. När man arbetar inkrementellt blir det naturligt att vissa sprintar är extra test-tunga, andra innehåller mycket front end-utveckling o.s.v. Jag tror speciellt vi som pysslar med design på olika sätt tjänar på att testa eller utveckla lite, det kan finnas fördomar om att vi är snobbiga och vägrar göra något annat än design.

Dessutom blir alla gladare när folk hjälps åt, bra stämning är viktigt!

Fler lästips

Integrating UX into agile development – UXMatters snillen spekulerar kring agil UX. Innehåller även en massa bra länkar.

Conference review: IA Summit 2011 – på IA Summit 2011 handlade mycket om agil UX – kolla t.ex. resultaten från workshopen där ett agile UX manifesto skulle tas fram!

Anders Ramsay – har skrivit en massa bra om agil UX

Ha en skön sommar!

About these ads

4 kommentarer

Lämna en kommentar
  1. Karin / Jun 29 2011 21:24

    Att visualisera saker genom wireframes,personas är så effektfullt, genom att sätt upp dessa på väggen gör man dem synliga för alla i gruppen och det är lättare för att förstå en bild. Håller med dig gällande user stories, vissa utvecklare vill nästa ha något som liknar en serie tidning men med andra kan man lägga mindre fokus på detaljer. Det är ju lite galet att vi UX /id folk lägger ner massa tid på att speca för att det verkligen skall passa utvecklarna vi borde lägga mer tid på designen.

  2. eric idebro / Jul 1 2011 07:19

    Karin: jag tycker att designen i stor utsträckning (eller kanske helt och hållet)är ett kommunikationsverktyg och försöker anpassa den efter mottagaren. En utvecklare vill ha en snabb blyertsskiss, ok. En annan vill ha en klickbar och annoterad html-prototyp, det är lika ok. så länge slutresultatet blir bra.

Trackbacks

  1. Lean UX is amazing « Helt sonika
  2. Design i agila projekt – dags att börja spela rugby? « Helt sonika

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s

Följ

Få meddelanden om nya inlägg via e-post.

Gör sällskap med 35 andra följare

%d bloggers like this: