Martin Christensen

Martin Christensen

An Agile UX coach who is making sure that we are both doing the right thing and doing it right.

Design Studio – Collaborate towards a shared understanding

Design Studio is a design method that focus on a specific format for collaboration to create a shared understanding of the problem. This is done by, together as a team, coming up with a solid foundation for a design solving the problem.

Here’s the short version:

  • Illuminate – In the first step, the team gets a presentation of the problem and possible boundaries (such as a certain target group or a platform).
  • Sketch – The second step is all about creativity. Let everyone in the team sketch solutions to the problem within a timebox of about 5 minutes. It is important that the sketching is quick and dirty, since giving people time gets them stuck on unnecessary details.
  • Present – In the third step, each and everyone presents their design. A good timebox is one minute per person. When a person has presented, a critique sessions for that particular person’s design follows.
  • Critique – As a fourth step, an open discussion about the design is held. The critique is meant to churn out the key issues with the ideas previously presented and inspire the other members for the next sketching iteration. Try to answer the question: Does the design solve the problem? A good timebox is 2 minutes. The discussion will make everyone think deeper about both the problem and the solution. After the critique, listen to another team member’s presentation until everyone has been given the opportunity to present and discuss their designs.
  • Iterate – Run the last three steps at least 2-4 times. Iteration is the key to finding reliable solutions and getting a shared understanding of the problem.

The overall rule for Design Studio is to never dwell on details to get most value out of the least amount of time. After a Design Studio session, the UX designer, have plenty of material to work with to take the design towards implementation. Try it out in the course Agile UX or read on to find out the details.

read more »

Real Life Mob Programming

mobteam1

Daniel and Martin have been in the same team since the beginning of summer and they’ve been collaborating in an unconventional way. Yassal interviews them to understand what’s been going on.

You’ve been successfully using mob programming with your team at Expressen for the past 6 months. How did you get started?

Daniel: The project started without any tech solutions in mind. We decided as a team that mob programming was a good way to figure out what tech stack to use. We had no backlog, but we sort of knew what we needed to do

Martin: I remember proposing this as the best way to do discovery work from a tech perspective. We didn’t know what language or tech platform we were aiming for, and this way we would learn more quickly as a team and could come to a decision. 

So, what is mob programming anyway?

Daniel: I don’t really care about the formal definition, to me it’s group programming rather than pair programming. One person is at the keyboard and the others act as support, coming up with suggestions, or researching potential solutions. This helps the whole team stay on the same page, and makes sure that we’re all learning at the same pace.

read more »

Kontinuerlig förbättring i det långa loppet – hur och varför?

Hej kära läsare! Mitt namn är Martin och jag är en “process-aholic”. Jag har sett processer (eller avsaknaden av dem) överallt sedan jag var barn. Jag har sett en del människor som gör saker på “fel” sätt och en del människor som gör saker på “rätt” sätt. På universitetet lärde jag mig dock att inte ens när det kommer till processer är livet svart eller vitt, men jag förstod aldrig hur jag skulle kunna särskilja en “bättre” processen från en “sämre”. 11 år senare när jag fann Scrum blev jag glad över att hitta en process med inbyggd processförbättring. Jag kunde äntligen experimentera och sedan utvärdera om det hela blev bättre eller sämre. När jag insåg att de flesta team körde Scrum utan denna del, bestämde jag mig för att försöka lära världen ämnet kontinuerlig förbättring. Detta är ett sådant försök, men det var nog uppenbart…

Vad jag har saknat när jag predikat om tillbakablickar/retrospektiv är tydliga och konsekventa mål. Att nyttja de fantastiska grundvärden som agila metoder vilar på, såsom Extreme Programmings kommunikation, återkoppling, enkelhet och mod (inklusive respekt från version 2) och Scrums öppenhet, engagemang, fokus, etc, har hjälpt mig att sikta bättre på kort sikt. Men det var inte förrän jag lärde mig om två specifika (och överlappande) mognadsmodeller, en via Torbjörn Gyllebring och en via min kollega Fredrik Lingren (tack så mycket till er båda!) som jag förstod hur jag skulle kunna tillämpa en mer fokuserad strategi för ständiga förbättringar. Detta är min strategi:

read more »

Slides från session Agila Arbetsmetoder @ SAST Q20

IMG_5797

Otroligt kul att se hur många som fick plats i ett konceptrum i Aula Magna under våra presentationer under SAST Q20! Vi pratade först om kontinuerlig förbättring och sedan om working agreements. Slides hittar du nedan.

På Crisp har vi en hel del gratis material och guider, bland annat en Toyota Kata mall, som Martin nämnde under sin presentation.

Vi pratade också om Mobprogrammering, och den främsta källan till information finns på mobprogramming.com.

Tack till er alla som kom och lyssnade och vi ber om ursäkt för att alla inte fick plats.

/Martin & Mikael

IMG_5789

Att mäta användarens upplevelse

En av principerna från Lean Startup handlar om att kontinuerligt utvärdera det man tar fram för att veta att det man gör är rätt. Först bygger man något, sedan mäter man det och till sist utvärderar man mätningen för att förstå och lära sig – Build, Measure, Learn.

Build Measure Learn loop från Lean Startup

Vissa saker kan te sig enkla att mäta, andra omöjliga. Men till skillnad från att allt inte kan torktumlas, så kan allt mätas, till och med användarens upplevelse.

read more »

En guide till Minimum Viable Products

Varje produkt börjar med en idé. Det första man behöver göra är att validera den idén och det görs bäst genom att bygga det minsta möjliga som förklarar den idén och gör idén mätbar. Låt oss kalla det den minsta mätbara förhandstitten.

När man mäter så får man data för att kunna avgöra om idén var bra eller inte. Det vi lär oss av att mäta och utvärdera idén kan vi sedan nyttja för att ta nästa steg, såsom en detalj av idén eller en ny idé baserad på den förra, som vi också behöver mäta och utvärdera. Vi vill validera problemet, målgruppen och möjliga lösningar för att vara säkra på att inget lämnas åt slumpen. Detta blir en lärandeprocess baserad på riktiga resultat. read more »

Lean UX & Agil UX – modern användbarhetsmetodik

Grunden i traditionell User Experience (UX, användarens upplevelse av en produkt) består av iterativa användarstudier och interaktionsdesign under krav- och designfaserna, för att säkerställa att produkten kommer att uppfylla användarnas behov och ha god användbarhet. Vi ser till att ta reda på vad vi ska bygga innan vi börjar bygga det. Det finns två huvudsakliga problem med det här (som båda beror på vattenfallsmetodikens inbyggda brister). Dels överlämnas resultatet av arbetet i krav- och designfaserna till utvecklarna i stora och svårförståeliga dokument, ofta bestående av flödesscheman och annoterade wireframes som inte speglar den tekniska verkligheten. Detta rent felaktiga sätt att bygga en produkt leder ofta till att man i slutändan bygger fel produkt. Dels sker oftast leveransen av produkten till slutanvändarna långt senare än det var tänkt och då har marknadsläget vanligtvis ändrats, vilket också innebär att fel produkt levereras.

Agila metoder löser problemet med att leverera produkten snabbt nog. Lean Startup (innovationsdriven produktutveckling) löser problemet med att marknadsläget ändras genom att fokusera på affärsmålen genom hela utvecklingscykeln. Inget av dessa paradigm är dock användarcentrerade. För att möta detta problem har två tankesätt utkristalliserats:

  • Lean UX, där vi ser till att bygga rätt produkt genom kontinuerlig validering mot affärsmålen av det vi bygger just nu och starkt fokus på att lösa användarnas problem
  • Agil UX, där vi ser till att bygga produkten på rätt sätt genom kontinuerligt samarbete runt det vi bygger just nu och fokus på leveransmålen

Venn-diagram över UX, Lean UX och Agil UX read more »

Designprinciper

Jag läste en artikel om User Experience (användarens upplevelse av en produkt) häromdagen. En person hade kommenterat texten med den väldigt vanliga kommentaren om UX. Han sa att “allt vi behöver göra är att låtsas vara en användare och utvärdera vad vi har byggt ur den synvinkeln”. Detta håller jag tyvärr inte med om. Vi är alltför partiska som produktdesigners och utvecklare, vi känner till för mycket om hur produkten fungerar. Dessutom tillhör vi troligast inte den avsedda målgruppen, vi kommer inte att använda produkten i en faktisk situation för att lösa ett faktiskt behov, så det kommer bli mycket svårt för oss att låtsas tillräckligt.

Men vad vi kan göra är att luta oss tillbaka på forskningsresultat som kan appliceras på de allra flesta människor och därmed de flesta av våra användare. Dessa resultat kallas designprinciper och med deras hjälp kan vi lyfta vår produkt upp till en bättre nivå. Detta är det minsta du kan och bör göra för dina användare. read more »