Radical Agile UX
Integrating design into an Agile development process is not a new topic, and frankly, I’ve never found much of a conflict between the two.
Over the summer, I chanced upon this tweet:
We designers seem to have a ceaseless appetite for advice on doing our jobs among manifesto-wielding, user-storying, pivotal-tracking developers. Here are my mutually-exclusive suggestions, from my perspective as a designer/developer in a small, tight-knit startup. Adopt what you can. Witheringly critique what you won’t.
Be the CSS you wish to see in the world
I've spent the last 17 years writing web code, so I’m biased. But are there any design disciplines whose practitioners are not experienced with the tools and materials of production?
Take your seat at the Agile table
Worried that you won’t have enough lead time to get your user research done? To get your wireframes drawn? Then pay close attention to the sprint plans, and know every feature in the backlog before it gets assigned to a sprint. If you’re a dedicated designer to a single team, volunteer to write the user stories and moderate the prioritization sessions. Make sure stories don’t get scheduled for development before you've had time to design.
Get in the way
At the end of a development sprint, someone’s pushing the “accept” or “reject” button on that user story. Why shouldn't that be you, the muddy-boots designer who knows your users frontwards and backwards, and designed the feature in the first place?
The software developers you work with are smart. They are talented. Whiteboard with them. Bring them to a user interview. Let them observe an evaluation session. Explain your methodologies to them, and ask them to teach you about useful technologies.
Once we made it over the Version 1.0 hump at ACT.md, many features have tended to be smaller components or iterative improvements. Detailed mockups and prototypes are often overkill.
For example, I’ll sketch a design on a whiteboard, then invite the team to discuss. We make edits directly to the sketch as we go. Afterward, I’ll post snapshots to the team wiki — instant “design documentation” and “software requirements.”
Remember that you have access to a broad spectrum of design techniques—it’s a sliding scale, so match the technique to the complexity of the design problem.
Be the boss
Eliminate the barriers between design and implementation by hiring your front-end developers as part of the User Experience team. Remember how you learned to code? This is where it’ll help to share a common language. For each project or feature, pair up designers and developers so they can learn to deeply understand one another.
Remember that UX and Agile solve different problems
Agile and UX are apples and oranges. The Agile disgust over “documentation” has everything to do with 100-page requirements documents and nothing to do with sketches, wireframes, and prototypes, i.e. useful visual collaboration materials.
Apples and oranges, yes, but both fruits, to be sure. Schedule a brown bag lunch with your entire team and watch this 45-minute interview of Alan Cooper, granddaddy of interaction design, from the Agile 2008 conference. Then everybody hug.
Hold your team to the fire
The biggest blind-spot of the Agile methodology, which I have experienced both as an Agile developer and an Agile customer, is actually delivering a specific set of features by a specific date. Yes, your team may be delivering “working software” but if all the user stories don’t add up to a useful scenario, you have failed. The real world rarely provides blank checks and unrestricted timelines.
So, do everything in your power to queue up your team for success, to minimize the uncertainties that jeopardize the budget and the timeline.
That is, be a user experience designer.