Recipe for Agile UX Design

Originally published at https://www.astridparis.com on November 16, 2014.

I’ve had the privilege of working for a software company that really “got” it when it comes to agile UX design and development. While our processes were far from perfect, most a of the time we were able to strike a decent balance between designing too far ahead and designing just in time. Here are some things we baked into our process that helped us do just that.

Shared understanding

On the team I worked on at this company, the product owner team (product manager, lead dev, and lead UX) drafted user stories and acceptance criteria well in advance of the desired sprint we wanted to put them into so that we could make sure we fully understood the business value we were trying to achieve even before we introduced the rest of the team to the story/epic. Once we had a pretty good grasp on that, we’d start introducing the story or stories to the rest of the team through “grooming.” Story grooming gave the entire team a chance to

• hear the problem we were supposed to solve,
• hear the product owner team’s hypothesis of how to address it,
• ask questions, and
• talk about proposed solutions.

We found grooming to be a critical step in keeping the development ball rolling, as it created a shared understanding among the team before even one line of code for a new feature was written. When everyone has a chance to provide their input, teams feel more empowered. Even if we had some pre-designed solutions in mind before we got to story grooming, the product owner team was always open to changing things up based on conversations from grooming. A developer might have a less expensive way to implement a desired interaction. Another might ask probing questions that even challenge the need for the feature. Great things can come out of story grooming! It helps keep everyone on the same page as far as what value the team’s trying to provide for the user.

Lean processes

Skipping the traditional lengthy UX design process helped my team focus on what mattered the most — getting value delivered quickly to our users. If this meant all we did was sketch potential solutions for a feature and then jump straight into coding it, then that’s what we did. Designing too far ahead can attach stakeholders to an idea that might get bulldozed once you get into implementation. Sometimes, a higher-fidelity prototype was needed to really envision the user’s experience, but even in those instances, we generally didn’t “dot all the i’s and cross all the t’s.” Design and prototype just enough to give confidence that you’re in the right direction.

Design and prototype just enough to give confidence that you’re in the right direction.

Dev/UX pairing allowed the developers to start putting in the framework for a feature and then later come back and work with the UX person to hone the UI. “Putting on the polish” can mean anything from offering suggestions for quick things like the final microcopy for a page all the way up to more detailed stuff like getting a CSS animation just right.

In a waterfall world, teams might go through several rounds of iteration and review before the stuff finally gets approval to be in the actual code. Designers might have to write up specs to get styles pixel-perfect or animations spot-on. When you handle these things at the time of development, you free the UX person to work on other tasks (since he or she isn’t wasting the time on documentation). You also usually wind up with a better experience because the designer is right there to suggest changes. Why waste your time writing specs only for them not to get implemented and then have to submit tons of styling bugs? Tweaking the details only right before you ship a feature can save tons of time on design deliverables.

Continuous design and delivery

Our team had moved from 2-week sprints to continuously delivering value, so there seemed to inherently be reduced pressure to start coding something that wasn’t thought out to the level it needed to be. If we were about to start a sprint and didn’t have a big feature quite ironed out yet, we would just pull in another story that was better prepared. That bought us a little more time to make sure that the next big thing was ready.

From a user experience perspective, “agilefall” shops often want big design upfront (which calls for documenting many, many details). If that big design upfront gets rushed because of an impending deadline for starting the next sprint, guess what happens? The team unnecessarily rushes through the design. I’ve seen firsthand how this practice can negatively impact the final experience. Sometimes, the team ends up building the wrong thing/uses the wrong interaction/etc. Agile design is all about adapting to change. If you learn something new in the fourth week of your design for a feature, and you’ve done big design upfront, and you have no weeks left to adapt, then you’re more than likely going to stick with building the wrong solution.

Effective backlog management and release planning

Continuous delivery is largely made possible by having a good grip on your product backlog and keeping up with your release planning. When the product backlog has a good inventory of groomed stories, teams can more easily make the go/no-go decision on stories to pull into a sprint. Feature A stories not ready on Tuesday? That’s okay. Pull in Feature B stories and start on Feature A stories by the following Monday if they’re ready.

Constant communication

I’ve been in more waterfall-like agile environments that weren’t run like above, but one thing that did allow us to keep things moving was taking just a few stories/epics at a time and having frequent checkpoints and design reviews. Design on Monday, review internally (e.g., with other designers) on Tuesday, iterate on Tuesday, review with stakeholders on Wednesday, etc. Keep things moving by sharing each iteration with your stakeholders as early as possible.

Keep things moving by sharing each iteration with your stakeholders as early as possible.

Agile UX design recap

• Focus on writing user stories and grooming with your team before getting knee-deep in design.
• Make sure everyone understands the need for a feature and the “whys” behind a design direction.
• Remove process inefficiencies by focusing on outcomes, not output.
• Introduce dev/UX pairing to minimize the time your designer spends working on deliverables rather than designing the user experience for your product.
• Use rapid prototyping tools like InVision App, Solidify, Marvel App, or Proto.io to quickly communicate flows through a system and/or to get some quick user feedback.
• Only work on things that are ready to be worked on. You’ll save hours later by not having to trash something because it sucked or didn’t address the user’s problem. You’ll also possibly buy the design team some time to finish fleshing out the bigger features.