Where does design go?

We know design shouldn’t go at the end… but where exactly should it go?

In Agile dev teams, I’ve often seen a struggle to find the right place for design. Where does it fit in to sprints? Where does the handoff between design and development happen? Who keeps design intent at the forefront throughout the development process?

Oh dear, not at the end

We know, at least—we should know, that we don’t stick design ‘at the end.’ Design isn’t a todo item you check off only after you’ve made a massive engineering investment. This causes problems. We know this, so let’s not go back there.

Well how about at the beginning? That makes sense!

The beginning! That feels right doesn’t it? Let’s start with design so that we do it right! Right? Well… not really. I often see this go wrong as well. The reason is that here’s the expectation: The designer (and product manager) work on specs, do wireframes and mockups; stories get written, tasks are assigned to devs; and dev work starts. This coincides with about the same time the designer has “checked out” of this task/project/feature and moved on to the next.

I’ve been told to stay a sprint ahead so that you can work ahead of the developers and always be prepared. But if you are always ahead, you are never aligned—never in sync. See the problem? Let me elaborate.

So really, not at the beginning?

See here’s the thing. Front-loading design work wrongly assumes one thing. That designers know what they’re talking about. We don’t. Well at least, we can’t possibly anticipate all the problems ahead of time. Sure we use past experiences, and any new information we have on hand to make educated guesses, but once real dev work starts, we start to identify problems that we didn’t anticipate. If designers aren’t involved during the dev process when these problems arise—and I mean involved, not torn away from new work to re-engage an old problem—then often what gets built is based on wrong assumptions.

Ok so where? (I don’t like where this is headed)

Simply, EVERYWHERE. If design is not involved at the onset of development, during development and after development, then the vision the designers worked so hard to create is more likely to be lost. Trade-offs are made—not agreed upon compromises—trade-offs that often don’t even involve the designer at all.

Furthermore, to delineate this to a design process and a development process ignores the fact that this is in fact, together, is the product building process. Design AND development both need to permeate that entire process. This means there is no predetermined hand-off phase between design and development. Ideas bounce back and forth constantly so that everyone can be aligned to the same goal, and keep each other in check.

A designer’s job isn’t done when they hand a design to a developer. If as a designer you want your vision of the product to be upheld, it’s your responsibility to be involved throughout its creation. Of course, both sides need to agree and work together to implement this strategy.

I’ll admit it’s a lot easier to say that design should go everywhere, but it’s a different thing altogether when you actually want to put it into practice. I’ll cover off some tips about how to practically implement this strategy in your product team in a subsequent post!

Carlos Perez is a product strategy consultant that helps product teams work more effectively across design, development and marketing. Contact him today at carlos@practicalblend.com.