This week on The Dirt, we kick off 2015 with a new series entitled, Creating a Successful Product. We sit down with Mike Kruzeniski, the Design Lead at Twitter to talk about his thoughts on how to design successful product. Mike exposes the design culture at Twitter and how they make sure all products are of the highest quality.
Listen to the Show
Show Notes
Transcript
Mike: Where are you guys based? You sound very Canadian right now.
Tim: Hello and welcome to The Dirt, I’m Tim Wright. Today, I’m here with Steve Hickey.
Steve: Good morning.
Tim: Good morning, Steve.
Steve: Good morning, Tim.
Tim: And I’m also here with Mark, Grambau.
Mark: Hey, Tim. How are you doing?
Tim: I’m doing well, Mark. How are you doing?
Mark: Dandy.
Tim: Fantastic. And we have a very special guest today, all the way from the West Coast, Mike Kruzeniski, design director at Twitter. Mike, welcome to the show.
Mike: How’s it going, guys?
Tim: It’s going very . . . it’s swimmingly this morning.
Mike: I’ll allow that word.
Tim: So this is part of a series we are doing on creating a successful product, and we wanted to have Mike on the show because he’s created some very successful products. Correct me if I’m wrong, Mike. You were the creative director on the Windows phone project and now at Twitter; just a handful of great, great experiences.
Mike: Well with Windows phone I’ll say, I think I was of the more outspoken people working on the phone, so I tend to get more credit than I think I deserve by far. But I was working on Windows phone with a really great team, so thank you.
Tim: So I guess right off the bat, I wonder if you could take us through some of the non-secrets about how Twitter designs success metrics on a product.
Mike: That’s a great question. I guess for us, one of the things that’s really important and we’ve always talked about in the team, is how do you create a product that’s really delightful to use, that people really just enjoy using. But not with that as a goal that gets in the way of just creating a product that first and foremost just really works really well and does what people expect for it to do and stay out of the way and doing all the great things that Twitter does. We love the stories that emerge on Twitter, all the kinds of amazing things that happen every day. I think a lot about it happens because we just try to stay out of the way, and allow great things happen through sort of subtle things we do in the interface every day.
I think as a team, how we define success . . . one of the ways that we’ve really tried to focus the teams is to not think of design success as just purely design success, but as success as defined through the cross engineering and product teams that they are working on. So we as a team are a central design team, but all of our designers are working very, very closely. In fact every day, most of our design studio is pretty empty. So they are building a lot of the goals with the specific product teams that they are attached to, and so try to create goals that are a combination of what will make the engineering team successful and what will make the product teams successful, and what will make the design teams successful, and having all of those groups look at the same goals as making each other successful.
At some point, the view of the product is not specific to what the design team does, but how well the product works from an engineering standpoint, how well we chose which product to make based on the goals that the product team has, and see how it all comes together, the design.
Tim: One of the great things that I just love about the way Twitter does stuff is it was like the first instance I really saw of a company looking at the community and seeing how are they looking this application and then implementing those features. “They are using hashtags, let’s do something with that. They are using At Reply, let’s do something with that.” I know it was a while ago, but that was really the first time I saw somebody pay attention to what the users were doing.
Steve: And build around it; that was really nice to see.
Tim: Actually build features based on it.
Steve: So it sounds like the design team is distributed, and a question I would have about that is, if you have your design teams split across multiple functions and they are located in actual different locations, how do you go about keeping everyone coordinated on the same page with the same design language?
Mike: It’s really hard. The thing that we constantly are trying to refine and improve and it’s something we constantly keep an eye on, as a certain percentage of my time is always sort of focused on thinking about how we make that easier. It’s a combination of just how we sort of try to build the culture of people that are on the team. The design team is a very collaborative open culture, which needs to be because there are often different parts of the company working on different things, and their particular team may have some big goals, and they go off in a direction, but those might butt up against the goals of another designer working somewhere else. And so rather than having situations or disaster type situations where designers have been fighting with each other constantly to figure out wins. We have a very, very open culture where designers are all sort of at a very gut level, really want Twitter to feel like it’s been designed by one person and it feels really cohesive.
It’s not designed by one person. There are lots of people working on it. So our designers are constantly reaching out to each other and connecting with each other to see what each other is working on. We have, I guess, also a combination of processes. We have design cribs throughout the week that we are very public about. So those take place in the studio. So our studio is the kind of place where designers are always coming back together. They are coming back from their different parts of the building that they’re working in with the project teams and coming to meet up with each other and review work, share what they are working on. Every week we post what’s going to be reviewed and then the outcomes of that, people then post links to stuff that they are working on.
Tools, so we’ve actually being using Envision, which is a collaborative . . . I don’t know if you guys are familiar with it. It’s a really, really great tool. We actually have custom stuff internally that just was not keeping up with how big we were getting and didn’t have all the stuff that we needed. And so Envision has been really great for us to have designers posting work regularly, have other designers comment on it and being able to share broadly. And finally we have . . . I guess this is my background working on Windows phone and what I saw worked there. Having a team that sort of relies on control sets as the backbone of what you are building. So we have a team within the design team that’s focused on building control libraries, and then focus on refining the controls so that other designers will build off that, almost like Lego blocks. So no matter what designer you are, you are sort of building from those pieces and it helps all of it stick together. So it’s probably culture process tools and shared parts.
Steve: Somebody wrote a really nice article recently. They were comparing the maps application in iOS to Google’s Maps application.
Mike: That was one of our designers actually.
Steve: That’s awesome, that’s great. They had a really great viewpoint. What I liked at the beginning of it was that they pointed out that designing within a platform is such a different experience than a lot of agency designers are used to, because you need to design in a way that respects and promotes the platform and sometimes that seems like it’s less fun, but the end result is valuable and very, very worthwhile.
Mike: Yeah, it is a very different process. So John Bell wrote it, I worked together with him at Windows phone. I was really happy to have him. You should totally do a plug for John because I think John is brilliant.
Steve: Well it was an incredible article. It had a very interesting perspective I hadn’t considered before.
Mike: Yeah and it’s actually interesting because I think even reading that sometimes . . . in a way he articulated things that I didn’t even sort of recognize, but that’s very true. Like the way you work when you are trying to build a . . . I think in many ways, Twitter as in like an app. We have a rounded square on your home screen and it sort of looks like another app but it’s a very connected platform and you are working across multiple mobile devices in the web and so it’s sort of more like almost designing an operating system.
Mark: And that’s interesting, as you said going across platforms. That’s something that a lot of companies do. If you are building a product and you get to scale, all of a sudden you are going from maybe you started just as a web app, then you have an iOS app, then maybe you have an Android app, you have a Windows phone app. And all of a sudden you are trying to maintain yourself across all these platforms. Can you speak a little bit to the challenge of both feeling at home and feeling native on those platforms, and feeling like you belong, while also having a very clear strong brand identity as Twitter?
Mike: Yeah. I’ve been with Twitter for two and a half years, so my experience here is one part of a long history. And I think over the years, Twitter has gone back and forth to fill that out. I think lot of companies, bigger companies that have been around watching the different app ecosystems grow, I think there have definitely been moments in Twitter history where it’s sort of taken the approach of do whatever on either platform because they are different and you should do either. And then there was a point in time where there was a really strong draw towards very, very tight consistency because it saves the Twitter app and it must work the same across all the platforms. I think we are in a place where we look at both apps as we want them to feel similar, and so there are certain sort of fundamental elements. When I think of a tweet, it’s a core; it’s like a native object on Twitter and should work very similarly across Twitter.
But the UI around it, you have different capabilities on the different platforms, people use the platforms differently. The UI patterns in the platforms are different, and so if someone using the Android app isn’t . . . most people using the Android app aren’t also using the iOS app simultaneously. They’re using one or the other. So I think our point of view tends to be embraced in what the capabilities of the different platforms are. And I think that’s sort of interesting actually. I think John touches on this in the article, how Google has approached that. I actually really loved that Google was using the patterns of iOS in their apps, and they were doing a really great job at it. The Maps app, the Gmail app, they worked really well. It’s interesting to see them now, essentially saying, “No, there is a Google way of designing,” and they are doing the Google way across all apps no matter what.
I think it’s interesting to see Microsoft right now as taking the approach with a lot of their apps that they are putting across android and IOS, being very respectful to each of the platform patterns. To me that model makes a lot of sense, because someone using iOS all day is using iOS all day and they are familiar with it. As far as the brand like I said, once you identify what are the core parts of your product that are distinct to your product across all platforms? And so for us that’s like a tweet as an example, or profiles. It makes sense to have more consistency in there. The rest of the brand is just some of the . . . obviously the logos and the colors and those things, those are fairly easy to keep connected. And actually in some ways it doesn’t take much more than that.
Mark: I think your point of Microsoft’s recent work is a good example. Just looking at their update to the Skype app recently, you know it’s Skype, you’ve got that Skype blue, you know it’s Microsoft, it’s the font and the typeface up at the top. But then they also have a little bit of the behavior that would come out of Windows phone and some of their more recent design, just the way that you move between the content, but it doesn’t feel out of place. I think they struck a pretty nice balance there in terms of platform independence.
Mike: Skype is an interesting one. I’m a little surprised how much of Windows phone they brought into the iOS app. It seemed a little more than I would have personally, because it’s like they are . . . There is efficiencies from the design side that I think you get from working that way and I think some of that isn’t history as well. If you design it in one way, that’s easier for the design team. I think it’s less easy for the user though, because as you open up the Skype app, you have to learn the pivots, UI pattern.
Mark: Yeah, a new vision language.
Tim: Mike, let’s say someone listening to the show is in the early stages of a startup or building an app that they want to release, and there’s a lot of focus on getting to marketing quickly and getting features in. At what point do you think they should step back and establish some of those UI guidelines or brand guidelines and start applying? What’s the point of, “Okay I have enough features,” or should they even do that beforehand, before they start adding features?
Mike: I think it’s interesting being a designer. Coming from a design background where I think my instinctive answer to that question a long time ago would be, “Of course, you need the story; you need the strong identity around the product before you launch the product itself.” Having lived in the West Coast and then just part in San Francisco or Silicon Valley for the last couple of years I think that’s challenged the way I think about that stuff.
I think the builds fast or move fast, break things and MVP thing is a little bit too far on this scrappy side of the spectrum for my taste, but I think there is a lot to that. I think sometimes when I see really big product launches where clearly there’s been a big design agency behind it, sometimes I think they make the mistake of it as there’s so much that’s gone into the brand before even finding a market fit, before even finding whether the product works and whether it’s going to have an audience.
I think there is something to making a good product, having some sense of identity, but not over thinking it and not locking yourself into something too early, and going out there and seeing what works and iterating on it. I think there’s a lot of value to that. I don’t think it’s the right to totally lock yourself into some sort of brand guidelines and really strict story about what you are, just as you are getting started. Use that as much as it’s helpful to guide yourself, but as soon as you find it becoming dogma and constraining yourself, it’s so hard to build a product from scratch and so hard to find a market. Why you put arbitrary constraints on yourself when you are just getting out the door.
Steve: You need to leave yourself some room for exploration or you’re probably going to leave good ideas on the table at some point.
Mark: And the more you harden your brand, I think you are digging your heels in on your own bias a little bit. You may have a feeling for what this is and who it’s going to appeal to, and what’s going to be appealing to them and why. And you might be the most insightful empathic designer in the world, but until you get out there in the market, you are really not going to know it. And you need to understand how to identify the difference between snarky feedback and just complaining for the sake of complaining, and real dissonance with the market. You need to be open to that dissonance because it’s going to tell you that, “Hey, maybe I was misinterpreting how this design was going to be taken by the market.”
Tim: Mike, I’m sure you guys have to deal with tons of feedback. How do you process at that level what’s good, what’s crap, what’s snarky, what Steve is just tweeting at people randomly?
Mark: And you are at such a scale with millions and millions, hundreds of millions of users that . . .
Steve: Everything seems amplified.
Mark: Everything is loud and every small change. You guys can probably change the font by one little degree, the color by one degree and everyone freaks out, “Twitter is dead. I hate it.”
Mike: Yeah, that happens. My favorite changes are the ones where almost nobody notices. If you take the stance of a great design and it’s transparent or invisible, I don’t know if that’s always the truth, but there are lots of iteration and evolution we do to the product that you don’t notice, and it’s slowly making it better. If you look at Twitter the way it was a year ago or two years ago and you put that aside, you look at that, wow, there’s actually a lot of stuff that’s different. But because we’re sort of evolving it on a regular basis and not necessarily everything is being noticed right away, it’s just slowly making the product better in the background without disrupting the user too much.
Because I think if you are depending on Twitter every day for your news, for connecting with people and there are these massive disruptions, then that can be a bit jarring. That said, yeah we have big things that we work on as well and we try to find ways to work those in a way that makes sense to this fluid. And that they are focused on problems that people have, so that it feels like, “Oh, Twitter solved that problem that I had.” But we do have a little large audience, so the problems aren’t the same across everybody.
I think at scale, I think to your question, the smaller product on a very focused market, I think that that feedback tends to be roughly the same and so you can react to it in very clear ways. I think with the product that gets to a really large and global scale, you have to look through it and you have to determine what’s most important to act on, what’s a real problem, what’s a point of view that’s totally valid, but you just need to make evolutions to the product because a larger audience really has this problem and it’s working against a smaller audience potentially, but it’s an important change to make.
Some of the other things they talk about is an ongoing process. Everybody at Twitter I think is always looking in their timeline for feedback. We are very publicly available on Twitter. Some days I’m hearing from people who just reach out directly and say, “Hey, I don’t like this feature. I don’t like the way this works. Why don’t you have this?” And so we are always taking that into account, and we have research teams. Within the design team we have a user research team that’s constantly looking out across the product and reaching out to people to find out what’s working and what’s not working.
Obviously a lot of big companies, we have data teams as well, they are looking what’s the reaction within the product itself. Sometimes, surprisingly, I think some changes, people will feel . . . their first reaction to it is that they don’t really like it, but then what we’ll see is actually they adopt it pretty quickly and will move past it pretty quickly.
So I think with products like these, for me as a product designer, my first background in project management was industrial design, and then as we moved into interaction and software design, my first experience with software design is what I call like a box release. You do update release every six months or 12 months or 18 months what have you. That’s very, very different than the constant releases and you are changing the product as people are using it, and that’s new territory for designers. It’s a very tricky thing. “The things that my colleagues at places like Facebook and Airbnb and Amazon are all dealing with and trying to figure out how do you do that.
Imagine if you came out to your car every morning and suddenly the car designers had changed the way the door handle worked and where the glove box was. And they might have all very good reasons for it like , “The steering wheel is better if it’s in the center now.” That would be extremely jarring, and that’s the thing we are dealing with, that sometimes we have to make something work, have to make these bigger changes. And because we want [inaudible 00:22:30], we have to make these bigger changes. And how do you do it in a way that doesn’t feel disruptive, because people are waking up into the products.
Tim: It’s a big change for designers, it’s a big change for users too, as they are adapting to a world that they don’t elect to get that kind of change that just shows up. The first time I can really remember seeing that was maybe 2005, 2006 with Facebook specifically in one of their first big . . . I think it was the introduction of the News Feed, one of those big famous giant changes that everyone freaked out about because change is scary.
Mark: Like the world ended.
Tim: And that was one of the first times. After that I started seeing Facebook do it. We now have seen Twitter do it, I’ve seen Google do it where, “Hey we’ve got this new design, do you want to check it out? You can try it, you can look at it, but it’s temporary, you can go back.” And giving people the ability, really calling out that there are changes coming, giving people the ability to test it, try it, get their feet wet. But more and more I think people are having to get used to the fact that things change. iOS now automatically updates your software if you let it. And the Mac, too. That’s just sort of the world we are inhabiting.
Mike, you spoke about fragmentation of your users by demographic and by space, by being in a different country when you get to a huge scale, and that different users use things differently across the world. But can you speak a little bit about the user fragmentation that happens because of the growth curve itself? Talking about your early adopters, who in Twitter’s case were often very tech focused and as Tim was saying, they helped really build and design even some of those features. It’s the community that came up with At Reply, things like that, versus when you get to be on the scale that you are now, and it’s used by everyone. You’ve got a product that’s trying to serve people who maybe use it very, very differently and have a very different understanding of what it was because of when they joined that curve. How do you design for those very, very different kinds of users with very fundamentally different understandings of the product?
Mike: I think it comes down to investing in research. I think that’s been the best thing that Twitter and any company can do. I think within our design team, our design team, our user research team are very, very tight and we talk about always understanding the problem first and who you are designing for. We couldn’t do what we do without our research team. And I think in Twitter as a company, as different kinds of research teams that are always trying to understand exactly that. So I think the first step is identifying that and getting to know that the different people that are using the product and how they are using it. Because you are absolutely right, that is something that happens. And I think the bias you are always trying to work against, is how you understand the product as you and you use it every day.
And a lot of times, people who work at Twitter or a company like Facebook or Amazon or Dropbox are there because they love the product and they use it and it has a place in their life, and it’s fun to work on things that are meaningful to you. But that can build in this bias because you start to generalize things like, “Of course every does this because I do.” And so that’s a thing that we are always working against.
And then also I think with Twitter and any sort of network, you are also dealing with a lot of the people that I’m connected to on Twitter are other designers or other people who are in the tech world, who are probably similar age. But I try to broaden the kinds of people I’m following, but there’s probably a large overlap of similarity. And so that again biases when we introduce something and we see the way people react. And these times you can go, “Wow, everybody thinks this or everybody thinks this is important, or everybody doesn’t like this depending with the changes.” That’s not always true because these are your views of how the product is used, become reinforced by your network. And I think that’s a challenge that I think any designer working within a large product company or a large product network has to deal with.
It’s similar to a thing when I was working at Nokia, because Nokia designers, and I realized this in retrospect. I was, “You work at Nokia, so your phone bill is paid for and you’ve got phones whenever you needed a phone.” That’s not normal. Phones are easy to get and people call internationally all the time for free because you never see your phone bill, and so you start to have these really weird biases that get built up. Teams will talk about how important it is to dog food your own product, but I think it’s more than that. How do you put yourself in the shoes of these different user groups or if people who aren’t people who work at your company and are experiencing the product in the same way that you do.
Tim: That’s so difficult. We’ve the forest from the trees. We do it all the time. Even at a programming level, pair programming, just sitting next to someone, getting different eyes on the product, it’s really difficult.
Mark: Something that I actually . . . it’s not my favorite feature admittedly as a user in Instagram or in Twitter. The discover, the ability to just going into seeing what’s trending, it’s not how I personally use the product. But I’ve actually . . .
Steve: You’re criticizing Twitter.
Mark: Well I’m saying, well to his point, I use it one way but I know that other people use it in a different way. Discover is not the thing for me, but what I do really like it as is it’s helped me see that people use this product tremendously differently than I do. And I will open up the discover tab, where I’ve done in Instagram too where they are showing suggestions of suggested photos you might like. I see someone write the craziest freaking wall of hashtags. They are constructing a sentence with #I #love #puppies #sunset in Boston #blue sky #sure love puppies. And that last one is one solid hashtag. And at first you can’t help but criticize, “This is insane, what are these people doing?” and then I just think, they are using this differently than I do.
Mike: They are a completely different type of user.
Mark: They are a completely different type of user.
Tim: I think maybe Twitter needs to change the terms of service to go after those people for using excessive hashtags.
Mark: You could flag someone for abuse of hashtags.
Mike: But then at the same time, so much of Twitter’s history. Like you mentioned the hashtags, at handles, something like that, comes from that creativity. It’s sort of a fascinating platform to watch within this one constraint that we’ve got. What are other different ways that people . . . what are the things that people do with it? It’s fascinating. I think you quickly settle into your, “This the way that you are supposed to use it.” it’s really fun to see different ways again to use.
Mark: It’s sort of become a linguistic testing ground, a linguistic Petri dish for verbal memes. Not even straight up actual memes of setting around a weird GIF of judgmental Asian father or . . .
Tim: Or just a GIF.
Mark: But things . . . because Twitter, the use of the word because without the word of, a little weird linguistic thing that’s become a linguistic meme on Twitter. People write a certain way. Have you ever seen that?
Steve: I know what you are talking about but I never pegged it as coming from Twitter.
Mark: And maybe it’s not. I peg it as part of internet generation, part of [inaudible 00:30:19].
Steve: Well you look at things that came definitely out of Instant Messenger for example. You can identify a lot of speech patterns that came specifically from Instant Messenger.
Tim: Lazy teenagers is really where it comes from.
Mike: Yeah, we were all lazy teenagers.
Tim: Teenagers, kids. So Mike if you . . .
Steve: Laziness is a great way to innovate.
Mike: It is actually. There’s a longer discussion that we don’t have for it today about that, and how developers are inherently lazy, so we build systems that create these amazing things to save us five minutes.
Steve: Maybe we can cover that next time.
Mike: Maybe next time.
Tim: So Mike, if we were face to face with somebody and they asked you the question, what is the key, the one key, there probably isn’t one key, to creating successful products, what would you tell them?
Mike: Well I would have to lean on the way we think of it here. It’s really to understand the problem and always be going as you explore ideas. Going back to iterate around the problem and do everything you can to then try to validating the problem. I think it’s the thing that I see people skip constantly and it’s really weird, trying to understand, why are you trying to do what you do? I think there’s so much excitement around the idea and the ideas then become the thing that we think is the important thing. Actually getting back to the problem, to me is always the most important thing. I’ll see people sort of go, “Okay, well this is the problem.” And it’s like, well no, is that really the problem or did we just sort of take a sentence and try to frame the idea as a problem? Because that seems like a thing that people do.
Really understanding the problem, I think in the tech space, there is this term pivot. I think pivots are really just because the theme didn’t really fully understand or wasn’t really attacking the problem and so they had to pivot because they realized they weren’t really solving something important.
Tim: Every time I screw up, I like to assign a buzz word.
Mark: Well I think Pivot is a really, it’s this attractive word because we so romanticize the fail fast, fail often, and that we have to learn. But no matter how much you want to tell yourself that, fail is still a word with a pretty strong negative connotation. We all grew up with that in there, and so we say pivot. We are not failing; we are pivoting because are discovering this new direction to go.
Steve: Can I pivot with my personal life at all?
Mark: All the time.
Tim: It’s called a divorce.
Steve: That is not what I meant just to be clear. Sorry honey.
Mark: So cynical, so cynical Tim.
Tim: I opened the door and just walked through it.
Mark: Yeah, why not?
Tim: But Mike we want to thank you for taking time out of your day to chat with us, this was incredible.
Mike: No problem. This was fun.
Tim: I know, I learned a lot. This was a great show. And if people want to get a hold of you, what’s the best way to do that?
Mike: @mkruz.
Mark: @mkruz on where? Do you have a particular and preferred social network?
Mike: And Twitter would be great. I just assumed. Yes, on Twitter you can find me @mkruz.
Tim: And you can find us on Twitter also, @thedirtshow. Please send your longwinded comments to The Dirt at freshtoiledsoil.com. And send us a review on iTunes or Stitcher or send us a personal email. I just like to hear from the users. That’s all we have for today, thank you for listening, and we’ll try and do better next time, but honestly that was a fucking awesome show. Thanks, guys.
Steve: If you drift by the mic, that will actually come out as a pretty good Jetson’s noise.
Tim: His would be faster.
Steve: Yes.