Integration setup was unclear and hard to verify
The Integration Overview page, the central place for setting up and managing integrations was unclear, fragmented, and hid key information by default. Users often couldn’t tell if their setup was complete or working, leading to delays and repeated support requests.
Adding to the complexity, this project had to be designed and built directly in the production codebase using Roo + MCP in Angular. There were no static mockups or traditional handoff, every interaction and state needed to be tested live with real data, requiring design decisions to happen in real time alongside implementation.
Our high level goals were to:
Make integrations easy to understand and complete
Reduce uncertainty and improve visibility across all integration types
Deliver a consistent, scalable experience for both developers and GTM teams
Led end to end design and implementation in production code
I led UX research, strategy, design and development for the Integration Overview page, working directly in production code with Roo + MCP in Angular. This meant bypassing traditional static mockups and instead designing in the medium of the product itself, with AI-assisted tools accelerating component creation and iteration.
Synthesized large scale user feedback into actionable priorities
We approached this in two steps: (1) broad discovery across support chats Reddit threads and internal docs to find recurring issues, then (2) a focused sprint to target key personas and prioritize critical pain points.
Two-step discovery narrowed thousands of conversations into actionable priorities
Early Research & Insights
We began by reviewing a large volume of qualitative and quantitative feedback:
1,412 support conversations
962 Reddit threads on deliverability and integrations
Internal documentation and product behavior patterns
From this, we identified recurring friction points across SMB and enterprise customers:
Lack of visibility into integration state
Unclear or fragmented setup steps
Uncertainty around API behavior
Persona Targeting & Prioritization Sprint
After a wide ranging discovery, we shifted into a focused 1 day UX sprint. Research pointed us to two high impact personas: Developers, implementing integrations, and GTM stakeholders in Ops, Finance, and Marketing, managing them. Their high ticket volume, revenue impact, and central role made them our priority. As part of the workshop, we mapped the full Zapier integration journey, capturing user actions, goals, feelings, and pain points. For this case study, I’ve distilled it to the core steps before the redesign to give quick context.
bounce
issues
Search online for “email validation”
finds LetterBound
Lands on
LetterBound homepage
Navigates
to API
list page
Creates
new
integration
Integration
overview
page
Locate &
copy
API key
In Zapier:
Paste copied API
key into Zapier
authentication and
test the Integration
Check results,
usage
breakdown...
No
Form
valid?
Yes
Signs up
Compare
bounce before/after
Simplified baseline Zapier integration flow — case study version of the full journey map
From the journey map, we captured 28 pain points, clustered them via affinity mapping, and used these clusters to drive prioritization:
Integration Visibility
Where’s the
API key?
Unsure
if key
active
Missing
status
Is the
integration
active?
No alert
on failure
Where is
last sync
date/time
Usage chart
empty on
first load
Collapsible
sections
hide info
Key actions
low visibility
areas
Process Clarity
Order of
steps?
Unclear
required
vs optional
Naming app
is a blocking
modal step
3rd-party
flows fail
Unclear where
to change
settings
setup info
below the
fold
Cost & Usage Transparency
Cost impact
unclear
Past activity
disappears
quickly
Usage
reports
lack
context
No cost
breakdown
Test cost
unclear
Billing
unclear
after tests
API Behavior
API key is
hard to find
Better
sandbox
testing
No feedback
when key
copied
Navigation/Info Placement
Confirmation
messages
out of view
Similar
settings
split
Context links
open new tabs
unexpectedly
Affinity mapping results from usability pain point analysis
We synthesized these findings into a prioritization matrix, mapping each issue by Impact (user value) and Effort (implementation complexity).
Where’s the
API key?
Collapsible
sections
hide info
Naming app
is a blocking
modal step
Test cost
unclear
Is the
integration
active?
Order of
steps?
3rd-party
flows fail
Better
sandbox
testing
Prioritization of pain points based on estimated implementation effort vs. user impact
The high-impact items became the sprint’s focus, turning a wide field of problems into a tightly scoped action plan. This ensured we addressed the most valuable improvements first while deferring low impact changes to future iterations
#04
Designed and iterated directly in production code
With priorities locked, the sprint shifted from decision-making to execution. Instead of moving into traditional wireframes, we built directly in the product’s codebase, allowing design, testing, and refinement to happen in real time.
Using AI-driven tools Cline and Roo, we could write natural-language prompts that generated production grade Angular components, styled automatically with SCSS tokens from a visual spec we authored. This let the design system live in code, and made prompts the interface into the component layer.
Prompt (chat)
Roo output (HTML)
Token peek (SCSS)
Natural-language prompt → production output + token mapping
This approach meant that every improvement could be designed, tested, and shipped in days, not weeks. The following transformations show how these high impact priorities moved from friction to clarity in the live product.
Made setup details, status, and next steps visible by default to clarify integration setup
Before breaking down the detailed changes, here’s the redesigned screen at a glance, a cleaner two tab layout applied across integration types.
API Key tab, as applied to the Zapier integration (setup details visible by default)
API Key tab, as applied to the JavaScript widget integration (inline snippet instructions instead of a key)
Usage tab, as applied to a Custom integration (reorganized filters and clearer request breakdowns)
No More “Where’s the API Key?”
Problem
Our #1 reported blocker: critical setup elements, including the API key, were collapsed by default. New integrations opened to an empty usage chart, leaving the API key hidden and driving repeated confusion.
Solution
We surfaced essential setup details front and center, with the API key visible by default. To further streamline the experience, we replaced long, collapsed sections with a tabbed layout, moving slower loading usage data to its own tab. This reduced visual clutter, improved load performance, and kept the configuration area focused on setup.
API key visible by default — setup details in plain sight from the first interaction
No More Blocking Modals
Problem
Creating a new integration opened a modal where users chose a type and entered a name. Most clicked “Create App” without naming it, triggering errors and repeated drop-off.
Solution
We removed the modal entirely. Integration type is now chosen from a dropdown, and the app is created instantly. Users land directly on the overview page with the name highlighted in edit mode. If they don’t rename it, a default name is applied automatically, eliminating blockers and keeping momentum.
Removed modal - app created instantly, name highlighted inline — no blocking step, no errors
No More “What Do I Do Next?”
Problem
After creating an integration, users often stalled, unsure what actions to take and whether running a test would consume credits. This uncertainty led to hesitation, mistakes, and incomplete setups.
Solution
We introduced a persistent step panel that provides clear, sequential guidance tailored to each integration type. It explains test behaviour, cost implications, and required actions, ensuring users can proceed confidently without guesswork.
Persistent step panel — clear guidance, cost transparency, and next actions made explicit
No More “Unclear Status”
Problem
Users struggled to confirm whether their integration was active. Without a clear state indicator, they had to guess or troubleshoot unnecessarily.
Solution
We introduced an explicit status tag (e.g., “Connected” or “Not Connected”) on all integrations, so setup state is visible at a glance.
Clear status tags — integration state visible immediately, no guessing required
These fixes cleared up the biggest sources of confusion and made setup easier to follow. It’s a solid step forward, but the work is still in progress.
Designing in code reshaped how we ship
This project redefined how our team approaches design:
Designed directly in code: built, tested, and shipped without traditional mockups.
Shifted perception of design’s role, from static handoffs to live.
Laid groundwork for system level change, establishing a base for consistent, scalable improvements
Next iterations focus on guidance, feedback, and system depth
We’ve solved the biggest usability issues, but there’s more to do, from small tweaks that smooth the flow to bigger changes at the system level.
Quick Wins
Replace empty graphs with guidance and clear CTAs.
Add hover states and tooltips for key areas (code block, status chip, filter chips).
Give feedback (like animation or toast) when the API key is copied.
System Improvements
Keep refining prompt based components so styles stay consistent (tabs, badges, chips).
Future Exploration
A dashboard view across multiple integrations (active, failed, pending).
Contextual onboarding for first time users.
So far, the biggest blockers are gone and setup feels smoother. Next up: tightening the details and building a stronger system around it.
