Case studyCycode Enterprise Security · B2BSenior Product Designer~6 months

Dashboard Builder: less to decide

Inside Cycode's enterprise security platform, we replaced a third-party analytics tool with a dashboard builder of our own. The goal wasn't feature parity — it was making dashboards something people could actually finish building.

Product

In-house dashboard builder inside Cycode, replacing a third-party analytics solution

My role

Senior Product Designer.
Strategy, research, IA, builder UX, widget library, migration, design QA

Team

1 designer (me),
1 PM, 3 engineers

Timeline

~6 months,
within an ongoing role at Cycode

+34%

dashboard creation completion after rollout

Mixpanel · after launch

8→3.5 min

time to create the first widget

Mixpanel · after launch

−31%

support requests related to dashboards

Support tickets · after launch

The context

Our product leaned on a third-party analytics tool for dashboards. It worked — but it was someone else's software wearing our logo, and that gap showed everywhere: a different feel from the rest of the product, an onboarding people bounced off, and a roadmap we didn't control.

The brief wasn't "rebuild what the third party does." It was to make dashboards feel native to our product, and make them meaningfully easier to use along the way. Those are two different jobs, and the second one is where the actual work was.

Inconsistent experience

The embedded tool looked and behaved like a separate app. Users felt the seam every time they crossed into it.

Hard onboarding

The builder exposed advanced settings before a person had made their first chart. Too many decisions, too early.

External dependency

Every future dashboard feature was gated by someone else's roadmap and someone else's maintenance cost.

Low adoption

Only 23% of organisations in Europe and 28% in the US used dashboards at all — a strong signal the experience was too complex for most customers.

What we agreed to measure — before designing

This is the part I'd skipped on earlier projects and regretted. Before touching a screen, the PM and I fixed the numbers that would tell us whether this worked. That single decision is why the results section of this case study has real figures in it.

Business goals

Replace the third-party solution
Migrate existing customers without breakage
Reduce engineering dependency
Speed up future dashboard development

Product goals

Simplify dashboard creation
Reduce time to first dashboard
Improve completion rate
Reduce support requests
Increase dashboard adoption

Reading the product before redrawing it

Before designing anything, I looked at how dashboards were actually used in production — not how we imagined they were used. Two analyses set the direction for the whole project.

Adoption was low to begin with

Organisations using dashboards

Share of customers, by region

23%

Europe

28%

Production usage analysis

The insight

Fewer than a third of customers touched dashboards at all. That's not a feature gap — a feature gap looks like people asking for more. This looked like people finding the whole thing too heavy to start. So the goal shifted: not recreate every capability, but make the common path dramatically easier.

1,200+ widgets, and a very clear pattern

I analysed more than 1,200 production widgets across every customer dashboard. The distribution wasn't close:

Widget usage in production

Count across all customer dashboards

354

Pie

240

Table

180

Scalar

119

Bar

Area

Line

Waterfall

Funnel

1,200+ production widgets · others under 50 combined

What it told me

A handful of visualisation types carried almost everything. Several existed only once or twice in the entire customer base. We were maintaining — and asking users to wade through — a full catalogue to serve a long tail almost nobody used.

The calls I made, and what they cost

Two decisions defined the project — one about scope, one about how much freedom to give the user.

Decision 01

Rebuild every widget — or ship the ones people actually use?

The safe, expected move when replacing a tool is feature parity: match everything, so nobody can say you removed their thing. But parity here meant rebuilding visualisation types that appeared once or twice across the whole customer base, at real engineering cost, for three engineers.

✓ What I chose

Ship the widgets that cover 90%+ of real use

We kept Pie, Table, Scalar, Bar, Area, Line, Waterfall and Funnel — together over 90% of production usage. Map, Sankey, Gauge, Scatter, Object and Progress were cut from the initial release. Less UI to wade through, less to build, and only a very small number of existing dashboards affected.

✕ What I rejected

Full feature parity on day one

Politically safer, but it would have spent our small team's time rebuilding the long tail nobody used — and kept the builder as cluttered as the tool we were replacing.

What it cost

A handful of customers using the removed widgets had to be handled deliberately in migration. Cutting features from a replacement is a trust risk, so it had to be backed by the usage data and a migration flow that let teams check their dashboards before switching.

How I decided

Straight from the 1,200-widget analysis. The cut list wasn't an opinion — it was the bottom of the usage distribution.

Decision 02

Give users every setting — or make most decisions for them?

Research pointed at something specific: people weren't stuck because the builder lacked power. They were stuck because it asked for too many decisions, and asked too early — advanced settings surfaced before a user had even made their first chart.

✓ What I chose

Opinionated defaults, complexity hidden until relevant

Progressive disclosure: hide advanced settings until they matter. Sensible defaults so a chart looks right before you touch anything. Live preview so every change shows its effect instantly. The builder makes the boring decisions for you and gets out of the way.

✕ What I rejected

Expose all controls, let users configure

Maximum flexibility, and the exact trap the old tool fell into. Power the confident 5% love and the other 95% drown in. Adoption was already at 23–28% — more knobs wouldn't fix that.

What it cost

Power users lose some immediate control, and defaults have to be genuinely good or they become the new frustration. It's a bet that most people want a fast right answer over a slow perfect one.

How I checked

Mixpanel funnels, click tracking and usage analysis on the quant side; interviews, stakeholder workshops, support feedback and PM collaboration on the qual side.

The design

Four principles ran through every screen: progressive disclosure (hide complexity until it's relevant), opinionated defaults (fewer decisions), live feedback (see every change immediately), and consistency (feel like our product, not an embedded app).

Process timeline

Note

Placeholder for your process timeline diagram — drop the image in here when it's ready. Sized to sit full-width like the other visuals.

1 · Dashboard creation

A much simpler entry point, with far fewer required decisions before a person gets their first result on screen.

2 · Widget library

Instead of presenting every visualisation as an equal, the library recommends the widgets people actually use and groups them logically — the usage data, turned into a UI.

3 · Widget configuration

The configuration panel was rebuilt around live preview, grouped settings, simplified terminology, progressive disclosure and smart defaults — so the common case takes a few clicks and the advanced case is still reachable.

4 · Migration

Existing customers needed confidence that nothing would break. The migration flow let teams review and validate their dashboards before switching permanently — the safety net that made cutting the unused widgets acceptable.

Built on the design system

A core goal was to not create another isolated experience. So I built the dashboard builder almost entirely from Cycode's design system — a tokenized library with light and dark themes, fully documented in Storybook — with roughly 85–90% of the interface assembled from existing components and new ones added only where genuinely necessary. Faster to ship, more accessible, visually consistent, and far less to maintain.

120+

reusable components used across this builder

themes — light and dark — tokenized from the ground up

40+

screens across 12+ redesigned user flows

Design system reuse — components highlighted

Why this counts

Building on the system instead of around it is what let one designer and three engineers replace a whole third-party product in about six months. This builder is one piece of a larger effort — I own the design system for Cycode's product org overall, including 20+ integrations and native reporting surfaces beyond this specific dashboard. Building systems from zero and scaling them across a product is the thread that runs through most of my work.

Working with three engineers

With a team this small, every design decision hit delivery directly. So I worked with engineering to prioritise features, cut implementation complexity, drop low-value functionality, reuse existing components, and split the work into incremental releases. That's how the MVP shipped fast without giving up the long-term vision.

Results

Because we set the metrics up front, I can tell you exactly what changed. Tracked in Mixpanel after rollout.

Dashboard creation completion

Share of started dashboards that got finished

Base

Before

+34%

After

Mixpanel · after launch

Widget creation completion

Started widgets that got finished

Base

Before

+39%

After

Mixpanel · after launch

Time to first widget

Minutes from start to a working widget

8:00

Before

3:30

After

Mixpanel · −56%

Average clicks to build

Clicks to create a dashboard

Before

After

Mixpanel · −46%

−31%

support requests related to dashboards

In-house

platform established, third-party dependency removed

Faster

future features, via design-system reuse

What the numbers do and don't say

These are real Mixpanel figures against goals we set before starting — that's why I trust them. What I'd still want to see is longer-term adoption: completion and speed went up sharply, but the honest test is whether the 23–28% of organisations using dashboards actually grows over the next few quarters. That's the metric I'd track next.

Reflection

The real lesson wasn't about dashboards

It was that simplifying a product often means deliberately not rebuilding everything that already exists. The instinct on a replacement project is parity — match every feature so no one complains. The usage data said the opposite: match the 90% people use, cut the tail they don't, and the product gets better precisely because there's less of it.

Setting metrics first changed everything

On earlier projects I measured after the fact and had to reconstruct impact. Here the PM and I agreed the numbers before design started — completion, time-to-first, clicks, support load. That's the only reason this case study can show a clean before/after instead of a shrug.

Where AI fits today

This project predated AI in my process. Now it would take the heavy analysis — clustering 1,200 widgets, synthesising interview notes, drafting the many configuration states — and free me to spend more time on the judgement calls: what to cut, what to default, what to hide. The decisions stay mine; the grind doesn't have to be.