Now Lean is a UX methodology, the focus is on quickly concepting and visualizing key components in front of your team and users, and iterating on the design. If you’re working with an Agile team, this can mean UX and development working side by side during a sprint. But, as Jeff points out in his article, the concepts of Lean UX can be applied to any development style.
So here’s our overall development process: Defects and feature requests can enter our system from almost anywhere. Many come from customer service, responding directly to customer requests. Others come from sales, marketing or development. All of these defects and feature requests are added to our Agile tool. Feature requests are translated into the form of a user story, although at this point we just want it in the system, so we’re pretty loose with the criteria. What product management wants in these situations is to identify a comprehensible user need. There does not have to be any implementation path inferable from the user story.
Once every two weeks, business stakeholders meet to process new items and to review the priority of the backlog. (This is our product council and it includes executives, customer support, marketing, UX and development representation.)
The outcome of this process is a prioritized backlog of user stories.
UX then takes the top story on this list (or more than one, depending), and prototypes, decomposes, and works to get a full understanding of this story. UX shares prototypes with the developers who will ultimately be responsible for implementing the solution to get their input and perspective. If the developers are in mid-sprint, this collaboration may just be with the manager, but typically responding to the prototypes is no more burdensome than responding to email. The original business stakeholders also have visibility into this process. They can see the prototypes, and the UX pro can pull them in at any time to view prototypes and ask for clarification.
The End User is there
End user testing is frequently part of this process too. For our team, end user testing usually happens after one or more iterations involving the internal team. The prototypes and feedback from executives, sales, customer service and developers, as well as end users, are all linked to the user story or stories in the backlog. When the product council reviews the backlog, they can take this information into account in deciding the priority of each of these features. After UX exploration, user stories might have their priorities dropped, or other stories might come in that are higher priorities, and UX will begin work on those items. In effect, UX goes through a series of 2-week sprints to elaborate and explore user stories.
How does UX know that they are done? Well, assuming that product management keeps the user story as top priority in the backlog given the newly developed prototypes and discussions, development tells them.
Developers, developers, developers
Developers package sprints based on the backlog. The backlog now includes user stories, prototypes and discussions about a feature. Developers have been involved in creating these artifacts (even if only for feedback), so they don’t get any surprises, and it creates a feeling of shared striving.
Our developers move the top priorities from the backlog into a sprint-ready bucket. If items haven’t been adequately explored, the questions or issues are raised to the UX team.
Sprints are then packaged from items in the sprint-ready bucket. In general, these sprints are highly efficient. The issues raised are clear, well thought through, vetted by end users, and developers are already familiar with the issues.
But collaboration does not stop just because a user story is placed in a sprint. Just as UX could request feedback from developers on user stories in progress, now it’s development’s turn to seek feedback and clarification from UX. Developers always uncover issues not considered by business or UX, because the lens of implementation has many additional considerations. Our developers sometimes modify the existing prototypes, ask questions regarding existing prototypes, make new prototypes, prototype in code, or actually develop a solution, make it available through the nightly build, and then request feedback. End user testing can also occur on actual, potentially releasable code. One thing to note – if end user testing reveals something critical, it’s much more difficult (and expensive) to turn the ship at this point. The UX sprint is more agile than the Agile sprint.
I’ll admit, UX has a tough job, and it is really the fulcrum of communication. While it’s usually adequate for developers to give quick feedback during the UX phase, UX frequently has to dig back in during the sprint. They may have to adapt existing prototypes, create new proposed solutions, vet changes with end users, and vet changes with up-stream stakeholders. The goal for UX is to help developers minimize rework. It’s up to UX to choose the most efficient path to vet and clarify solutions, so that once the developer builds the feature, changes are minimized.
Here are the basic steps and the primary groups responsible.
Propose (everyone) → Prioritize (Business) ↔ Explore, Test, Validate (UX) ↔ Build, Test, Validate (Dev) ↔ QA (QA) → Deploy (Ops)
So is this Lean? In Jeff Gothelf’s article on Lean UX, he includes an image describing the Lean UX process. The basic steps outlined are “Concept → Prototype → Validate Internally → Test Externally → Learn from User Behavior → Iterate.”
Given this definition, I’m going to say yes, we’re Lean. What’s interesting is that our process involves both a shadow-sprint (a pre-development UX-only sprint), as well as embedded UX and development. What I like about the shadow-sprint is that you’re not constrained by the sprint timing and that you don’t suffer from a UX-Dev impedance mismatch (where UX and development tasks take significantly different amounts of time). What I don’t like about the shadow-sprint is that it is more difficult to keep developers engaged in the solution and to create the shared understanding that I’ve beaten to death in my articles. Embedded UX makes the shared understanding possible, but keeping everyone busy and working at the maximum velocity can be much tougher.
Are you Lean? Has your organization been trying to implement lean principles? What are you finding? What works and what doesn’t. I’d love to hear your experiences.