Product Design
B2B SaaS
Design Systems
Multi-Product
One System, Multiple Platforms: Proving a Design System by Using It
A design system means nothing until someone bets a real project on it. Here is how one built from a brand guideline got tested on the company's hardest internal platform first, then reused twice more because it held up.
Client
Jalasoft
Role
Product Designer
Timeline
2021–2026 (5 years)
Scope
17 projects
Overview
Building the system, then proving it scales
Company
Jalasoft — nearshore software outsourcing and staff augmentation.
Format
One system, proven once under real conditions, then extended
I joined Jalasoft in 2021. Before I arrived, every internal tool looked like it came from a different company: different type scales, different button styles, different shades of the same brand color, because each one had been designed in isolation. One of my first tasks was to fix that at the root, by turning the company's Brand Guidelines into a working Design System: a typography scale in Manrope and Nunito, and a four-tier color system anchored by the brand's Pantone red.
A design system on paper is a guess. It only becomes real the first time a live project depends on it. That test came almost immediately, with the redesign of the company's internal BPM platform, the tool every employee used for tasks and hiring. It was the least forgiving place to find out if the system actually worked, and it did. That result is why the system got reused twice more: on the company website, and on a new team estimation tool called Planning Poker.
Ths case follows that sequence. Not three unrelated projects that happen to share a color palette, but one system, proven once under real conditions, then extended. Alongside that, I designed and taught a UX/UI curriculum across Latin America, and later moved into direct client work, both covered briefly below.
01 · Foundation
The design system.
It started with the company's Brand Guidelines. From that starting point, I built a complete design system: a typographic hierarchy covering titles, body copy, and buttons, and a three-tier color system (primary, secondary, and tertiary) anchored by a red brand color (Pantone red, #EF293D).
This became the shared foundation every platform below was built on top of.
02 · The First Test
BPM Platform Redesign
The system's first real assignment was also its hardest: a redesign of the company's internal BPM platform, the tool employees used to manage tasks and the hiring process. This was not a greenfield product where a clean system is easy to apply. It was a live, in-use platform with real workflows and real complaints, surfaced through direct UX interviews with the people who used it every day.
I redesigned the navbar, the task views, and the full hiring process flow, using only the components already defined in the system. If the type scale or the color tokens did not hold up under an interface this dense, this is where it would have shown.
It held up. And that gave me something to point to when the next two projects came up
03 · Extending the System
Website, Planning Poker, and Elearn App
With the system proven on the hardest internal case, extending it to the rest of the company’s products was less about testing and more about applying it fast, across products with very different shapes.
Jalasoft Website
The company site needed a redesign: a new hero, the metrics that mattered (1,000+ employees, years in the market), a working blog, and a dedicated page for the bootcamp program. Every type and color decision came straight from the system already in place, which meant the visual identity question was already answered before the project started.
Elearn App
The system's furthest reach was a full learning platform for Jalasoft and Jala University's bootcamps, serving students, teachers, and administrators in one connected product. I owned it solo end to end, from stakeholder interviews through final UI, and built every screen on the same Manrope, Nunito, and color tokens established at the start of this case. It has its own full case study on this portfolio.
Planning Poker
A lightweight agile estimation tool for teams, built end to end with the same components: problem statement, research & discovery, testing & iteration, and a documented conclusion. Where the BPM redesign took months, this one took a fraction of that, because there was nothing left to decide about how it should look.
04 · Tokens & Dark Mode
From Fixed Colors to Variables
Inside the bootcamp I taught, students went through App Rebuild, a challenge where they picked an app they used regularly, screenshotted it, and rebuilt a high-fidelity replica of its interface in Figma. I designed and built that tool on top of the same design system.
App Rebuild needed a dark mode variant, and that was the moment the system's color values stopped being good enough. Up to then, every color was a fixed hex value: the accent red, the Raisin Black, the Alice Blue. A dark variant meant a second full set of values, hardcoded and disconnected from the first, with no guarantee they would ever stay in sync.
Instead, I rebuilt the system's colors as tokens: variables with a light and a dark value, referenced by name instead of by hex code everywhere they were used. Once that was in place for App Rebuild, it was not a one-off fix anymore, it became how the entire design system defined color going forward.
05 · Teaching
Training the next generation.
Six to eight months in, I was invited to design and teach the UX/UI Design curriculum inside the company’s Full Stack Developer Bootcamp — building the course from scratch and teaching it across 10-12 cohorts throughout Latin America.
Retrospective
What I took away.
Win
Hardest project first
Testing the system on the hardest project first, instead of the easiest, is what made the next two fast. A system that only survives on simple products has not really been proven.
Win
Speed is the real ROI
The website and Planning Poker shipped faster than the BPM redesign for a specific reason: the visual decisions were already made. That speed is the actual return on investment of a design system, not a slide about consistency.
Challenge
Reuse still needs judgment
A system built for a dense internal tool does not automatically fit a marketing site or a lightweight app. Each reuse still required judgment calls about which parts of the system to lean on and which to adapt.
Challenge
Teaching as a forcing function
Teaching forced me to explain design decisions in principles, not just in Figma files, a different kind of rigor than shipping alone.
