Spock, Kirk, and the ideal designer/engineer relationship

I’ve long been a fan of collaboration between design and engineering.

Not pictured: the amazing idea Spock and Kirk come up with together.

Spock and Kirk
Spock and Kirk

I tend to think about Star Trek when considering how designers and engineers should work together. After all, it wouldn’t be Star Trek if you only had Kirk — you need Spock to balance him out (and it’d be kind of boring if it were just Spock, right?).

Spock and Kirk work together and solve difficult problems. One’s driven by logic, the other by empathy and the heart. This relationship feels like a good template for how designers and engineers could work together because one working independently wouldn’t be nearly as effective or interesting as both working together. Oh, FYI: you’ll end up playing both Spock and Kirk during the course of a project.

Work closely by staying on the bridge with each other. #

Show an engineer your sketches, ideas, and prototypes before you send them out. Make sure you two join the kickoff meeting so everyone can think of ways to solve the problem at hand. That way, your engineer can start to think about how to solve the problem from their end, help avoid any pitfalls, and put forward some other interesting ideas to shape the project.

Consider that you’re both designing something. #

Design is more than looks, it’s how it works. The sooner both people know what they’re doing, the better. It’s like building a house—engineers put the foundation and plumbing in place, designers work out the house’s layout and interior. You’re going to want to keep in close contact so it’s clear what you’re presenting can actually be built. This house wouldn’t be much if it looked amazing but no one had running water.

Designers: be specific in your intentions. #

Let’s think about designing a button that submits a form. You’ve got a lot in your head: the button color, the animation that happens when you interact with it, where the user goes once it’s pressed. Your engineer pal shouldn’t have to guess about those things.

The sooner your engineer knows your intentions, they can start figuring out how to apply their know-how on keeping that form secure to protect users from any attacks. They’ll start thinking about if they need to store that data in a session, or an ajax call is appropriate.

I’m reminded of that joke about an engineer being sent out to get “some eggs” and never returning. No one’s really that obtuse, it’s just a fun reminder that you benefit from being more articulate about what you want to do. You need to know what kind of eggs, and if they’re cage-free, white, or brown. Otherwise you’re going to cause some roadblocks.

Engineers: Come hang out with us. #

Engineers have tons of knowledge to lend to a project. For example, one of my engineer friends and I were working on a iOS signup form. I’d planned and prototyped all the interactions, then he came in with a new library that let us do some neat animations to make the experience even better.

This kind of relationship challenges us to think deeper about our designs. Sitting alone pushing pixels with no regard to how it’s built doesn’t make for a great product, but collaborating with the person building it does.

The more you show your engineer, the better your product will be. Prototypes are extremely helpful, much more so than a static mockup. You run the risk of making too many assumptions if you’re looking at a picture of the thing rather than the thing itself. An engineer can help make your design even stronger. If you don’t code, find a way to demonstrate your intentions by looking at other products or do an animation in Flash or After Effects.

Getting to warp speed. #

It feels like all of this comes down to talking about and collaborating on your work. Don’t let each of you sit alone waiting for something to be thrown over. If you and your engineer collaborate like Spock and Kirk, you’ll build amazing things together faster than you’ve ever thought.

Original post