One Product Designer, Six Projects at Once: His Five Workflows, Down to the Claude Skill Source Code
- A product designer at a VR fitness company went from handling 1 project to 6 in six months, with iteration cycles measured in days.
- His takeaway is that AI actually changes the scope a designer can cover, but the real gold is in the five workflows, each paired with a genuine screenshot.
- The most valuable bits are all in the screenshots: the full trigger conditions and output templates for a Claude Skill, an AI-written data logic doc, and a branching prototype built with just two fields.
What He Did: From 1 Project to 6 in Six Months
Krystian Zun is a product designer at VR fitness company FitXR with over eight years of experience building 0→1 products. Six months ago, he was focused on a single project. Now he's juggling six simultaneously—handling brainstorming, system logic, prototyping, tickets, and progress updates himself, with iteration cycles of just a few days. He's sharing the five workflows he's developed over this period, each backed by real screenshots. The full Claude Skill definition, the AI-generated data logic document, and the branching prototype implementation are all ready to be copied verbatim.
His own framing is this: AI is usually seen as a speed tool—getting the same work done faster. After a year, he thinks that framework misses the point. What it truly changes is scale—how much a single designer can own end-to-end. Speed is just a byproduct. He stresses that he hasn't gotten smarter or started working longer hours; what changed is where his attention goes, and the rest is delegated to AI.
The catalyst was FitXR, which he describes as the fastest-paced place he's ever worked. In the first few months, he kept shipping experiments and quickly hit a wall: he needed to find a way to keep up. Since then, whenever he hits a bottleneck, he asks himself the same question:
Can I find a way to inject AI into this?
Krystian Zun
Can I offload part of it? Make it faster? Get a better result? It's all been trial and error, he says, including figuring out where AI doesn't help—or slows him down—where doing it himself is better. Unfortunately, he didn't give a single example of that, which is the biggest gap in the whole piece. More on that later.
His Mental Model: AI Extends the Horizontal Bar of the T-Shaped Designer
The design world has an old concept: the T-shaped person. The vertical stroke is your deepest expertise—UX, UI, research, motion, whatever it is. The horizontal bar is your ability to span other disciplines and get things done—not at the same level or speed, but enough to move the work forward.
AI lengthens that horizontal bar. It makes him significantly faster in areas where he's not an expert.
Here, he offers a refreshingly honest caveat, worth quoting directly: the benefit varies by domain and by person. For instance, AI still fails at high-quality visual design—at least by his standards, by what he demands of himself. But give a developer who isn't a designer a prompt to generate a simple landing page, and the result looks surprisingly decent.
The second layer is about what the job of a designer actually is. He breaks it down to its core: understanding the problem, understanding the connections and impacts across business, technology, and product, and then finding a solution that ties it all together. In practice, it's a constant loop of switching directions, changing approaches, and iterating until something clicks.
AI makes this loop faster. He says he uses AI like a sketch or a paper prototype: the output isn't the point; pushing his thinking past the "obvious" layer is.
Workflow 1: Handing Weekly Reports and Tickets to a Claude Skill, He Just Approves or Skips
First, a crucial premise that determines whether you can copy this: FitXR doesn't have product managers in the traditional sense. The projects and their day-to-day operations are handled by the people building them. Scheduling, alignment, writing tickets, updating progress, reporting to management—all of it piles on top of the core design and engineering work. So they automate whatever they can.
His stack is Claude + Skills + MCP connected to Slack, Granola, and Linear.Granola is a meeting notes tool that transcribes calls and creates summaries; Linear is the team's project and task management tool.
The chain has three steps:
Granola handles the context. The team is remote, and context is scattered across Slack threads, stand-ups, and calls. With it, he can be truly present in meetings instead of heads-down taking notes. Then, each weekend, a Skill scans those transcripts and Slack messages, drafting Linear progress updates for different roles and people.
A second Skill manages "drift." He says his team is notorious for making decisions in Slack and never leaving Slack. This Skill compares conversations against Linear tickets, flagging discrepancies: scope changes that weren't synced back, incorrect statuses, decisions made but not recorded. He reviews each suggestion, approves or skips, and it's done in minutes.
He's currently involved in six projects, all part of the same larger picture, but each with its own details, challenges, and loose ends. A few months ago, he could only give this level of attention to one project. His conclusion: if he had to track all of this manually, it would easily become a full-time job. AI can't replace involvement and understanding, but it can offload the repetitive, time-consuming parts.
The Skill Source Is in the Screenshot: Trigger Conditions and Output Template
This section isn't in the article text at all—it's read entirely from the middle panel of the screenshot above. The Skill is called linear-status-update, and its trigger is "slash command + automatic."
Its description is almost entirely about "when to show up."
The description spends most of its space enumerating the ways a user might phrase a request: draft an update for the project, write a status update, update Linear based on slack, write a project update from our meetings, pull together a project update, plus "any combination of source (Slack, Granola, meetings) and destination (Linear, project update)." It ends with a safety net:
Use this Skill whenever compiling recent activity into a Linear update, even if the user doesn't mention the word 'skill'.
Skill description from screenshot, translated by us
This approach is worth learning in itself. Skill writers tend to pour all their energy into "how to do it," and the result never gets triggered when it should. The more specific and natural the trigger conditions are, the more reliable it becomes.
Step 3: Figure Out What's New Before Writing
Step 3: Identify what's new
Before drafting, work out:
- What has happened since the last update?
- What decisions were made?
- What was completed? What's in progress?
- Are there any timeline changes, milestone shifts, or blockers?
- Is there any significant engineering or enablement work worth
calling out?
Focus on substance. Ignore noise like channel join messages, bot
notifications, and minor logistics. If something was already
covered in a previous update, don't repeat it.Chinese reference: Before writing, figure out what's happened since the last update. What decisions were made? What's done, what's in progress? Any timeline changes, milestone shifts, or blockers? Any significant engineering or enablement work worth highlighting? Focus on substance. Ignore noise like join messages, bot notifications, and minor logistics. If it was already covered last time, don't repeat it.
The last two lines are the ones to steal. Weekly reports usually fail from too much noise and repetition, not a lack of information. Writing down what to ignore is more effective than writing down what to write.
Step 4: Match the Project's Existing Format First, Fall Back to the Default Template
Step 4 starts with "strictly follow the format and tone of the project's existing updates," and only falls back to this default template when there are no historical updates: