As the VP of Design Education at InVision, Aarron Walter draws upon 15 years of experience running product teams and teaching design to help companies enact design best practices.
Aarron founded the UX practice at MailChimp and helped grow the product from a few thousand users to more than 10 million. His design guidance has helped the White House, the US Department of State, and dozens of major corporations, startups and venture capitalist firms.
Eli Woolery is the Director of Design Education at InVision. His design career spans both physical and digital products, and he has worked with companies ranging from startups (his own and others) to Fortune 500 companies.
In addition to his background in product and industrial design, he has been a professional photographer and filmmaker. He teaches the senior capstone class Implementation to undergraduate Product Designers at Stanford University. You can find Eli on Twitter and Medium.
J. Cornelius: Hey everyone. We are super excited to have two guests today, Aarron and Eli. They are the Batman and Robin of Design Education at InVision, you know? That prototyping tool that everyone loves. Hey guys, welcome to the show.
Aarron Walter: Hey, thanks for having us.
Eli Woolery: Thanks for having us. Great to be here.
J: Yeah, glad you could join us. Most people who are listening are probably familiar with InVision, but for those who aren't, how about a little recap of what the app does, what the product does, and how you got there, and what you're working on that's exciting these days.
Aarron: Well, InVision is an interesting platform. Generally we say it's the place where design happens as a team. People can create better products faster by working together, designing, prototyping, testing with your customers, socializing your designs within the company, getting feedback. The product does a lot of different things these days. It's grown a lot. I used to use the product way back in the day when I was at MailChimp, and it really changed the way we worked as running the product time there. I've been a customer for a long time, and now at InVision, it's sort of serendipitous that I'm there. I have a strong bias and strong belief in the platform and what it does.
Eli: Yeah, like Aarron I was a customer before I became an employee. My work is mostly client based working for small start ups, and it just really revolutionized how quickly we could get feedback on designs and iterates. I fell in love with the tool close to when it came out, and used it for several years before finding out that Aarron had joined InVision and started something called Design Education, which really aligned with my interests because I have a background in product design, physical products, and digital products, and I also teach design. I teach design classes at Stanford called Implementation. The intersection of design and education was really interesting to me, so I chatted with Aarron and he brought me onto his team.
J: Awesome. Aarron, you and I have known each other for a number of years, and I've always respected what you've done in terms of educating not just the people on your team, but the people around you and in the community, so it's great to see a platform like InVision embrace that and give you a tool or an audience to do that at a much larger level. Can you talk about what you're doing? What is the Design Education department, and what are you doing?
Aarron: Yeah, so we talked about the platform, and that's an important thing for us, you know? Building a product that helps design teams, but a tool is not the only thing that helps design teams elevate their design practice. They have to understand the practice themselves, the methodologies, the process, how to run a team, how to be a design leader. These are all things that are very interesting to Eli and I, and the Design Education team. When we started this team just about a year and a half ago, this was the start of trying to take advantage of this really unique opportunity, this unique position that InVision has, because we have millions of users, thousands of design teams around the world at big companies that we're familiar with, big brands, but also small companies maybe you haven't heard of, and everything in between. Lots of different types of design teams are using the platform, so we have this unique position where we get to see all these teams, see how they work, see where they struggle, and also see what are the best practices and how do they succeed.
Of course Eli and I have our own personal experiences of leading teams and being involved in different types of companies that help color that perspective and fill some things in as well, but the design education team, our mandate is to elevate design practices in companies around the world. We do that by spending time with these teams, learning from them, hearing how they solve problems like how are they building design systems and implementing those? How are they using design thinking as a way to get more people involved in the design process, improve buy in, get design a seat at the table with executives. There a lot of different types of things that we do, initiatives that we do to deliver on that promise of trying to elevate design practice.
J: Yeah, so as you've talked to a bunch of different teams, can you identify some common themes about what works and what doesn't? Not just around the tool, but around what types of projects they're working on and how they approach them?
Eli: Yeah, so I think I'm going to point to Aarron on that one just for an essay he wrote about some of the things that design teams are struggling with, because they're trying to scale design in their organization, and we could drop a link to that essay in the show notes. I think one of the over-arching themes is really how do we demonstrate the value of design to people outside the design organization, and show that investing in design has a really huge return on investment for the companies that put the resources into it. I think we're starting to get the stories from all different kinds of industries, not only companies that are thought of already as being relatively design forward, like Google and the Airbnbs of the world, but other companies, let's say like Nationwide Insurance, who are really latching onto the principles of things like design thinking to spread design throughout an organization.
Aarron: That's a really common theme that we've heard is, "How do I communicate the value of design?" We think about that in what we call little D companies. Companies that haven't quite figured out that design is valuable and important, and a key part of their strategy. That's how they maybe improve profit margins or breakthrough in a very busy marketplace. In little D companies, we expect to see that executives, engineers, product managers, they might not understand design, where it should fit into the process and what value it brings to the business. We even see that in some big D companies, some really big companies, brands that we're very familiar with, where we hear design leaders having to communicate the value of design every day to their colleagues and say, "Hey. Design is important. It should be thought about early on in the process, not brought in at the eleventh hour to make something pretty." We're here to help solve problems. We're here to help the business succeed to improve product usage, to reduce churn, to reduce support costs, whatever those metrics are that design is addressing directly in the business.
Eli and I, we hear a lot of stories from design leaders, talking about how do you communicate that value of design to others? A big thing is that you have to bring more people into the process early on, and that's something that designers feel a little resistant to sometimes, of if we draw back the curtain and show people how we work, and we get them involved in the design process, won't people value our contributions less because they think, "Oh, well we can do that too. We can be designers." That's why we see all this resistance and uproar in the design community when people like Jared Spool say, "Hey, everyone's a designer." People just go crazy over that.
I think there's something to that, to what Jared's saying is, is everyone adept at the craft of design and designing an icon or designing a UI? No. That's a very specialized discipline that certain people do very well, but the idea of design and thinking about a problem, and what Eli's talking about with design thinking, this methodology of empathizing with the audience, discovering the opportunity of how you can solve that problem, prototyping that thing, testing it. All these things are part of the design process, and there are places where other people can plug in. Other people being engineers, product managers, executives, lawyers, marketers, anybody.
It turns out that the sooner you can get people involved in that process instead of selfishly claiming all of our legos for ourselves in the glory, but to share our legos with other people to play and build together, you can achieve buy in faster, instead of this grand reveal of design, song and dance. This is what we've come up with. We are geniuses, worship at our altar. That's really not how it works in most companies, but people don't receive those sorts of big reveals very well. They feel like, "Why wasn't I consulted? Why am I not part of that process contributing?" That can be heartbreaking, because designs can get crushed. You get very invested and you get a few months into the project and you find out, "You know what? We didn't hit the mark and we need to go back to the drawing board. We've wasted time and energy", and the teams morale starts to drop.
If you get people involved sooner, get them involved in the ideation and even the research empathy process, if you get them involved in design reviews every step of the way and help them understand design and what the value that that design is bringing to the company, people buy in and that leads to supporting design, that leads to investing in design, that leads to happier design teams.
J: Yeah, and it leads to a greater understanding of the value amongst those executives who would typically just pull in and to borrow another one of Jared's terms, do the swoop and poop, right?
J: It helps prevent a lot of that friction in the process as you start to expose other teams to what you're building, and it's progress. Have you seen typical team composition that tends to work better than others, or a particular approach? Design thinking is pretty broad and there's a lot of articles out there about how to go about that, but have you seen any approaches that are working better than others?
Eli: I think we see a lot of different team configurations, and we actually had an interview with John Maeda a while back, where he really encapsulates it quite well. He tells a story of designing a table and at first you're designing a table just to hold some knickknacks. Later on it's got to hold an elephant, and so the size has got to be a lot different. To relate that back to the company as it scales, the team configuration is going to change as the company scales and so the challenges change for the company. Companies like Airbnb are using an EPD, Engineering Product Design configuration, so you have a stakeholder from each of those sides of the product teams in each team, and that seems to be working really well for them at their current scale. I couldn't say we've seen any hard and fast rules for team configuration kind of across the board. It's really dependent on the teams, the stage of the company and kind of challenges that are facing.
J: Yeah, so do you see that correlating to like organization size or the type of product they're building, or does it really just vary depending on the culture of the organization and how well they work together?
Aarron: Yeah, it varies dramatically. That's the thing that I hope designers realize, is that in a rapidly growing company, the design organization and just the org structure of the company in general is going to change a lot, and that's going to create FUD, Fear, Uncertainty, Doubt. The organization changed, where do I fit? Am I still valuable? Am I still going to be happy in this new configuration? There's a lot of movement in organizational structure. We actually, we talked to Shopify recently, and they have grown tremendously. I asked them about their organizational structure, and Eli and I have talked to countless heads of design and all kinds of different companies. We went into our research over the past year and a half thinking there's some definitive org structure type, and the more we ask about org structure, the more we realize it's not definitive at all.
At Shopify for example, they said, "We can't even tell you what the org structure is right now, because it's changing and it's going to change again, and that just happens over and over again." That happened at Mail Chimp. In my experience, as we were growing and having a lot more people, and the design team kind of shifted, and the way that design and engineering of product kind of fit together, it shifts. When it was ... My experience of being inside of one company, I thought, "Oh this is just us", but now it's really clear that it's just like what John said, that your org structure will change based on your needs.
For example, if you've got a centralized design team, that might be advantageous if you were developing a design system, or you have a weak design organization with a lot of junior designers and you want to try to nurture their skills and help them level up a bit. It could be a problem, because you get a bit of an echo chamber where it's all designers talking to one another, and they're not really thinking about product and engineering considerations in their design. A lot of companies, they'll break that centralized design structure into a distributed structure, where they send designers out onto these islands where they're cross functional teams, where it's maybe a designer, sometimes it's a couple, with a bunch of engineers and a product manager. What's great about that is you get higher bandwidth and communication, because they sit together, they're cross functional, you get multiple perspectives, it tends to develop respect and empathy for these different disciplines, but the problem is if you're the only designer in that team, it's a bit like expatriating.
When you expatriate, you give up your citizenship of your mother country, chances are you're speaking a new language, it's a new culture, and you're there in this new place, but you never quite fit in, so one designer ...
J: Right, they'll never be native.
Aarron: Yeah, exactly. You're never native. One designer with 15 engineers, they're going to march the report to different values. Do we really need to create this animation for this design, because we could develop this and push this live and maintain it better if we didn't have that. That does add to the experience. It creates a memorable experience, which can help with marketing or the user journey, reduce churn, et cetera. There are problems with that structure as well. There are other structures to be considered in addition to those two, but it's a matter of thinking about what are the priorities of the business right now, what are the priorities of the team, what do we need to develop, and then choosing that structure for your needs.
J: Yeah, so it sounds like there really is no right answer, kind of like everyone talks about being agile, and that's upper case agile, or lower case agile, or agile-ish, or whatever kind of process they're following, and there really is no right answer. Is that true for the design process as a whole?
Eli: Well I think that the design process as a whole is another really interesting thing that we've been interviewing companies about, and there is a lot of variation there. Companies like IBM have been experimenting a lot with design thinking and kind of tweaking it to achieve the kind of scale results that they need to have given their hundreds of thousands of employees, and a thousand designers, thousand plus designers. I think that there are some commonalities amongst the companies. They're doing design well and that also harkens back to a really fundamental part of design thinking, which is just being customer centric and really engaging with the customer early on and the product design process, and doing that repeatedly and iteratively. There's a lot of different ways to attack it. There's design sprints, design thinking. There's a lot of tools out there, and I think just like any tool it's got to work for you. For some teams, design thinking won't be the right answer. Maybe design sprint for any given challenge.
I think it does still come back really at it's core to this empathy for the customer, and really understanding their needs.
J: If you were forming a new design team, or if you had advice for somebody who had a new design team that's trying to solve a problem, where would you tell them to start, and what advice would you give them?
Aarron: I think that when you start a design team, you need generalists. You need people that can do a lot of different types of things. People who are good with the big picture, they're comfortable with uncertainty, they tend to be explorer types, which is different than the farmer types who are optimizing, and they're pulling weeds, and they're making refinements. That type of thinking is not useful when you're starting a product, you're starting design team, you're in a nascent company. You really need these lateral thinkers who can explore and have a kind of can do attitude, and work on a lot of different things.
Now as you scale, you want a different type of person. You still need some big picture people to stitch together the various teams and help people understand this is the vision for the product, this is the mission of the company and so forth, but you need more specialist people. You need that icon designer, that animator, that really talented friend developer, someone who is a great marketer, et cetera. We see a lot of start ups where people, they might be working on the marketing site and the product, and they're at events and various things. That just can't scale at a certain point, like you're scrappy early on and you try to work with what you have, and then as you scale and you want to really refine and level up your skill set, you need specialists. As you add more specialists, you need mortar to join all those bricks together. You need people who can organize teams and manage teams, who can rally people around a common mission.
When you get to a very large scale and you've built a customer base and you're profitable, you're making money, that's when you need to bring in the farmers to optimize. Let's pull these weeds. Some of this work might be boring to certain types of people because we're just going to find this code, refine this design, shave a second off of this work flow for the customer. People who love that stuff, they're very valuable. You just continue to iterate and the grand innovation is sort of left behind.
J: Yeah, but you're not giving permission to like an early team to just be sloppy and leave a bunch of stuff for refinement later, are you? I mean there's more to it than that.
Aarron: Absolutely not. I mean you're just making do with what you have. It's sort of like going from MacGyver with I have my pocket knife and my duct tape. There's nothing sloppy about that. MacGyver always wins, right? He's going to make the airplane out of the tarp and the lawnmower one way or another, right? He's going to make it happen. At a certain point, you don't want to fly 150 passengers on a lawnmower and tarp airplane. That's just not going to work. You need to build something more sophisticated and more refined, and that requires specialists.
J: Yeah, I like the continuation of that metaphor. DesignBetter.co, talk about what's happening there, and who is it right for?
Eli: Yeah, so we can kind of go back a little bit towards the origins of it, because it was the first big project when I came on and Aarron kind of shared the vision for it. I was just really impressed by how they pitched it and how they thought it through, because there aren't all that many great resources out there for designers and people who are outside of design that want to understand some of the fundamentals and best practices. I think there's some good books, but there's not any really great kind of consolidated resource. I think that's part of what we wanted to achieve with Design Better, was to create a repository of information that would hopefully stand the test of time to a certain degree. There'll be specific things in there that will become outdated, but a lot of the principles, we hope, will stand the test of time.
It's something a designer can go to either early in their career if they're just wanting to learn, or later on in their career if they feel like they're getting stuck, because we're trying to address some of these common problems that companies small and large are facing as they scale their design team and tackle different challenges. Currently we've got up there three different books. We've got a book on the principles of product design, which Aarron wrote. We've got a book on a handbook for design thinking, which I wrote. Then a book on design leadership, which Aarron and I co-authored. We feel like that's a good start, and we've already got some more on the way, which maybe we can preview, but we've been really excited at the reception so far.
In addition to the books, we've got a podcast going there. We just launched our seventh episode. We're also running workshops for companies that are interested in bringing it in, some really fantastic folks like Jake Nap, who is going to be the design spring workshop. We've got a lot of stuff there, a lot of material, and we're already getting some great feedback. We hope to continue this to be an evolving evergreen resource for folks.
J: It sounds like you haven't been sleeping very much.
Eli: Yeah, that's true, especially up to the launch point, but we're excited about it.
J: Yeah, that's a lot of content. It sounds like it's good for both beginner designers, all the way up through seasoned people and people who are even managing design teams. Would you also say that it could be a good resource for like a product manager, or someone who has to work with the design team, but isn't necessarily on the team?
Aarron: Absolutely, yeah. Each one of these three subjects that Eli outlined, product design, design thinking, and design leadership. I think that the more that a product manager or an engineer who is working with designers, the more they can understand that discipline, that craft, the better. The better they can collaborate with their colleagues, so it's useful there too. It's worth pointing out, it was a very important thing for us to not just go deep and kind of wax academically about these various topics. We want to ground this in reality. We want to tell the story of InVision customers and all of these various teams that are trying to figure this stuff out. We're all trying to figure this stuff out together, at the same time, and we would like it to be together as well, because I think there's lessons to be shared.
Inside of each book, inside of each chapter, you'll find video interviews and audio interviews from people in the industry, people from Netflix, people from Google, NPR, Facebook, all kinds of different types of companies. They're doing cool stuff and they're sharing stories from the front lines that expand the ideas that are presented in DesignBetter.co, into reality, into the everyday work environment of the designer.
J: Yeah, I guess that's one of the advantages that you have coming from InVision, is that you've got companies of all sizes across all types of verticals, building all kinds of different things using the product, and so you can get a glimpse into how all of those companies are doing that, and then build this resource in a way that can really speak to anybody no matter what they're trying to design.
Aarron: Yeah, absolutely. It's definitely a privilege that we have to be able to look across all these different types of design practices and see what's happening.
J: Yeah, exactly, and it's a beautiful site too. It's really well done.
Aarron: Thank you.
Eli: Yeah, that credit goes to ... We have a really fantastic creative team and a really great illustrator who really brought the content to life. Just to reinforce something Aarron said earlier, just the fact that we were able to sit down with all these people and they gave us their time, and let us interview them on video, we wouldn't have been able to make the book without those contributions, so really, really grateful for that.
J: Yeah, cool. As we're starting to wrap up, if you were to take somebody who was really struggling to get their team working effectively, no matter what type of product or what type of company that they're in, what would you say they need to do to at least try to get things back on track or moving the right direction? What is the ... If we were to distill it down into an elevator pitch, what do you think that would be?
Eli: Being a designer, I'm going to give a bit of a biased answer, but I think if you're talking about somebody who is on a design team, who wants their team to be more effective, I think leaning on the scale of empathy is a really good one. Get out there, talk to your colleagues outside of the design team, talk to developers, talk to product managers, and understand their problems, because if you're bringing something to the table and it's just your own perspective and biases, and needs and desires that you're bringing to the table, it's not going to be nearly as powerful as if you understand what those needs are from other teams, and from the CEO, and from everybody that needs to make the decisions that's going to move the team forward. I think really it comes down, if you want to be effective, to just leaning on those empathy skills that you already probably have as a designer.
Aarron: To just build on that, this is the common theme that we've heard across many interviews with lots of different companies, is that design is a team sport, and not just the design team, but all teams. Mark Opland, who is a design manager at Facebook said something that really resonated with us. He said that, "Sometimes your feet are your best design tool." Getting away from your computer, talking to other people. We've heard a number of designers who have been successful in their organizations. A common habit is that they have breakfast, they have coffee or lunch with their peers, colleagues in different departments that they have to collaborate with on a regular basis.
For instance, at Airbnb, Alex Schleifer who is the Head of Design, he has breakfast almost every morning with the head of product and the head of engineering, and that allows them the opportunity to build rapport, build empathy for one another, align their efforts, sync up on projects, and allocate resources accordingly. That's a huge help. Then Ryan Page at Capital One, he also said something that I found interesting. He said, "You don't win a VP position with your headphones on."
J: Yeah, I like that.
Aarron: This just sort of reiterates this idea of as designers we love to sip a latte with some great tunes on and stare at our beautiful, big monitor and design something. That's great, and an important part of what we do as individual contributors, but design at any sort of scale, it requires other people to touch our work, to take that to the next level, the next step. If we are only focused on this one discrete step of pixels, layout, how does this feel, those sorts of things, then we're not thinking about how's this going to work? How will this be translated into code? What are the things I'm not thinking about, because I'm a designer, I'm not thinking about data perhaps or engineering opportunities that I didn't know that we had. How does this align with the business objectives? That's a really important thing. How do I communicate this idea, this story to the company so they get excited and they want to buy into that and support it after it's launched, help market it, et cetera.
The people who tend to do best and make it furthest in their career, are those who have strong communication skills, they might have strong writing skills, and they're willing to step away from their computer and get to know other people.
J: Yeah, that's great. It sounds like empathy is the number one skill that people need to develop in order to be an effective designer. It's not so much about work flows or pixels or anything else, but just understanding who you're designing for and the context you're designing in, and being able to assemble those things in a way that works together.
Eli: Yeah, absolutely. Going back to my origins of teaching, that's sort of the core part of our product design program, is it's focused on empathy and the people that are going to be using the products, not so much that students, there aren't as much of an emphasis on the business side of things, but I think that carries over as they make their entrance into the real world jobs that not only can they have the ear for a customers needs, but they're well positioned to also understand their colleagues needs and the leadership needs in a way that's really powerful. I think yeah, empathy is at the core of a lot of successful designers and creators.
J: Yeah, couldn't agree more. Well guys, it's been great having you on the show today. I really appreciate the insight and your time of coming on and chatting with us a bit about design and what you're working on. If somebody wants to learn more or speak with one of you guys individually, how can they find you and how should they reach out?
Eli: I'm best reached probably just on Twitter @EWoolery. I am also on Medium under the same name, @EWoolery.
Aarron: Yeah, and you can catch me on Twitter. I'm just Aarron on Twitter. The trick is, my name has two A's and two R's, because my dad misspelled my name at the hospital. It made it easier to get my Twitter handle.
J: Yeah, kind of like me with the one letter J, it serves as a great filter, so if someone misspells your name, you know that they don't know you that well.
Aarron: That's right.
J: Well, thanks again guys. Like I said, it's been a true pleasure having you on the show. I'd like to get you back on the show at some point in the future and learn a little bit more about what you've learned over your course of working with people, and how Design Better is working, so I look forward to doing that too.
Aarron: Thanks so much for having us.
Eli: Yeah, thanks for having us. It was great.
How can we help your company use great design to achieve its business goals?
Whatever you’re building, our workshops and project engagements can help you do it better. Reach out to discuss your project or request a quote.