Loading summary
Transcript69 lines
- [00:00]
Rid
You ended up hiring two people out of like a thousand applicants. Are there other behaviors or traits or just things that they even did in those later stage conversations that helped you get to the point where you're like, yeah, that's the person that we should make an offer to, doing everything you.
- [00:14]
Dan Weiner
Can to not end up in a really narrow role. Then people start to think of you as somebody who delivers knowledge, not just delivering prototypes.
- [00:22]
Rid
Difference in output between a figma file that is groups and rectangles and hex codes versus auto layout and variables is night and day, and the former is completely unusable.
- [00:33]
Dan Weiner
We were thinking, okay, design system, it's how designers and engineers talk to each other. But now what I'm saying is design system is how designers and cursor talk to each other, and that's a whole different paradigm.
- [00:44]
Rid
Welcome to Dive Club. My name is Rid, and this is where designers never stop learning. This week's episode is with Dan Weiner, who's the director of product design at Kit, which I've used for years to power my email. But he's also a top maven instructor, where he helps designers move from pixel pushers to strategic partners. So we're going to do a deep dive into all of the ways that you can advance your career in the age of AI. And I want to start by talking about Dan's recent experience with hiring, because he brought on two designers out of over a thousand applicants. So let's begin by hearing what Dan's looking for first.
- [01:25]
Dan Weiner
The honest truth of this, which designers hate to hear, is the initial stage is really just visual design. And it's not that the candidate that I hire is being hired for their visual design. It's that all the people that were rejected in the first stage were rejected for that. And I will not read through a case study or really, like, spend much time on their portfolio. If I see basic things that are off around white space, not being able to create visual hierarchy through typography, colors used in random ways. So it'll be just be those, like, fundamentals of visual design that you. That you learn. If you've ever done graphic design lessons, it's the basics, it's spacing, it's how to use white space, it's typography, it's use of color. And if those seem okay, then I will go in and start to actually read case studies and see if they have relevant experience. And so many candidates are just rejected straight away by that initial glance at their visual design. And I see all these posts online where people are like, this is terrible. You're hiring people just based on graphic design skills. Like, all you want is pixel pushers and things like that. And it's like, no. We then have a series of other criteria that people go through. But visual design skills is a requisite for getting the role. Like, it's one of the requisites. It's one of the skills that I have, one of the eight skills in the skill matrix for the designer. So I may as well just make sure they have it first, because I can, I can check that out literally in five seconds. So I may as well do that first. It doesn't mean they're getting hired for that, but, you know, it is one of the requisite skills for the product designers that I hire. And I, I have never hired for a design role where we separate out, let's say, the more kind of like traditional UX design from visual design.
- [03:15]
Rid
I love that because you're right. So many people point at that behavior from a hiring manager and say, oh, well, they don't want a UX designer, they just want a visual designer. And you're just saying, no. That's just the only thing that I can get a signal from in about six seconds. And so you can't succeed, but you can fail in those six seconds.
- [03:34]
Dan Weiner
Yeah, it's like when you do your driving test, you do the theory first. At least here it's like you have to pass the theory first, then you can do the driving test. It doesn't mean that you're only getting your license because of the theory. You just got to get through that. And it's the same with visual design. And I think the advice that people are giving on LinkedIn is just really harmful to designers in general that are looking for work, because basically, make your portfolio have the visual design level of the companies that you aspire to work at. Look at those companies that you aspire to work at. Does your portfolio reflect the same kind of care to UI design? And if it doesn't, and if you've been working on, like, really outdated enterprise software, redesign those screens, you know, just redesign them all. Nobody's going to check. And even if they did check, they'd be like, oh, wow, that's so cool. Like, the real project looks terrible, but if you had the freedom to design it the way you wanted, you would have made it look so much better. So, you know, I wouldn't care at all that somebody redesigned all of the screens of this kind of, like, outdated software they work on, which is the main pushback I get, which is, you know, but you know, the app I work on looks terrible.
- [04:40]
Rid
I love that. I've never heard somebody share the device, but you're right, I'm even putting myself in the hiring manager's shoes. And if I realized the discrepancy and asked about it and they were like, actually, I just made it better, I'd be like, that's great. Do you want to talk more?
- [04:55]
Dan Weiner
Yeah. Because we have screens at Kit, which some of them left behind. You know, we did a rebrand. Some of the screens are great, some have been left behind. So somebody that can take an old screen that's looking a bit outdated and give it a refresh and show off the UI design skills, then for me, that's amazing. And I think the other misconception is that it's just, well then that's just vibes, you know. Well, you know, what you think look good, looks good isn't what other people think looks good. So now it's just completely subjective. Which when people point that out, it shows me that you have absolutely no understanding of visual design. Like you don't understand using color for consistent prompts. So you know you've used green for success, but you've also used green for something completely unrelated. You've used like a confusing array of colors. So now I can't see what the primary action is on the page. You haven't used any system for spacing. So spacing within a component is the same as spacing between components, things like that. There's no scale with typography. So like a section header here is the same size as a section header over here, but this section is inside a component, this one's outside it, you know what I mean? So they like all of this is very systematic.
- [06:06]
Rid
Real quick message and then we can jump back into it. By now you probably know how much I love granola, so I'm going to toss it to one of my favorite designers, James McDonnell, to share his experience. He says granola is one of the best AI tools out there and the fact that it takes notes during calls and meetings and stores them for later is genuinely life changing. And I couldn't agree more. I simply cannot imagine life without granola at this point. So if you're a designer, you shouldn't be having a conversation about your work without running granola. And they're offering three months free for you and anyone on your team. All you have to do is go to Dive Club Granola. If you're a student, then I have some pretty Incredible news. Lovable is offering you 50% off their pro plan. This is easily one of the most impactful products that I've used in the last year and I was literally just creating a prototype before recording this, so I cannot recommend the product enough. You can build incredible apps, websites and prototypes in minutes just by chatting with AI. And if you use the code Dive Club in the next 30 days, you can get even more of a discount. So if you want to try it out, then head to Dive club slash students to get the special offer. Okay, now on to the episode. Let's keep going. In the skill matrix a little bit, what are some of the next skills that you're then looking for earlier in the process when you're evaluating candidates?
- [07:32]
Dan Weiner
I have eight skills, which is really very small. So I've worked at a lot of companies where I've been in charge of putting together the skill matrix because of the writing I do online. I think people, when they hire me, they're like, oh, you can do our skill matrix and growth progressions for designers. Because it's stuff that I'm interested and I write about. So I have research, end to end process, interaction, design, UI design, writing, design system and collaboration and influence. And it's not that each stage tests like a different part of that skill matrix, but at some point we will hopefully have tested all of them. And the next stage that we do is a project presentation. And what I like to do is get people to do a little short loom video of a project they're really proud of and then we'll discuss it in real time. But we'll use a meeting for a conversation so that people are not like practicing their presenting skills in real time, which is very like nerve wracking and also kind of a waste of time for the people doing the interview where you know, they're being presented to and instead they could watch the video, prepare their questions and then ask those questions and also really encourage people to get questions ready before the interview. So we can even send those questions to the candidate. They can have time to think about what they're going to be asked and then we can do follow up questions and they're not like put on the spot and in that project presentation a lot of that will be understanding that end to end process part. And it's also maybe a time when they can jump into Figma as well and then maybe there's some interactions they can show us and they can show us if they contributed to the design system, stuff like that. So it does check off a few more of those kind of elements of the skill matrix as well.
- [09:14]
Rid
Writing stood out to me when you say that is it more copywriting? Like, are you making that evaluation based off of a portfolio or is it more, hey, we're doing internal product strategy documents. Talk to me a little bit about that skill in particular and what you're looking for.
- [09:27]
Dan Weiner
Yeah, so that is more their ability to do sort of UX writing, to write copy as part of the interface. And that would be in that, hopefully in that project presentation or on the portfolio, we'll be able to assess that. It's difficult because sometimes they will be working with a copywriter. And at small startups you don't have that privilege, you know, to have somebody that's by your side helping you with copy. So that's a little bit of a tougher one to judge. And it's really not. It would be the least kind of deal breaker of all of them.
- [10:00]
Rid
Yeah, it makes sense. If you're at a small startup though, you can make really beautiful UIs and totally mess up the design with that copy. Like, I feel that every single day I'm writing so much copy and I'm like, oh my gosh, is this good? I really actually don't know.
- [10:13]
Dan Weiner
And I do think that how you write is some sort of reflection of how you think. And it's not the case for everybody. Some people are doing this in their second language. Some people are dyslexic. And it doesn't mean they're going to be any worse at designing, but up to a point, it is a reflection of how you think, is how, you know, concise. You can, you can make your copy, your ability to distill complex ideas into the kind of simplest form.
- [10:38]
Rid
So you ended up hiring two people out of like a thousand applicants. So I kind of want to dig just a little bit deeper. Are there other behaviors or traits or just things that they even did in those later stage conversations that helped you get to the point where you're like, yeah, that's the person that we should make an offer to.
- [10:55]
Dan Weiner
So talking about this is a little bit uncomfortable because the things that I do are the things that you will hear so many people writing about and online and saying, like, what is wrong with design leaders? Why can't they figure out, you know, the right hire without making people jump through those hoops? But if you look at like hiring best practice, not for design, just hiring best practice, one of the key things is to make the interview as close to the actual role as Possible. So, you know, imagine this was a completely different profession and you could just get somebody to help you, I don't know, build a house with you and see how they do, and then just give them a day rate, you know, regardless of whether they do well or not. That's kind of what I. What I want to do with the hiring process is the final stage is we get somebody to work with us for a week. So they're in Slack, they're getting paid. We don't expect them to do like a full week's worth of work, but we expect them to ask questions in Slack. We expect them to tackle a challenge that we're facing that there's still a lot of ambiguity around that we haven't got solved ourselves. Because I think if you feel like you've solved it, then there's a lot of bias there where you're just like, let's see if this person comes up with the solution that we've already got.
- [12:07]
Rid
Yeah, I agree.
- [12:08]
Dan Weiner
And you're not open to, you know, really like, new ideas. So a problem that you might have some ideas around, but you haven't. You don't think it's fully solved. And so that's what we try to do. And, you know, we expect a prototype at the end of the week, but we also expect communication. We expect questions about, do you. Do you have any of this sort of data? You know, what. What is the importance of this? You know, how important is this problem to your customers? And all sorts of questions that we could help that would help evaluate how this person thinks, how they communicate asynchronously, they share their work with us. We get to look at it, we get to ask questions in Slack that we expect them to answer in the call. And so it's very much like a realistic representation of what it would be like to work at Kit, because they get to work in a Slack channel with a pm, with a designer, with me. I think it's very realistic, but it is a really, really tough process. But I also think these jobs are amazing if you can get them. These are amazing jobs to have. I've done a lot of really terrible jobs, and this is an amazing job. You get paid to be at home and work on fun stuff, and you get paid well. So I think it kind of makes sense that it's difficult.
- [13:20]
Rid
I want to return to the ugly enterprise screen example because it's one of two main pushbacks or questions that I see come up a lot. The other one being, well, I know hiring managers want to see business impact and how I'm driving business outcomes, but I simply don't have that data and I'm not able to quantifiably tie my work to some end result. Any advice for someone who feels a little bit trapped in that scenario?
- [13:49]
Dan Weiner
I want to see an understanding of what data you didn't have and what you think that this could have driven if you had had the data and how you would have measured it. So I think it's a little bit of a cop out to just be like, well, I didn't have any data, so I just don't even think about this stuff. For me and this is something I teach in my course. First of all, you think that you want to design for some sort of emotion, right? This should be fun, this should be simple, this should be empowering. And then you would expect that if, if somebody feels that emotion, then they will do some sort of action. So if you're going through onboarding and it's super simple, there's like loads of great defaults and all you got to do is just click next or like using a typed form, it's really easy to use the keyboard and just keep going using the keyboard. So what's the action? The action is that you just fill in more fields. So I want designers to think, okay, there's this emotion that will lead to more of this action. Those actions in aggregate would lead to a product metric. So let's say onboarding. It would lead to like onboarding completion rate. What would that lead to beyond onboarding Completion rate would be maybe an activation rate. Maybe it'd be like new mrr because at the end they, they reach like, they reach the end of onboarding, they reach their trial, they go through their trial, they use a feature, they, they start paying. And so that would be ultimately like the business goal would be contributing to New. Mr. If you can explain where your work fits in that scenario. But say, but I don't know the exact impact because I didn't have the data. I know that that designer with the data or with the being empowered to talk to the right people to get the data, to advocate for the data would then make use of that data. But a designer who has the data but has no real understanding of where their work fits into the bigger picture, even if they had data, it wouldn't really matter because they wouldn't be using it. They wouldn't understand how it helps their work anyway.
- [15:49]
Rid
Yeah, that's cool. I guess it is tied back to what you were saying earlier where maybe my High level takeaway is that as designers, we should feel a little bit more freedom to extrapolate and play out scenarios that are completely fictional as a way to just demonstrate how we think.
- [16:07]
Dan Weiner
Yeah. So the question is, imagine if you had the data, like, imagine you had all the data in the world, what data would you want tell that story? Like, you know, unfortunately we didn't have heat maps, but I would have loved to have known how many more people clicked on this after the redesign. And if more people had done that, then that would have led to X. Yeah, exactly.
- [16:27]
Rid
And you could even do like different scenarios then at that point where it's like, this is the variable that I would have really loved to see. If it was below my threshold, maybe that would have led me in this direction. If it was above my threshold, then maybe that would have led me in this direction.
- [16:39]
Dan Weiner
Those kind of designers, what you'll find is probably if they're a company long enough. And not all companies, some companies are completely different and they're just, it's just like a closed wall you can't penetrate. But if you have a designer, that sort of company, and they really care and they're really interested, a lot of those people will have figured out how to get the data. You know, they would have, like, they won't shut up about it, they'll advocate for it. And then they have the data in their case studies because they advocated for it. So a lot of times it's also, you didn't have the data because you never wanted the data and you never talked about it, were never the person advocating for it.
- [17:12]
Rid
Okay, I'm going to use that as a segue into strategy and influence inside of your team, because I know that's something that you think a lot about. So maybe we could start kind of high level. What do you believe about where the industry is headed that's impacting the way that you're thinking about and teaching these topics?
- [17:30]
Dan Weiner
Something that was true when I started to write about this is often the job satisfaction of designers is completely ruined by finding out that their role is really, really narrow. And so they thought the role was kind of like a detective. You know, you like go off, you investigate problems, you look for leads, you figure out, oh, maybe we could do this and it would lead to that. And then they find out, actually the role is like the PM is just saying it just gives them like a PRD and they do design and they give it to the developer and they're just kind of like stuck in this very narrow role between the, the PM and the developer. And that I think has always been true. And then now what I'm saying is that designers who are in that role, I think are really the ones most at risk of job replacement. Because if you have a really mature design system and you have PMs that are doing all of that and not really asking designers to get involved, or designers are not, you know, advocating to be involved with research or any sort of stakeholder alignment, anything like that, no discovery work, then as soon as the PM feels that they can create prototypes of sufficient quality that the developer can work from them and the design system is established enough, or they can just like grab something from Chad CN and theme it with their own theme, then I really worry about those kind of designers, like what role do they play if the only thing they were doing was kind of like following instructions to create a blueprint for developers.
- [19:05]
Rid
I see this a lot on Reddit right now where somebody will post onto the UX design subreddit and it's basically like, what do I do? My PM just cut me out. Like that's the story for a lot of people.
- [19:15]
Dan Weiner
I've been lucky enough to lead the PMs and designers at a company and it helped me understand what PMs think designers roles should be and why. Sometimes they're not getting designers involved in discovery. And mostly it was just like it's not that they wanted the control because for them it's just like a lot of extra work, a lot of responsibility. They're not able to look forwards and see what's coming next and really plan the roadmap and think strategically about what's the next big thing we can do, you know, in our squad. Instead they're really like in the weeds of figuring out like the, the problem space of this, of this feature. And they just think it's, the designers are too busy, you know, with all the screens they have to design. So it's, that's what I found. Mostly it was just a case of, well, designers are too busy, they don't like doing that stuff. They like being in Figma designing. And then designers are thinking, well, it's not, you know, it's PM's role. I don't want to step on their toes. And so I found like a complete communication mismatch as to why people, why PMs will be doing more of that. Designers wouldn't be doing it. And so how do you establish this relationship with the OPMs? How do you share discovery? How do you lead a part of discovery and I think it's, it's more important than ever. But more than just leading discovery, more than like becoming a strategic partner, the concept really is like widening your role, like just broadening it, doing everything you can to not end up in a really narrow role where you're not very technical and you're not very strategic. And really it's just like Figma prototypes is, is all you can do. What I'm saying is like, if you can be an expert at design systems. I don't think I took it as seriously. I always took it seriously, but I don't think I took it as seriously as I do now to see what a huge unlock for efficiency that is. So whether it's like, what changed? Just trying to get a Figma frame link into Cursor to generate a React component. I saw that all this stuff that designers have been talking about of the really more kind of niche technical aspects of design systems, where you keep your variables in sync with tailwind classes using design tokens, stuff like that, that was like, okay, I can see how that is efficient. But also at the same time, like, you know, getting a developer to just make sure that they have the right hex code, it's not such a big deal, right? Yeah, but then when you realize that actually you can just prompt Cursor to create this Figma component in React and its training data is your design system and it's going to mess up if everything isn't perfect. And one of those things that it can mess up on is not finding the right variable. So imagine you have a blue hex code, but it's brand primary, but it's also info alert or something is the same hex code and you just let Cursor figure out which tailwind class to apply. Apply, because you didn't apply any classes. It might apply the info banner to your primary stuff and then you, you know, you change that and everything is. It looks wrong. So that's a kind of technical skill that broadens your role. Being able to code is a technical skill. There's like strategic skills of being able to, let's say, facilitate workshops to get stakeholders aligned to analyze data. There's research skills to be great at talking to customers, not just great at talking to them, but confident to like set up calls and, you know, schedule like lots of outreach calls. All these skills that are just whatever is like not just you playing and figuring with your headphones on, like going beyond that is what I think designers have to really understand. You have to get out of the building and, you know, get uncomfortable and do some other stuff.
- [23:01]
Rid
There's like four follow up questions that you just sparked in my mind. So I'm going to put a mental pin in a few things. I want to come back to the cursor topic specifically, but I want to get ultra specific for a second and speak to the designer who does kind of feel trapped in execution mode, basically where they're not actively shaping product direction, they're not part of the discovery process. What can they do? Like they open up their computer, they're listening to this on Friday, they open up their laptop on a Monday morning. What are the very specific things that they should do to get some momentum to start moving upstream?
- [23:36]
Dan Weiner
One of the first steps that I recommend is to have a discovery process. So I have a discovery template that I share in my course and we walk through all the different questions. But basically the question is, first of all there's two stages. Like one is understanding the problem. So like the discovery stage, I call it. And then there's the defined stage where we start to think about the solution and to do all of this work in a way that you are making it cross functional so you're getting the input from your peers. That is something that you need to start getting involved with. Because when you start doing that, then you can share insights with your team. And then people start to think of you as somebody who delivers knowledge, not just delivering prototypes. And so that is a big change for people. Then it's like, okay, well you know, Dan is good at delivering prototypes, but he's also the person I'm going to turn to if I want to know a little bit more about onboarding. Like where's the onboarding data? Or what are some opportunities that he thinks that we have for improving onboarding, or how could we improve our trial to paid rate, you know, by improving our onboarding, they're going to come to you with those sort of questions and that is a little bit harder to replace. You know what I mean? Because now it's like you have some knowledge about strategy for an area of the product, but you can also be the person who can implement the work that needs to be done. And so that discovery template, it's basically, do you understand the problem from your customer's perspective? So like, what is the problem in the customer's words? And to do that, you know, you need to find sources, you can interview customers, but there might be existing interviews, there might be support chats, there might be sales calls, all kinds of things. But really describe it from the customer's perspective. There's how do we know it's a real problem? Like, what's the scale of this problem? Can you define that in some way? There's things like, what have we done before to solve this? Because often you'll find the startups, they're just kind of going around in circles trying to solve the same problem and they do it in the same way. Especially with people just staying like a couple of years, you will get entire teams just going around in circles doing the same things all the time. And so digging into the archives to try and figure out if we've done this kind of thing before, where would we find the data on it? Or who's been here longest in product or design or engineering that might know something about it. And also how you could do this in a way that's like that. You can kick it off asynchronously, make it cross functional, get people from all departments involved, and then wrap it up with a call where you go through some of the inputs that you've got, dig into them more with people that might have more context for you, and also turn it into an exercise of, okay, we've now got all of these assumptions. Because another part of the question is, what are the assumptions that we have, why this problem occurs? And then when you've filled out all of the questions on that whiteboard, which could take a long time if you don't have any research data, so you have to go and do the research. A lot of times organizations are sitting on loads of research data. It's just not being pulled out. Once you have all that data, then you can move on to thinking about how could we solve some of these issues. Also, how can we verify some of these assumptions we have of why the problem is happening? So then you get into like the solution space, coming up with hypotheses. Well, if we do X, then we should see more of Y. If you can lead that or do it in partnership with your pm, that completely changes the sort of role that you have.
- [27:01]
Rid
That was kind of my next question, which is a lot of the things that you're talking about do feel like they infringe a little bit on how I would traditionally think of the role of a product manager. And I don't know, I don't even really have a question. I guess it's just that tension is very real. But at the same time, you have all of these stories of PMs who are getting more into prototyping. And part of me is just interested to See where the dust settles and what lines do persist in between these two roles in the long run.
- [27:30]
Dan Weiner
We have a big project at the moment, and the PM really sold the importance of working on this area of the app. I think you're familiar with Kit. It's a huge app. Yeah. So many features. And so the PM really sold the idea that we need to improve this one aspect of the app and kind of created the vision of how improving this feeds into our creators getting more subscribers. And the success of our creators is our success. You know, we scale with subscribers with their subscriber size, our pricing scales with our subscriber size. So there was a work to be done to create that strategy doc, that vision to really sell it to the. To the company. And then that's when the product designer comes in, which is like, okay, well, we're going to improve that area of the product, but what is improving it mean? Like, what do our customers want? And so using that discovery template, I can get the designer to answer a bunch of questions and then we can see, do we have existing information about it? So in this case, it was part of it would be integrating AI. And so we don't have existing data. It's not like, a year ago, people were interviewing creators about how to use AI with this particular part of the app. And so, no, we don't have sufficient information to describe in their words, like, how they would want to use AI in this situation. So then we can see there's a gap there. We need to go off, we need to do the research. And there's another vision that has to be created, which is like the vision for this part of the app, this feature they already have, but like a 2.0 version of it. And so the PM has created the vision of why this is important in the ecosystem, like, why we need this feature to improve. But the design has to create the really, like, detailed vision of, like, this is how it will behave, like, this is what the interactions will be, this is the functionality that we'll have. And that that vision is based on talking to customers and that it also aligns with stakeholders on what they want the app to be. And so what I expect from the designers in that initial phase is that they're very confident about the direction we're moving in, and they're confident about it because it aligns with the value that it's supposed to give our creators, which, you know, also provides business value. So if we build this properly, it will help creators succeed in a way that we also can charge for. And it will scale, but it also does it in a way that addresses all of these customer problems that we know are true because we've surfaced them through that discovery phase.
- [29:57]
Rid
I would imagine there are probably multiple checkpoints on that journey to get the feedback you need, get the team aligned. What do those typically look like at Kit? And is there any behaviors or practices from the designers that you think are just crushing it, that you see that other people could learn from in terms of what it looks like to share some of the kernels of that vision as you're still kind of shaping it, and make sure that you're bringing people along for the ride?
- [30:27]
Dan Weiner
Yeah. One of the things that I've seen that is fundamental, especially in small startups where you often don't have dedicated UX researchers, is something that a great researcher will do is they will talk about insights that they've got from the research and how this could impact the design or how it could impact the, you know, whatever we build. And so what great designers do is they. They look for data, or they go out and get the data through interviews and then synthesize that data into an insight that affects the design that they're working on. And being able to communicate that, being able to, first of all, having the skill to be able to do it and then be able to communicate why the design is the way it is, based on what they learned, that it's kind of connecting the dots and it's also being able to communicate it is. Is really a huge skill that I see that makes designers successful.
- [31:17]
Rid
Is it happening live? Like, do you have regular design reviews, people doing this async? What's that look like?
- [31:23]
Dan Weiner
Yeah. So at Kit we have four squads, four product designers, and once a week we have a design review session. So it's rotating through the squads. So each designer will present once a month, which is not frequent enough that you wouldn't expect async updates as well the rest of the time. So there's a mix of presenting something in design review and then there's also the async updates, and then there's also all the squad rituals. So that design review, it's once a week, but it's really once a month where you present, that is, with myself, with our VPO product. And also ideally there'll be some members of the squad along as well. So like the PM for the squad and maybe some engineers that will be working on that will be present as well.
- [32:07]
Rid
Can we drill into the storytelling piece for a second? You've kind of Touched on that a few different ways. I kind of want to make it more of a personal experience question to start. So when you kind of reflect on your journey and you've been in these leadership roles across these different companies, you're at Kit now. What are some of the ways that you've personally evolved your approach to storytelling over the course of your career?
- [32:29]
Dan Weiner
It's an interesting one, storytelling, because I think it's such a confusing topic. So when you read online about storytelling, you can get really lost in the rabbit hole of like, there's, you know, Disney's guide to storytelling. Or like the build up, the climax, the crescendo, the, the, you know, like all of these, like storytelling themes that I find them super confusing as, like, how do I apply this to have this thing I'm working on? I either want to advocate for time and budget to work on it, or I've already worked on it. I want to show that it was impactful or I'm in an interview and I have a project presentation and I want to, you know, be able to tell the story of why, why this was a good, effective design. And so the storytelling that I teach, it's really just context, problem, solution and impact and those four stages. And in the design review session, it's also the exactly the same thing that I ask my product designers to present. And it's in the course I share a presentation that I've used to get my last role and I share the exact presentation just with like some numbers pixelated out.
- [33:37]
Rid
Hey, quick note, if you're enjoying this and you want to go deeper, Dan has a course on Maven that's all about going from pixel pusher to strategic partner, which I think is more important today than ever before. So if you're interested, I asked Dan if I could share a quick discount and he agreed. So if you head to dive club Dan, you'll get a hundred dollars off of his upcoming court. All right, now back to the episode.
- [34:02]
Dan Weiner
Context for an interview is really high level. You need to actually understand, like, what the company does context. In the design review, you can really get more into the weeds and jump straight into more detailed context. Like, what's the problem we're solving? This I think is really interesting because you need to be able to describe a problem from lots of different angles to make this effective. So you want the problem for the user, but you also want the problem for the business. If we don't solve this problem, then what happens? Why should we care about this problem? I like to think about that in at very different levels. So problem like with the interface, like this low contrast or confusing interface, that's a problem for the user because now they don't know where to click. They don't know how to move on to the next step. That's a problem for like our product metrics because we have a lower conversion rate and then that impacts the business because you know this and this revenue loss. Like so telling a problem should have multiple layers. It should be like an onion. You should be able to like start with like this very technical detail problem but you should be able to like unwrap that and it leads to like a problem for the, for the business. So problem is like a multifaceted thing and solution is the thing that we all want to just jump straight to as designers. Like you know, what did you actually do? And wrapped up in that is the process. And I think that process has like had its day now. And people are a little bit bored of talking about process. I think I tend to recommend to people just kind of skip over. Just like not skip over completely but show that you have a process but don't talk about it too much. Nobody really cares as long as it, the impact was good. A lot of people just the eyes closer glaze over when you talk about process. So high level process, the solution and then the impact that it had. And if you're advocating for something that you want to build something, then it's like the impact that you think it could have. Which is the same scenarios we talked about with people that don't have data. It's like the impact that you, that you hope it had but you don't know if it's true or not. But at least you have an idea of like what you're aiming for.
- [35:56]
Rid
I really like the onion analogy for problems because you're right. I could have numbers of drop off in a flow, I could have user quotes, I could have a little highlight of some kind of an interview I did. But all of that is just at the user problem level. And if I don't make the connection to how that impacts the higher order elements of the business and what we're trying to accomplish, I'm missing that's a big chunk. I'm missing a lot from making something that is compelling, especially to more of the key stakeholders.
- [36:28]
Dan Weiner
And I think people get really hung up on this. Like I did this design, I changed this screen, I'm never going to figure out how much money that made. And it doesn't matter. It's like as long as you understand, like there's a whole chain and as long as you kind of understand that chain and you can talk about it and you can communicate where your work fits in, that's great. That already puts you ahead of a lot of designers.
- [36:47]
Rid
It reminds me of a past episode. I'm trying to remember who said it, but they just asked the question basically like, can you explain what the most important business levers are for the company right now? Like, what are the very specific levers that you are trying to pull as a company to grow? It seems so simple. And yet at the same time, as soon as you get a little bit more specific, then make more money, have better profit margins, it's like, ah, what percentage of designers can answer those questions? Well, because those are the levers, everything that you're doing should be tying back to those.
- [37:15]
Dan Weiner
What's the churn rate? Like, does your company have an incredible churn rate once people sign up after the trial? If they do, then you know how much work you're putting into onboarding, what's that day one experience like? And you know, things like that is great for designers to understand. You don't need to be an expert in like accounting. You don't need to become incredibly fluent at reading like a profit and loss spreadsheet. But just some basic understanding of the company is like in a SaaS business anyway, you have your new MRR. You know, people, they go through onboarding, they sign up, either they have a trial or it's just through like feature led. You have your retention. You know, are people sticking around? Do they keep paying you? If so, like, what do they keep paying you for? And then you have your expansion, like, how do you get an existing customer to pay you more? It's really those three categories that designers have to be aware of. And then just like figure out where does your work fit into those three categories. It sounds silly, but if you do, like if you know which one of those three your project fits into, you're already ahead of a lot of designers. Like, already. Just like, if you don't know, just ask and figure it out. And asking those questions will help. This is something that I encourage designers a lot to think about is just asking questions about where your work fits into the broader context. The information that you find out is important, but figuring out who to ask that question to, making those bridges, asking the questions, building those connections, being seen as the person that's actually interested in that stuff, that is already a big part of the work you need to do to grow your Career, which is, which is weird because, like, we haven't even talked about getting the answer or doing anything with the information yet. It's literally just the act of, of reaching out and starting those conversations is already a catalyst for your career growth.
- [39:05]
Rid
I'm a big believer in the power of video to explain my thinking as a designer. So when it's time to get feedback, I'll drop a loom link and slack and another link to a Figma prototype and feedback will be scattered everywhere. And I mean, it's a mess. So I'm building the product that I've always wanted to exist, and it's called Inflight. You can kind of think of it like an Async crit. It's an easy way to share a video walkthrough along with an interactive prototype or whatever you're designing, and then AI interviews the people on your team to get you the feedback that you need and organizes everything for you in a beautiful insights page. So right now I'm only giving access to Dive Club listeners. So if you want to be one of the first to use Inflight, head to Dive club, slash inflight to claim your spot. There's this tension that I feel a little bit where in order to you have that path be recognized, you gotta kind of talk about the impact. And it almost feels like I have to shine a flashlight on my own work, which it feels uncomfortable, you know, like there's this tension between, well, if I don't do anything, the reality is I might not get credit and that's not going to advance my career as much as maybe I deserve or what I would hope for. And on the flip side of it is the last thing that I want to be is seen as somebody who's tooting my own horn on the team. How do you think about that tension? Where's that line that you think designers can shoot for?
- [40:29]
Dan Weiner
Yeah, I'm glad he brought it up because if you hadn't, then inevitably there will be people saying, well, you know, designers don't actually achieve any of this data. It's, you know, it's done with a whole team. And that's the key. It's like understanding what you and your team contributed to. So when I say like, what impact you had, it's, it's really the impact that you're, that you had on your team. And we just had a off site with kit. We had a manager's day and we talked about how we can measure metrics and metrics for individuals, metrics for teams, and for me My stance on this was that the metrics, like the measurable metrics for product designers, are the same as for the product managers and is the same basically for the squad. I wouldn't call it a failure if they don't hit those goals. I would only call it a failure if they didn't exhibit any of the behaviors that are conducive to reaching those goals on the squad. But if they've done all of those behaviors and we still didn't reach those metrics, then, you know, that's just the nature of working in a startup. Right. It's not. It's not a car factory. It's not like it's not very predictable. A lot of the stuff, a lot of the goals we set every quarter, we don't reach them for various reasons and it's super unpredictable. But understanding that this is really about the team's success, but at the same time, you have to investigate what went right, keep a journal of it, save it somewhere. Whether it's like a customer quote from a sales call or something like, I absolutely love this new feature. It's really helped me do X and Y. And you worked on that feature, you know, own that, own that. It's not like you're saying I was solely responsible for it, but hopefully, you know, as the product designer on the team, you know, there's some credit for you.
- [42:22]
Rid
I've definitely been in positions where I've remembered something that was said, or I'm like, oh, man, I'd love to build a point to that right now, and I don't have it. Yeah, like, it's such a practical thing that you can invest in as a designer is just being better at organizing the highlights.
- [42:35]
Dan Weiner
Absolutely. Like, just set a reminder after something has shipped, set a reminder to go and check the data, talk to salespeople, talk to product support. Depending what kind of app it is that you might have, like app reviews, you might have Facebook groups that. Where people are chatting about. You know, there might be. I was going to say there might be Reddit, but that will all be. They'll be all completely negative. But, you know, there's like all sorts of places where you can. Where you can look for positive feedback. If you are building a portfolio, it is so powerful to have just like in research in showing impact, having quant and qual metrics. So if you have customer quotes and you also have some data, like that combination for hiring managers that are looking at your portfolio, like, that is such an amazing combination. If you can have both.
- [43:26]
Rid
Yeah, I really don't see very many customer quotes in portfolio projects either. Like, yeah, that could be one of the main things that you would lead with. And I can't even remember seeing that before.
- [43:37]
Dan Weiner
Yeah, which is a shame because everybody has got it drilled into them that for research data, you know, you want to have excerpts from an interview and you also want to have like data of like, why, how you know, it's a real problem. But when you are figuring out like, did people like this, like, knowing what they say about it is. It's amazing. Like, it's amazing if you can put that.
- [43:59]
Rid
So often I feel like we take the writing of a portfolio and we put it into this, its own category. But like if you were making a website to sell some kind of a product, you would put testimonials whenever possible. You would have the customer explaining an idea on your behalf rather than you having to say it. Because it's always more impactful, it's always more compelling. And yet how often do we do that when we're talking about our own work? Yeah, I almost never see it.
- [44:24]
Dan Weiner
Sometimes you have it about working with that designer, but yeah, never about like the work that they shipped, which, you know, as, you know, I just credit.
- [44:32]
Rid
All those anyway, they just feel like LinkedIn endorsements, you know, they just feel like, oh, they, they made you say that. They just felt bad they had to say that, you know, for sure.
- [44:39]
Dan Weiner
But you know, from your course, like your, your course, my course, it's, it's our product and we get people to put testimonials on the course page of what they think about the product. And so the products you design, if you can get that for the products you design, then that's an amazing thing. And so I always say to designers as well, like, if you are talking to customers about the next thing that you're working on, ask them about the thing that you already worked on, you know, like, see what they think about that. Then it'll be an opportunity to think about the impact it had, whether there's ways to iterate on it. But if there is a quote from that conversation, you know, save that. You know, have a project file, save it with all the, like the screenshots or like working files, research data. And then if you can add a customer quote to that on like what people are actually saying about it, then that's, that's gold. Just having that project file saved somewhere as well on your computer, you know, in your own personal space as well, I think is something that I know that I didn't always take it seriously. I started to like, like most people, I took it seriously. When you leave a job and you don't have access to it, same take that seriously and then add, you know, add impact data to that project file.
- [45:49]
Rid
I think I'm going to take a hard left. And you mentioned the retreat that you were on. You also mentioned to me that one of your personal projects for that retreat was trying to set up a bit of a figma to cursor workflow. So I put the mental pin in it from, you know, the 20 minute mark or wherever we're at in this conversation. I want to come all the way back into it now. So can you tell me a little bit about what that process was like for you and also some of the goals. What were you even trying to accomplish for the team?
- [46:16]
Dan Weiner
Yeah. So I'll go way back to when I started designing. When I started designing, I basically did design and code from the beginning. When I started designing, it was in Photoshop. So I'm pretty old. There was no interaction in Photoshop. You couldn't design an interaction. Like you could create a, you know, you create a button, you could create the hover state of the button, but it's basically just two PNGs. You don't really know if that hover state makes any sense. Right. So for me there's like how a design looks, but there's also how it feels, you know, like the animation, like how a dropdown opens, how a modal opens, what the button feels like when you hover it, when you press it. None of that was possible in Photoshop. I don't know. And a lot of designers probably don't realize how amazing it is that you can do that in Figma, like not leave the tool to do it. So for me, Photoshop was the first bit of the design and Photoshop was really more just to get like buy in directionally from stakeholders. The design then moved to HTML and css. And I think the amazing thing about that era is that you really had a lot of control over exactly what got shipped to customers. So I started off doing websites for small businesses locally and then product design. And as far back as around 2011, 2012, I was doing what we called back then style guide driven development. And it's basically it's like a design system. But I would have a page, the app that I was working would have a page called slash style guide and then every component in designs would be on that page. So it would just be like one long HTML page. You'd have to like do control F to find the thing that you're looking for. And it would just be, you'd have to then like view source as a developer or like look at the file. Like it was not, wasn't documented or anything. It was just like, this is the HTML CSS for all of our components in one place. And as part of the design process I would just add all the stuff to that. Then there came a point where you couldn't hire designers who could do HTML and css. If you did, then you were really like narrowing the talent pool. Right. So it's like you were narrowing it down so much that now you had to like settle for designers that maybe weren't very good at visual design or didn't do research, but they did do code. You know what I mean? Like you always had to make this kind of compromise because it went out of fashion. So I stopped working with designers that could code. But there always seemed to be like this, this missing aspect to that where you're really relying on the attention to detail of the developers that you work with to actually care about implementing this certain like animation or this hover effect or whatever it is. And I don't know how many developers really like, if you set like a custom like animation effect, are they. How many are looking at that and thinking about it. You know what I mean?
- [49:10]
Rid
Like, you missed my custom easing curve.
- [49:13]
Dan Weiner
Yeah. And then I think a lot of developers just like, what is the point? Like, you know, you know what I mean? You can't get them to care about it as much as you do. And so now I think we're at the point where we can get a whole generation of develop of designers that don't need to go through all of that distraction of learning to code. Because I know for a lot of designers, like the role is so broad at the moment that to learn to code and especially in like modern day, front end is a huge mountain to climb. And it does mean distracting yourself from other stuff you could do. Like, you know, the stuff I teach on my course, which is also like a whole new skill area for some people. But I think that we're in this world now where the handoff for a designer could be a react component as well as the prototype and Figma. And that means that they could go to Storybook and they could really test out the responsive nature of it in a browser. They could check the hover state if it's a drop down, you know, they could see how quickly it opens and closes and you could Ask Cursor. Like, this dropdown feels a little slow. What is the timing on it? And Cursor can tell you it's at 0.4 seconds. And if you're in chat mode, which I recommend to begin with, you know, then you can be like, okay, no wonder, like, I had it in 0.25 in figma. And then you can switch to agent and you can get it to update it, and there's no reason why it wouldn't be exactly what you want. So when this. We're in this world where I think designers can get really, really like, detailed about this stuff on their own, make these super polished REACT components. So my thing for what we call Create Week at Kit was can I get a designer to generate a React component with, like, minimal or no knowledge of React? And it was fascinating. And I would say we succeeded in some ways, we failed in other ways. And the main learning for me was that this will fail to, like, the worst aspect of your design system. So all of the worst parts of your design system will be exposed. And that's like the level that it will fail to. And it gave me just like this really newfound respect for design system designers and, well, design system engineers and designers who have been talking about this kind of stuff, you know, for ages now, like design tokens and having consistent naming between figma and React and things like that that I think I knew more about in the REACT space because I did React development as an ic, I would turn all my designs into REACT components. So on the REACT side, I was totally sold on it. But on the figma side, I think I just kind of, like, didn't pay that much attention to it. I could just do something in FIGMA that looks fine and then I can just finish it off in React. But now I can see, like, having designers in figma that are really in tune with getting things in sync with the code, like using variables in FIGMA that actually correspond to tailwind classes, that is the training data for Cursor when it comes to building your components. And so the better that is, the better the output is going to be. And we're definitely in a world now where with the investment in the design system, and in some cases it might be in the expertise. So like hiring a design engineer, you can get to the point where engineers will not have to, like, create those rack components from scratch and they won't have to tweak them when there's a design change, but they'll probably have to do the work to, like, make them properly. Functional. And so I don't think it's taking work away from anybody, but I think it is adding this ability to like, really add, like, incredible level of detail and polish and. And getting designers to really own the thing that customers interact with. Which I think, for me, I think is really exciting.
- [52:56]
Rid
I love that phrase, like, you're owning the thing. There's like a level of accountability that comes with being the person that is making the specific elements that somebody's interacting with. Like, you can't point fingers when it's your design. That design just happens to be a react component. And the design system piece is so interesting too, because I have as good of a finger on the pulse of the industry as anyone probably, you know, like, I've had all these conversations, and so I kind of have my own trend lines of like, what's the narrative about different topics over the last. Whatever it is, 150 conversations. And there was a very clear trend line with design systems. Like, they were going down. You know, it was like guest after guest was getting on here basically like, yeah, we don't do a design system. It doesn't make sense. And it's like it came back from the grave like that meme. You know, all of a sudden people are realizing like, wow, this is actually really, really important. Like, the difference in output between a figma file that is groups and rectangles and hex codes versus auto layout and variables is night and day, and the former is completely unusable. And so even for myself, that's kind of. I'm trying to make time for it even over the next week. You know, we're early stage product, but if you can have just a little bit more structure, it's just this amplifier now for designers to be able to tinker in code where otherwise it's just a lot more work. You're doing everything from scratch.
- [54:22]
Dan Weiner
Yeah. And I think what we always understood is that design systems increase the efficiency between designers and engineers. You know, they allow them to communicate better. And that was always great, but sometimes, you know, it wasn't the biggest unlock for your company at that point in time. You know, we were thinking, okay, design system, it's how designers and engineers talk to each other. But now what I'm saying is design system is how designers and cursor talk to each other. And that's a whole different paradigm. Right. That's like, if designers can talk to cursor and get it to do what they want, that's that, you know, that efficiency unlock is wildly different.
- [55:00]
Rid
And even if it requires a dedicated role like that design systems engineer type person. Before it felt like, well, that's just bloat and unnecessary headcount. But if you can make the design team of even just five people that much more efficient, it's a pretty big deal. Changes how you think about Org and staffing for sure.
- [55:20]
Dan Weiner
And if I wasn't in the role I'm in and very happy with my role, the thing that I would be doing now is setting up a consultancy to be a design engineer to make cursor and designers like talk the same language. Because I think that a lot of companies would hire the person to set that up, but they might not necessarily be in totally invested in having that person as like a full time role that they need in, you know, in perpetuity. But to get that initial setup running to do all the work that's needed for the variables, for the tailwind classes, to write the documentation of how you need to approach components, because it needs to be a design engineer. Because on the engineering side there's a way that you should approach it as well. Where everything should be a component. Components should be made of components. Your smallest primitives should be components. The components shouldn't be too functional. They should be pretty simple. And so creating that whole balance, understanding Figma and React. I think that role, especially as a consultant, I think people doing that, I'm sure they already are killing it, but I think there's going to be room in the market for a lot more.
- [56:36]
Rid
I haven't seen it, I've seen a lot of design systems consultants, but it's definitely through the lens of you have a very big legacy system that's bloated and out of date. So step one is do the audit. And this framing would be completely different. It would, you could have messaging. That feels like, at least for me as the younger company owner that you're speaking directly to me was like, you need to unlock your designers now. Like you're, you're, you're spinning your wheels. You're not moving as quickly as you could be. Let me just build that little amplifier that would be pretty compelling.
- [57:10]
Dan Weiner
And I think the work is like 90% the same work. Now getting everything basically like in order is the same work. And then the last part is basically the instruction file for cursor or for whatever you're using. And you know, there's definitely, I'm no expert, I just spent a week on this. But there's definitely like some nuances to how this works. But I think spending a week on Something in AI world makes you an expert, right? That's what I mean. Yeah, that's what I know online. So like, I think it's pretty much the same work that it's always been. Maybe there's like more crossover between the design and the engineering, but there's like that instruction file as well and that like test cycle where you're generating components through prompts. But yeah, it's an exciting new space and I'm really hyped about it. I can't wait for us to get to that point where our designers are just spinning up storybook and then ensuring that they've identified the right component in chat that Kirsten knows what they're talking about and it's like, okay, great, change the background to this tailwind class, increase the delay on this blah, blah, blah, whatever it is. Yeah, I think, I think it'd be amazing.
- [58:18]
Rid
Well, Dan, I appreciate you sharing some of the hard earned expertise over a decade plus as well as the week long expertise. It's all appreciated and it's really cool. You give me a lot to think about. Like a lot that I'm immediately after hitting end on this. I'm going to jot down some notes because I think the way that you're seeing things and what you're focusing on is really, really interesting. So I definitely appreciate you coming on and taking the time to share it with us today.
- [58:43]
Dan Weiner
Oh, amazing. It's a pleasure. Like I said at the beginning, I'm really a big fan of the podcast, so it's an honor to be on.
- [58:49]
Rid
Before I let you go, I want to take just one minute to run you through my favorite products because I'm constantly asked what's in my stack. Framer is how I build websites. Genway is how I do research. Granola is how I take notes during crit. Jitter is how I animate my designs. Lovable is how I build my ideas in code. Mobin is how I find design inspiration. Paper is how I design like a creative. And Raycast is my shortcut every step of the way. Now, I've hand selected these companies so that I can do these episodes full time. So by far the number one way to support the show is to check them out. You can find the full list at Dive Club Partners.