toranja design system

A component spec written from inside the DS team isn't the same as one written from inside a product flow.

Design system components for financial data carry more than visual consistency. A portfolio chart has to communicate negative performance clearly, not just plot it. Input Money has to behave correctly across dozens of transaction contexts — investments, bill payments, transfers — each with different rules.

I treated my contribution as quality gate: every state, every edge case, every interaction had to survive contact with real product use before shipping.

How the work happened

Research before specs. I ran three parallel streams: benchmarking across financial and general-purpose systems, interviews with designers from other Super App verticals, and use case analysis inside every investment flow that touched charts or money input. This last stream — the unglamorous one — became the requirements doc that anchored every later decision.

Critique sessions that stress-tested. I facilitated reviews with designers from across the Super App. Not open feedback rounds — structured around questions like "does this handle your most complex use case? where would it break in your flows?" That structure surfaced edge cases the DS team alone couldn't have anticipated.

Homologation as quality control. I participated in homologation for each component with a detailed checklist: visual accuracy across all states (Enabled, Hovered, Focused, Pressed, Selected, Skeleton), behavioral correctness, token application, accessibility, documentation completeness, cross-vertical compatibility.

Components shipped

[image — Chart Line, full states view, ideally one GIF showing interaction]

Chart Line — Trends and time-series. Two types (Basic/Granular), two sizes, multi-line support, segment-level direction indicators for negative performance.

[image — Chart Donut, with selection micro-interaction GIF]

Chart Donut — Part-to-whole relationships. Asset allocation, portfolio composition. Animated segment selection.

[image — Input Money, focus and keyboard interaction]

Input Money — Monetary entry across all financial contexts. One of the highest-traffic components in the system given Inter's transaction volume.

Plus Chart Bar and Chart Meter, each with their own use case scope.

Documentation

[image — documentation page snapshot, showing structure]

Each component shipped with documentation covering: definition and alternative names, usage guidance (when to use and not), every configurable property, every state with visual and behavioral specification, animations and interaction patterns, accessibility behavior, related components, content guidelines, and concrete use cases from real product contexts.

This became the single source of truth designers and engineers across the Super App actually used. Not a reference no one opens — a working document.

Reflection

The components are necessary but not sufficient. What makes a system genuinely useful is the quality of thinking embedded in it — what states to include, what use cases to anticipate, where to draw the line between configuration and constraint.

Contributing from outside the DS team meant carrying a specific responsibility: making sure the system reflected the reality of the products it would power. That work doesn't show up in component galleries. It shows up in the components quietly working — across 160+ products, every day, for millions of people.