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 the Agile software development methodology. Agile is, like Lean UX, iterative… and the old process of document-driven design was far too “waterfall” to work with the Agile process.
The best thing about Agile, to me, are user stories. They describe, in a simple narrative way, what the functionality of the system being designed needs to be.
Here’s the typical format:
As a (user type/persona) I want to (action/feature) so that (reason)
As a (user type/persona) I want to (action/feature) because (reason)
User stories are usually partnered with “Acceptance tests” or “Conditions” which detail contextual and business rules when users perform a task.
If (context) and (additional context) when (event) then (outcome)
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 escripts.
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.
When UX people document scenarios and journey maps, they tend to get very creative in that work… and the resulting design documents sometimes are beautifully confusing. Again, the focus of UX design should be designing a solution for users, not making pretty documents that look great in the designer’s portfolio.
Other benefits of user stories are traceability… user stories can be integrated in development tracking software and software “sprints” are structured to deliver x number of user stories per sprint. Everyone will know what functionality is being coded and when. The user stories can also give project and program managers a clear list of features to prioritize and can inform product roadmaps.
The goal of design documentation is simple: Document the design, and user stories are the best way to start that process. It lets UX set the direction, it allows the UX team to work well with the development group, and it’s also faster and easier. What’s not to love?