One System, Three Platforms: Proving a Design System in Practice
A design system means nothing until someone bets a real project on it. See how a system built from a brand guideline was tested first on the company's hardest internal platform, and only reused twice more because it held up.
Building the system, then proving it scales
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, slightly different shades of the same brand color, because each one had been designed in isolation. One of my first tasks was to fix this at the root, turning the company's Brand Guidelines into a working Design System: a type scale built on Manrope and Nunito, and a four-level color system anchored on the brand's Pantone red.
A design system on paper is just a bet. It only proves itself the first time a real 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 whether the system actually worked, and it did. That result was what justified reusing it twice more: on the company website and in a new team-estimation tool called Planning Poker.
This case follows that sequence. These aren't three unrelated projects that happen to share a color palette — it's one system, proven once under real conditions, then extended. Alongside this, I designed and taught a UX/UI curriculum across Latin America, and later moved into working directly on client projects, both covered briefly below.
The Design System
The starting point was the company's Brand Guidelines, a document built for marketing, not product. My job was to translate it into something a designer could actually use to build interfaces: a type hierarchy in Manrope for headings and Nunito for body text, and a four-level color system built around a brand red (Pantone red, #EF293D), with Raisin Black, Alice Blue, and white rounding out the supporting roles.
The goal wasn't decoration. It was giving every future product a shared vocabulary, so no one had to reinvent type scales or pick a slightly-wrong shade of red again.
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 wasn't a greenfield product, where applying a clean system is easy. It was a platform already in use, with real flows and real complaints, surfaced through direct UX interviews with the people who used the tool every day.
I redesigned the navbar, the task screens, and the full hiring workflow, using only the components already defined in the system. If the type scale or color tokens couldn't hold up in an interface this dense, this is where it would show.
It held up. And that gave me something concrete to point to when the next two projects came along.
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 a different kind of work: less about testing the system and more about applying it fast, across products with very different shapes.
The institutional website needed a redesign: a new hero, the metrics that mattered (1,000+ employees, years in the market), a working blog, and a page dedicated to the bootcamp program. Every typography and color decision came straight from the existing system, which meant visual identity was already settled before the project even started.
A lightweight agile estimation tool for teams, built end to end with the same components: problem, research and discovery, testing and iteration, and a documented conclusion. While the BPM redesign took months, this one took a fraction of that time, because there was nothing left to decide about how it should look.
The system's longest reach was a full learning platform for Jalasoft and Jala University's bootcamps, serving students, teachers, and admins in a single connected product. I ran the project solo, end to end, from stakeholder interviews to final UI, building every screen on the same Manrope, Nunito, and color tokens defined at the start of this case.
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.
Training the next generation
UX/UI Design, Full Stack Developer Bootcamp
Six to eight months after joining the company, I was invited to design and teach the UX/UI Design curriculum inside the company's Full Stack Developer Bootcamp. I built the course from scratch and taught 10 to 12 cohorts across Latin America.
Moving into direct client work
After this more internally-focused period, I moved into working directly on client projects. Two of these already have a full case study in this portfolio.
What extending one system across three products taught me
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 hasn't really been proven.
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 real return on a design system, not a slide about consistency.
A system built for a dense internal tool doesn't automatically fit an institutional website or a lightweight app. Every reuse still demanded decisions about which parts of the system to keep and which to adapt.
Teaching forced me to explain design decisions as principles, not just as Figma files — a different kind of rigor than simply shipping alone.
