As organizations of all shapes and sizes come to grips with the fact that UX is critical to project and product success, a common question resurfaces time and again:
“How do we add Lean UX practices to our current process?”
When I hear this question, I know that what’s really being expressed is concern, and in some cases, fear. What they really want to know is how can we do this without screwing up the way we do things now? In some cases, that’s a legitimate fear. Companies whose agile development processes are well-managed and well-executed are understandably reluctant to add anything new to the mix. Any change brings difficulty, and the simple fact is that there is no way to add Lean UX to company culture or process without experiencing some bumps in the road.
That said, there is most definitely a way to minimize the disruption and get past those speed bumps quickly. Adding Lean UX practices into an agile process successfully can be a complex process, and the specifics change depending on the organization, the project and the deadline. However, in my experience the are are 4 truths, 4 pieces of advice that apply to any situation.
1) Hire experienced UX analysts and designers; you need at least one experienced, senior UX member capable of sharing the driving.
Ideally, they need to be part of your team as early in the process as possible. Meaning when you’re scoping the project, they’re at the table. They should be sitting side-by-side with your Agile Customer Team or Product Team. They need a voice and a vote when you’re meeting with the client and still pitching or planning project strategy. These people should be helping you decide the overall business strategy that determines why you’re building this, what you’re building and why it matters, to both the business and your end users. They should be collaborating with the development teams (front end, mid-tier, back end) to prioritize the tactical work that gets done. They should have an active role in deciding what collection of features gets released first, next and beyond in each iteration.
The ability to do all of that quickly, efficiently and effectively comes with experience. Expecting a first-year UX designer to lead the charge is something I see all too often. While they are more than capable of executing in the areas I mention here, they don’t yet have the experience of leading the charge, and they don’t have an understanding of just how many moving parts and points of influence there are in a large enterprise project. So no matter how many people are on the Lean UX team, everyone will be better served if at least one of them already has deep roots in Agile or iterative development.
2) There must be an “Iteration 0” in your process where “just enough” research, modeling and design happens. Lean UX only adds value if the UX team is inserted at the outset of the process. So at the same time your project team is doing their research and planning, your UX folks should be doing upfront user research and modeling. The output of that work is typically personas, use scenarios, workflow models, information architecture and the like. Experienced UX teams can do this work both thoroughly and quickly, because they know what matters most and what can wait. A team truly practicing Lean UX will:
- Be ruthlessly aggressive in prioritizing user types, spending time on those who represent the most value back to the business.
- Use non-formal methods to model user profiles, use scenarios and information structure quickly, making sure to collaborate with their development counterparts team throughout the process in order to validate the feasibility and viability of these approaches.
- Defer any and all less critical research, analysis and design while the software is being built.
This work needs to happen in days and weeks, not months. In my experience, the most opportune time for the UX team to be doing this work is when the project team is still staffing and scheduling resources. In addition, when the development environment is being setup and ready to go, a Lean UX team has ample time to ideate some high-level design in terms of information architecture and workflows.
3) Follow a process where UX, design and development work is “chunked” and starts with the core, most broad-reaching areas of features and functionality.
If Iteration 0 is executed properly, your entire team should have a high-level roadmap of what the functionality of the software will be. From the project manager to the development team to the Lean UX team, everyone knows what the core user stories are and there should be no guessing. I’m talking about the areas of the app or site or software that represent the majority of use. The workflows that include the majority of user interaction, navigation and data input/output. Scenarios where those that follow are likely to re-use some of these same flows, patterns and even controls and elements. The details of smaller, more granular workflows may be unknown, and that’s OK.
You certainly have to break down the system into small parts. But it’s critical that the parts you tackle first be those where you can re-use the majority of the interaction patterns, design decisions and functional code in the chunks that follow. You may not know how the story ends, but you are intimately familiar with the plot line, the characters and the intended outcome. This is the only way to ensure that UX and development remain reasonably in sync for the duration of the project.
4) Use a collaborative, parallel work process to keep UX efforts both ahead and behind development efforts.
We typically hear that UX teams should be working one to two sprints ahead of development, researching and designing what will be built in future sprints. There’s a little more to it than that. What really needs to occur is that there is a collaborative cycle between the Lean UX and development efforts, which looks something like this:
The UX team is doing something akin to time-travel, moving from the future to the present to the past within each iteration or sprint. In each iteration, they are:
- Reviewing and validating the work from the previous sprint with stakeholders and users
- Acting as a sounding board for development, guiding and supporting work being done in the current sprint
- Researching and analyzing to determine what work needs to happen in upcoming sprints
- Validating that analysis with the development team in terms of viability/feasibility.
As I said earlier, every situation is different, and there is certainly more to consider. But these 4 guidelines should give you a clear blueprint for how Lean UX and Agile development teams can work together efficiently and effectively.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
If you’d like to get more advice from me every month on UX, UI and Product Design + Development topics — in the form of training videos, full-length courses, e-books, downloadable templates and more — check out my NEW online school, the UX 365 Academy. Every month I publish new content, and you also have access to every course, book and training video I’ve ever created — some of which have never been published online before now.
