Teaching Design to Engineers

Designer and Lean UX pioneer Lane Halley posed this question on Twitter:

What do you think? How much UX can and should a “full stack developer” know? laurencegellert.com/2012/08/what-i…@carbonfive

— lane halley (@thinknow) June 7, 2013

The article linked in the tweet states that the true “full stack” developer should have knowledge starting down near the metal, stretching up past the UI, into the user experience and beyond, into the business. (I’m exhausted just thinking about it.)

I fear the person asking this question will not get the outcome they want. Knowledge by itself can’t be a bad thing, though in my experience motivation is the real source of magic. I have some strong opinions on this, because I’ve been fortunate enough to see the results when engineers become excited by shipping products others will value, instead of solving puzzles for their own enjoyment.

The engineer mind

Solving puzzles is where it all starts. When today’s programmers were children, they enjoyed building with Legos, working hard until the pieces fit together. Tomorrow’s programmers are ignoring their meals and debugging their Arduinos as I type this. Why? Because it’s fun! At least, they think so.

Actually, let me rephrase that: It’s fun for them. They extract enjoyment and learning from it, and those positive outcomes go into their hearts and minds. Even if they’re just passing the time, the critical distinction is the activity is about them and not another person.

Can you hear me now?

Here’s another example: the recently released book Exploding the Phone: The Untold Story of the Teenagers and Outlaws who Hacked Ma Bell tells the story of the teens and twentysomethings who figured out how to “hack” the phone system and make free long-distance phone calls in the 1950s-1970s. The author stops to make the point that these kids had no one to call. The goal was not to save money or stick it to The Man; they just wanted a challenge.

Here’s one anecdote from the book: the pranksters called several military facilities and were busted by the FBI. Since this was the Cold War era, the authorities thought they uncovered a ring of spies. The interrogation was intense, and only ended when an AT&T engineer produced records proving the kids had made no calls of any possible value. The G-Men couldn’t wrap their heads around the fact that the kids would spend so much time reverse engineering the system without a “real reason.”

But, to them, they had a reason: it was fun. And they learned something.

The big shift

Product teams need to take talented people like this and get them to build something that someone else will use and like, whether or not it’s an exciting technical challenge. By hook or by crook, their focus needs to move outward into the messy world of people and their problems. And, since comparatively few organizations are truly design-led, it’s incumbent upon designers and product managers to build bridges to these awesome folks and activate their amazing potential.

The good news is, it’s possible. I’ve seen it happen; it’s incredible. In our case, a key front-end engineer attended a design conference, and our seating chart worked out such that he sat back-to-back with our (also incredible) visual designer. Before long, the two of them were working on ideas of their own, and we were shipping stuff that was both well-designed and well-built.

That success inspired me put together a UX “crash course” targeted towards developers. If you have a roomful of developers, I’d love to share that message again. I truly believe the single most effective way to improve your organization’s products is by getting the engineers to care about design.


If design isn’t a big part of your company’s culture, don’t worry about how much engineers know about design and user experience. Building things for others isn’t why they started their career. Get them to care about shipping things others think are great, and backfill the knowledge they need a little at a time. They have to want the knowledge before you hand it to them.

Questions are places in your mind where answers fit. If you haven’t asked the question, the answer has nowhere to go.

— Clayton Christensen (@claychristensen) August 3, 2012