--- title: My actual Claude Code workflow as a designer description: "The real daily loop I use to design and ship products with Claude Code. Not a tool list. Four steps, one taste file, and where the human still stays in the work." date: 2026-07-20 tags: [ai, design, workflow, claude-code] url: "https://mahdif.com/blog/my-actual-claude-code-workflow-as-a-designer/" --- # My actual Claude Code workflow as a designer The real daily loop I use to design and ship products with Claude Code. Not a tool list. Four steps, one taste file, and where the human still stays in the work. I am a product designer. I have been one for 17 years. And most mornings now I don't open Figma. I open a terminal. That sentence would have sounded like a gimmick to me two years ago. Today it's just how I work. In the past few months I rebuilt my portfolio site from Astro to Next.js, built a full job search app with its own feed and pipeline, and turned a folder of markdown files into a system that runs half my life. I designed all of it. AI wrote most of the code. Every piece shipped. This post is the actual workflow. Not the influencer version. The loop I run daily, including the parts that are unglamorous.
THE DESIGN-TO-SHIP LOOP 01Write intentnot specs 02Load contexttaste in a file 03Reviewin the browser 04Commitship the PR REPEAT EVERY PHASE
The loop, start to finish. Every phase runs it again.
## Step 1: I write intent, not specs Every build starts with a few plain sentences. What I want, who it's for, and what done looks like. Not how to build it. Here's a real one from my job search dashboard: "I want a side panel that opens when I click a role. It should lead with what I need to do next. Everything else collapses." That's it. No wireframe. No spec doc. The spec was always a translation layer between my head and someone else's hands. When the same person holds both, the translation disappears. I still sketch when the problem is genuinely visual or novel. But that's the exception now, not the rule. ## Step 2: The context does the heavy lifting This is the part most people skip, and it's the part that matters most. Claude Code reads files before it writes code. So I keep files worth reading. Every project has a conventions doc: the stack, the design rules, how things are named, what not to touch. And I keep a written taste file. Mine says things like: light by default, no drop shadows, separation comes from hairlines and tone, collapse detail until it's asked for, strong typography, cut anything that doesn't earn its place. That file is the difference between getting generic AI output and getting something that looks like I made it. AI has taste defaults. They're not mine. So I wrote mine down, and now every session starts from my defaults instead.
taste.md loaded at the start of every session The file every project starts from. AI has taste defaults. These are mine. Light by default Hairlines and tone, never shadows Collapse detail until it's asked for Strong type, clear hierarchy Cut what doesn't earn its place
A real page from how I work. The agent reads it before it writes a line.
Designers have always been good at articulating principles. It turns out that skill compounds now. A principle you can write clearly is a principle an agent can apply while you sleep. ## Step 3: Build in phases, checkpoint each one I don't ask for the whole thing. I ask for a phase, review it, save progress, then move on. When something goes wrong, and it does, I lose an hour instead of a day. The review isn't a code review first. It's a design review. I open the thing in a browser and use it. Does it feel right? Is the hierarchy honest? What can I remove? Same questions I've asked for 17 years. The mockup just happens to be real now. Then I push back in plain language. "The table is too dense." "This animation is trying too hard." "Why are there three greys here?" The agent revises like the strongest production partner I've ever had: no ego, infinite patience, ships in minutes. ## Step 4: Everything ends in a commit Real repo, real commits, real deploys. This is non-negotiable for me, and it's the same conviction I built my last product on: AI wins when it ships a PR, not a suggestion. Output you can't ship is a demo. Output in version control is progress. It also changed what my design artifacts are. My source of truth isn't a Figma file anymore. It's the codebase. When design lives where the product lives, it can't drift out of date. ## Where the human stays Here's the honest part. The model is genuinely good at building. It is not good at knowing what's worth building, when something feels off, or what to delete. That's still the job. My time didn't shrink. It moved up a level. Less pushing pixels, more deciding, reviewing, and cutting. I kill features I built the same week I built them, because building got cheap enough that sunk cost finally died. The fastest teams treat everything as disposable. Now one person can. And the model is sometimes wrong. I design for that in my products, and I work that way with my tools too. Small phases, verifiable checkpoints, everything reviewable. Trust the loop, not the output. ## If you're a designer wanting to start Start with your own problem, not a client's. Build a tool you'll actually use. The feedback loop of using what you made teaches faster than any course. Write your taste down. Seriously. One page of design principles you actually believe. It will improve every AI interaction you have. And lower the stakes. Your first build doesn't need users. Mine was my own website. The tenth one might matter. The first one just needs to ship. Designers keep asking whether AI will take the craft out of the work. After months of working this way, my answer is the opposite. I've never spent more of my week on judgment, taste, and deciding what deserves to exist. The production moved to the machine. The design moved back to me.