Why Developers should be in your design sprints.

AKA: The Rise of Technical Designers

Interestingly, if you google “Technical Designer”, the main result is for those talented types in the fashion industry who construct the garments based on an illustrator’s drawings. Recently though, that’s a title I’m hearing more and more in digital, mainly around devs who’ve gone over to The Dark Side.

The parallels are there, traditionally developers are the people who weave code out of the pretty pictures given to them by their stylish and enigmatic designer colleagues. They are the people who bring the ideas to life for use on real actual people. The ones who understand the warp and weft of code, making sure it’ll fit an IE just as well as the idealised size 0 Chrome.

A Technical Designer in this world is a developer who doesn’t just build the product, but gets involved right from the outset, lending their expertise to the design process.

As design sprints become ubiquitous, it’s a golden opportunity for devs to get all up in the design teams business and deal with some longstanding gripes:

• Poor communication between design and devs, creating a disparity between what is designed and what is actually built.
• No shared ownership of the user experience, devs don’t see the value in the UX decisions made.
• Frustration in design choices leading to bad code.
• No sense of ownership of the project.
• …Dance code monkey, dance.

And it’s to the benefit of everyone involved, especially the design team. I’ve been involved in more than one project where they conveniently “forgot” to invite someone from the development team into the sprint. Every time has resulted in a convoluted (and in two cases, downright horrific) “service” that could have been avoided with just a few minutes of developer input.

All that wasted time…

To designers…

So. Why exactly should you, as a designer have developers in a design sprint?

• I’m pretty sure your sprint team should be a diverse group. I know developers are weird and scary, and probably wear the wrong trainers, but sprints aren’t supposed to be a designer love-in.
• Devs have awesome problem solving brains. It’s what they do. It’s why they are developers. If design thinking is “tackling ill-defined problems in a human-centric way”, you need people who problem solve on the fly, every single day. And contrary to what some of you think, developers are humans too.
• Devs have amazing knowledge and insight. Think back to those guys in the fashion industry, the ones who actually understand how clothes work in the real world, those are your devs. It doesn’t matter how good the design is if you don’t have someone who can make it work. Now imagine how good the design could be if you had that expertise from the very start.
• Devs are craftspeople. It’s like having a digital master carpenter on your team. They take enormous pride in producing elegant things out of complex systems and concepts. And what they build is good.

To developers…

So why should you, as a developer get involved in the arcane arts of design sprints?

To know your Enemy, you must become your Enemy. — Sun Tzu

It’s a bit trite, but surely it’s better to understand why these things are happening. You should understand the process that leads to the work that lands in your lap with a nice pink stickie that says: “Make this!”.

As to the rest:

• It’s fun. Seriously. It’s challenging, and can be frustrating, but it gives you a chance to stretch your mental muscles in a very satisfying way. Personally, I love the way you can throw out ideas and see that look on a designers face that says: “I’ve never looked at it like that before”.
• It feels good to be heard. You’re in a room where “there is no such thing as a stupid idea”, use that opportunity to voice your opinions. If you’re sick of seeing certain design decisions, raise your voice and explain (nicely) why they are so bloody stupid. You have a chance to steer the room to the right solution.
• Ownership. Rather than getting handed a wodge of Figma pages and being expected to get on with it, this is now your project. You’ve helped make this baby, and now you get to bring it into the world. It becomes like one of those side projects you do to stop yourself from going metal. Imagine the satisfaction.
• You will understand the thinking behind the UX decisions. No more looking at a design and wondering “say what now?”
• Laziness. Every dev is lazy, that’s why we use Gulp. Why do more work when you can spend 3 times as long automating it (okay, bad example, but, you know what I mean). The best thing about design sprints is that after the amazing creative splurge of Ideation, the designers have to bugger off and take care of prototyping and testing. You get the fun stuff.

For everyone…

Shouting to those at the back:

• Better communication — what gets designed is what gets built.
• Better final product.

I’m not going to extrapolate on these. The benefit should be pretty self evident. If you don’t see it. Step. Away. From. The. Sprint and go and bother some middle management somewhere.

I am interested, but…

By now you’re hopefully convinced to at least give it a try , but there are still a few doubts. Based on some recent conversations with fellow developers, I’ll take a guess that your top 3 worries are:

1. “I don’t understand the process.”
2. “I don’t understand the terms to the designers use.“
3. “I don’t want to look stupid.”

These are good and valid points. So here are three quick answers:

1. This is a brilliant resource, you’ll understand Design Sprints in 2 minutes: Interaction Design Federation — What is Design Thinking?
2. Meh. They like to sound clever. Just start throwing around some fancy language of your own.

3. Remember what I said about “no such thing as a stupid idea”? Yours may be “different”, but that’s why you’re there. That’s your imposter syndrome talking and you should ignore it. If you’re a working dev, you sure as hell ain’t stupid.

“Calling Agent Triple X…”

It may feel strange getting involved in this. There’s a sense of blurring the lines between two traditionally disparate groups, but as working processes evolve, it’s vital that we do too. Better cross-discipline communication only leads to better work. A good developer never stops learning, and this is a great opportunity to not just gain a whole new perspective, but also teach the other side about what you do.

It’s like the uneasy detente between East & West Germany in the 80’s, where you’re playing off both sides against each other to bring down the wall. Hell, you’re being David Hasselhoff.