Platform System
Last updated
Last updated
Platforms, like web or app, have their own libraries that share common components for that touch point but that are also shared and accessible to all teams. We recommend starting with one platform—a product that is core to the business strategy of the company—that represents the best UX and UI patterns.
These design patterns will be shared and used throughout all digital products and therefore should be the very best UX/UI. If the quality of design needs to be elevated, this is the opportunity to achieve that while creating the digital system. Do not add anything to a digital system that you do not want reused throughout the company.
Create the first component libraries using the selected product, linking the designs to the foundations system by using the design tokens.
As we mentioned at the beginning, systems are composed of different elements placed together to solve a specific need. For there to be clear, efficient work flow between teams, it is critical that there is common nomenclature and understanding of the different elements of the system. Based on their use and purpose, we propose the following: Fragments, Components, Modules & Templates.
A fragment by definition is something that only makes sense when it is joined with something else to create meaning.
As an example, a fragment would be a tool tip icon that accompanies a title or piece of copy. It would never stand alone because it has no meaning without the text, and would only cause confusion.
Another example would be items that are part of a larger container and should never used separately—links from a navigation bar for instance. Therefore, the following elements will form part of the group of fragments:
Icons
Items (such as links in a header)
(...)
A component is an element that can live by itself and performs a specific function. It makes sense without other elements being paired with it.
As an example, a button is a component. A button has a specific and individual function and can be placed within a composition without other elements to accompany it. The most common components are:
Button
Text blocks
Links
Lists
Selectors
Images
Illustrations
Text fields
Tab groups
Tables
(...)
A module or section of a page is a group of components that are placed together to perform a function or transmit a message. One example would be a contact form. The individual components—form fields, buttons, headers, background—are placed together to create the contact module.
Another example is a product selling module. Normally this module has individual components—promo cards, headline, button, background—that are grouped together to create the module. Some other examples of modules are:
Cards
Forms
Modals
Search bars
Calendars
Galleries
(...)
As digital systems grow to support a widening landscape of components and platforms, design tokens — and their names — are increasingly important. Effective names define and sustain the team’s shared common language throughout the evolution of the system.
'Terms matter. As we make things, we must be able to browse and search tools to quickly recognize and recall the purposeful decisions we’ve made. Not just in code and documentation, but in design tools too'. - Nathan Curtis, Eight Shapes
To create a sustainable naming structure, levels can be organised in four groups: namespace, object, base and modifier. No digital system or individual component uses all levels, but it is a good foundation to ensure scalability. Below is an example of how we curated a naming structure using this foundation for a client with two unique audiences and experiences—retail and enterprise:
Namespace levels combining of system (material), theme/subbrand (nikeSB), or domain (retail).
Object levels to refer to a component (button), element within a component (left-icon), or component group (forms).
Base levels as a token’s backbone that combine category (color), concept (action) and property (size)
Modifier levels to refer to one or more of variant (primary), state (hover), scale (100), and mode (on-dark).
Naming structures can become very extensive—and a bit daunting—as described in this very thorough Medium post, but the main idea is that there are a range of options to define a naming structure that fits the scope of the digital system. We work with our clients to understand their needs, ecosystems and goals and together we craft the naming structure that works best for them.
Define leading project to build the base library of elements.
If UX/UI patterns need to be elevated, use this as the opportunity to redesign the touch point as you are building the digital system.
Work between the design and development teams to align on component naming and structure.
Build Figma/Sketch libraries using naming structure.
Document all to be shared with entire team.
