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.
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.
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…
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”.
Help your team improve by visualizing their way working with the fluent@agile game. With the game you can help a team find out where it is on its agile journey and help it find new ways of both fine tuning and make leaps in their daily agile practices.
Me and Christian Vikström made the game together at Spotify during the spring 2014 when we were coaching and helping team to improve their agile skill sets and processes.
At Spotify the teams owns their own way of working. A team is basically only accountable to itself. We therefore needed an coaching tool that could help team take ownership of their self image and improvement strategy.
We also wanted the tool to be opinionated. It should be normative, tell what’s good and not, what kind of practices and behaviour that’s expected and not. But at the same time it should be open to new ideas, new practices and the teams local conditions.
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
Back in undergraduate school I had an artsy roommate who quickly dropped any intention of attending classes. Soon thereafter he picked up a line cook job at the local diner and took on a nocturnal lifestyle. That lifestyle led to a whole new set of friends who quickly helped him develop a recreational drug habit. To support his new found hobby, my roommate began dealing to his new found comrades and their acquaintances. The temptation of having all of that product around him turned out to be too much though and, soon enough, he was consuming more than he was selling leaving him increasingly in debt to his suppliers. This culminated in a day I’ll never forget. I had to take him to the pawn shop so he could trade his car (his last possession) for cash to get out of that debt. We rode home on the back of my motorcycle (which became our only means of transportation for the duration of our cohabitation).Continue reading
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
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
Our human brain is way better interpreting visual information (images) than any other information. Evolution taught us to survive this way. Yet, still today, the most common form to deliver requirements is … text. In the old waterfall days it meant a lot of text, today using Agile slightly less text, but still, text. If we do it well we back it up with a conversation.
Let’s look at an Agile example, using the “As a..” syntax:
“As a buyer, I would like to buy a pair of shorts, so I can go running.”
This is a guest blog from Jeff Gothelf who will have an open course in Lean UX with Crisp in May 2013
Jeff Gothelf has spent a 15 year career as an agile product designer, team leader, blogger and teacher. He is one of the leading voices on the topic of Agile UX and Lean UX. In addition, Jeff is the author of the O’Reilly book (2013), Lean UX: Applying lean principles to improve user experience (www.leanuxbook.com). He is a highly sought-after international speaker and workshop leader. Jeff has led cross-functional product design teams at TheLadders, Publicis Modem, WebTrends, Fidelity, and AOL. In 2012, Jeff launched Proof, a product design and innovation studio that combines lean processes with strategy, design and technology that has since been acquired by Neo.com where he is now Managing Director.
Lean UX in the Enterprise: 5 hills to climb
Expanding my original post on challenges implementing Lean UX in the enterprise, I wanted to add a couple more hurdles that most companies will undoubtedly have to go through to build, collaborative, cross-functional and agile teams.
Co-location is a dirty word
Many large companies are distributed across countries, time zones and cultures. Getting employees to work together is tough enough when they’re sitting across the hall from each other. The distance between distributed teams breaks down a collaborative culture very quickly.Continue reading
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: