What 6 Years at Google (so far) Taught Me About Design (that school didn't)
In the winter of 2019, I landed what many consider the "Holy Grail": a Product Design role at Google. I walked in expecting a masterclass in pixels; I walked out six years later with a masterclass in persuasion. Google is a rare beast. Its business model allows for a luxury most startups can’t afford: the time to fail, the space to take risks, and an obsession with craft excellence.
If you want to move from "pixel pusher" to "product leader," these are the 10 hard-won lessons I’m taking with me.
1. Kill the MVP. Build a Great Product.
In the startup world, "Minimum Viable Product" is gospel. At Google, it’s often a ceiling. We didn’t just want it to work; we wanted it to be excellent. If an experience isn't seamless across every platform, don't ship it. Wait until it’s ready to wow, not just function.
2. Storytelling is Your Real Hard Skill
You aren't just a designer; you’re a salesperson. You aren't selling features to users; you’re selling a vision to stakeholders. At Google, even the smallest feature change requires a slide deck. Why? Because designers use stories to influence, not just to show.
3. Communication Outpaces Craft
Great design will get you in the room. Great communication will get the project built. Your ability to project confidence and articulate why a decision was made is the difference between a "cool concept" and a "shipped product."
4. Passion is Contagious (and Strategic)
The biggest shift in my career happened when I started putting skin in the game during meetings. Don’t just present the work—be obsessed with it. If you aren't excited about your solution, why should a VP be?
5. Focus on the "Feel"
Sundar Pichai demonstrates how to communicate a vision consistently. People might forget the specific hex codes or grid systems you used, but they will never forget how you made them feel. Do they feel confident in your direction or bored by your data?
6. The "One More Thing" Mindset
Junior designers solve the ticket. Senior designers solve the future. Always include a "bonus" section in your pitches—a stretch goal or a "what if" scenario. It shows you’re thinking three steps ahead of the current roadmap.
7. Trust Expert Intuition
Data is great, but for high-stakes innovation, you can't always A/B test your way to greatness. We relied on rigorous internal critiques with Directors and VPs. If your design can survive a room of world-class experts, it can survive the market.
8. Master the "Strategic No"
Seniority isn't about how much you can do; it's about what you choose not to do. To deliver exceptional quality, you have to say "no" to a hundred "good" ideas so you can say "yes" to one transformative one.
9. Stop Seeking Bottom-Up Consensus
Consensus is a momentum killer. Instead of trying to please twenty stakeholders, seek decisive alignment. Get in front of the decision-makers, get the green light, and get back to the craft.
10. You Are a System Architect, Not a Decorator
Your role has evolved. You are no longer just executing; you are driving product vision. Own the system, influence the stakeholders, and never let the "process" get in the way of a brilliant user experience.
The Bottom Line: At the end of the day, we are all "deck designers" to some extent. We use the power of narrative to move mountains. Master the story, and the design will follow.
The "Frankenstein" tech stack is killing our focus.
We’re living in a loop of link-hell: docs in one tab, calls in another, and a relentless stream of chat in a third. We spend half our day copy-pasting URLs and the other half playing "Permission Gatekeeper" just so a teammate can see a single mockup.
Even when the tools work, the context dies. Discussions vanish into the scroll. Decisions are buried in a thread from three weeks ago. It’s not just messy—it’s a tax on our collective intelligence.
We decided to stop fighting the tools and start fixing the workflow. Here is the blueprint for how high-performing teams should actually communicate:
1. Posts over Pings
Most internal communication should be async-first and topical. By defaulting to structured, threaded posts with nested comments, we trade the "constant buzz" of chat for high-signal discussions that actually lead somewhere.
2. Calls with a Paper Trail
A meeting that isn't searchable is just a distraction. Every call should be recorded, summarized, and socialized. If you missed the sync, you should be able to catch the "highlight reel" in two minutes, not forty.
3. Docs without the Bloat
We’ve all been lost in the "Infinite Nesting" of modern doc tools. We need collaborative spaces that prioritize speed and clarity over complex block hierarchies. Formatting should be beautiful by default; typing shouldn't feel like a chore.
4. Ephemeral Chat
Chat is for the "in-between" moments, not the source of truth. By keeping chat ephemeral, we nudge the team to move important decisions into Posts or Docs. It keeps the noise floor low and the transparency high.
The Result? In the last year, we didn't just "optimize" our workflow—we gutted it. We ditched the fragmented chaos of Notion, Slack, and Zoom in favor of a unified system. We stopped managing our tools and started focused on the craft.
Keeping Claude Code Sync’d Between Computers
Context switching is a momentum killer. Nothing breaks a coding flow faster than realizing your custom Claude Code skills—the ones you’ve spent weeks refining—are stuck on your other laptop.
Setting up a new machine shouldn't feel like a chore, and it definitely shouldn't involve manual copy-pasting. I wanted a "source of truth" that actually stayed true, no matter which device I’m on.
My solution? I treated my configuration like production code.
I moved my entire Claude Code setup into a git repo and built an install script to symlink everything directly into ~/.claude/. No more "missing skill" friction—just a clean, automated bridge between my machines.
The Logic: Tactical State Management
A blind sync is a recipe for a mess. To keep things organized, I categorized every skill into one of four states, visible directly in the CLI:
Synced: The gold standard. Live in the repo, live on every machine.
Local-only: Experimental or machine-specific tweaks that stay put.
Conflict: A safety net for when local changes clash with the repo.
External Symlink: For those edge cases where a skill needs to live outside the standard directory.
The result: I stopped managing my environment and started actually coding. The CLI dashboard tells me exactly where my skills live at a glance, so I can keep my focus where it belongs: on the craft, not the config.
Coding agents are only as good as their feedback loops.
If you aren't giving your agent the eyes to see and the tools to verify its own work, you’re basically hiring a genius who isn't allowed to look at the screen.
The Golden Rule
If your agent ever asks you to do something manually, stop. Don't just do the task. Think really hard about how to give the agent the tools it needs to do it itself.
If you’re still typing "make it faster" or "fix the bugs," you’re in for a bad time. Agents are brilliant, but they’re inherently lazy. Without a rigorous loop, they’ll fix one thing, break three others, and keep pestering you to check their math.
The goal isn't just to write a prompt; it's to reorient your mental model. Stop giving orders. Start building systems.
Example 1: The Performance Audit
The Lazy Way: "The app is slow. Audit the code and make it faster." The Pro Way: "Your job is to make this app faster. Before you touch a single line of code, build yourself a laboratory."
Phase 1 — Instrumentation: Build a benchmark harness. Add timing utilities. Use the Chrome Devtools MCP to capture baseline performance traces.
Phase 2 — Diagnosis: Identify the top 3 bottlenecks. Write a hypothesis for each.
Phase 3 — Iteration: Fix, re-run benchmarks, and compare to baseline. Only keep what actually moves the needle.
Phase 4 — Report: Generate an HTML report with before/after charts.
Example 2: The Design Implementation
The Lazy Way: "Use the Figma MCP to implement this design: {url}" The Pro Way: "Implement this design, then run a refinement loop until it's pixel-perfect."
First Pass: Pull the design, study it, and build the foundation. It will be wrong. That’s fine.
The Loop: * Screenshot the implementation and inspect the properties.
Compare it directly to the Figma source.
List every discrepancy: spacing, shadows, responsive behavior.
Fix, verify, and repeat.
The Standard: Don't stop at "close enough." The gap between "almost" and "correct" is where the polish lives.
The 2026 Playbook
Dictate, Don't Type: As models get better, prompts get longer. Use a dictation app like Monologue to save your hands.
Develop "Model Feel": Not every task needs a five-page scaffolding. Learn the intuition of when to go deep and when to keep it light.
Don't Formalize Too Early: Learn how your agent handles subagents and commands before you try to build a rigid framework.
Pro Tip: Once you’ve prompted your way to a workflow that actually works, have the agent "save its game." Tell it:
"Take everything we learned here—my prompts and your problem-solving approach—and encode it as a new skill in
~/.claude/skills. Give it a clear name so we can run this exact workflow again next time."
Since we’re treating the agent like a high-end engineer, the skill needs to be more than just a "how-to." It needs to be a system definition.
Here is a draft for the .claude/skills/performance_lab.md (or your preferred skill format) that encodes the "Laboratory" mental model.
Skill: performance_lab
Description: A rigorous, data-driven workflow for auditing, benchmarking, and optimizing codebase performance.
1. Initialization (The Laboratory)
When this skill is invoked, you must first build your testing environment. Do not modify production code until the lab is verified.
Baseline Tooling: Create or identify scripts to measure execution time, memory usage, or network latency.
Instrumentation: Use
console.time,performance.now(), or the Chrome Devtools MCP to hook into critical paths.Snapshots: Record a "Clean State" baseline. Save these numbers to a
perf_baseline.json.
2. Diagnosis & Hypothesis
Analyze the data to find the "Heavy Lift."
Identify: Call out the top 3-5 bottlenecks.
Hypothesize: For every fix you propose, write a one-sentence "Expected Outcome" (e.g., "Replacing this map with an object should reduce lookup time by 20%").
3. The Iteration Loop
Work through fixes one by one. Never bundle fixes.
Apply: Change exactly one variable.
Verify: Re-run the benchmark script.
Compare: Check against
perf_baseline.json.Commit: If it’s a win, commit with a message including the % improvement. If it’s a loss or neutral, revert immediately.
4. Reporting
When the audit is complete, generate a PERFORMANCE_REPORT.md (or HTML) including:
The "Before & After" Table: Clear delta on all measured critical paths.
Architectural Red Flags: Notes on systemic issues that require human-level decisions (e.g., "We need to switch from Client-Side to Server-Side rendering for this module").
Usage Prompt
To trigger this workflow, the user will say:
"Run a performance lab on [feature/path]. focus on [metric]."
Pro-Tip: I've structured this so the agent knows it must revert neutral changes. This stops "refactor creep" where the agent rewrites half your codebase just because it thinks it looks "cleaner" without actually making it faster.
Building a better mousetrap (mousetrap = portfolio)
I’ve spent a lot of time reviewing portfolios, and I keep finding myself giving the exact same feedback. It usually boils down to two things: “Storyshowing” and “Tailoring to Hiring Managers”
When I decided to redesign my own site this year, I used it as a laboratory for these principles. If you’re looking to give your portfolio a revamp, here’s my slightly controversial take on how to actually get noticed.
The Goal: Your Website is a Conversation Starter
Let’s be real about why your portfolio exists. It’s not a museum; it’s a tool to get you an interview.
Your portfolio shouldn't be a case study—it should be a showcase. Think of it as a teaser. Its job is to grab attention, spark curiosity, and open the door to a conversation with a hiring manager. The deep dive into your messy process and "how we got there" belongs in the interview, not on a landing page that a recruiter is skimming for 30 seconds.
Recruiters look at dozens of sites a day. They don’t want a novel; they want clarity and visual impact.
Job #1: Define Your Superpower
The Principle: Self-Awareness
The first fold of your site needs to answer one question: What do you actually do? Stop using the "I’m a UX/UI designer based in [City]" template. It’s generic and tells me nothing about your value. Instead, tell me what you can do for my company.
For my redesign, I went with: “I’m a Product Designer focused on building 0–1 products with a strong focus on craft and interaction.”
The Tip: Be specific. Are you a growth expert? A design systems nerd? A 0–1 builder? When you define your focus, you make it easy for hiring managers to see exactly where you fit in their team.
Job #2: Show Me the Magic
The Principle: Outcomes over Process
Instead of documenting every single sticky note from your discovery phase, show me the "final-final" result. Use high-fidelity mocks, animations, and sizzle reels.
Apple’s marketing manifesto says it best: "People judge a product by its cover." If you’re a designer, your work should look the part.
Use video: Show how the product moves and feels.
Prioritize mocks: Let the visual craft speak for itself.
Cut the fluff: Demonstrate what you can do with pixels, not paragraphs.
Job #3: Make Me Want to Meet You
The Principle: Input Quality
Your portfolio is a reflection of your personality. Avoid generic templates that make you look like every other designer on the market. Whether your style is minimalist, high-motion, or colorful, make it distinct.
Even if you’re more of a strategist, a polished, thoughtful site signals professionalism and creativity. Your goal is to spark enough interest that a recruiter thinks, "I need to hear the story behind this."
The Bottom Line
A portfolio is your biggest chance to make a visual impression. It’s not about the granular details; it’s about showing who you are and what makes you unique.
If you’re early in your career, this can feel daunting. But trust me: learning how to tell a streamlined, punchy story about your work won't just get you hired—it will make you a better designer every single day.
One portfolio is not enough: Why your website should be different from your interview deck
We’ve been told for years that a designer’s portfolio is their calling card. But here’s the reality of the 2026 market: trying to make one website do everything is like trying to use a Swiss Army knife to perform heart surgery. It’s technically possible, but it’s going to be a mess.
If you’re aiming for a staff-level role or a spot at a top-tier product company, you don’t need a "better" portfolio. You need two of them.
Here is the breakdown of the dual-threat strategy required to land a dream design job.
1. The Public Showcase: The "Movie Trailer"
Format: A lightning-fast, visually-heavy website. The Goal: To make them stop scrolling and start typing an email.
Your website is not where you prove you can solve complex problems. It’s where you prove you have impeccable taste and craft. Recruiters and hiring managers are often "window shopping" through dozens of tabs. If your site looks like a wall of text describing a discovery phase, they’re going to bounce.
The Vibe: High-fidelity mocks, interaction videos, and "sizzle" reels. Think of it as a gallery, not a library.
The "Zero-to-One" Rule: In the first five seconds, a visitor should know exactly what your superpower is. Are you a motion wizard? A 0–1 product specialist? A systems thinker?
Why it works: It builds immediate "gut-level" trust. When the UI is beautiful and the interactions are polished, people subconsciously assume the logic behind it is just as sound.
2. The Interview Deck: The "Director’s Cut"
Format: A curated Keynote, Figma prototype, or PDF. The Goal: To prove you can navigate the "messy middle."
Once you’ve cleared the "Do they have taste?" hurdle, you’ll be invited to an interview. This is where the website usually fails and the Project Portfolio shines. This isn’t a public URL; it’s a controlled narrative you present live.
The Vibe: Sketches, failed iterations, stakeholder pushback, and data pivots. This is the "how the sausage gets made" documentary.
The Storytelling: While the website shows the shipped asset, the deck shows the shipped value. Use this space to talk about the trade-offs. Why did you choose Option B when the CEO wanted Option A? How did you handle the technical constraints?
Why it works: It demonstrates seniority. Junior designers show the "happy path." Senior designers show how they navigated the obstacles, managed the ego in the room, and still delivered a high-quality product.
The "Third Asset": The Personal Proof of Work
If the first portfolio is the What and the second is the How, there is a silent third asset: the Who.
In a world of AI-generated case studies and template-heavy sites, the most engaging portfolios are the ones that show a designer’s "side-hustle" energy. Whether it’s a passion for vintage furniture restoration, a woodworking project, or building a niche reselling site, these "off-the-clock" projects signal a fundamental curiosity.
They show that you don't just "do design" for a paycheck—you have an innate drive to build, refine, and improve things.
The Bottom Line
Stop trying to cram your entire design process into a scrollable webpage. It kills the mystery and slows down the user experience.
Build the Website to Hook them: Make it punchy, visual, and undeniably beautiful.
Build the Deck to Close them: Make it analytical, narrative-driven, and honest about the struggle.
When you separate the Showcase from the Story, you give yourself the freedom to be both a world-class artist and a pragmatic problem solver.
Since the goal of this deck is to be the "Director's Cut" of your work, it needs to focus on decision-making rather than just pixels. In a live interview, stakeholders aren't just looking at what you built—they're looking at how you think when things get difficult.
Here is a 7-slide structure designed to bridge the gap between a beautiful "showcase" website and a high-stakes interview.
Slide 1: The Hook (Title & Context)
Don't just name the project. Give it a mission statement.
The Content: Project Name, Your Role, and a "TL;DR" (Too Long; Didn't Read) of the outcome.
The Key: State the Business Goal immediately.
Example: "Redesigning the Checkout Experience to reduce cart abandonment by 15%."
Slide 2: The "Why" (The Complicated Problem)
This is where you show the stakes. Use data or user quotes to ground the problem.
The Content: What was the pain point? Why was this hard to solve? (e.g., "Technical debt meant we couldn't change the API, but users needed a faster way to pay.")
The Goal: Establish that this wasn't a "make it pretty" project; it was a "solve a puzzle" project.
Slide 3: The Messy Middle (The Pivot)
This is the most important slide. Show a version that didn't work.
The Content: Side-by-side comparison of an early exploration vs. the final direction.
The Story: "We initially thought [Assumption A], but after [User Testing/Technical Constraint], we realized we had to pivot to [Assumption B]."
The Pro Tip: Showing "failed" iterations proves you aren't precious about your work—you're focused on the right solution.
Slide 4: Strategic Trade-offs (The Reality)
Every project involves compromise. Senior designers are the ones who can explain why they compromised.
The Content: Use a simple table or list to show what you prioritized.
PrioritizedDe-prioritizedSpeed to Market (MVP)Custom AnimationsAccessibility ComplianceUnique Branding Elements
Slide 5: The "Aha!" Moment (High-Fidelity)
Now you can show the beautiful mocks from your website, but with a voiceover.
The Content: A high-quality video or prototype link.
The Story: Focus on the Interaction Design. Explain how a specific gesture or flow solved the friction you mentioned in Slide 2.
Slide 6: The "So What?" (Impact & Metrics)
Designers often forget to talk about the business. Don't be that designer.
The Content: Hard numbers (conversion rates, NPS, time saved) or qualitative wins (stakeholder buy-in, team adoption).
The Goal: Prove that your design wasn't just an output; it was an investment that paid off.
Slide 7: Retrospective (The Human Element)
What did you learn that you’ll take to your next role?
The Content: One thing that went well and one thing you would do differently next time.
The Goal: This shows humility and a growth mindset—qualities every hiring manager is looking for in a long-term teammate.
Tips for the Presentation:
Keep it in Figma: If you're applying for a product role, presenting out of a Figma prototype allows you to jump into the "working files" if they ask a deep-dive question.
Less Text, More Talk: Your slides should be 80% visual. The "story" should come from you.
The 20-Minute Rule: Aim to get through the deck in 20 minutes to leave 10 minutes for a healthy Q&A.