The benefits of Agile Design
Originally published on the Humana Digital Experience Center blog in 2016
I work with a lean, agile, balanced team. Designers are an integral, required part of product teams. Our iterations are short, our pace is fast, our delivery is continuous, and we release early and often. Facilitating those practices requires design that is as agile as our development. On most products, the design work is only a week or two ahead of development. Designers today are prototyping and testing interfaces that will be built into real products tomorrow. This tight timeline isn’t a byproduct of being unprepared, it’s how we prefer to work. How on earth do we design well in that sort of environment?
When I first joined an agile development team as a designer, my initial fear response was strong. I thought, “I have no time! My designs will be half-baked, incomplete … maybe outright bad.” I was used to the idea of taking requirements into my designer cave, doing my designer magic, and emerging victorious, presenting my beautiful solution to the stakeholders like a magician. There’s personal pride in the big reveal, and a sly sense of satisfaction that the college tuition was worth it, because not everyone can do design magic.
The thought of exposing my design process to the whole product team was was chilling. “They’re going to see all that crap I come up with before I get to the Good Thing!”, I worried. To make matters worse, I didn’t even have clearly defined requirements. The team had a vision of where the product was going, and I had a list of features to design for, but the specifics of how all that would come together was totally up to me. Instead of detailed technical specs, I had things like “Jane enters a blood pressure reading and gets an assessment.” Worry! Fear! Paradox of choice!
I got over it.
Now that I’ve spent time working quickly and transparently, I am frustrated by the mere thought of Big Design Up Front. The process I’ve grown used to has been so instrumental in the success of our products that I’ve started to wonder how I ever got anything done, let alone right, before. Success has more to do with principles than practices, but here are some practices that teams I work with use. These practices made agile design my best friend, instead of my worst enemy.
Paired Design
Pairing is a practice taken from Extreme Programming. (Grab a Mountain Dew and read Extreme Programming Explained if you’re unfamiliar.) The basic gist is that you and your pair work on literally the same thing. Sometimes that’s whiteboarding and sometimes it’s a design tool like Illustrator or Sketch. What’s important here is that you’re not working alone.
Working directly with another designer has proven immensely beneficial to developing a diverse skill set and bettering my work. I would never give it up. The times that I don’t have a pair, I find myself feeling adrift. A design pair is able to thoroughly explore new ideas when in the early stages of a concept, and the collaborative relationship refines concepts naturally and quickly. A pair also keeps you from getting lost in research, or going off on a tangent.
Cross-disciplinary Collaboration
When I design, I sit an arm’s length away from my entire team. The engineers and product manager are close enough that when I have a question, I simply raise my voice and say “Hey! What do you think about …” The close collaboration we have across disciplines enables designers to come up with solutions that not only work well for our users, but also effectively meet business goals and make the most of the technology available. We’re also able to reach those well-rounded solutions with a minimum of lost time and work. Being in constant conversation with the product team helps designers keep all the various inputs to our work well-balanced and top-of-mind.
All the information a designer pulls together to inform their work can be overwhelming. It’s challenging to balance business priorities, design best practices, and technical limitations and opportunities. Working within an agile team helps us balance and remember all this information, thanks to tight feedback loops. Designers here never have to wonder what the business stakeholders, the engineering team, or the users will think of something — they can find out in a matter of days, or even instantly.
Frequent User Feedback
Of course designers care about the visual impact of a product. However, all that nice-looking stuff looks nice because we want it to be easy to use, and possibly even FUN to use (dare I use the word “delightful”?). The best way to know if we are succeeding in that endeavor is to put our work in front of users and observe their interactions. Our team brings in users in every week to test what we’re working on. Often, we have working software to show them. Sometimes, we have a prototype. At the earliest stages of a concept, we have sketches or rough mockups. Regardless, designers are able to get regular feedback from actual users, which is used to inform the work.
Built-in Improvement
Think back to a project you worked on a year ago. Is there anything you would change about it, based on what you’ve learned since? Most designers I know would say “yes”, without question. Now apply that same thinking to a project from six months ago. Likely you can still think of some updates you would make. In fact, most designers never think of the work they do as finished. Digital work has the benefit of being editable at a much lower cost. Agile design takes full advantage of that opportunity, allowing designers to work on smaller pieces of design, and then come back and look at the bigger picture later on, while making improvements along the way.
While iterative design presents its own challenges, and requires a great degree of flexibility, it is absolutely worth the effort. An iterative process allows us to design better products, delivered faster, by teams that have a fuller understanding of the product and its users.
The concepts I’ve touched on here begin to explain aspects of the agile design process that I’ve found valuable. There’s quite a lot more to be said on the topic. Check out these articles for other perspectives on similar design processes: