This is a guest post I did for UserZoom.com, and I am reposting it here.
Several years ago I attended a presentation on Agile and UX at the Agile Australia conference, and about ten minutes into the talk I started twitching.
The two UX folks on the stage were the worst example of user experience practitioners I’d ever seen: Academics. “If I could, I would do user research forever and never design anything,” one of them said, and my twitching worsened. This was a presentation about how UX and agile can work well together, and instead it sent the message to the audience (an audience that was almost exclusively agile practitioner and scrum masters) that UX was optional, and should be squeezed in like a square peg in a round hole.
I almost stormed the stage, years before Kanye did.
Flash forward: I’ve been a UX practitioner for over 15 years now, and I have worked on projects large and small – as I write this, a member of my team is working on a multi-year effort that is 100% agile, and I have helped him align our UX process to that methodology. It’s not hard, as long as you embrace some core principles and avoid being academic about it.
Time-box design activity
UX folks need to accept the sprint model and embrace the constraints. One of my favorite sayings is that “perfect is the enemy of good” – too often designers want to get things “just so” and they tweak the design to death. While the devil is in the details, and details absolutely matter, at a certain point the investment of time and energy to polish and refine doesn’t result in substantial improvements.
This is NOT to say iteration is bad – it’s a natural part of a mature UX process and the Agile methodology. It’s just that any delay caused by excessive iteration endangers the project and could prevent ANY solution from reaching end users. The whole point of user experience design is to create solutions for people to make their lives better. If nothing is ever shipped, no one will get any benefit from what you have designed.
And when it comes to productivity, I’m a firm believer in the saying that “The work will expand to fill the time that it is allocated to it” – so time-box design to align with the sprints to get stuff done.
Don’t sacrifice research
User research is vital, the key is to be focused and time box it. Don’t let a Scrum Master tell you that there is no budget for a “research sprint.” Research is a key input into defining solutions and understanding what the user needs are.
Work with the Scrum Master to identify a “Sprint 0” which is usually when the team is coming together and planning for the project is taking place – use that planning period to do some foundational research and gain understanding of user needs and frustrations.
Embrace user stories, not scenarios or journey maps
The best thing about Agile, to me, is user stories. They describe in a simple narrative way what the functionality of the system being designed needs to be. Here’s a couple of examples, based on a recent project I was on:
User story:
As a doctor, I want to prescribe one or more medications to an inpatient so that they can receive the medication I think is appropriate.
Condition:
If the prescription is for a Narcotic and I am in New York I cannot send that prescription via paper – I have to send it electronically to a pharmacy that accepts e-scripts.
What do the users need to do? The user story tells us that. Why do they need to do that thing? Again, the user stories detail the goals of the user distinctly and effectively.
What is so great about user stories is they can replace other design artifacts and will often communicate the design direction BETTER than these other artifacts can. The documentation it replaces, journey maps and scenarios, are intended to detail exactly what user stories do.
Create “Minimal Viable Documentation”
One of the big topics of conversation in UX circles the past few years has been “Lean UX,” an approach focused on minimizing and reducing design documentation in order to focus more on what is being designed instead of the artifacts. I’m a big advocate of Lean UX, because it aligns very well with Agile. Also, the old process of document-driven design was far too “waterfall” to work with the Agile process.
So, strive for what I like to call “Minimal Viable Documentation” – documenting just enough to communicate the design with your team, and make sure that you are available for your team to answer questions and refine details based on feedback. Be a part of the sprint team, not outside of it.
Finish fast, but finish well
How does UX (often) get a bad reputation? When UX teams spend too much time iterating and not enough time executing and finishing.
To quote an overplayed song in my household, designers need to finish and “let it go.” Be truly agile and focused on getting things done fast, but stick the landing. Finish well, and be focused on solving problems and creating value for end users – not on documentation or process.
In other words, be UX professionals.