Home / Work / Barlepie

Charts as a product, not a feature: Barlepie

A library of chart templates a team can style, fill with their own data and embed — without a designer or a front-end developer.

Barlepie — Data viz
Role
UX/UI Designer
Timeline
2021
Team
Client, engineering
The challenge

Everybody needs a chart on their site and almost nobody has the two people it normally takes.

Putting a decent bar chart on a marketing page usually means a designer to make it fit the brand and a developer to wire it to the data. For a small team that is a week of two people's time for one graphic.

The alternative most teams reach for — a screenshot from a spreadsheet — is unstyled, unreadable on a phone and out of date the moment the numbers change.

A template library only solves that if the templates are genuinely good by default. A chart that needs work before it looks right has not saved anybody anything.

Opportunity

Design the defaults, not the options

The value is in what the chart looks like before anyone touches it. Customisation is the escape hatch, not the product.

Key insight
Nobody wants a chart builder. They want a chart, and to stop thinking about it.

Tools in this space compete on how much you can configure, which is exactly backwards for the person who has one number to publish this afternoon.

So the flow is upload, pick a template, adjust the few things that matter — colour, type, labels — and take the embed code. Everything else has an opinion baked in.

The solution

A catalogue of finished charts, each of which happens to be editable.

Bar, line, pie, scatter and their relatives, each designed to be legible at the sizes people actually publish at rather than at poster scale. Data arrives as CSV, Excel or JSON, or from a live source that keeps the chart current after publication.

Customisation is limited to the decisions a non-designer can get right: palette, typeface, data labels. The proportions, spacing, axis treatment and small-screen behaviour are not exposed, because those are where an untrained hand does the most damage.

Design decision

Templates that are finished, not starting points

Every chart is publishable the moment your data is in it.

The default state of each template is the design work. Legibility, contrast, label density and how the chart behaves on a phone are decided once, properly, so the user inherits them instead of negotiating them.

That is also what makes the library a product rather than a toolkit — the promise is a good chart in two minutes, and every configuration option added is a way for that promise to fail.

Design decision

Embed is the finish line

A snippet you paste, that keeps updating.

The whole journey ends in somebody else's website, so the export is the feature. Connecting a live source means the chart is still right a month later, which is where a pasted screenshot always loses.

Annotations and comments sit with the chart rather than around it, so the story the numbers are telling travels with them into wherever they end up.

Outcome

A chart on the page by lunchtime.

Teams with no designer and no front-end capacity can publish charts that look designed, stay current and read properly on a phone.

The library holds its consistency because the parts that carry it — spacing, axis language, label behaviour — were never made configurable in the first place.

Reflection

What I would keep from this one

Restricting what a user can change is usually framed as a limitation. Here it was the entire value proposition, and the hardest part was persuading everyone that fewer controls was the feature.

Charts are also a good reminder that defaults are design. Most people never open the settings, so whatever the tool does on its own is what the tool is.