The design system was an initiative to create a cohesive and efficient framework of styles and components for the KDS.
Another objective was to meet one of our design KPIs, which was to add efficiency to the design process and workflow.
The KDS was part of the larger Aloha product ecosystem, so our design had to align with the Aloha point of sale system for a consistent experience across both front and back of house.
Spacing unit values were calculated and defined using a linear progressive scale, with a ratio of 2.
Base primitives were given the prefix `size-` followed by the corresponding spacing value.
Color primitives were defined first and then attached to tokens to give intent and meaning. Blue was chosen to be the base color, based on the established primary color from the Aloha point of sale.
Colors were built using the HSL color model. All colors in the set were built to comply with the AA contrast level (4.5:1), as defined in WCAG 2.2.
Each color primitive was linked to a token in the library intended to represent function.
Light and dark color values were also defined for different interface elements, all from our color primitives.
Font sizes were defined in terms of best practices for display screens/kiosks. Inter was used as the base font with three distinct weights — Regular (500), Semi Bold (700), and Bold (900).
Font sizes, alongside weights, letter-spacing, and line-heights were specified for each token. Each token followed a functional or semantic naming convention.
Primitive and semantic tokens were set up for adding elevation to toasts and alerts, popovers, and button components.
Shadows (and other effects) were stacked together in order to provide greater depth.
Primitive and semantic tokens covering border widths and radii were set up for various elements in the app interface.
The aim was to enable faster decision making in terms of adding border radius and/or widths.
We designed rounded icons by aligning them to our 4px pixel grid using a keyline/grid.
This design approach followed the rounding tokens from our border-radius primitives.
Kitchen staff are usually busy multitasking while preparing food, and they often view the kitchen display from a distance.
It was crucial for our text to be readable at various distances. We implemented kerning adjustments to enhance the visibility of individual letterforms, taking inspiration from real-world traffic signages, so the text on the screen could be read at different distances.
Kitchen staff work in a chaotic environment, where there’s vapour, steam, and they often wear gloves while prepping food, or have greasy fingers. Interacting accurately with the system in such conditions can be challenging.
Ensuring large, optimal touch target sizes for all interactive elements was essential to minimise interaction errors.
We ensured that all colors met at least the AA contrast level as specified in WCAG 2.2 standards.
Contrast checks were conducted by comparing the lightest color from the palette against a dark background, and vice versa.
We tested ticket status colors in our palette for color blindness, to ensure that no two colors overlap and cause confusion for individuals with color vision deficiencies.
Components were built using the atomic design framework.
All components made use of semantic tokens from our style guide.
A utility ‘slot’ component was defined and added to the layer stack to make components flexible.
This ensured that a designer could directly add custom content to components instead of detaching or adding items using an external frame or layer.
Component states, variants, properties, and dos and don’ts (where applicable) were annotated in Figma to minimise ambiguity.
The documentation was designed to be flexible, so more guidelines could be added to it as the design system evolved.
While designing requirements for the first product milestone, the Design System played a key role in ensuring that the KDS app design and interactions were consistent and cohesive.
While the typography choices made were solid, there was an opportunity to enhance the system by adding some more semantic type tokens for various elements.
Having more type tokens would have provided greater flexibility and consistency and ensured a more robust foundation for accommodating future design iterations and requirements.
The first version of the KDS design system was a great success — both the product and engineering teams appreciated the efficiency it added to the design and development process.
Two separate product and development teams at NCR worked on two retail back office products, which share a common functional foundation.
As both products scaled in terms of the functionality and feature development, the design for both apps diverged which led to a loss of opportunity for collaboration and generally led to a slower pace of development for all teams involved.
We identified an opportunity to build a component library that can be used across both systems to build a cohesive identity and consistency in terms of the design patterns and the visual language.
Interace differences between both back office products. The differences shown above are subtle, but the colors, components, and the overall experience between the two systems was generally inconsistent.
Since both products had been in development for more than a year, one significant challenge for the design team was with the scope of the task, in addition to regular feature design work.
The product and engineering teams were consulted with so we could get an idea of their openness, efforts, and timeline estimates for switching over to the styles and components in our new design system.
We made a case for the advantages of switching to using a design system with both Product and Engineering teams.
With the Product team, we highlighted how it enables easy brand customisation with a set of basic design tokens defined for styling and theming and adds some speed into the development cycle. With Engineering, having code for the UI elements ready which they could plug and play, or customise if needed, adding to an ease in development costs and a consistent experience overall.
We extended the Material design base theme components and used it as the foundation for our design systems.
An 8pt spacing system and a 12 column grid (with a 4pt baseline grid) was used to ensure layout alignment for various elements and fluidity for responsiveness, as the product is primarily used on web/desktop based devices.
Purple was chosen as the primary (white-labeled branding) color for the interface.
Descriptive tokens/variable names were also specified in the design system documentation.
The color palette was intentionally chosen using a HSV scale which ranged from 5 (lightest) to 90 (darkest) to ensure that the colors meet the AA level for contrast per the WCAG standards and specifications.
For the typography, Inter was used as the base font.
A set of different weights were specified based on a harmonic type scale.
After publishing V1 in August of 2022, we quickly adopted and applied components and patterns from the design library to all our design mockups, which made the design process faster.
In addition to that, the rollout for V1 of the design system was successful with engineers switching components, with a minimal disruption to the build, which was appreciated by all teams. It was made possible through great collaboration and support between everyone involved.
→ Next project
