Driving Impact Through Design: A Fireside Chat with Alissa Briggs

Alissa Briggs is a leader committed to elevating design teams around the world. She’s done exactly that in leading and scaling top-notch design orgs at companies of all sizes, coaching countless designers to take their impact to the next level, and guiding startups as an advisor here at Designer Fund. Alissa now leads user experience, architecture, operations, and culture for an 80+ person global design team at Autodesk. Prior to that she was Head of Design at construction productivity app, PlanGrid, where she grew its design organization from 5 to 25+ team members.

In a recent fireside chat moderated by Enrique Allen, Alissa shared invaluable lessons on driving significant business outcomes through design decisions, navigating a company acquisition, using facilitative leadership to align and empower her team, and more. Below, we've put together a lightly edited and consolidated version of the conversation.

Topics covered:

How to Choose the Right Company to Join

Enrique Allen: I’d love to hear a little bit more about how you evaluated the opportunity to join PlanGrid, and what convinced you to join. There's a lot of designers in our community who are curious about joining fast-growing early stage companies.

Alissa Briggs: When it comes down to picking a place to go and spend some time, I consider a few different things:

  1. First and foremost, what are the values of the company? In the past, I've joined places where I got a little bit burned because I found that my personal values didn't align with the company’s values. When I was considering joining PlanGrid, it was important for me to get to know the founders and other people I’d be working closely with, to get a sense of their shared sense of integrity and how much they valued solving for customers.
  2. I also look at the health of the business. I’ve built out a personal philosophy that if we want to have amazing design in a company, it needs to be extremely clear how great design contributes to the business bottom line. I think that alignment of the business and the customer needs lends itself to being able to do great design work.
  3. The last thing I look at is my own personal growth goals. Before joining PlanGrid, I was at a point in my career where I had built out my design portfolio and developed my management skills in the consumer and enterprise world, but what I was really excited about was learning how to scale a company and scale a team.

When I was going through my job search, I specifically looked at series B companies with great traction in the market, strong product-market fit, some beginnings of a good team, and especially lots of room for me to bring structure, a clearer vision, and strategy to the design team—and the ability to grow the design team alongside the company’s maturing.

How to Drive User Adoption in an Antiquated Industry

EA: When building software for people in a more antiquated space like construction, how do you balance mirroring their existing workflows to help them better adopt what you're building, versus creating new workflows that are potentially more efficient, but less familiar?

AB: Because PlanGrid was helping replace and digitize blueprints, we specifically designed the UI to feel a lot like using a physical blueprint, taking cues from how people mark up and swipe through the pages. Using those real-world metaphors was super important for getting early users on board because construction is one of the most antiquated industries. I regularly talk to construction workers who don't have an email address and haven't touched a computer. So being able to hold the app in their hands in a way that feels just like paper helped them quickly learn how to use the app.

We also look for moments of magic. For example, people used to spend weeks or months manually breaking up and keying in 1000+ page documents into Excel so that each line item could be reviewed and approved. We came up with AutoSpecs, a tool that automated this work through some wild behind-the-scenes operations, taking the process from months to minutes. It was also fairly simple to set up and use. When we showed the tool to customers, they'd say, “whoa, how did you do that?”

So I think finding that mix of familiarity and wizardry is a great way to get people interested in picking up and trying out your product.

Digitized blueprint viewed on the PlanGrid app | Photo by Jesse Dodds

How to Lead Your Team Through an Acquisition

EA: As you navigated the acquisition of PlanGrid, there were probably changes at the team level and at the business unit level of this huge company. Can you talk a little bit more about how you navigated the acquisition and any major lessons you learned from the process?

AB: For context, Autodesk acquired PlanGrid in 2018. So I've been on this journey of bringing our teams together for the past couple years. When PlanGrid was acquired into Autodesk, it was interesting because we already had quite a large R&D team and Autodesk was a 12,000-person company. Both organizations had strong opinions about their identity, how they liked to work, and what great design and product mean.

There was also a lot of suspicion about each other. On the PlanGrid side, we thought, “here comes big, old Autodesk.” Then on the Autodesk side, people were like, “who are these hot shots? They think they know so much, but they don't understand our legacy and what it looks like to operate at scale.” There was a lot of figuring out how to build respect and partnership on both sides, and to grow trust over time.

One of the things we did was to define opportunities and projects that required teams from both sides to work together. That naturally led them to learning about each other and building empathy. Not allowing people to stay in their respective camps was an effective way to blend the culture of the teams.

We also worked together to create a shared vision of how we would bring our products together. Both Autodesk and PlanGrid teams were excited about the prospect of building a comprehensive construction platform—bringing together Autodesk’s existing construction tools, and the magic of PlanGrid.

However we quickly realized that over the years, Autodesk and PlanGrid had both built several, competing products. We needed to clarify our story to the market and create a cohesive experience. We had many difficult conversations and debates about which pieces of technology to pull from each side and how to stitch everything together to create a comprehensive experience. Fortunately we were able to come together as a team and accomplish something ambitious. We successfully launched the unified Autodesk Construction Cloud experience about a year later, much to the delight of our customers!

Coming out of this acquisition experience, one thing I reflected on a lot is the importance of being very honest with your team and sharing as much information as possible. When there are two large camps like this, you can easily end up in a situation where there's a lot of mistrust, where people are making assumptions about each other and getting defensive. As a result, they try to hold onto what they have.

Some advice that’s a bit counterintuitive is telling people from the start: “it’s going to be hard and we’ll need to change, and that’s okay. Evolving is good. Growth is good. Let’s honor and celebrate what we did in the past, and then look forward to the journey ahead.

Alissa and her team on a hike | Photo by Jesse Dodds

How to Build a Design System, Brick by Brick

EA: At PlanGrid, your team built a design system that enabled the company to deliver stronger user experiences, more efficiently. It was also highlighted as a key strength during the acquisition. Can you tell us about the process behind building the design system from the ground up?

AB: A lot of people ask me, “when do you know if you're ready to build out a design system?” and it’s a good question to ask because if you wait until you have 50 designers and everything is a mish-mash, it’s probably too late. That said, if you're the sole designer at a five-person company, it's probably too early to invest heavily in a design system because you're still finding product-market fit. I think finding the right timing comes down to looking at things like what the UI looks like today, how aligned the team is, and if there are clear opportunities to improve the consistency and speed up decision-making.

When I joined PlanGrid, there were about five designers. Everyone was working closely enough together and there was some level of alignment. But in reality, things were starting to get messy. Because this was pre-Figma, we had Sketch symbols stored on Dropbox and 50 different button tiles, and people would often forget which one to use.

We felt that it was time for us to spend a few cycles getting a design system together, aligning on what it was going to look like, how it was going to feel, and maybe even investigating some technical components for the system. The problem was that we didn't have everyone at the leadership level on board to go all in on the design system. So we ended up going with a phased approach to building a design system that started with tackling the low-hanging fruit, then demonstrating the tangible benefits, and eventually getting the executive buy-in we needed to fully staff out a team.

A peek into PlanGrid’s design system components

PlanGrid’s Phased Approach to Building a Design System:

  1. Simplify the typography: One of the first things that we did as a proof point was combining and unifying our fonts. We had a million different fonts in the past but we went through them and chose just one. We saw big benefits from that single decision in less than a week. Simplifying the font reduced our page weight and made everything look much more consistent.
  2. Define the colors: We also unified our color system, which the engineers really loved. Previously, the color codes in everyone’s Dropbox files didn’t quite match (e.g. “is it 0,0,0 or is it 0,0,1?”). Just by putting color variables in place, the engineers started to talk about how much more efficient they were getting. The impact was easily noticeable.
  3. Scale the system: From there, we identified larger changes that needed to be made, got the engineers who had helped us with our early projects to advocate for more investment, and over time, we were able to hire a proper team, which was amazing. We also ran a bunch of ROI calculations—especially as we started building out technical components—to show the number of person hours that were saved each time we built out a proper component.

How to Make a Business Impact Through (Seemingly) Small Design Decisions

EA: Any other stories about design decisions or initiatives that had an impact on the business?

AB: One story that comes to mind for me was around a small—but super impactful—navigation change. PlanGrid initially started out as a sheet-viewing mobile tool that allowed you to look at blueprints on an iPad. At the time, we were trying to shift our business model to be less focused on blueprints and more focused on construction productivity.

There was this tiny little icon in the corner, and if you knew to click on it, you would get access to all these really powerful tools around communication, problem-solving, and various construction processes. We affectionately called this icon the “junk drawer.” The problem was that basically no users knew the junk drawer existed, and had no idea that other tools were available to them!

One of the designers on my team came up with a prototype where he took all the navigational elements out of the junk drawer and instead pulled them out into a main navigation at the bottom of the iPad app. This allowed you to see the full functionality of the app immediately.

It was a navigational change that wasn't that hard or that expensive to make. Yet it ended up being the number one most impactful change we made that year. Usage for each of those areas shot up because they were finally discoverable. Even the way that the sales teams did demos changed because they shifted from giving a tour of the blueprints to showing the overall app, with each of the navigational elements. This also helped to communicate how we were shifting our brand from a blueprint tool to a construction productivity app which was crucial for fundraising and market positioning.

The PlanGrid projects dashboard, before (left) and after (right) the navigation changes.

How to Identify UX Improvements Through Cross-Functional Collaboration

EA: Have you ever experienced stakeholders being wary or skeptical of the impact of improving the user experience? If that’s the case, how did you approach getting your work prioritized to help improve the user experience?

AB: All the time. I think there’s always a tension between shipping new features, fixing bugs, and making investments to improve the UX. One of the things I've found to be most helpful for building the case for user experience improvements is to frame them in terms of business impact. At PlanGrid, that meant viewing the sales, marketing, and customer success teams as key partners for us in identifying the areas of the user experience that needed to be improved and then making those changes.

Sales folks actually really want a good user experience. Some of the UX improvements we made to our navigation and workflows translated directly into how easy it was for a salesperson to pitch a customer on the product. So every time we were looking to make UX improvements, we talked to sales. We’d have them pull quotes from customers who were struggling, then after we made the changes, we went back to the team to ask about the impact, keeping an eye on how their demo changed.

The same went for the customer success team. They regularly conducted trainings for new PlanGrid users, and over time had developed a very good sense of what areas of the product were confusing to new users. We decided to set up processes to shadow and learn from the customer success team to help us identify major UX issues. We made these improvements so that it was easier for any user to walk up and use the product. The customer success team was happy that they were able to help shape the product, and that in trainings, they could now spend less time explaining confusing UI, and more time going deep into the selling points of the product.

How to Be a Facilitative Leader

EA: You’ve previously talked about facilitative leadership, and I do think it's a hidden superpower of designers and design leaders. Can you tell us a bit more about facilitative leadership and how you've used it to foster collaboration?

AB: Sometimes when people say “leader”, they’re imagining the smartest, strongest person with the best ideas, who rallies everyone behind them and tells them what to do.

But I think real leaders are people who understand that the best idea is not in their head, but rather in the space that exists between all of our heads put together. I see facilitative leaders as those who really embrace that and look at their job as being someone who brings folks together to collectively get to the best ideas, have everyone feel bought into and aligned with those ideas, and then bring them back to the day-to-day work.

A lot of what I do as a facilitative leader is helping guide people through processes of brainstorming, ideation, synthesis narrowing, and then having clear decision-making frameworks to help them move forward.

Alissa Briggs
I think real leaders are people who understand that the best idea is not in their head, but rather in the space that exists between all of our heads put together. Alissa speaks at EuroIA | Photo by Peter Vermaercke

EA: Any favorite decision-making frameworks?

AB: I think the biggest thing is that whatever framework you use, be clear about it from the outset and make sure everyone is on board. I'm a big fan of DACI (Driver / Approver / Contributor / Informed): clarifying each person’s role and not changing them halfway through the project. If you decide that someone is going to be the final decision-maker but later change your mind, that’s very disempowering and throws the team’s whole decision-making process off.

It’s also important to be clear on what technique you’ll use to make the decision itself. That could look like voting (taking a majority rule vote), full consensus (every single person getting on the same page), or it could be that one person is going to listen to everyone else's opinions, and then they will make the final decision and their word will be law. As a leader, you need to be extremely explicit and avoid revisiting the decision again and again.

EA: And when do you bring that up in the project? At the kickoff? The midpoint? It seems like it can get lost in the back-and-forth and chaos.

AB: As early as possible. At Autodesk, we use a very structured decision-making framework that requires every person who’s leading a project to create a project plan and go through DACI at the beginning. It’s essential that we do this–and that we do it early–because Autodesk is such a big company with many heavily interconnected departments and teams with strong opinions. This has really helped speed up decision-making at the company while also helping people feel clear on where and when they should be offering opinions, and how that will impact them later.

Key Lessons from Alissa

  1. When choosing a company to join, consider these three things: the values of the company, the health of the business, and your own personal growth goals.
  2. Trying to get your UX work prioritized? Partner up with cross-functional teams like sales and customer success.
  3. Remember: even the most simple, inexpensive design decisions can have the biggest business impact.
  4. When building a design system on an early stage team, start small to demonstrate impact and get executive buy-in (also, identify internal advocates from other teams early on).
  5. Consider honing your facilitative leadership skills to create healthier, stronger, and more collaborative teams.

Header image by Jesse Dodds