The Path
Start Here If You're a Founder
This is the stuff I wish every founder I've worked with already knew before we started. Not design theory. Not color wheel nonsense. The practical knowledge that changes how you evaluate your product, your interface, and the decisions your team is making on your behalf. I put this in order on purpose. Start at the top. Work your way down. By the end you won't be a designer, but you'll be dangerous enough to know when design is working, when it's not, and what questions to ask that save you months of building the wrong thing.
→ Design Isn't What You Think It Is
Most founders think design is what something looks like. It's not. Design is how something works, how it communicates, and how it earns trust. Until that distinction is internalized, every design decision optimizes for the wrong thing.
Here's the clearest way to understand the difference: decoration makes something look better. Design makes something work better. Both are valid. Only one moves a business metric.
The most important design decisions in any product don't look like design decisions. Choosing what to put above the fold on your homepage is a design decision. Deciding the order of your onboarding steps is a design decision. Determining how your error messages sound is a design decision. None of these involve color palettes or font choices. All of them directly impact whether people use your product or leave.
When teams treat design as a final layer, something applied after the product is built, they end up with products that look polished but feel confusing. When teams treat design as a foundational layer, something that shapes decisions from the start, the product is clear, intuitive, and trustworthy before a single visual element is added.
The shift is subtle but significant. Stop asking "does this look good?" Start asking "does this work?" Does the user understand what to do next? Does the interface earn trust before asking for commitment? Does the experience reduce friction or create it?
If you can consistently answer those questions about your own product, you'll make better decisions than most founders who hire designers and hope for the best.
The one thing to take from this: Design is decision-making, not decoration. Every screen, every flow, every word in your product is a design decision whether you treat it that way or not.
→ Your Landing Page Is Lying to You
Most landing pages are built to make the founder feel proud, not to make the visitor take action. This is one of the most expensive mistakes in early-stage companies and it's invisible because the page "looks good."
Here's the test. Show your landing page to someone who knows nothing about your product. Give them five seconds. Then take it away and ask two questions: what does this product do, and what should I do next? If they can't answer both, your landing page is failing at its only job.
A landing page has one purpose: make the visitor care enough to take one action. Not five actions. Not "explore our features." One action. Sign up. Book a demo. Try it. Whatever your primary CTA is, that's the only thing the page should optimize for.
The most common problems with landing pages are predictable. The headline is clever instead of clear. There are multiple CTAs competing for attention. The value proposition is generic and could describe any competitor. The social proof is unspecific or irrelevant to the target audience. Features are listed before the user understands the benefit.
Here's the hierarchy that works. Above the fold: headline that says what you do and for whom. Subline that says why it matters. One CTA. Below the fold: how it works in three steps or less. Social proof that's specific and credible. One more CTA. Done.
Every section you add beyond this is another chance to lose someone. Most landing pages have too much, not too little. If your bounce rate is above 60%, the most likely fix isn't adding more information. It's removing everything that isn't directly serving the conversion.
A common objection: "But people need to understand all our features." No. They need to understand one thing: is this worth my time? Features come later. Conviction comes first.
The one thing to take from this: Your landing page should answer two questions in five seconds: what is this, and what should I do? Everything else is secondary.
→ The First Five Minutes Decide Everything
Every product has approximately five minutes to turn a new visitor into someone who sees value. Miss that window and they're gone. Not because your product is bad. Because you didn't give them a reason to stay fast enough.
Most onboarding flows make the same mistake: they try to educate. Feature tours. Tooltips. Welcome wizards. Five screens of explanation before the user touches anything. This feels logical to the team that built the product because they know everything the product can do. To a new user, it feels like homework.
The alternative is what I call the "first win" approach. Instead of explaining what your product does, get the user to experience one valuable outcome as fast as possible. What's the smallest thing someone can accomplish that proves your product is worth their time? That's your onboarding goal. Everything else can wait.
For a design tool, the first win might be creating their first element on the canvas. For a data product, it might be seeing their first insight generated. For a Web3 product, it might be showing them what their potential returns look like before asking them to connect a wallet.
The sequence matters enormously. Consider two approaches. Approach one: sign up, connect wallet, complete profile, watch tour, start using product. Approach two: see a preview of value, interact with sample data, experience one result, then sign up when motivated. Same product. Radically different conversion rates.
Map your current first five minutes. Every screen. Every click. Every decision point. Ask yourself at each step: does the user have enough context and motivation to continue? If the answer is no at any point, that's where you're losing people.
The best onboarding doesn't feel like onboarding. It feels like the product working. No tours. No tutorials. Just a clear first action and a visible result.
The one thing to take from this: Don't explain your product. Let people use it. Find your "first win" and make it happen in under two minutes.
→ How to Evaluate Design When You're Not a Designer
You don't need to be a designer to know if design is working. You need the right questions. Most founders either defer entirely to their designer's judgment or give feedback based on personal taste. Both are problematic. The first abdicates responsibility. The second wastes everyone's time.
Here are five questions that cut through both problems. Ask them about any screen, any flow, any page.
Is it clear? Can someone understand what they're looking at and what to do next without any explanation? If you have to explain it, it's not clear enough. Clarity isn't dumbing things down. It's being precise about what matters and removing everything that doesn't.
Is it consistent? Do the same patterns mean the same things throughout the product? Do buttons look the same everywhere? Do colors carry the same meaning? Inconsistency creates cognitive load. Users process it as "something feels off" even when they can't articulate what.
Is it trustworthy? Does the interface feel reliable? Are error messages helpful? Are loading states clear? Does the product handle edge cases gracefully? Trust is built in the moments that most teams skip: the error state, the empty state, the loading state, the confirmation step.
Is it fast? Not just technically fast. Does it feel fast? Are there unnecessary steps? Are there screens that could be combined? Is the user doing work the product should be doing for them? Every unnecessary step is a chance for someone to leave.
Does it guide? Is there a clear visual hierarchy? Does the user's eye go to the right place first? Is the most important action the most visible element? Good design doesn't just present information. It tells you where to look and what to do.
When giving feedback to a designer, frame it around these questions instead of personal preference. "I'm not sure a user would understand what to do here" is useful feedback. "I don't like the blue" is not. The first is about user experience. The second is about taste. Your designer should own the taste. You should own the clarity.
The one thing to take from this: Evaluate design by asking: is it clear, consistent, trustworthy, fast, and guiding? If it passes all five, the design is working regardless of whether you personally like how it looks.
→ When to Hire a Designer (and What Kind)
Hiring a designer at the wrong time or hiring the wrong type is one of the most expensive mistakes a startup can make. And it's common because most founders treat "hire a designer" as a single decision when it's actually three different decisions depending on what you need.
The three types of design help operate at different levels. Strategic design help means someone who can look at your product, your market, and your users and tell you what to build and how to position it. This is usually a consultant or an experienced fractional design lead. Systematic design help means someone who builds the infrastructure: design systems, component libraries, pattern documentation, and the frameworks that let a team ship consistently. This is a design systems specialist or a senior product designer with systems experience. Executional design help means someone who takes defined problems and produces high-quality solutions. Screens, flows, visual design, prototypes. This is a product designer or UI designer.
Most early-stage founders hire for execution first. This feels logical but often backfires. An executor without strategic direction will produce beautiful solutions to the wrong problems. The most leveraged first design hire is someone who can do all three but leads with strategy.
The stage question matters. If you're pre-product-market-fit, you probably don't need a full-time designer yet. You need a consultant or advisor who can help you make the right product decisions and a freelancer or contractor to execute the interface work. Hiring a full-time designer before you know what you're building is paying a salary to explore alongside you, which is expensive and often frustrating for both sides.
If you're post-product-market-fit and growing, that's when a full-time hire makes sense. At this stage you need someone who lives inside the product, understands the users deeply, and can make fast decisions without external context.
When evaluating candidates, look past the portfolio. The portfolio shows what they've made. The conversation shows how they think. Ask how they'd approach a problem in your product. Ask what questions they'd want answered before starting. Ask about a time they pushed back on a stakeholder and why. The best designers aren't the ones with the most polished case studies. They're the ones who ask the sharpest questions.
The one thing to take from this: Don't default to "we need a designer." Define what you actually need: strategic direction, systematic infrastructure, or execution. Then hire for the most urgent gap.
→ Design Systems Aren't What Twitter Told You
If you've spent any time in design communities, you've probably come away thinking a design system is a giant Figma library with hundreds of components, detailed documentation, and a dedicated team maintaining it. That's one version. And for most startups, it's the wrong one.
A design system, at its core, is an agreement between design and engineering about how decisions get made. It's not a library. It's a shared language. The components and tokens and documentation are artifacts of that agreement, not the agreement itself. This distinction matters because most teams build the artifacts and skip the alignment, then wonder why nobody follows the system.
The practical question is when you need one. The answer is: later than you think if you're talking about a full system, and earlier than you think if you're talking about the foundations.
The foundations are simple. A defined color palette. A type scale. A spacing system. Consistent border radius. A handful of core components that appear on more than half your screens. You can establish these in a week. They'll prevent 70% of the visual inconsistency in your product without requiring a dedicated design systems team.
The full system comes later. When you have multiple designers shipping to the same product. When new team members take too long to get productive because they're reverse-engineering patterns from existing screens. When your engineering team is rebuilding the same UI components from scratch across features.
The biggest failure mode is building comprehensively in isolation. A team goes away for three months, builds a beautiful system, documents everything, and launches it to the rest of the team. Adoption stalls because the system was built without input from the people who need to use it. The fix is simple: build incrementally, with the product team, solving real problems as they arise. Every component in the system should exist because someone needed it this week, not because it might be useful someday.
One metric that tells you whether your system is working: ask your designers and engineers, when was the last time they used a system component instead of building from scratch? If the answer is "I'm not sure" or "it was easier to just build it," the system has an adoption problem, not a coverage problem.
The one thing to take from this: A design system is an agreement, not a library. Start with foundations (tokens and core components). Build incrementally with your team. Measure adoption, not coverage.
→ AI Won't Fix Your Design. But It Will Expose It.
AI is changing how products are built and experienced. If you're a founder, understanding what this means for design isn't optional anymore.
Here's the core shift: traditional interfaces are menu-driven. Users navigate to what they want through pages, tabs, and buttons. AI-native interfaces are intent-driven. Users express what they want and the interface responds. This isn't just a UI change. It's a fundamental rethinking of how products are structured.
What this means practically: the information architecture matters less. The quality of the AI interaction matters more. But here's the catch. If your underlying design foundations are weak, AI will amplify the problems, not fix them. Unclear product positioning becomes even more confusing when an AI tries to communicate it. Inconsistent brand voice becomes worse when there's an AI speaking on behalf of your product in real time. Broken user flows don't get fixed by adding a chat interface on top.
The products getting AI right share a common trait: they were well-designed before AI entered the picture. The AI enhances an already clear experience. It removes friction that was already identified. It surfaces information that was already well-organized. AI is a multiplier. And multipliers amplify whatever they're applied to, including problems.
For founders, the practical takeaway is this: don't add AI to fix design problems. Fix the design problems first. Then add AI to accelerate what's already working.
When you do add AI features, the biggest design challenge isn't the technology. It's trust. Users need to trust the AI's output before they'll rely on it. That trust comes from the interface: how results are presented, how confidence levels are communicated, how errors are handled, and how transparent the system is about what it can and can't do.
The AI features that feel trustworthy share specific design patterns. They show their reasoning, not just their output. They indicate confidence levels. They make it easy to edit, override, or undo. They don't pretend to be perfect. They present AI as a tool the user controls, not a system the user submits to.
Taste matters more in AI-native products, not less. When the AI handles execution, the human advantage becomes judgment: knowing what to ask for, knowing when the output is good enough, knowing when to push back. That's taste. And it's the one thing that gets more valuable as AI gets more capable.
The one thing to take from this: AI multiplies whatever it touches. Strong foundations get stronger. Weak foundations get exposed. Fix your design first. Then use AI to accelerate what works.
——
That's the foundation. Not everything there is to know about design, but enough to make you dangerous in the right ways: asking better questions, spotting problems earlier, and knowing when design is working versus when it's just looking good.
If something here shifted how you think about your product, there are two natural next steps.
Take the Diagnostic. Two minutes. Honest answers. See where your product actually stands right now. → Go to The Diagnostic
Book Office Hours. Fifteen minutes. Free. One specific question about your product or team. → Go to Office Hours
Start Here If You're a Founder
This is the stuff I wish every founder I've worked with already knew before we started. Not design theory. Not color wheel nonsense. The practical knowledge that changes how you evaluate your product, your interface, and the decisions your team is making on your behalf. I put this in order on purpose. Start at the top. Work your way down. By the end you won't be a designer, but you'll be dangerous enough to know when design is working, when it's not, and what questions to ask that save you months of building the wrong thing.
→ Design Isn't What You Think It Is
Most founders think design is what something looks like. It's not. Design is how something works, how it communicates, and how it earns trust. Until that distinction is internalized, every design decision optimizes for the wrong thing.
Here's the clearest way to understand the difference: decoration makes something look better. Design makes something work better. Both are valid. Only one moves a business metric.
The most important design decisions in any product don't look like design decisions. Choosing what to put above the fold on your homepage is a design decision. Deciding the order of your onboarding steps is a design decision. Determining how your error messages sound is a design decision. None of these involve color palettes or font choices. All of them directly impact whether people use your product or leave.
When teams treat design as a final layer, something applied after the product is built, they end up with products that look polished but feel confusing. When teams treat design as a foundational layer, something that shapes decisions from the start, the product is clear, intuitive, and trustworthy before a single visual element is added.
The shift is subtle but significant. Stop asking "does this look good?" Start asking "does this work?" Does the user understand what to do next? Does the interface earn trust before asking for commitment? Does the experience reduce friction or create it?
If you can consistently answer those questions about your own product, you'll make better decisions than most founders who hire designers and hope for the best.
The one thing to take from this: Design is decision-making, not decoration. Every screen, every flow, every word in your product is a design decision whether you treat it that way or not.
→ Your Landing Page Is Lying to You
Most landing pages are built to make the founder feel proud, not to make the visitor take action. This is one of the most expensive mistakes in early-stage companies and it's invisible because the page "looks good."
Here's the test. Show your landing page to someone who knows nothing about your product. Give them five seconds. Then take it away and ask two questions: what does this product do, and what should I do next? If they can't answer both, your landing page is failing at its only job.
A landing page has one purpose: make the visitor care enough to take one action. Not five actions. Not "explore our features." One action. Sign up. Book a demo. Try it. Whatever your primary CTA is, that's the only thing the page should optimize for.
The most common problems with landing pages are predictable. The headline is clever instead of clear. There are multiple CTAs competing for attention. The value proposition is generic and could describe any competitor. The social proof is unspecific or irrelevant to the target audience. Features are listed before the user understands the benefit.
Here's the hierarchy that works. Above the fold: headline that says what you do and for whom. Subline that says why it matters. One CTA. Below the fold: how it works in three steps or less. Social proof that's specific and credible. One more CTA. Done.
Every section you add beyond this is another chance to lose someone. Most landing pages have too much, not too little. If your bounce rate is above 60%, the most likely fix isn't adding more information. It's removing everything that isn't directly serving the conversion.
A common objection: "But people need to understand all our features." No. They need to understand one thing: is this worth my time? Features come later. Conviction comes first.
The one thing to take from this: Your landing page should answer two questions in five seconds: what is this, and what should I do? Everything else is secondary.
→ The First Five Minutes Decide Everything
Every product has approximately five minutes to turn a new visitor into someone who sees value. Miss that window and they're gone. Not because your product is bad. Because you didn't give them a reason to stay fast enough.
Most onboarding flows make the same mistake: they try to educate. Feature tours. Tooltips. Welcome wizards. Five screens of explanation before the user touches anything. This feels logical to the team that built the product because they know everything the product can do. To a new user, it feels like homework.
The alternative is what I call the "first win" approach. Instead of explaining what your product does, get the user to experience one valuable outcome as fast as possible. What's the smallest thing someone can accomplish that proves your product is worth their time? That's your onboarding goal. Everything else can wait.
For a design tool, the first win might be creating their first element on the canvas. For a data product, it might be seeing their first insight generated. For a Web3 product, it might be showing them what their potential returns look like before asking them to connect a wallet.
The sequence matters enormously. Consider two approaches. Approach one: sign up, connect wallet, complete profile, watch tour, start using product. Approach two: see a preview of value, interact with sample data, experience one result, then sign up when motivated. Same product. Radically different conversion rates.
Map your current first five minutes. Every screen. Every click. Every decision point. Ask yourself at each step: does the user have enough context and motivation to continue? If the answer is no at any point, that's where you're losing people.
The best onboarding doesn't feel like onboarding. It feels like the product working. No tours. No tutorials. Just a clear first action and a visible result.
The one thing to take from this: Don't explain your product. Let people use it. Find your "first win" and make it happen in under two minutes.
→ How to Evaluate Design When You're Not a Designer
You don't need to be a designer to know if design is working. You need the right questions. Most founders either defer entirely to their designer's judgment or give feedback based on personal taste. Both are problematic. The first abdicates responsibility. The second wastes everyone's time.
Here are five questions that cut through both problems. Ask them about any screen, any flow, any page.
Is it clear? Can someone understand what they're looking at and what to do next without any explanation? If you have to explain it, it's not clear enough. Clarity isn't dumbing things down. It's being precise about what matters and removing everything that doesn't.
Is it consistent? Do the same patterns mean the same things throughout the product? Do buttons look the same everywhere? Do colors carry the same meaning? Inconsistency creates cognitive load. Users process it as "something feels off" even when they can't articulate what.
Is it trustworthy? Does the interface feel reliable? Are error messages helpful? Are loading states clear? Does the product handle edge cases gracefully? Trust is built in the moments that most teams skip: the error state, the empty state, the loading state, the confirmation step.
Is it fast? Not just technically fast. Does it feel fast? Are there unnecessary steps? Are there screens that could be combined? Is the user doing work the product should be doing for them? Every unnecessary step is a chance for someone to leave.
Does it guide? Is there a clear visual hierarchy? Does the user's eye go to the right place first? Is the most important action the most visible element? Good design doesn't just present information. It tells you where to look and what to do.
When giving feedback to a designer, frame it around these questions instead of personal preference. "I'm not sure a user would understand what to do here" is useful feedback. "I don't like the blue" is not. The first is about user experience. The second is about taste. Your designer should own the taste. You should own the clarity.
The one thing to take from this: Evaluate design by asking: is it clear, consistent, trustworthy, fast, and guiding? If it passes all five, the design is working regardless of whether you personally like how it looks.
→ When to Hire a Designer (and What Kind)
Hiring a designer at the wrong time or hiring the wrong type is one of the most expensive mistakes a startup can make. And it's common because most founders treat "hire a designer" as a single decision when it's actually three different decisions depending on what you need.
The three types of design help operate at different levels. Strategic design help means someone who can look at your product, your market, and your users and tell you what to build and how to position it. This is usually a consultant or an experienced fractional design lead. Systematic design help means someone who builds the infrastructure: design systems, component libraries, pattern documentation, and the frameworks that let a team ship consistently. This is a design systems specialist or a senior product designer with systems experience. Executional design help means someone who takes defined problems and produces high-quality solutions. Screens, flows, visual design, prototypes. This is a product designer or UI designer.
Most early-stage founders hire for execution first. This feels logical but often backfires. An executor without strategic direction will produce beautiful solutions to the wrong problems. The most leveraged first design hire is someone who can do all three but leads with strategy.
The stage question matters. If you're pre-product-market-fit, you probably don't need a full-time designer yet. You need a consultant or advisor who can help you make the right product decisions and a freelancer or contractor to execute the interface work. Hiring a full-time designer before you know what you're building is paying a salary to explore alongside you, which is expensive and often frustrating for both sides.
If you're post-product-market-fit and growing, that's when a full-time hire makes sense. At this stage you need someone who lives inside the product, understands the users deeply, and can make fast decisions without external context.
When evaluating candidates, look past the portfolio. The portfolio shows what they've made. The conversation shows how they think. Ask how they'd approach a problem in your product. Ask what questions they'd want answered before starting. Ask about a time they pushed back on a stakeholder and why. The best designers aren't the ones with the most polished case studies. They're the ones who ask the sharpest questions.
The one thing to take from this: Don't default to "we need a designer." Define what you actually need: strategic direction, systematic infrastructure, or execution. Then hire for the most urgent gap.
→ Design Systems Aren't What Twitter Told You
If you've spent any time in design communities, you've probably come away thinking a design system is a giant Figma library with hundreds of components, detailed documentation, and a dedicated team maintaining it. That's one version. And for most startups, it's the wrong one.
A design system, at its core, is an agreement between design and engineering about how decisions get made. It's not a library. It's a shared language. The components and tokens and documentation are artifacts of that agreement, not the agreement itself. This distinction matters because most teams build the artifacts and skip the alignment, then wonder why nobody follows the system.
The practical question is when you need one. The answer is: later than you think if you're talking about a full system, and earlier than you think if you're talking about the foundations.
The foundations are simple. A defined color palette. A type scale. A spacing system. Consistent border radius. A handful of core components that appear on more than half your screens. You can establish these in a week. They'll prevent 70% of the visual inconsistency in your product without requiring a dedicated design systems team.
The full system comes later. When you have multiple designers shipping to the same product. When new team members take too long to get productive because they're reverse-engineering patterns from existing screens. When your engineering team is rebuilding the same UI components from scratch across features.
The biggest failure mode is building comprehensively in isolation. A team goes away for three months, builds a beautiful system, documents everything, and launches it to the rest of the team. Adoption stalls because the system was built without input from the people who need to use it. The fix is simple: build incrementally, with the product team, solving real problems as they arise. Every component in the system should exist because someone needed it this week, not because it might be useful someday.
One metric that tells you whether your system is working: ask your designers and engineers, when was the last time they used a system component instead of building from scratch? If the answer is "I'm not sure" or "it was easier to just build it," the system has an adoption problem, not a coverage problem.
The one thing to take from this: A design system is an agreement, not a library. Start with foundations (tokens and core components). Build incrementally with your team. Measure adoption, not coverage.
→ AI Won't Fix Your Design. But It Will Expose It.
AI is changing how products are built and experienced. If you're a founder, understanding what this means for design isn't optional anymore.
Here's the core shift: traditional interfaces are menu-driven. Users navigate to what they want through pages, tabs, and buttons. AI-native interfaces are intent-driven. Users express what they want and the interface responds. This isn't just a UI change. It's a fundamental rethinking of how products are structured.
What this means practically: the information architecture matters less. The quality of the AI interaction matters more. But here's the catch. If your underlying design foundations are weak, AI will amplify the problems, not fix them. Unclear product positioning becomes even more confusing when an AI tries to communicate it. Inconsistent brand voice becomes worse when there's an AI speaking on behalf of your product in real time. Broken user flows don't get fixed by adding a chat interface on top.
The products getting AI right share a common trait: they were well-designed before AI entered the picture. The AI enhances an already clear experience. It removes friction that was already identified. It surfaces information that was already well-organized. AI is a multiplier. And multipliers amplify whatever they're applied to, including problems.
For founders, the practical takeaway is this: don't add AI to fix design problems. Fix the design problems first. Then add AI to accelerate what's already working.
When you do add AI features, the biggest design challenge isn't the technology. It's trust. Users need to trust the AI's output before they'll rely on it. That trust comes from the interface: how results are presented, how confidence levels are communicated, how errors are handled, and how transparent the system is about what it can and can't do.
The AI features that feel trustworthy share specific design patterns. They show their reasoning, not just their output. They indicate confidence levels. They make it easy to edit, override, or undo. They don't pretend to be perfect. They present AI as a tool the user controls, not a system the user submits to.
Taste matters more in AI-native products, not less. When the AI handles execution, the human advantage becomes judgment: knowing what to ask for, knowing when the output is good enough, knowing when to push back. That's taste. And it's the one thing that gets more valuable as AI gets more capable.
The one thing to take from this: AI multiplies whatever it touches. Strong foundations get stronger. Weak foundations get exposed. Fix your design first. Then use AI to accelerate what works.
——
That's the foundation. Not everything there is to know about design, but enough to make you dangerous in the right ways: asking better questions, spotting problems earlier, and knowing when design is working versus when it's just looking good.
If something here shifted how you think about your product, there are two natural next steps.
Take the Diagnostic. Two minutes. Honest answers. See where your product actually stands right now. → Go to The Diagnostic
Book Office Hours. Fifteen minutes. Free. One specific question about your product or team. → Go to Office Hours
