TL;DR
Lucidchart's Themes & Styles feature was barely used — only 3% of weekly active users had ever touched it. Through 24 user interviews, we discovered that formatting wasn't a primary user intent. Users would only adopt themes if applying them required minimal effort. We pivoted the project around a one-click application model.
We followed it up by rebuilding Conditional Formatting on the same styling primitives — so a single visual style could be applied either manually or driven by data, without users learning two separate systems. 81% of new CF rules now use styles instead of icons or progress bars.
833%
Increase in feature usage (3% → 28% WAUs)
54K
Daily active users on the styling system
4K → 8K
Daily events doubled through onboarding
81%
Of new CF rules use styles instead of icons/progress bars
Context
Themes & Styles had been in Lucidchart for years but had never found product-market fit. Pre-launch analytics showed only ~3% of weekly active users had ever interacted with the feature. Stakeholders across the org had different opinions on why: some thought the UI was wrong, others thought it needed more themes, others assumed users just didn't care about visual polish.
The project (internally codenamed "GUT") was in a difficult state when my team — another designer, a PM, and I — were assigned to it. Stakeholders had conflicting priorities focused on individual features rather than user intents. Prior approaches relied heavily on subjective opinions rather than evidence-based insights. Testing had been limited to mocks, which didn't reflect how users actually interacted with the product.
Compounding this: the previous solution failed to integrate with existing formatting systems and lacked plans for compatibility with legacy systems. Whatever we shipped had to live alongside Conditional Formatting, theme color overrides, and the formatting bar — without breaking documents that pre-dated the new system.
Research
I led 24 external user interviews and 4–5 SME interviews to validate (or invalidate) the assumptions baked into the existing direction. Two findings reshaped the project:
Finding 1
Formatting isn't a primary use case
Most users came to Lucidchart to communicate something — a process, an architecture, an org structure. Visual polish mattered, but it was downstream of the diagram itself. They weren't looking to "design"; they were looking to "ship a doc."
Finding 2
One-click or it doesn't get used
Users said they'd only adopt themes if applying them required minimal effort. Anything resembling "configure a theme" or "open a styles panel" got dismissed. The mental model needed to be: pick the look, see it applied, done.
The Pivot
The research handed us permission to make a hard call: scope down the feature, drop the "configure a custom theme" workflows, and prioritize a small library of curated themes that could be applied with one click.
I worked with my PM to advocate this scope reduction to leadership. We proposed Corporate Themes (a constrained, brand-aligned set) over a more open Insights-based direction another track had been exploring. Our proposal — backed by interview data — was eventually accepted as the well-thought-out direction.
I separated system-design discussions from visual-design feedback. Themes were designed using the brand palette with high-contrast, accessible options. Stakeholder reviews focused on usability mechanics first; aesthetic feedback was deferred until the system worked.
Design Approach
The styling primitive — a "style" that bundles fill, stroke, and text properties into a single applicable unit — was designed to be reusable. It needed to work for:
- →Manual application from the formatting bar (one click)
- →Theme-driven application across an entire document
- →Conditional Formatting rules that swap styles based on data
- →Backwards compatibility with documents using legacy formatting
I created mocks demonstrating how the same style primitive could scale across other products and features in the suite, ensuring the design wasn't just a Lucidchart fix but a sustainable foundation for the broader platform.
Conditional Formatting Redesign
Once the styling primitive was working, I led the redesign of Conditional Formatting (CF) — the data-driven counterpart. Previously, CF rules used a separate visual vocabulary: icons, progress bars, color overrides applied directly to shapes. Users who wanted a visual change could either format it manually or write a CF rule, and the two paths produced different-looking results.
The redesign let CF rules apply styles — the same primitive used in manual formatting. A rule could say "if status = blocked, apply the 'red alert' style," and the rendered shape was indistinguishable from a shape someone styled by hand.
Before
Two separate systems. CF used icons and progress bars; manual formatting used colors and borders. Migrating was a rewrite.
After
One styling primitive. CF rules apply styles. Switching from manual to data-driven is one toggle, not a rebuild.
The redesign was validated with 2 SMEs and 5 users. Although the broader CF revamp project was eventually deprioritized in favor of other initiatives, the styling integration shipped:
81% of new CF rules use styles
In the months after launch, 81% of newly created Conditional Formatting rules used the new styling primitive — replacing the older icon/progress bar pattern as the default. The two systems converged on a single visual vocabulary.
Impact
3% → 28%
Of weekly active users now use themes/styles. An 833% increase from pre-launch.
54K
Daily active users on the styling system after launch.
2×
Daily usage doubled (4K → 8K events) after onboarding improvements.
Beacon tracking surfaced an early adoption blocker: usage of the "edit styles" feature was unexpectedly low because users didn't know it existed. I designed and implemented an onboarding flow that surfaced the feature contextually, and daily usage doubled.
The longer-term win was strategic. Themes & Styles became the visual foundation that other features could build on rather than re-invent. The CF redesign was the first proof of that — but the same styling primitive now underpins how visual identity is applied across the document, regardless of whether it's user-driven or data-driven.
Reflection
The hardest design decision was scope. Themes & Styles had a long backlog of "nice-to-have" capabilities — custom palettes, theme marketplaces, per-team libraries. The user research was clear that none of those mattered until the one-click case worked. Saying "no" to the larger vision in MVP was what allowed the one-click case to ship cleanly.
The CF redesign taught me to look for shared primitives across features that look different on the surface. CF and manual formatting felt like separate problems for years; they were actually the same problem with different inputs. Designing around that shared model — rather than two parallel UIs — collapsed a lot of complexity.
The biggest organizational lesson: communication artifacts matter more than design artifacts in projects this size. Loom videos, decision logs, flowcharts, and Slack-context-setting did more to keep stakeholders aligned than any prototype. Mentoring my co-designer Dev to do the same — and to read which level of detail a specific stakeholder needed — was as much of the project as the interaction design.