Viewing entries tagged
Leadership

How design teams can demonstrate impact to a doubting product org

image credit: Esteban Lopez

Many years ago, early in my career as a UX designer, I was at an agency finishing up wireframes for a client. The account executive came to my desk with questions and a suggestion. He stated he had doubts about how I had designed a particular feature.

“Why did you design it that way?” he asked. So I provided an answer citing current design trends and how this approach eliminated clicks. He was unconvinced, and argued for a different design approach. I referenced ease of use and insights we gained from user interviews pointing to my approach being better. The account executive called into question whether the research was sound — “why that way?” he asked again — and again pushed for his approach citing how he thought users would behave. Round and round we went, me making the case for my design based on my experience and expertise, him questioning it and pushing for his approach. He was not moved by anything I said. Finally, quite exasperated, I responded to his latest “but why that way?” question with: “Because I’m the UX designer and you’re not!”

I’m rather embarrassed by that response. I’ve thought about it many times over the years and I cringe every time. It was absolutely the wrong thing to say. I did go up to the account executive afterwards and apologized for my behavior and we cleared the air. Still… uggh.

Many designers struggle to justify their work to others. The above example, if not the poor response by me, likely sounds familiar to many designers. It should be self-evident that design matters and is valuable. The struggle is real. Many organizations wrestle with this challenge: how do you quantify the impact of design?

Now the easy answer here is: focus on metrics. Yes, do that. Design teams need to frame their work through the lens of business metrics. Define success criteria before the work kicks off and measure the change in those metrics when work is completed/launched.

But for this post, I wanted to share examples of how design can demonstrate impact and value beyond just improved metrics. I’ll share three real world experiences where my design teams have delivered results and changed perceptions of our efforts for the better.

 

1. Stop calling… please

When I first arrived at Liberty Mutual I was tasked with building out a new design team for our part of the organization where one had not previously existed. Most of the PMs and engineers were not used to working with design and as such we didn’t have their trust. There was a lot we wanted to push for but was not making progress. What we could do and how much change in features and page construction was very limited. Often we were asked to use only existing (old, poorly designed) components.

At that time there was a big push to reduce calls. Calls cost money and Liberty wanted to push more people to a digital self-service model (that didn’t quite exist at the moment; more on this later).

Data analytics identified the page that generated the most calls into Liberty Mutual: the Contact Us page. I was asked to have my team redesign the page so it generated fewer calls.

Liberty Mutual Contact Us page, 2017

The problem is the page was already designed in a confusing manner that made it hard to find a phone number. In fact, users found prompts to mail a letter or fax a request before you came to a phone number. There was little I could do to make the page less directive to calling (short of transposing digits in the provided phone number).

My team started by reviewing the available analytics for the page. One data point that stood out was the high number of call transfers it generated. There are two main numbers for Liberty Mutual — one for customer service and one for sales. Liberty had calculated that the cost for a representative to transfer a caller from one call center to another to be $3.50 per switch. So we ran an A/B test: the test page would display clear headers indicating one phone number was for customer service and one was for sales. The control version was the existing page without headers.

The results were dramatic. In the control version calls were evenly split between the two numbers (571 calls for sales vs. 452 for service). For the page with headers, almost all calls were for customer service — 852 for service vs. 29 calls for sales. Users were now getting to where they wanted to go. We virtually eliminated call switching, which saved Liberty hundreds of thousands of dollars annually.

This was a simple test that didn’t really require design work. But what it showcased was design’s ability to evaluate a problem, hypothesize a solution, and deliver results. This small success put our nascent design team in a positive light. We earned just enough trust to explore more involved changes. We would iterate on content and design patterns that made the Contact Us page more aesthetically appealing while also better helping users accomplish what they needed to. We leaned into self-service, getting users answers and increasing login-rates. We would even launch a successful chatbot.

All of this became possible because we could succinctly demonstrate the ability of design to solve real business problems and deliver meaningful results.

 

Liberty Mutual Contact Us

 

Let design lead the way

One summer the engineering team at Drizly was bogged down in extensive, and necessary, infrastructure work. It was all-consuming and demanded everyone’s attention. Except for design.

With a lighter workload, I had the design team take advantage of this lull to focus on users. Specifically, we undertook the effort of mapping out the primary user flows of our consumers. What were the main tasks they wanted to accomplish and what was the experience actually like for them. We documented everything. We also layered in available user research findings. We zeroed in on every point of friction for users, calling them out. We also identified opportunities to make different points more joyful (one of our design principles). We had everything laid out for onboarding, browsing, gift-giving, checkout, and several others.

This wasn’t busywork or a way to continue practicing our craft. I had an insight. Q4 is the busiest time of the year for Drizly. Historically we’ve been slow to get work done ahead of Q4 that we know will improve the Drizly experience. We end up rushing out quick fixes scattershot. I also knew the rest of leadership and the PMs hadn’t had time to think beyond the infrastructure work. We would need a plan. To borrow a hockey metaphor, I was skating to where the puck would be.

I pitched the C-suite on what I was doing and got buy-in. I presented our work at a product team all-hands. Sure enough, there had been little planning done on what to launch in Q4. The design team’s work solved that. I met with senior PMs to break down the findings and plan out the work. We decided our big focus should be on gifting enhancements. We had queued up 55 tweaks, fixes, and general improvements to the gift-giving flow that became the consumer team’s priority. We launched them in time. What we saw was a dramatic reduction in customer-service contacts (the need for Drizly CX to contact recipients) and a flattening of order void rate. Historically gift-giving void rates were much higher than non-gift orders. For this holiday season, the rate was the same as all other orders.

 

Some unknowable answers are knowable

One fall while at Drizly, I was part of a lengthy discussion with senior leadership about developing in-store pick-up as a new feature for order fulfillment. Drizly is an alcohol delivery service, but the theory was that users may like to order ahead and pick up at the store if it’s nearby or on the way home.

This was actually a discussion that was had multiple times. We would discuss it, try to pull some numbers on the opportunity, feel the data was inconclusive. And then we would have the same discussion again a month or two later.

This felt like an unanswerable question. It seemed as though the choice was to build it and find out, or not build it. But results would be determined after it launched. There seemed to be no way to know ahead of time if users would want this feature.

I will state for the record that at the time, I thought it might be better to build the feature than to not because at the very least it would be something some people used so… bonus?

There was one thing that changed that fall. I had onboarded our first UX researcher. More interesting to me than whether we should build this feature or not — and be right or wrong about it — I felt this was an excellent opportunity to prove the value of UX research. After conferring with our new researcher, we developed a study that could help get an answer to this question and I positioned UX as the team to solve this question from the C-suite.

We conducted what’s called a Kano analysis where users are asked about a bunch of features to evaluate their interest in those features. It will show some signal about whether users think the feature is exciting, considered table stakes, or something that’s just not that compelling. We asked users about a bunch of features related to fulfillment — the last mile of the experience.

The findings of the study showed that users weren’t excited about in-store pick-up. People might use it, maybe a nice-to-have, but not a driver. What the study also showed was that user’ biggest interest was around transparency. Once an order was placed there was no information available until a driver showed up with their delivery. Users found this frustrating. Users were interested in more information about their order post-order. This led us to prioritize live order tracking.

Live order tracking for Drizly is a bit more complicated than the same feature on Uber Eats or DoorDash. With those examples, the driver is part of the delivery service (Uber drivers and DoorDash drivers). With Drizly the driver is employed by the store, so we have less real-time data to provide. This makes the service a bit more complex. But the Kano study and some additional user interviews gave us the confidence to build live-order tracking. We would launch it the following year to great success.

Drizly live order tracking

Design demonstrates impact

Three examples of design proving their value, showing the impact the team can have on the organization and the products they build:

  • Design able to properly diagnose the problem and deliver a solution that returns desired results.

  • Design able to anticipate organizational needs and develop quarterly roadmap planning when teams are focused on immediate concerns.

  • Design able to answer questions that seem unanswerable, identifying the features and innovation that users desire.

So yes, as a design team you should understand business metrics and organize your work around delivering those results. But more than metrics, design practices a methodology that helps organizations move forward — to identify opportunities and quantifiably determine the best paths forward.

image credit: Yulia Matvienko

The one thing leaders should focus on when building a successful team

Building successful design teams is something that I’m passionate about. I’ve had the opportunity to do this at several organizations and I think I have a certain talent for it. It’s definitely rewarding. Bringing together a collection of designers — of well-meaning people — and through process and coaching helping them to become a cohesive unit that elevates the output of each other and the larger product org.

I’ve talked previously about how I build teams. You can read about it here. What I haven’t talked about though is the one metric I most closely monitor when forming a team (and maintaining its health). That one thing is: team members’ talk time. I’m paying attention to how much time each member of the team talks in any given meeting or gathering. Is it roughly equal? Then things are good. Is one person or a small segment of the team doing most of the talking? Then we may have a problem.

The more clinical way to describe the metric is: Equality in distribution of conversational turn-taking.

It’s a little obvious when you think about it. Is the culture of the team such that everyone feels able to speak their mind, contribute, and have a sense of support and safety as they do it? Or are people reserved in meetings, worried about saying the wrong thing or and being criticized for it?

Project Aristotle

In 2012, Google embarked on an effort to identify what makes a team successful. What are the markers that all accomplished teams have? Researchers set about quantifying this and looked at all factors they could think of: previous success, years of experience, awards, educational background, years together. They looked at it from every angle they could measure. This research effort was code named Project Aristotle.

Eventually they began to focus on team norms. Through research, study, and various social experiments, they found that how a team was set up — the behaviors that were encouraged and the behaviors that were discouraged — had an outsized impact on the performance of the team. More specifically, this could be boiled down to equality in distribution of conversational turn-taking (team members’ talk time). When people felt safe to speak their minds in a positive and supportive environment, the collective intelligence of the group went up (leading towards more success). Conversely, when the free flow of ideas from members was hindered because people felt less safe to share, the intelligence went down.

All of this was written about in the New York Times Magazine back in 2016, in a feature issue examining the science of working more effectively. I read the article when it came out. This was early in my time as a design leader and the lessons have stuck with me; I think about them often. You should take the time to read the article yourself, which you can find here.

As the researchers studied the groups, however, they noticed two behaviors that all the good teams generally shared. First, on the good teams, members spoke in roughly the same proportion, a phenomenon the researchers referred to as ‘‘equality in distribution of conversational turn-taking.’’ On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment. But in each case, by the end of the day, everyone had spoken roughly the same amount. ‘‘As long as everyone got a chance to talk, the team did well,’’ Woolley said. ‘‘But if only one person or a small group spoke all the time, the collective intelligence declined.’’

Tending your team’s culture garden

Any group of team members will naturally form a culture, a way of behaving when together. These norms may be positive or negative. The only thing you can be sure of is that they will form. These norms are what an effective leader should be focusing on as their team forms.

One can be explicit in defining norms, and I think group discussion and affirmation of those norms is important. But what behaviors are written down aren’t necessarily how people act. It’s important for leaders first to model the behavior — adhere to the agreed upon norms. And it’s important to encourage the behavior, through conversation and consistency.

I think about culture and team norms like tending a garden. Provide the proper nourishment (encouragement and support) where appropriate. Weed out the elements (actions) that threaten the team’s growth. Be mindful and always attentive. Absence will lead to bad outcomes quickly.

Equality in distribution of conversational turn-taking

Which brings me back to talk time. In meetings with my team, I think about this often. I take mental note of who has spoken and who hasn’t. I solicit opinions from those who haven’t contributed. I do this in a positive way (nothing shuts down discussion like calling people out). I demonstrate real interest in what each person has to say.

I’m also mindful of my role as the boss and the weight that carries. And then I try to counteract it. In discussion I recognize that I can end discussion when I speak. Who’s going to argue with the boss? I try to withhold my thoughts till the group has shared theirs. I also encourage push back — I ask directly for people to disagree or critique what I’ve said. And I genuinely listen to the feedback.

As a leader, your job is not to have the right answer. It’s to build a team that consistently finds the right answers. Creating an environment where each member of the team feels supported and safe to share their perspective, to listen to others and adjust their thinking appropriately, is the best way to achieve this goal.

Talk time. Roughly equal amongst the diverse members of your team.

Seriously, take the time to read this New York Times Magazine write up of Project Aristotle and what Google learned about building effective teams.

Pillar 4: Establish a design-thinking mindset

 

Pillar 4: Establish a design-thinking mindset

Design thinking is a framework for identifying opportunities, exploring solutions, and testing them.

The benefit of a well-formed, effective design team is in how it transforms the whole organization, empowering everyone to think more critically and creatively in identifying problems, figuring out what to tackle, and the solutions they work towards.

This is design thinking, and while it has “design” in the name, it’s not just for designers. It offers a repeatable method for identifying opportunities, develop new solutions, and to validate those ideas, all relatively quickly. When this methodology is adopted by a whole squad, it superpowers their alignment and cooperation, and helps them work more effectively, autonomously.

Design thinking was popularized by the design agency, IDEO:

“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”
— Tim Brown, Executive Chair of IDEO

Its approach has been adapted into the Design Sprint, outlined in the book Sprint by Jake Knapp of Google Ventures. This is the way a lot of organizations first interact with the methodology.

I’ve taught design thinking at several organizations now, and it is often quite transformative. I’ve led design sprints at multiple organizations. At Liberty Mutual we were committed as a company to instilling this approach within our product org and developed a program that immersed whole squads in a month-long effort, called Digital Garages that taught the participants the methods and principles, and had them working on a core product problem, interviewing users, and building & testing prototypes.

Scenes from a digital garage

A number of things happen. First, team cohesion grows. Designers, engineers, PMs are working together and building bonds. And since no one is stuck exclusively in their domain expertise (designers in Figma, engineers coding, PMs in JIRA… sorry), everyone is working together and equally contributing.

Design sprint cadence

This also gives the larger team a greater appreciation of the skills and approach designers bring to the work. They start to realize that design isn’t “make it look pretty” but rather, a user-centered approach to solving business problems. After I’ve taught teams about design thinking, I see the efforts of designers to be more valued.

One last key benefit of design thinking is that it sets the team up for success going forward. I’ve facilitated a number of design sprints over the years. And while we make meaningful progress on whatever challenge we focused on for the sprint, the team learns this framework and leverages those skills and exercises in their work going forward. Where a team might get stuck on “what to tackle next?” before they were introduced to design thinking, the team will set up an effective brainstorming session* to focus on a real user need.

* unstructured brainstorming sessions are mostly useless and essentially action that isn’t actually productive. A design thinking ideation session is very different.

Teams have the tools to better define the problems and challenges before them, to break them down into key parts, and tackle them effectively, all without wasting time debating about what to do or how to do it.

 

In conclusion

I’ve found that investing in these four areas will turn a collection of well intentioned designers into an effective team that can transform a product org and help power innovation throughout the company. It’s simple enough, to outline, but takes a lot of hard work from everyone involved to achieve. And it does take time. But once you make headway on these pillars, the transformation begins to accelerate.

What do you think? Have you seen other foundational pillars for building a team that I didn’t address? Or do you have questions about the how to structure this? I’d love to hear from you.

 

Pillar 3: Elevate design execution

 

Pillar 3: Elevate design execution

Raise the bar for overall quality of what reaches users. Establish and meet a higher standard of excellence.

In companies with less mature design teams, focus is on expediency and less so on quality. Or more accurately, quality design is not defined. Get the work done quickly, hope it looks good, share visceral reactions but little in the way of constructive critique. As a result there is no way to truly execute consistently good design.

To elevate design execution, you must first define what “good” is. This is a step that is often missed in establishing an effective design team. Everyone has their own sense of what good design looks like (including non-designers). But this isn’t openly discussed and documented. When building a new team, this is something we spend some focus on: What is good?

This usually starts with an honest evaluation of the current state of things. Often one of the first things my team will do is complete a heuristic evaluation of the site or app (or both). It’s important to look at things holistically, screen to screen, review from beginning to end the complete user flow. Capture every inconsistency, every friction point, every potential area where the pushed live components don’t live up to the level of experience we want for our users.

The reality is that teams rarely look at the whole journey. They work on pieces of it with tight deadlines. Taking the holistic view is a chance for everyone to get a true understanding of what the experience is like. It also strips away the “we had to just launch it and move on…” excuse that often results in less than ideal experiences going live. Users don’t care what your constraints are.

And with heuristic evaluations completed, you will likely have a list of things to fix. And this is important because it signals to the rest of the product org a seriousness about craft. And it will also point to business impact (“fix this issue on checkout to improve conversion by X%”).

Design principles are an important part of defining good design. They help inform how one might design something, as there are often many different ways to solve a problem. Perhaps more important than having an agreed upon principles, is the act of creating them. This is an exercise that should involve all of the design team. The debates, discussions that will take place will challenge everyone and help crystallize for everyone what is important and should be the essence of the product’s experience.

Our team’s design principles

At Drizly we established a set of design principles. These informed how we would design solutions. For those who don’t know, Drizly was an alcohol purchase and delivery app that paired customers with local liquor stores. Orders had a minimum order amount. Design principle #5: “It should be enjoyable” helped inform the best way to address this. Initially we treated orders that were under the minimum as an error state. You order size is has not reached the minimum. We would redesign it to treat it in a positive light. We redesigned it as a progress bar, urging the user on and celebrating when the minimum was achieved. Both approaches are valid. But one is more inline with our design principles.

Over time, a shared definition of “good design” develops amongst the design team. It is important for this to happen organically. I certainly coach up the team and share what I see is good and what is lacking. But it’s important for the notion of “good design” is internalized.

This leads me to an important point: in the early stages of a design team, it’s more important to focus on process — how we make good design decisions — rather than any single design decision. If we build the foundation of a good design process, owned and championed by each designer, then we will more consistently make good design decisions.

To effectively elevate design execution, it’s critical that an agreed upon understanding of good design is developed by the whole team. If all design decisions have to run through the head of design — me for instance — then that leader becomes a choke point. You overly rely on the individual to make decisions and shut down growth and development for the design team. And it’s not scalable. And so in building design teams, I endeavor to coach the team on how to make good design decisions. This leads to more stable and consistent design execution.

 

Pillar 2: Drive design integration

 

Pillar 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.

 

Pillar 1: Strengthen design team culture

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.

typical design team calendar

The four pillars for building a successful design team

 

The four pillars for building a successful design team

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.

 

Cult of personality (testing)

Image credit: The Huffington Post

Question for creative directors and other design leads: do you use personality tests as part of your hiring process?

On a recent “Seeking Wisdom” podcast* about how to hire talent, David Cancel stated that he has candidates (and employees) take a personality test when joining his company, Drift. Specifically, he mentioned a free online site called 16Personalities.com.

*He starts talking about personality tests at the 17:00 minute mark.

 

When I heard this, I first hot take: “I get it, but it sounds a little creepy.” No one wants to be defined by the results of some test psychologists (or not) made up. I’m more than the results of some multiple choice survey.

But I continued to think about it. As a creative director and team lead, I recognize implicitly that I can’t manage everyone exactly the same. People respond to different management styles and interactions. I view it as my job to learn what style works best for each individual and adapt my approach accordingly.

I think back to the teams I’ve lead over the past few years. I’ve had both extremely extroverted designers and others that were quite shy. Some do well in a group setting where ideas are being explored and others I could get more out of with 1:1 discussions about the work. I would always encourage discussion from those that would sit quietly (and sometimes get the more outspoken members to dial it back a little). What I’ve learned is that the work is greatest when the team collectively contributes. So I have tailored what I say and do to each person working on my team.

*for a great long read on team dynamics and better production, check out this NYT Magazine piece about Google’s research into how to build the perfect team.

And this is Cancel’s point. To be an effective manager, you have to recognize that each designer, developer, etc. is different; manage appropriately.

So I took the 16Personalities.com test. This was my first time taking such a test.

My result is ENFJ-A

16Personalities.com labels me as a protagonist personality.

“Protagonists are natural-born leaders, full of passion and charisma.”

I confess, I feel like sharing that is a bit of a humble brag. But the takeaway is that I felt the description was true about me (though I don’t think of myself as extroverted as the result suggests… ok THAT was a humblebrag).

The result was for me indicative of my personality (or so I think). And if that’s the case, it can possibly point the way to other testers. And information like this is helpful in managing people.

my test results

my test results

I don’t think a manager should consider the result of a personality test as ironclad. New information and insights about a person and their behavior will always be forthcoming and a good leader needs to recognize that and continue to evolve their approach. I don’t know that I like the idea of using the test as deciding factor in hiring. But I do think it can help the manager better manage people.

So back to my original question: anyone out there using personality tests in hiring?

At my company — a large, global agency, I don’t think the lawyers that be would allow me to incorporate this tool (to be fair, I’ve not asked). I suspect anyone I brought this to would stop at my own initial thought. But I think using such a tool in the proper way, and properly weighted (which is to say, not definitive), it could be a valuable tool.

What does everyone else think?