Tyler White

The part of Nick’s story I keep coming back to is how normal it sounded. That’s what made it land. It wasn’t some dramatic designer origin story with a cinematic turning point and a perfectly timed mentor quote. It was a bunch of small career moments that slowly changed how he saw work. A school process that didn’t survive real timelines. A job that disappeared after an acquisition. A startup that ran out of funding. A consultancy role where the business model looked better than the actual fit. A developer community where being useful turned into paid work. None of it sounds rare. That’s the uncomfortable part. Most designers have some version of this. Maybe not the same path, but the same feeling. You do the work. You improve the craft. You try to be useful. Then eventually you realize the work is only one piece of the game. There is the work. Then there is everything around the work. Budget. Timing. Trust. Visibility. Risk. Business models. Who gets listened to. Who gets protected. Who gets cut. Who gets remembered when an opportunity shows up. I think that’s the overlap between Nick’s story and mine. He moved toward freelance because he wanted more ownership over his work, time, and income. I moved deeper into business impact because I got tired of watching design be treated like decoration after the important decisions were already made. Different response. Same irritation. At some point, you stop asking only how do I become a better designer? You start asking how do I make my judgment harder to ignore? That’s the thread I’m pulling on this week. Because the longer I do this, the more I think a designer’s career is shaped less by talent alone and more by how well they understand the room their talent is sitting in.

The thing I keep thinking about from Nick’s story is how many career decisions were shaped by things outside the design work. An acquisition. A startup running out of funding. A consultancy not having the right kind of design work. A manager taking a bet on him. A community of developers sending him paid work because he was useful before he was selling. None of that fits neatly into the way designers usually talk about career growth. We like to pretend the path is mostly craft. Get better at UX. Build a better portfolio. Improve your case studies. Learn better storytelling. Become more strategic. All useful, but there’s a whole second layer most designers don’t see until it hits them in the face. The business layer. Who has budget. Who trusts you. Who understands your value. Who is willing to take a bet on you. Who sees your work as revenue, risk reduction, or speed. Who sees you as a nice-to-have when the spreadsheet gets nervous. That layer decides more than designers want to admit. I’ve felt this inside teams too. You can do strong work and still watch it get watered down, delayed, ignored, or reframed by people who control the business context around it. Craft matters, obviously. But craft alone is a dangerous little comfort blanket. At some point, designers have to understand the room around the work. Because the screen is rarely where the real decision gets made.

I thought this episode was going to be about Nick’s freelance journey. It ended up being about something way more useful. How many times he had to learn that being good at design doesn’t automatically give you control. His first internship taught him that school timelines don’t survive contact with real work. His first job ended because of an acquisition. His second ended because the startup ran out of funding. A consultancy role taught him that billable hours can make you valuable on paper and still leave you feeling like you don’t quite fit. And somewhere in that mess, the freelance itch started to make a lot more sense. The thing I liked about this conversation is that Nick didn’t package it like some clean founder origin story. It was more honest than that. A bunch of weird career bruises. A few lucky breaks. Some uncomfortable realizations. And eventually, a very practical question: How much of your career do you actually want someone else to control? That question hits differently when you hear the full story.

I’ve hosted a podcast with Nick for a while, but I realized something recently. I knew what he did. I didn’t really know the story that shaped how he thinks. There’s a big difference. It’s easy to know someone as your co-host. You know their opinions, their jokes, their takes on design, the stuff they repeat often enough that it becomes part of the rhythm. But when someone actually walks through the messy version of their career, different details start to stick. Like the first internship where school taught him to move through the proper steps, then real work punched him in the face with timelines that didn’t care about the proper steps. Like the first job that ended because of an acquisition, not because the work was bad. Like the startup that slowly ran out of oxygen. Like the consultancy role that looked good on paper, then turned into a lesson about billable hours, placement, and whether the business model actually had room for him. That’s the part I keep thinking about. Nick and I have had very different careers, but I think we’ve both been circling the same uncomfortable thing. Control. Not control in the annoying designer way where everything needs to be precious and protected. Control over how your work is valued. Control over where your judgment shows up. Control over whether people understand what you actually bring to the table before a spreadsheet quietly decides your role for you. Nick’s path pushed him toward freelance. Mine pushed me toward business impact, adoption, ROI, and influence inside teams. Different careers. Same allergic reaction to being treated like design is just the last decorative step after all the important decisions are already made. Reference: Nick’s story includes the internship timeline shock, acquisition, startup funding issue, consultancy mismatch, and eventual freelance shift.

Designers do not lose portfolio interviews because the work is bad. They lose them because the story gets heavy. You can feel it happen. The hiring manager stops nodding. The PM starts scanning ahead. Someone asks a question three slides early. So the designer grabs tighter. More context. More research. More constraints. More proof. All the shit that mattered, delivered in the least useful order possible. I wrote about why your portfolio is not the presentation, why I always include a “what went wrong” slide, and how to structure your case study around decisions instead of a timeline. Because hiring teams are not just asking whether you can design. They are asking whether they would trust you in the messy middle of a real project. Full post here: saasifyos.kit.com/posts/the-case…

By the time a designer gets to the portfolio presentation, the website already did its job. It got them in the room. That is where the real interview starts. And this is where a lot of designers accidentally keep presenting like they are still being judged by the website. Perfect layout. Perfect story. Perfect screenshots. Perfect little outcome section that says engagement increased by 18 percent and everyone went home emotionally regulated. But the room is not hiring the website. They are hiring the person who has to survive the project after the kickoff deck stops being useful. That is why I keep coming back to the same idea this week: A portfolio presentation should not make you look flawless. It should make you look trustworthy. There is a big difference. Flawless hides the miss. Trustworthy explains what happened after the miss. Flawless avoids the awkward launch. Trustworthy shows how you responded when adoption came in lower than expected. Flawless makes the designer look like the hero the whole way through. Trustworthy shows the moment they got knocked off the path, took ownership, and found their way back. That is what I wrote about in this week’s public article. How designers actually get hired after the portfolio review. Because the portfolio gets attention. But the presentation reveals judgment. And judgment is usually the part people are actually hiring for.

Weak portfolio presentations usually fail before the screens. Too much setup. Company context. User problem. Design process. Stakeholder background. Research summary. Fine. But after 2 minutes, nobody knows what decision was actually hard. On The Design Table Podcast, Nick said: “Say less at the beginning.” That stuck with me. Most designers front-load everything because they’re trying to prove they belong. But the more you explain upfront, the less the room has to pull on. The stronger move is getting to the tension faster: “We thought this would work. It didn’t.” Now people listen. Why didn’t it work? What changed? Who owned it? What did you do next? My personal rule: “If the case study makes me look flawless, I probably edited out the most useful part.” Final screens show craft. Failure shows judgment.

The portfolio interview is not a presentation. It’s a trust test. Most designers treat it like they are defending a school project. They explain every decision, every screen, every constraint, every metric. But the team is not grading the effort. They’re asking: Would I want this person in the room when the project gets messy? That’s why the weird questions matter. Why did this fail? What would you cut? How did you use AI? What happened after launch? Those are not interruptions. They are the interview. Senior designers don’t just show polished work. They stay useful when the script breaks.

I have a hard requirement when I present my own case studies: I need to show where the thing failed. Not in a fake humble way. Not the polished interview version where the lesson is I learned communication matters and everyone gently nods themselves into a coma. I mean the part where the work actually struggled. The launch missed. Adoption was lower than expected. The stakeholder alignment cracked. The metric did not move. The beautiful Figma flow walked into production and immediately got punched in the mouth by reality. I like including that part because it is usually the most honest part of the story. No one is 100 out of 100. I’m not. Most of the work I’m proud of has some scar tissue on it. Something went sideways. Something was misunderstood. Something shipped smaller than I wanted. Something had to be rebuilt because the first version looked good in review and then fell apart in real usage. That does not make the case study weaker. It makes it believable. What matters is what happened after. Did I take ownership, or did I quietly make the PM the villain? Did I understand why it failed, or did I just polish the screenshot and move on? Did I go back to the data, watch the behaviour, talk to users, tighten the flow, or admit the original bet was wrong? That is the part I like talking about. Because recovery says more about a designer than the perfect happy-path walkthrough ever will. A case study should not make you look flawless. It should show how you navigated reality, took the hit, and worked your way back into the hero position.

Designers think the portfolio interview is where they explain their work. That’s usually where they lose the room. They start with company context, research, flows, iterations, edge cases, stakeholder drama, and the metric that maybe moved but got weird after launch. At first, everyone is with them. Then the hiring manager stops asking questions. The PM starts scanning ahead. Someone asks how AI was used. And now the designer is not presenting screens anymore. They are being asked where their judgment showed up. That’s the trap. The portfolio website teaches designers to present like the page is the product. Start at the top. Scroll down. Explain everything. But interviews are pressure tests. Especially now. If AI helped you move faster, the question shifts from: What did you make? To: What did you decide? That is what the room is actually judging.

I got promoted this week. Then immediately started questioning half my workflow. Which feels about right. A new title is great, but it also makes the standard harder to ignore. You can’t say you want more ownership, more leverage, and more business impact while quietly babysitting bloated workflows that keep you away from the real product. So this week I started cutting. I doubled down on Cursor over Figma Make for prototyping real product logic. I started moving my portfolio site off WordPress, which I’ve embarrassingly been using for 10 years. I started moving my other site off Webflow. Both are going to GitHub and Vercel. The result? Roughly $1,300/year saved. But the money isn’t really the point. The point is that every tool should earn its seat. If it gets you closer to the product, great. If it helps you validate faster, great. If it helps the team make better decisions, great. But if it just makes you feel productive while quietly adding friction, maybe it’s just expensive furniture. I wrote about the promotion, Cursor, Figma Make, WordPress, Webflow, and why I think senior designers need to think less like artifact makers and more like system owners. Read it here: saasifyos.kit.com/posts/i-got-pr…

Designers are not actually afraid of other people having ideas. I think we’re afraid of realizing the part of design we can point to is not the same as the part people pay for. The file is visible. The wireframe is visible. The prototype is visible. But judgment is harder to see. So when someone else makes an artifact, it feels personal. Wrong fight. The company does not win because the designer owned the wireframe. It wins when the right thing gets built, for the right reason, with fewer expensive detours.

Years ago, an engineer suggested a solution to me. I thought, cool, that could work. So I started shaping it. Cleaning it up. Making the flow better. Then a day later I realized I had skipped the most important part. I never quality checked the idea. I took the solution as the starting point instead of asking if it was the right solution in the first place. A polished bad idea is still a bad idea. It just has nicer spacing.

@mrtylerwhite and I share what work outside of Figma looks like for us in the latest episode of Design Table Podcast. Take a look here - youtube.com/watch?v=19j9zz…

Here’s a fun little identity crisis for designers: If Figma disappeared from your job tomorrow, what would be left? No pushing pixels. No wireframes. No prototypes. No moving rectangles around until your soul leaves your body. What would the company still need from you? For me, a lot. Product strategy. Customer conversations. Analytics. Facilitation. Turning messy ideas into something a team can actually build. Figma is useful. But it is not the job. The uncomfortable question isn’t whether designers still need tools. It’s whether designers know what they do when the tool is taken away.

Designers say they want a seat at the table. Then someone at the table has an idea and we act like they touched the thermostat at our parents’ house. That’s the uncomfortable part. Sometimes we don’t want influence. We want control dressed up as influence. We want product to include us earlier, but not too early. We want engineering to think about UX, but not enough to suggest changes. But the table was never supposed to be a throne. It was supposed to be where better decisions get made.

Designers get weird when a PM shows up with a prototype. But when was the last time you showed a design and everyone said: Perfect. Ship it exactly like that. Almost never. You show the work. People react. You find gaps. You adjust. So when someone else brings a rough flow, that’s not the threat. The threat is treating the first version like the final answer. Design still matters because someone has to quality check the thinking. Your value is not being the only person allowed to suggest the solution. Your value is knowing whether the solution is any good.

I thought I was being thorough. Turns out I was just being expensive. This hit me after a client call while waiting for my flight home from a Toronto offsite. I knew the patterns. I heard the hesitation. I knew which objections mattered. Then I opened the recording and started doing the same shit I always do: scrubbing through the call, pulling insights, cleaning them up, and turning messy human signal into something product, engineering, and sales could actually use. Halfway through I stopped. Why am I manually doing this part? Not the thinking. That already happened in the call. I was doing the packaging. And when you do the math, that tiny repeated task gets stupid fast. 45 minutes, twice a week, is 6 hours a month. At $75/hour, that’s $5,400/year. Not for strategy. Not for judgment. Just packaging. I wrote the full breakdown here: saasifyos.kit.com/posts/you-migh…

AI may not be exposing weak craft. It may be exposing how much repetitive labor we mistook for expertise. That’s a harder thought. The question I keep asking now is: What actually needs my judgment… and what am I doing out of habit? That feels like a much bigger shift than tooling.

Most designers don’t have a workload problem. They have a repetition problem. Summarizing calls. Formatting tickets. Rebuilding the same artifacts in new wrappers. A lot of that isn’t craft. It’s drag. I started noticing if I explain something for the third time, there’s probably something to delegate.