Agile UX

Agile and UX are, on the face of it, incompatible but Agile UX can be tailored to work with a range of Agile methodologies; the challenge is streamlining the UX to fit in with Sprints. Preparation, testing, refinement, design and implementation can fit in easily if you have a view of upcoming work.

Ideally your Product Owner involves you with the product grooming, which gives you plenty of 'thinking time' before a Sprint reaches kick-off; thankfully with the Land Rover project this was a given.

Step One

Typically, my first task would be a briefing with the Product Owner as to the nature of the upcoming Sprint. As we talked I'd produce quick scamps of potential solutions, so we could rapidly identify pain-points, both from a business perspective but from a user perspective too, these came from initial project user research and, with enough time before Sprint kick-off, guerrilla testing of the initial scamps. Were they pretty? No! Were they effective? Yes!

I'd start to work these scamps up into more detailed solutions, consulting with the devs and creatives, still on paper, which I'd present during Sprint kick-off. Each design decision being matched again a user story. It was at this point that dev and design teams became fully involved, bringing their knowledge to bear and challenging and refining the proposed solution. When we had reached agreement the decisions were documented and the, now heavily annotated paper designs, were placed on the wall for instant reference.

Scamps illustration

Step Two

Once the Sprint had kicked off, with all team members agreeing to and knowing what and why our solution was going to be,. I'd take the agreed designs and start to wireframe every screen using OmniGraffle. This served two purposes, one it created a paper-trail so that any designer who came after me could follow the design rationale when the wall posters were taken down and secondly it allowed more detailed annotations for team members who had questions if I was unavailable.

If necessary I'd prototype the wireframes to agreed breakpoints using Axure, clearly illustrating both responsive and adaptive solutions, so that content authors could start to produce long and short form content pieces and developers could start preparing layout templates.

Break Points Image

Step Three

As development progressed I'd be less involved with the documentation, which would mainly be through updating rather than creating new, and I'd bemore involved with working with the Product Owner to on product grooming and go back over research. The project was demoed at regular intervals to the Product Owner, to ensure we were matching his/our vision, and the final piece was shown via web-ex to the global Stakeholders as you would expect in an Agile project. Every demo would illustrate the cross-device solutions and any known issues. When MVP had been satisfied, it would then be tested extensively for user feedback, which would then lead to refinement in bug-fixing sprints before going live.

What would I change in retrospect?

Not a thing. This was one of those projects that just ran like it was supposed to and the fact that we went from an empty room to delivering an entire global platform inside of 6 months is a major highlight of my career.