Design for startups (part 1)

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 Postress, 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.

And then following Gary, we have Kat Manialak, 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.

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 startupschoolatycombinator. 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. And 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, to startupschoolatycombinator. com, 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.

Um, 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 will, I am hugely pleased to introduce Gary Tan. Thank you. Thanks, Jeff. Thanks, Jeff. Thank you.

Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thanks for coming all the way out and spending time with me to hear about design. And well, frankly, design can be incredibly complicated and there's a lot to it.

But in 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. 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 cliche 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 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. And 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 going to explore today is, you know, well, what is design? Why does it matter?

We're going to go deep on both the concepts around product design, interaction design, and visual design, but we're also going to 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 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, 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 doing 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, 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 put together the iconography of something that is very significant. And so when I joined Palantir, it was just 10 people, and we got to design this logo.

And one of my favorite things about it is this mix of both meaning and aesthetics. And so on the face of it, one of the things I really wanted to do was sort of really underscore what Palantir was about. And so 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 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 design actually, well, 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, into something that can go on a T-shirt or on a hat, actually.

And 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. 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.

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, perhaps now, perhaps tomorrow, that you'll want to actually start applying these things. Google's your friend. There's everything in the world that you need to know. It's out there.

And so the computer is truly the bicycle for the mind. And so the other thing that I really want to underscore is we talk about design as the 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. And so 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 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.

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?

And 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.

And one of the most important things that I think that he really showed us in his designs is that 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.

And just to drive it home, I mean, this is a guiding sort of force in sort of everything that we see in the marketplace today. History doesn't repeat, it rhymes. And another thing 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. And 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 that, hey, this is new. I've never seen this before. This is interesting. I 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 stake.

If delight is a sizzle, then works well as a stake. That's why we're here. We're trying to get something done. And 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, 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, you know, this is again an example of form, this idea of, 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, 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 were 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, there's not, 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, form 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 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, 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 what are your users thinking? You know, what are they feeling? 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 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 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, 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, 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. You know, beers are over here.

And so, you know, that sort of politeness, that inviting, welcome 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, 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 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, basically each of these do sort of talk about a particular, 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, of 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 interest 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 design for its own sake. And, you know, design for its own sake isn't design, it's art. 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. You know, make stuff that we think we need and then actually it's not, 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, they're 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 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? 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 of this physical object? Or, you know, transportation design. Like, a car is one of the most evocative things. It's 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 going to 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, 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's 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, and 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, 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, I 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 there's, you know, this, you could call this product management. Some, you know, 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, 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 had 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 problem statement is actually to think through who are these very, very specific people who have this problem. And so I'm going to 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, 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, or very specific things like, you know, what type of phone do they use or what type of computer do they use. 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 do they use for email? You know, 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 intention as well. It's like 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 technology is 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, you know, they're being deployed to construction, to, you know, global freight. So if you walk into any office in the world, you know, you're going to 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 in line level worker and their 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, 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, you know, 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, you know, 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 could 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.

And what we, 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 post at posterous. com and we'd take care of the rest. The interesting thing was that 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.

And so, you know, 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 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 up 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, and 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, you know, we want to use our product and to be as basically crisp as possible around, you know, what their needs are. You know, we call that user research.

And this actually does, 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 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, and 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, it 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, 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, 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, you know, 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's 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 ship, right? 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 must-have. We're just going to 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 attachment 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, you know, 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, 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 file, video file support.

At least, you know, if your 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, what 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 PMing a given product gets very easy because you can just cut off the bottom. Everyone sort of knows, well, you know, we're going to 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, you know, 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 always, 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 in production, and you're not going to 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, the other 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, 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, F it. We'll just ship it. And so, you know, it's a real danger.

Like 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, how do we actually translate that into, you know, something that, you know, you can actually start working on? And so the questions 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 know, you might use a tool like OmniGraffle, or you know, there's quite a few prototyping, wireframing tools that are out there. And 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, you don't wanna care about color, you don't wanna 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, and 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 B. J.

Fogg at Stanford were able to show that people mirror with computers, even without any sort of anthropomorphism, 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.

And 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. 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 phenomenon that I can think of, it maybe explains Trump and a lot of other things, is that 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, you know, kind of a part of you.

And 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. 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.

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 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, in your design, in your first time experience. You know, it's passive voice.

You're, you know, you're not showing your 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. 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 to be incredibly obvious. Like, you know, the previous, you know, 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, you know, called out to me on our signup page back in 2008 was why the hell do you have a confirmed password? You know, well, I mean, you have their email address. 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 optimize 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% 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 because it's like, you know, Windows 95 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, 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 know, 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 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 beginning designers or people doing it yourself, you know, have, you know, 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. It'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 is from a 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, you know, 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, you know, there are just so many of these that I can't possibly cover them. Like, that would be its own 10-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 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, you know, 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 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 going to 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, I want to start off by just saying, like, let's just avoid as much ornament as possible. Like, 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 Quantity. quantitative information.

And 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 means either. And why is that a green background for this map? Why are there 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 trying to get across?

And 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, borders, really anything. Even colons. A pet peeve of mine is seeing colons all over a form on the web or in a mobile app.

And it's like, if you removed it, would you even notice it? In fact, it looks cleaner. And 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. You're really like, and this is a very opinionated version of design, of course, but it's just worked for me.

It's that 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. 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, 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, your eye is 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 related. 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 know, you have this login page, and then why, you know, what is going on there? Like why, why is the login page, 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 all of 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, 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 to, 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.

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 guidepost. 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, there's, it can be very confusing. And this is a common mistake for people who do DIYs. 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. You know, 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 a 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 to 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 there's, 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. 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 know, took the airport, took an airplane and walked 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, who designed where the signs go. You know, you have the design. You know where everything is.

You're sitting there and, you know, 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 to 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, lack of proper signage is one of the, you know, I 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.

You know, 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 have to fix it in a bug in code later. And then the other part that is way, way under appreciated 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 or in the requirement document.

But the best requirement documents, the best wireframes, 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 blue moon this happens. But there are 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.

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 know, as a founder, the best part is, 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 going to 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, a quote from Paul Bukai, 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. You know, 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 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.