To design better, we need to look beyond the confines of our craft. Design is more than color and form; design is the act of planning with the intention to serve others. Under this definition, the borders of design stretch beyond a single team.
Engineers, product managers, and researchers all have an important part to play in the design of a product. Their work, like ours, shapes the user experience. But despite shared interests, teams are often siloed by discipline, which makes collaboration and communication difficult, even dysfunctional.
Organizational design influences product design—significantly. If the relationship between the people who make a product is broken, the product will be broken too.
Broken teams, broken product
Here’s a scenario that plays out in companies far too often: Courtney and her team spent weeks perfecting the design of a new product. They presented the final concepts to stakeholders, got immediate sign off, then handed off their design files to Everett and his engineering team.
Though the dashboard design was stunning, Everett’s team had to gut it because the data Courtney’s team wanted to display wasn’t actually available. They also had to throw out the account sign up design because the designers hadn’t included all the necessary fields.
As Everett’s team continued to build the app, the distance between the intentions of designers and the execution of engineers widened. When Courtney finally got a peek at the app, she was horrified and said, “This looks nothing like the design we created!”
She walked across the building to engineering and stormed into Everett’s office to demand an explanation. Everett, frustrated that he and his team weren’t consulted earlier, curtly explained the design concept was ignorant of engineering requirements.
The relationship between design and engineering was already rocky—this wasn’t the first time they’d felt out of sync. Now it had gone from bad to worse, and the product was a reflection of their animosity. It was a mess.
Like an episode of HBO’s Silicon Valley, this story may hit a little too close to home. Courtney and Everett are out of step, as their organization is operating with a handicap—they have a vertical relationship. Design, at the top of the process, passes work down to engineering to execute—engineers aren’t part of the problem solving phase. Subsequently, Courtney’s team missed key technical details and key parts of the design had to be scrapped.
Vertical relationships also flow the other way—from engineering to design. Engineers rush to build a product’s infrastructure and pass it to designers for decoration afterwards. The results are equally disjointed, as buttons and type might look nice, but workflows built around database models instead of mental models leave users confused and frustrated.
Both scenarios are broken. Great products blend design and technology seamlessly. The feel and function of a product are interconnected, and equally important—like the right and left hemispheres of our brain that pass information laterally to synthesize creative thinking and logic.
We can take a cue from nature. When we bring teams together to work laterally—working on the product at the same time in the same place—we can reduce process entropy and create better products.
Build a first-class design team
The Design Leadership Handbook is your guide to transitioning to design leadership and building strong teams.
Cross-functional teams
Cross-functional teams are a hallmark of the Agile process. They bring together engineers, designers, and a product manager to define a product’s purpose, function, and feel.
Figure 1. Airbnb is organized into small, cross-functional teams that bring together design, engineering, and product management.
Three elements define a product: the business, the code and the pixels. Give each a voice in all product decisions.
Alex Schleifer
Airbnb
Cross-functional teams work laterally. Together product managers, designers, and engineers work to understand the problem and conceptualize solutions concurrently, not linearly, giving each team member a voice in key decisions.
Unlike the vertical workflow Courtney and Everett followed, cross-functional teams have no grand handoffs where communication falls apart and political battles erupt. No one is downstream. Pixels and code come together simultaneously around a clear business strategy.
Product managers
The role of Product Manager (also called a Product Owner) can vary, but in most organizations they’re responsible for the product roadmap and achieving the business’ goals. They keep the team on schedule and clear any barriers to progress.
Cross-functional teams have many benefits:
- Working closely, designers and engineers develop a strong understanding of their colleagues’ craft.
- The rapport established within cross-functional teams fosters empathy and respect that make collaboration easier (and more fun).
- Communication is much faster; designers are immediately made aware of the technical challenges their decisions create, and engineers learn when function diminishes form.
- Diverse perspectives each step of the way lead to better product solutions.
- Shared ownership dampens political fighting and builds trust.
Though a team may disband after a feature launches, strong bonds remain (like friendships formed in summer camp). This can only strengthen the company culture.
The benefit of small teams comes down to three words: communication, focus, and camaraderie. Smaller teams are easier to keep current on project status, changes, and new learning. Dedicating your team to one project keeps everyone on the team focused on the same priorities all the time. Having the team all in one place allows relationships to grow between colleagues.
Jeff Gothelf
author of Lean UX
Team size
Keep your cross-functional teams small—no more than 10 people to make communication easy. Any more and the team will have to spend time creating process documentation and scheduling meetings to keep everyone synced. Team collaboration and communicate happens more fluently when everyone in a shared space.
These days you see some companies investing even more heavily in design…
Irene Au
Khosla Ventures
Dipping a toe in the water
To make sustainable improvements to the way your organization designs products, you may need to take a red pen to your organizational chart. These sorts of changes don’t come easy or quickly.
But before doing anything drastic, you can test the waters with some small experiments. Small projects with tight deadlines are a great place to start experimenting with cross-functional teams.
If time is tight, start by investing just 1 week in a Design Sprint.
Design sprints
A design sprint is a 5-day process developed by Google Ventures for answering critical business questions through design, prototyping, and testing ideas with customers. Because it takes just 1 week, it’s a low-risk way to try out a lateral design process in a cross-functional team.
The Google Ventures group goes into great detail in their Sprint book and its related websites, but in short, over 5 days a small team will go from understanding the problem space to validating a design solution.
If you survive the sprint and produce a great product idea, you’ll have set the stage for more cross-functional teamwork in the future.
Working groups
Like design sprints, working groups assemble a cross-functional team to tackle a tough problem. But working groups stay together much longer than a week to produce a final product that’s actually shipped to customers. After the project is complete, everyone returns to their respective teams.
Working groups have:
- Clearly defined objectives and metrics to measure success
- Designers, engineers, a product manager, and maybe even a design researcher
- The autonomy to make key decisions about the product they’re building
- A deadline to ship
MailChimp has a long history of assembling working groups to focus on hairy projects. One such team was created to design a new drag-and-drop email editor.
A designer, a front-end developer, and 2 engineers—one of whom had a talent for prototyping—sequestered themselves behind closed door in a small MailChimp office to tackle the project. Sketching and debating, they looked at the problem from all angles.
Sketches turned into simple prototypes. The designer explored UI concepts and made refinements. Developers coded out the new design, tweaking interactions as they went. Back and forth they worked, always sharing progress with each other immediately and inviting debate.
Figure 1. The MailChimp email editor is the product of lateral design in a working group.
Eventually, the prototype had reached its limits. After testing with the whole company and select customers, the new editor, Neapolitan, eventually shipped. This working group gave the company the opportunity to escape the gravitational pull of the product roadmap to go deep on an important feature that made working in MailChimp easier and faster.
Everyone on the working group returned to their respective teams with respect for their colleagues and their craft, and knowledge of what could be accomplished when designing laterally.
Going further: Institutionalizing lateral design
Big wins from working group projects can spark conversations about optimizing the rest of the company. The cross-functional team structure that enables lateral design can be scaled up by uniting engineering, product management, and design in an organizational structure commonly referred to as EPD.
Alex Schleifer, VP of Design at Airbnb, describes EPD as a 3-legged stool that supports the organization.
The team should resemble a three-legged stool, in which each leg represents one of the three areas that helps build a product. If it’s done from the start, each function can grow in parallel at proper ratio as the broader organization scales.
Alex Schleifer
Airbnb
Figure 2. The EPD structure is like a 3-legged stool—engineering, product, and design need to be equal to achieve balance in product design.
A stool with 1 leg shorter than the others causes instability and imbalance. Similarly, EPD organizations are unstable when a function of the troika is weaker or more powerful than the others. EPD’s strength comes from sharing power.
Each function of EPD must be involved and aligned from a product’s inception to its launch. EPD teams are typically organized around product features by areas of the user experience:
- Facebook organizes its teams by product feature like news feed, profile, or messenger.
- Airbnb organizes teams around areas of the user experience like the guest or host experience.
Like workgroups, each team is cross-functional, with representation from each leg of the EPD stool.
We see more impact through a collaboration between engineering, product, and design.
Katie Dill
Airbnb
The success of EPD is directly connected to the health of the relationships among the 3 leaders of engineering, product management, and design. Dysfunction from the top will trickle down to the respective teams quickly. It’s imperative that these 3 leaders remain united in their leadership and communication to the company.
Better cross-function collaboration
On the FirstMark Capital blog Alex Schleifer describes how Airbnb unifies staffing and hierarchy across EPD to make collaboration and planning more efficient.
The challenges of cross-functional teams
Though cross-functional teams offer a number of advantages, they can be challenging. Workgroups, because they’re temporary, rarely surface significant issues. Instead, designers might feel like they’re on a vacation—they get to learn new things before returning to the comforts of home.
Permanent cross-functional teams are more like expatriating—designers will wrestle with their identity and struggle to adapt to a foreign land. Read on to learn how these problems, though common, are being solved at a lot of great companies. Going into an EPD structure with open eyes and a set of solutions will help you transition smoothly.
Isolation
As we saw in Show and Tell, designers need regular feedback from other designers. In a cross-functional team, it’s common for a designer to operate alone, which leaves them craving conversations with peers. Organizations like Slack, Twitter, and the BBC offer some interesting solutions.
Slack: Paired design
Lateral design in cross-functional teams is a mainstay at Slack, but designers always work in pairs, with 1 acting as the lead designer.
Pair design gives you a partner in crime to help you explore ideas more. It’s two people with similar or complementary skills riffing off each other. Plus when you have two people, it helps you get unstuck faster when you hit a roadblock.
Diogenes Brito
Slack
Having that kind of collaboration be really low friction…brings the quality of everything up.
Diógenes Brito
Slack
You can pair designers even if you’re short staffed. Pair a designer with a colleague from another team who can spend about 8 hours per week (or just a little over an hour per day) working in tandem on design problems.
Twitter: Design reviews
In early 2014, Twitter transitioned from a centralized design team to embedding designers in cross-functional teams. In order to prevent designers from feeling isolated or unable to consistently learn from their colleagues, Mike Davidson, VP of Design, scheduled weekly design reviews and other activities in the design studio to bring everyone together as a team. Congregating regularly gave all designers the opportunity to discuss the overall design style of the company and keep everyone in sync.
BBC: Rotate teams
The BBC, with more than 20,000 employees, lets employees work on a new team every year. This policy helps all employees, not just designers, form new relationships and broaden their understanding of the organization.
Designers who want to rotate within the UX&D team speak to their manager to explore the idea. Approval is common if they’ve spent over a year on the same team. The resource manager facilitates the transfer, taking into account the designer’s skills, career goals, and current team availabilities.
Aligning style and values
Decentralized design teams have to work a bit harder to make sure design remains consistent across features and products. The style of each UI and the values that guide design decisions can fall into disarray if teams are left without clear guidelines. Many large organizations are working hard to solve this problem, but few more than Spotify.
Spotify: Design systems and values
As a company scales, design consistency becomes more difficult to manage. Companies like Salesforce, IBM, the BBC, and Atlassian created a design system to solve UI consistency issues, but Spotify used their design system to solve an organizational problem too.
Figure 3. Spotify’s GLUE design system helps all teams produce consistent UIs, and is managed by a central team.
The team that manages Spotify’s design language—called GLUE (a Global Language for a Unified Experience)—is the center of the design universe in the company around which all other design work orbits. Designers regularly sync up with the GLUE team to get guidance on new UIs and suggest additions to the design language.
A system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.
Nathan Curtis
EightShapes
Design systems, once thought of as an occasional side project, are playing a more central role in large organizations, making them a perfect place for designers to converge and find common solutions.
Guilds
Designers in cross-functional teams throughout Spotify are joined together by a design guild—a community of interest where knowledge, tools, and best practices can be shared. Anyone, not just designers, is welcome to join discussions in the design guild. A guild coordinator is responsible for managing activities.
Spotify’s guild structure comes from the Agile practices developed by the engineering team.
Values
Outnumbered as they often are in cross-functional teams, designers acquiesce to engineers who encourage smaller design iterations and a simpler approach. Do we really need that animated transition? Does it add much value? It’s difficult to champion the necessity of small details when you’re the lone designer. Many simply give in and get back to work.
As the only designer in a cross-functional team, you’re accountable to a different set of values than you would be if you were working with other designers.
Mike Davidson
formerly Twitter
There’s nothing wrong with a little pushback between designers and engineers—it keeps both from becoming self-indulgent. But often, engineers push back on design simply because they don’t understand how to measure the success of a design.
Engineers measure success quantitatively:
- How many lines of code were required?
- Did this impact site performance?
- How many bugs did we ship?
Designers measure success qualitatively:
- Does it look good?
- Is it easy to use?
- Is it delightful?
Just as an engineer’s work shouldn’t be measured by design metrics, a designer’s work shouldn’t be measured by those of an engineer. Instead, designers and engineers, working together, must form a shared understanding of what constitutes success.
Recognizing this need, Spotify articulated a series of design values—principles that communicate what’s most important when solving a design problem—and made them available to the whole company. Common values help designers articulate their design decisions.
For example, a large image occupying key space in a UI may seem indulgent to an engineer—Is this photo really necessary? We could fit more data here if we get rid of it. With the support of well defined design values in the vein of Spotify, a designer might respond, “Our design values state that a UI should ‘be alive’. This image creates movement, adds color, and brings an otherwise stagnate UI to life.”
With a shared set of design values, priorities and how they’re communicated becomes clearer.
Figure 4. Spotify established design values to guide all teams as they work on disparate projects.
Design drives business
Learn about design ROI at the world’s most innovative companies
Lateral design in practice
Lateral design is not organizational dogma. Whether your company is Agile, Lean, or something in between, it creates a spirit of respect and empathy between domains to produce great products.
Organizational design influences product design. Shared ownership, collaborative problem solving, and blended teams are key.
Here’s your to-do list as you put lateral design into practice in your company:
- Starting small with a 1-week design sprint.
- When you’ve had a taste of the benefits of cross-functional teams, create a working group to tackle a project with a clear timeline and defined outcomes. You should have designers, developers, and a product manager on the team.
- When your organization is ready to go further, organize teams in an EPD structure. Engineering, product, and design should share power, and report directly to the CEO or COO.
