Role
Product Designer
Team
2 developers,
1 product owner
Tools
Cursor, Codex, Github, Figma
Timeline
2 weeks
Overview
A tool for publishing announcements to insurance advisors and brokers
InsurFact's internal ops team publishes announcements, product news, sales tips, webinars, that appear on the front-facing platform for insurance brokers and advisors. This tool is how they create and manage those announcements.
Before the redesign, publishing one announcement took about 12 minutes
The form was disorganized, content and settings were mixed together with no clear structure, and admins had no way to preview what an announcement would look like to brokers without navigating away from the tool entirely.
The Problem
A form built around the data model, not the admin user's workflow
The original tool surfaced every field in a single undifferentiated form. Content fields and configuration settings sat next to each other, multiple content types (HTML, PDF, video, URL) shared the same form layout, and there was no preview capability. Admins had to open the advisor-facing platform in a separate tab to verify their work.
Painpoint 01
No structure between content and settings
Everything lived in one form. Admins had to scan the whole page to find what they needed each time.
Painpoint 02
No preview in context
To check how an announcement looked to brokers, admins had to leave the tool and navigate to the front-facing platform.
Outcome
From 12 minutes to 5 without touching the backend
↓ 58%
Task time
2 weeks
Design to ship
Constraints
What I had worked within
01
No backend changes
I could only redesign the interface. Data structure and APIs had to stay exactly the same.
No new endpoints, no schema changes.
02
Admin side only
The advisor-facing announcement display was untouched. Any preview had to work within the admin context.
03
Existing tech stack
The product is built on PrimeVue with Tailwind CSS. Solutions had to work within what was already in place.
User Research
I observed how admins used the tool and organized three insights
I sat with an internal ops admin while they published a typical announcement.
Rather than asking what felt difficult, I watched how they actually moved through the task where they paused, what they re-read, and what pulled them out of the tool entirely.
Insights
01/
Scrolling constantly to re-check what was already filled
02/
Filling fields out of order, jumping back and forth
03/
Logging into advisor profiles to check how it looked
Design Goal
HMW help admins publish announcements faster by making the form easier to navigate ?
Design solution 01
From a modal to a dedicated page
The original add/edit experience lived in a modal, which severely limited how much information could be surfaced clearly.
I moved it to a dedicated full page. This gave enough space to separate content from configuration, and made room for a proper preview experience.
This was the single biggest structural change. Everything else depended on having enough canvas.
Design solution 02
Organize by what admins decide, not by data schema
The original form was structured around the database: fields appeared in the order they existed in the schema.
I reorganized it around the admin's decision-making process: first decide what you're publishing (content), then who sees it and when (settings).
Content fields moved to the left.
Configuration, audience targeting, scheduling, distribution, moved to a right sidebar.
Admins no longer had to scan the entire form to find what they needed.
Design solution 03
Add preview as a tab
Admins were spending time navigating to the broker-facing platform just to check how an announcement looked. This was the biggest single driver of the 12-minute task time.
I looked at how other tools handled this. Most SaaS content tools offer a real-time preview that renders as you type.
That would have required building a new renderer in the admin context which is a significant engineering lift.
Instead, I proposed a tab-based preview that reuses the existing broker-side render.
Less engineering cost, same outcome for the admin.
Competitive analysis
How other tools handle preview
Before proposing the preview solution, I reviewed four preview approaches used across content management tools by evaluating each against the constraints of this project.
Design tradeoff
Submit-first preview
This isn't real-time preview. Admins need to submit before the preview tab appears.
Building a live renderer would have required backend changes outside the project scope.
Instead, the preview tab reuses the existing broker-side render, so what admins see is exactly what brokers see.
The real win is eliminating the account-switching detour.
Five steps across two sessions became one submit inside the same tool.
Known limitation: if something looks wrong in preview, they'll need to edit and resubmit.
