Hey guys, what's up? As promised, I'm here with Scott Tom Scott has worked in product design at places like IDEO, IFTTT, Pinterest, and he's now a designer fund, he advises early stage startups about design. Essentially, you just think of him as like the goat of, of design. And we're really excited to hear from him. Before we do, I'm just going to remind you, audience q&a is open. So any questions that you have for Scott, please do put them in the chat, put them use that q&a button, and we will get to as many of them as possible. And with that, Scott, first, thank you so much for being here. And second, take it away.
Well, thank you for that I have never been called the goat of design or anything. So I'll take that as a very high call coming from you, Jordan. Thank you, TechCrunch. And thank you all for for taking your time out of your day to join me on on the stage today to talk a little bit about design. Jordan already gave me a great intro here about a couple places that I've been before. And there's a couple topics, I wanted to share with you all that I think, you know, get bandied about quite a bit brand design process, working with designers. And I want to sort of illuminate or demystify these a little bit, because they these terms do get used so frequently. And hopefully, we can start from some common ground, especially as folks are building new companies, you want to think about these topics thoughtfully. And the goal here for this presentation is really to, you know, there's a spectrum of those terms being overly simplistic or maybe too complicated, and over my, you know, career as a design practitioner and leader to try to synthesize them for you to be hopefully useful. And they've worked for me at various stages of company building. And I hope they're useful for you as well. So the first is brand. Of course, the term comes from this idea of branding cattle that, you know, stretches back, I think 2700 BC, or even before that, to allow people to identify their cattle differentiate from one another, which whose cattle was whose. But in modern times, it's sort of gotten reduced to the term becoming about logos, right? When people talk about brands, oftentimes, the uneducated will say, what's your what's your logo, what's your brand logo. But on the other end of the spectrum, it is become really complicated to this is the Wikipedia entry for brand. And I would challenge anybody to digest this, absorb this and then be able to regurgitate it back to somebody and say, here's my understanding of brand. But a useful analogy that has stuck with me for many years actually comes from the book zag by Marty Marty neumeier. And he says that the closest word in the English language to brand is actually reputation. And I think that's a really great analogy. And so you know, the analogy of brand is to company as reputation is to person. There's a really interesting, here's a kind of funny explanation of it visually, the differences between marketing, telemarketing, public relations, advertising, graphic design, and branding, branding brand is about reputation. And this is kind of the analogy of people, right. But if you look at a logo, you know, this See, without any context probably connotes certain things, maybe the first word that came to your mind was cat. But if you change it, the meaning completely changes as well. Of course, this is the logo for Chanel. And with that logo comes all the associations of the reputation of the Chanel brand, the quality, the history, the prestige that comes with the luxury, and use in a different context, that C has a completely different meaning and has a completely different set of associations, so brands, reputations, if you can kind of link those two together in your mind. I think it's a really great place to start when you're having conversations about brands is what is that reputation? You know, what is the first impression? What are the consistent behaviors that your brand hopes to repeat over and over? What are the memorable moments that stand out that that stick out that make your brand your reputation memorable? The second is design and ironically, the term design suffers from a brand issue. Many designers have heard this before, make it pretty. I think that's on the simplistic side of what designers do is kind of the skin around whatever the product or service happens to be. But on the other end of the spectrum, you know, design hasn't doesn't as a word doesn't do itself any service, it has 14 different definitions and Merriam Webster dictionary, and they're all accurate. They're all correct. But as people use them in every day, you know, work. They are, they might have one definition in mind when another person is kind of receiving it on the other end, they have a different definition in mind.
And to complicate things further, there's so many different disciplines within design, right? There's, you know, of course, as a TechCrunch, product design, UI UX. Those are what typically get referenced when we talk about design, but there are things like sound design, apparel, design, set design. So what is it that actually ties all these things? You know, these design disciplines together, if they're so vastly different, or can be so vastly different. And a great quote from Herbert Simon, American economist is that to design is to devise courses of action aimed at changing existing situations into preferred ones. And that definition has stuck with me for many years, because it highlights two different states existing and preferred. When you're thinking about existing situations, you have to come to a kind of shared understanding of what is true today, with your product, with your service with your brand, whatever you're designing what works, what doesn't, and why. That's kind of the starting place for any new thing or incremental change that you hope to improve on. And then when you get to a preferred situation, what's embedded in the word preferred is like, Who is this preferred for? And how is this better for this audience for this audience, that you have some intent to make the situation better for. So really keeping those words in mind existing and preferred and the transition between them the intent behind the transition between the existing state and the preferred state is really something to keep in mind when you're thinking about design. You know, it's not just about the pixels at the end of it, it's the thinking that goes behind it. The third is process. You know, there are many different ways to talk about design process. But for those that have never worked with designers, maybe they think that the process is like magic, it's a black box. And oftentimes, design gets conflated with art. Oftentimes, design and art use some of the same tools. But they are very different purposes. They serve different purposes, art and design. But on the other end of the spectrum, what it's complicated is, we can try to diagram what the design process may look like. There's a human centered design process, there is the Double Diamond process from the British design Council. And these are attempts to sort of help bring folks that are not designers along on a journey, which can be quite confusing, and is not often linear. But we try to make it we try to tell the story that is linear to help kind of grasped what goes on, and what happens in this in the creative process. And, of course, what design deck wouldn't be, would be complete without a Steve Jobs quote, when you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and you live with the problem and peel back more layers of the onion off, you can oftentimes arrive at very elegant and simple solutions. If I try to break that down and synthesize that into something that's been useful for me, in teams that I've worked on, or worked with, or LED, it's kind of two sides of the coin, designing the right thing, and then designing the thing, right? And what that kind of means is solving the right problem spending your energy figuring out what is the right problem to solve. And then once you figured out that, that right problem to solve, you've hit on something. How do you strive for the best possible version of that current solution? So a good designer, good design teams will think about both sides of this equation, are we designing the right thing? Or are we kind of spending our time polishing finessing, making sure that this is the best possible version of the current solution? And over time, the right thing ends up becoming dated or competition comes. And everybody kind of copies the idea. Maybe there's a need for innovation. So you might go back after designing the thing, right to designing the right thing again. I've also heard this articulated as problem seeking versus problem solving. And when you're building products, especially in software, there is no real end state. It is a iterative process. It's a dynamic process. You know, user needs change, business needs change, technologies change. And so there is this need to kind of vacillate Between problem seeking and problem solving.
And of course, you know, working with designers can often be a varied process, depending on the kind of agency that you might be working with. Or if you have full time employees in house, or, you know, there are variances of where people are educated or what kinds of industries they've worked in before. So one way that I've heard and have talked about working with designers is thinking about the two ways of designing a service, or design as a partner. And when you think about design as a service, there is this kind of idea that there is a finite beginning and end to the relationship or the engagement. You know, there are many more steps than the oversimplification here. But at the beginning, there's some sort of statement of work, there's probably a number of check ins along the way. And at the end of the engagement, there are some sort of deliverables that are that are handed off. But when design is a partner, where it's really difficult to tell, where does the beginning and end happen, because there shouldn't be a beginning and end. This is of course, from Eric Reese's lean startup, the build, measure learn cycle. You know, I'd argue that really great product design, it requires iteration, whether that happens to be user facing all the time or happens internally, and then you release something, you have to kind of work through these iterations together. And great designers understand that building a version one is usually not the first the best version of anything, it takes many, many iterations to kind of get to a great solution, and refine and refine it and find to get to the kind of most pure form of it. So when you think about these and compare them, they can be used in different ways, right? There's a clear beginning and end when there's design as a service. But when it's design, as a partner, you're thinking about an iterative journey together with your cross functional partners, particularly product management, and engineering and technology startups. When you think about the kinds of profiles that you might bring to work on this, agencies, freelancers and contractors, oftentimes, what you would use for a service as a service, whereas in house full time employees, or embedded in teams, you have, you're thinking more of your designers, as partners. And when you have design as a service, you know, just by virtue of having this kind of clear beginning and end to the engagement, there's limited shots on goal, you have one opportunity maybe to get the project, right. But again, in building software, where it's kind of continuous, you're looking for this iterative journey together, where there's continuous improvement over time. So, you know, I know that's a lot for for ideas, but to just recap, brands or reputations. Design is about moving from existing situations, to preferred situations, and the questions that are embedded in those words. The process is about designing the right thing, and then designing the thing, right, and then kind of going back and forth between them. And when you think about working with your designers think of design as a service or design as a partner, neither is necessarily better than the other. But there are probably appropriate or more appropriate contexts to think about when you're kind of engaging with a relationship with your design team. So hopefully, there's some useful nuggets in there for you to take away. And I'm really interested to hear what your thoughts are, and have the discussion about it.
Thank you so much, Scott, as a lot like you said, this is all good. And it all kind of makes sense in flows. The other, I wanted to ask you, you know, the audience's is getting involved here in the q&a. But before they do, I wanted to ask you, you know, we've seen a lot happen in the design industry, right, like in the design software space in the last like five to 10 years with envision and figma and Canva. What, like, do you have a preferred design software? Like for the designers in the room? Like, is there one that you prefer over others? Or is it kind of whatever suits your tastes? Or where do you stand on on that kind of battle that's being waged?
I mean, I've probably use every tool under the sun. And they all have their kind of pros and cons. But you know, I've been very, very impressed with what figma has done in the last three to five, you know, three years or so. In fact, when I was at Pinterest, we had been using sketch for a very long time, we kind of kind of became the industry standard very quickly. And then figma, you know, slowly kind of came to parody with the feature set that that sketch had, but with the genius of collaboration on top of that, and many of the organizations that I've seen have started to adopt figma are adopting it not because just because designers love it, which they do, but also because non designers get a window into the design process as collaborators know before They start to see the final presentation or resort before they see a product get shipped. So I've been I've been very, very impressed with figma. And I have very, very high hopes that they'll continue to, to do well, in that space.
There's one question we have is that designers are kind of intrinsically tied to other departments, right? Like you don't designers don't just like, I mean, maybe they do go home and just like design stuff for the fun of it. But like, at work, you know, you're either working on a product or maybe something have to do with brand design, or maybe you're working with the sales team on their materials, or whatever it might be. How do you think that that looks in a remote environment, right, like when we're all does that it feels like it would impact designers a little bit more than it might, someone who can kind of work in a silo and they have their own okrs? They could just kind of blast forward?
Yeah, I mean, I might argue that like, it doesn't matter what discipline in your you're in, I think collaboration is really important, you know, you can design the perfect thing. And if it doesn't get engineered properly or built properly, the results still suck. You know, users don't care about the kind of relationships in between. But what happens internally kind of the users consent, so if there's fragmentation across teams, in communication, then the user will feel in the experience, what designers in particular, you know, my experience with leading teams at Pinterest, so they get inspired by being around other designers. And that's not just if they're working on the project that you know, collaboratively on a single project, you might be working on something completely unrelated. And that might spark an idea that you might be working on, you know, on a different project. It's actually one of the greatest things that I loved about my time at IDEO as a consultant is that, you know, I might be working on a project in the financial services, industry, and somebody else might be working on national security. And the insights that they have about their work might be applicable to you as a designer. So I think for sure, designers do get inspired by working with each other, but also, by seeing the work of each other going on, even if it's unrelated. Now tools like, you know, figma, or the Google suite, or Dropbox, paper, these are all means to allow folks to kind of create that shared understanding of whatever project they're working on, and hopefully, you know, collaborate in an effective way, whether they happen to be together or remote. You know, even when we're in the same building of ventures, we still have to document your work, to make sure that folks that maybe aren't, that don't have the benefit of being in the room with you can understand the decisions that you made. And then afterwards, you know, even if you have left the company, they still can look back and say, Oh, this was the justification for doing X, Y, and Z.
Let's the kind of like what's the most you advise a lot of early stage? startups? What's the most common kind of pitfall that you see companies get into when it comes to, to design, whether it's product design or brand design, like what's the more common mistakes that folks make?
I don't know if you'd call this a mistake. But I think it kind of ties to this design as a service versus design as a partner insight that I that I shared. You know, a lot of early stage founders, maybe they don't have experience working with designers, or they don't have a background in design. And so they sort of see designers as you know, there's only one type and all I care about is kind of getting the result. And so design as a service ends up becoming the prevailing model. They want to get, you know, a specific project done or a specific outcome and a short for a short term solution. And so end up hiring a contractor or a freelancer or an agency to kind of get this one thing done. But inevitably, what happens is, the result maybe isn't, doesn't hit the bull's eye on the first try. And what they'll end up doing is maybe they'll turn through another contractor or another agency to try to solve the same problem. But what's lost in that is, I think the model of design as a partner requires that iteration. And so if you if you only have one shot on goal and you miss as a contractor, or freelancer, you're kind of sLl. But if the relationship is set up in an expectation, where Hey, we know this is going to take multiple iterations to get right. You know, there there are going to be learnings along the way with each version and that learning compounds that knowledge compounds over time. And so really, really great product teams have designers that have that institutional knowledge those insights are live with them. And it's not like you start a project you finish and then you forget everything that you just did the Result positive or negative stick with you and you kind of you want to build on those learnings over time. So I'd say really being thoughtful about hiring designers is important because sometimes it's completely appropriate to have a contractor do something when the project scope, the project brief is very clear. And the outcome is, you know, it just needs to get done. All right. But early stage startups are oftentimes about building something brand new to the world where the answers are definitely not clear that they're not if the solutions were cleared out, we would already be done. So thinking about the relationship differently, thinking about an iterative cycle, you know, product cycles happen over and over. And you need to understand that the knowledge shouldn't just be kept in a document or relied on just the product manager to understand it, or just the engineer to have that institutional knowledge. The designer can be proactive and be problem seeking, as well as problem solving.
Well, that brings us to another audience question, which is what? How early should should a company bring on like an in house designer? And it sounds like you're saying like, Yeah, do that, like you should? That shouldn't be part of your founding team? Am I hearing you right there? I
think so. I mean, I, I definitely think early stage companies need like a builder, for sure. And somebody that knows how to articulate and sell the value proposition. And I would add that designers can, can help with both of those things they can build and they can sell. So yes, I think the earlier that you can bring on a designer, the better but you want to bring on the right kind of designer, if you're going to engage with them in this partnership type relationship. If it's just about, you know, making some marketing material that you need done, then probably design as a service makes a lot of sense. But my recommendation for first early hires at early stage startups is to think about hiring generalists rather than specialists. generalists? Will, you know, they will, they're probably more likely to be problem seeking, and problem solving than just problem solving.
Yeah, that was another question that we had was like, What What should a founder look for? Right? So you're building out a team who, you know, you know, maybe you're a technical founder, or maybe you've hired that, you know, co founder CTO position. And next step is who's going to design the thing, like, you know, a generalist is, is a good step one, but what else should founders be looking for? When they're hiring, you know, that first kind of lead designer to bring the product to market?
two qualities that I always look for are curiosity, and humility. Curiosity is really important. Because, you know, usually, the designer is not going to be the subject matter expert in the particular thing that you're the product or service that you're building. But their curiosity will help your audience translate will help translate to the audience. What is it that you're trying to get across? A lot of times, you know, when I'm working with teams, I'm trying to understand the problem, as well as the the person that's kind of defining it, and even challenging the definition of that problem. So that we can get to a shared understanding of what that problem is, and then design solutions against that. And that dialogue is really important that dialogue requires that kind of curiosity, the humility, part of it is important, because, you know, it's unlikely that the first version again of anything is going to be perfect, the first version of the bicycle probably wasn't perfect. And still, to this day, there are many, many iterations of the bicycle to try to perfect it for a specific context. So you know, there are very few in kind of professions where you're probably going to throw away 90% of your work, or more. And designers are that profession, like, we're always kind of pumping things out, trying, you know, for ourselves in our own personal iterations, and for our teams and things that we ship, and release on cycles. So I try to look for folks that have both of those qualities of curiosity and humility.
Yeah, I love that. So all hanro from the audience asked what is more important, pleasing the client or designing something you feel is more effective?
I guess that's, I would say that's a false dichotomy. You want to you want to do both? Always? As much as you can. I feel like, you know, certainly, you know, I've been in experiences where it's just like, it's impossible to please a client, maybe it's the wrong match between the client and the designer. But I think pleasing the client is not actually the goal, understanding the end user is actually the most important thing. So, you know, clients oftentimes, maybe try to represent their idea of what the user is, but their understanding may be only clouded or partial, it may not be a full, true understanding. So I think it's not just one or the other. And you, you definitely want to, I think work. When you when you put your work out there it is a representation of your belief in quality. You know, when you design the right thing and design the thing, right? You're thinking about solving the right problem, but also doing it in a way where it is the best possible version that you can come up with at that with it, given the constraints, given the time constraints, given the budget constraints, etc. But I think it's a it's a yes. And not at all.
Yeah. 100%. Another question is, how should founders talk to designers about what they want? So whether it's a third party service, or it's, you know, found the one who has all those qualities you listed out, you're going to come in house and be my designer? For for a founder or CEO who's leading the company and kind of leading product vision that doesn't necessarily have a design background? Those conversations can be a little bit tricky, right? Like, I know, I want it to look away, but I don't know how to use the correct the correct words to articulate what I want. Yeah, it can be a really difficult on both sides of the conversation, for sure. really frustrating for sure. I
think, you know, I'm, I'm a student and believer in Human Centered Design. And you know, a quick refresher on that, if, if people aren't familiar is that Human Centered Design is sort of the overlap of user needs, business viability, and technical feasibility. And all three of those are necessary in sort of a balanced equation and balanced decision making. But where human centered design has a point of view is that everything starts with user needs first. Because if a user doesn't need it, if there is not solving some problem for a user, it doesn't matter what the technology is, or what the prospective market may be. Because at the end of the day, it's a person that's using the service or product. So if you can articulate clearly who that ideal user is, and what they not only, like, kind of like, what are they saying? Or what are they doing? But how are they thinking? And how are they feeling? And how do we touch on those more soft, hard to measure things? But if you can get to an agreement on that user persona, or that user profile, then you can start to evaluate objectively, are we solving this problem in a way that makes their life easier, better? You know, you know, using Pinterest as an example, are we giving them inspiring content? Are we inspiring them? How do we know? How, what are they engaging with? Those? Those questions can be answered more clearly with data. But the the root question is like, what are we trying to accomplish in the first place? and for whom are we trying to accomplish it for? So I think having conversations starting at that level, everybody can speak at that level. And then when you start to evaluate the design work, you can start to benchmark it against those kind of core things that you already agree on and have a shared understanding about.
Jeff, from the audience asked, should designers have coding or develop developer skills for early stage startups looking for broad talent and initial hires, what should good designers also be able to do?
I think coding has become more and more a, an important part of a designer's toolset. I don't think it's required for all disciplines in design, for example, brand design probably doesn't need to have a lot of coding experience. But when it comes to software, the reason that coding may become more and more important it is becoming more important is because it closes the gap between intention, and what actually gets shipped. Oftentimes, there's this handoff between the, you know, the flat files or design mockups, and then what actually gets built. And some things like transitions or animations end up getting cut out, because there's not enough time or maybe the engineer doesn't want to figure out like, What is it? What are the Bezier curves that we need to do this motion easing properly. So as you want to have your design intent, match, what actually gets shipped, coding oftentimes can be a way to close that gap. So I think it's, it will become increasingly common and important, but tools that are out there allow for a better expression of what the final outcome intends to be. And hopefully, you know, on one end designers learning how to code can close that gap. And on the other end tools getting better at translating. What designers want to do into something that's understandable to engineers can close that gap as well. So I think we're in this interesting period where they're both kind of moving to close that gap. And it can, it can always help. It can't hurt necessarily, but I wouldn't say it's a requirement for every discipline, but certainly for digital product design. It can it can certainly be a benefit.
So I was talking with Mike Bernal from Sequoia earlier today. And we were talking about feedback loops, and tempo essentially when it comes to product iteration. And I was wondering like, what what does that look like for a designer? Right? Is that the same? Is that all the same? Like, we're just looking and listening to what users say? Or are there other kind of feedback loops that designers can build into? You know, their flow and their process?
I think that's a great question. cadence is super important in any kind of technical NATO technology product, and a lot of times that cadence is built on the release cycle, right? You you have, you know, either a monthly or bi weekly or weekly release cycle. And you want to make sure that you're able to, you know, make the most of that release cycle by shipping some experiments that help you learn. And I think that's a, that's a great practice to get into. However, it can also turn into a bit of a reactive hamster wheel. You're only looking at user data to help you make decisions, which I've seen happen time and time again. But if you take a step back from that, obviously, very important cadence. There's also the vision, like what are you iterating towards is a really important question to ask periodically. And regularly. An analogy that I have often used is, you need a compass, and you need a steering wheel, the compass tells you the compass is your vision, right? It's like, our, here's what we're trying to achieve long term. And are we headed in that direction, generally, we should always be checking, you're not looking at your compass 100% of the time. But you sort of want to know that you're headed, you know, north. On the other side of that, you need a steering wheel, you need to navigate the obstacles that are in front of you, in the kind of immediate short term timeframe. But what's really important is the relationship between those two, like, are the moves that we're making today, in the short term, setting us up for future success at arriving at this vision that we have? Or is it that, you know, we've been driving for 500 miles navigating all these different obstacles, but when we take a look at our vision, where we're, you know, 500 miles away from where we intend to be. So I think keeping those two timeframes in mind, the short term, stuff really matters. But also taking a step back and looking at the bigger picture looking at where is our compass pointed? Are we headed in that direction?
Yeah, another question that we have here is kind of like re iterating it, I think, and trying to get the the concept across. But you know, in oversimplified worlds, you have this founder, we're talking about super early stage, you have this founder, who came up with this idea, you know, has kind of like the wireframes gone, and it's ready to start building has figured out the market, you have the either CTO or that is also the founder, who's coding it all together. And then you have this designer, like, where should they sit at the table? Because you hear a lot of these design companies talking about, like designers finally have a seat at the table, or they have more seats at the table, right? Like they're, they should have equal say, and kind of prioritize saying what's going on at an early stage startup? How should founders think about, you know, their designer, in terms of giving feedback on maybe things outside of just design?
Sure. Yeah. I mean, I think a really great articulation of this is a T shaped person, the T, the depth of the tea is their specialization, so maybe the founders depth is product, or business, and maybe the CTO, their their depth is in, you know, obviously, technology, for designers, hopefully, their depth is in understanding or advocating for the needs of users. And that's all those depths are really important. And, of course, what's also important is the breadth of that tea, the empathy for other disciplines. So, you know, typically, what I'll see is that there are a product manager, designer engineer working together, and they all have empathy for each other's discipline. And it goes back to that that point about curiosity, like, do I care about how this is built? from a technology standpoint? Do I care about the business that we're trying to build? And do I care about the problem that we're trying to solve the value that we're trying to create for users, and that tripod requires all three legs, so you can specialize have that that depth in one area, but it's important that when you collaborate, you're also speaking the language of your your cross functional partners. So when I you know, when people say there's a seat at the table, that's great. But it doesn't mean that one seat dominates the others, it means that you're looking for a better balance than what currently exists if you have a great technologist. Then a product person, but they're not neither of them are advocating for a great user experience, then I'm fairly certain that the end result is not going to be great. No matter how great the technology happens to be, it might be a solution in search of a problem.
Okay, so then our last question I think that we have time for comes from Shang. And they asked, Where do you think the biggest collaboration gaps exist between designers and non designers?
Well, that's a really interesting one. I think maybe kind of, to my previous point about this, this breadth, the tea, I think it behooves designers to understand technology and business more, as much as it be who's a technologist to understand design user needs more as well. So those gaps exist. You know, when you're at a small stage startup, what's great about being together in a, in a small, intimate setting, is that everyone sort of knows what's going on. And there's kind of like ambient communication, because the vision is so, so ambitious, and there's so much to be done. But everybody's working hard. I think what happens as teams start to grow and get bigger and bigger is there's this, like, naturally, there's a division of labor that happens for operational efficiency, teams will splinter off, I'm gonna work on this feature, this team's going to work on this feature. And the gaps end up growing that way, you know, as a natural side effect of, you know, division of labor. So the gaps, I think, are, are not just sort of like between disciplines, which are important to pay attention to, and kind of using that, that T shaped to think about depth and empathy are important. But also, when you think about scale, how do you make sure that the teams are in sync and thinking holistically as what's good for the users at large, the company at large? And again, kind of, you know, are we headed in that, that direction of the compass in the long term? And are we using the steering wheel? Are we steering in the same direction as a company in the short term?
Awesome. Well, this has been fantastic, Scott, I really appreciate you taking the time to hang out with us. It's been a pleasure.
Thank you so much. Thank you. Thank you. And if anybody has additional questions, hit me up on Twitter. I'm not super active. But I think post this talk maybe I'll get some questions that I can indulge. Awesome. Thank
you and my camera overheats. So we're right on time right on time. Thanks so much.