Lori Kaplan is a veteran design leader, whose pioneering work includes authorship of the original Macintosh Human Interface Guidelines in the 1980s. In this episode we speak with Lori about how the Atlassian playbook helps both internal and external teams address design challenges, the deep roots of cross-functional collaboration at the company, as well as Lori’s perspective on how attitudes towards design have shifted in recent years across industries.

Takeaways:

• How Atlassian “designs across the seams” with a broad view of the customer
• The habits and rituals of teams within Atlassian that help create better cross-functional collaboration
• How quantitative and qualitative metrics work together to measure the impact of design.

 

Designing across the seams at Atlassian

The following is a complete transcript of this episode of the Design Better podcast. Enjoy the episode!

[Introduction]

Lori Kaplan:  I think it is a superpower or potential superpower of all design teams is to design across the seams, and I think that is one of the key roles that we play as designers is to bring that customer view and the broad complete customer journey into our work.

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: If you use a Mac, you’ve been impacted by Lori Kaplan’s work. Lori wrote and helped develop the original Macintosh human interface guidelines in the 1980s, which had a huge impact on how software was developed on that platform and others in the intervening years. After a career path that included design leadership at many top tech companies, Lori is now head of design for cloud migrations at Atlassian. In our chat with Lori, we talk about how the Atlassian playbook helps both internal and external teams address design challenges. We also talk about the deep roots of cross functional collaboration at the company, as well as Laurie’s perspective on how attitudes towards design have shifted in recent years across industries. So plug in your Mac classic and get ready to listen to our chat with Lori. Thanks for listening.

Aarron Walter: Hi, this is Aaron Walter.

EW: And I’m Eli Woolery. We hope you’re enjoying the Design Better Podcast, learning a thing or two that will help you in your career.

AW:      We put a lot of time and energy into producing these interviews with top industry leaders, and we want to share their wisdom with as many people as possible. You can help us achieve that goal by taking just a minute to review the podcast on iTunes or Google Play.

EW: Your review will make this podcast more discoverable, and will help us reach new people in the design and business community.

AW: We appreciate your support. Now let’s get to the show.

EW:  If like Aaron and I, you grew up learning and playing on Mac computers in the 1980s and ’90s, you may not be familiar with our next guest, but you were definitely impacted by her work. Lori Kaplan wrote and helped develop the original Macintosh human interface guidelines, HIG, in the 1980s, and that was just the start of her storied career as a designer and design leader at some of Silicon Valley’s tech leaders. Lori went on to be a designer at Intuit, creative director at Netflix, director of UX at Motorola, and VP of experience design at LendingClub. She is currently the head of design for cloud migrations at Atlassian. Lori Kaplan, welcome to the Design Better Podcast.

Lori Kaplan: Thanks, Eli. Hi, Aarron.

EW: Great to have you here.

AW: Great to have you.

EW: Let’s start off with a little bit of what we mentioned in the intro. So you played a really big role in the design of many products over the years since your time at Apple in the ’80s and ’90s. How have attitudes toward design shifted in recent years?

LK:  I think with the advent of the web and the democratization of design and product creation, people realize the importance of design in a broad sense, not just visual design or interaction design, and we’ve been able to prove the impact of including design in a product development process, so now companies are clamoring to include design thinking, as we now call it, in their processes and build huge design teams. So we’re even seeing a trend where design studios are being acquired by consultancies and other firms that want to augment their design capability.

AW: Can you talk a little bit more about just communicating the value of design? This is something that time and again, it’s always on the minds of designers. There are a rare few places where executives, key stakeholders, they get it already. That’s becoming more common though, that people get it, as you stated. Can you talk a little bit about how you, maybe in your current role at Atlassian or in previous roles, how have you helped people, executives and others, understand this is the opportunity by having design involved in a strategic conversation early on, involved in the process going forward? How does design create value for the business?

LK: That’s a good question. So I didn’t have to lay the groundwork at Atlassian. That has been done over the last seven years by Jürgen Spangl and his team of design that existed when I joined a year and a half ago. They’ve done a ton of work on showing how products get better when you go through a design process. And in the past roles, what I’ve done to build buy in for design is help people codify their thinking and express their thinking. So basically, if you can partner with somebody who wants to convince somebody to do something, and you can be the hands and mind for them and help them visualize what the experience could be, it’s a much more powerful pitch than going in with just a business case. So I always take the path of how can I help you express your ideas, and through that kind of work from the inside shaping the concepts and then taking it forward.

LK:  One really powerful tool we have now that we didn’t really have back in my early days in design are analytics and metrics. So we can actually measure, as long as we put in the coding to get the metrics out, the impact of particular changes. And a lot of people are doing AB testing to do that. I think that’s awesome. And you also need qualitative insights that go along with it. So you have to talk to people to understand why they did what they did, even if they do it in large numbers. So I think those are some ways. Be the boots on the ground and then measure what you do and look at the impact and retro all your work.

AW: Is there anything that you’ve recently worked on at Atlassian or you’re currently working on, where you could maybe unpack that a little bit more for us where specific analytics have helped you understand the impact of your team, and then maybe how qualitative findings support that as well.

LK: Sure. I’ve been working on our cloud migration projects for a little more than a quarter. We have two sides of that environment, but on one side we’re building tools that help migrate data and users from our server on-prem hosted products to our cloud products. The project was well underway when I joined. We were about to launch an app, which is a plugin, to our Confluence server product, and while we were building it, we also knew we wanted to understand if it was working or not, so there were some basic metrics put in. We also, before we launched, with our insight and analytics team built a dashboard in tableau. Once we launched, we were able to see how many people downloaded the app, how many people launched it, how many people migrated data. And so it’s a regular activity that we come in in the morning and we look and we see, “Wow, yesterday people migrated 500 spaces.”

LK: So we’ve gone in the course of two months from zero to 11,000 plus Confluence spaces migrated, and we can see how they’re going about it, where the drop off is, where we released a new version of the app, and because we had embedded a version in the Confluence server, there was a glitch, we didn’t upload the right files, and people were still using the previous version. We caught that very quickly because we could see on the dashboard, “Oh, people are still using that old version. Why is that?” So we can see both the impact, and then we also track through our metrics support contacts, and we can see if once we launched the app people are having more trouble or less trouble migrating.

LK: They were doing it using different functionality in the past, which was harder. So then we go and we talk to those people. In parallel, we have a research effort going on where we’re doing a little bit higher level strategic research about why are people migrating, what do they need, and we marry that with what we’re seeing in the tactical analytics to understand are we making a difference? Do we need to course correct? Are we hitting the target? Are we seeing more contacts or fewer contacts? Are we seeing more people migrating or fewer? So we kind of look broadly.

EW: So we’ve had an opportunity to talk to a bunch of folks on your design team lately for an upcoming Design Genome report, which should be published by the time folks are listening to this, and your team has some really interesting practices like sparring, and there’s this product brain trust. Maybe you could talk a little bit from your perspective about what makes the workflow between designers and developers effective at Atlassian.

LK:  I think what makes it effective is that we don’t think of it just as a design developer relationship, we work in a triad model, which is actually more like a quad or a pentad or a bigger team. So we work very cross functionally here by design. What that means is for every project we do, we have a product manager, a designer, and a tech lead, and then we might have other people in those roles as well that make the broader team. And using the Atlassian playbook that you referred to in different plays, which are how we talk about how we do things, and share the best practices across the org. We work through a pretty canonical flow that you would think of in product development, where we start with what is the customer problem we’re solving? What is the business need to solve that problem?

LK: How are we going to go about it? How are we going to form a team? Do we have the right people? How long is it going to take? How urgent or important is it? How are we going to measure our success? And then we get down into the, “Okay, let’s plan out what we’re going to do.” And of course we’re big agile people building tools that support agile processes. So we work in agile, some people use Scrum, some people use Kanban. It’s kind of up to the team, the local team, how they choose to operate. But then we go into a pretty dedicated sprint process to get to the outcomes that we are looking for. So in that process, designers have tickets to do design work, engineers have tickets to do engineering, product is looking at are we doing the right thing in the right time, are we measuring it appropriately, getting all the resources we need and making sure that customers are part of the conversation.

LK: So we design spar as you call it, which is really just another name for design critique. And we spar with other designers across teams. We spar with our development and product partners leadership. So we do a lot of critique along the way. And so hopefully engineers are involved in the process as early as possible. Sometimes they’re the ones who are initiating a project, and so that’s how we kind of work in lock step as we go along all the way through initial idea to ship, learn, iterate.

AW: You mentioned the playbook that you use at Atlassian, and I’ve always been impressed with the playbook, that it’s public and it’s a way to share this is the way that we work and solve problems in what we see leads to success, because of course Atlassian’s very focused on teamwork, collaboration and has a great deal of expertise on these subjects, and you put the playbook out for the world to see, consume and use themselves. Can you talk a little bit about, I mean, it’s an interesting approach to just institutionalizing wisdom. We see this in the public, but how does it get used internally inside of Atlassian, and how does it shape your work?

LK: When a new employee on boards, we have a very methodical process about how we bring them up to speed to be successful at Atlassian, and playbook is a part of their introduction to work at Atlassian. So we require everybody to read it, and then as we integrate people into the work flow, the playbook becomes part of it. So we’re all immersed in the play so to speak, and as we go around and we spar whatever it is, and we don’t just spar designs, we spar processes, we spar plays, we spar ideas, we spar issues, et cetera. We get feedback about, “Oh, I’m really struggling with this problem.” And a frequent response will be from somebody who’s more seasoned at Atlassian, “Oh, you might want to try this play.” And so that’s how it becomes, it’s in the DNA of the company.

AW:  In the language.

LK:  It’s in the language, and it’s also in the behavioral DNA, because we’ve learned over time these activities work to solve these kinds of processes, problems, whatever. And so it’s shared, and we’re also developing new plays all the time as people innovate and try new things. So as new people join, they bring best practices from their previous lives and try them out, and when it’s a process that works, then we make it a play.

AW: Is there some sort of governance to the playbook? Is there a team that owns it? Or how does one get a play into the playbook?

LK:  I have to confess my naïveté. I have seen it happen. I’ve seen the conversation going on about a new play that’s being added, which I can’t think of what it is right now. So there is somebody who is responsible. I don’t know if it’s within design or if it’s a broader like learning and development team and the people team, I’m not quite sure how that works, but there is a process. It’s a conversation, “Oh, we see this as working. Have you shared it with other teams? Write a blog about it.” One of our company values is open company, no BS, which means that we publish a ton. So one way to share is to write a blog and share it with everybody. It’s basically, unless it’s locked down, it’s open to the whole company and then we share through chat or through team conversations, et cetera. And then once it gathers some solidity, there’s a conversation, “Oh maybe we should make this a play.” And then there is a process to write it up, get feedback, get sparred around the company and then somehow it gets published.

AW: I think this is a really interesting space for other companies to consider. Design systems are all the rage and people are talking about how do we unify user experience across products, across different verticals, across teams, teams that aren’t always in the same location. And that’s something I feel like at this point people kind of understand, they know why that’s important and they basically know how to do it. But we still see teams, they operate very differently, and there’s oftentimes, as you described, there’s some autonomy to how the team approaches, whether it’s Kanban or agile or whatever it is. But to have some sort of standardized playbook as a point of reference seems just imminently useful for our business to reduce a lot of entropy.

LK: Well, I totally agree. It’s been very helpful coming into Atlassian because it helped me integrate into the Atlassian way. But it also, because it’s a living, breathing document, enables me to contribute to it or to modify it or to personalize it for the situation and context I’m working in. So I think it’s a great practice.

AW:   That’s cool. Do you have a print version of it or is it only online?

LK: I don’t have a print version of it. I think there may be. We did, we collectively at Atlassian, but as you know, Alastair Simpson is one of our design janitors, started a medium blog on design and that has been published into a book. So maybe the playbook exists in a physical form. I don’t know that it should, because that would capture it at a point in time, and then as I said, we’re always evolving it. So I think it’s better as a living digital document.

EW: So one of the things that Jürgen mentioned when we spoke to him was that a superpower of the design team is in his words, their ability to design across the seams of the organization, that they can have this view of the entire customer journey and help it be more coherent across the different products. And I’m curious how that relates to the kind of collaborative culture of Atlassian, and I wonder if you could compare the culture Atlassian in that way to maybe some of the other places you’ve worked.

LK: I think it is a super power or a potential superpower of all design teams is to design across the seams, and I think that is one of the key roles that we play as designers is to bring that customer view and the broad complete customer journey into our work. I think it’s easy to lose sight of it as you get deep into delivering on your personal mandate or your team mandate, whatever that is. So I think some of the playbook plays help us up level, like sparring. We have to spar across teams, and as we do that we share, and that’s an opportunity for designers to up level and say, “Wait, how does that experience fit into this customer journey?” We also use journey maps and put assets up on walls, which is kind of difficult given that we’re distributed around the world, but we’ve adopted tools like InVision, of course, MURAL and Gallery to share our work asynchronously, so that we can stay in touch with what’s happening across all the teams. And then we can, as design teams or design leaders look and see where are the gaps, where are things falling apart.

LK: I think it’s a challenge of all design teams. I don’t know that our culture is that different from other cultures I’ve worked in, and that’s probably because I choose places that feel comfortable to me and where I feel like I best fit and can contribute and help. Not all companies are as open as we are, so that’s been a challenge in the past to understand where other people are working on part of what a customer experience would be, but they’re in a different org in a different location, and it’s not as accepted to share work because it’s considered the company culture is not to share. There’s the whole conversation about the structure of design orgs that’s been bubbling for a few years. Depending on how you’re structured, if you’re a centralized team with a direct report up to a VP of design, there’s an opportunity to have more visibility and more fluidity in people’s roles and how you move people across teams as opposed to having a really decentralized team. I think that’s shifted over time, and I think we’ve developed the awareness of how important it is to look at the overall customer journey.

AW:  Hey, everyone. We wanted to take a moment to tell you about InVision, the company behind the Design. Better Podcast. InVision is a digital product design platform used by 97% of Fortune 100 companies, and there’s a product from InVision that really excites a lot of designers called Craft. It’s a free plugin for Sketch and Photoshop that allows you to easily sync designs to InVision for better prototyping and collaboration, meaning no saving, exporting, dragging or dropping. It also includes tons of helpful extras, like the ability to grab high res images from Getty and iStock, bring real data to your designs, have real time collaborative whiteboard sessions around your art boards and even more. It’s all available at invisionapp.com/designbettercraft. So check it out, start designing better with Craft today. Thanks so much for listening. Let’s get back to the show.

AW: Have there been significant organizational shifts recently at Atlassian, the way teams are structured?

LK: I would say not the way teams are structured, but we have shifted our focus and we have shifted our teams, our company, to focus on where we think our best impact is. So in the springtime, we reorganized to focus on, broadly speaking, we have a server team that focuses on our server products and then on our cloud products we split into two general groups. One is focused on what we call tech teams, which is the tools that technical teams use to build software. So all the Jira’s: Jira Core, Jira software, Jira Service Desk, Bitbucket, Pipelines, all of those tools, they give those teams focus, and one of our co founders is leading that org. The other broad cloud team we call all teams and platform, and that’s the team that’s focusing on building the software that all teams might use to collaborate and communicate like Confluence and Trello.

LK:  And then our platform that supports all the products. So features that would go across all products like identity management or security or our design system, for example, is in that team. So we reorganized to appropriately give focus and help teams accelerate their work. So that’s a recent example of a shift. But within each product area we’re structured, we create teams that include product management, design, engineering, analytics, research, all the functions. So we sort of matrix people into a product team.

AW:  So there’s always a researcher embedded in a team?

LK:  No, there’s not. So our research team is separate from our design teams, and they’re focusing on strategic questions and supporting the product teams in doing more product focused research. So for example, my team, we do have a researcher that’s working with the leadership on our strategic cloud migrations questions. And then we’re thinking about how do we do more product focused design research, more tactical research. So we’re collaborating on constructing what are the questions, what are the approaches, how are we going to execute that? And probably some of the designers on the team will be doing some formative and evaluative usability testing on the apps and the content that we’re designing.

EW:  So Lori, you mentioned before we started recording that your own role is starting to evolve a little bit. Could you talk a bit about that?

LK: Sure. I’ve been leading the cloud migrations, content design and design team, and now I’m expanding my role to include the buyer experience team. Which means the people who design and build our Atlassian.com website where customers come to learn about our products and sign up to get them. This makes sense because there’s a synergy between getting people into the right product at the right time, and helping them move from a server product to a cloud product when and if they’re ready to. So we’re unifying, again, going back to the broad customer journey. We’re trying to think about how do we collectively help customers find out what our products are, how they’re going to meet their needs, get the right one at the right time.

AW: Lori, I’m curious, so we talked a little bit about team organization and the triad structure that is common to a lot of companies at this point. But could you talk to us a little bit just thinking about things you’ve been working on lately? How does it work just getting these multiple perspectives involved in a project early on, and just fostering collaboration, fluid, efficient collaboration between engineering, product and design, and then presumably stakeholders like executives?

LK: I think it’s always a challenge and it’s really profound for me to remember at the core, we’re all humans, so we each bring ourselves, our whole selves, to work every day, and sometimes that’s easy and sometimes there are things going on that create friction. So as a leader, I’m constantly thinking about how do I help these teams be their best? How do I remove roadblocks? How do I encourage collaboration? Fortunately at Atlassian, this is our focus as a company. We try to make collaboration and communication for teams the best that it can possibly be. We have a process, a canonical process that like I said, we can call it the double diamond or whatever process flow you use, but basically to kick off a project, there’s a lot of leadership discussions about what are the right efforts that we should be doing, what are our company goals?

LK: We break that down into organizational objectives and key results, and then we break that down into what projects will meet those needs. As we identify a project and assemble a team, if it’s not already functioning, we typically start with what we call a project poster, which is one of our plays. It’s a document that the team puts together that identifies what customer problem we’re solving, what business need does it have? What do we need to get this done? How long will it take? Who are the people? What are our success metrics? What do we know about this? What data do we have? What data do we need? So we put that information together, and then within the team we spar it and make sure that it makes sense, and then that gets presented to leadership and said, “What do you think about this?”

LK: We get feedback, and then from there the team operates, breaks into their functions to say, “Okay, now we’re going to do this. How are we going to do it?” And that’s when we shift into more of the agile process where whether you’re using Scrum or Kanban, you organize your work in a backlog and then we groom it and we assign, people take tickets and start working. We have regular meetings where we talk about the project, agile ceremonies where we do retros after a sprint, and also plays. So we do retros and we do team health monitors I think is an important way to surface where there are things are working well and where we need to apply some more thoughtfulness to our process.

LK: So I think that’s how we learn how things are going. And then the team collaboratively identifies where are we a little bit sick, which is a funny way to think about things, but where are things not working as well as they could be? What help do they need? What do they want to try to make it better? And so with a cadence of constantly looking at how we’re working with the intent to make it better, I think that’s how we engender the collaboration.

AW:  Hey Lori, I’m curious, it seems like from the outside that Atlassian has a lot of just process and operations buttoned up and figured out really well. I’m curious, does this feel similar in your experience to the way you’ve seen other teams run in different companies, or does this feel markedly different?

LK:  What feels similar to me is that we’ve all been thinking about and working on how to work better. What’s different at Atlassian is how people are thoughtful about it, and how committed I believe we are as a company to putting the lens on how are we working and developing tools to support work. So I think in other companies, we’re developing products. At Atlassian, our focus is developing products that help teams work better. So it gives another layer on top of it that I think is very helpful, I’m finding very helpful.

EW: So Atlassian was founded in Australia, they’re headquartered in Australia. You get a chance to go out to Sydney pretty often from talking to you. It’s a lovely city. Is there anything about the fact that the founders and a lot of the employees are from Australia that makes it unique, that kind of impacts the way the work is done there at Atlassian?

LK: There is a particular Australian ethos to the company that I’m learning, but I don’t know that that’s its unique flavor as much as what we’re trying to accomplish and the goals of the company, and the type of people who fit in the company, who we hire to our company values. And so you have to already be demonstrating those values in your previous work life, and we elicit that through our interview process. So again, I go back to the thoughtfulness of the company and the company mission, and how we really live by what we set out to do and hold each other accountable for that as a key difference in what Atlassian is up to versus other companies. Plus, Aussies have a really fun way of talking that I’m learning about.

AW: Yes, they do.

LK: So yeah, I don’t know. I mean we’re a global company, so even though it was started and founded in Australia, we have people from all over the world that are part of our company and our culture, and I think that adds to the specialness of our company.

EW: So one thing I know that Atlassian has been thinking about quite a bit in the past year and a half, maybe two years, is design operations, which seems to fit quite nicely with the general interests and values of the company about collaboration and efficiency. And I know that that’s been a learning process, that not just for Atlassian but for the broader design industry in general, that bigger teams require more support and more guidance through specific projects, and then also just guidance from care and feeding of the team. Can you talk a little bit about the state of design operations at Atlassian today? How is that supporting design efforts?

LK: It’s not really my area of focus, but so I’ll tell from my perspective as a design leader who’s a consumer of the design operations team. So just around the time I joined, I believe the design org recognized a need to do what you said, to help us operate better as an organization at scale. So they’re putting effort into processes for Craft, as well as processes for people and growth. So that’s been really helpful. I’ve struggled with this in previous roles. In my last company where I was the head of design, it was where I spent a lot of time and energy to help a growing design team know how to operate as a team, bring our special sauce to all of the different projects we worked on, and have some support in how to do that and how to share best practices. So I think our design operations team in the past year has invested in developing our growth profiles, clarifying our design levels, and creating educational material to support those efforts to support growth within and across the org.

LK: They also are investing in some tools and content that we need. So we have a principle designer who’s working on design principles that will sit between our company values and our product principles. I think that’s a tool that’s going to be really helpful for us to again look at are we making a difference, is design making a difference, and how do we think about constructing Atlassian products that are consistent and usable and friendly and express our company values as well as how we want our customers to interact with each other. And then there’s some operational efforts that they work on, including organizing our yearly design week where we all get together in Australia as a design org and spend time. It’s basically a design conference, people share best practices, there are talks, we bring in speakers, and it’s a way for us all to take time together as a team and think about who are we? What do we want to focus on? Where are we growing this year?

LK: How can each of us contribute to being the best design org that we can? And there’s other operational efforts in place. Looking at our onboarding processes as a current effort, because we’ve heard from new hires over the last, I don’t know how long, as long as I’ve been here, joining Atlassian can be super overwhelming. So we’re having a conversation about how do we do that better? How do we get people in? How do we help them feel comfortable and be able to contribute as easily as possible? So there’s some conflict created by our values, like open company, no BS, means we share a lot. When you join, there’s so much content, and it’s hard to know, do I spend all my time reading all the blogs? What’s important? What’s important to me at this phase of my career at Atlassian? How do I manage all of that? So that’s another effort that the design ops team is looking at. How do we help people become involved in Atlassian and feel successful as early as possible.

AW: So Lori, we’ve got one more question for you and we’ll wrap it up. Speaking of reading, is there anything that you’re reading right now that you’re finding inspirational or finding an inspiration elsewhere?

LK:  Wow. I read a lot, so right now I’m listening in Audible to a book called The Big Store, which is about the history of Sears Roebuck. And it’s a really interesting case study because it’s an American business that’s gone through all of the great success and all of the big challenges over the course of time, and there’s a deep evaluation of leadership. And so I’m learning a lot about how that works and how that doesn’t work from a lens of a different industry, eCommerce, which were not necessarily in eCommerce, but that’s fascinating. I’ve read a ton, not necessarily about design. I’m trying to think what I’m reading about design right now.

LK: I spent over the holiday some time reading a lot of articles about design leadership, to think about how I can improve as a design leader to learn from other people, but those were blogs and articles. We just shared with my expanded team, we did a workshop with design and product management, and we read some of Marty Cagan’s Silicon Valley Product principles about what makes good product teams, what makes bad product teams. That’s really cool. Inspired is a book that I’ve been reading that’s really good about how to think about innovation. And I love all the Behavioral Economics works, so I’ve been spending some time with that as well.

AW: Lori, thank you so much for joining us today. Always fun to talk to you and just hear what you’re working on. I always learn something.

LK:  Oh, thanks.

AW: So thanks so much for your time.

LK: Great to talk to you too, always.

EW: Thanks so much.

EW:  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.