In one of our Chief Instigator's previous posts, we talked about how we can no longer think about design as being purely the domain of designers. Everyone on your team needs to design, especially your engineers. In fact, if you take a look, you'll most likely find that your engineering team is already making the majority of your interaction design decisions.
Creating Product is Like Creating a Building
There is a fundamental misunderstanding about the role the engineers play in building products. Let's articulate this with an analogy.
Creating a product is like creating a building. You have an architect that defines what the building should look like. He imagines the building and creates a design for how the building should look and function. The architect works with a structural engineer to create a blueprint defining how the building should be built based on an understanding of the constraints. At the end of the process, a team of experts with tools come in and assemble the building based on the blueprint.
Just like in the digital product realm, you've got a product manager that works with a designer to create the technical specification, and a team of engineers that uses the specification to assemble the product. Seems like a clear analogy right? It's close, except for one critical detail.
Engineers Don't Build Products, They Design Them
When you build a web application, your product is not the code. It's the page that gets served up to a person's browser. Your engineers are not sitting in a room, waiting for a person to navigate to your site and then build them a web app — that's what the computer does.
Imagine if an architect could just use a massive 3D printer to assemble a building — that's what software engineering is. People come to your application and, based on the code defined by your engineers, a product is assembled for them while they wait a whole second or two.
The Right Analogy
There is no one person who sits alone at a big desk and defines every last detail or interaction, it's just not how it happens, in software or architecture*. When products are done well, they're the results of a team of people working together to produce the definition — i.e. the software — that will be used to assemble the product.
Someone might play the role of the business owner dictating what the purpose of the building should be. Another may be a sociologist offering ideas of how the building can best serve that purpose. A structural engineer will make sure that the building can actually do the things the others are suggesting.
* I have no idea if this is true.
A Real Example
Back in 2011, I had the privilege of working with some great people on the first version of Foundation, our responsive web framework. We functioned as a team and my responsibility was the JavaScript. We were creating new components that were going to be used by millions of people. The interactions needed to be solid or what was the point?
How did we do it? Our designers certainly didn't create a spec. It started with some loose conversations as to what kind of components we needed to have. There were some existing plugins we had written and some new ones to be added. Once I had a loose idea in my mind of what we wanted I got to work.
The first iteration was created and one of the designers tried it out. He tried it out in a way that you can't try out with a specification or a wireframe. He clicked on it in funny ways, resized the screen, right clicked it, got it into funky states, all while I was sitting there taking notes. I went back to coding and incorporated his feedback, making tweaks or changes weighing the value of an interaction with the cost to implement it.
We repeated this numerous times, mostly just the two of us, until we got to a place where it was time to launch (if you think you'll ever get these things perfect, you're not looking hard enough).
Say Hello to Interaction Design
Interaction design is where user needs and technical feasibility overlap to create an interaction that solves a person's problem (typically at a very small level) and also, well, works. It's not just about fighting for the user, it's also about being able to ship something that actually works.
In most cases, this is what your engineers are actually doing when they are building code. Sure they are solving a lot of technical problems, but with modern languages and frameworks making this easier and easier, they are probably spending a lot of time filling gaps in the definition they were given. There is still a substantial set of skills required to write code, but maybe someday soon we'll close this gap architects will be printing buildings from some sort of moon base.
3D-printed Buildings? You, Sir, Are Crazy
Less crazy than you think. Disney California Adventure has a portion of the park that is modeled after Radiator Springs from the Pixar movie cars. The red rock walls are incredibly detailed and large, presenting an execution challenge to get builders to create the walls as Disney Imagineers wanted them.
To solve this, the Imagineers (notice the engineers part of that title) designed the rock walls using software and then shipped them to a company that used computerized machinery to fabricate them directly from the designs.
Engineers Make the Best Interaction Designers
OK, let's be real for a second now. Good designers do know a lot about how products work (if they are T-shaped) and can certainly make large decisions without having to understand every last detail of the code. But what about the really detailed decisions that can add up to something big. Think Disneyland. Great product through amazing execution on all the details.
You can't define all the interactions of predictive type ahead without understanding JavaScript. How can you come up with all the states that someone can get into if you don't know how the code itself works?
Engineers are fantastic at solving these detailed problems because they can push the available functionality right to its limits and not waste time exploring things that are impossible or prohibitively expensive.
Know Your Medium
Imagine an artist creating a piece of work in some medium like copper. Now imagine the artist knows nothing about copper and is telling some guy with a blowtorch how to to put it together.
"No no, it needs to have more pop! Maybe it you get the thingy on the right really hot and then grab it with your bare hands."
The end result is going to be second-degree burns and a piece titled 'The Mediocre Result of Piss Poor Collaboration.'
So You Want Me to Teach My Designer to Code? That's So Last Year
Basic understanding, yes. Full-blown unicorn, no. There is a lot to know when it comes to engineering, and running through a couple classes on Team Treehouse does not make you a full-blown engineer. But don't sweat it, start small and keep an open mind.
Start simple with HTML/CSS. It's the medium in which web interfaces are designed, and if your designers are still delivering finished interfaces in Photoshop or Wireframes, there is a big gap in the definition you're asking your engineers to close.
The next step is JavaScript. jQuery is a great place to start, as it allows you to start defining behaviors. The more complex interactions in your product are going to be JavaScript, and it's very likely they are going to be some of the most important interactions you deliver.
Stop Wasting Your Time With Worthless Specs
Let your engineers do this in the code, because that's what it is for. Get your designers working with your engineers to ask them questions about what's possible. Push them to experiment and give honest feedback on what they come up with.
We've seen (and heard) this many times. A design team spends countless hours putting together a very long, very detailed document explaining how everything should work. They zip it up and send it over to the engineering team. After an appropriate period of time has passed, a product is completed that bears little or no resemblance to the original specification.
Why does this happen? Are your engineers stupid? No, products are complex, and even the most detailed specification will have inconsistencies, gaps, and leave room for interpretation. Ever played telephone art direction? It can turn out kind of like that. Describing something is different from defining something, and the more room you have for interpretation the easier it is to describe something that is not possible.
Don't Let Engineers Design Alone
Engineers can be great interaction designers, but they also need sparring partners. Any time you leave a person to their own devices they tend to settle more easily. Working in small teams creates excitement and a sense of accountability. To avoid that accountability turning into hostility you need to ...
Develop T-shaped People
Rather than trying to get your designers up to speed on engineering, or teach your engineers everything there is to know about design, strive to create some overlap. Having some expertise in common makes it easier for teams to communicate. You are trying to avoid the 'throw it over the wall' mentality.
Specifically Though, What Are We Supposed to Do?
Here at ZURB, our designers work with our engineers to define our products. We use sketching as a tool to present ideas and get feedback on what's technically feasible and how it will play with any existing functionality. Typically we work in pairs, one designer and one engineer.
Our designers create static prototypes in HTML/CSS (T-shaped!) to demonstrate the functionality and give them complete control over visuals and layout while still working within the medium (no burn wounds here).
The screens are annotated using our Notable tool to explain ideas that are not obvious from the prototype itself. This is also used to demonstrate how multiple pages come together into a flow. From Notable, the engineer can give feedback to the designs on pieces that might not work right when implemented.
The engineer hooks up the static code that defines the detailed interactions in the code itself. Interactions include actions like what gets focused when a modal opens or where is the user redirected to when they try to access the page while logged out.
Once implemented the designer can play with the functionality and make changes to the design, layout and messaging, or go back to the engineer for another pass at the detailed interactions.
This loop continues until the pair are happy with the result, and then it goes live.
Honestly, We're Not Fully There ... Yet
We want everyone at ZURB to continue to learn, year after year. There is nothing more dull than performing the same tasks day in and day out. For our engineers we want them to go even further than just learning a new programming language.
By working side by side with designers, engineers certainly pick up a lot of skills around visual and interaction design. However our vision goes even further than that. We want our engineers to be the ones pushing our designers when it comes to interaction design. Setting the bar and defining the patterns for new interactions.
Being a maker or a craftsman is more than just doing something the right way, it's about putting your mark on your product. And to do that you've gotta make some design decisions. We want our engineers to have that opportunity. We believe it's a more fulfilling career, and produces superior products.
We're certainly not all there yet, there's a lot to learn just on the engineering side alone. But we strongly believe this is the right way to go, and we're going to keep chipping away at it.
