Leveraging Agile frameworks for UX
5 min read
Agile methodologies are well established in software development, but how well do they work for design? At times it can feel like trying to fit a round peg into a square hole, but there are definitely some great things to leverage if applied right.
I live in an old Victorian house that we’ve spent over a decade remodeling and extending. I’ve learned many things over the years, and love how applicable the construction analogy is to software design. Would you begin building a house without blueprints? Would you focus on selecting the faucets in the bathroom, the paint color, and tiles before deciding how many bathrooms you need? The answer, of course, is no. The most essential questions to ask and answer first are those related to function and structure. Paint color can easily be changed, faucets swapped out, but if you haven’t planned sufficiently for the way the homeowners will use their house, you’ll end up with unhappy clients.
The same is true in software development. Ideally, while designers and researchers are doing their discovery, the development team is also doing discovery in parallel, so they can provide strong recommendations about the environment, tech stack, hosting, security, integrations, content management and migration. Advising on whether a “build” or “buy” solution makes the most sense is also part of this foundational discovery. With all disciplines focussing on structure as opposed to surface, we can be confident we are building a solid foundation for the future.
Getting it “right”
At the beginning of any project, the project team spends time working through a project plan, trying to anticipate how long things will take, identifying unknowns and neatly organizing deliverables into a compact timeline. In many cases, especially where time is the key driver, there are critical dependencies between development and design that leave no room for significant change. As designers, we know how essential it is to lock in more fundamental aspects of the design system, like navigation, core templates, and interaction paradigms early, so that building can begin in parallel, as we further hone and finalize designs. But what happens when key requirements haven’t yet surfaced, or when key stakeholders weren’t involved early and now request significant changes?
I have experienced both of these phenomenons and would argue that while each can throw a curveball, both can usually still be managed by doing a rapid design sprint in parallel, or pausing to refactor if necessary. After all, design is iterative and needs to accommodate change, especially in software design. Given that design is about how something works, not just how it looks, taking the extra time to get it “right” is essential. And I’ve seen first-hand that fixing something during design is always infinitely cheaper than building and refactoring it later when costs can be as much as 10x higher.
The Agile methodology is intended to encourage rapid and flexible response to change. Unlike its predecessor, Waterfall, it is not characterized by the initial creation of user requirements that have taken months or years to develop before development begins. Instead, it incorporates adaptive planning throughout, with incremental development and delivery milestones organized into “sprints.” A backlog of user stories that are continuously “groomed,” estimated and prioritized during sprint planning sessions provides the entire team with a clear sense of what’s ahead.
Design should always be two sprints ahead
So what does this mean for designers? And how far ahead do we need to be to ensure that development handoffs are smooth? It would be easy to give a non-committal answer here and say “it depends”, but after working on many tightly integrated design and build projects, I feel comfortable being less vague. I’d argue that rapid discovery and initial design can be completed within 2-3 sprints and that 5 weeks into any project you can have enough definition for development to begin in earnest. This doesn’t mean that everything has been figured out, but if the initial focus is on structure as opposed to aesthetics, this provides enough for the development team to begin building the backend.
The design team should always be at least 2 sprints ahead of the development team to allow enough time for reviews, stakeholder feedback, iteration, and refinement. Hearing developers complain that they’ve wasted a day building something that then changes is never fun, and frustration can grow exponentially if this happens frequently. I’ve just spent months developing a product myself and can appreciate even more strongly how important it is to establish a solid design system before building begins in earnest. I’ve also started creating design specs iteratively from the beginning so that key elements like color palette, typography, button and form treatments can be defined as styles early and changed system-wide in the same way they can be during development.
Valuable learnings
To summarize, Agile offers a great framework that we can leverage for UX, and staying two sprints ahead will optimize productivity and make for a much more cohesive team. When there isn’t a well-defined backlog as a starting point, as long as there are high-level requirements, we can apply a similar sprint structure to design. We can also estimate roughly how long a given template or discrete piece of functionality will take to better manage expectations around delivery. This is one of the most valuable learnings I took from sitting in many sprint planning sessions with developers. They typically don’t over-promise and are not afraid to communicate when something is hard and will have unknowns. I’ve applied a similar rule of thumb, more typically providing “top-down” estimates as opposed to bottom-up, and have consistently delivered on time and on budget.
I’m also a big supporter of the sprint retrospective, as a time to identify what went well and what can be improved. With the right facilitation, this can be an excellent way of diffusing tensions and pausing to reflect. And because it’s built into the Agile methodology, it can be scheduled from the beginning, so it doesn’t feel reactive or punitive.
Share this article
share on twitter share on facebook share on linkedin
