Skip to content
the obstacles that prevent us from getting to the UX outcomederived from the current user journeyused to come up with a bunch of solutions to build that will bring us closer to the outcome (if the solution doesn’t work it informs the problem for a new iteration).
Performance Payoff: Measures the value that comes from investing in new product features.Basic Expectations: Measures the value that comes from ensuring the product meets expectations.Excitement Generators: Measures the value that comes from adding unexpected features and capabilities.
Functionality goes upComplexity goes upExperience goes down.
It’s very expensive to miss basic expectationsMeeting basic expectations gives us, at best, neutral satisfaction: nobody’s going to talk about how wonderful the file system is in your design tool, they’ll just get very angry if you don’t have one.
Pleasure: exceeding expectations. It’s the opposite of missing expectations. Something does a bit more than you expected, or in a slightly better way. Pleasure it’s the cheapest excitement generator to achieve, but it’s also the easiest to copy.Flow: optimising time, e.g. making something that currently takes 30 minutes only take 5.Meaning: you can make things delightful if you give them some extrinsic meaning, e.g. by using this product I’m making someone else’s life better. Meaning is the harder excitement generator to achieve.
Inspire your Agile teams with what users truly need
In the process of being as fast and efficient as possible, Agile tends to break any connection with the user.
We need to make sure that every developer understand how each user story fits into the bigger use, and that communication is not going to happen inside the user story / Jira ticket.
User stories have to come directly out of research. They can’t come out of just guessing what user needs. Pretending to be the user (“I, as a hiring manager…”) is a fake empathy thing we engage in, if we have never met the user. We have to have the research. If we have actually met a hiring manager named Tara, we can actually say “Tara want to create a job listing”.
User stories have to represent the difference between the current experience and the delightful one, but we can’t rely on traditional user story format to embody current and delightful journey. We can’t rely on user stories to tell us what the background is, therefore it’s natural for developers to struggle with delivering something that’s helpful, because we’re not including that anywhere.
You need to know where you’re going in order to have this conversation. That’s why we use .
We need to make sure that everybody on our team is aware of current user journey, aspirational user journey and UX outcomes.
The problems to solve are:
The core of our Sprint must be about understanding the problem to solve and the solutions, which means that the user journey must come from research that we do upfront.
Continuous research is better than one-off discovery research because informing the problem over and over and over in the end will help us build solutions that are more innovating, more industry leading, solve problems in a way that nobody else is doing and, most importantly, is delivering value to our users and customers.
Deriving problems to solve from the Kano model
We can derive problems to solve from the Kano model.
The Kano Model asks the question: How much investment does it take to make customers delighted?
It's a two-dimensional model. On the horizontal access is investment (from low to high). On the vertical access is customer satisfaction (from extreme frustration to extreme delight).
There are three trends that Kano noticed when putting together the model.
Performance payoff
The theory is that every time you add a feature you make things more valuable. But that’s not how it works. At some point you start seeing a dip that comes from excessive complexity. The more things you add, the more complex it gets if you don’t do something about it, or you’ll get experience rot:
You want to control complexity by being very careful and judicious about what you add into the product as well as going back and refactor existing things so that you’re not just adding things, but you’re actually think about flow and product organisation.
Basic expectations
Our users have basic expectations when they come to the products. Invision Studio failed because it didn’t have a way to group things into different projects. They missed basic expectations.
Therefore, we have to make sure that we understand basic expectations.
So many of users’ frustrations happen because their basic expectations are not met.
Excitement generators
Excitement generators come in three ways
With our research we need to understand, and make sure that everybody on the team understand, what’s the nature of the problem to solve - basic expectations, performance payoff or excitement generator - because the way of solving each one is very different from the others.
We need to make sure that everybody on the team is completely aware why they’re building what they’re building. If we pull that off, it gets really exciting. This is the number 1 thing that makes the Agile process drudgery for them: they don’t understand why they’re doing what they’re doing, if they’re either fixing a debt that was caused by missing expectations, or improving the experience by making things more delightful, or reducing complexity and building a product that is effective but not overwhelming. They need to have that connection, and they need to see in terms of the definition of “done” that they have accomplished that.
If we manage to do those things, we get a more rigorous and delightful experience, and it is game changing.
Conclusion
We started by reframing and saying that we’re going through a transformation where we’re putting together Agile and UX. We do that by:
We bring it all together by investing in expanding our research capabilities, to the point that potentially we reduce investment in design, because many time we invest in design to compensate lack of research. If we can bring the research to a head a give it exposure to everybody in the team, they’ll understand why they’re building what they’re building.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.