Design driven software has consequences for the way we've been building software with the agile method. Agile is a proven method for building and delivering software, but lets stop pretending its a formula for building the right software. It's just one piece of the puzzle.
Over the years I’ve found that design driven software is at odds with many agile driven software projects. Here are some of the pain points I’ve seen, along with some possible solutions.
1. Front loading design tasks is confused with waterfall
I’ve watched designers get shredded over producing comprehensive comps and wireframes by the hardcore agile enthusiast who sees that amount of upfront thinking as a wasteful waterfall activity.
Good design requires a complete understanding of the constraints involved, not only from a technical perspective, but also from the business and user perspective. These constraints always inform the visual and interactive makeup of an application.
When you shortchange that understanding, you end up with one of two things: unexpected rework or a son of Frankenstein interface.
2. Estimating features before a clear design direction always robs the user
Many agile enthusiast are quick to put points on a feature in order to deliver estimates and understand scope. If these estimates are being done without understanding the design direction and interactions, they are only useful for measuring the complexity of code, effectively shortchanging the design process from the start.
I’ve seen some projects include estimates for design tasks before the design is even started. I think it’s helpful to time-box design activities as a constraint, but estimating design points around features is a fools errand. On that note, once the design has been started and the interactions are understood, then I think its fair to begin estimating points around features.
3. Design requires divergent thinking and making
A clear danger in estimating design activities in agile, prior to understanding the breadth of constraints, is that convergence often happens too quickly. Design requires exploration and iteration, and shortchanging that process in order to fit design tasks into a poorly estimated story is a recipe for disaster.
4. Optimizing for quantity of features over user needs and desires
Don’t let the feature become the hero. If we estimate features without a responsible design consideration, we priorities features over users. The user is always the hero.
Features that have been estimated without a responsible design consideration only represent the utility of that feature from the user perspective. Humans are drawn to a much wider experience than utility alone. In many cases, utility isn’t the primary motivation for a users engagement, and its never the sole ingredient of user delight.
As designers, we take the unique position as advocate for the user. That requires us to make room in agile for the users voice to be heard. Don’t let agile stand in the way of that! (FTR, I don’t believe agile intends to undermine design, it is, however, a consequence in many cases.)
If you’re not, start:
- Making room, upfront, to understand the constraints around desirability, feasibility and viability.
- Investing more into upfront design activities. Don’t sacrifice the whole for the part.
- Estimating design tasks after a design path is clear.
- Time-boxing upfront design tasks to force convergence, but be mindful of the time required for divergent thinking and exploration.
- Optimizing for user delight instead of quantity of features.
Design driven software is the next evolution, building on the important principles that agile has taught us.
Photo by Vitalijus Daukantas on Unsplash
