Design for Startups by Garry Tan (Part 1)

Welcome to week four of my accommodator startup school! This is going to 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 going to talk about product design and how to make that an advantage as you're building something people want.

Then, following Gary, we have Cat Man, 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 want to just mention a few rapid administrative matters. 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 startupschool@ycombinator.com. It's okay, don't panic.

Secondly, we have, as many of you know, just done a merge 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 as soon as you can. Again, that's startupschool@ycombinator.com—that's the easiest way to do that. If, for some reason, you think you're in the wrong group and 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. That sounds, if that sounds like a broken record, it should. And with that, let's get going! I am hugely pleased to introduce Gary Tan.

Thanks! Thank you guys for coming all the way out and spending time with me to hear about design. Well, you know, frankly, design can be incredibly complicated and there's a lot to it. But, you know, in hopefully an hour, possibly a little bit longer, we're gonna get through about a hundred slides. So, I tried to cram down basically everything that I knew that founders would get wrong or, you know, run into problems with all the time.

And 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, you know, personally, I am actually self-taught. And so, you know, the first thing that I really wanted to start off with is actually, I mean, it's almost cliché to associate Steve Jobs with design, but I think that this is 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 start-up; 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. Steve says, "Once you learn that, you'll never be the same again."

So, the thing I really want to 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. And so what we're gonna explore today is, you know, 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.

If even if you have no design background whatsoever, if you're a human being, if you're smart, if you can put yourselves in the shoes of other people, well, you too can do it yourself. And in fact, as founders, you probably need to. And then finally, we're going to walk through, well, you know, when should you hire and how should you do it? You know, when should you use a consulting firm? Things like that—practical matters.

So, I spent my 10,000 hours. You know, actually, I was trained as an engineer, so I've never been to school for being a designer, but I taught myself. You know, whether it's books, learned 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, you know, 10 batches working with companies, initially actually just as designer in residence. So, I sat here in this room doing office hours with more than a thousand 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, a product process?

And 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, you know, sort of put together the iconography of something that is very significant. And so, you know, when I joined Palantir, it was just ten people, and we got to design this logo.

One of my favorite things about it is this mix of both meaning and aesthetics. And so, on the face of it, you know, one of the things I really wanted to do was sort of really underscore what Palantir was about. And so, you know, at one level, this wordmark, 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 enemy's 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. And so, one of the major themes of Palantir broadly is that, you know, 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.

And so what a computer is, is basically the infinite book. And so that was just one example of where I've seen, you know, design actually will help put together a culture for a company. And it's fun; it's just fun to be able to translate, you know, all of these different pieces of a company and why we're here, what it's about into something that can, you know, go on a t-shirt or on a hat.

And I had actually—and so really, really big disclaimer—I'm an engineer by training. I never went to school; I, you know, never went to school formally for this stuff. Totally self-taught. You know, I was a founder, so I applied this just like you. I did it myself, and now I’m a VC basically by accident.

And so the things that I'm talking about today will be a hyper simplification. You know, if we wanted to, we could turn this into easily a ten-week course just about each given section. But instead, what I want this to be is a roadmap. So you might hear these terms. You know, there will be times in your startup, like perhaps now, perhaps tomorrow, that you'll want to actually start applying these things. You know, Google’s your friend; everything in the world that you need to know is out there.

And so, you know, the computer is truly the bicycle for the mind. And so the other thing that I really want to underscore is, you know, we talk about design as the singular thing on its own, but it truly is deeply integrated in this broader picture of, you know, 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, you know, it takes great product management, you know, in addition to that great design and engineering and customer support. It's all of these things, and especially at your stage, you know, don't box yourself in. You know you have to know that you are the shepherd of your product, and you're going to 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. Those are two sometimes disparate things that will, as we'll see, you know, some of the most inspiring companies to me in the world, you know, they have design as a very core piece of what they do.

And so, you know, you 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 we, you know, that are coming up, we're gonna talk a lot about that process on how it works, you know, what should it do, and, you know, what are the problems.

I like to think about, like, and you know, I just got my first Leica camera, and I kind of can't believe I waited this long. I love to finally get one. But, you know, 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 fun, functional. It's also about the deeply the functionality. What, you know, why is this thing better than all the other things that existed before it?

So, you know, a review from 1929 actually just straight-up told you that, you know, a Leica at that time was basically magical. It was, you know, eight times lighter and, you know, ten 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 he really showed us in his designs is that good design is actually as little design as possible, so minimalism. And so that's, you know, a point that will return to several times in this presentation. But, you know, the key thing here is how do you create things that are not burdened with non-essentials? You know, it really is about purity, about simplicity.

And, you know, just to drive at home, I mean, this is a guiding sort of force in everything that, you know, we see in the marketplace today. It's, you know, history doesn't repeat; it rhymes. And, you know, another theme that we'll get back to in this talk is actually simply the fact that there's very little and 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.

And so what do I mean by that? Earlier, we talked about form versus function in the form of delight and works well. These were sort of the two yin and yang, the opposing forces when you're trying to put together a design. You know, we obviously always want something to be beautiful, we want something to make you feel good, make the user feel good.

But at the same time, you know, delight is also a part of novelty. It's that, "Hey, this is new. I've never seen this before. This is interesting." You know, I want to see more of this, like, let me turn the page, let me click next. But at the same time, function is the thing that you—that's the steak. That's, you know, if delight is the sizzle and works well as the steak, that's why we're here; we're trying to get something done.

And so, you know, part of the problem with, you know, form over function—and this actually happens even in the best products—I mean, I'd like to call out Apple for it. I mean, that is, you know, 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 differentiate it from, you know, all of these other smartphones out there.

But in terms of function, when I'm watching a video, this is categorically worse. Like why am I, you know, 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. Like, I, you know, this is again an example of form. This idea, you know, well, we want to 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? And so, and this happens all the time. I mean, you know, 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. And so this is, you know, one of the more absurd situations of like someone actually had a right pull on this thing because too many people just 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, you know, when you put form over function, if you put the wrong door or, you know, it's too elegant, and it's not clear how you use it, well, that's, you know, missing the point.

And so if you take a moment and try to think through like why is it that we see, you know, over function so much in, you know, the things we use, the products we use, just walking around in our daily lives, you know, why does this happen? You know, clearly, this should not happen. And so that form should follow function.

And deep down, I really want to emphasize 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. You know, one of the things that I admired the most about my time both working at YC but also as a founder going through Y Combinator back in 2008, it was that sitting down with Paul Graham, he would give us such incredible advice about specifically how what are your users thinking? You know, what are they feeling? What—why are they here?

And really being able to peel away the layers of like, you know, I know we're sitting in a room looking at this particular UI, but, you know, 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, you know, and you know, one of the things that I put actually in, you know, my recommendations for design resources, and on its face it's kind of absurd, this is this 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, you know, one must actually become genuinely interested in other people. You actually have to see their point of view. You don't want to be able to be sympathetic; like understand what are their ideas, what do they understand, and you know, what do they actually want.

And you know, this goes back to YC itself. The first day you get into YC, you get a t-shirt that says, you know, "Make something people want." And I think—I don’t know if they still do this, but do they still give you 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.

Oh, so one of the things that's really interesting about building highly technological products is that we often think about them as incredibly complicated, you know, machinery. But the most useful mental model for me in what I've been doing is actually that, you know, to not think of it as, you know, building a car or even building a website or, you know, writing software or anything like that. It's actually about throwing the best possible party you possibly can.

And so if you think about great parties you've been to, there's no line. You're ushered right in. A human being—some, ideally someone you know—someone who's very friendly comes to you and says, "Hey, welcome! I am so glad you're here! Here are your friends! Oh, let me take your coat; beers are over here!" And so, you know, that sort of politeness, that inviting welcomed nature, that thoughtfulness—that's something that you really have to keep in mind as you do, you know, your work as not just a designer but as a founder.

And the key piece here is actually knowing what problem you're actually solving—just being very crystal clear. And, you know, this is sort of—if I'm, you know, starting to sound like a, you know, 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 in, you know, that we need to solve. And this is sort of the core tenet of design thinking as well.

And so part of the problem with not knowing what your problem is, and in going back to lack of empathy and going back to, you know, 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. So if you, you know, to basically each of these do sort of talk about a particular price—you know 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, you know, each one of these inventions were created mainly to serve the central problem of the inventor, the inventor wanting something to solve. And so, you know, this is the opposite again—like, you know, just to give more examples. This is the opposite of empathy. This is something—this is you putting novelty, putting, you know, one's own interests ahead of your users, of society, of, you know, the people around you.

And so, at the end of the day, if there's no problem, then there's no solution. It ends up being designed for its own sake. And, you know, design for its own sake isn't design; it's art. You know, and there's nothing wrong with art; I love art. But, you know, that's not what we're here for, actually. It's, you know, founders creating things that people don't actually need or, you know, engineers do this too. We, you know, make stuff that we think we need, and then actually it's not something, you know, 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. You know, it's no mistake that some of the most obvious examples of companies that are design-driven, there are actually hardware companies. There are as many kinds of design as, you know, types of things that humans need. It's no mistake by that, you know, architecture is absolutely a form of design. Branding and identity. You know, communication design—being able to communicate something using data and iconography, or maps or charts, furniture design. You know, a piece of furniture easily has all of the mechanisms as anything else that a human being might use.

A landscape design—how does someone go into a place? How do they use it? Where, you know, where do they know where to go? You know, packaging—so how does this make me feel when this arrives at my doorstep? If this is a gift, you know, why is there a gift box anyway? And, you know, what is the form and function of each piece—each piece of this physical object? Or, you know, transportation design—like a car is one of the most evocative things. It’s you're almost entirely pure emotion.

But for the people in this room, you know, 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. And 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, you know, how do we actually do that right? How do I actually, you know, create wireframes, create the flows, create the sort of intermediate step between that and the, you know, pixel-perfect, ready-to-go, ready-to-implement thing? And the visual design actually really is about that last mile. And, you know, part of the reason why we divide this up this way, you know, 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's incredible. All right? But that's obviously a unicorn. Like, you know, 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 if, you know, certainly quite a few watching online. So, you know, shout out to the unicorns in the room!

And 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 is good at a few of them, you're really, really blessed. And, you know, 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. You know, in each of these, it really is a little bit of a waterfall. Sometimes you really can't start interaction design without actually capturing requirements. And then, finally, of course, engineering. You know, ideally, you're kind of in conversation all the way through, but, you know, engineering and actually implementation—often that is something that happens afterwards.

So let's dig in a little bit to product design. And so, what's funny is I'm cheating a little bit here, so I am actually mashing product management into this. But to me, I actually just can't do product without—I can't do the design process without doing this part. And 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?

And so, you know, 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, you know, every single one of these things has a fairly specific deliverable. And so, in this case, you know, the deliverable here is a PRD—a product requirement document, or, you know, you can also call it a spec.

And so the interesting thing is there's not really one way to do product design just as this—you could call this product management. Some Microsoft calls it program management, and then some organizations, you know, sort of de-emphasize some of this stuff, and they just call it project management. But the project manager still actually has to think through all of these things.

So, you know, the labels matter less; the fact that you do them matters a lot more. And so this is actually the actual content of my YC application from, you know, basically January of 2008— or I think it was February. And so everything that, you know, you really do sort of have to start with a problem statement. It's, uh, you know, what we were trying to solve is this ability to post online.

We looked at online services at the time. You know, blog platforms have been out for a while, but they're, you know, 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, and we thought this is a novel, different way to actually do it.

And so one of the most valuable things that you can do once you have that the statement is actually to think through who are these very, very specific people who have this problem. And so, I'm gonna use Posterous as an example to walk you through personas, and 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; you know, there's not really one way to do this either. But this is what we did. You know, we thought about our users really as three different types. David the Dad is sort of one of them, you know? We kind of want to identify them as human, as you know, specific human beings. Like, this is a very abridged version that you might do. You know, sometimes you fill them in on backstory like what school did they go to? Or, you know, what kind of family did they grow up in?

Or, you know, very specific things like, you know, what type of phone do they use? Or what type of computer do they use? Did you know back then it was did they use Internet Explorer or did they use Chrome? Did they use, you know—I'm not sure if Safari was even out yet—you know, what are they used for email? What type of technology? What level of comfort with technology do they have? And so that will actually help you a lot when you're making decisions about, well, what are you trying to do, and you know, what are the features that really matter.

Another persona we had was actually David's family, and so we, you know, captured this in the form of Grace the grandma. You know, and some of this is actually in tension 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. And part of the reason why this is incredibly important is thinking through different, you know, both modality and level of comfort with technologies—often some of the most important things.

Like, you know, you guys, some of you in this room are actively thinking about building things for totally late adopter industries. You know, some of the best YC companies in the past five years have been—they're being deployed to construction, to, you know, global freight. And so if you walk into any office in the world, you know, you're gonna find some tech-savvy people, but not a lot.

And so, you know, even for, you know, enterprise companies—for B2B companies in the room—these personas, it’s still a very valuable exercise because it makes it very clear. You know, you might have your decision-maker, you might have your executive, and then you might have your inline-level worker, and there are capabilities with, you know, their motivations, why they're here; they might be very different.

And finally, we also had, you know, this was the dawning of social media. It's 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, you know, she had very specific needs, and so we were trying to build something for her as well.

And so, one of the things you really do have to do as you think through a sprint, you know, whether it's the next two weeks or the next month—you know, the shorter the better, frankly—you know, 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 get them, try to bucket them into coherent features that make sense.

So, in our case, you know, one way to do it for us would be post by email with plain text; that's just one coherent thing, that's a capability— you know, 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 signup 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.

And what we—that was very intentional in that we wanted to cement a totally new novel behavior that nobody had ever done. So, you could just email post@posterous.com, and we take care of the rest. The interesting thing was that the capability itself was not novel; there were other people who were doing it, but it wasn't a central part of the flow.

And so, you know, once you’re capable—once you're able to do the basics of it, you know, there are other things that you want to be able to do: photo attachments, being able to take multiple attachments and turn them 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, you know, we launched at TechCrunch. Michael Arrington himself actually reviewed us, and he immediately—he knew that if he started using it, everyone else in the valley at the time definitely had his email address.

And so he almost immediately tried to get his technical friends to try and hack him, 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, you know, actually important for us.

And so, I want to 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, you know, end up trying to hire people for that role, this is sort of where it fits.

It's that, you know, then frankly if you're working on your startup, you should be, you know, just doing this as a matter of course. Like you should not be, you know, outsourcing this; this is just a basic piece of customer development— understanding your users, spending time with them, you know, being able to write down specific personas for these are the types of users we want to—we want to use our product and to be as basically crisp as possible around, you know, what their needs are.

You know, that we call that user research. And this actually, done right, it does actually happen before you even, you know, start thinking about what problems to solve at some level. So, you know, 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 want to 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. And so this is just a guideline; this has just worked for me in the past. There's not one way to do it, but, you know, 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. You know, P0 is pretty self-explanatory; just start on this. This is just the core thing. If we don’t do this, then, you know, what are we here for?

And so, you know, P1 is what you would consider, you know, the next obvious step. You just wouldn't ship without it, but maybe it’s not quite as core. And then, you know, if you think about this in the terms of say a two-week or three-week sprint, you know, you try and get all the P0 bugs, the P1 bugs, you know, then actually—sorry, I skipped ahead a little bit, in that, you know, 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, you know, you as a small team, you might not need it, but as you grow, your team can be one of the most fundamental ways that you can make sure that you're doing the right things as a product.

You know, especially as your team grows, having a bug database and assigning these priorities, and, you know, it doesn't have to be this, you as a team could you 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, you know, the wireframes or the visual comps that, you know, an engineer needs—that can be one way coherently you can run your whole product and engineering organization.

And so, you know, as we go down, one of the things that has always worked for me is actually, you know, 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 that, you know, there are just things that are totally unforeseen that break things.

And so part of the reason why this priority prioritization is very important is that it makes sure that you try to set up realistic goals. You know, 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, you know, two months, three months— and then you never—you know?

And so we'll talk about that in a little bit, but this is really why priority matters. And so, in this case, you know, it's pretty straightforward: post by email with plain text. Hey, that's a must-have. We're just gonna start that first. And then one of the things that you know— 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 you know, is that important? What's the interaction between them? You know, post by email without an account. Well, some of our less technical users are actually very scared by signing up for new products.

And so being able 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 attachments support. David and Irene as power users, they both— you know, it's 2008. They, you know, they had the newest, most beautiful iPhone, and so it's immediately the thing that they really, really wanted to do. And, you know, P2 as you go down, you can kind of break down what is important and what is less important.

So, you know, 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, you know. 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.

And so the other way to, you know, the reason why it's useful is that then you can think of your product across different sprints. So you might be doing a release this month, and then P3 file, video file support—at least you know if you’re a software engineer, knows that that's something that they want to do, well, when they’re factoring, when they’re actually writing those classes or writing, you know, 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.

And so, you know, one of the key difficulties of product is always trying to figure out, you know, what are we doing now and what are we doing later? And 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.

And so that's, you know, really, really product management 101. But if you do this, you will be far ahead of pretty much, you know, 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, where are the problems we're trying to solve, and then what are the respective priorities.

You know, and one of the classic reasons why, you know, we kind of talked about this already, but if you do the prioritization up front, then, yeah, product gets very easy because you can just cut off the bottom. Everyone sort of knows, well, you know, we're gonna start with P zeros first, then P ones, and then oh, if we're ahead, like, let’s do the P twos and the P threes. But if we're late—well, again, 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, you know, how much you do—that's the 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 product. You know how many bugs are there? Are there things in there that just don't work? And that, you know, that's sort of always an issue.

And finally, time. You can all, you know, do all the features you want, with the highest possible quality, but, you know, you might have to slip your date by two weeks, three weeks, four weeks. And, you know, if you don't cut scope, likewise, well, you might be able to hit your time, but you know, users are going to run into a thousand bugs, and you're not gonna like that.

And so if we work backwards from that, then this is precisely the process you use to sort of fight that. And so, you know, the other thing that is very common—there are the reason why prioritization is incredibly important is that, you know, without this, well, you basically can head off a lot of really strange product decisions at the pass.

And so if you ever get incredibly frustrated with, you know, you're deep in some settings panel in, you know, your iPhone or something, you know any sort of 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, eff it, we'll just ship it.

And so, you know, it's a real danger. Product quality and products, you know, really, really fail simply because prioritization and these basic requirements are not really figured out. And so finally, you know, and the classic thing that, you know, 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 unsavvy 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? And 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, and how do we actually translate that into something that you know, you can actually start working on?

And so the question is you ask, how will they actually do it? What are their goals, you know, and how do they achieve it? And so, at the end of the day, what you're trying to get to is either a prototype or a wireframe. And so what these things are are basically—you might use it a tool like OmniGraffle or, you know, there's quite a few prototyping wireframing tools that are out there.

And what you want to do is figure out just the text, just the call to actions, just the flow screens, the screen. You don't want to care; you don't want to care about color; you don't want to care about, you know, really how it looks, what font you use; you don't even really have to worry about layout too much—though it is, you know, I would start thinking about layout, you know, as a part of this process.

And so the most interesting important aspect of interaction design is actually that people treat—you know, this is kind of a very shocking thing to me. I did 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, you know, it turns out that if a computer is polite to you, you know, a person will be likewise polite back.

Or, you know, 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 anthropomorphic assists, without, you know, Clippy, without, you know, an avatar, without anything like that.

Truly, every interaction you have with computers, they're actually a conversation—it's a conversation that happens over and over again because it's written in pixels, it's written in design, it's written in code. And so what is this about at the end of the day? Like, you know, 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 phenomena that I can think of—it maybe explains Trump and a lot of other things—actually when you absorb media, whether it's reading or, you know, any type of media, period, you actually read that stuff in your own voice.

And so that actually becomes, you know, deeper. That, you know, kind of a part of you. And so as an interaction designer, an interaction designer's not merely the person who figures out where the buttons go or what the layout might be or what the flow is, it's also— 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 and, well, you know, so just to put a point on this, really command language is about, you know, people will do whatever you tell them to do, you just do really do have to tell them. And so you know, this is a super common thing. In fact, I'm pretty sure, you know, a lot of you are making this mistake in your homepage copy and your design and your first-time experience.

You know, it's passive voice, you’re, you know, you're not showing, you’re telling, and you're just describing something about what you're doing in sort of this, you know, sort of third-party disembodied voice. And 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.

You know, if you go to Microsoft's homepage and start clicking through the products, like the product names are like blah blah blah server edition admin, you know, 2009, whatever it is, like, this insane word salad. And if you read it, you have no idea what that product is and who it's 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 to be incredibly obvious. Like, you know, the previous, you know, why is that sigh? Why is this so small? Like, this happens all the time. Actually, people never are opinionated about what you want the next user to do.

And so, you know, this is an extreme example, obviously, but you know, what you want is—you know, contrast. You want to be incredibly direct. You want to use command language, and you want the call to action to be, you know, someone goes to that webpage and they just know—they go to that mobile app and they just know what they need to do.

So, you know, the other part of interaction design that is actually also very important is trying to figure out how do you, you know, aside from direct command language, how do you get people to actually do things? And 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 signup page back in 2008 was, "Why the hell do you have a confirm password?" You know, well, I mean, you have their email address if they—if it's broken, just ask them to, you know, 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 it's fine. Why would you for this strange case that doesn't happen that often? And it's actually really interesting. If you remove that confirmed password it actually will increase conversion on a signup flow by as much as 50 percent on average. So it's significant. You know, 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? And so, you know, I like to use this example; this is Lego Windows 95. This is this absurd, you know, I mean, one of the first wizards really to come out. But, you know, I think that there is a timeless aspect to it. You know, the other thing that I often think about, because, you know, some of you in this room will be doing fairly B2B enterprise.

You just like complicated configuration steps, you know, kind of 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 acts more intelligently with a wizard.

And so, you know, these are a couple patterns that you can use. And then I want to kind of stop there and sort of really point out another super big misconception that in beginning designers or people doing it yourself, you know, have—that they sort of run into all the time. They’re always trying to do something incredibly novel. And at the interaction design stage, I don't recommend that. I actually really recommend that you just steal what works.

And so, you know, don't reinvent the wheel; that's very important for you to be aware of what are the conventions and things that people already use. And so, you know, these are very basic ones. For instance, you know, pull-to-refresh is something that works incredibly well. A lot of apps do it, but you know, 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.

You know, this was from Mailbox app which sold to Dropbox. And so, you know, there's a reason why, you know, 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. And so, you know, 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 you'll just—you know, 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 know, 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 want to be something that gets people to the right place as quickly as possible. And so there are just so many visual—I can't possibly cover the whole—like that would be its own ten-week course.

So you know, I highly recommend, you know, go to that website and check it out. And so one of the really interesting things I do want to call out, and you know, it's sort of a danger zone for using design patterns. You know, one of the more common ones that I've seen is actually, you know, using the wrong kind of pagination. Like, you know, one of the things that can be very frustrating to use—I’ve seen, you know, people designed 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, that's really, really bad. And so you have to be incredibly careful with mixing modalities, you know, and even each one of these design patterns as you implement them, you should sort of think through like, well, why am I here? What does 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. You know, visual design really is about, you know, again, these things really do blend together. It's the interaction design and visual design are, you know, they're super linked, and it really is how you tell a user what is important at the visual level— you know, what emotions do we want to evoke? How do we want them to feel?

And the output of this is either, you know, pixel level compositions—usually, you know, Photoshop or, you know, sometimes the actual HTML/CSS. And so the really interesting thing here is that, you know, to go back to function over form, you know, when you're forced to be simple, you actually have to solve the real problem.

So, you know, they want to start off by just saying like, let's just avoid as much ornament as possible. Like, you, you know, 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."

And so, one of the key concepts that he talks about is chart junk. So he just can't stand chart junk. You know, then these are just examples of it. You know, here's a chart, but there's no Y-axis, and we don't know what the X-axis means either. And you know, why—what—why is that a green background? And you know, for this map, like why are these, these are these, you know, strange gradients? And what do they mean?

And then, you know, again, what the major misconceptions that people starting out have around visual design is, like, you know, visual design is not actually about necessarily expressing yourself per se. The key thing is what are you trying to—what information that you're trying to get across? And so one of the key principles that you can actually apply is, you know, just look at any design that you’re doing, and just try to figure out, you know, if it can be removed without taking away any meaning.

So that includes, you know, text. That includes lines, borders, you know, really anything. I mean, even colons—like, I, you know, the pet peeve of mine is like seeing colons all over a form on the web or, you know, in a mobile app, and it's like, you know, if you removed it, like would you even notice it? In fact, it looks cleaner. And so this is, you know, a stupid example, but an incredibly basic one that you know you can apply over and over again throughout anything that you do.

You know, ornaments at the end—they are not signal; you're really—like, then this is a very opinionated version of design, of course, but it's just worked for me. It's that, you know, we want to eliminate this type of ornament because we want to focus on that which is useful.

And so how do we actually do that? Okay, 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 that you can give is bold versus not bold—more important, less important— incredibly simple. The other—that 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, and so immediately you can kind of see, you know, 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. And 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 you try to design anything.

It's, you know, all of your choices around color around weight, you know, it really is a question of contrast. And so it goes both to the less important, but also the more important. You know, if you want to, 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 know, you can kind of—we call it the squint test. So if you can look—if you look at any webpage, any effective mobile app—immediately, if you just squint your eyes at it, if you can't make out the details of what's on that page, but you can just make out the basic shapes of—you can, you know, without having the ability to read any of this, you kind of know, oh, there's something—you know, your eyes immediately drawn to the thing that is the highest contrast, the highest weight on the page.

And so this is a very basic, you know, basically your hammer for visual design is contrast. Related to that is closeness. And so, you know, you as a designer can take related flows, related ideas and put them together to make them actually relate. And that, you know, serves your purpose as a designer.

And so I can't tell you how often this is just a personal pet peeve of mine. You have this login page, and then why, you know, what is going on there? Like, why is the login page? It's like—it’s very confusing because 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, you know? That, to me, feels so much better.

And so it's a very simple principle, but, you know, one to be very, very mindful of. But if you put both 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, you know, the basic building blocks of being able to create great visual design do-it-yourself style.

In a nutshell, you know, sort of—not to break it down to the CSS level, but you could literally just create divs that were of any size that would automatically flow into a flexible grid, and that's incredibly valuable. And so just, you know, this is just, you know, literally the boilerplate stuff off of the old version of Bootstrap, but you know, it's a good example of using a grid.

And so why this is important? Well, you know, we can overlay this grid and we can actually see that we are immediately, you know, and so you can see how the headings actually just line up to particular sections of this visual design. And it’s important because users, when they're using your site, they're coming to your site and trying to figure out, you know, 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 ahead, like headings exist exactly for this reason. A user will go to a webpage or an app, and they'll 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 what I'm looking for?

I have a goal; is it, you know, is this going to get me what I want? And then if so, then they'll actually direct their, you know, if I do care about that part, then immediately I'm going to dive deeper into, you know, exactly that part. And so visual hierarchy is your best tool for giving your users, you know, basically the guideposts— like this is the way to go.

So, okay, now we got visual hierarchy, but you know, what do I do with all of these lines, and you know, why are there so many? You know, how do I use color? You know, it can be very confusing. And this is a common mistake for people who do DIY; they just, you know, put boxes all over everything or they use lines and things like that.

Here's my super EXTREME oversimplification on how to do your own layout. You know, basically figure out what you need to put on the page, and then first, you know, try to use padding and margin to the extent that you can. You know, you can use a grid; you can put related things close to each other. And then next, use a line if you have to.

And so, you know, 90% of the time you can probably get away with just using, you know, a proper grid with enough spacing, putting related things together with good headings, thinking through the contrast. But finally, you know, 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, you know, websites around a call to action. It, you know, really is a high-contrast thing.

So, but be very, very careful when you use it because otherwise, you know, you kind of end up with this sauce of a ton of boxes, and you know, I have no idea what's important and what I should be doing. Whereas if you use the grid, if you use this sort of visual hierarchy, it is very straightforward. You know, the other thing that's very valuable is like you don't have to fill every single design.

You know, margin de margin, white space can be incredibly useful. You know, sometimes even helping direct a user, helping to explain what's going on, like having, you know, space on the side just gives you a place to put that or to just, you know, focus the user’s attention. And so, you know, those are incredibly basic, but, you know, a lot of these minimal techniques are really from, you know, the folks who created Helvetica from Swiss design in the, you know, mid-20th century.

You know, and so these are incredibly simple things, but the use of contrasts, the use of a grid, and the use of color can actually do a lot. Okay, so I said that we're almost done with the tactical part, but I lied because there 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, you know, if you ever put yourself, you know, some of you have—you took the airport; you took an airplane and walk through SFO Airport. And maybe that was the first time you've ever been, you know, every airport is—this, you know, 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 we don't—you know, the signs are placed in the wrong place.

And there's actually—it's actually incredibly hard. If you put yourself in the shoes of the airport designer, the architect who created this airport, and more specifically, the person who put up the—you who designed where the signs go, you know, you have the design; you know where everything is. You're sitting there in your design tool, and you know where everything is—like, it's all loaded in your head. But how are you going to know for someone who's never been that airport, you know, what am I looking at?

You know, I'm at every given point in that airport, you know, what am I trying to do? What are my goals? And, you know, the lack of proper signage is one of the things—I'd get lost in airports all the time. I got lost in, like, Paris, accidentally, like just like this weekend, actually. And so this is actually what feedback is designed to solve.

And so there's actually two types of that, you know, both designers and founders should be really, really aware of. One is usability testing. So actually that moment between the wireframe and, you know, you can kind of even do this in parallel. Like 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 have never seen it before and just sort of walk them through it.

Or even better, say, you know, just ask open-ended questions: "What are we looking at? You know, 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 going to click next? You know, why am I here?" That's 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 I have to fix it in a bug in code later.

And 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; you know, they just don't even look at it, they don't reply to it. But the reality of product is that, you know, 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, right?

It's the 80% case, you know; it's the ideal case. In your wireframe, they're in the requirement document. But the best requirement documents, the best wireframe is the best designs; the best ship thing actually solve all of these other use cases that, you know, a PM might sit there and say, oh, well, once in a this happens, but there are actually ten thousand things like that—that once in a blue moon happens.

And if you add them all up, well, you have a broken product. And so that's one of the most fundamental reasons why we are 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, and you, you know, as a founder, you have the best part—it is like, I mean, these big companies—they don’t think about this at all.

Like, they literally make it impossible for, you know, designers and engineers and the product team to actually have anything to do with customer support. They just think of their users as cattle, and 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. You know, we're alone in this, you know, incredible place that, like, you know, we are so frustrated when our products don't work, and nobody listens. And so if you're the creator of that product and you listen, well, you know, you only need a couple hundred people like that, and you're well on your way to something that could be incredibly powerful.

You know, to steal, you know, quote from Paul Buchheit, don't try and go and make something that, you know, 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 so, you know, and design—the designer, the person who actually puts together the wireframes, who like thinks through the user—they're the best on the whole team to actually think through that.

So, you know, they're awesome at advocating for the user, and this process is incredibly complicated. But I just want you to make sure that you know, like, these are the parts of, you know, how I think about a great product. It's, you know, it's not just used for 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 know, 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.