How I Get Better UI from Claude: Research First, Build Second
Source: Dev.to
The Problem with “Build Me a Component”
When you ask Claude to build a UI component directly, it pulls from its training data. That means you get a mix of patterns it’s seen—some good, some dated, some just weird.
I was building a typing indicator for my Angular AI UI component library (those animated dots that show when the AI is thinking). My first instinct was to just ask Claude to build it.
Result: Functional, but forgettable—three bouncing dots that looked like every tutorial example from 2019.
The Fix: Make Claude a Design Researcher First
Research Prompt
I asked Claude Code (using Opus 4.5 in research mode) to research the problem first:
Research how typing indicators are used in modern web apps,
especially AI chats like ChatGPT, Claude, and Gemini.
Look at design patterns, animations, and how they signal
different states.Giving it specific examples of well‑designed apps makes a huge difference. Claude now has a reference point for what “good” looks like in this specific context.
The research returned insights I wouldn’t have thought to look for—how ChatGPT uses a pulsing effect vs. Claude’s shimmer animation, how Gemini handles the transition between thinking and responding, and accessibility considerations for motion‑sensitive users.
Feed the Research Back
I take the entire research document and paste it into a new conversation, then ask Claude to build the component with that context:
Based on this research, build me a typing indicator component
for Angular that follows modern AI chat patterns. Make it
polished and professional.Result: A night‑and‑day difference. Instead of generic bouncing dots, I got a component with:
- Subtle animation timing that feels natural
- Smooth state transitions
- Design choices that actually make sense for an AI‑chat context
- Details I wouldn’t have specified myself
It looks like something that belongs in a production app, not a weekend hackathon.
Why This Works
Claude is good at following patterns, but the problem is which patterns it follows. When you ask it to build something from scratch, it averages across everything it knows, yielding median design quality—safe, boring, forgettable.
When you give it focused research on how the best apps solve this exact problem, it has a much tighter reference point. It’s no longer guessing; it’s applying specific patterns from apps you actually want to emulate.
Think of it like this: asking Claude to “design a button” vs. asking it to “design a button like Stripe’s dashboard” yields completely different results. Research mode automates finding those references.
My Workflow Now
For any UI component that needs to look good:
- Step 1: Ask Claude (Opus 4.5, research mode) to research the problem.
Research how [component] is implemented in modern apps like [2‑3 specific well‑designed examples]. Focus on design patterns, animations, and UX details. - Step 2: Review the research (sometimes it surfaces things you didn’t know to ask for).
- Step 3: Paste the full research document into a new conversation.
- Step 4: Ask Claude to build with that context.
The extra five minutes of research saves hours of tweaking generic output into something that actually looks professional.
When I Use This
I don’t do this for every component. Simple stuff like form fields or basic layouts—Claude handles those fine without research.
But for anything that needs to feel polished:
- Complex interactive components
- Animations and micro‑interactions
- Components where “feel” matters (chat UIs, dashboards, onboarding flows)
- Anything users will see repeatedly
That’s when research‑first pays off.
The Bigger Point
AI‑assisted development isn’t just about speed. It’s about using AI at the right step.
Most people use Claude as a code generator, but it’s also a researcher, a design consultant, and a pattern library—if you prompt it that way.
The typing indicator I built is now one of the best‑looking components in my library. Not because I’m a designer, but because I let Claude do the design research before writing a single line of code.
Try it on your next UI component: research first, build second.