What designers can learn from the Skunk Works

I’ve long had a fascination with military jets. When I was a child there was a video game where the copy protection relied on users recognising jet silhouettes; I could do this without the handbook. Jets like the SR-71 Blackbird, XB-70 Valkyrie and B-52 fascinated me (and I could probably talk for hours about them). I mean, just look:

As I grew older, I started to read about the history of these aircraft and the people and organisations that created them, people like Bob Widmer, Robert Bartini and of course, Kelly Johnson (and anyone mentioning Pierre Sprey will get an atomic wedgie).

But this article is not about the ramblings of a former plane nerd. In Ben Rich’s book “Skunk Works”, he writes:

“Our senior shop people were tough, experienced SOBs and not shy about confronting a designer on a particular drawing and letting him know why it wouldn't work. Our designers spent at least a third of their day right on the shop floor; at the same time there were usually two or three shop workers up in the design room conferring on a particular problem. That was how we kept everybody involved and integrated on a project. My weights man talked to my structures man, and my structures man talked to my designer, and my designer conferred with my flight test guy, and they all sat two feet apart, conferring and kibitzing every step of the way.”

In recent years, there's been an increasing trend towards both specialisation and separation of roles. As part of my design work I have done research, design (including editing and copywriting), and testing. Those can all be separate roles, and there are pros and cons with splitting them out. Where some design organisations fall down is in the separation that sometimes accompanies specialisation. This is what the Skunk Works nails above: the different roles working closely together.

Having a computer science background, I’ve always worked closely with the software engineers and testers implementing my designs. What I’ve found works well:

Early discussions to understand the state of the codebase

The codebase in many organisations often leaves much to be desired, with multiple implementations of the same basic functionality, more time needed for bug fixing, and high coupling / low cohesion, making it hard to modify one part of the code without changing others. By working with developers to understand these pain points, you can create strategies to address technical and design debt in parallel.

Ongoing discussions through the design process

“Everyone’s a designer!”. No. No they’re not. Designers are designers. Software engineers are software engineers (honestly, I feel silly having to explain this, but apparently some people feel otherwise). But being close to the developers, clasping them firmly to your heaving bosom and walking through the design with them to get their feedback early? Absolutely. Developers can identify alternative approaches that may:

• Work better with the codebase
• Be quicker to implement
• Be more consistent with code elsewhere in the system

And if this can be achieved with little or no detriment to the UX? Go for it!

Providing detailed design specifications

Prototypes are there to test, iterate and demonstrate. To support development, they’re helpful but not sufficient: they provide a developer with a high-level overview of how the system looks and behaves, but the developer needs more than that. For example, take a date input field. You want it to capture a date, obviously. What dates are valid? Do you want to simply disallow dates that indicate someone is under 18? What’s the maximum age? How are you giving feedback??

You can code these things into your prototype if you want (and have lots of time), but what then – expect the dev to try everything out and work it out from there? Far better to write a design specification that describes in detail:

• The overall process flow
• Different states of each page (including empty states)
• Error states and handling

For designers, creating the design specification helps you to spot gaps in your design.

For developers, the design specification provides all of the information required for a developer to implement your design.

For testers, the design specification helps to create test plans before the implementation is ready.

Good designers work hand-in-glove with developers, testers, and others, as the mighty Skunk Works demonstrated. If I can help you with any of this, send me a DM!