About Braden Kowitz
Design is being seen more and more as an essential building block of a successful business. No longer just a department, design is now at the heart of many growing organizations, influencing key decision making and business outcomes. Evidence of this shift can be seen in the number of venture capital firms bringing on designers as partners. The role of “design partner” is a new one, and many people point to Braden Kowitz’ appointment as Design Partner at Google Ventures in 2009 to be one of the earliest, if not the first. In many ways Braden is defining not only what the role of a designer in a venture capital firm is, but the impact design in general has and can have in the new Silicon Valley startup paradigm.
Braden hopped on his Soapbox to share how he makes decisions based on data, why designers need to be storytellers and how to build communication and trust within your team.
Learning to Lead by Design
One of our first questions for Braden was about the role that a Design Partner has in a VC organization. What do they do and how do they help the startups they work with? Braden touched on many of the things we’ve covered in our blog recently, most notably about shifting from an implementer to a more managerial role. Google Ventures is the venture capital arm of Google and has roughly $2 billion under management. It invests in about 280 companies in the US and is expanding to Europe as well. All of these companies turn to Braden and his team of five designers to provide design leadership.
Braden brought out that his work is not to solve design challenges for these companies, but help their teams understand design, to know how to hire teams, work through design problems and build a design culture. In this way, the work of Braden and his team is not to solve short term problems, but give companies the skills and know-how they need to grow and thrive for years to come.
The team at Google Ventures does this through design sprints, where they work with their portfolio of companies on specific problems with a set amount of time. During this sprint, they lead companies through a design process and build on shared knowledge of the problem. After coming up with several possible solutions, they narrow it down to one or two and then quickly work to prototype and release the product. It reminded us of our rolling five day approach here at ZURB. These tactics keep teams focused on immediate results, but still give breathing room to try new things.
Until You Gather Data, You Don't Really Know
We asked Braden if he could give us an example of working through a problem with a company and what the results were. The first company that came to his mind was Blue Bottle Coffee. Blue Bottle Coffee was moving to sell coffee online, but the problem they encountered was figuring out how to best merchandise it. Analyzing the competition, they discovered that everyone merchandises their coffee based on region. The problem is: this isn’t necessarily the best way to sell coffee. He asked our audience if they had been asked which kind of coffee they’d like based on region, for example, Columbian or Ethiopian. Almost everyone raised their hands. He then asked how many people were confident they were making a good choice when asked this kind of question. Only one person in our crowd of 150 responded with a "yes."
Sometimes you see other people using a solution and you think it is the right way to go, but until you gather data, you don't really know.
Clearly, just because something is popular, doesn’t make it right. The best design decisions are based on data. The team brainstormed several possible solutions, everything from making the website look like the physical stores to filtering the coffee options in various ways, but the the biggest idea was to try asking people a different question altogether.
Instead of which region they would prefer, they asked shoppers “How do you make coffee at home?” After all, it’s a ritual everyone does and feels comfortable answering. This simple question was tested with shoppers along with a few fake brands to eliminate any bias.
... Doing something different than the way everyone is, is a big risk, and you can’t do that without data.
Designers are Storytellers
Braden brought up some great insights about the way both engineers and designers think. Engineers, he brought out, think about features or products in concrete terms, with limits and boundaries. Designers too think this way as well, only in a very visual way. They think of screens and images with bounds and an extent. The challenge is to view things the way users do, People don’t look at just screens or features, they take a pathway through a product. Designers need to walk people through that story.
Braden and his team often sketch out stories before they get into heavy design work so they have a framework in which to build from. Once this general outline is laid, they go in and look where the risks are and design those parts first, chipping away parts of the problem.
Build a Strong Team and Know When to Say No
Building strong teams was something our audience was really interested in. Braden likened his team to a group of super heroes. Everyone on the team had to have some sort of superpower. By having each member possess some special skill, the versatility of the team was greatly increased so that they could tackle a wide range of challenges. Some skill overlap is inevitable and can actually be desirable. Each member of the team must at very least understand what other team members do to eliminate friction.
The places I've seen it break down most are when people don't understand what the other people on the team do. I'm an engineer, I don't understand what design is. I think it's just making stuff look pretty. I don't know what you do all day. And honestly, communication and trust is the thing that ends up making that stuff work.
How is this communication and trust built? Working closely with each other both metaphorically and physically is one of the best ways to do this. Braden recalled a time when he was having trouble working with a team remotely in New York. He decided that he needed to fly out and work with the team directly. Just by working in close proximity to the team day in and day out, the major communication blocks were lifted. Working with each other and learning what is involved in the each other’s daily work builds empathy and understanding.
One of the biggest problems for both teams and individuals, according to Braden, is knowing when to say “no.” For a variety of reasons, people and teams may accept more design work than they can reasonably handle, leading to inevitably poor results. This causes people and organizations to lose trust in design, devoting less resources to it and thus fueling the “death spiral” or design. It’s admittedly difficult to say "no" as an individual, but it’s even harder when you lead a design team. But saying “no” allows your team to focus their efforts and do tremendous things. This improved work leads to growth and builds the trust and respect of others.
Details Matter
In the past, Braden has written that he’s a perfectionist when it comes to product launches. The reason for this? It comes down to trust in the product and the way customers see the product. Even if a product is usable and the engineering is solid, if the front end is sloppy or the colors are not matching or stuff is not aligned, they might assume the rest of it is built that sloppy. Trust is lost. Designers are the ones that must pick up on these small details and convey their importance to the team. Every decision they make must be backed up with a reason, a reason based on data. Braden called it the mark of a great designer, being able to articulate exactly why a decision was made.
... If you're doing really good design work you need to have great data on why you're making that decision.
Our chat with Braden ended with questions from the audience. We want to thank Braden for coming down and sharing his insights with ZURB and the ZURBsoapbox audience!
Transcript
Ryan: Hello how is every one doing today? Ready for another edition of Zurb Soapbox? Awesome. I would like to welcome you all here. We've got a great crowded room today. We'll be chatting here with Braden who is from Google Ventures. A design partner, correct? So everyone give a warm welcome to Braden.
Well I appreciate you coming down from the city to sit with us today. I want to get into it, what it means to be a design partner at Google Ventures. You have obviously led several Google products beforehand like Gmail, Google Buzz, apps and on and on and on, right? Now you're helping shape a variety of start-ups and how they approach their product. So how would you say your design work has actually changed?
Braden: Oh in a big way. So Google Ventures is the venture capital along with Google and we have $2 billion under management. We invest in about 280 companies in the US and we're just starting to move to Europe.
So we have five designers on our design team and we're supporting 280 companies through that. And that is a lot of companies to work with, right? Way more than the amount of engineers I had to deal with when I was at Google.
My design work has changed and the biggest way, it has moved from delivering design for teams, like solving a problem for a team. And instead I moved back and thought, how do I help teams understand design? And how do I help companies get better through design? That is a slightly different thing because as a designer I just want to solve the problem for them. And the problem with a company, if they're just chugging along and then you solve their problem, then they're a little bit better, they're still chugging along.
What I would rather do is teach them design and help them hire a design team and have them design culture and then they'll be chugging along. They'll improve and they'll just keep improving and that is the change we want to see. That's what we try to do.
Ryan: And how do you actually do that work? We were talking earlier and you were talking about your sprints. What does that look like for you guys? When Google says, "Hey, we're going to invest in this company." Where do you guys come in? How do you guys fit into the grand scheme of that investment?
Braden: Typically we just wander around our portfolio companies and talk to a bunch of companies about how we might help. A lot of that is office hours, that's what a lot of venture companies do.
Ryan: Like a professor.
Braden: Yeah, we chat for an hour or two and give some advice here. But then occasionally we'll find companies where what they're doing is really interesting and we think we can make a big impact in the way they work and we think we can change their trajectory.
So for companies like that, we'll do what we call a designs print where we'll put some of their team and some of our team in a room together for a week and try to solve a problem. I think of it a little bit as showing them what design can do and then getting them hooked on designs so that they want to change, so that we can help them change. To do that, we start buy setting this deadline. We have this problem and now we have scheduled users to come in and check out the prototype we're going to design and build. They're coming in on Friday, now we have four days to do it. And that really lights a fire under everyone. There is no dilly-dallying. There is no fluffy design talk. We have four days to get this done, let's go.
And then we lead the team through a typical design process where we work first on unpacking a problem and figure out what we know about it. And often designers, it's nice to play the fool sometimes. I don't know what I'm doing, why don't you tell me. You will find that different people on the team know different parts of the problem. "I did not know that customers have this challenge. I thought they had this other challenge."
So you'll pull that out of a team and help them build some shared knowledge of the problem. And get them talking about the biggest challenges they have. So they think about all the challenges and then narrow it down to a couple.
And then we help them through the second phase of that design process which is coming up with lots of solutions and narrowing it down to one or two that you we think will work. Quickly prototyping it and then putting it in front of customers. That's typically what a good design process looks like.
Ryan: In five days.
Braden: And we do it in five days.
Ryan: Wow. And can you give an example of a company that you worked through that problem, kind of take us through what was the problem you were unpacking and how did they move with you through that process?
Braden: So one that comes to mind is Blue Bottle Coffee. Good coffee here.
Ryan: Not sponsored by the way. This is just regular coffee from the pot.
Braden: They were moving to sell coffee online. They had some sales online but they wanted to pick it up. We looked at a bunch of stuff with them, but one of the challenges was, how do you merchandise it?
And we found that when you look out there in the world, when we do our competitive analysis, everyone merchandises their coffee based on region. You go to websites and here is Honduras coffee, Columbian coffee and you go into stores and they do the same thing. You go to a Starbucks, a really nice Starbucks with the clover coffee machine and everything and the same thing, they have a bunch of countries.
I'm curious if anyone here has talked to a barista and have them ask you two regions, like Columbian or Ethiopian. Has anybody got that question before? Okay a good number of people here. Who has felt like they knew how to answer that question? They were confident they were going to make a good choice there. So one person raised their hand in the whole room. It's odd. Sometimes you see other people using a solution and you think it is the right way to go, but until you gather data, you don't really know.
So we had a bunch of challenges. We had this idea, would that work? We had a bunch of other ideas too. Maybe we should make it really look like the stores, because the stores are beautiful. We had other ideas of filtering coffee in different ways, But our biggest idea, was what if we asked someone a different question?
What if we asked them, how do you make coffee at home? Because it is a ritual that everyone does all the time, and feel very comfortable in answering it. And it turns out that is one of the things they train their baristas to do in the actual store. So we actually built three different prototypes, put them in front of people as a shopping comparison. We found people who had bought craft coffee recently, who shop on line. We said that's good enough.
And then we showed them a New York Times article that referenced a couple of different craft coffee things. We created three fake brands so they weren't changed by, "I love Intelligence. I love Blue Bottle." Three fake brands and we showed them different ways of presenting coffee. And then we learned a lot. Two of them completely failed.
And one of them worked well and asking that question of how you make coffee at home, narrowing down the coffee choices that way and then talking about very simple flavors helped them pick and feel they had confidence with that choice.
So through that process, we felt like we could take a big risk because doing something different than the way everyone else is, is a big risk. And you can't do that without data. So we were able to isolate that challenge, come up with a bunch of different ways to solve it and then get them good data in a week.
Ryan: Oh, awesome and it seemed that part of that was getting into the story of the actual person buying the coffee as opposed to recommending, "Oh this has a bold blah-blah-blah."
Braden: Because we work in such tight timeframes, like a week, we have to spend a lot of time scoping and thinking about what part of the problems we really want to nail this week. And one of our ways for scoping is to think about the customer journey, someone is going to come into this website or hear about this company, then come into the website. In this case of coffee, looking at a bunch of products and to the purchase point.
We can just scope in on that story in one little area and try to solve that well.
Ryan: I'm actually going to jump ahead with my questions because you have brought it up a little bit. You call yourself a storyteller.
Braden: Maybe that's a fad. I don't know.
Ryan: Maybe that's a fad, right. [Inaudible 00:08:02] his little rant on that. But, how do you bring... because you have written an article on this about story-centered design. What exactly is that and how do you apply that to companies that you're working with. Obviously Blue Bottle, it seems like you have already applied that. But can you take us through what that is?
Braden: I think there is two parts of it. One is that, as designers we go on this journey. We think about the problem, we gather data, we try lots of things and we come to this point where we think this is the solution. And then we take that solution out into the world. We say please, please someone build the solution. Commit to this and it's hard.
One of the best ways to get people to understand why you think that's a great idea is to bring them along on that journey. The easiest way is to have them in the room with you as you're doing that design work. But failing that, you have to tell the story of how you made all these decisions.
When they say, "What about this idea?" You turn it around and say, "Yeah we had that thought like three weeks ago and here's what we found when we pushed it into a couple of directions or showed it to customers." You have to bring them with you on that journey. So that is one of the reasons why I think storytelling is important.
The bigger thing is that both designers and engineers have this similar way of thinking about products and it tends to be static. So engineers will often think about the feature or here is this thing we're building and it has this code, there's an extent, there's a boundary to it. Boom. It goes in there, that's the feature.
Designers, a lot of our education comes from the visual field. So posters, mostly. Most of our design tools are for making posters. So when I go and talk to designers often they'll say, "What do you think of this?" And they'll show me one screen. I'm like, "Well, that's interesting." It's very similar to that feature. There's this bound and extents to how it works and there it is.
But when you look at how people use products, they don't look at the screen, they don't look at the feature. They take this pathway through all your screens and features and that pathway might hit 24 screens and it might last anywhere from five seconds and two minutes and then they are typically out of your product, depending what the product is. Even session time for Gmail were not that long. People are coming in, they're doing a bunch of stuff and they're gone.
So what you really need to design is that experience and that story and then back fit all of your features and all of your design language and screens to that story. So when we're designing, we often start with that story, both the overall customer journey to help us scope. But even when we're sketching... when I get a bunch of people in the room and we're sketching ideas, if we ask people to just sketch screen, what you'll typically get is very different structures. One person would say, "It could work this way." And someone else will say, "It could work that way." Then you'll fight because there's only one structure you can have in the end.
But if you ask people to sketch little story boards, we do this by taking post-it notes and putting three big post-it notes on a sheet of paper and forcing them to tell a very boring comic strip basically, three frames of a comic strip. It's good too because it lowers the stress for people who don't draw all the time; engineers, product managers and CEOs and stuff. Because if they get it wrong on a post-it note, they can just crumple it up and put another post-it note down. You're isolating the mistakes you might make
But the key to it is when I tell a little story and you tell a little story, often those stories are at different parts of the journey and we can stitch them together much more easily than if you drew what the dashboard should look like and I drew what the dashboard should look like. Now we have to fight. That's how we do it typically, we'll create these little vignettes and then stitch them together and do a bigger story and then we'll build a prototype from that story. That's what helps us move so fast.
Ryan: Like the, "how do you make your coffee at home" example
Braden: Exactly. So in that example we had this article that someone is going to see first. We kind of storyboard actually the customer interview because one of our mantras is start at the end. If the end is the users study, the only thing that matters is the questions we ask and the experience we put in front of those users. Now we're going to think about our whole four days based on that point.
It can be true of a big presentation you have to give or anything else. It's that moment that matters and everything should funnel into that. Our story board that we're going to build, going back two steps, is about that user study. When are they going to come in, how are we going to get their mind in the right place and then how are we going to take them through that experience?
Ryan: Like any good author, you think of what your ending is or what you're going to go toward. I resonate with that as a writer myself. You want to know where you're going to take the person eventually and what that is. Do you find that it's hard for companies or the start-ups you work for to kind of grok that in terms of design as you're trying to teach them what design can do for them?
Braden: No, not really. People find it remarkably easy I think, to think about how the customers come in for their product. They have often never done it before and we can point out ideas. Then once you have that journey then you can look at where the risks are and dive in on those risky parts and design that stuff first.
So often it's just enlightening and stress-reducing to have it all captured somewhere, to think, "There's all these parts of the problem. I don't know." When you see it on how the customer is going to experience it, you're like, "Oh." It's one place, now we can start chipping off parts of it and working on it.
Ryan: It brings me to something that you once said in an interview, "I think of teaching design as kind of like learning how to ride a bike. I can give advice about riding a bike, but it's not until you get on the bike and try to ride it that you can learn how."
That being said, what is your approach in teaching design to these start-ups? How do you get them to ride the bike?
Braden: Well, the way that we bring them in as a team and work with them... we're a little bit like an agency in that we have a lot of clients, a lot of these companies that we're trying to help. We don't run away and solve the problem in isolation and come back and deliver it and say, "Here is this beautiful design. Aren't I smart?" Instead what we try to do is create a working environment together, where we put half of us designers and half of them from their company and we lead them through the design process.
We have strong rails to keep us on the process. But also we have a wide set of skills on our design team. So we can plug in where they're weak. If they're weak at writing, we can help. If they're weak at front-end development and prototyping, we can help. If they don't have great visual designers, we can help. We're just sort of plugging in any skill gaps and keeping them on the rails and then at the end of that they... people expect so much from design. They often think that it's about color, topography, or the logos, the surface level. I want it to look beautiful. They don't know what to expect from us.
But when you get in there and solve these problems for their business and you show them how quickly they can learn with the methods of design, that's like getting them on the training wheels and running behind their bike for a little bit. That's filling all the gaps with the process that we've got. We're holding them up and then they can see the exhilaration of great design. The wind through your hair. I can see what it would be like if its training wheels were off.
And then once they're hooked on that feeling, then we can talk to them about what does your organization need in order to do it on your own. Sometimes it might be filling those skill gaps and that's hiring and we can talk to them and help them through hiring a design team. Sometimes it's about how you put it together. How do you take this agile engineering team that's really good at building stuff and put design on the other end.
Ryan: And since you have brought that up, I do want to talk a little about, you founded your guys' design studio and your team and you also helped these companies build their teams. What does it actually take in your mind to build an effective design team. What is that and what does it look like?
Braden: In order to really be effective you need to work with the rest of the organization and that's probably most of it. But let's just focus on the core of the team for a moment. When I was building my team, I had this rule where everyone that joined had to have a new super power basically. We wanted some skill overlaps, so we understood each other and we could share and have some common ground. But also we wanted to expand the set of things that we could do. And whether that was user research or writing or visual and brand work or facilitation, everyone has a different super power. And that allows us to tackle so many different challenges. I think that diversity is what makes design such an interesting field because there are so many different granular skills. People have a wide variety of different skills. And when you put together a team that has that wide range, you can tackle amazing things.
The second part is, how does that high functioning design team work with the rest of the organization. That's tough, I think. The places I've seen it break down most are when people don't understand what the other people on the team do. I'm an engineer, I don't understand what design is. I think it's just making stuff look pretty. I don't know what you do all day. And honestly, communication and trust is the thing that ends up making that stuff work.
Ryan: How do you build that communication and trust? How do you build that overlap between an engineer and a designer, or a designer and a copywriter, or a designer who is strong in code but is not strong on brand and visuals. How do you foster that?
Braden: Some of that is just osmosis. I remember there was this team I was working with at Google. They were in New York, they're engineers. I kept presenting design to them and it was incredibly challenging. They just pushed back on everything I came up with. So I figured it can't hurt to go to New York and sit with them, right? This is going poorly.
So I got on to a plane and flew to New York and figured out what I was going to work on that day. And I sat right next to the engineers and I worked on it. I moved stuff around and work on this flow and trying to make it good. And occasionally I would ask for some feedback here and there. It just took me all day to get this flow to a part where I really liked it.
And when I showed it to the team, they said, "That's great let's build it." Wow how did that change? The thing was, a couple of things, one, I got their feedback along the way. But also they understood I was there working on... like this was not just I whipped it together in 10 minutes and was showing it to them without thinking about it. They understood that this was a tough problem and I was thinking on it all day and I was a smart person. And this was probably a pretty good solution. They didn't have the visibility of me working on the other side of the country. They just saw someone show up with a couple of photos once in awhile and like, "How hard is that?" Some of it is just sitting together.
And I think as you're building a team, having that overlap in skill set is really important. So everyone talks about designers that can code, partly because they're looking for a unicorn. They're like, "Please, I hope this is one person will just solve all my problems."
I often look for engineers that are interested in design and designers that are interested in product management and product management that's interested in user research, because when we have that little bit of skill overlap it helps us do those hand-offs. If I'm a designer and I have to build something for an engineer, if I know a little bit about engineering that hand-off is going to be much easier. That's true for product management and research and all these other fields. And it helps us respect other fields. If I know nothing about it, it's easy for me to feel like it's a big field, it's not hard. But if I've tried, I often realize the depth of that field.
I took an avalanche course last week on avalanche safety. I thought, "Oh yeah, avalanche is snow. It should be pretty easy." Three hours of that class with snow guys and snow rangers and I was like, "Whoa, I know nothing about this at the end of this week and I'm still going to know nothing about this."
Beginning in an area helps you understand the depth and that understanding of that depth helps you get trust with the other people you work with.
Ryan: It's like you have a core skill, but you're a generalist enough to have empathy and understanding every other persons job and how that fits into what you're trying to accomplish.
Braden: Exactly. That's much more nicely put.
Ryan: That's my only purpose being up here. In terms of that team, because obviously as a design partner you've taken a leap into a management role and I'm interested in hearing your take on how you move from being the designer into a design management role. And how does a designer evolve in the role to influence a team of people and their work.
Braden: Well I don't think of myself as a manager really. We put together a team of designers as a partnership and decided that we were all going to lean on each other. And because there are five people... well it's a couple of things. I just wanted to hire people smarter than me so that I could relax a little bit. And then we all just lean on each other and five people is small enough that that works.
How do you take a leadership role in your organization in general? That's a challenge. I think about it as ratcheting up. One of the bigger pitfalls I see for teams and individuals in companies, is peanut butter spread too thin problem where there is so much design work and they've only hired one person. And so you try to say "yes" to all of it and you do all of it poorly. And then people think, "Well design is not that effective. Look how poorly they're doing on all these problems." And then you never hire anyone else, the work load grows and it gets worse. And that is the death spiral of design.
The challenge is to say "no" to things. That's hard when you're an individual. It's even harder when you're manager and you've got a team and you're saying, "No, we're not going to tackle this new project because we can barely do these other things," or, "We're going to say no to these other things because the new project is important."
Being able to say "no" so that you can focus your efforts really knocks the ball out of the park, really do a great job, that unlocks the growth. People say, "Wow, if I could just get that designer on my team, look at all the other things that they've done with other projects." Or, "If I could just get that design team to work on my projects, look at what they've done in the past."
So by creating scarcity around it you can often increase the value. Its economics. But it sometimes runs the other way if you're not careful.
Ryan: I was so enthralled with the peanut butter story that I forgot what my next question was.
Braden: Yeah, economics will do that.
Ryan: Scarcity. And for you guys how do you... you have a portfolio of 200 and something companies, start-ups. How do you say no and how do you choose which one you're going to work on and how do you choose where you're going to devote your time?
Braden: Well a couple of things. One, we've decide to have a rubric on how we make these decisions. So any time there is a multivariate decision like this, we try to figure out what are the factors in making this decision and then judge each of those factors independently and then come up with a composite. Partly because I don't think our brains are very good at doing that on their own and addition is often a little bit better.
So our criteria is around a little on investment size. We made a very large investment at Uber. If we get a chance to work with them and they're excited to work with us, that might be a better choice than a very small investment.
Things around, are we excited and passionate about working on something because if you're not passionate about it, you won't be doing your best work. And then there are two other important things. One is, is the company actually excited to work with you? Is it a big problem for them? Are they going to put resources behind it? Can you affect the trajectory of this company?
And the last one, we found ourselves making a bunch of decisions to work on stuff that was making the world a better place. Why did we pick this thing? It turned out that we had this implicit criteria and we just put it into our rubric and said, apparently we care about that and that should be one of our decision processes.
Ryan: And can you tell us a little about what you guys did with Uber? I'm curious.
Brendan: We haven't done a whole lot with Uber. They have a great design team that is already mature. So they're good. They haven't needed us for a bunch of things. We've come in and run a workshop here and there, but we haven't done much.
The other way that I've found helpful working with teams and this was at big companies and within Google and also at Google Ventures, is oftentimes I would ask teams all these questions to figure out, will they build my design work. You were saying, "Do you have a front engineer? Or how often do you push code live?" You try to ask all these questions to try to get inside that black box and understand how it works, to try to think like, "Are you just going to be put my design work on the shelf? Are you really going to do something with it?"
And nothing I tried, no questions I came up with actually correlated well to whether or not our design work would match with the organization. It would change anything. So what I've learned to do is to use the paths as prologue. Do little bits of projects to see how it works and then if it works well, invest more and more and more.
Ryan: You're building trust by doing that as well. If they're going to do and go along with you on that journey and they're building trust in you that you're going to deliver on what it is you say you're delivering on.
Brendan: So there was this company that, I had an office hours with. It was two hours. They were thinking about taken their desktop product to mobile. We thought about it and the thing that actually helped them the most where they lacked was interaction designs. So I said, "Well, let's just spend the last two hours of the session just doing the flow on the storyboard, on the white board." And they were like, "Great, seems great."
So I drew it all out for them in the next two hours and we talked about it and figured it out. A month later they sent me a message saying, "We built it, here it is." I want to work with those people again. That's great.
Other people, you'll talk and do all this work and it just won't go anywhere. I don't know what's in that black box, but I know its working or not.
Ryan: One thing I do want to ask you really quick before I start pitching it out there, one thing that you have written on is that you're a perfectionist close to launch. And I know some people get in that mind set of everything has to be perfect and others are like, "Just push it out."
And you have written on this, why is it important to move that button three pixels to the left? See what I did there? I got the title in there. I spent all night writing that question to get the title in there. But why is it important that details truly matter at that point right before launch?
Braden: Well sometimes they matter and sometimes they don't. What I think annoys other people on your team is if you're asking to push all these little things around and they don't understand why. You're like, "Because it looks good." And they're like, "But why it that important?" And so its important to be able to articulate that and a lot of it comes down to trust in your product and the way customers see your product.
If they see that it's sort of slapped together, they might feel like the rest of it, even though the engineering is solid, if the front end is sloppy or the colors are not matching or stuff is not aligned, they might assume, particularly if it is banking or something, I assume the rest of it is built that sloppy. And I don't trust you all of a sudden.
So being able to articulate why moving this thing matters to the business is the designer's job. We have to be able to explain why we made all these decisions. That is the mark of a good designer is when you say, "Why is that headline in there." And they're like, "Let me tell you. We talked to customers, these are the biggest issues. So we thought maybe we had three different ways to go about the problem. This is the one we chose, we A/B tested it and that is the headline."
"Whoa, okay. We're not changing the headline. I get it, I understand that." And I think every pixels in the UI you need to, if you're doing really good design work you need to have great data on why you're making that decision.
Ryan: Very good. Thank you for answering my questions. I know we have a very large group here, so I want to get to audience questions, very large group. So who wants to ask the first question?
Braden: Yeah so the question is, do we bring our companies and our portfolio together to work on stuff? We don't for particular problems but we often bring them together on themes like hiring is a big theme, user research is a big theme. There are all sorts of things where we can help these companies lean on each other. And it turns out that startup designers often feel lonely, if you're the only designer there, it's hard to get critic on things sometimes. And so just connecting designers within our portfolio has been really valuable.
Part of it is showing the value of design and implicitly saying no to a lot of other things. Some of the way I think about it, is asking teams to pay, if you're on the internal team, you can ask teams to pay with their time instead of with money.
That's sort of what we do, we say, "We're happy to help you with this project. All you have to do is shut your laptops and put your phones in your pockets and sit in a room for the day to work on design." That is implicitly saying no to a lot of other things you could be doing in the organization. And it gives you this nice place to show how much better things can be when design is involved. And after they see that impact, it's often easy to convince them. Say, "Do you want to work that way every week? Because if you do, we did these things for you. We noticed that you didn't have a front engineer," for example, "That could really do gradation on JavaScript. You probably need to hire that, we can help you."
I worry about a lot of things.
Ryan: You can air them out here.
Braden: I think that the brand damage is really, really a good point and for me there are certain things in this world that are easy to measure, like how many people click this button, right? It's super easy to measure and then there are things that are hard to measure, like what do people think of our brand? How will that impact the company over the next two, three, four years?
Which one of those are more important? Probably the brand stuff, if you're really into it. What people think of your company and whether you have that word of mouth is going to be huge for your company particularly when it relates to press and other things. But how many people sign up on this page might be easier to measure but less meaningful.
And I think that is some of the challenge with UX. You'll say, "This is important," and the people on the other end will say, "Show me how to, I can't measure it so how is it important?"
I've often tried to explain to people the difference between that. There's latent things that are hard to measure that are important and then there are close things. And just because something is hard to measure, doesn't mean that it's not important.
So you still can't go flying blind, I think. You still need some types of data. So what we try to do is gather as much qualitative data as we can about that stuff. Usually it's in the form of one-on-one interviews with customers. And when it comes down to questions about brand for example, we'll often put then in that shopping scenario that I talked about with Blue Bottle.
And people go through this idea of shopping with lots of different products they use. Whether it's a to-do app and you're shopping between the post-it note in my right hand and this to-do app in my left hand. Or whether it is coffee or a number of other things, they're making a decision.
So if you can put customers in that mode where they're making decisions between a couple of different parts, you can see how they react to a brand without asking them about the brand specifically. So we try to highlight that qualitative data as high as the quantitative data and help make decisions on both of them.
Specifications, the way we work with companies is a little bit more on the coaching and guidance side, so I haven't had to get that deep in a long time. And my background is engineering so I end up building a lot of things that I design on my own.
In general I found that the more closely you work with engineers and the more prototyping, which will get you working more closely with engineers, the less specifications you have to write. And that tends to make it easier for everyone. So I don't write a lot of specifications but sometimes it's helpful. I guess I'm just pragmatic about it. If it's working for your team, then go for it. If it's not working for your team, then talk about why and try a bunch of different things, even if its just for you, you hate doing this. You deserve to work in a place that you like, figure out another way to work.
I think it should blend together. The way we think about design prints working is that in the world of lean and iterative start-up stuff, people often talk about that you have an idea and then you build it and you launch it and you look at your metrics. And that will inform the next way you change your product. And that's the cycle.
The way we think about the design print is that it's a little shortcut around there. So you can design a little bit and make a prototype and show it to customers and get around that cycle of learning without having to launch something which takes a long time. And those features you build ratchet it in because its so hard to take features out of a product.
That, that large circle is risky. The little circle is fast and not risky at all. And the way that we've worked most is running a little circle, getting confidence, and then running a slightly larger circle and then getting more confidence. And every iteration is becoming more and more real. It's often taking a little bit more time. You're spending more time on the engineering and polish side and less time on the strategy and conceptual side.
Until eventually you have enough confidence that you're like, "Yes, let's finish up all the bugs and launch it." So yeah, I really like blending those things together, so its not like design just drops the solution on the engineering team, that misses a lot of opportunity. And they're expensive.
So I think one of the biggest problems that teams like that have, is that they'll be searching for the unicorn, they'll be interviewing a lot of people, and will get down to two people that they like. And its apples and oranges. It's like, "Wow, this one person has this set of skills and this other person has this set of skills. What do we care about the most?" Then you have to make a hard decision about the skills that matter for your company. And you're doing it very deep in your recruiting funnel which is a problem. It makes much more sense to think very earlier on of all the skills the designers have, which ones are the most important for us.
So what we usually do is help companies think about those more granular skills. Its honestly the thing that I love most about design, is we all come from it from different angles and we all have this huge diversity of skills. So just embrace it.
So the six roughly skills that I work with companies on are, interaction design, visual design, copywriting, user research, front end development and product and more design process stuff is that last one.
Sometimes we add a couple of more skills but that's roughly the rubric. So we take those skills and we say, what are you good at today? Cross those out. Okay you don't need those skills. You're good at those. And what does your business demand? If you're a finance app, maybe it needs to look extremely high quality. So visual design is important to you.
But if you're building some control automation service for power plants, maybe it doesn't need to look beautiful. Maybe it just needs to be functionally correct. So there is another set of things that is important to you.
So you figure out where those holes are in your organization, those more granular skills that you need and then you build a design pipe line on that. Still though, oftentimes people realize they need six of those skills and they still need to hire someone. In those cases, I try to talk to them about a portfolio approach. You're likely going to be hiring two or three designers over the next year or two, think about which one of these skills is most important and hire there and then expand out.
The other thing to remind people of is that even if you find the unicorn, even if you find someone that's good at all that stuff, there's not enough time in the day to do it all well. You're just wasting all that extra recruiting effort and salary and all that stuff because the person is not going to be designing the brand if they're off talking to the users.
And they're not going to be talking to users if they're writing front end code. There's only so much that you can do in a day.
Ryan: Yes, all the way in the back again.
Braden: The idea that they shouldn't go and do something?
Female: [inaudible 00:35:48]
Braden: Sometimes you talk to people and they tell you their idea and you think its dumb. And you're like, "Oh I don't want to. I don't think that's going to work at all." You think either don't do that or do this other thing instead.
Over time I have learned a couple of things. One, is to be humble. Sometimes I don't know the answer. They're experts in the field and maybe it seems like a crazy idea to me, but it might work.
And the second is, typically I think the way designers approach this is someone says, "I've got an idea to do this," and you go, "Great. I'm going to talk to some of your customers." You go out and talk to the customers and you come back and you go, "Turns out, you're wrong."
Now you're in a fight. "I want to do A and you just told me you can't do A. Let's fight." And for entrepreneurs who are relentless, and it's a good thing because they need to build this company, they're really good at ignoring people telling them that they're wrong. They have to, to survive and they have a lot of positive signals that what they're doing is right. People have joined their team and they have got the investment and stuff.
So the way I think about it is capturing that energy and redirecting it. And that's one of the reasons we actually don't do often, sometimes we do, sometimes don't do user research at the beginning of the sprint. Someone will come up with an idea that we think it's a little nutty and we're like, "Great. Let's try it." And you take that idea and very quickly you work with them and put it in front of customers together. And sometimes you can squeeze in an alternate along the way and then together you're looking at it and going, wow.
First of all you've gained some trust because you've helped them visualize their idea which a super power design has. It's just kind of going around in their brain abstract and you've made it concrete and they're like, "That's amazing."
Then together you can put that amazing thing in front of people and if it works, then great. You're like, "It was good that I was humble." If it doesn't work, together you can go, "Wow. That thing we worked on didn't work. What are going to do about it?" And it's very different than saying, "You're wrong." And so sometime I put the user research at the end if we have enough time to do more and iterations after it.
I think it's very similar to the question about what's easy to measure and what's hard to measure. One of the things I did at Google was design the Google Checkout button, many years ago. And on that project the PMs were pushing us to make it more clickable. There's lots of ways from a design perspective that you can make it more clickable.
But it was starting to get a little garish honestly and I was trying to push back and say like, "Okay, this thing also needs to respect our brand is Google." And at one point my friend who was a little bit of a renegade came in with a design with a flame shooting out of it and it said free iPod and below it said, "When you checkout with Google."
He put that up on the screen and the PMs were like, "No, no. We can't. That's a non-starter." We said, "Why? I'm sure tons of people will click on it." If all you care about is clicks, this is your solution.
So we made them talk about, "Well that's not our only goal." "Great, what are your other goals?" and we got them to list out these other goals. And some of it was, set expectations correctly about what's about to happen with the rest of the checkout process. Present the Google brand in the right way to help build it and make it clickable and noticeable in the voice of a checkout process.
Okay, great. Now that we have those goals, then we can use a critique process to help us balance them and we can use A/B testing to figure out within what we think is acceptable for those other goals, those things that are more qualitative questions. How do we optimize within that boundary? I would not recommend using that technique but there are some good Photoshop flame tutorials if you need it.
I don't know, we've not had that much experience with industrial design and wearables. The closest we got was a robotics project with a company called Savioke. They make a hotel delivery robot that remarkably moves through a hotel and rides the elevator and delivers toothbrushes or anything else you forgot to bring to your hotel room.
As is the case with a lot of our projects, we were like, "We don't know what to do, but let's use our standard processes and see what happens." And I think because our process is so story-based and narrative-based, that experience design part of it actually worked pretty well. And it also reminds me that designers know how to learn from prototyping and that's like a thing that industrial designers and other people, they learn a certain way of prototyping like self-critique, but they often don't prototype to learn with customers. And that's something I think a broader industry can learn from us or put the other way, that we can push more people to do.
So I was working on an architecture project for our office space. We were working with architects and it was going swimmingly because designers and architects, great. And then we got to this point and we were like, "How do we prototype it?" It was like the record needle came off the thing.
"You can't prototype a building, that's hard." Like, what are you thinking software people? So what we did is what we do with all of our problems. We said, "Well, let's focus on what questions we have." And one of our questions was, we're going to make some of these rooms smaller and will that annoy a bunch of people in our office. Will we be okay with these smaller rooms?
We had lots of other questions, but that was one of them. So we thought, how do we just prototype that? There's a lot of questions about this building but can we remove risk there? So we went into these conference rooms and they had eight chairs around the table. We took four of them out so there were only four chairs left. Took all the other chairs and put them in the center of the office and tied them up so no one could get to them and waited a week to see if anyone screamed.
No one complained. So we were like, okay we can have smaller meeting rooms. Check. We've removed that risk. And there was a bunch of other things we tried. We put coffee at different places in the building to see if people gravitated towards different spots that would either encourage or discourage us from going with a particular floor plan.
But I think the idea is often with these more hardware things, people think you can't prototype it. Or with buildings you can't do that in this domain. But often you can if you're very careful about selecting the thing that you're worried about and splitting up all the risks into different categories and finding one of the other risks. And then prototyping around that risk and then moving to the next one.
My hope is that we can continue to work in a very similar to the way that we've worked if we're careful about that.
Ryan: Great. One last question.
Braden: First of all my [inaudible 00:42:33] design, it's in HCI, which goes back to human factors which goes back to psychology basically. Psychology is in many ways like the root of everything that we're working on here. Its how humans react to machines and work with other humans through machines. I think that as start-ups are getting better at understanding how to build products, they're getting closer to... they use more and more knowledge about the human brain in psychology.
This is true in BJ Foggs trigger action model. Its true in the "Power of Habits" things Charlie Duhigg wrote. There's lots of books out there really about how humans react to systems and the environment around them that is shaping the way that we think of companies. Sometimes for good, in terms these are habits we want to change, like, I want to run more. And sometimes for not so good, like, gambling and slot machines. The designers of slot machines know exactly what they're doing creating false wins and doing all these things to your brain that are a little scary. So you can use that either way.
For me, I think the biggest impact that it has had is in facilitation and understanding on how to work with the team and how to set up a process that helps teams of people work together. So one of the big changes I've noticed when we work with teams over the years is it used to be that everyone was talking. I thought that was a good thing that we're collaborating, we're talking.
And now I realize that when someone is talking, like in this situation, I'm talking and everyone's listening, that's a lot of wasted brain power. If we had a problem, we could all split it up and work on the problem ourselves with our own brains. And then, if we had to merge, we could merge together and find a really good solution. It's this parallel processing thing.
And when you're in a meeting, often the same thing happens. Only one person gets to talk at a time. It's very inefficient. So with facilitation, we're often looking for ways to break the problem apart, like a brainstorm. Everyone brainstorms individually, pick your top three and let's put the top three on the board.
That's a much faster way to brainstorm than having everyone just shout out stuff. That's really slow. So when we think about how we structure a design process, whether its thinking about challenges and solutions or thinking about how we get the most efficiency out of the room. We're often thinking about cognition and psychology for sure.
Ryan: Yeah, cool. Thank you very much Braden. I really appreciate you coming down to Zurb Soapbox. Thank you everyone for coming and all the wonderful questions and we'll see you next time.
