In the years since we’ve been providing integrated design and development on agile teams, we’ve noticed something that seems to emerge naturally on projects that are going particularly well. While we always set out to design our products in small releases, refactoring along the way (i.e. “the smallest whole“), often designers find themselves quickly under a ton of pressure from the developers, who are looking for well-defined stories to work on, sometimes after only a week of product definition.
Even once the overall product design is in place, each week brings a handful of new features that developers are eager to start. In addition, sometimes a teammate will throw a story into the backlog that is just an idea, not even ready for a designer to elaborate. At times it can feel like our team is a fiery coal-burning engine (our product manager and developers) starving for fuel (the design).
Without time for a complete set of wireframes (let alone visual designs) designers sometimes have to get a little creative. Not every story can get the same level of definition, and a one-size-fits-all workflow (e.g. design, build, deploy) doesn’t really make sense for every feature. We’ve found a set of activities useful when the team feels “blocked by design.” I like to call it Story Triage.
To get the most out of this flow, you’ll need a few things in place: a balanced team, an agile process and a living style guide. They’re not easy, even with a new team working on a new product, but it’s possible and the rewards are worth the effort.
First you’ll want to find yourself a balanced team composed of “t-shaped people.” What’s that? A balanced team is a small (say, between 3 and 9) group of people committed to delivering a successful outcome through active collaboration; a team composed of a mix of product, design, and development skills not completely siloed by individual. If you haven’t heard the phrase, “t-shaped” refers to people that have deep expertise in one area but also have interest, aptitude and some skill in others.
What if you aren’t on a team like that? Check to make sure; you might be surprised. Ask your team what they did before they found themselves in their current role. You may find (as we have) a developer who once worked in PR, or a designer with an long-forgotten CS degree, or a product manager who used to work as a user experience designer. Knowing what skills are hidden by your assumptions about your teammates opens up possibilities for inspiration and collaboration.
A bigger challenge could be team size. If your core product team is larger than 9, you should seriously consider splitting into smaller groups. There’s no silver bullet on how to do so (an API group, web client, iOS, Android and ops might seem obvious but can’t always be achievable) so it’s best to just give it your best guess given the lay of the land and assume you’re going to get it wrong at least a few times.
Effective story triage assumes you’re participating in an agile process, not some post-process “we just do it” environment. We’re pretty much by-the-book Extreme Programming practitioners but you should be able to use this technique on Scrum teams as well. Some parts of our process that reinforce (and are reinforced by) story triage include: weekly iterations, story writing, prioritization, estimation, pairing, continuous deployment and frequent releases. For now we’ll assume you’re doing some form of flavor of Agile.
Living Style Guide
A living style guide is a set of pages checked into a project with reference DOM and styles applied, that is used and cultivated by the designers and development team. There are definitely fancier variations, but that is the bare minimum. We’ll talk more about why you should have a living style guide, but most arguments I hear against it aren’t because the team doesn’t think they’re good to have, but because of the upfront time it takes to make them. In my mind, the quickest way to get a living style guide for a web application is to start with Bootstrap or Foundation and create a theme on top of it using selective overrides or a complete customization. For mobile, style guides are often hosted on a project wiki, with custom widgets called out and a strong bias to use native widgets and device style guides for iOS and Android whenever possible.
So you’ve got a balanced team, an agile process and a living style guide? Great! Let’s look at your backlog and do some story triage. Note: if you feel like it’s impossible to achieve these prerequisites, drop us a line; maybe we can help.
I define story triage as a designer, product manager and technical lead looking through the upcoming backlog each week and flagging stories with a customized workflow based on the definition and design needs of each story. The flags we typically use are: needs definition, needs validation, needs design and design pair.
Stories can have more than one flag applied and all of their flags must be removed before a developer begins work on a story. We use Pivotal Tracker on most projects so they’re called “labels” but every agile tool I’m aware of has some sort of tagging system for you to use. Let’s go over each of these flags one by one.
Before we do, I want to take the opportunity to harp on a pet peeve. I hate the term “blocked by design.” If you’re using that term (on teams or in a tool), please use “needs design” instead. Nobody likes to be the blocker, and on our teams if one role is holding up progress, it’s the responsibility of the entire team to figure out how to address the issue. Saying you’re blocked by a designer is just passing the buck, in my mind. Saying something needs design opens up the possibility that someone else on the team might be able to chip in.
We use a pretty standard story template on projects. It looks like “As a [role], I can [perform an activity] so that [user goal].” We usually throw a short title on the story card for easier scanning, but a story starts its life in this form.
Of course, a story is just a promise for a future conversation. Before estimation we talk again, elaborating the story with a set of scenarios (use cases) that define the acceptance criteria for the feature and form the basis for the unit tests the developers use to drive their design. That said, we don’t always do it right away. In fact, a backlog full of elaborated stories can be a sign of waste, since many stories deep in a backlog get deprioritized right out of the product (“agiled-out” as we lovingly say).
Because of this tendency to write the shorthand story and leave it until the iteration planning meeting to elaborate, throwing a needs definition flag on some stories that are more ideas than definable features is a great tool. We’ll use this liberally after we’ve estimated the current week’s worth of stories and encounter vague or big stories in the next iteration or two that need some product manager attention.
This flag is a sign for the PM to more clearly define the feature, usually with the help of a designer. The end result of this definition is sometimes a wireframe or comp, but often takes the form of a photo of a whiteboard or a new set of rewritten stories.
Stories that are well defined are considered actionable by developers. But, just because you could build something, doesn’t mean you should build it. Our friends at Aardvark (now repeat clients with Alt School and Good Eggs) only built a feature once everyone on the team agreed it was worth building. This usually meant running an experiment using a prototype (although sometimes it’s easier to build the software and test it live) and running a user test of some sort.
In cases where there’s disagreement on the team about whether or not a feature should be built as defined, a needs validation flag is used to indicate that an experiment needs to be defined, built and run before the feature should be picked up by a developer. Experiments are defined by the whole team and are often pretty inventive. Testing tools in our belt include: hallway usability, paper prototypes, card sorts, customer interviews, online surveys, A/B tests and in-person usability tests. Once the team reaches consensus (or decides building the feature is the best way to find out if it’s any good), the needs validation label is removed.
If you’re like us, you’ll find that adding needs definition and needs validation to appropriate stories will free up a lot of your designer’s time. These two flags take half-baked ideas off of the team’s radar until they get more fully fleshed out and tested.
Once the designer has a little breathing room, we use the needs design flag on stories somewhat deep (2-6 weeks) in the backlog to indicate that the designer wants to do more detailed design work before developers begin work. The flag is usually placed on large features with particularly hairy interactions, or on stories that are a key part of the customer journey. Designers then take those stories and do collaborative ideation sessions, paper prototypes, guerrilla usability tests, high fidelity comps and/or clickable prototypes to elaborate the design. The designer presents all artifacts to the group and attaches relevant assets to stories. Often these artifacts imply new stories, or cause existing stories to be revisited.
If all of this sounds familiar, it should. It’s a pretty standard design workflow on agile teams. It’s just sometimes challenging to achieve when developers are chomping at the bit for actionable stories and the product manager and designer are taking turns pulling back on the reins. Sharing the product design responsibilities efficiently between product management and design makes time for “real” design work. But what to do with the rest of the stories? Those stories that are well defined and the team feels like are worth doing without extensive design work and validation? That’s where the last flag, and that living style guide, come in.
About half of the remaining stories seem to get a design pair flag. This indicates one of two scenarios: either the developer and designer should work together as a cross-functional pair on the feature, or the developer should start the story and grab the designer for a pairing session before delivery. Which scenario is appropriate is often the developer’s call and dependent on how meaty the story is. If it’s small or they feel like they want design input up front, they usually start with the pair. If it’s a bit gnarly, they may want to stub it out first and have the pair later.
Having access to a living style guide helps to create a kit of parts for the developer to pick from when starting a story without explicit design assets. In fact, many stories in our backlog may get none of these labels at all. For relatively straightforward features developers can take a story and, based on the written description and acceptance scenarios, design their own UI using the style guide. The product manager can always reject the story if it feels insufficient, or add another story for an enhanced version with a needs design flag on it. We also encourage the designers to open up a “design polish” ticket once every iteration or so where they can create a punch list of nice-to-have details to keep the quality high and pay down design debt incrementally.
Give It a Shot
Creating a customized workflow for stories using labels like needs definition, needs validation, needs design and design pair can help create an efficient design flow on agile teams. Be sure to check in with your team and get them excited to chip in on design activities, and take a day or two to put in a barebones living style guide if you haven’t already. Once you give this technique a shot, or if you’re using something similar, let us know how it’s working for you.