Garry Tan - Design for Startups
Welcome to Week Four of Y Combinator Startup School. This is gonna be a great session. We have Gary Tan who is my good friend, former partner at Y Combinator, the founder of Posterous, the founder of Initialized Capital, which is what he's doing now, and an amazing designer who's gonna talk about product design and how to make that an advantage as you're building something people want. Then following Gary we have Kat Manalac who is my current partner at YC and Craig Cannon to talk about how you can use public relations and content to acquire users to improve the prospects of your company. Before we get going, I wanna just mention a few rapid administrative matters.
欢迎来到YCombinator学校的第四周。这将是一个伟大的会议。我们有加里·谭(Gary Tan),他是我的好朋友,也是Y Combinator的前合伙人,是Posterous的创始人,也是他现在正在做的初始化资本(Initiated Capital)的创始人,他也是一位了不起的设计师,他将谈论产品设计,以及如何在你打造人们想要的东西时,让它成为一种优势。然后,我们有Kat Manalac,他是我在YCCraig Cannon目前的合作伙伴,讨论如何利用公共关系和内容,以获得用户,以改善您的公司的前景。在我们开始之前,我只想提几个快速行政问题。
If you miss an update, I know everyone's trying to get their updates in so that they can meet the graduation criteria, do not fear. For now, the easiest thing to do is to send your update in an email to email@example.com.
It's okay. Don't panic. Secondly, we have, as many of , just an emerge of a number of your groups. Hopefully, it goes incredibly smoothly for everyone. Certainly it won't.
If, for example, there's a problem with your group, if there's no moderator, please let us know soon as you can again to firstname.lastname@example.org.
That's the easiest way to do that.
If for some reason you think you're in the wrong group, it doesn't work for some reason, let us know and we'll accommodate you to the best extent that we can.
If you haven't launched, we recommend that you launch, if you at all can.
If that sounds like a broken record, it should.
And with that, let's get going.
I am hugely pleased to introduce Garry Tan. Thank you.
- Thank you guys for coming all the way out and spending time with me to hear about design. Well, frankly, design can be incredibly complicated and there's a lot to it, and hopefully, an hour, possibly a little bit longer, we're gonna get through about 100 slides. So I try to cram down basically everything that I knew that founders would get wrong or run into problems with all the time. So it's not going to be super in depth. Think of this as more, these are the terms that you need to know, these are the basic concepts you need to know and personally I am actually self-taught. So the first thing that I really wanted to start off with is actually, I mean it's almost cliche to associate Steve Jobs with design, but I think that this one of the most important things.
If you're in this room or watching on the internet, you probably already understand this. This is why you're starting a startup, it's that "Everything around you that you call life "was made up by people that were no smarter "than you and you can change it, "you can influence it and you can build "your own things that other people can use," and Steve says, "Once you learn that, "you'll never be the same again." So the thing I really wanna underscore here is: What is design? It's about making and building these things that other people can use and if you remove one word from that sentence, it actually doesn't work. So what we're gonna explore today is, well, what is design? Why does it matter? We're gonna go deep on both the concepts around product design, interaction design and visual design, but we're also gonna see, tactically, how do you actually do it yourself? Even if you have no design background whatsoever, if you're a human being, if you're smart, if you can put yourself in the shoes of other people, well, you too can do it yourself.In fact, as founders, you probably need to. Then finally we're gonna walk through, well, when should you hire and how should you do it, when should you use a consulting firm, things like that, practical matters. So I spent my 10,000 hours, actually, I was trained as an engineer. So I've never been to school for being a designer, but I taught myself. Whether it's books, learn by doing, I just always found myself, not just in my code editor, but also in Photoshop trying to dream up, trying to figure out, what should it look like? How do I want people to feel? What should I be building before I actually put it to code?So I've been a program manager.I was employee number 10 at Palantir, and then YC funded me back in 2008 with a company called Posterous, which we will actually use as an example for some of how I've thought about product in the past and how you might be able to apply that to your startup in the future.
And finally, I spent 10 batches working with companies, initially actually just as designer-in-residence. So I sat here in this room during office hours with more than 1,000 founders, just like you, just starting out, how do I build my first homepage, what's my first-time experience, and then after that, what do I do next, how do I build a design process or product process? So what you're about to see is basically the distilling of those 10,000 hours. One of the things that I am most excited about when it comes to design is this ability to actually sort of put together the iconography of something that is very significant. So when I joined Palantir, it was just 10 people, and we got to design this logo. One of my favorite things about it is this mix of both meaning and aesthetics. So on the face of it, one of the things I really wanted to do was sort of really underscore what Palantir was about. So at one level, this word mark, but with this specific logo, is actually a palantir.It's actually an orb on a pedestal from Lord of the Rings.
It let you see into your enemies' secrets. So on a very literal level, it made sense, but a more subtle level of this that was very important to us as we were building that company was that this is also a human reading a book. So one of the major themes of Palantir broadly is that we're at this moment in society where computers are able to help us understand the world around us in a much more fundamental way, so what a computer is is basically the infinite book. So that was just one example where I've seen design actually will help put together a culture for a company, and it's fun.It's just fun to be able to translate all of these different pieces of a company and why we're here, what it's about to something that can go on a T-shirt on a hat, actually. So really, really big disclaimer: I'm an engineer by training.
I've never went to school, never went to school formally for this stuff, totally self-taught, was a founder, so I applied this, just like you.I did it myself, and now I'm a VC basically by accident. So the things that I'm talking about today will be a hyper simplification.
If we wanted to, we could turn this into easily a 10-week course just about each given section, but instead what I want this to be is a roadmap. So you might hear these terms. There will be times in your startup, like perhaps now, perhaps tomorrow that you'll wanna actually start applying these things. Google's your friend. Everything in the world that you need to know, it's out there. So the computer is truly the bicycle for the mind. So the other thing that I really wanna underscore is we talk about design as a singular thing on its own, but it truly is deeply integrated in this broader picture of how do you create great products? It's not just design on its own.It's how design actually interfaces with all the other pieces of the pie. So it takes great product management, in addition to that great design and engineering and customer support.It's all of these things, and especially at your stage, don't box yourself in. You have to know that you are the shepherd of your product and you're gonna have to do every single one of these things. So what is design? Why does it matter? In a nutshell, it really is just these two very simple things to me.
It's just creating things for users that work well, and delight them, and those are two, sometimes disparate things as we'll see. Some of the most inspiring companies to me in the world, they have design as a very core piece of what they do. So can't talk about design without talking about Steve Jobs and Apple, obviously, but the first misconception that is probably the most common misconception is that design is how it looks.
It truly is not merely how it looks.
It is actually also how it works, and that's why in the slides that are coming up we're gonna talk a lot about that process on: how it works, what should it do, and what are the problems? I like to think about Leica and I just got my first Leica camera and I kinda can't believe I waited this long in my life to finally get one, but one of the really interesting things about Leica as a brand, it truly is this beautiful design, this incredible brand, but then it is also functional.
It's also about deeply the functionality: why is this thing better than all the other things that existed before it? So a review from 1929 actually just straight up told you that. A Leica at that time was basically magical.It was eight times lighter and 10 times cheaper.
It was an incredible machine for its time, and it's still a pretty amazing machine. To other physical products as well, one of the great design inspirations for me and for a lot of other people out there is actually Dieter Rams who built all of these very simple, incredibly beautiful products that were incredibly usable. One of the most important things that I think that he really showed us in his designs is that a good design is actually as little design as possible, so minimalism, and so that's a point that we'll return to several times in this presentation, but the key thing here is, how do you create things that are not burdened with non-essentials? It really is about purity, about simplicity. Just to drive it home, I mean this is a guiding sort of force and sort of everything that we see in the marketplace today. History doesn't repeat, it rhymes, and another theme that we'll get back to in this talk is actually simply the fact that there's very little totally new under the sun.
In fact, as designers, you probably shouldn't be spending too much time trying to be extremely novel because novelty is the opposite of functionality. So what do I mean by that? Earlier we talked about form versus function in the form of delight and works well. These are sort of the two yin and yang, the opposing forces when you're trying to put together a design. We obviously always want something to be beautiful, want something to make you feel good, make the user feel good, but at the same time, and delight is also a part of novelty.
It's the, "Hey, this is new. "I've never seen this before. "This is interesting." We wanna see more of this, like, "Let me turn the page. "Let me click next，" but at the same time, function is the thing that, that's the steak.
If delight is the sizzle, then works well as the steak.
That's why we're here. We're trying to get something done. So part of the problem with form over function, and this actually happens even in the best products.
I mean I'd like to call out Apple for its notch.
I mean that is the definition of form over function.
I mean this is a photo from their marketing website and certainly it's incredibly novel, certainly it serves the purpose of a marketer to be able to have this very novel different thing and to differentiate it from all of these other smart phones out there. But in terms of function, when I'm watching a video, this is categorically worse.
I'm not here for the notch.
I'm here for the content, and this happens all over the place. You might go to a restaurant later tonight and it's a beautiful restaurant, incredibly well decorated, very very thoughtful, incredible food, but you'll walk in and you'll sit down at this seat, and "Gosh, it's so romantic, "but I really can't read my menu. "I can't even order." This is again an example of form, this idea of, "Well, we wanna make people feel like this "is a romantic, premium, incredible experience, "but then if I can't even read the menu, why am I here?" This happens all the time.
I mean one of my favorite books that I highly recommend that you read is Don Norman's Design of Everyday Things and he basically has a whole chapter about this on doors that are incredibly beautiful, but you have no idea how to use them. So this is one of the more absurdsituations of like someone actually had to write pull on this thing because too many people could not figure out how to use a door. A door is one of the simplest things that you could possibly try to use. But when you put form over function, if you put the wrong door or it's too elegant, it's not clear how you use it, well, that's missing the point. So if you take a moment and try to think through, like why is it that we see form over function so much in the things we use, the products we use, just walking around in our daily lives? Why does this happen? Clearly, this should not happen.
It's that form should follow function and deep down I really wanna emphasize the one thing that frankly as founders I think you need to spend a lot of time on, and that's empathy. This is the thing that I admire. One of the things that I admire the most about my time both working at YC, but also as a founder going through Y Combinator back in 2008, it was the sitting down with Paul Graham. He would give us such incredible advice about specifically, what are your users thinking? What are they feeling? Why are they here? Really being able to peel away the layers of like, I know we're sitting in a room looking at this particular UI but put yourself in the shoes of someone who has never seen this before, and this is something we'll come back to again and again. One of the things that I put actually in my recommendations for design resources, and on its face it's kind of absurd, this is a Depression era book written by Dale Carnegie, a self-help book, but I actually think that it should basically be required reading for founders, it's that one must actually become genuinely interested in other people. You actually have to see their point of view. You wanna be able to be sympathetic, like understand: What are their ideas? What do they understand?What do they actually want? This goes back to YC itself. The first day you get into YC, you get a T-shirt that says, "Make something people want." I don't know if they still do this. Do you still get a T-shirt if you get an exit that says, "I made something people want?" Yes, I need to get mine, by the way Oh shoot, okay. Maybe that's why I haven't gotten mine yet, okay. So one of the things that's really interesting about building highly technological products is that we often think about them as incredibly complicated machinery, but the most useful mental model for me in what I've been doing is actually to not think of it as building a car or even building a website or writing software or anything like that.
It's actually about throwing the best possible party you possibly can. So if you think about great parties you've been to, there's no line, you're ushered right in, a human being, ideally someone you know, someone who's very friendly comes to you and says, "Hey, welcome. "I'm so glad you're here. "Here are your friends. "Oh, let me take your coat. "Beers are over here," and so that sort of politeness, that inviting welcome nature, that thoughtfulness, that's something that you really have to keep in mind as you do your work as not just as a designer, but as a founder. The key piece here is actually knowing what problem you're actually solving, just being very crystal clear and this is sort of, if I'm starting to sound like a sort of, if I'm repeating myself, I mean that in a nutshell is I think what you're going to get over and over again at Startup School is that really how do we be as crisp as possible about here's the problem that we need to solve. This is sort of the core tenet of design thinking as well. So part of the problem with not knowing what your problem is and going back to lack of empathy and going back to basically form over function is that if you don't know who that user is, what their problem is, then you are in danger of creating something like this. Basically each of these do sort of talk about a particular pr-od, they refer to a particular problem that someone might have, but if you buy any of these products and you have that problem you're trying to solve, now you have two problems.
If anything, each one of these inventions were created mainly to serve the central problem of the inventor, of the inventor wanting something tosolve. So this is the opposite. Again, just to give more examples, this is the opposite of empathy. This is you putting novelty, putting one's own interest ahead of your users, of society, of the people around you. So at the end of the day, if there's no problem, then there's no solution.
It ends up being design for its own sake, and design for its own sake isn't design.It's art. There's nothing wrong with art, I love art, but that's not what we're here for actually.It's founders creating things that people don't actually need, or engineers do this too. We make stuff that we think we need and then actually it's not better, it's not novel, it's not something that other people actually want, and that's a problem. So there are so many types of design.
It's no mistake that some of the most obvious examples of companies are design-driven. They're actually hardware companies. There are as many kinds of design as types of things that humans need.
It's no mistake by that. Architecture is absolutely a form of design. Branding and identity, communication design, being able to communicate something using data and iconography, or maps, or charts. Furniture design, a piece of furniture easily has all the same mechanisms as anything else that a human being might use. Landscape design. How does someone go into a place? How do they use it? Where do they know where to go? Packaging. So how does this make me feel when this arrives at my doorstep, if this is a gift? Why is there a gift box, anyway? What is the form and function of each piece of this physical object, or transportation design. A car is one of the most evocative things.
It's almost entirely pure emotion, but for the people in this room, I think that these are probably the ones that are most relevant to you and we're gonna spend a bunch of time talking about that. So this is again an extreme oversimplification, but the way I would break it down in terms of design for startups really is, product design, so what's the problem and who's it for, interaction design, so how do we actually do that, how do I actually create wireframes, create the flows, create the sort of intermediate step between that and the pixel-perfect ready-to-go ready-to-implement thing, and the visual design actually really is about that last mile. Part of the reason why we divide this up this way, to be frank, the ideal is that you have a co-founder on your team who's able to do all of these, and then if they can code, that's amazing.
If they can do business too, that'sincredible, but that's obviously a unicorn. Unicorns are incredibly rare, they do exist, though, and I'm sure there are a few unicorns in this room as a matter of fact and certainly quite a few are watching online. So shout out to the unicorns in the room. So part of it is you will find very specific people who have experience and who are extremely good usually at one of these things.
If you can find someone who's good at a few of them, you're really, really blessed. Man, if you can find someone who can do all of those things, immediately make them a co-founder, but only if you've known them for a while. So going back to the overall product process, I mean there is sort of a sequential aspect to it. Truly, you start with product design. Each of these, it really is a little bit of a water flow sometimes. You really can't start interaction design without actually capturing requirements, and then finally, of course, engineering.
Ideally you're kind of in conversation all the way through, but engineering and actually implementation, often that is something that happens afterwards. So let's dig in a little bit to product design. So what's funny is I'm cheating a little bit here.
I am actually mashing product management into this, but to me, I actually just can't do, I can't do the design process without doing this part. So it really is thinking about the business case: What's the problem? Who has the problem? What are all the possible ways to solve the problem and what's the actual priority for each of those parts? So indulge me.
I know this isn't exactly formally a part of design.
I just don't know how you could possibly do design without doing this part too, and every single one of these things has a fairly specific deliverable. So in this case, the deliverable here is a PRD, a product requirement, document or you can also call it a spec. So the interesting thing is, there's not really one way to do product design just as, you can call this product management. Microsoft calls it program management, and then some organizations sort of de-emphasize some of this stuff and they just call it project management, but the project manager still actually has to think throughall of these things. So the labels matter less. The fact that you do them matters a lot more. So this is actually the actual content of my YC application from basically January of 2008 or I think it was February. You really do sort of have to start with a problem statement.
What we were trying to solve is this ability to post online. We looked at online services at the time. Blog platforms have been out for a while, but they're pretty stale, actually, and the iPhone was brand-new, and then we looked at email as sort of this universal way to get content online. We thought this is a novel, different way to actually do it. So one of the most valuable things that you can do once you have that problem statement is actually to think through: Who are these very very specific people who have this problem? So I'm gonna use Posterous as an example to walk you through personas. So personas are just one tool for designers or product people to think through who are these very very specific people, and it's just a tool. There's not really one way to do this either, but this is what we did. We thought about our users really as three different types: David, the dad, is sort of one of them. We kind of wanna identify them as specific human beings. This is a very abridged version that you might do. Sometimes you fill them in on back story, like what school did they go to or what kinda family did they grow up in or very specific things like what type of phone do they use or what type of computer do they use? Back then it was, did they use Internet Explorer or did they use Chrome? Did they use, I'm not sure if Safari was even out yet.
What do they use for email? What type of technology? What level of comfort with technology do they have? So that will actually help you a lot when you're making decisions about, well what are you trying to do and what are the features that really matter? Another persona we had was actually David's family. So we captured this in the form of Grace, the Grandma. Some of this is actually intention as well. She's a little bit less, she uses an Asus Netbook. She uses Hotmail. She doesn't really understand exactly how to use it. Part of the reason why this is incredibly important is thinking through both modality and level of comfort with technology is often some of the most important things.
You guys, some of you in this room are actively thinking about building things for totally late-adopter industries. Some of the best YC companies in the past five years have been, they're being deployed to construction, to global freight. So if you walk into any office in the world, you're gonna find some tech savvy people, but not a lot. So even for enterprise companies or B2B companies in the room, these personas, it's still a very valuable exercise because it makes it very clear. You might have your decision maker, you might have your executive, and then you might have your line-level worker and their capabilities with, their motivations, why they're here, they might be very different. Finally, we also had, this is the dawning of social media, sort of the Cambrian era of social networks and so it wasn't clear that Twitter was going to win yet. There were sort of a dozen different social networks that were happening, and so this was another persona. She had very specific needs, and so we're trying to build something for her as well. So one of the things you really do have to do as you think through a sprint, whether it's the next two weeks or the next month, the shorter the better, frankly. A PRD document basically will detail, "Here are the actual features "of what we're trying to build," and so there's not really one way to do it. You just try to bucket them into coherent features that make sense. So in our case, one way to do it for us would be post by email with plaintext.
You might have your decision maker, you might have your executive, and then you might have your line-level worker and their capabilities with, their motivations, why they're here, they might be very different. Finally, we also had, this is the dawning of social media, sort of the Cambrian era of social networks and so it wasn't clear that Twitter was going to win yet. There were sort of a dozen different social networks that were happening, and so this was another persona. She had very specific needs, and so we're trying to build something for her as well. So one of the things you really do have to do as you think through a sprint, whether it's the next two weeks or the next month, the shorter the better, frankly. A PRD document basically will detail, "Here are the actual features "of what we're trying to build," and so there's not really one way to do it. You just try to bucket them into coherent features that make sense. So in our case, one way to do it for us would be post by email with plaintext.
That's just one coherent thing that's a capability. You can hand this to an engineer and they would understand what exactly that was.
And then post by email without an account. So one of the things that we did for Posterous that was very novel was that we didn't have a sign-up flow on our homepage. All you had to do was send an email from whatever email client you actually already had and you could attach anything to it and we would just reply with your new URL.
It was very intentional in that we wanted to cement a totally new novel behavior that nobody had ever done. So you could just email email@example.com and we take care of the rest. The interesting thing was the capability itself was not novel. There were other people who were doing it, but it wasn't a central part of the flow. So once you're able to do the basics of it, there other things that you wanna be able to do: photo attachments, being able to take multiple attachments and turn it into a web gallery, being able to support videos, and then finally a security aspect that was very important for us early on was that we launched at TechCrunch. Michael Arrington himself actually reviewed us and he new that if he started using it, everyone else in the Valley at the time definitely had his email address. So he almost immediately tried to get his technical friends to try and hack 'em and luckily we had already figured that one out. So it wasn't possible for someone to actually spoof his Posterous email address, and that was novel and actually important for us.
So I wanna pause there and actually say, earlier when I said it was these steps, I actually lied. There's actually an additional step in here. This whole exercise, when you're talking about users, this is actually called user research. So if you see that term out there, if you end up trying to hire people for that role, this is sort of where it fits. Frankly, if you're working on your startup, you should be just doing this as a matter of course. You should not be outsourcing this. This is a basic piece of customer development: understanding your users, spending time with them, being able to write down specific personas for, these are the types of users we want to use our product and to be as basically crisp as possible around what their needs are. We call that user research. This actually does, done right, it does actually happen before you even start thinking about what problemsto solve at some level. So if some of you out there are trying to figure out what problem to solve, sometimes you could just go and talk to people who you wanna build software for and that has worked for people.
So if you see that term out there, if you end up trying to hire people for that role, this is sort of where it fits. Frankly, if you're working on your startup, you should be just doing this as a matter of course. You should not be outsourcing this. This is a basic piece of customer development: understanding your users, spending time with them, being able to write down specific personas for, these are the types of users we want to use our product and to be as basically crisp as possible around what their needs are. We call that user research. This actually does, done right, it does actually happen before you even start thinking about what problemsto solve at some level. So if some of you out there are trying to figure out what problem to solve, sometimes you could just go and talk to people who you wanna build software for and that has worked for people.
That will shake out their problems. So once you actually know what these requirements are, the next step really is prioritization. So this is just a guideline. This has just worked for me in the past. There's not one way to do it but this is more so basic Project Management 101, but being able to assign these priorities to the specific features is actually a very very useful and important exercise. P0 is pretty self-explanatory. This is just the core thing.
If we don't do this, then what are we here for? So P1 is what you would consider the next obvious step. You just wouldn't ship without it, but maybe it's not quite as core.
And then you if you think about this in the terms of say a two-week or three-week sprint, you try and get all the P0 bugs, the P1 bugs. Actually, sorry, I skipped ahead a little bit in that if you haven't started using a bug database in your software development, you absolutely should.
In fact, that's one of the key ways that you, as a small team, you might not need it. But as you grow your team, it can be one of the most fundamental ways that you can make sure that you're doing the right things as a product, especially as your team grows. Having a bug database and assigning these priorities, and it doesn't have to be this. You as a team, you could figure out what these priorities mean for you, but being able to sort of manage a given sprint just at the beginning by putting these bugs in. Linking to a PRD document or all of the wireframes or the individual comps that an engineer needs, that can be one way coherently you can run your whole product and engineering organization. So as we go down, one of the things that has always worked for me is actually, a lot of the devil in the details is actually in priority two and three because things will always go wrong, almost guaranteed.
I mean I just have never been through any sprint or any release thatthere's things that are totally unforeseen that break things. So part of the reason why this prioritization is very important is that it makes sure that you try to set up realistic goals. One of the most dangerous things in product development period is that if you don't have these priorities, you don't know what to cut and so that two-week sprint might become three weeks, four weeks, six weeks, two months, three months and then you never ship. So we'll talk about that in a little bit, but this is really why priority matters. So in this case, it's pretty straightforward. Post by email with plaintext, hey, that's a must-have. We're just gonna start that first. Then one of things that, you don't always write this in the spec, but it's something that's just very useful as you think through this stage of your product development process.
It's really helpful to think through: who of my personas, who of my users need or want this, and is that important? What's the interaction between them? Post by email without an account. Well some of our less technical users are actually very scared by signing up for new products. So being up to do this without an account really opens up our user base to the whole set of people who are not very technically savvy, and then photo attachment support, David and Irene as power users.
考虑一下真的很有帮助:我的人物角色，我的用户需要什么或者想要什么，这很重要吗? 他们之间的互动是什么? 通过电子邮件发送，没有帐户。事实上，我们的一些技术较低的用户对新产品的注册感到非常害怕。因此，在没有账户的情况下，我们的用户群向所有技术上不太精通的人开放了，然后是照片附件支持，大卫和艾琳作为超级用户。
It's 2008. They have the the newest most beautiful iPhone and so it's immediately the thing that they really really wanted to do. P2, as you go down, you can kind of break it down, what is important and what is less important? So to be frank, this has never happened before in my life, but if you're very very lucky and your product development goes awesome in that particular sprint, that's often one thing that you can just start, it's valuable to have P2 and P3 things as a part of a given sprint simply because sometimes you'll just have extra time and someone will be able to get farther along than you hoped. The reason why it's useful is that then you can think about your product across different sprints, so you might be doing a release this month and then P3 video file support.
If your software engineer knows that that's something that they wanna do, well when they're factoring, when they're actually writing those classes or writing the library or architecture of that code, they'll know that they can't make it just for photos. They'll also be able to support other types of media and that can actually save everyone on the team a lot more rework. So one of the key difficulties of product is always trying to figure out: what are we doing now and what are we doing later? So priority and being able to be very crisp about these requirements, that's one of the most fundamental ways that you can make sure, like release-to-release, you know that the product's going in the right direction. So that's really, really Product Management 101, but if you do this, you will be far ahead of pretty much a lot of your peers. A lot of people don't even do this very basic step of: writing down what these features are, who are they for, what are the problems we're trying to solve, and then what are the respective priorities? One of the classic reasons why, we kind of talked about this already, but if you do the prioritization upfront, then PM-ing a given product gets very easy because you can just cut off the bottom. Everyone sort of knows, "Well we're gonna start with P0s first, then P1s, and then, "oh if we're ahead, like let's do the P2s and the P3s. "But if we're late," well the key thing that everyone and all of you will run into this, you really have three things in front of you: scope, quality and time. So how much you do, that's part of the prioritization. Quality. The reality of it is this is not encompassed by your PRD.
It's just purely in how people use your products. How many bugs are there? Are there things in there that just don't work? That's sort of always an issue, and finally, time. You can always do all the features you want with the highest possible quality, but you might have to slip your date by two weeks, three weeks, four weeks.
If you don't cut scope, likewise, well, you might be able to hit your time, but users are gonna run into a thousand bugs in production and you're not gonna like that. So if we work backwards from that, then this is precisely the process you use to sort of fight that. So the other thing that is very common, the other reason why prioritization is incredibly important is that without this, well you basically can head off a lot of really strange product decisions at the pass. So if you ever get incredibly frustrated with, you're deep in some settings panel in your iPhone or any sorta product and you're like, "Why is it broken like that?" Well it's probably because someone failed to do this properly and so they just said, "You know what, "F it, we'll just ship it." So it's a real danger. Product quality and products really really fail simply because prioritization, these basic requirements are not really figured out. So finally and the classic thing that personas really help you with is sort of this classic trade-off of you're gonna have users who are incredibly savvy and some people who are incredibly un-savvy and how do you actually deal with that? How do you think through not just what you're going to do, but also how do you represent it on the screen? So all of these things are incredibly important for this very first part, which is just pure product design. So interaction design. So you know who the user is, you know what the problem is, how do we actually translate that into something that you can actually start working on? So the questions you ask: How will they actually do it, what are their goals and how do they achieve it? So at end of the day what you're trying to get to is either a prototype or a wireframe. So what these things are are basically, you even might use a tool like OmniGraffle or there quite a few prototyping wireframing tools that are out there.
What you wanna do is figure out just the text, just the call to actions, just the flow, screen-to-screen. You don't wanna care about color. You don't wanna care about really how it looks, what font you use. You don't even really have to worry about layout too much, though I would start thinking about layout as a part of this process. So the most interesting important aspect of interaction design is actually that people treat, and this is kind of a very shocking thing to me.
I did a research at Stanford for the late Professor Cliff Nass and he built an entire career at Stanford based on this notion that people treat computers like people and it turns out that if a computer is polite to you, a person will be likewise polite back or being negative will sort of elicit the same response. Almost every psychological principle that psychologists have proven, Cliff Nass and Byron Reeves and BJ Fogg at Stanford were able to show that people mirror with computers, even without any sort of anthropomorphism, without clip-py, without an avatar, without anything like that. Truly, every interaction you have with computers, they're actually a conversation.
我在斯坦福为已故的Cliff Nass教授做了一项研究,他在斯坦福大学建立了整个职业生涯的基础上,人们把电脑当作人对待,结果发现如果一台电脑对你有礼貌,一个人会同样礼貌地对你,或者消极的态度会引起同样的反应。心理学家已经证实的几乎所有心理学原理,斯坦福大学的Cliff Nass、Byron Reeves和BJ Fogg都能证明人们用电脑照镜子,即使没有任何形式的拟人化,没有剪辑,没有化身,没有类似的东西。真的,你和电脑的每一次互动,实际上都是一场对话。
It's a conversation that happens over and over and over again because it's written in pixels, it's written in design, it's written in code. So what is this about? At the end of day, interaction design is actually about commands.
It's actually about telling people what to do and you actually doing it. People are incredibly suggestible actually. One of the most interesting psychological phenomenon that I can think of, it may be explains Trump and a lot of other things, is that actually when you absorb media, whether it's reading or any type of media, period, you actually read that stuff in your own voice and so that actually becomes deeper and kind of a part of you. So as an interaction designer, an interaction designer is not merely the person who figures out where the buttons go or what the layout might be or what the flow is. They're also the writers. They actually are trying to influence people directly by using direct command language, and so this is actually one of the most common mistakes that founders make. They write like this. Well, so, just to put a point on this, really command language is about, people will do whatever you tell them to do. You just really do have to tell them. So this is a super common thing.
In fact I'm pretty sure a lot of you are making this mistake in your home page copy in your design in your first-time experience.It's passive voice. You're not showing, you're telling, and you're just describing something about what you're doing in sort of this sort of third-party disembodied voice.
I thought a lot about why this is. I actually think big companies actually can get away with this.If you go to most big-company websites, they are actually written in a very passive voice.
If you go to Microsoft's homepage and start clicking through products, the product names are like blah-blah-blah server edition, admin 2009, whateverit is.
It's like this insane word salad and if you read it, you have no idea what that product is and who's it for, but Microsoft can do that because it's incredibly big and it has a scale that's unimaginable and it has a sales force that will go out and sell their product and they have incredible amounts of capital. But you as a startup cannot afford that, and so everything that you write needs to be direct.It has to be a direct personal voice and you need the call to action be incredibly obvious. Why is this so small? This happens all the time actually. People never are opinionated about what you want the next user to do, and so this is an extreme example, obviously, but what you want is: contrast, you wanna be incredibly direct, you want to use command language and you want the call to action be someone goes to that webpage and they just know, they go to that mobile app and they just know what they need to do. The other part of interaction design that is actually also very important is trying to figure out, aside from direct command language, how do you get people to actually do things? So obviously this is an oversimplification, but I generally think about this in two ways. One is, how do you remove actions? One of the things that Paul Graham really directly called out to me on our sign up page back in 2008 was, "Why the hell do you have a confirm password? "Well, I mean, you have their email address. "If it's broken, just ask them to click, forgot password. "It's fine. "It's really not that bad to just have them "type a wrong password and have them recover it, "and most people won't type the wrong password, so is fine. "Why would you optimize for this strange "case that doesn't happen that often?" and it's actually really interesting.
If you remove that confirm password, it actually will increase conversion on a sign-up flow by as much as 50% on average. So it's significant. Cognitive load is an incredibly real issue. The other strategy that you can really use is, how do you chop up an action if it's incredibly complicated? How do you break it up into steps? So I like to use this example 'cause Windows '95 is this absurd, I mean one of the first wizards really to come out, but I think that there is a timeless aspect to it. The other thing that I often think about because some of you in this room will be doing fairly B2B, enterprise, just like complicated configuration steps, kinda like doing your taxes actually. You don't have to do the taxes that often, but when you do, it can get really complicated. You might have branching flow. You might have a lot that you have to take care of and so the other thing that you can do is actually chop up those actions more intelligently with the wizard. So these are a couple patterns that you can use and then I wanna kinda stop there and sort of really point out another super-big misconception in beginning designers or people doing it yourself have, they sort of run into all the time. They're always trying to do something incredibly novel. At the interaction design stage, I don't recommend that.
I actually really recommend that you just steal what works. So don't reinvent the wheel.It's very important for you to be aware of what are the conventions and things that people already use, and so these are very basic ones. For instance, pull to refresh is something that works incredibly well. A lot of apps do it, but it's become a convention because it's easy and natural to use. It's satisfying.It's great to use.Swipe left to right, this was from Mailbox app, which sold to Dropbox.
我真的建议你偷点有用的东西。所以不要重新发明轮子,对你来说非常重要的是要知道人们已经使用的习惯和东西,所以这些都是非常基本的。例如,拉pull to refresh是一件非常好的事情。很多应用程序都会这样做,但它已经成为一种惯例,因为它很容易使用,而且很自然。使用起来很好,从左到右,这是邮箱的应用程序,卖给Dropbox。
There's a reason why, Mailbox was incredibly innovative, but the reality was like, you guys generally don't need to, and you can get really really far with just design patterns. So this does take a little bit of time, and frankly, anyone who uses computers for any amount of time, you can just click through all of these things and just the synapses of recognition will just kind of come to you. You'll just realize, oh my god. There's actually so much that you have already seen that you can just steal wholesale, and that's actually what is desirable for you for most of your designs. You don't want to be novel.
You wanna be something that gets people to the right place as quickly as possible. So there just so many of these that I can't possibly cover them.That would be its own 10-week course so I highly recommend, go to that website and check it out. So one of the really interesting things I do wanna call out and is sort of a danger zone for using design patterns, one of the more common ones that I've seen is actually using the wrong kind of pagination. One of the things that can be very frustrating to users, I've seen people design for the web and they actually use these little dots to represent where you are in sort of a swiping navigation, but you're on the web and you're using a touchpad, and that makes no sense at all and in fact it's really really bad. So you have to be incredible careful with mixing modalities. Even each one of these design patterns as you implement them, you should sort of think through, like, well why am I here, what is the user trying to do, and does this make sense for my modality? Here's probably the most tactical part of the whole talk, but we're gonna start off with a little bit of theory. Visual design really is about, again, these things really do blend together, it's the interaction design and visual design, they're super linked and it really is how you tell a user what is important at the visual level.
What emotions do we wanna evoke? How do we want them to feel? The output of this is either pixel-level compositions, usually Photoshop, or sometimes the actual HTML CSS. So the really interesting thing here is that, to go back to function over form, when you're forced to be simple, you actually have to solve the real problem.
I wanna start off by just saying, like, let's just avoid as much ornament as possible. Ultimately we're here to build something that solves people's problems and it's about that substance. One of my favorite design thinkers is actually Edward Tufte. He has a great book called The Visual Display of Quantitative Information. So one of the key concepts that he talks about is chart junk. So he just can't stand chart junk, and these are just examples of it. Here's a chart, but there's no y-axis, and we don't know what the x-axis meanseither and why is that a green background? For this map, why there are these strange gradients and what do they mean? And then, again, one of the major misconceptions that people starting out have around visual design is visual design is not actually about necessarily expressing yourself per se. The key thing is, what information are you're trying to get across? So one of the key principles that you can actually apply is just look at any design that you're doing and just try to figure out if it can be removed without taking away any meaning, so that includes text, that includes lines, borderers, really anything.
I mean, even colons. A pet peeve of mine is like seeing colons all over a form on the web or in a mobile app.
If you removed it, would you even notice it? In fact, it looks cleaner. So this is a stupid example, but an incredibly basic one that you can apply over and over again throughout anything that you do. Ornaments at the end of the day are not signal. Really like, and this is a very opinionated version of design, of course, but it's just worked for me, it's that we wanna eliminate this type of ornament because we wanna focus on that which is useful. So how do we actually do that? So I have actually just three very simple principles that you can use in visual design. The first and most important is actually contrast, and so I'll just walk you through a very simple example. The most basic type of contrast you can give is bold versus not bold, more important less important, incredibly simple. Bold is not the only way you can actually denote what is important versus not. You can use color, and so that's an incredibly valuable tool. You can also use size. So immediately you can kind of see, as a visual designer, I am being opinionated about what you should pay attention to, when, and what is important and what is less important. So what's funny is if we unwind those things, all of these suddenly become basically the same level. If everything is bold, nothing is bold, and so that's something that you should definitely remember as you go about your business and try to design anything. All of your choices around color, around weight, it really is a question of contrast and so it goes both to the less important, but also the more important.
If you want, you can use color and weight and size to also make something even more important. The final really cool trick that I like to use is, you can kind of, we call it the squint test. So if you look at any webpage, any effective mobile app, immediately, if you just squint your eyes a bit, if you can't make out the details of what's on that page, but you can just make out the basic shapes of, without having the ability to read any of this, you kind of know, "Oh, there's something，" your eye's immediately drawn to the thing that is the highest contrast, the highest weight on the page. This is a very basic, basically your hammer for visual design is contrast. Related to that is closeness. So you as the designer can take related flows, related ideas and put them together to make them actually related and that serves your purpose as a designer. So I can't tell you how often, this is just a personal pet peeve of mine, and you have this login page, and then what is going on there? Why is the login page like, it's very confusing 'cause the user will come here and say, "Why is the login there? "Is it like a part of creating an account? "It doesn't look like it's a part of that other thing." That to me feels so much better. So it's a very simple principle, but one to be very very mindful of. But if you put just those two very simple concepts together, you get visual hierarchy, and this is where a grid really comes into play. This is why Bootstrap from Twitter was this incredible tool that just suddenly put in the hands of everyone here the basic building blocks of being able to create great visual design, do-it-yourself style.
如果你想，你可以使用颜色和字重和大小去让一些东西变得更重要。我喜欢使用的最后一个很酷的技巧是，你可以把它叫做斜视测试。所以，如果你看任何一个网页，任何一个有效的移动应用程序，立即，如果你只是眯着眼睛看一会，如果你看不出页面上的细节，但是你却能分辨出页面的基本形状，而不具备阅读这些东西的能力，你就会知道，“哦，有一些东西”，你的眼睛马上就会被这个东西吸引到最大的对比，页面上最重的东西上。这是一个非常基本的，基本上你的锤为视觉设计的对比。与此相关的是亲密。因此，作为设计师，你可以获取相关的流程，相关的想法，并将它们组合在一起，使它们真正相关，这符合你作为设计师的目的。所以我不能告诉你多少次，这只是我的一个个人宠物，你有这个登录页面，然后发生了什么? 为什么登录页面就像，它是非常令人困惑的，因为用户会来这里说，“为什么登录在那里?”它是创建一个帐户的一部分吗? “这看起来不像是另一件事的一部分。” 对我来说感觉好多了。所以这是一个非常简单的原则，但是要非常注意。但是，如果将这两个非常简单的概念放在一起，就会得到可视化的层次结构，这就是网格真正发挥作用的地方。这就是为什么推特的引导程序是一个令人难以置信的工具，它突然把这里的每个人的基本构建块，能够创造伟大的视觉设计，做自己的风格。
In a nutshell, sort of not to break it down to the CSS level, but you could literally just create dibs that were of any size that would automatically flow into a flexible grid, and that's incredibly valuable. So this is just literally the boilerplate stuff off of the old version of Bootstrap, but it's a good example of using a grid. So why this is important? Well we can overlay this grid and we can actually see that we're immediately, and so you can see how the headings actually just line up to particular sections of this visual design.
It's important because users when they're using your site, they're coming to your site and trying to figure out: why am I here, what am I trying to do, and they will immediately be drawn to the highest contrast things. Remember the squint test? You'll immediately go to head, like headings exist exactly for this reason. A user will go to a webpage or an app and they will actually just scan the page and they'll look for the highest contrast things and try to figure out, is this what I want? Is this what I'm looking for? I have a goal.
这很重要，因为用户在使用您的网站时，他们会来到您的网站，并试图弄清楚:为什么我在这里，我试图做什么，他们将立即被吸引到最大的对比事物。还记得斜视试验吗? 你会立即去头部，就像标题存在正是因为这个原因。一个用户会去一个网页或一个应用程序，他们实际上只是扫描网页，他们会寻找最大的对比的东西，并试图弄清楚，这是我想要的吗? 这就是我要找的吗? 我有个目标。
Is this going to get me what I want? And then if so, then they'll actually direct their, if I do care about that part, then immediately I'm going to dive deeper into exactly that part, and so visual hierarchy is your best tool for giving your users basically the guidepost, like this is the way to go. Now we got visual hierarchy, but what do I do with all of these lines and why are there so many, how do I use color? It can be very confusing, and this is a common mistake for people who do DIYs. They just put boxes all over everything or they use lines and things like that. Here's my super extreme oversimplification on how to doyour own layout. Basically, figure out what you need to put on the page, and then, first, try to use padding and margin to the extent that you can. You can use a grid. You can put related things close to each other.
这能得到我想要的东西吗? 如果是这样的话，那么他们实际上会指导他们的，如果我真的关心那个部分，那么我马上就会深入研究那个部分，所以视觉层次结构是给用户提供路标的最好工具，就像这样。现在我们有了视觉层次结构，但是我如何处理所有这些行，为什么有这么多，我如何使用Color? 这可能是非常令人困惑的，这是一个常见的错误的人谁做DIY。他们只是把盒子放在所有的东西上，或者用线之类的东西。这里是我的超级极端过度简化如何做自己的布局。基本上，找出你需要在页面上写些什么，然后，首先，尽量使用填充和边距。你可以使用网格。你可以把相关的东西放在一起。
And then, next, use a line if you have to. So 90% of the time, you can probably get away with just using a proper grid with enough spacing, putting related things together with good headings, thinking through the contrast, but, finally, a box is actually a very important thing.
It draws a lot of attention so that's why you'll see it so commonly on websites around a call to action.
It really is a high-contrast thing, but be very very careful when you use it because otherwise you kind of end up with this sauce of a ton of boxes and I have no idea what's important and what I should be doing. Whereas if you use a grid, if you use this sort of visual hierarchy, it is very straightforward. The other thing that's very valuable is you don't have to fill every single design margin-to-margin. White space can be incredibly useful, sometimes even helping direct a user, helping to explain what's going on. Having space on the side just gives you a place to put that or to just focus the user's attention. So those are incredibly basic, but a lot of these minimal techniques are really from the folks who created Helvetica from Swiss Design in the mid 20th century and so these are incredibly simple things, but the use of contrast, the use of a grid, and the use of color can actually do a lot. So I said that we're almost done with the tactical part, but I lied becausethere is actually a part that I did not cover yet. Most people think about design as the creation part, but it's definitely not the only part, and here's the reason why.
If you've ever put yourself, some of you took an airplane and walked through SFO airport and maybe that was the first time you've ever been. Every airport, itself is designed and one of the issues with a badly designed airport or a badly designed user experience is that we don't know where to go, we don't know where we are, and the signs are placed in the wrong place and actually it's actually incredibly hard.
If you put yourself in the shoes of the airport designer or the architect who created this airport, and more specifically the person who designed where the signs go, you have the design, you know where everything is, you're sitting there in your design tool and you know where everything, like it's all loaded in your head, but how are you going to know, for someone who's never been in that airport, what am I looking at at every given point in that airport? What am I trying to do? What are my goals? Lack of proper signage is one of the, I get loss in airports all the time.
I got lost in Paris accidentally, like this weekendactually. So this is actually what feedback is designed to solve and so there's actually two types that both designers and founders should be really really aware of. One is usability testing. So actually that moment between the wireframe, and you can kind of even do this in parallel. Once you have the wireframe, you can actually start doing usability testing with the wireframe. You can print it out and actually sit down with people who've never seen it before and just sort of walk them through it or, even better, say, just ask open-ended questions: what are we looking at? You can prompt them a little bit with like, "Oh well, you're here to do," blah-blah-blah, and it's like, "What are you reading? "What are you gonna click next? "Why am I here?" Before you even write a line of code, you can do a lot to test out whether or not this thing is going to work and it's way cheaper to do that than actually have to fix it in a bug and code later. Then the other part that is way way underappreciated but is extremely important for great product is actually customer support. Most people treat their support line as basically like kind of a shredder. They just don't even look at it. They don't reply do it, but the reality of product is that most, and this is an extremely extremely common problem for people building things for other people, is that we always assume that the product that we're creating, well, it's just the visible part.
It's the 80% case.
It's the ideal case in your wireframe, in the requirement document, but the best requirement documents, the best wireframes, the best designs, the best ship thing actually solved all of these other use cases that a PM might sit there and say, "Oh, well, once in a blue moon, this happens," but there actually 10,000 things like that that once in a blue moon happen and if you add them all up, well, you have a broken product. So that's one of the most fundamental reasons why we're so dissatisfied with the products that we use day-to-day.
It's that some PM or some designer looked at that and said, "Oh, when is that ever going to happen?" So the devil truly is in these long tail bugs. As a founder, the best part is, I mean these big companies, they don't think about this at all. They literally make it impossible for designers and engineers and the product team to actually have anything to do with customer support. They just think of their users as cattle. So the greatest advantage that you have in this room is that you're a human being, you built it yourself, and when someone comes to you and says, "Oh my God, I'm stuck here. "What happened?" you don't have to just throw that email in the garbage. You can say, "Oh my god, that's a bug. "Oh, I'm gonna fix it," and then once you do that, you have an evangelist for life because we live in a world with products that are incredibly impersonal. We're alone in this incredible place that like we are so frustrated when our products don't work and nobody listens. So if you're the creator of that product and you listen, well you only need a couple hundred people like that and you're well on your way to something that could be incredibly powerful. To steal a quote from Paul boo-khahy, "Don't try and go and make something "that a thousand people kind of like. "You really need to go and create something "that a hundred people absolutely love," and customer support is the way you can do that, and the designer, the person who actually puts together the wireframes, who thinks through the user, they're the best on the whole team to actually think through that so they're awesome at advocating for the user. This process is incredibly complicated, but I just want you to make sure that you know these are the parts of how I think about a great product.
It's not just user research.
It's all of these things, one after the other, and usability testing and customer support are the key pieces of this and so you're never done with just one sprint. You're basically in a perpetual cycle of doing this over and over again and you really do need to, you don't need people doing every single piece of this, but you do need to spend a little bit of time thinking about each piece of this.
Garry Tan: Now's the super practical section of how to find and choose designers. We can get through this really quickly. I'm happy to answer questions afterwards about it. But the basic question we always get asked is: Well, when and how? The reality of it is, there's so many ways to answer this. But this is just super boilerplate advice. It's that pre-seed, seed, and probably pre A, you still need a co-founder probably to do it.
And then you could probably get by with a little bit of consulting. By series A, you should probably, unless you truly have nothing that has a user facing element, which is rare. I mean, even developer APIs today, I would argue that you need a developer API designer who sort of runs through this whole process, but just for a developer experience.
That's incredibly valuable.
That's make or break for even highly technical products.
That's when you should really start thinking about your first hire.
And then by series B, what you really should think about is: How do you hire a team? A lot of people reach series B, and they're actually still at the first hire stage.
And the difficult part is if you actually have 10, 15 engineers and you're trying to hire that first designer, and you don't have ... You're not going to hire a team, that's actually a little bit of a nightmare for a designer to work at, which makes sense actually, to be the only person on the whole team in charge of design, and you versus 20 engineers is a very scary thing for a designer. This might be a little outdated, but this is sort of what I've always used in the past. They're just websites online to sort of find designers. Dribbles is incredible portfolio. You can get a lot of LinkedIn. Look for companies in your space that have done design very, very well.
And you can just very point blank start reaching out to them. Behance, Crop, all of these are websites that you should just go check out. AIGA even has a little database of member designers on there. When I'm thinking about hiring people directly for a full-time role or even for contract, there are a bunch of schools that have worked well for me, CMU, HCI, NYU, MIT, [inaudible] , Parsons, Stanford. This is really not a comprehensive list.
And frankly, there are so many incredibly good designers who have never been to a design school. In terms of finding consultants, there's really two paths here. One is to go ahead and find an individual, so it turns out that there are a lot of people who you can kind of use this as a way to recruit them. Some of the best folks, they actually really like to work on a lot of different projects all of the time. There's actually a very large pool of individuals who are basically individual consultants.And they're hard to get, and you might have to email a lot of them. But you can reach out. You can hire them as consultants. If there's a really good fit, that could be a way to get to know them to come on board. A really cool trick that I've heard for people who just need low cost logo design, visual design, there's actually an incredible number of people out there in the world who are not first world designers.
And they're totally available on 99 Designs, Fiverr. There are probably a bunch of other places like that. The trick that I've heard that you could use is you can actually take your job, put it on one of these job boards, and then don't just do it for one. Don't just hire one job. You could hire 20 jobs. And then look at the output of those 20 different people.And then personally befriend the person who does some of the best work.
And you'll find people all around the world, Philippines, Thailand, Eastern Europe, everywhere really, Africa, Asia, Europe, even the United States, people who are incredibly talented, who actually ... They're just starting out in their careers, or they don't know how to actually get great jobs.
And you can be that way to they learn about startups. Design firms, there are just so many. The difficulty with design firms is you kind of have to find one that is willing to work with startups.
And many of them, the bread and butter for the best design firms truly is working with Fortune 500 companies for outrageous sums of money, so it can be very difficult to find ones that will work with startups. Viget Labs is the one out of DC that I used the most. But there are giant directories.
And frankly, referrals are sort of your best bet.
And then I want to call out a company that just graduated from YC a few weeks ago called Plato Design. Their URL is useplato.com. You should definitely reach out to them. I think that they do a very, very amazing job. How do you actually attract a designer to work at a startup? The ideal at series A, or even where you're at right now, is if you are truly a consumer focused company, you kind of need a co-founder on there who can actually run this for you. But later on, especially, if you're a three or four person team, you can usually find one ideally unicorn to come join and give them a much more senior role.
That'll be fairly important at series A. But once you do have a larger team of five to 10 engineers, it gets really scary for a designer who's used to working with teams, working for design firm, or working at Facebook or one of the large tech companies. They're used to sitting with other people who spend all of their time thinking about all of the things that we were just talking about with wire frames and users and personas.
And so it can be incredibly scary for those designers to come and work for you much later stage if you don't plan to hire a team that is diversified. It just gives them a really good day to day.
And then at the end of the day, being able to be very crisp about what those roles are, that's the other part of hiring a team that's incredibly important. It's going to be very, very hard to find a unicorn. But often, you can break it down by the exact things that I mentioned, like they're incredibly good PMs, who have great resumes, who have great backgrounds.
That's one coherent role. Interaction designers, sometimes they can't make things that are pretty, but they are incredibly empathetic. They're able to think through. They're great writers. They're incredible communicators.
And that's what you would look for in that role.
And finally, visual design.
That's probably the part that often stands on its own. It doesn't have to.
And so it's just a different skillset. And then really quickly, it's actually very effective for startups who want to hire design teams to actually write about it. Content marketing works extremely well. Social media works incredibly well. If you're all engineers, but you're already thinking about this and talking through a lot of the terms that I was talking about, well, that's a culture fit for designers because that's basically what they want. They want executives or workplaces, or founders who understand and speak their language.
And so that's why I encourage you guys to be very open with do it yourself, to understand these things because even if you don't do it, down the road you're actually far better at evaluating, managing, and working closely with people who do and who are very good at it. How do you actually interview these designers? Well, this is typically what I recommend. Do a quick phone screen. At the end of the day, no matter how beautiful a portfolio is, it's just so hard to work with people who have sort of their own vision that cannot communicate.
And so the phone screen is really all about great communication skills. I think that's incredibly essential.
And then when they actually come and meet you and the team, actually have them walk through the hard decisions, the trade offs. We spent a lot of time about product design. You want to see exactly that kind of thought about personas, about prioritization. What are the difficult trade offs? Because there always are in every type of product you could design.
And finally, I recommend whichever founder has been doing the design or the product, you've already been solving problems that you might have. The key thing there is, if you've already spent your 100 to 1000 hours thinking about a given problem, it's the best for you to actually spend time walking through a candidate over and over again just to make sure that you think through these things the same way that they do. You can read this later, but it's pretty straightforward. Think about design. You don't want people who are complainers.
That actually is pretty common. You want someone who's empathetic and listens to your needs. It's usually bad for someone to talk about themselves a lot.
And so going back to the empathy point, that's incredibly important. The funniest thing that I like to use is when I ask them a design question, if they just go to the white board and just start drawing, they fail because, wait. Why didn't you ask about the users? Who's it for? What's the problem? And so these are just guidelines. There are so many ways to interview. If you don't have a really good design leader on your team, I highly recommend that you go to a friend or someone who you do respect, who can do this stuff, to just be sort of a final check before you do hire someone. These are a bunch of books that I sort of refer to throughout the talk. This is just a starting point. This is far from comprehensive. But if you bought every single one of these books and read it front to back, you would be a pretty good designer maybe. Here are a bunch of links that you should probably read afterwards too. Taste for Makers is one of these PG essays that I think not a lot of people talk about. But it's incredibly timeless, so I highly recommend that.
所以回到移情点，这是非常重要的。我最喜欢用的是当我问他们一个设计问题时，如果他们只是去白板和刚开始画，他们失败了，因为，等待。你为什么不问问用户呢? 这是给谁的? 有什么问题? 所以这些只是指导方针。面试的方法太多了。如果你的团队中没有一个真正优秀的设计领导者，我强烈建议你去找一个你尊敬的朋友，或者一个可以做这些事情的人，在你雇用别人之前做一个最后的检查。这些是我在整个谈话中提到的一大堆书。这只是一个起点。这一点并不全面。但是，如果你买了这些书中的每一本，并把它前后读一读，你可能会是一个相当好的设计师。这里有一堆链接，你可能也应该在以后阅读。“对制造者的品味”是这些PG文章中的一篇，我认为不是很多人都在谈论的。但这是难以置信的永恒，所以我强烈建议。
And then these are links that are very specific about: How do you write a PRD? What's your first wire frame? And then these other websites, we just really, really like because there's so much there. This field is incredibly deep. Thank you so much for spending and making it all the way to the end of this talk. It's an hour and a half, 90 minutes. We made it through a 104 slides, so thank you for sitting with me. I will leave you with just one final thought.
然后这些链接是非常具体的:你如何写一个珠三角? 你的第一个线框是什么? 然后这些其他的网站，我们只是真的，真的喜欢，因为那里有太多了。这个领域的深度令人难以置信。非常感谢您的花费，并使之成为本次演讲的最后一个环节。一个半小时，90分钟。我们通过了104个幻灯片，所以谢谢你和我坐在一起。我只留给你最后一个想法。
And it's truly that what we're talking about with the startup, design is only one leg of this three legged stool.
And your startup success truly lies at the intersection of all of these things. Thank you so much. Thank you for spending time with me. I know that was a lot.
Speaker 2: How important is it for early stage companies to incorporate an about us or our story section of the early concept points?
Garry Tan: The question is: How important is an about us page? This isn't necessarily a design thing. I actually really think it's important. Going back to our moment where we were talking about how alone we are in this sort of product barren, product landscape. You just feel so alone.
And the about us page is the one place where you as founders can tell your story. Everyone is spending so much time trying to be incredibly ... They're trying to imitate Microsoft. They're trying to be Google. Right? You should embrace how powerful it is that you're trying to do this thing.
And being a real human being, answering emails, and putting your name on the website. I mean, I would argue that's why, one of the big reasons why Coin Base was so successful. Brian Armstrong very early on, he was probably the only person in the whole bitcoin world who was willing to put their name, address, I mean just basic things to make it an incredibly real thing. I think about us is very important for your relationship with your customers.
And that's not a design thing. Yes.
Speaker 3: Two. Later on in the talk you were talking about understanding your users.
And early you mentioned transport, global transport, which had I think advertised transport decades before the [inaudible] .
And engine efficiency is 50%, while your car was only at 30%. How do you ask questions that really let you accurately see your user? A lot of times you might be doing a user interview, and you feel like they're not really giving you the whole story.
Garry Tan: Yeah. I guess the question is: How do you properly ask questions to sort of get the story of your user? You know, the hard part here is there's not really one way to do it. I think it really does come back to being a good interviewer and thinking through. Asking open ended questions is actually a really good way to do it. It's just, tell me about your day.
And you can even seize on emotion because the best problems to solve are actually incredibly emotional ones. It's like, I get frustrated when, blah. Or I get mad when, blah. Those are a lot of very, very strong ... Going back to, I think Jeff might've taught me this, actually, just purely that you really want to look for things that are hair on fire problems, things that actually get people upset. Emotion can be an incredibly powerful and good thing, so open ended questions and look for emotion. Yes.
Speaker 4: Hi. My name is Lawrence from Intersect. You talked a bit about prototyping.
And maybe bonus question, if you know the problem, or have the problem and solution [inaudible] . And you have to get an [inaudible] . How would you go about finding a solution?
Garry Tan: Yeah. First question is about prototyping.
Speaker 4: If you had something important about that, [inaudible] .
Garry Tan: I have a confession to make. I have not done a lot of prototyping simply because I'm always in such a rush to get the code done that the second I know what I want to build, I just build it.
And then I ship it, and then I'll just do it live.
And so I haven't personally gotten a lot of use out of prototyping. But I know that it's an incredibly valuable tool. And that's just a weird one for me because I'm just always ... I would rather just ship the thing and have it be out there.
And then sorry, the second question.
Speaker 4: Get to know the problem of the user. You haven't found a solution to get an accurate reading.
Garry Tan: Yeah.
Speaker 4: How would you go about it?
Garry Tan: The question is: If you know a problem, but you haven't found the solution. The hard part there is it's not totally clear to me that design can solve it. What you described maybe is either a business problem or a technology problem. It sometimes is a design problem if there's ... I don't know. The hard part is these things are so squishy. Right? If it's a business problem, then you don't have distribution. People don't know they have the problem. You can't get in front of them. Or if it's a technology problem, then yeah. How do we actually build the thing? And if we're not capable of doing it, then design can't solve it. Right?
问题是:如果你知道一个问题，但你还没有找到解决办法。最困难的是，我不完全清楚设计是否能解决这个问题。您所描述的可能是一个业务问题，也可能是一个技术问题。如果有。。。我不知道这是个设计问题。最困难的是这些东西太软了。对吧? 如果这是一个商业问题，那么你没有分销权。人们不知道他们有这个问题。你不能站在他们面前。或者是技术问题，那么是的。我们实际上是如何建造这东西的? 如果我们不能做到这一点，那么设计就不能解决它。对吧?
Speaker 4: [inaudible] solve that problem.
Garry Tan: Yes. How about you just keep building things until you get it right. Do what Jeff said. Over here. Yes, please.
Speaker 5: Yeah. You talked about Coin Base. Were you thinking of keeping that distance between you and your users or you and the [inaudible] appropriate. [inaudible]
Garry Tan: The question is: Are there places where you should maintain your distance? I can't think of any at the moment. There probably are. There was a really big advantage for them to be out in the open. I could imagine being, if it's A, incredibly competitive.
And if you want to be secretive, there are cases where you don't want to be that open.
And that does happen, especially for something that's easily copied or something that is incredibly enterprise focused, so it's not important for a lot of people to know about it. Those are the main scenarios where I think secrecy turns out to be very important. But most people tend to err on the side of more secrecy than less. The standard YC-ism around this that I very much believe is whenever you're creating something new, you're not competing against all of the other people out there. You're only competing against obscurity. You're competing against the back button. To the extend that, that's true, being as open as possible, getting as many people to know about you as possible, and being a human being and having that interplay, that's really good.
Speaker 5: You don't think controversy ... If you think controversy's a reason to do that.
Garry Tan: Question is controversy. It depends on the type of controversy. One of the funniest examples of me giving very bad advice and me being very relieved that the founder did not take that advice, was a company called Soylent, so they came in through YC. They were working on something totally different in networking equipment.
And I sat down with them in this room for office hours.
And they said, "Great news. We have this incredible ... We have all of these orders. People love this thing. Oh, by the way, we're going to stick with the name Soylent." And I said, "Please, please, don't call it that. Do you know what that means? Haven't you seen the movie?" And it turns out that the entire reason why they were able to get probably $1 billion worth of earned free advertising, the reason why they have an incredibly powerful business today is purely because they found exactly the right kind of controversy. 90% of people who love food hear about it and say, "This is terrible. I hate it." In fact, they hate it so much that they're at dinner and they're telling everyone they know about it.
And then 10% of people hear about it and they're like, "Oh my God. I need that now." There are cases where controversy can be incredibly powerful.
Speaker 6: Let's stop it there. I'm sorry.
Garry Tan: Thank you, guys.