When engineers and designers team up, magic can happen. Everyone on the team is more engaged. User research findings and usability testing results are shared with everyone. Engineers are invited to walk-throughs of early designs and asked for feedback and input. Designers become aware of technology constraints and the structure of data that can be surfaced from the system to users. And a whole lot more—meaning good ideas and thinking are spreading throughout the team to help build an awesome product for users.
Unfortunately, in some companies, the engineering and design teams are siloed from each other. Whether the separation was planned or occurred organically, the consequences are the same. Morale, efficiency, and in the end, the product will suffer. How do you align design and engineering teams into a unified product team?
Divided we stand
How does a product team become divided? Causes can be:
- Department silos
- Overly rigid process
- Poor team culture
- Tight deadlines (communication is one of the first things to get tossed aside, but usually on a totally unconscious level).
Let’s take a closer look at some of the causes.
Culture of otherness
In some cases, the wall separating engineering and design may be caused by managerial style. In his book Kitchen Confidential, Anthony Bourdain revealed that he fostered a feeling of “us” against the rest of the world within his kitchen staff. While Bourdain claimed not to have not created the dynamic in an interview with Harvard Business Review, he explained that he happily exploited it. The only problem is that while engineering may be similar to line chefs, the design team are not part of the front-of-the-house staff—they belong in the kitchen as well.
Bad past experiences
There are bad designers and bad engineers in the world, it is true. When you run into one, or a worse a dysfunctional product team, it can cause a lot of hurt feelings and distrust. Unfortunately, this can produce baggage that team members carry from team to team. The most important thing to remember is that every team is different—every engineer and designer is different from all of the others you have ever worked with.
Discomfort with waste
While we live in an iterative world, no one wants to redo something, nor do they want to build something only to have to trash it. An iterative test and learn process will produce short-term waste at times. Both engineers and designers need to strive for efficiency, but also need to come to terms with a certain level of waste to reach product effectiveness for users.
Religious wars
In other cases, the divide may be philosophical as pointed out in Mike Bulajewski’s article Crossing the Great UX–Agile Divide. There is a saying that you can never win a religious war, so the best thing to do here is not to get into one. The key to remember here is that Agile’s main goal is to produce better products, it is a tool, not a religion, leave the deep sociopolitical philosophy discussion for outside the office, it’s not helpful if it amounts to nothing more than navel gazing or builds division.
Us versus the world
I once met a tech leader who was fostering two of the above examples. By understanding where he was coming from, I was better able to refocus the conversation and show more similarities between engineers and designers than the differences he was bringing up. In the end, we had an incredibly tight product team with engineering and design relying heavily on each other’s skills.
Knowing the source of a division will help you develop the best strategies to bring people together. But, no matter the source, the most important remedy will align goals and boost both communication and involvement. If there is going to be “us” against the world, then you better make sure engineering and design are on the same “us” side.
Aligning Design and Engineering
Reunited through a common cause
At the root of such problems lies poor communication between the designer and the engineers. In other disciplines, similar problems of course occur, silos organic and invented litter the landscape of the work world, leading to poor or not enough communication.
So how do you tear down the walls and solve for this? For starters, grab a designer or engineering opposite from your team and go to lunch with them. Invite the designers to hang out with the engineers and vice versa. Is it really that simple? No, but familiarity breeds empathy, which leads to understanding.
At the next level, talk about pain points (no finger-pointing) and how to make each other’s lives easier. Discuss debt, both technology debt and design debt, keep the focus on the user and find ways to quantify the value of lessening each unit of debt to the user. For example, what is the value of a 5% increase in download speed, what is the value of removing a step from the user’s workflow). This helps move people away from what they value to what the customer values—helping to align the team. Aligning everyone around the customer is the ultimate goal here.
We are more the same than different
Some people claim design is a right brain activity, and engineering is a left brain activity. I say bull, both require skills that are equal parts creative and analytical. Designers collect data to understand users and how these users will both use and benefit from the product, they then think strategically and creatively about how to solve problems. Is that really any different from how an engineer approaches a problem? Not really. Design and engineering are both creative professions, they have more similarities than many think—emphasize these similarities.
Process for peace
Another area to look at is process—how are the teams working together. If the design, or the product team, are tossing tickets over the fence at engineers, there is little doubt problems will develop. A good process should be flexible enough to deal with anomalies, but rigid enough that people know what they need to do. More importantly, a process should facilitate communication and the flow of the right amount of information.
Engineers should be in the room at the first kickoff meeting where a problem is discussed. Engineers also need to be accessible to the design team to answer questions, including the occasional reality check—this will remove assumptions about the system, which is what leads to non-executable designs.
When possible, designers should give engineers a walk-through of the design, to get feedback, relate what was learned during usability tests and give developers a heads up about what is coming next. This heads up is invaluable, as it allows engineers an opportunity to better consider the choices they are making today that will affect the work they will do in the sprints to come.
Lastly, there should be a handoff meeting for a final walk through before engineers commit. This will give engineering a chance to better understand what is desired.
The above may sound like a lot of meetings, but there is no need for a traditional meeting to accomplish any of the above. Most of the meetings can be 15 minutes or less, can happen organically or scheduled. If you want, you can calendar regular discussion times. In any case, designers and engineers should self-organize as needed to make the best of the time—you don’t need everyone in the discussion, just the people who will be directly working on it. If a designer and front-end developer need to grab a back-end developer for a few moments, then they should—but large numbers of bodies from both groups should not be needed.
Part of my process includes putting all of my work on a wall and invite anyone from engineering (or business) to check it out anytime, leave PostIt notes, have a discussion, or do a heuristic walk-through. And I expect to be able to bounce things off the engineers I work with so that I can gain a better understanding of what our system can and cannot do.
Design on display
In Agile, a part of the process is demo day at the end of a sprint to show what was completed. When possible, the work output of the design team should be included. What was learned about users during this sprint or the way they use the product, how is a new feature fairing in the wild, as well as user journeys, flows and more can be shared. These all will help show how the team’s designers are thinking, how decisions are driven by users and analytics, and give engineers more visibility into the process.
In the end, communication and transparency strengthened by a process and culture that facilitates them will break down the walls and bring engineers and designers together.