An Agile Alternative: Embedded Design

Last week I wrote a blog post about a depressing example of non-agile design. This week, I'd like to show you an alternative method of design, along with some examples drawn from my experiences. This is not, by any means, a new concept, but hopefully I can convince a few people who still think that agile development and interaction design don't go together.

I've worked as a designer and user researcher with agile teams on several different projects. The trick is that, instead of doing all the research and design up front and then throwing the work over the wall to the engineering team, the designer stays embedded with the team throughout the entire development process.

How does an embedded interaction designer help at various stages of the development process?

Strategy and Product Definition

At this stage, your designer (or design and research team, if you’re well-funded) should be out talking to potential users about their problems. A designer at this point in the cycle can help you define who your customer is, learn how potential customers are currently dealing with the problem that your product solves, and come up with a small set of crucial features that will solve those problems better.

Could a great product manager also do some of these tasks? Sure, and they should definitely be involved or even leading the process. But, in my experience, being involved at this stage allows me, as a designer, to really understand the problems I’m going to be solving and the people for whom I’m going to be solving them. In other words, to have a successful design process, I will have to know all these things anyway, and participating in the earliest stage of research is the most efficient way for me to learn them.

Example:  One company with whom I was working wanted to add a new feature that would allow users to play music while interacting with the product. From our discussions with users of the product, we knew that people were already doing this, but in a way that caused them all sorts of issues and made many people unhappy. We interviewed current users about things like:

• How they were currently using music with the product?
• What benefits did they get from using music with the product?
• What major problems were they having with music? 

We also looked at the quantitative data that we had about what sort of music was being played, how much people were likely to pay for it, and  what percentage of people were active music users. The answers to all of these questions helped us come up with a new concept for music that would solve many of the problems and add some fun new benefits

Design

I don’t have to go over this one, right? You need a designer at the design phase. You could always let your engineers design all the screens and the interactions, of course, but that strategy often goes very, very badly. (not always, of course, but I’ve seen more disasters in this area than I care to remember…)

Besides, if you’re building in a Minimum Viable Product in an agile environment, the design phase itself can be quite short, since the designers tend to stay only a couple steps ahead of the engineers.This means that there is often considerable overlap between the design phase and the development phase, rather than a clear delineation between the two.

Example: When working with a couple of different agile teams practicing scrum, we would start our design process one or two sprints ahead of the development team. When the engineering started, the developers generally started work on the back-end processes, giving us a little more time to get the user facing designs ready.

A side benefit to this approach was that the engineers had a much better idea of what they were going to be building, since some design was done, and they could give better time estimates for their tasks and make better decisions about product architecture. On the other hand, since they didn't need to wait for a "full" design to be done, they could begin development in parallel with design and speed up the whole process by a matter of several weeks.

Development

Your next question might very well be, “What good is a designer during the development phase?” Well, if you've started your design phase only a sprint or two early, the chances are that your product is not completely designed. And it shouldn't be! Things change during the development process that require design changes, especially when you're constantly getting feedback from real users on the work in progress.

Things also change during the design process that have nothing to do with users, of course.

Example: I was working on a fairly large, important feature that had a lot of user interaction. We were at the point where most of the back end work was done, and we had created a well-tested user interface and visual design that engineers were busy implementing.

Every so often, an engineer would come to me and say, “This thing you’re asking me to do will take 3 weeks. Is it worth that?” When that happened, I could sit down with the engineering team and go through our options. Sometimes the piece was so critical to the experience that we had no choice but to forge ahead with it. Other times, we were able to find a solution that was almost as good (and sometimes better) that would take significantly less time to build.

The most important thing was that having a designer on the team at all times allowed us to make those choices with a full knowledge of how they would affect the final product. It let us make smart, fast changes to the design without losing the overall vision.

QA

I know that QA isn’t always its own separate phase of the product cycle, but at some point, I hope that somebody’s looking for problems in your product before your customers find them. Having an embedded designer at this phase is extremely helpful, since whoever is looking for bugs needs to know what’s a bug and what isn’t, and the person who is best suited to answer that question is the person who designed the thing in the first place.

Example: I can’t tell you the number of times I’ve had a bug that an engineer marked as “as designed” that I've had to bounce back to them with the comment, “Well, I sure as hell didn’t design it that way.”

Deployment

If there’s ever a time it seems like you could do without those pesky designers embedded on a team, deployment is that time. After all, what is there left for a designer to do?

Plan for the next version, of course! Once the product is in the hands of your customers, it’s the best time to start gathering metrics, observing users, and coming up with the next set of features for the product.

Also, keeping your designers embedded on a particular product over several versions or product cycles allows them to really get to know the users, the product, and the projected feature roadmap. Designers can help make sure that any new updates, features, and bug fixes remain consistent with the core product and don’t contribute to drift.

You Missed Something

“Hang on,” you’re thinking, if you’re paying attention. “Didn’t you miss the part where you test your designs?” I did not. In my mind, iterative testing is part of all the phases of the project. You should be constantly getting feedback of one sort or another on your designs to make sure they’re usable to your potential customer. User feedback isn’t a separate phase. It’s built into all of them.

Time Commitments

One question that often comes up is whether having an embedded designer means that that person has to be dedicated full time to one, single project. Well, it really depends, but in most cases I’d say no. The design workload on a project tends to wax and wane, depending on the phase.

Obviously, the research and design phases can be resource intensive, but the others often require much less time, which can free the designer up to work on other projects simultaneously. I’ve often been on a project full time during the research and design phases, and available for meetings and questions for several hours a week during the development and QA phases.

The most important thing is that there should always be an informed design resource available to handle the questions and tasks that can come up at any point in the project lifecycle.

Tell me your stories about agile or non-agile design in the comments. 

Enjoy the post? Follow me on Twitter!