Designing Ahead: The Good, The Bad, and The Ugly

by Anders on August 22, 2010 · 9 comments

in Agile,Process

In my previous post, I talked about how starting to build earlier has a cascading and transformative impact on the UX practice. One big change change driven by starting to build earlier is that of condensing up-front design work down to Just Enough. In other words, we go from doing a lot of analyzing and creating a lot of documents, sometimes for months, to committing to start delivering some kernel of the real product within weeks of project inception.

Once some kernel of the working product has been built, there is a fundamental shift in the working relationship between design and development. We move from the traditional assembly line hand-off model to something more akin to a theater production, where we are in a continual state of iterating on something real, from reading the script to acting it out in some rehearsal space, to adding set design, costume, and so forth. We are designing by doing rather than designing by describing. This is a concept Robert Austin and Lee Devin describe in wonderful detail in Artful Making, a must-read for anyone interested in elevating their Agile UX chops.

But alas, designing the product while developers are building the product is alien territory for many traditional designers. A UX designer indoctrinated into a traditional approach to UX design, with lots of pre-development design work, lots of exploration and iteration away from those who will actually be building the product, is unlikely to be prepared for the type of transformation of their practice that this change will bring about.

Without an Agile mindset, without an understanding of what it means to iterate not just design in isolation from development, but to instead iterate design with development, which is what we really are talking about here, you are almost certain to suffer some form of dysfunction, such as this horror story relayed to me a while back by a UX colleague:

This whole designing ahead thing is driving me crazy. I’m supposed to have detailed designs ready for the next sprint, which starts in a few days, but I can’t get the developers to stop coding and spend some time whiteboarding the UI, because they’re heads down finishing the current sprint and want to match or beat their velocity from the previous sprint. So now, the same thing that happened last sprint will happen this sprint: the developers build what I give them, which ends up being only half-baked in terms of UX because we didn’t really collaborate on it and because I had to rush my work to not fall behind, and yet they call it Done because they built everything I put in the wireframes. I can’t keep up. I’m just one UX Designer and they’re a whole team of developers. Man, I miss the good old waterfall days…

Does this sound familiar? The lone UX’er having to crank out wireframes to keep the dev team busy, with the resulting product perhaps being impeccable at the code level, but half-assed at the experience level? This phenomenon, sometimes referred to as “Feeding the Beast,” is what I think of as the dark side of Designing Ahead, which has become a relatively standard pattern among teams integrating Agile and UX.

The dysfunctional Feeding the Beast phenomenon occurring when waterfall thinking is applied to Designing Ahead.

The idea of designing ahead one or more iterations, of working on the UX for iteration 6 while developers are working on iteration 5, has emerged as a common practice in Agile UX circles. One of the originators of this pattern are Desirée Sy and Lynn Miller and this now-somewhat-famous paper they wrote. Don’t get me wrong: the issue is not with Designing Ahead per se. Desirée and Lynn and the folks at AutoDesk have applied this approach and been very successful.

The issue is with applying the pattern with a waterfall mindset rather than with an Agile mindset, which is what leads to much of the dysfunction. Top-most among them, in my experience, is thinking that designing ahead means designing alone.

Don’t Confuse Designing Ahead with Designing Separately

This is a great example of a waterfall mindset sneaking into an Agile approach. Just because there is a need to do some UX design ahead of the iteration work doesn’t mean you should be doing that design separately and away from other team members. So, let’s be very clear:

It is not the UX designer who should be designing ahead. It is the team that should be designing ahead

“But wait a second,” I can already hear a UX designer asking, “how can the whole team be designing ahead if the developer-part of the team is busy building for the current iteration? How can they be doing two things at once?” The problem with this question is one of misunderstanding what type of work is (or should be) done during an iteration. It makes the assumption that project iterations are discrete units of work with no overlap from one to the other.

As Mike Cohn explains in Succeeding with Agile, iteration work should include not just delivering value by the end of that iteration, but should also include planning and preparing for the next iteration, to ensure that it too is able to deliver value. And that preparation should include UX Design.

Bake UX Design into the Planning and Preparation for the Next Iteration

This means that the team should be committed not just to building for the current iteration but also designing for the next one. Certainly, the UX designer may be spending more time than the developers on this, but the developers are continually and actively engaged, reviewing mockups, providing feedback, showing the UX designer what they currently are building, to allow that to inform the design work being done for the next iteration.

Remember, adopting an Agile UX approach requires transformation not just on the part of UX designers, but also on the part of developers. That means that developers who may have been of the mindset of focusing on code quality and velocity will need to broaden their thinking to include product quality, where user experience plays an evermore central role.

Another common problem is that of trying to have a “finished” UI design by the time the iteration begins.

In my opinion, the goal should always be to complete the UX design of what you are building in the same iteration that you are building it in and then move the design work to an earlier iteration only if needed, in which you have virtually eliminated hand-offs and document waste. Yes, it will in many cases not be possible, but it is the mindset that matters here, to be thinking of that as the ideal state. There are two factors, in my opinion, which will require the team to forego that ideal: 1) Inexperience collaborating and 2) A high degree of design innovation.

Reason 1 to Design Ahead: Inexperience Collaborating

The idea of integrating design work with development work is, as I mentioned earlier, uncharted territory not just for traditional UX designers, but also for many Agile developers, who often are used to doing all the design work on their own, or just being handed some UI mockups to build from. This means that Designing Ahead requires teams that are highly adept at collaborating, teams that, for example, understand how to use light-weight rapid communication methods. If you’re new to this form of intensive collaboration, getting to that point will require a few training rounds and some good coaching.

Reason 2 to Design Ahead: A High Degree of Innovation

The more innovative the design work, the more groundbreaking or otherwise unusual it is, the more time you will likely need for upfront exploration. On the one hand, be mindful of the high level of risk attached to pursuing a highly unusual and non-standard user interface. At the same time, innovation is part of the UX game. Try to treat the innovation work like a UX spike, i.e. a short and intensive exploration. Just don’t turn it into an excuse for doing weeks or more of mockups and sketches. The goal should always be to find the shortest path to start to confront your ideas with something real.

{ 2 trackbacks }

{ 7 comments… read them below or add one }

Name *

E-mail *

Website

You can use these HTML tags and attributes: <a class="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>