Continue reading: UX – It’s obvious, right?: Part 3

UX – It’s obvious, right?: Part 3

In the talk I gave at Agila Sverige in June, I brought up misconceptions about UX I’ve encountered during my years in the IT business. One of these is that it’s only the UX people (and possibly the PO) who need to meet the users. In this post I’ll discuss why this not true, but also how meeting the users can make a real difference in focus and motivation for the team.

It's not only UXers who need to meet the users!

Continue reading

Continue reading: UX – It’s obvious, right?: Part 2

UX – It’s obvious, right?: Part 2

In June I gave a talk at a conference about things that I, as a UX professional, find obvious that I have noticed that others don’t. After giving the talk, I decided to also put it down in writing as a series of blog posts. This is part 2 of that series and talks about that even if you hire usability experts, they still need to meet the users.

Continue reading

Continue reading: UX – It’s obvious, right?: Part 1

UX – It’s obvious, right?: Part 1

I did a talk at the local conference Agila Sverige in June about things that I, as a UX professional, find obvious about UX, but that I have discovered that other professions might not. I actually felt really nervous giving the talk, because I feared that I had been mistaken and the things actually were obvious to everyone. I needn’t have worried…

Continue reading

Continue reading: The Minimum Loveable Product

The Minimum Loveable Product

I recently attended a course (the excellent LeanUX course held by my colleague Martin Christensen) and again the topic of what a MVP is or is not came up in a discussion. In the Lean startup-world an MVP is defined as the smallest thing you can make to validate a hypothesis which helps you decide if you should continue developing something or if you should stop. For more information about this, I suggest you read Eric Ries’ blog post on the topic. However, in (very) many companies and organisations the term is used to describe the first version of a product released to the end customers. This “version one release MVP” usually contains as little functionality and features as is possible without making the end customers too upset, disappointed or unwilling to pay.

Another colleague of mine, Henrik Kniberg, wrote a quite thorough and lengthy blog post about MVPs a while back where he touched upon the point I’m about to make. While quite a few people see the different uses of the word MVP as problematic, I see it as a symptom of a need for a better word for describing at least one of its currently used meanings, i.e. the “version one release MVP”. Luckily enough a good friend and coworker gave me the answer to that need a few years ago: He called the first release of the hardware product we were working on at the time the “Minimum Loveable Product”.

Continue reading

Continue reading: Guest blog by Anders Ramsay – Finding Agile UX Nirvana with the One-Feature Release

Guest blog by Anders Ramsay – Finding Agile UX Nirvana with the One-Feature Release

This is a guest post from veteran Agile UX coach Anders Ramsay who’ll be visiting Crisp in March.

In a traditional UX practice, there tends to be a strong focus on whole product design.  In other words, we want to integrate all the features of a product into a unified and coherent experience, before we can consider the design work to be done.

Big Design Up-Front is like growing a tree in a “wireframe nursery” before planting it in the real world of working software.

But if you are taking this approach in designing the user experience, and you’re also part of an Agile team, then that might be a major reason why you’re struggling to integrate your UX practice into an Agile model.Continue reading

Continue reading: Lean UX & Agil UX – modern användbarhetsmetodik

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 UXContinue reading

Continue reading: Dyr lärdom från PUST: hur undvika nya IT-fiaskon?

Dyr lärdom från PUST: hur undvika nya IT-fiaskon?

2010-2011 gjorde RPS en bra grej. De byggde ett system (Pust Java) som gjorde polisen mer effektiv. Poliserna fick datorer i sina bilar och kunde direkt registrera brott. Därmed behövde de inte åka in till stationen för att avrapportera lika ofta som med gamla systemet. Systemet var skräddarsytt för att ge hög användarnytta, och projektet blev en framgång. Pust Java blev finalist i CIO awards “project of the year 2011” och DN skrev en helsida “Polisen rapporterar betydligt snabbare med ny metod“. Systemet var inte perfekt, men en bra start. Poliserna sa att det var bättre än vad de hade innan, och folk var optimistiska inför systemets framtid.

Sedan hände något tragiskt. Istället för att vidareutveckla och kontinuerligt förbättra systemet, så valde ledningen att skapa ett nytt system från grunden (Pust Siebel) med undermålig teknik. Det blev ett fiasko. Ursinniga poliser klagade på att en avrapportering kunde ta flera timmar – “Pust Siebel gör en helt frustrerad och på gränsen till vansinnig!” – och saknade det gamla systemet. RPS hamnade i ett mediadrev. En poliskälla uppskattade samhällskostnaden till 10 miljarder kr!

Efter massiv kritik från både media, poliser, skyddsombudsmän och oberoende aktörer med insyn i projektet, beslutade RPS att lägga ner Pust Siebel.  Nu är det allt fler som förespråkar att Pust Java återinförs

Varför spenderar en myndighet hundratals miljoner på att bygga något bra, för att sedan spendera ytterligare hundratals miljoner på att byta ut det mot något dåligt? Ännu värre: varför gör man detta trots att hela IT-avdelningen visste, och högljutt påpekade från början, att det nya systemet skulle bli sämre?

Syftet med denna artikel är att belysa och sprida lärdomarna, så andra företag och myndigheter slipper göra om liknande dyra misstag.

Continue reading

Continue reading: Designprinciper

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.Continue reading

Continue reading: Slides from Dare – “Visualization, what’s my brain got to do with it?”

Slides from Dare – “Visualization, what’s my brain got to do with it?”

Just got back from DARE conference in Belgium.  I don’t know how Maarten makes it happen, but I always leave with more ideas than I had when I came. I ran a session on visualization – highlighting our brains limited capacity capture and record knowledge (and what to think of when using visualization). An amazingly

Continue reading
Continue reading: How to build the Right Thing

How to build the Right Thing

The software industry is going through a shift of mindset.

Agile basically solved the problem of how to deliver software. Most any company that applies an agile method and mindset can get working software out the door. Now, the biggest waste in software development seems to be building the wrong product, or the wrong features.

“There is surely nothing quite so useless as doing with great efficiency that which should not be done at all” -Peter Drucker

This insight has given rise to methods and techniques such as Lean Startup, Impact Mapping, Story Mapping, Feature Injection, etc. But is there a common denominator, a set of underlying principles?

On Feb 11, Gojko Adzic organized a full-day meetup in London with people deeply engaged in this issue, people like Jeff Patton, Mary Poppendieck, Ingrid Domingues, Chris Matts and others who have been inventing and spreading techniques for dealing with the how-to-build-the-right-stuff issue.

It was a very inspiring day! We compared our different approaches and experiences, extracted the core principles, and (to our surprise) managed to condense it into this shared message:

Great results happen when:
1. People know why they are doing their work.
2. Organizations focus on outcomes and impacts rather than features.
3. Teams decide what to do next based on immediate and direct feedback from the use of their work.
4. Everyone cares.

There. So now just go do it! 🙂
Actually, if you want a more detailed description of each point see Gojko’s post.

Posts from the other participants:

Full participant list (in no particular order): Gojko Adzic, Mary Poppendieck, Gabrielle Benefield, Tom Poppendieck, Gordon Weir, Henrik Kniberg, Jeff Patton, Ingrid Domingues, Karl Scotland, Russ Miles, Christian Hassa, Dulce Goncalves, Aaron Sanders, Shadi Almviken, Chris Matts, Olaf Lewitz and Matthias Edinger.

Continue reading