Category
F&B
Platform
Point of Sale
Collaboration
Developers
Year
2026
TastyBite POS is used by cashiers to hand over meals that students have pre-ordered.
As the product evolved, more features and screens were added over time without a shared Design System. This created inconsistencies across the experience and made it harder for Design, QA, and Engineering to maintain the product efficiently.
I led the Design System rebuild alongside a broader POS UI refresh, focusing on creating a scalable foundation that could support the product as it continued to grow.
As the POS evolved, UI patterns started to diverge across screens.
The same components could have different spacing, typography, states, and interaction patterns. This created additional work for designers and engineers and made QA more difficult because inconsistencies had to be checked screen by screen.
The real challenge was no longer just making the POS look consistent. We needed a shared source of truth that could make the product easier to design, build, test, and maintain.
My responsibilities included:
Auditing the existing UAT product to identify component inconsistencies, UI drift, and usability issues.
Defining design foundations, including tokens, components, variants, and reusable patterns.
Prioritizing components based on usage, product needs, and implementation impact.
Working with Product, BA, QA, and Engineering to align on scope and feasibility.
Building the case for Design System investment and communicating its value to business stakeholders.
Supporting Engineering and QA in adopting the new system in their daily workflow.
Using AI-assisted workflows to accelerate repetitive implementation and validation while retaining ownership of design decisions and quality.
Before creating new components, I reviewed the existing POS through UAT and looked for patterns that were inconsistent, duplicated, or difficult to maintain. I compared similar components across different screens and documented differences in spacing, typography, states, interactions, and visual behavior. This helped me distinguish between problems that were purely visual and problems that were creating real operational cost for the team.
The audit became the foundation for deciding what needed to be standardized first.
Instead of redesigning every screen individually, I started with the underlying foundations that would make future screens more consistent by default. I established the core design tokens and reusable components first, then used those foundations to improve the existing POS experience.
This allowed the system to grow incrementally rather than becoming a large redesign project that would be difficult to adopt.
The initial problem could have been approached as a visual consistency exercise, but I saw a larger opportunity. Without a shared source of truth, QA had to check screens individually, engineers could implement similar patterns differently, and design fixes did not consistently propagate across the product.
I therefore treated the Design System as a product that needed to solve problems for multiple users — designers, engineers, QA, and ultimately the people using the POS.
The goal was not simply to create reusable components, but to make the product easier to evolve and maintain.
A Design System can easily be perceived as an internal design initiative rather than something that directly contributes to the product.
To get the investment approved, I reframed the conversation around the cost of not having a reliable system — including repeated design work, engineering rework, inconsistent implementation, and additional QA effort.
This helped communicate the Design System as a product investment rather than simply a collection of Figma components.
Once the foundations and core components were established, I applied them to the existing POS experience. Rather than treating the UI refresh as a separate redesign, I used it as an opportunity to validate whether the new system could support real product requirements.
This also helped identify gaps in the system and led to further refinement of components, states, and patterns as they were applied to actual screens.
The result was a closer relationship between the Design System and the product it was built to support.
With the foundations and tokens in place, I used Figma MCP and Claude to support repetitive component-building and validation tasks.
The purpose was not to outsource design decisions to AI. The Design System provided the rules and structure, while I remained responsible for defining component behavior, states, interactions, and visual quality.
This workflow helped reduce repetitive work and allowed more time to be spent on higher-value design decisions and system refinement.
The Design System was approved and funded as a dedicated initiative and became the shared source of truth for the POS.
Engineers now reference the system directly, making implementation more consistent and changes easier to propagate across screens.
The system is still evolving, with ongoing refinement and expansion as the product grows.
I initially saw the challenge primarily as a consistency problem, but the project showed me that a Design System creates value only when it solves real problems for the people who use it.
Building the components was only one part of the work. Getting stakeholders to invest in the initiative, making the system practical for Engineering and QA, and continuously maintaining it were equally important.
It also changed how I approach Design Systems today: I think less about creating a perfect library and more about building a system that can evolve with the product and become part of the team's everyday workflow.
