← Back to work

Using design to build trust for enterprise customers

Company[current company] RoleLead UX Designer (sole designer) Timeline2022 – present (~2 years) FocusBrowser security / Enterprise SaaS

[current company] had a working product and about 15 paying customers when I joined. The product functioned — but the company was struggling to close larger enterprise deals. Those customers had different expectations and our product wasn't effectively communicating that we were enterprise ready.

I was hired as the first and only designer, with a clear mandate: help the company hit its pre-Series A annual recurring revenue target. The product needed to be enterprise-ready, not just functional.

Full product audit

Before designing anything, I needed to understand the full scope of the problem. I conducted a comprehensive product audit that surfaced over 100 issues across accessibility, visual consistency, and data density. I documented the issues and partnered with the engineering lead to prioritize by effort and impact — so we could start with what would move the needle fastest.

[ Audit findings: annotated screenshot or issue categorization overview ]

Systematic improvement across the product

We worked through the audit backlog methodically, improving contrast ratios, fixing color usage, and tightening layout consistency. Accessibility was a key focal point. In larger companies there are often accessibility requirements that help companies achieve mandated compliance and I knew that we would be making the product better for every user if we mad it better for users with specific needs. The goal wasn't a redesign; it was raising the floor across the entire product.

[ Before / after: contrast or accessibility improvement ]

Replacing Material Design with a custom system

The deeper structural issue was the design foundation itself. The product was built on Material Design, a system designed for consumer apps, not enterprise security tooling. Material's defaults assume generous whitespace and limited information density. Our users needed to scan and act on dense security data quickly. Those goals are in direct conflict.

A bigger issue was general lack of consistency across the product. We were using multiple versions of buttons and other elements that should have been more standardized. I started with the button and designed and documented a set of buttons that would become the first component for a Figma library to document and enforce consistency.

[ Design system: Figma component library overview ]
[ Before / after: table or data-dense view — Material vs. custom components ]

Building a living design system site

As the sole designer, I needed the design system to be accessible and useful to the whole team, not just me. I built and maintain an internal design documentation site, written in code and versioned through GitHub. It serves as the single source of truth for design at [current company], with a changelog tracking every update.

The site covers color, typography, logo usage, and voice and tone as well as key UI patterns found in product. We also host live prototypes on the site where I am able to show coded examples of how an experience is designed to work. The design site provides a visual partner to our codebase and has been useful for clearing up exactly how interface elements are intended to work.

[ Design site: foundations or components section screenshot ]

Designed for AI-native workflows

From the start, I built the design site with more than documentation in mind. As a small team, we're building toward a project pipeline where AI agents participate directly in the design process. The site's structure is intentional: consistent, well-organized, and machine-readable so that agents can query it, reference it, and act on it.

The first focus is project scoping. Agents will pick up problems, help frame them, and assist in roadmapping direction. This is early work, but the infrastructure is already designed to support it. The goal is to multiply the team's capacity without multiplying headcount, handling the kinds of upstream PM activities that slow small teams down.

[ Agent pipeline diagram or project scoping workflow ]

Data visualization playground

One of the most useful things I built was an interactive playground for the data visualization work on our dashboard. Rather than designing charts in isolation, I coded a prototype that let the team explore every chart in four states: empty, low data, ideal, and overfull. Each state was tested across all breakpoints.

This became a direct handoff artifact for engineering. Instead of describing edge cases in a spec document, we could point to the playground and say "here is exactly how this chart behaves when there's no data, and here is what it does when it's over capacity." It removed a significant amount of back-and-forth from the implementation process.

I use Claude Code in the terminal to write and commit design assets like this, opening PRs directly to the design site repo. The workflow lets me move at engineering speed without needing a dedicated front-end developer to translate design intent into working code.

[ Data viz playground: chart states or breakpoint comparison ]
  • 3 six-figure enterprise deals closed following UX improvements
  • Users begin to cite UX as a differentiator for [current company] vs the competition within 8 months
  • Figma component library and coded design site both in production use
  • 100+ audit issues resolved in partnership with engineering
  • Data viz playground used directly as an engineering handoff artifact
  • Design site is the single source of truth across foundations, components, patterns, and prototypes

[ What would you do differently? What tradeoffs did you make? What did this project teach you about designing as a sole designer in a startup? ]

← All work Next: Microsoft →