I was recently having a conversation with a company about design teams. Specifically how to build and scale them. This is a topic I’m passionate about. I’ve had the opportunity to do this several times at different organizations and have had success. Building design orgs can transform how a company builds product, goes to market, and relates to their users. And a really good design team has the ability to unite Product, Engineering, Data Science, Marketing, and a host of other departments to a common purpose and alignment.
A design team assembled well, is greater than the sum of its parts*. They support each other, encourage, and learn from each other. They grow their talents and capabilities. They also form a stronger, nuanced, and more comprehensive POV on the design aesthetic and user experience for the products they design. And in turn they can take that POV and more clearly articulate it to others — product, engineering, executive leadership.
* I should note that when I refer to the talent on a design team, I mean the full spectrum of roles: designer, researcher, content strategist, UX, design ops, everyone.
In building teams, I focus on 4 pillars that form the foundation of a strong, vibrant design team. They are:
- Strengthen design team culture
- Drive design integration
- Elevate design execution
- Establish a design thinking mindset.
Done correctly, this allows a design team to scale quickly and make a meaningful impact on the company.
I’m going to break this article up into two posts since it got pretty lengthy. This first part will cover strengthening design team culture and driving design integration.
1. Strengthen design team culture
Mold individual designers into a cohesive team. Establish a design process that is repeatable and scalable.
It’s important to focus first on team culture. How does the team interact with each other? What are the norms that everyone must follow? What about team ceremonies? Investing early in team culture is critical. Without it, very little else you do to build the team will matter.
Culture is important for how people treat each other, how they communicate and how they show up. It’s often overlooked for seemingly more pressing concerns (design execution, urgent deadlines, whatever). Here’s the thing though: culture will form no matter what. Norms are constantly being established. So one can focus on it and nudge culture in different directions, or it can grow wildly and hope that it serves your needs.
There’s a study I read 8 years ago that has had a profound impact on my leadership style. Google conducted a massive study to determine what factors most contribute to a successful team. They looked at every possible factor — experience, past success, training and background, length of time together. What Google found is the biggest determinant of team success was talk time.
If each member of a team spoke in group meetings roughly the same amount of time, that was the biggest predictor of team success compared to any other factor. This finding has always stuck with me and I think about it constantly. When I’m in meetings with my team, I notice who’s participating and who’s not. How can I create an environment where people feel safe to share and ask questions? How does my role as team director encourage — or shut down — conversation?
You can read about the study in this New York Time piece.
Often a design team is understaffed compared to the organization. Rarely can a design team dedicate a designer to a single squad, let alone multiple designers. But designers work best when they can collaborate with other designers, share ideas and feedback. It’s important to build into your team opportunities to collaborate and share work, through design reviews, working sessions, etc.
Typically, I’ve established several recurring meeting types to aid with team cohesion:
- UX Team Standup — Occurs once Monday morning. Team shares what they’re working on and any potential obstacles. Announcements and updates also shared. The rest of the week we will usually have Slack standups where people post each morning their update.
- UX Design Review — It’s important to provide regular opportunities for individuals to share work and get feedback. So instead of a single 1 hour (or longer) block occurring once a week, I’ve opted for 20–30 minute standing review sessions that occur 3 times a week. If people have work to share, they bring it. If they don’t the meeting is canceled.
- UX Workshop — This is dedicated time, once per week, where a design team member can request help on a particular problem. The team gathers for a workshop-type session where designers can collaborate. The person requesting the time has to organize the activities. If no one requests the time, the session is canceled.
2. Drive design integration
Increase design’s reach throughout an organization. Develop processes that force closer collaboration with product and engineering.
Often in companies design is set up outside of the working product org. A product manager will request a designer to design a specific thing, with requirements, and then reviews it, takes the completed design back to the agile squad. End of the designer’s contribution. And often the ask from the PM is solution-oriented and specific, rather than a discussion about the problem and consideration for how to solve that problem. This is a terrible way to involve design and leads to a lesser result all around.
I believe strongly in getting design as close to the squads doing the work as possible. They should be a part of the team if possible, dedicated certainly. In most organizations there aren’t enough designers to be assigned to a single squad (more designers are always needed!). But as much as possible, designers should align to specific squads, ideally those squads focused on a related/similar part of the user journey. This allows the designer to go deeper on a portion of the experience, think more on the same set of problems and thus generate a holistic view of the solution.
When designers work with the same squads, they get to know the people better and build relationships and shared vision. The first thing I coach to my UX team members is to develop a relationship with the PM. Get to know the things they’re thinking about — what are the problems they think about, what are the opportunities they’d like to explore if they had more time. Work with them to flesh these things out. This allows the designer to confidently focus on the things that matter. And to be sure, they should also building relationships with engineers and the rest of the team.
Designers should attend regular team ceremonies — standups, grooming sessions, retros. When they are viewed as part of the team, they are more closely involved and that builds cohesion. Collectively the team starts to think through problems and they leverage the combined perspectives and skills of each individual. Designer thinks through problems with the input of an engineering mind. Engineers better understand the thinking behind a particular design and work to maintain the spirit of that intention. The team ultimately pursues more thought-out solutions.
One small example of this that has always meant a lot to me: a few years ago a team was working on an ambitious project to redesign/replatform the entire site. One of my designers came to me one day, dejected. He informed me that the product pages we had planned to launch that day was going to be delayed. Apparently the engineer had noticed in QA that there were some CSS-related bugs in the display of the pages. Odd line breaks and font changes. Spacing was off. He brought this to the attention of the designer and the two worked throughout the day to solve the bugs. They got a lot of these fixed, but they needed another day or two to fix everything.
What this meant: a developer had a deadline, and pages that worked, but they didn’t look as good as they could look, and so developer and designer worked together. This is about raising the level of execution, the level of what “good” means. This was possible because the two worked closely together normally. That type of relationship is what you want to foster.
I believe there is an effective way to integrate design workstreams into agile frameworks. My teams have practiced what I call “UX Kanban” wherein the design work is tackled in kanban fashion — which is to say, the top priority is worked on, and then the next priority is taken up when the first task is completed. This regardless of whether the agile squad is operating in sprints or kanban themselves.
The design work is tracked in JIRA, or however the squad tracks stories. It’s important to use the same board and methodology here. It offers one simple place to see all work — backlogs, in progress and status, and completed work. If an entire squad has a single source of truth for work, why introduce a different source for just design work?
I find UX Kanban offers three main advantages:
- Transparency: Squads and PMs can see the status of everything. What’s being worked on, what the blockers are, and how things are tracking. This is critical to every agile squad.
- More UX “autonomy” to tackle work: Designers know what the biggest priorities are and the order they need to be worked on. When this is not in place, I’ve often seen PMs either struggle to come up with the next task or they fill the time up with less-meaningful tasks. This keeps the right work moving.
- Reduced time between design and development: A benefit related to transparency. Also when the work is reviewed and discussed in progress as happens with JIRA, there’s greater shared understanding. This reduces hand-off time.
It’s important that design work does not get trapped in a black box. PMs and engineers and whomever should be able to see the work in real time, as requested. Status should always be communicated. Now with that it’s important for non-designers to be comfortable with seeing work that is in progress and not finished. Equally, designers need to be comfortable sharing work that’s still in progress.
It’s also important that the design work is conducted outside of the sprint, which is to say, not bound by a two week cadence (or whatever sprint length the team adopts). Design work doesn’t break down into discreet steps the way engineering work typically does. When you try to write out tasks for each step of a design process, things get messy and unwieldy quickly.
The designers will still have “in sprint” work, and this is crucial. Once engineers pick up the work completed by the designer, the designer should be available, supporting in any way they can. On call to provide context and explanation, to provide ad hoc QA, to make any necessary changes to the components. This work doesn’t get tracked in JIRA, but should absolutely be viewed as necessary work by designers.
One last point: I instruct my designers to write their JIRA tickets. They should be responsible. It helps them think more akin to the way the entire squad is thinking. It also gives them more ownership of the work itself. I’m not as concerned about the stories being written in the same format as engineering stories. They should still provide any critical context and be generally informative.
Getting design properly calibrated and working hand-in-glove with product and engineering is hard work and requires trust and accommodation by all of those involved. But once integrated, the team will really start making a huge impact on the work to be done.
Thanks for reading part 1. You can read part 2 here.
