Abigail Hart Gray, Director of UX at Google, is one of the most inspiring design leaders we know. A self-proclaimed analytics nerd, Abigail uses numbers to deftly communicate the value of design to her colleagues, giving her team the runway to do great work.

In this episode of the Design Better Podcast, Eli and Aarron get Abigail’s take on measuring design’s impact on business, how parenthood has changed her approach to problem solving, and more.

Bio

Abigail Hart Gray is the Director of UX for Google, where she champions user-centric design practices for the Ads group. Previously, she was VP of Design at LearnVest (part of Northwestern Mutual). Abigail has also brought her UX expertise to clients like AOL, American Express, JetBlue, the BBC, and more. Follow her @abigailhartgray.

 

 

Google’s Abigail Hart Gray: Communicating the value of design

The following is a complete transcript of this episode of the Design Better Podcast.

Enjoy the episode!

Introduction

Abigail Gray: We can design towards anything. The great thing about design is that there’s no one solution. So, when you find the places where you can all agree, “Okay, let’s merge it towards this goal,” I think that’s the way to start building a relationship and building trust because you want to show them that you care about the same things they do.

Narrator: This is the Design Better Podcast, where we share lessons and insights from today’s foremost design leaders. We hope the conversations and stories you hear help you transform your design practice and build remarkable products. In our third season, we’re exploring the connected workflow: how designers work more effectively and efficiently with their engineering and product counterparts. We’ll talk about how building key partnerships throughout an organization can help you ship better products faster. This podcast is hosted by Aarron Walter and Eli Woolery and is brought to you by InVision, the digital product design platform powering the world’s best experiences.

Eli Woolery: Sometimes you know someone’s a good leader just by listening to them. This is certainly the case with Abigail Hart Gray, who we first got to know through a profile of Northwestern Mutual in the Design Genome Project, where she was VP, head of design. Here’s one of our favorite quotes by Abigail from that report.

It reads, “A/B testing is great for small optimizations, but if you need a revolution, you don’t find that in an A/B test, even if you run 100 of them at a time.” Now, a director of UX at Google, Abigail is bringing her leadership skills to a bigger organization with bigger challenges. Because we were speaking with Abigail just a few weeks into her new role, we mostly focused on her experiences at Northwestern Mutual, specifically topics like the workflow between designers and developers, how she brought developers into the design process early, and how she got the right people involved from the start of projects. So get ready to listen to a great leader, and we hope you enjoy this chat with Abigail.

Aarron Walter: We also wanted to share a fun, easy way to get more from Design Better Podcasts at home. The Design Better Podcast is available as an Amazon Alexa skill for Echo. Simply say, “Alexa, play the Design Better Podcast on TuneIn,” and you’ll hear our latest episode. Thanks for listening. Now let’s start the show.

EW: Abigail Hart Gray is a design leadership powerhouse. She grew the design team at LearnVest after it was acquired by Northwestern Mutual by 10x in two years and is now a director of UX at Google, leading the charge on digital video ads for the sell side and buy side. We spoke with Abigail earlier this year about her team at Northwestern Mutual, and now we’re back to revisit some of the lessons she learned and hear about what she’s hoping to accomplish at Google. Abigail Hart Gray, welcome to the show.

AG: Thank you so much. It’s a pleasure to be here.

EW: So Abigail, you’ve had a lot of experience working with large teams and building teams, and it’s not always easy to connect the design org to the rest of the organization. I’m curious, in your experience at LearnVest and now at Google, you’re just a few days into the new role, but how do you generally approach connecting the design team to the rest of the org, engineering, product, et cetera?

AG: That’s a great question. I think it’s really all about relationships and finding the overlap between what you’re trying to achieve within the design group and what product and engineering are trying to achieve as well as the business partners. When you find that common ground of the things you all want, you can design towards that.

So one of the things that I always like to do is find out what do other people care about. What are the metrics that they’re trying to effect? We can design toward anything. The great thing about design is that there’s no one solution. So when you find the places where you can all agree, “Okay, let’s merge towards this goal,” I think that’s the way to start building a relationship and building trust because you want to show them that you care about the same things they do because there’s always a lot of overlap.

EW: I’ve heard you describe yourself as a bit of a metrics nerd. Is that accurate?

AG: I am. I’m metric obsessed. Yes.

EW: So, this is interesting to me because it’s not something we often hear from a lot of designers and design leaders: that design can be a bit squishy. It can be subjective, often seen as the voice of the customer. But you have brought metrics and KPIs to your teams in the past. Can you talk about why that’s important and what does that do for the design team and its relationships to the broader company?

AG: The way that I got to being obsessed with metrics is because of my unique history … or semi-unique, I don’t know. I started a design firm when I was 23 years old in the naive way that only a 23 year old can. And I had to find a way to prove that I was worth what I wanted clients to pay me. So, the way I found I could do that was I would sort of give them like an entry price for the first project and then prove that whatever they wanted to be the outcome actually happened and then charge them like 5x, 6x, 7x for the next project because they knew I would achieve the results that they wanted.

So I guess I got obsessed with metrics at a very young age, but it’s actually served me well moving into the business world because that’s a way for me to find ways to quantify the value of design to the larger organization. So, I adopt what metrics are important to the business, or I work with my data counterparts, my product counterparts, my engineering counterparts to find whatever proxy for what we value as a company that can be measured.

It’s baselining where you are and then finding out what the power of design—and usually, let’s be honest, the power of collaboration—does for those metrics, because a design idea that never gets built is nothing, it’s pretty pictures. And an engineering idea that doesn’t have a good UX on it isn’t going to be adopted and used the way you want it. And a product idea without any designer or engineers kinda doesn’t go anywhere either.

So you can achieve more and show that you actually impacted something that really matters when you do that kind of before and after comparison. A previous manager of mind said, it’s playing moneyball. So I liked to play moneyball in design.

AW: That’s awesome. So we usually kind of try to avoid talking about our own tools and our own platform. But last time we spoke, you had this really intriguing way you were using InVision to measure your team performance when you were at LearnVest/Northwestern Mutual. Could just talk about that a little bit?

AG: Well, I’m a super big nerd. So, every year at the end of the year I would do the year in design. And although a lot of it was sort of feel-good stuff showing what we had launched, we measured a lot of things. So, the ways that I would show our productivity as a team, as we were exploding from seven designers to 70 was I would show how many screens have been uploaded into InVision that year, how many prototypes had been shared, and how many comments, which was a proxy for just like how many people were interacting with design as a way to show how we were kind of infiltrating, if you will, the rest of the organization. And that became a core part of that yearly celebration of the achievements of design.

EW: I want to play devil’s advocate with you here. I wonder if there’s a point at which metrics could be a bit of the tail wagging the dog, that if we align metrics all the time, if design is always aligned to broader metrics of the company, if that shifts the values of the team. So for instance, if the KPI is, “Let’s generate a bunch of MQLs,” or “Let’s generate X amount of revenue,” could it cause the focus to be less on the experience of the customer and more on the outcomes that we want to create for the business?

AG: Well, I think you’d be really careful about what metrics you use. Statistics, everybody always says, can be very misleading depending on the way you use them. Metrics are the same way. So, if you’re talking about task completion rate or, in e-commerce, reducing the drop off from the shopping cart to actually the purchase click. Those are really key metrics that show that your experience is getting better.

If more people are making it from a declaration of intent, like putting something in their shopping cart through to purchase, you know you’re doing a better job. So I think it’s about being really careful in how you measure things. The other part of it is some of our metrics, I don’t want to say they were squishy because they were hard numbers and they’re measured of my group, but for example, LearnVest/Northwestern Mutual, we measured how many of our clients thought we were making continuous improvements for the better.

That was something I always kept an eye on because that’s telling me, “Okay, what percentage of our audience actually thinks we’re making improvements versus being stagnant,” which you never want to be. Or, worst case scenario, thank goodness this never ever happened, but we were not making any improvements for the better. And if you see that kind of number rising, you know you’re pointed in the right direction. So it’s about finding the right way to measure your value. And well, revenue obviously for all businesses is really important piece. There’s often proxies that tell you a better indication of how the experience is improving.

AW: One other thing along that theme that was really interesting last time we spoke to you, I’m going to pull out a quote, let’s maybe a little bit of paraphrasing, but you said that A/B testing is great for small optimizations, but if you need a revolution, you don’t find that in A/B test, even if you run 100 of them at a time. Could you talk a little bit more about that?

AG:  Yeah, sure. So I think a lot of companies are coming up against the fact that they started with an experience at X point in time, and they’ve been iterating on it and adding to it and there’s new features or market conditions change, and all of a sudden, you’ve got an experience that’s a little bit Frankensteined. It’s the exquisite corpse of building on top of something else, and you’re not going to get a beautiful portrait of a person doing that.

So if you really want to change the game by 10x, which is something I’ve heard already in my first two weeks at Google, “We don’t want to change something 10%, we want to change it 10x.” You can’t do that with small little A/B tests. That’ll help you localize small problems that can have a big impact over time, but not that kind of step level change when you want to revolutionize something. And that was something we recognize really early on with LearnVest/Northwestern Mutual in terms of the client experience as well as the field facing experience for our sales force. And that’s something I think that’s always strived for here at Google as well.

AW: Do you have any stories around products that you made that step level change, that little revolution in your time at LearnVest/Northwestern Mutual that you could talk about?

AG: I think the whole lauding client portal was an example of that. So in my first year, I asked our EVP of client digital experience what he cared about, and he said he wanted to increase client adoption. He wanted to see people signing up for paperless billing and for paperless document delivery. He wanted people to be more engaged with us. And so when we come back and looked, by the time I had left we had 6x client adoption.

We had somewhere in the neighborhood of 2,100% increase in e-delivery. And when we reduced by about a third the time between visits, we knew we were becoming more relevant to people. That’s, I think, step change. Those were big shifts for that audience. And we’re really proud of helping Northwestern Mutual achieved those results.

EW: One thing I find really interesting about your approach is that when you step into a new role, and presumably this is already running through your mind in your new role at Google, how do you come in and create value for the company, win the team’s trust, start to win partnerships, this whole idea of connecting a workflow really has to happen. You know, as you described earlier that through building rapport and relationships.

And part of that, especially at a place like Google where there’s a lot of smart, talented people, you’ve got to come in and show your mettle, you’ve got to show what you can do. And you had an interesting approach at LearnVest. When you started was a different scenario. At Google, design is an understood and valued quantity and it’s being invested in, at a Northwestern Mutual, a large organization with a long history, a company that is still learning what’s possible for the business with design. So can you talk about your strategy of how you walk into a new organization like that and to a new role rather and show this is the value that design can bring to the business?

AG:  I’m really lucky because I’ve gotten to be at a few different companies in very different industries, and that forces me to, or gives me the opportunity to, go on a listening tour and learn. So, the first thing I always do when I walk into a new organization is meet as many people as I can. Ask them about what’s going well, what’s not going well, explain to me things as you see them.

Once I have a good bit of information, and after I feel like I understand the landscape, what I like to do is pick something which has no value to the company currently, little or no value, and choose that to do a rapid kind of workshops, sprint process to rebuild it oftentimes with no new functionality. Because if you’re going to do that, you may not really get to add any new exciting features if you want to get it out quick, but to turn it around and show how it can be something of value to the company.

And if I target the right things, I’ve found that I can build a lot of trust. For example, when I walked into LearnVest/Northwestern Mutual in my second or third week, we decided that the logged in dashboard for our clients was the best test case for that, right? Had no impact on revenue. It was not impacting the greater metrics, as I mentioned before of client adoption, electronic document delivery, and account aggregation that we wanted.

So I decided that was a fantastic test case because one, metrics wise, there was nowhere to go but up, and two, nobody really thought that much of it. So if I did something that people didn’t like, it wasn’t going to negatively impact any real sort of major company metrics in any way. Took a small group of product folks, engineers. We did a workshop, it was the first design workshop that they had ever had, and in six weeks we had redesigned, rebuilt, and relaunched this logged in dashboard.

So, when you type in your credentials, it  was the first place that you would land. And within six weeks, we were getting some really good indicators that things were going well. We had over 300% increase in account aggregation. We had 29% increase in client adoption. We saw an 86% reduction in the bounce rate. And I’ve found that when you take something really low value, you can turn it into something that really works for you because people see you as almost like a miracle maker, right?

Wait, they didn’t do any new features. In that case, it was still on an old tech stack that we knew was going to be deprecated in three months after we launched it. But we could still use the design work obviously. And so then it was like, “Oh my goodness, you guys made it rain and it was a drought forever.” And it’s the opposite when you take something really big. I think a lot of designers, they get so excited and they know they can do big things and so they go after the big shiny apple and this thing that is super important to everybody because they want to make an impact and it’s a great impulse.

But when you’re going through that process, you can also make people really nervous. If you’re going after the cash cow, you do not want to mess it up because then design will be responsible. And you also may not know enough and really have the relationships with people so that they’re like, “All right, this is scary, but I trust you,” instead they’re like, “Who does this person think she is going after our most important asset here?”

And so this has become a little bit of playback of mine. I’ve done it the wrong way at places too, but we did this at AOL and it worked really well for the AOL APP. I did it at LearnVest and it worked great for the summary page when you logged in. I don’t know what it’s going to be a Google yet and I’m excited to find out. But it’s a very large and very complex problem in the ads worlds of the buy side and the sell side software that we’re dealing with. So right now I’m still in my listening tour.

AW: That’s great. So you mentioned workshops as part of that strategy, and I imagine it’s a great tool for bringing teams together early on, especially if you’re building those relationships. Could you talk a little bit about the workshops?

AG: The workshop serves selfishly two purposes, right? So one is of course you make everybody feel part of whatever it is that you’re doing so that they’re buying into whatever the result is. But also as a new person coming into an organization, their knowledge, their intellectual capital up there in their heads is so valuable to you. So, you really get to absorb all of their knowledge, and they’re helping you do your job well.

So, it is a mutually beneficial activity to do, and I think it can be very fun, and it can be exciting to spend two days in a room with people. And in the case at LearnVest, we all went home, and I sent them out to dinner at a great New York City restaurant, and I went home, put my daughter to bed and then wire framed until about 2 AM so the next day I could put those up in front of people, get their critiques, which were fantastic, and then have an idea of where we needed to go.

It serves that dual purpose really well because the people that have been in an organization longer than you just can offer so much to help give that kernel of insight that you can springboard a whole kind of trust building design activity off of.

EW: You talk a bit about how you sell the idea of getting involved in a sprint or a design thinking workshop because you know, depending on where you are. So at Google, that’s not going to be a hard thing because sprints are part of the culture. It’s just in the water there. But at other organizations where they don’t necessarily understand what a sprint is, what’s required of them, they might feel reticent to sketch or participate in a design activity because “I’m not a designer.” How do you bring people into that and get their buying into the process?

AG: To be totally honest, I don’t think designers give people the benefit of the doubt. Yeah, some people might be scared to sketch, and there was an instance where we did design workshop at a previous company and somebody who is not a designer started crying when we suggested that people sketch stuff out. But that’s only happened ever once. And I’ve done a lot of workshops, and then we just gave her a designer and all of a sudden she had a scribe, and it was okay.

And by the end of, in that case, it was a four-day workshop, she was psyched and she was doing her own sketches by the last day because you have to just show people, it doesn’t actually matter how well you can draw, it’s about getting your ideas out and in front of each other. So we do a lot of telling people upfront when they arrive in the room what we’re going to be doing so that they know what to expect and not telling them too much beforehand.

If somebody is really unfamiliar, maybe they’re thinking they’ll just come and tell designers what to do, which is fine because you need their brains. So when you get them in the room, you can explain. The other thing that sometimes we do is we’ll pair up groups of non-designers with the designer whose job is to be their scribe.

And inevitably there’s some good dialogue that comes out of it and people will pull out their own pens and paper and start trying to show the designer exactly what they’re thinking because everybody imagines something different. And the other really key thing is snacks, because the quality of the food I think results directly in the quality of the feedback. So, make sure you’ve got plenty of yummies to help people’s brains stay active and keep them talking. And I’m not above bringing in sugar to get people talking.

EW: That technique works on 4 year olds and 40 year olds.

AG: Being a parent has been the best thing for teaching me how to be a better designer.

EW: Tell us more about that.

AG: I have a fantastic daughter who loves to draw and paint, so we never have any trouble getting her to do that. But I think being a parent, it teaches you patience. It reminds you what it’s like to have somebody in front of you who hasn’t had whatever experiences you’ve had, and you remember to stop and explain before you go to, I took my daughter to a Broadway play, and she was very confused.

Would these be real people, where is the screen? It was Frozen on Broadway. Would there be a real snowman and did she need her coat? And it was so great because it sort of takes you back to say, “Remember what it’s like to know nothing about something, and everything is new and exciting?” A lot of times going into these workshops, people have the same kind of fear. They don’t know what to expect. They’ve never been in this before. And it’s an opportunity to actually give them a positive experience of what it’s like to work with a bunch of designers and to have some fun doing it.

AW: So, at Northwestern Mutual, you were part of a transformation as the company was moving more heavily into digital territory and design thinking is a powerful way to power that transformation. What are some of the ways that you experienced design thinking as a tool for transformation?

AG: The biggest way in which design thinking is a tool is the way that it teaches empathy. Because, usually the problem that businesses have when they’re in the midst of a transformation is that they’re thinking from the “inside the company looking out” perspective, instead of remembering to look from the outside into the company. That’s where a lot of times when companies hire agencies for example, and you go and you look at the navigation on their website, you think, “Oh God, this reflects their internal structure and not how people actually think about their products or services or what have you.”

That’s just the most common problem, and yet what design thinking asks you to do is one, not be prescriptive about the answer but to first think about the problem and think about the people experiencing that problem. And only then to be very open to the possibilities of how you may solve that problem, and to come at it from a different angle. So I think that is maybe the most salient way that design thinking changes how companies are solving problems and transforming themselves.

EW: One of the most important partnerships that designers have is with engineering developers. And I’m curious, in your experience, how do you build rapport, build understanding, bring that notion of empathy that you just described to your colleagues in engineering just to make sure the process is seamless, communication is clear, transparent. How do you build that connection with an engineering org?

AG: I’m not sure it’s any different from building a connection with anybody else. It’s understanding what they want, how they approach things, what they’re worried about, what they’re excited about. I would say where I’ve gone wrong in my career is making assumptions. Maybe it was having to read out a usability study of an experience and not inviting my chief architect, which happened at LearnVest.

And he came to me and said, “Abigail, I heard you did this research on this experience we’re launching. And there was really good critical feedback. I want to know what the users think of what we’re building. I really want them to like it. Can you do another read out or invite me next time?” And I was like, “Oh my gosh, what an oversight?” Here I was like, “Oh you know, one in a bunch of usability studies we’re doing in this experience.”

But it really opened my eyes to how even blind I could be in not understanding how much overlap there is and what the engineering team was interested in and what I was interested in. And so then I just started meeting with this gentleman regularly and asking him what was his team doing? What were they interested in? What were they curious about? What did they want to explore? Could we do that together? Could maybe set up a charrette and have everybody work on that together?

And then people are so much more eager to actually engage with you and spend that like shoulder to shoulder time even on the more mundane things like design QA, that it’s really just talking to them and getting to know them and what makes them tick and makes them excited about their work, I think is what everybody wants. I think that’s design thinking actually. It’s empathy.

AW: When we last spoke to you, you had an interesting perspective on QA that at least I hadn’t heard before. Why do you think QA is an important part of the design process?

AG: QA is so important because ultimately, it’s the way to ensure that all the time you’ve invested in the product requirements and your wireframes and your comps and making sure that everything comes together seamlessly. If you don’t really diligently QA that, it’s kind of like you’re giving somebody else your child to take care of or you know, closing your eyes and letting somebody else do your makeup, which just never comes out really well.

It’s not sort of taking things to the finish line, and I think you have to be willing to invest that time and that collaboration because things come up when it’s being built. That’s one of the things that I think so many designers are working through right now is what is the best tool to communicate how I really want this to be? And so far, I don’t think there’s any perfect way that any designer has figured out to prototype every single interaction in every single moment that they want to be delightful. We create patterns and then we make those extensible, but other stuff comes up.

EW: So just a little build on the QA question. You actually sat down with the head of QA and created design QA process together. What was that experience like?

AG: It was awesome. So the head of QA at LearnVest, he and some of his team would come up with this 12-point checklist, which I thought was fantastic, but they wanted to know how to deal with design, right? And so we actually ended up white boarding it together and figuring out a process to make sure that we can still move quickly and get things launched and have a collaborative way to assess what were blockers, what we’re fast followers, what maybe weren’t that important of whatever is found in QA.

And then we put it up on Confluence so everybody could see what he and I felt like were important things to do and considerations to have before you launch something. And it was the first time I got to do it like that, which was really neat. And then about two and a half years later, we got back together, and we’re like, “Should we revisit this? Let’s update it, let’s make a new diagram. Now we have these things. All right, cool.” And we did it again, which was so fun.

EW: Can you talk more about those steps? What does a good effective QA process look like for design?

AG: The first step is for the engineering team to decide how they want to engage with designers and QA. Because what we found is that there were some teams who wanted to do it, let’s say like five hours at the end of every sprint where the designer and the QA person could sit together, and they could go through all the bugs together face to face. Other teams, they could be a little more shy. They wanted to go through many sprints and then give us a heads up when they were ready for QA so they could sort of shift their brains from being in build mode to being in QA mode.

And I think it was really important for the design team to be flexible in how we approached it to match their mindset. So once we did that, what we did was we always created these mocks that were showing the build on top of the mocks and highlighting where there were differences and also what needed to be fixed. And then what we would do is we would prioritize them together.

So between product engineering and design, we would go through each one of the bugs and classify it as a blocker, as a major, a minor, or something that didn’t need to be addressed and figure out what we’re going to do for release, what we do for fast followers, what would be in subsequent sprints and sort of rinse and repeat. So, both methods worked great. We just all had to agree what the rules of the game were together before we got too deep into build.

EW: This might be pedestrian but just the mechanics of the build and the mocks, are you just printing out two different screens and showing those side by side or was there some of the-

AG: No, we had separate InVision projects that we wouldn’t label QA, so it would have the same name as the design mocks that they were building off of, but have QA in front of it. And so we have that digitally so that we would have a record of what the state of the QA was at evident given point for those teams that like to do it iteratively or just to be able to reference it when we were doing sprint planning later on. So we kept it non paper on purpose just to make it more kind of transparent and accessible to people.

AW: That’s great. So as we mentioned in the introduction, you grew your team at LearnVest by 10x, and I’m guessing there are some folks listening who want more investment in their design teams. What are some of the things you learned along the way that helped you grow your team with that factor?

AG: Few things. One, you do need to keep educating companies about what design does. We were also proud to be designers, especially within the context of the design thinking movement that was happening at LearnVest/Northwestern Mutual. But we were also a little bit of a misnomer because we were a crew of UX designers, visual designers, copywriters, researchers.

And there was a time, usually in the summer, maybe it was too much rosé when people would come and say, “You have x number of designers, why do you need more?” Or, “Why can’t you do more?” And so I’d sort of dust off this presentation every few months they would say, “All right, here’s how many designers we have. But of those, this number are writers, they don’t do design, they write things. This number is research. Researchers don’t design things. They give us insights.”

And then all of a sudden people would say, “You need more heads.” I go, yeah. And then they say, “Okay, let’s find you some more heads,” and to not get upset about it, just be used to that. People, they haven’t worked with design, if it’s not already part of the company’s DNA, it’s something that needs to be developed over time. The other thing is to talk very openly about what the models are of how you can staff design and make it a collective decision for how the company wants to spend their money.

So when we were going from six designers and one researcher to anything because we had many hundreds of engineers, even in the early days, we had the question do we do embedded, do we do full shared service, do we want to aim for some kind of hybrid? And we knew that we were not going to spend the amount of money to have dedicated UX designer, visual designer, copywriter, and researcher for every scrum team at the company.

One, I never could have hired them that fast. Two, just in terms of spend, it’s very expensive, right? There’s a great thing that people develop long-standing relationships with everybody on the team, and they work really closely, which is awesome. But we also had a lot of products that would by virtue of the technical complexity of them would mean that there was downtime for those designers. And so then, you’re paying for designers to not have enough to do. And we didn’t want to do that.

In the early days, our solution was to be a totally shared service, just resource against company priorities, send people where they were. Once we got to a certain level of scale, we could start to have a more nuanced view of things. And where we ended up was having groups of products that we called portfolios that were thematically linked and have fixed leadership in user experience, visual design, copyright, and research at the top of those portfolios.

And then a shared pool of individual contributors to put where the work was. So we had people developing deep product and engineering and business expertise in certain areas, but then could kind of flex the workforce to where the most work existed at the time. And I think when you make that decision together, you can then remind people, “Hey this is why we decided to do it this way. That’s why you want a designer tomorrow, but it’s going to take us three weeks to get you your team.”

Or if people say, “Why are there so many designers? Because you went with the embedded model that you can say, “Well, it costs this much because you wanted and always on design service for you.”

EW: Once you hit scale, that’s the good news that you got the heads, you’ve got the staff that you need to keep up with the work. The challenges start to shift that there’s a broad communication challenge that we’re staying connected to what work is happening. Making sure there’s no redundancy in the work. Helping people learn from one another, share systems. And then more broadly, how do you communicate out to the rest of the company, this is what’s happening inside of design so they have a sense of what you’re doing and how you’re creating value? Can you talk about some mechanisms or processes that you’ve used in the past that help design be more visible to itself and also to the rest of the company?

AG: In terms of design being visible to itself, having open crates or work shares is really important because people do find value in them. And you know, it started early on when I was there as a way when you have six designers, of course you’re going to look at the work altogether because there’s only six people you need to accommodate. And later on, I would actually do polls with the team. When we got to be about 50 people, I started to get nervous.

Do people really want to see X, Y, or Z project that they have nothing to do with in a team format? And it turned out people really did. We tweaked the format a lot. People wanted to have different hosts, so we rotated host between all the portfolio leads. Sometimes even with individual contributors, people wanted to see, sometimes they found a lot of value out of seeing a whole users’ journey presented together versus a portfolio.

But that became a very important mechanism for us internally to keep designers learning from each other and finding ways to piggyback off of each other’s work. In terms of the larger organization, we found that it was really important to go into other teams staff meetings, and let people know what was going on. So to communicate the structural changes of what was happening within design to let’s say the product all hands, that that was very important, and to keep letting people know about our capacity changes.

So, there is an incidence where we found out there was some product managers doing some research themselves and we got feedback that maybe that wasn’t ideal. And I went and asked the product manager like, “What’s going on? Why are you guys doing this?” And he was like, “Well I know you only have three people and then somebody left. So I just didn’t want to ask you.” I was like, “Well, yeah, somebody left, but we hired five more people. You could have had one of them.”

And he was like, “I didn’t know.” And I’d kind of hit myself on the forehead and went, “Oh my gosh. I was introducing people to my team as people joined my team, but I was forgetting to tell the outside world, “Hey, guess what guys, we have five more researchers. We’re now at three x capacity of what we had six months ago. Let’s reengage.” And so, it has to become a routine, not just a sort of moment.

So we started like rapping on doing our little like design 101 intro at lunch and learns and found people were really excited to come, whether because they hadn’t seen it in a while, or they’d never worked with us yet, but they had heard about it. We had sort of thought we were done with that stage, but we really weren’t. It takes much more time and reinforcement than I realized at the time.

AW: So when we last spoke, you were really engaged in learning about ops, design ops, and you’re starting to spin that up at LearnVest. How has that process gone for you? What were you learning as you were engaging in that?

AG: Oh gosh. Well, I learned a lot. It was very exciting. I think that the stuff that struck me the most was how different groups structured the group, what kind of talent they went after, because it’s very new field. So most people aren’t coming out of 10 years of design ops. And InVision was actually fantastic in making a bunch of introductions for me to talk to people on Facebook, people at Pinterest.

And for me the way I had sold in design ops to Northwestern Mutual and LearnVest was that it was a collection of capabilities that help design run better and communicate better with the rest of the organization. The really fantastic thing that I learned was how many companies were beginning to also pair that with learning and a designer experience program, which I thought was so fantastic. And so we began to look at better ways, more efficient ways to onboard new designers.

Because one of the biggest problems when you’re growing 10x in two and a half years is how do you get all these people up to speed? Because at a certain point, you have newish people training new people on what you’re doing, and if you’re not doing a good job of bringing people in, there’s real risk that stuff can go a little crazy. So that was a really exciting thing to think about as well that sort of let us kind of dip our toe into that designer experience aspect.

So I thought that was fantastic and I think that thinking about communication tools can mean a lot of different things. So, it was through that effort that we actually had started to build a tool for copywriters to be able to seamlessly flow their copy into sketch without needing to actually know how to do sketch and without heavy copy DAX and having designers cut and paste copy.

During that time though, the folks that were working on it actually found a new plugin that was released, and getting that in the door save both a lot of frustration on the designer side because copying and pasting things doesn’t make anybody feel particularly strategic, but also make the copywriters feel more included in the design process.

And the other thing was how resource managers and program managers could come in and help us run a really big initiatives, and ensure that the team was staying in line with our product teams kind of strategic ideas, and the engineering teams roadmaps to make sure that the design effort was aligned to both of those. I think it’s a very exciting time in design ops.

EW: It is. And design ops is this recurring theme we hear a lot about when you talk about scaling a design team, ops is kind of an essential thing. You need this input output layer for the design team to be able to connect to the rest of the organization to be successful. So Abigail, we know that you are a consummate learner. You’re always pushing yourself, learning new things as evidenced by your devouring of everything you could get your hands on around design ops. So, we’re curious about books that you’re reading right now that are interesting and compelling, informing what you’re doing and maybe if there are blogs or podcasts or other places where you’re picking up new ideas.

AG: Wow. Exciting. So I’ll be honest, the books that I’m reading right now are really about Google’s history. I’m trying to contextualize what we’re doing now and how we’re looking at the future with this really rich history that I don’t think I fully appreciated even before I got here and went through my nuclear orientation. And that’s everything from work rules to there’s another history of Google somebody gave me.

But one of the things I’m most excited about was that yesterday at our own UXU, I heard a keynote by Debbie Millman, and she was talking about the history of branding and packaging and consumer confidence. And although it was for the whole broad UX audience here, I felt it was so relevant to thinking about as in the modern marketplace, and what does brand signify and what does safety mean to consumers in this latest iteration of the digital age.

And if you can pick up one of her books or that’s another podcast that I think is worth listening to. I was very excited in the way that it was making me think about the experiences that we’re creating for consumers as well as publishers and advertisers.

EW: Yeah, Debbie Millman’s podcast Design Matters is great. It’s been around for a long time. Very interesting stuff.

AW: So Abigail, as always, it was fantastic talking with you. You shared such great stories and insights. We really appreciate having you on the show, and best of luck as you forge ahead in your new career at Google.

AG: Thank you so much. It was an honor to be here and lots of fun as always.

Narrator: That concludes this episode of the Design Better Podcast. Thanks so much for listening. If you’re hungry for more stories and lessons to continue to level up your design practice, visit invisionapp.com/designbetter. You’ll find eBooks, videos, and articles on design that you and your team can use to learn more about design thinking, building world class operations, facilitating enterprise design sprints, and so much more.

If you enjoyed this episode, please leave us a review on Apple Podcasts and share this podcast with a friend or teammate interested in designing better today. Thanks so much for listening.