Back to Case Studies// Design System · Personal Project

Building an Unbranded Design System From the Cracks Four Banks Left Behind.

Every bank I worked with had its own design system — and every time, I started from zero. Natuna Digilab fixes that: a foundation that doesn't belong to any one brand, so it moves with me, only the tokens changing underneath.

RoleCreator & Maintainer
Statusv1.0 — building
Scale1,600+ components
DistributionFigma Community
Started2023, right after BSI
// Context

Right after leaving BSI in 2023, I looked back at every team I'd worked with and found the same weak point: the design system. Not the visual polish — the discipline behind it, the thing meant to hold a product together, kept breaking down in practice. So I built Natuna Digilab as my own initiative — a foundation I could trust instead of rebuilding one from scratch every time.

Natuna Digilab logo
// The Problem

As a designer moving between companies

Every new design system meant relearning someone else's conventions — disciplined or not. I had no portable foundation of my own to start from.

As someone handing off to engineering

Developers kept asking the same specific questions — “why is this hex different here,” “why does this stroke width change for no reason.” The things supposed to be consistent by definition, weren't.

For the wider design community

Most design systems on Figma Community are heavily branded — colors, logos, identity baked in — so people have to “un-brand” them before they're useful as a starting point.

The same Button component built independently across five banking design systems — BRISPOT, BRIMKS, BTN Syariah, BTN, and BSI — each with different shapes, colors, and conventions

The same “Button” rebuilt from scratch across five banking systems — BRISPOT, BRIMKS, BTN Syariah, BTN, and BSI. No shared shape, color logic, or naming — the exact drift Natuna Digilab was built to stop.

// Process & Architecture Decisions
01

Token-first, not component-first

Built from five token categories before any component existed: Color (--color-*), Typography (--text-*), Effect (--shadow-*), Number (--spacing-*), and Icons (on Phosphor as a neutral base). Components just consume these tokens — rebrand the foundation, and only the token values change, not every component.

02

Unbranded by design, not by default

A deliberate choice, not a limitation — neutral on purpose, so it works as a starting point for anyone instead of one brand identity. Most public design systems do the opposite: double as a showcase for their creator's brand.

03

Dev Mode annotations & clean token exports

Both prove the foundation isn't just built to look good in Figma — there's real attention to how a developer consumes it at handoff, same discipline as the rest of the portfolio.

04

Trial and error, before it was a system

The earliest version was trial and error — color usage that didn't match any real standard was a recurring issue across teams. There was a pull to just copy proven systems — Wise, Gojek's Asphalt/Aloha — but Natuna stayed anchored to its own principle: unbranded, ours. Every component went through repeated iteration before being called “done.”

// The Solution

Natuna Digilab, v1.0 — still “building,” an honest status, not a weakness. 1,600+ components, full variable support across five token categories, distributed on Figma Community so others can use it too.

Two components that prove the depth

Button

Full property set — Shape, Type, State, Size (sm–2xl), swappable icons, editable label. Dozens of variant combinations, all from one component definition instead of duplicated one-offs.

Input Field

Matches Button in depth — Type, optional attached button, toggleable label/description/helper/character-count, nested instances not flattened layers. Proves the token-first claim: this configurable, and only consistent because every state pulls from the same tokens.

Natuna Digilab Button and Input Field components — variant grid and full property panels from Figma

Both were built from a wide survey of design systems across the banks I've worked in — pulling together the variant patterns that kept recurring, not copying any one system wholesale.

The trade-off of building this alone: governance that a team-owned design system gets by default — a review before a new variant ships, versioning discipline, deprecation notices — I have to hold myself accountable for, with nobody else catching what I miss. So far that's kept it small enough to manage single-handedly. It's the first thing I'd formalize if Natuna Digilab ever gets adopted by a team, or before I add more component categories.

// Outcome
5users on Figma Community — organic, with no promotion yet
two-way relationship with BRISPOT's design system — ideas flow both directions

Ideas from Natuna Digilab shaped BRISPOT's token architecture, and patterns that proved out there — validated by a real team under real constraints — folded back into Natuna Digilab. No big external number yet, but the value holds: it speeds up how I work on every new project. No more starting from zero each time I change companies.

Natuna Digilab — Foundation Design System listing on Figma Community, showing 5 users and the Open in Figma button
Live listing on Figma CommunityOpen in Figma ↗
// Reflection

If the other case studies show the resultof a solid design system — a workflow that stays consistent, hand-offs that don't drift — Natuna Digilab shows howI build that foundation in the first place. From zero, not just inheriting whatever a company hands me. It's also the project most likely to look “unfinished” next to the others — no shipped product, no team validating it under deadline pressure. I'm fine with that tension; a personal foundation is supposed to keep evolving, and freezing it into a “finished” v1 would defeat the reason I built it.

See the tokens for yourself.

Open the live file on Figma Community — full variables, no screenshots on faith.

Open in Figma Community ↗