Agile & design methods: Learning to get along
Working every day with three agile teams has taught me a thing or two about software development, that’s for sure. What’s ‘agile?’ A well established method of developing software that emphasises quick, regular iteration and testing. It’s great in principal -keeps things motoring along and means for the most part that real users are kept in mind. There’s a catch though – the agile method was drawn up without any room for considered, creative design activity whatsoever.
Agile means developers work from ‘user stories’ which are small, one or two line descriptions of a task someone needs to perform with the product. These are written by the ‘product owner,’ a manager responsible for the overall vision. Developers then have a two week work cycle (a ‘sprint’) to design and code their part. The theory goes that their work will either sink or swim when people start using it, and they can iterate based on the feedback they get, so the aim is to get it done quick and rough without worrying about every detail at first. Products are built from the bottom up, piece by piece and polished as we go.
Meanwhile, the designer works the other way around. We start by figuring out the big picture through research. There is, after all, a huge amount of information to be extracted and considered before we can wittle down the users’ needs to a series of small stories. Then we might create a concept for how a product should be, covering the vision, appearance and fine detail of the user experience. Then we need to test, refine and iterate ourselves. Top to bottom.
UX design is a fairly new discipline – despite its ideas being well worn in the industrial design world – and arguably it has yet to achieve the foothold in the industry that agile has. There is a lot written about the two practices, yet most books and articles discuss the friction that comes from trying to make them work together. When I began, I quickly found 4 good reasons to persist:
1. Short sprint times mean that only changes possible inside of ten working days tend to get done. Small features are iterated often, but major changes tend to get postponed as speed of development doesn’t allow adequate time for the team to step back and think big.
2. Professional creative process never results in one design. There are always several concepts at first – possibly hundreds – edited, refined and combined until the strongest survives. The advantage is that this allows disruptive ideas and major changes to make their way into the product. In agile, developers tend to make a quick mental leap from a user story to a single design expression, and in my experience this is usually the one that offers the path of least resistance – tidy code or something we’re familiar with – which doesn’t always translate into good experience.
3. Breaking the product into many small user stories, worked on by many people, means there is often no shared vision, and the product can lack consistency. What do we get when all the parts are put together? Without any guiding reference, the launched product can feel rather patchwork, and inconsistency in language, UI controls and appearance can make for a jarring or worse, confusing experience.
4. The product owner can be hampered by difficulty communicating his or her vision. He or she may be unsure what users need without proper research skills to apply, and may struggle to convey new ideas without visual communication skills. The attempts I see are often bulky spec documents that developers don’t have time to read.
My challenge is to work out how agile and UX can be integrated to make for better user experiences and lower risk development. How can we maintain the speed and flexibility of agile, but bring in a clear product vision, effective team communication, and space for disruptive new ideas?
I began working with key users and product owners on concepts, and first delivered a light design ‘spec’ document to developers containing mockups from Balsamiq or Photoshop. The idea was this would accompany user stories and be the reference everyone could use for consistent design. It worked, but I quickly found the static format couldn’t communicate everything needed, and was time consuming to update, so couldn’t keep up with the agile team.
The Mark II was an HTML wireframe, made using Axure RP. This meant basic interactions and animations could be included, and by being a clickable, on-screen prototype, a barrier to comprehension was removed. It immediately got a better response from developers, and surprisingly also account holders who wanted to use it to demo upcoming products to clients. Taking advantage of this, I began using the wireframe for user research and stakeholder presentations, making it a continually updated vision of things to come.
There was an unexpected side effect however, when I discovered the development team were behind schedule, despite the product’s evolution into an unquestionably better user experience. They were following the high fidelity wireframe to the letter and spending more time than ever before on visuals, rather than building quickly and loosely. My wireframe communicated the vision, but it wasn’t clear which details should come first and which later.
For the Mark III, two versions of the wireframe are maintained. Developers see what is called ‘minimal viable product’ – a grey mockup showing them just what they should build over their next few sprints, with colours, graphics and fine details omitted. Product owners, users and account managers see a high fidelity version with all the rich detail and visuals included, so they can buy into and discuss our long term vision. To make two wireframes manageable, I’ve rebuilt my Axure files using a library of masters and custom widgets, so sweeping changes are quicker to perform.
I’m now working a sprint cycle of my own, timed to happen some weeks ahead of the development team. I use a mix of informal user research and sketch designs to agree and validate an overall vision with the product owner. The wireframe is updated and two versions produced for two different audiences. Where major changes are needed, I book out a block of several weeks known as a ‘spike’ to allow time for extensive user research and broad scope concept generation. More on this next time.
We’re all learning as we go, and there’s still plenty more to improve before we can say we’ve integrated agile and UX. Already though, we’re a better team producing a better product, and when we demo our work, the team show an obvious pride in our creation.