Skip to content
toolsskillsmindset.
losing salessupport costtraining costproductivity costdamage control costproblem escalation costproducing features that nobody usesrebuilding features because we got them wrong the first time
The mindset shifts your stakeholders will need for successful Agile UX
Significant change has to happen in three ways:
This lesson is about mindset change.
The mindset change must happen not only for us, but also for our key stakeholders, because that’s key for a strategy to work.
If our strategy is to make Agile and UX more integrated, more unified, then we have to make sure we have the right mindset changes across anybody makes decisions that influence the user experience: people who have “UX” in their title but also the influencers: people who influence the UX but may not even be aware that their decisions have an impact on the user experience. For example the people who chose to use Agile in the first place, the people defining the teams, their skills and compositions, etc… If those people decide to hire people that know about UX, then we’ll achieve a better UX than if we hired people who don’t.
5 key mindset changes
These are the most important things we need to makes sure people understand the changes we have under go. If they understand these things, they are more likely to help us succeed.
It may take months or even years. We’re influencing change across a large group of individuals, and that never happens quickly. That’s why we pick long term outcomes - 5 or 6 years in the future - and focus on getting buy in for those outcomes, and getting there with baby steps. If we do this, we also gain some resilience, because we don’t need to get things right the first time: we can make mistakes, learn and recover.
1. Transformation to Agile UX and proactive UX - is a long term thing.
Agile is perfectly designed for this: sprints are meant to make us see what we can get done and what we can learn in 2 or 3 weeks. The goal of a sprint is not to squeeze all the work in 2 or 3 weeks: it’s to break things up, take a step back and asking “how did we do?”, “did we get to a right place?”, so we’re sure that we’re going in the right direction. This process has to support the long term goal, not the other way around. We figure out the long term goal and then take baby steps towards it; we don’t just make random baby steps. The process must support our goals, instead of the the goals supporting the process. We must use the goals to understand what our process should be, and what’s not working in our current process. The sprints serve the vision, not the other way around.
Any Agile UX implementation that doesn’t support the vision, isn’t helping us. Every sprint must take us closer to the vision. We may make mistakes but then we must be able to recognise that we did something that didn’t take us closer to the vision.
In the planning session, the things that bring us closer to the vision have to bubble up at the top, be more important than the ones that aren’t. It must be part of our prioritisation system.
In the retro, we must ask “Did we get closer to our long term vision?” If not, then the sprint was not a success, and we must ask ourselves what we did wrong and what we need to do different.
2. UX research is absolutely central to Agile UX
This is a very hard change for a lot of teams that have the idea that “they can’t afford research because it takes too much time”. That’s like saying that you can’t get organised because getting organised takes time, even though the reason why I’m wasting time is that I’m disorganised.
It is very likely that we’re underinvesting in research. Very few companies invest the right amount in UX. But it’s not a luxury, it’s something we constantly have to be investing in. Research is actually a better investment than design and development. It’s the best investment we can make, because if we do it right, we will shorten the design and development efforts. Those things are elongated because we don’t know why we’re building what we’re building, we don’t know what are people’s problems. UX research is what tells us how to improve people’s live, what to do next.
At the core of UX research there’s the idea of exposure, the amount of time everybody on the team gets in front of the users. The higher the exposure, the more we are likely to succeed. We need to make sure that we produce enough research.
2 hours of exposure for each team member every six weeks - 20 minutes per week - is the bare minimum. If you’re doing less than that, you must make changes to reach that threshold. If you reach that threshold, people start applying their knowledge to their work, to the decisions they make. It will cause a dramatic improvement in the quality of the designs delivered by the team. User stories will start to make more sense.
3. Research should be continuously ongoing
Research is all about growing our understanding, and we will never feel we’re out of research, because the more research we do, the more we understand our users and their problems.
We need this inversion: research doesn’t happen in a sprint, and is not little part of a project. It happens in different sprints so we can give knowledge to our teams whenever they need it, at the right moment.
Research planning looks ahead: we should be able to predict stories. We should be able to define the participants for a research way before a sprint happens. We should make sure team members have the information they need when the sprint happens.
The two hours every six weeks is just the minimum: we need to build a continuous research system where every day there’s new research, every day there’s opportunity for the team members to join into that research when it’s relevant to them, when it can have an impact on the decisions that are about to be made. That’s how you get exposure up.
When research becomes proactive we can then work with senior stakeholders to identify key risks. We use the research to help the executive leadership reduce risk, reduce uncertainty, and when we do that, research becomes strategic: they’ll see it as something they can’t live without because it changes their ability to be confident and mitigate key issues.
Research is key to the three facets of our transformation to Agile UX: prediction, collaboration and learning.
If we have key stakeholders that are against research, we must track the cost of not doing research. Poor UX always ends up costing the organisation somewhere:
The more we’re able to track those costs, the more we’re able to show the value of being able to mitigate those costs, which is what research gets us. It’s a less expensive investment that paying for all that UX debt. UX debt and technical debt are one and the same, and we can mitigate almost all of them with UX research.
4. Human needs must be in the definition of done
This is where UX outcomes helps us, by asking the question “If we do a really good job at this, whose lives will we improve?” Everything we do must be focused on this. As UX leaders we have to bring everyone to the mission of why we’re doing the things we do, because nobody else in the organisation will do it.
By setting our criteria on actual use - again, coming out from research (if you struggle with coming up with UX outcomes it’s because you don’t do enough research) - then we have specific criteria for the definition of done.
5. We have to make the UX skills of the entire Agile team a priority
We don’t hire people who can’t write, do math, or speak clearly. We shouldn’t hire people who can’t do basic UX, because it affects everybody’s job. Everybody should be able to do the very basic: basic UI, basic prototyping, basic research. They don’t need to be the world’s best designers, but they can know more than the average graduate of any 11-week bootcamp program.
We must makes sure we hire and train people with those skills. Train must be done with , like pair designing with a developer, or bring people in a research session and research analysis. They can learn how to iterate on a design based on the research they just did. It must not feel like training.
We must be talking all the time about what works and what doesn’t, what made an improvement in our designs.
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.