Self-initiated · Product design + AI build · 2026 · 8 min read
Focus Forest
Building a real, interactive prototype by directing AI tools, with no code experience.
Focus Forest is an easy-to-use, motivational mobile app that combines a calendar, to-do list, and countdown in one place, with an animated jungle scene where people level up and unlock new animals as a reward for staying organized. I conducted the UX research and designed three key screens in 2022 when I moved from architecture into UX.
In 2026, I returned to it to bring it to life, building it with AI tools, with the code on GitHub and deployment handled by Vercel.
On naming: in this case study, "Claude" refers to the chat app; "Claude Code" and "Claude Design" are separate Anthropic products.
Approach
The experiment
By 2026, four years into my career as a Product Designer, I wanted to see what a designer's workflow looks like when AI handles the code. I had no coding experience. My goal wasn't to learn to code, but to stay in the architect's seat: directing, deciding, verifying while AI assisted me in building the remaining screens and shipping a real, interactive prototype.
The question I was testing
Could I take a fully researched design from static screens to a shipped, interactive prototype without writing the code myself?
My goal
An interactive prototype, live on Vercel: a locked design system, a library of reusable components, and working key screens with real interactions and a preview of a jungle animation.
Building with AI
A workflow where each tool had a different job
I kept the judgment for myself and let each tool do what it does best:
Claude Design
Built the design system (tokens, typography, components) as real CSS and HTML.
Claude
Strategist and thinking partner: planning steps, brainstorming ideas, information architecture, prompt drafting, and creating new screens as previews.
Claude Code
The actual builder. It read the real source files and wrote the code.
Cursor
The fallback builder. When Claude Code hit its usage limit mid-session, I switched to Cursor to keep moving.
GitHub & Vercel
Code on GitHub, with deployment handled by Vercel.
Where I sit in the workflow
From the design system through to deploy, the tools changed at each step, but my place in the loop never did.
A prompt framework I developed
Prompt quality determined output quality, so I converged on a four-part structure and used it for every meaningful prompt:
- Role: Who the AI should be.e.g., "You are a senior frontend engineer specialized in AI-assisted UX/UI…"
- Context: The situation.e.g., "I'm building a motivational calendar app for people who struggle to organize events…"
- Task: What I want.e.g., "Generate a step-by-step plan to…"
- Outcome: The format.e.g., "Short, clear bullet points"
The workflow evolved as I went
At first I had Claude check every change Claude Code made, and when Claude Code hit its usage limit mid-session, I brought in Cursor as a second builder to keep moving. Once the changes were reliably matching the plan, I let Claude Code build and self-check across files, and kept Claude for the higher-level calls, consistency, accessibility, and UX. The valuable part wasn't choosing the tools; it was spotting when a step in my own process had stopped earning its keep.
The build, phase by phase
Phase 01: Setting up the design system
Claude Design
I fed Claude Design the typography, colors, and key screens I had designed in Figma back in 2022, and iterated on them. From there, it generated the design system as real artifacts, most valuably a colors-and-typography CSS file with the actual variables, which skipped an entire "translate the design into code" step later.
Two issues came up:
- Prompting directly inside the Claude Design chat gave unpredictable results, fixed by using a separate Claude conversation as a prompt engineer.
- It hit its weekly limit fast, fixed by scoping it to the foundation only, then moving on.
Phase 02: Exploring
Claude, in a dedicated project folder
Putting the design system into a Claude project folder was the unlock. With my tokens, typography, components, and existing screens in context, it could explore with me.
I worked through the information architecture of the app (e.g., the previous labeled "Progress" tab became a new "Today" daily dashboard, or the gamification moved to an "Up next" teaser on Home), and it drafted first screen concepts straight from the design system, each previewed as HTML right in the chat, instant to view and iterate on.
Phase 03: The workflow between tools
Claude ↔ Claude Code
I tested an approach where Claude wrote meticulous specs, which I then pasted into Claude Code and reviewed together with Claude. It was too slow, and Claude Code often missed details anyway.
The fix: Simpler prompts, often with a screenshot attached. Claude Code understood those much better, and the workflow was faster.
Phase 04: Building the screens
Claude Code, verified in the browser
I built the key screens: Home, To-Do, Calendar, Today, and Profile. The visual result in the browser was where I checked the work: something could look finished in code and still be wrong until I actually saw it.
The hardest piece was automatic scroll on the Calendar: tapping a day should scroll its agenda to the top. It required refinement as the sticky header grew, exactly the kind of bug that only reveals itself when you actually scroll it in the browser.
Phase 05: Animation & polish
Claude for planning · Claude Code for implementation
The jungle animation on Home (trees swaying, the bird bobbing, the frog blinking) with reduced-motion preferences respected. Because it was built in code rather than dropped in as a fixed image, I could keep tuning the motion until it felt right.
Phase 06: Deploy
GitHub (Source) · Vercel (Deploy)
Once the refinements were done and verified in the browser, I pushed to GitHub, and Vercel auto-deployed it, producing the live, shareable URL of the prototype.
How I work
Three decisions that show how I work
Throughout the build, I stayed in the architect's seat: directing the vision, making design calls, and verifying every output.
Protecting a deliberate choice
When a clean rule would erase a deliberate choice, the choice wins.
Catching what only shows in the browser
Some problems never show up in the diff, only once the page renders in the browser.
Deciding what to leave out
AI makes adding features easy; good design is knowing what to cut.
A real example from my workflow
While building the "Tabs" component, Claude took the pattern I'd already set and proposed it as a system rule: "yellow = action, white = navigation". It sounded right.
But I flagged it: applied there, the rule would have stripped the deliberate yellow from the "Add" button. Yellow was a real decision: more inviting to tap than white. I retracted the system-level rule and let each component reference its own color.
Even a rule drawn from my own system can flatten a deliberate exception. Knowing which inconsistencies are intentional is the design call.
A real example from my workflow
After I built the bottom nav, the code compiled, no errors, the diff looked clean. I checked the visual result in the browser and immediately flagged what code review had missed: the "Add" button's top half was clipped by the wrapper's overflow.
Clean code isn't a finished screen. I judge the design where the user meets it: in the browser.
A real example from my workflow
Because building with AI made new ideas fast to try (streaks, stats, sharing), the easy move was to keep adding.
I cut back to the core loop, calendar, to-do, countdown, and the jungle reward, so the prototype stayed legible and the story clear.
AI makes building easy. The design skill is deciding what not to build.
Honest notes
What worked, what didn't
What worked
- Writing prompts as short bullet points worked reliably: Claude and Claude Code both understood them correctly, working through the bullets in order.
- I was able to build the entire design system with Claude Design, delivered as CSS, so Claude Code could build straight from it, with no "translate design into code" step.
- With Claude, I could brainstorm and build screens I'd never designed in Figma. Each previewed as HTML right in the chat, so I could refine the layout and content before giving it to Claude Code to build.
- Claude Code built the jungle animation as real, reduced-motion-aware CSS, not a static image.
What didn't
- Claude Design's weekly limits hit fast, so I scoped it to the design-system foundation only.
- I tested prompting directly inside Claude Design, but results were inconsistent. Drafting prompts first in a separate Claude conversation worked better.
- Detailed prompts pasted into Claude Code didn't work well. Simpler, screenshot-based prompts were far more effective.
- Claude Code response times on complex prompts can reach around 10 minutes. I worked around this by batching related changes.
AI makes designing and building fast. Judging whether it works as good UX is still the designer's job.
What I'd do differently
Plan around AI tool limitations
Schedule Claude Design sessions to fit its weekly limit, and defer anything the other tools can do.
Match the prompt to the tool
Prompt style varies by tool. I'd recognize an approach that's not working properly or is too slow sooner and pivot. When a tool doesn't understand what I mean, a screenshot usually makes it clear.
The interactive prototype
See it running
The result: a deployed, interactive prototype with 5 working screens, a complete design system, and real interactions, built without writing code myself.
Built on a modern React stack (Next.js, TypeScript, Tailwind) with a custom design system: a 13-color palette, a 9-step type scale, and 9 accessible component primitives, each built 1:1 to a locked design reference.
Reflection
What it demonstrates
The honest framing isn't "AI built this for me". It's: I designed a workflow where AI handled the implementation, my design judgment handled the verification, and the product carries both signatures. Along the way the workflow kept breaking and forcing me to redesign it, which taught me that a process is a living thing you tune, not a setup you do once. That, more than any single screen, is what I took into the next project.
Where I'd take it next
A single real-life moment, for example, a birthday party, currently lives in three separate places in the app: a calendar event (the date), a countdown (how long until it), and a to-do (buy a gift). The 2022 research found this was the core pain point: when non-calendar tasks get separated from their dates, people lose track of them.
The direction I would like to take Focus Forest is to act like a connector between events: it would link their date, countdown, and related to-dos into one place. This solves the exact problem the research identified.
Foundation
UX Research · 2022
Gathered 45 survey responses · 5 user interviews · 5 apps analyzed
Produced persona · user flows · wireframes · hi-fi screens
Before any of the AI build, Focus Forest began as a research-led UX project in 2022. To ground the design, I ran a 14-question survey (under five minutes) and five 30-minute interviews with people aged 26 to 40. Together they pointed to a clear brief: a mobile-first, visually clean app whose most important job is helping people remember their schedule.
Interview pain points Named by all 5
- Hard to remember events like birthdays and appointments
- Reminders stop before the task is actually done
- Alerts disappear too early, before you're finished
- No way to check tasks off
What they needed (5/5): alerts · multiple reminders · checking-off