Build in Public Day 7: UI/UX Optimization — Getting Demo-Ready

With the landing page live, I came back to the application prototype to refine it for real demos with prospects. The goal: walk through the entire experience as a user, identify friction, and polish until it's ready to put in front of real people.

Walking Through as a User

I opened the prototype and went through every screen, every interaction, every element — as if I were a first-time user. Here's what I found and changed.

Font readability over style. The original font looked expensive and fancy — appropriate for targeting lawyers. But it made things harder to read. I switched to a more readable font for body text while keeping some stylistic elements in larger headings. Readability beats aesthetics every time.

Dashboard cleanup. I removed a "next scan" tile that wasn't useful for V1 — the system will run on a set daily schedule, so showing the next scan time isn't valuable real estate. Keeping three metrics instead of four also cleaned up the visual layout.

Revenue captured, not hours captured. This was the single most impactful change. I converted the main dashboard chart from "hours captured" to "revenue captured" by incorporating the billing rate data. Now the dashboard literally shows users how much money the product is recovering for them. If your SaaS can show financial impact, do it. Nothing communicates ROI more clearly than a dollar figure.

Report status tracking. I added the ability to set a status for each report — new, reviewed, entered, billed, paid. Since multiple people at a firm may work with this data (attorneys and administrative staff), status tracking prevents duplicated effort and keeps everyone aligned.

Activity log for collaboration. Each report now has a history log showing who did what and when. This supports the collaborative workflow without requiring full integrations with other systems in V1.

Navigation fixes. The collapsible menu had a floating expand button that was easy to miss and overlapped with the logo. I removed the logo and anchored the expand control so it's always visible. Small UX details like this make the difference between a prototype that feels polished and one that feels rough.

Help and support. I added a dedicated Help & Support section with the ability to send messages directly from the app, plus space for guides and FAQs. Even in V1, users need a way to reach you. I typically start with email support and add chat shortly after.

The Lovable Iteration

I fed all of this feedback to Lovable in a single prompt. It nailed every change. The revenue captured chart even added tabbed views to toggle between revenue and hours. The status tracking used color-coded tags. The activity log was clean and functional. The help section included both messaging and self-service options.

The Demo Account Pattern

One strategy worth highlighting: instead of hiding the entire application behind a login wall, I keep a public demo account accessible. Prospects can explore the product freely without signing up. The people who reach out after exploring the demo are already warm — they've essentially sold themselves. This is a product-led qualification tactic that works particularly well at this stage.

Your Takeaway

Walk through your prototype as a user and note every point of friction. Prioritize readability over style. Show value in financial terms whenever possible — revenue captured beats hours captured. Add collaboration features and help/support early. Then iterate with Lovable in one prompt and review the results. By the end of this day, you should have something you're genuinely proud to demo.

Next in the series: Day 8 — Development Environment. We transition from design tools to real code.

Start the free 5-day email course

Watch the Build in Public Series on YouTube