스타트업의 고품질 디자인 문화 구축

### 고품질 디자인 문화 구축하기: 스트라이프의 케이티 딜이 전하는 인사이트
* 🎨 스트라이프의 디자인 책임자인 케이티 딜은 디자인에서 평범함을 피하려면 **해결하고자 하는 문제와 타깃 고객**을 이해하는 것이 중요하다고 강조합니다.
* 🚀 리프트와 에어비앤비에서의 경험을 바탕으로 사려 깊은 디자인이 민감한 거래나 서비스를 처리하는 비즈니스에 필수적인 **사용자에게 신뢰와 확신을 심어주는 방법**를 강조합니다.
* 💡 Stripe의 디자인 팀은 엔지니어 및 제품 관리자와 긴밀히 협력하여 **청구 및 브랜딩을 포함한 모든 플랫폼에서 일관된 사용자 경험**을 제공합니다.
* 📊 Dill은 이러한 요소가 사용자의 신뢰와 제품 효과에 직접적인 영향을 미치기 때문에 디자인 결정은 **기능, 사용성, 심미성에 중점을 두고 사용자의 니즈에 기반**해야 한다고 말합니다.
* 🔍 그녀는 지속적인 사용자 피드백과 반복의 필요성에 대해 설명하며, **잘 디자인된 제품이라도 품질과 관련성을 유지하기 위해서는 정기적인 평가**가 필요하다고 강조합니다.
* 🏆 Stripe의 문화는 **모든 직원이 사용자로서 제품에 참여**하도록 장려하여 디자인 품질과 사용자 만족도에 대한 공동의 책임을 장려합니다.
* 🔑 궁극적으로 Dill은 **스타트업 초기 단계부터 디자인에 대한 높은 기준**을 심어주면 경쟁 시장에서 장기적인 성공과 차별화를 이룰 수 있다고 믿습니다.

케이티 딜은 스타트업의 신뢰 구축과 성공을 위해서는 훌륭한 디자인이 중요하다고 강조합니다.

Today on design review, we'll be doing something a little bit different. I'll be interviewing Katie Dill, Stripe's head of design. The gravitational pull is to mediocrity. It's never easy. There is no black and white answer of like, Oh, you ship it when it's this, or You ship it when it's that. It's best to always come back to like, Well, what problem are we trying to solve, and who are we trying to solve it for? Katie has led design teams at some of the most successful companies in Silicon Valley, like Lyft, Airbnb, and now Stripe. So, I sat down with her to learn about how design played a role in their success and how you can build a culture of high-quality design from the earliest days of your startup. [Music] Katie, thank you for having us today. Well, thanks for being here at Stripe, and thanks for having me on. So, our audience is early Founders, and I think you and I are very much aligned that we would love to see more great quality design in the world. Yes, so I am

excited for them all to learn from you today about how to do that, what great design looks like, and how to bring that to their startups at the earliest stages. Maybe to start, why don't you tell us a little bit about your role here at Stripe and a little bit how the design team operates here. So, I lead the design organization, and what that means is that we have the product designers, researchers, content designers that work hand in hand with engineers, product managers building the product. So, for us, that's Stripe billing, that's the checkout, that's pulling together all of the various products that show up in our dashboard or in our consumer interfaces. But also, a part of the design organization is the brand studio team that works on our advertisements, our events, our branding, the books we design at Stripe Press, and then lastly, the website team, stripe.com. Everybody watching this will probably be familiar with Stripe and Lyft and Airbnb and, you know, a number of other companies that you've worked at, and they're also

known for having great design and a great user experience. What is the role that you think design played in the success of those companies? It's really interesting if you think also like back to their early days, right? So like Airbnb was creating a product that was, you know, pretty different at the time, right? Very novel, like I'm going to stay in somebody else's house. Like I've never done that before. I don't know. And so design was instrumental in making that something that people could identify with and gain confidence in, you know, the safety, security, and enjoyment of that experience. And so the founders did an incredible job bringing very thoughtful details to that experience, like how is this going to work, how is the money exchanged, how are they communicating, how do we portray it on the internet. And by doing that and really sweating over every one of those details, I think they made it more approachable for somebody to try something new. And I mean, you know, look at them now, that's just like, you know, grown in such wonderful

ways, and they're continuing to make design such an integral part of it. Um, and that same thing for Stripe. You know, Stripe, you know, the founders when they were creating, you know, the early days of these products. It is, you know, also something new and different. Like, no, people were taking payments online, but they had never solved the problem in that way. And you know, these founders care a lot about every detail of the user experience, and they put that in to the early days of the work, such that people could feel more confidence by seeing that how much they cared about the details of, you know, just how the interface is portrayed. That like, oh, maybe then you also are going to take very good care of my money, and you're also going to take care of these other parts. It builds that confidence, builds that trust, and also makes the product more functional and easier to use. Yeah, it's interesting from the outside. I bet a lot of people think of Airbnb as the UI that you interact with, Lyft, the app that you call a car, you know, Stripe.

maybe the developer API, or you know, other tools that you have, and they don't think of the holistic experience of what goes on behind the scenes there. And I think one thing that all of those companies have in common is that you need incredibly high levels of trust, more than like any other type of B2B software. A Stripe, it's moving your money. With Lyft, you're getting a stranger's car. With Airbnb, staying at a stranger's house. And if it didn't look trustworthy, and the experience was not a well-oiled machine that felt really friendly and approachable and trustworthy, I don't think those businesses would have worked. I don't know, what do you think? I absolutely agree that there is a huge part to that. I mean, if you just think about the small details, and sometimes it's subconscious, right? Is it like you see a typo, and you're like, H okay, that's like a little weird. And then you know, maybe you know something else is just like not really laid out correctly, or that like you

closed out that box, and then you lost all your work, and then you're like, Oh gosh, I have to start again. You start to question, like, Well, if they haven't pulled that off right, if they haven't gotten that detail, what other detail aren't they getting right? And I think people also have to consider, you know, you just pointed out that, like, these are companies that are reliant on that trust in that relationship. But if you think about just, like, competition in general, you are relying on building that anyway, right? Like, There's too many options out there. Like, why would I work with the janky one when I can work with the one that's going to, you know, more reliably get it right, both on the surface and underneath? Yep. I'm curious, you know, in building these big companies and having design be so integral to what the companies do, how important is the role of the founder there? And also, have you worked at companies where the founder did not care about design and sweat those details?

like you're talking about quite as much. Maybe they had another focus or, you know, another thing they're more interested in. And like, how does that play out in the role of the company too? It definitely is a major comp because it is part of the culture. And so, I think hopefully we can agree that, you know, design makes a difference in, you know, the value and the effectiveness of the product, right? I mean, you, it's not hard to look around and see places where that example comes through. And so, they, I luckily, I think most would say like, yeah, we want to have a well-designed product. But if they are only thinking about it in terms of like, well, it's going to move the numbers, then they're only going to do it when it moves the numbers. And there are plenty of times when you're making a design decision where you're not going to be able to prove it just yet, maybe eventually, but not right off the bat. What I think the, you know, founders that we're talking about here, right, like

you know Brian Chesky and Joe and Nate and then you know the Cison brothers. Is that it? It is so fundamental to how they think about building and that they first and foremost care about who are the users, what do they need, how are they going to do it, and how do we build something with so much intention, like every detail, every part of that experience. How can we make sure that is meticulously thought about and executed on? And having that mindset and then hiring that mindset in every person that enters that company will end up creating this kind of X Factor that is very different than the motivation of like, Well, how is this thing going to move the numbers? And so when you encounter one of those difficult decisions of like, Is this thing worth it to do it or not? that you know you lean on the back of like, Well, our pride is telling us that we need to do it. How have you seen some of these companies build that culture from the earliest days to give the space and the permission to actually be able to go

that extra mile and delight users and go above and beyond. Yeah, I think it is definitely something that, again, has to kind of come in in the early days in the culture, and you have to instill it. You have to exemplify it, showing that that is important, and then, you know, having the courage to make those hard choices. Like, frankly, unfortunately, you know, the gravitational pull is to mediocrity. You know, there are, you know, I would imagine most companies on this planet want to do great work, and they want to say that they will say they want product quality, but what it really comes down to is those like micro decisions every day, and are you making the one that is, you know, actually moving the product into a better place, or are you letting it, like, slip back down to me? And that courage, you know, is something that the founders can do, and they can show that, right? It's just like, you know, what, actually, we're going to hold on this ship, we're going to take another spin on it, and we're going to ship it.

next week because it's important we get it right. Um, and that I think is really hard to do. It can hurt the team like, but we've been working on it. You know, like we want to get it out just like yes, but it's more important that we get it right and we're going to, you know, exemplify that. How do you balance that with the ethos of ship early, ship often? You know, get it in front of users, get their feedback when you know it's not the best version that it could be. Yeah, and I recognize that, you know, it's really to say just like stop the ship and wait until it's like great, and that is just not a possibility. Um, especially, you know, when you're, I, you know, absolutely understand that the need for urgency in a startup, but also like, you know, even Stripe is a much, you know, larger organization. Our users are dependent on what we are providing, and so like, yeah, we want to get that feature out. Uh, so I would say that, you know, it's never easy. There is no like right

or you know black and white answer of like, Oh, you ship it when it's this, or You ship it when it's that. But I think it's best to always come back to like, Well, what problem are we trying to solve, and who are we trying to solve it for? And if this is going to hinder the user experience, if this is going to leave a mark, right, that like, you know, potentially hinder that first impression that you might make, then that's serious enough that you do want to hold and wait. But I think there's also attributes to moving fast and taking things down in maybe more bit-sized ways. So, we really leverage betas as a way of getting something out there, and most importantly, getting feedback. Because if you're just like sitting there, like crafting it all day long and taking their sweet time but never actually learning from folks, then you're not getting the product better, um, and certainly you're leaving people waiting. How do you know when you've hit that bar? I mean, it seems like it's kind of a taste thing, but like

In your own work, how do you know whether you should wait that extra week and do the extra stuff to go the extra mile maybe, or whether it's actually hit the bar and you're ready to move on to the next thing? I will say it is one of the hardest parts of the job where you know you're just like, Am I going to be a stick in the mud on this and ask for another iteration or not, and is it worth it? I think the ways to make that easier, but definitely not easy, is again, you know, going back to the users like, What do they think? How well is this solving their problem? You know, is it actually a net positive or, you know, is this not really actually moving the needle or is it maybe even, you know, having detrimental costs to it? I think the other piece is that there is, you know, a number of things that you should think about, like almost like a checklist of things that you look for in product quality.

like a high-quality product is highly functional, right? First and foremost, it has to have utility. It has to serve a purpose and solve a problem for the user. Secondly, it has to be usable, right? So, um, so you can imagine a chair like solves a problem. You can sit in it, but it's like extremely uncomfortable. Well, you know, that's not going to work out for you for very long. So, usability is that second most important thing. And then third is craft and beauty. Obviously, craft and beauty is not like, you know, nice to have. It's absolutely material to increasing the utility and usability of a product and also making it far more enjoyable. But there's no reason, you know, crafting something nicely if, like, you can't actually sit in it, for example. And so, if you use this kind of as a checklist as I look at this product as like, well, it first and foremost solving a problem, you know, if it's not, then you definitely should not let it go forward because what's the point? You're just

adding cost to your maintenance later. Um, and then you know the next pieces come along and it seems like you know whether you value and to what level craft and beauty like it's there whether you make the choice to invest in it or not just sometimes it's not good. Yeah, I honestly I think a big big big part of you know design when we're talking about design is it's just intentionality, right? It's just like are you being thoughtful about how this thing is going to be perceived or not and if there's infinite options why not choose the one that is most appealing and most easy to use and you know just like sparks a little joy. Uh, you know we create you know software for people to run their businesses and you know I think a lot of enterprise software out there doesn't put that first and foremost which is fascinating given that those are human beings that work in those companies, right? And like why not bring you know the joy to the work um for anybody.

we do think about craft and beauty is definitely not a nice to have. It's a must-have. And you know, thinking about those details, making sure that there are no defects that somebody might start to question whether or not the product is working overall, and you know, bringing a little bit more joy to the utility. Yeah, for Founders maybe that don't consider themselves to have an eye for design or a design background or something like, how can they know what great design looks like? Yeah, I think part of it is going back to that kind of checklist and thinking like knowing what to look for. Yeah, I'm a pilot, and one of the things that my CFI taught me is that, you know, before you take off, you do what's called a pre-flight. And so you look at all the aspects of the plane, you follow a checklist to make sure that it's airworthy before you know you take off into the sky. And the checklist is a really great way of

making sure you never miss a thing. But the other aspect that my CFI has taught me is that you should be looking at it as if you know something is wrong with the plane. You're just trying to find it, and so that mindset is really helpful because it really requires you to take a different posture of that like there's something here, and I'm going to find it. I'm not just going to take it for granted. And when you do that, when you think through like let's say you're about to launch an app for ordering coffee online, and you're kind of going through, and you know you yourself want as the founder want to see if whether or not the product is any good, and you start questioning every word, every pixel, you know it can be annoying for the team, but it is important that you do because when you start to question it, you wonder like oh yeah it's a little weird that you know when I hit this button I end up here, but I have no

context of where I just came from. Um, and like actually, these words don't really communicate our brand, and actually, that's not really uh communicating what I'm supposed to do next. And so, you start to think a little bit more about each of those details and observe, like, how is it making you feel? Is how is it actually helping you along your way? And is it or is it not? And what are those gaps? Um, and you know, that might not be taste, but it is certainly, you know, utility. And I think that's like obviously, again, a super important part. Developing taste, I think, is also, you know, one of the harder things to develop. Um, but you can certainly hone it, and you can improve it. Um, one of the ways, of course, is to observe, and you know, what do you like about the companies out there that you enjoy their products in? What seems to be working? You know, what are the details of it that are really nice? And just like taking note of that. Um, and then of

course you going to hire well, and you know, listen to your people, and, and, and, you know, observe, um, and, and that can certainly cultivate your taste too. It's interesting when you talk about that checklist, you know. I think one thing that um technical Founders are really good at is like finding the edge cases and um, you know, finding all the ways that like the product or the code that they've written might fail and not work. And it's really interesting to think about actually just applying that to the design side of things and trying to find those edge cases or the areas that it will break might be like a good way for them to think about it and to be able to level up their own design thinking and and paying attention to their own product. Yeah, absolutely. I I think one of the hardest parts for any of us is stepping outside of our own Viewpoint. I mean, if you're working on this thing, it's your baby. You think about it night and day. It is really hard to imagine, you know, to just like erase that what you

know from your brain and experience it like somebody who doesn't see it every day. Um, so obviously, you know, we you can do a lot of the assessment yourself, but bringing users into it is really, really important. And you know, it's never once. It's not like, Oh, we just did it at the, you know, we did user research in the beginning. It's like ongoing and, you know, work with the user, hear from them, have them talk out loud as they look at your product, and recognize that, you know, they are operating with a very different context in mind and a lot less knowledge about the product and what do they see and, you know, what does it make them feel like. Um, what is their impression of who this brand is based on, you know, the colors, the way it's laid out, or how it interacts, and is it clear to them what happens next, and how do I get there. Yeah, you talked about hiring, and I think one of the ways to get good at hiring is to see lots of candidates, to understand what good looks like. Um,

and it sounds like what you're saying is that one of the ways to get better at design is to see lots of good design, interact with it, and like see what good looks like, and then that can help you um level up. Are there any other tips that you would have for people that are trying to level up their own design skills as a founder, and that they can bring to their company? We can learn a lot from observation. Pay attention to the products you don't like and why. Pay attention to the products you do like. Certainly, you know, I recognize sometimes it's a little chicken and egg. It's like we want to get great designers, but without great design, they don't want to be here, you know? So um, I think a big part of that too is, you know, getting out there in the community, and also, you know, if you're trying to hire great designers to your team, like help them understand what role they can have in the company. Um, if you don't know how design works, don't presume to tell them how it works.

think about how you can learn from their ideas. Design often does work differently than, uh, perhaps an engineering discipline, uh, and so that is something that you know you as a Founder can learn a little bit about by bringing folks on and maybe even just an advisory role to help you think about how you're going to hire or, um, maybe even coach maybe a junior designer that's on your team, uh, and yes, I think just meeting people, learning from them, and, uh, seeing their examples as a really great way of cultivating that taste. Can you teach taste? I think you can make it better. I, I think, you know, to be honest with you, in hiring, for example, I would certainly say that it is easier to teach somebody the tools or the domain and the, you know, the space that you work in than it is to teach taste. For example, if you see somebody's portfolio, it's like, Oh, but like, you know, we're in the, you know, fintech space and this person's worked in fintech forever, but they don't

exemplify great taste. I think that's dangerous because I think it would be not necessarily easy but easier to help them learn your space, whereas taste. I think it's also like a passion for it, you know, that also can be difficult to teach because, you know, is their mindset there? Is it something that they like think about every day, that they, you know, just want to make things more attractive, more actionable, more useful? Like you, you want that like deeply in that individual if that's what their, you know, main job is in your company, right? Let's talk about design and your design process at Stripe. Tell us a little bit about the process and how that works. Yeah, I think first and foremost is actually even thinking about how we're organized and we work together. We have a highly collaborative environment where designers, engineers, product managers, they work hand in hand. So like if you ask any designer on the team like what team are you on, they'd be like, well, I'm on the connect team and

I'm on the design team, so you're not like a service or that people just kind of reach out to like an agency to get work done and then kind of go back to your cave. Yes, yeah, for a number of reasons. So, number one, you know, all those functions that I talked about earlier are all a part of the design or because on purpose. We want all those teams working well together because we want the user experience to feel coherent. So, whether you see us on the billboard or the website and then into the product, that should feel like one coherent story that's building on itself. So, that's why we're all in one org. But, of course, we don't want, you know, the designers to be just like popping in and out of projects and not having the context of the product, really the deep expertise, and also not the same goals in mind. So, they are embedded in the teams. They have the same shared goals as PMs and engineers, and they're working on these things together, start to finish, and that makes a big, big difference in

how the work gets done, and so in terms of process, uh, you'll not be surprised, but we of course always start with like, well, who's the user and what is their need. And that's where, you know, all these, you know, kind of ideas for new products and things come from, is that we're often hearing from our users, and they are very much like engaged in working with us and vice versa. And so we, you know, potentially learn about, uh, a need for a product. I I just mentioned connect, so this is our product for platform businesses and marketplaces. And so it allows them to create essentially a relationship with other businesses so that they can help them grow, grow their own business, and even offer, uh, financial services. And so these organizations, um, that worked with us, one of them was Lyft for early days, for example. They, you know, Came Upon This need. They wanted to pay out drivers, and so they built the product with us. Um, I can talk about another product that I'm super excited to show you, which is

called workbench, similarly like we worked with Slack and Notion on you know how to make that product better every day. And so we are doing prototyping and iterating, and they are giving us feedback almost on a weekly basis. And that real tight feedback cycle and iteration in the product really helps us kind of stay away from going down faulty assumptions and creating things that just won't work in real life. And the spectrum of users that we serve, and this is probably the case for most of your Founders too, like you know there's not going to be one type of user, you know, that they're going to be interacting with. And so to work with a range of users and have that iteration cycle really helps reveal things that you might not otherwise never have thought about. And that really could persist straight on into the execution and the shipping. And we keep learning and iterating because one thing that I think you know never ceases to surprise us is that you know you could design this perfect little product and you get

it out into the world, and then what do you know? Like three months later, it's full of bugs, and you know the interaction points with your next new product aren't great. And so, you really got to stay steadfast into learning about your product and seeing also how it continues. And so, we actually have this part of our process, and it's almost like a culture of using the product and doing walk-the-store exercises, where people from, you know, honestly anywhere in the company, but especially, you know, in the product teams, you know, engineers, product managers, designers, um, trying the product like a user would in the journey aspect, right? Not just that moment in time where the product shows up, but thinking about it from, you know, how do I learn about it in an email? How do I, oh, and then I go into the website? Oh, and then I go into the product, and how does that feel? And what are the moments where it doesn't make sense? Because, you know, the day it shipped for the first time, it may have

been all perfect, but over time, like it starts to, you know, potentially erode with the creation of new things. So, you got to continue to evolve it too. I think every founder has had that experience of trying to nail the product, launching it, focusing on other things, and then coming back and trying your product six months later and being like, Oh my God, what has happened here? How did this happen? Yeah, I mean, it's a, it's kind of funny. One team member had given this analogy. It's like when you're working on your house and like you redid the dining room, and so you added nice new molding and like little light plates and painted the wall, and now all of a sudden the dining room next to the kitchen looks horrific. And you know you have to think about how, you know, you're continuing to push and pull different parts of your product and, uh, never lose sight of how it fits across all of them. How often do you do that, walk the store with all your products? I mean, I bet you someone is doing it, right?

now um it is it's just a it's a cultural norm um we have a a program where it is like very organized and established. It's called our essential Journeys and so what we did was we identified what are the you know top 17 you know most important user flows that many of our users go through you know daily um and it's not a comprehensive list by any means but we just needed something kind of digestible and so there's 17 and we have dris and team members assigned that every quarter they review that experience they score it they friction log it so that's like kind of writing down your experience as you go and and noting where like well that felt weird and this is kind of that like check that uh pre-flight thing that I mentioned of like using a checklist to like does this make sense or not and noting that down scoring it we keep it on a scoreboard there's a little social pressure of like let's get these things to green and our scoring mechanism it's nothing fancy.

it's literally, it's just like red, orange, yellow, yellow, green, and green. Uh, and we pay careful attention to it. It's a company goal to get these things to green and keep them at green. And so, you know, as I mentioned, like regressions can happen. So how do you stay steadfast on that, improve it quickly, get it back out there? And so, yeah, it's definitely happening a part of that program. But I think what's super cool is when, you know, somebody from the, you know, um, sales team does a walk-the-store of the, you know, uh, billing product and then sends their friction log to the billing team. Because those are those great moments of hearing what somebody thinks who's not living in it day after day and like see that like, Oh, that actually doesn't make as much sense as we thought for somebody who doesn't have the context. I love that cultural norm of measuring these things and having effectively like leaderboards and calling it out publicly and making that visible to everybody. That's a

really great way to emphasize this in the culture. Yeah, absolutely. So, we have several examples that I'd love to show you, and yeah, would love to check it out. Yeah, so, uh, one of the things that I think actually came out of the walk-the-store exercises that we do, um, is that you get to experience the product firsthand, and you really get to feel it. Like, a prototype might not always show you how it's going to show up in the real world, so using it in the real world is very helpful. And the other thing I didn't mention is that we have, um, a bugs-at email alias that anybody can send a bug to in the company and outside the company. Because of that, we can hear from various people in the company that have tried the product and seen an issue, and it's like, If you see something, say something, which is, you know, super helpful. So, one of the things that came out of that was that we have this product called Link, uh, which is our extremely fast way of checking out.

online, uh, but what we also provide with it is a way to buy crypto really quickly. And so, in this website here, is a nice easy tool where you can quickly buy crypto. And what we found is that when you proceed and somebody types in their email address, uh, what was happening, I I I'll tell you what the problem was 'cause it's gone now, so I have to tell you. But you would type in your email address, and before you would stop typing in the email address, there would be an alert that it was invalid, was invalid. And that I'm sure you know, maybe in the figma file, was like great, we're going to do this, and it's going to be fine. But what like actually is different when you feel it is just like that's really annoying, you're yelling at the person before they even finished. And so, what we did was just you know, we saw that that was a bug filed, and so now as I I type it in, it it doesn't yell at me. And what's cool is even when I hit a space, right,

the space is not needed, but it's just like a natural thing a human does that is not, you know, on purpose. It's not yelling at me now; it will yell at me if I give it a second. So now it alerts me when it's appropriate, right? It's just like a little bit delayed, and that microc, that matters. And so I'm super glad that was filed and taken care of. Y. Another example that I think is going to be useful as a point of how much design can really impact the bottom line is this great one about an email. So we had this one email that was trying to communicate to a user what to do with the product after they have signed up. And as you could see, it's just like there's not a lot of hierarchy; it's not a real clear call to action, what to do if you read it. You know, the words just like not super clear; it's kind of a wall of text. It's easy to delete that and ignore it. Yes, exactly, and it's just like what

is the role of that versus something else, so we redesigned it and we thought about the words. Of course, we thought about what happens after you hit this button. Is this button clearly communicating what happens? We certainly added more hierarchy, a little bit more visual interest, which also communicates better, and doing that increased product conversion by 20% from this email, which is pretty huge. And I can see why. There's a clear call to action. There's a headline that, you know, I can't read the sub-paragraph there, but I can read that headline from here, and it immediately gets my attention. Yes, yes. Okay, so let's talk some product stuff. So, um, so thrilled about this product, uh, that we launched this year, that is called, uh, workbench. And so, we were hearing from the developers about the, you know, some of the challenges they have with working with the integrations and, and continuing to maintain and grow, um, one of which was, you know, essentially breaking their flow state. So, they would be working in, you know, the stripe, uh

dashboard and they would be going back to their code editor and you know a lot of switching of um what do you call it contact switching um or going to the docs and cont sing lots of tabs Etc and we had a you know we've had a developer area but that was kind of getting like a little too jam-packed in a small space and so we wanted to create a tool that would make it a lot more powerful and easier for developers to use and stay in their Flow State and so with workbench um it comes in here at the bottom of the product and you can see you could pull it up um you could change the how much of it it takes over this screen and what it provides for you is basically it's both like a microscope and a telescope of what's going on with your integration and so you can debug it you can prototype it you can make changes um and all of that stuff is right there for you so I can give you an example so let's minimize this for a second and so let's

say I'm in the dashboard, and maybe somebody in the company let me know that a user called, and the invoice didn't work out, and so we got to debug it. What? Why didn't it? Why didn't they get charged? So, we come over here, we go into invoices, and I take a look, and it's like, Okay, here's the user. What happened here? What are the issues? And so, you see here in workbench, it's offering this little information to inspect. I could also see whether or not there were errors related to it, but it looks like not right now. But if I click on the inspector, I can come in here. Now, I can see the background of what is involved in this invoice, which is also helping my mental model of how the API is constructed, which then, you know, kind of fuels the developer's ability to go further with it and build potentially, you know, new innovations on top of that. And so, let's say, Okay, I want to learn about the customer. What's going on with them? What

happened in the event, and I can go right into the API explorer to then, you know, if I need to understand what's happening in the API and make changes. And so, this is almost like a little coach for you to be able to see how this works, what's behind all of these various parameters, and, you know, what you would normally be doing today would be going to docs, also reading about it, and it's just like, again, contact switch. So, that information is now here. I can make, Oh, okay, that's what wrong. It's their email is wrong. So, I'm going to just get rid of that error. Let's do that. Let's run it. Okay, it's updating. Let's get the code snippet so I can just bring that into my editor. It's right there in my language, which I could switch out. And now, if I go back to that spot there and see this user, it's already updated right into the dashboard. So, it's really kind of like lowering that hurdle between the dashboard experience and, you know, your editor and

really being able to like bring the power of the CL right into the dashboard. And so we've gotten great feedback, and this is that example I told you about where we were working directly with Notion and Slack and iterating in real time and hearing from them how to make that better. Yeah, this is great. I don't know that I've ever seen something like this before. Um, and it seems like you came up with this from some first principles thinking. It's like a web inspector but specific to Stripe and for all the tools that you would need to manage and improve um all of your Stripe integrations. That's super cool. It's really cool, and thank you for saying that. I think the team crushed it on this one. And you know, one of the other things that I love about this is so check this out. So part of this like process of working with users on it was that we created uh this forum, this community called Insiders. And so we can you know continuously hear from developers about their experiences it and learn from it.

and so even recently, the designer on this work back in May posted about it, and it's like, Hey, here we did this, what do you think? and you get the commentary right on it. It's like, Actually, this isn't working, and like, This is really great. And you know, no matter what size the company is, that regular touch with users is so critical to actually make a product for users. I think one of the things that I take away from this conversation is how deeply integrated the entire company is with your users. And you've got founders talking to users and sharing that with everybody. Everybody's encouraged to be a user of the product and report feedback and things that they learn on a regular basis. And uh, you've got forums like this that uh, help you connect really closely with your users. And I think that probably clearly explains why Stripe builds such great, well-designed products. And so, you know, kudos to you for leading a lot of that. And um, the other thing that stands out to me is pride. It's very

clear that you and the founders and everybody that works at Stripe takes a lot of pride in the products that you put out, and I think that that shows. You hold that high bar for yourself, and I think that's a lesson that all founders can take away: the level of pride and the level of detail that you go to to make something incredibly great for users. So, um, I've learned a lot about that today, so thank you. Well, that is all very, very nice to say. I appreciate that. And yeah, honestly, I do think like the Cs and brothers did such a fantastic job instilling that in the culture. It does move the needle, you know. Design certainly does make, you know, business sense, but even if it didn't, they would still do it. And I think that that's that X Factor. That's the thing that's going to make, you know, hard decisions along the way possible and certainly worth it. Awesome. Well, thank you so much for having us. Yeah, of course. Thanks for having me.

Mastering Product Design With Katie Dill: Lessons from Stripe, Airbnb and Lyft

Videos to help you build a successful startup. Subscribe for startup advice, founder stories, and a look inside Y Combinator.

What is Y Combinator?
We invest $500,000 in every startup and work intensively with the founders for three months. For the life of their company, founders have access to the most powerful community in the world, essential advice, later-stage funding and programs, recruiting resources, and exclusive deals. 

Visit ycombinator.com to learn more.

Video Team:
Zach Both - Video and Content Lead
Ryan Loughlin - Senior Producer



Y Combinator

스타트업 성공에서 디자인의 중요성

스트라이프의 디자인 책임자인 케이티 딜은 문제를 해결하고 사용자의 신뢰를 구축하는 데 있어 디자인의 중요한 역할을 강조합니다.

그녀는 에어비앤비, 스트라이프와 같은 기업의 사려 깊은 디자인 디테일이 사용자의 신뢰를 얻고 성공을 이끄는 데 얼마나 중요한 역할을 했는지 강조합니다.

사용자 경험과 비하인드 스토리 모두에 초점을 맞춘 디자인에 대한 총체적인 접근 방식은 높은 수준의 사용자 의존도가 필요한 비즈니스에서 신뢰를 구축하는 데 핵심적인 역할을 합니다.

건축 회사에서 디자인과 리더십의 중요성

디자인은 기업의 성공에 중요한 역할을 하며, 창업자의 사고방식과 문화는 기업의 실행에 필수적인 요소입니다.

사용자의 요구를 우선시하고 디테일에 세심한 주의를 기울이는 기업은 단순히 숫자를 움직이는 것 이상의 독특한 문화를 만들어냅니다.

제품 출시의 시급성과 품질에 대한 요구 사이의 균형을 맞추는 것은 어렵지만 성공적인 조직을 구축하는 데 필수적인 요소입니다.

사용자 중심 제품 개발의 중요성

효과적인 제품 개발은 사용자 문제를 해결하고 사용자 경험을 향상시키는 데 초점을 맞춰야 합니다.

베타 테스트를 통해 피드백을 받는 것은 제품을 개선하고 사용자를 기다리게 하지 않기 위해 매우 중요합니다.

고품질의 제품은 기능적이고 유용하며 미적으로도 만족스러워야 하며, 의도적인 디자인 선택을 통해 사용자에게 즐거움을 선사해야 합니다.

창업자로서 디자인 기술 개발하기

창업자는 제품의 유용성과 사용자 경험을 개선하기 위해 제품의 문제점을 찾고 모든 세부 사항에 의문을 제기하는 마음가짐을 가져야 합니다.

성공한 기업을 관찰하고 배우는 것은 물론, 적합한 인재를 고용하고 그들의 의견을 경청하면 좋은 디자인 감각을 키우는 데 도움이 될 수 있습니다.

지속적인 사용자 조사와 상호 작용, 그리고 좋은 디자인과 나쁜 디자인을 모두 관찰하는 것은 창업자가 디자인 기술을 향상시키고 팀을 효과적으로 이끌기 위해 매우 중요합니다.

디자인에서 배우기: 창립자의 인사이트

디자인과 엔지니어링 분야는 서로 다르므로 창업자는 디자인 전문가의 도움을 받아 배울 수 있습니다.

Stripe에서는 디자이너, 엔지니어, 제품 관리자가 공동의 목표를 향해 함께 일하는 고도로 협업적인 환경이 조성되어 있습니다.

디자인 프로세스는 사용자 중심으로 이루어지며, 긴밀한 피드백 루프와 반복을 통해 다양한 사용자 요구 사항을 더 깊이 이해하고 제품을 지속적으로 개선할 수 있습니다.

제품 몰입과 지속적인 개선의 중요성

이 회사는 제품 사용 문화를 강조하고 사용자 여정을 이해하기 위해 매장을 직접 둘러보는 연습을 실시합니다.

필수 여정이라는 구조화된 프로그램을 통해 상위 사용자 흐름을 검토하고 점수를 매겨 녹색 상태를 유지하는 것을 목표로 합니다.

또한 버그 제보 이메일을 통해 피드백을 장려하고 여러 팀의 인사이트를 활용하여 제품 문제를 파악하고 해결합니다.

사용자 경험 및 제품 디자인 개선

웹사이트의 암호화폐 구매 도구에 성가신 이메일 유효성 검사 문제가 있었는데, 유효하지 않은 항목에 대한 알림을 늦추는 방식으로 해결했습니다.

잘못 디자인된 이메일 커뮤니케이션을 다시 디자인하여 제품 전환율이 20% 증가했습니다.

새로 출시된 워크벤치 도구는 동일한 인터페이스 내에서 디버깅, 프로토타이핑 및 변경을 원활하게 통합하여 개발자가 흐름 상태를 유지할 수 있도록 지원하는 것을 목표로 합니다.

Stripe의 API 탐색기는 실시간 피드백과 코드 스니펫을 제공하여 통합을 관리하고 개선하는 프로세스를 간소화합니다.

이 회사는 커뮤니티 포럼인 인사이더를 통해 사용자들과 적극적으로 소통하며 피드백을 수집하고 제품에 대한 반복 작업을 진행합니다.

창립자가 심어준 Stripe의 문화는 디자인과 사용자 피드백의 중요성을 강조하며, 그 결과 잘 만들어지고 영향력 있는 제품을 만들어냅니다.