Radical Agile UX

I chanced upon Nick’s tweet today:

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

That is, learn to code, and then learn to code really well. If you’re writing the HTML & CSS, there’s no middleman between your pixel-perfect PSD and the software that gets delivered to your users. Just as importantly, you’ll learn much faster if your novel interaction pattern really works by prototyping it with real JavaScript. You’ll also be supremely valuable in the job market, and far more useful in a startup, where specialized roles for designers are rare. (NB: I’ve spent the last 17 years writing web code, so I’m biased.)

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?

Be inclusive

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.

Be flexible

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. Remember that you have access to a broad spectrum of design techniques - it’s a sliding scale, match the technique to the complexity of the design problem.

Be the boss

Eliminate the barriers between design and implementation by housing your front-end developers within 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. (And what do you know, here are some designer/developer heuristics that might help.)

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.