A shared design language for Marcura’s maritime products—connecting brand, interface and implementation.
Project Result
Reduction in design time for new features
Reduction in development time for new features
Reduction in Global Design Updates
Problem Statement
Marcura’s growing product family needed a more coherent experience. Teams were solving related interface problems independently, creating differences in visual language and repeated work. The challenge was to turn a common brand direction into shared foundations, reusable components and guidance that connected design decisions to implementation. The system needed to support distinct maritime products while making familiar interactions feel consistent across the portfolio.
Goals and Objectives:
Consistency in Design
Give related products shared foundations and familiar interaction patterns.
Proper Documentation
Make component decisions, usage and behaviour easy for teams to understand.
Design and Development
Connect the design library with implemented components and specifications.
Maintaining WCAG and QA
Build contrast, legibility and interaction states into component review.
Visual Language
Marcura’s product family needed a recognisable visual language that could work across very different maritime services. The foundations brought colour, typography, imagery and interface styling into one coherent direction.
The content guidelines shown below extended that consistency to language: how products explain their value, guide people through a task and communicate with a clear, confident voice.
Together, these principles gave teams a shared starting point while leaving room for each product’s purpose and audience.
From brand principles to product UI
The brand direction became a practical set of interface decisions. The examples below connect Marcura’s identity with the screens people use every day, from payment workflows to product navigation.
Colour roles, typography and layout gave those screens a common hierarchy. Product-specific content could change without each team having to reinvent the underlying language.
This created the bridge between a recognisable brand and a reusable system for building software.
Connecting design and development
Figma and Storybook gave the system two complementary homes: one for designing and composing interfaces, the other for inspecting implemented components and their behaviour.
TOOL INTEGRATIONS
Figma
Figma held the shared design library, bringing reusable components, styles and prototypes into one workspace for product teams.
Component based architecture
Design and Prototyping
Easy developer handoffs
Consistency across multiple projects.
TOOL INTEGRATIONS
Storybook
Storybook made implemented components visible in isolation, helping designers and engineers review states, behaviour and documentation together.
Robust documentation.
Interactive playgrounds designers and developers.
Enables easy collaboration and quick iteration.
Setting up Tokens
Design tokens translated the visual foundations into reusable values for colour, spacing and typography. The examples below show how the same decisions could be named, applied and maintained across design and code.
TOKEN STRUCTURE
Colour Tokens
The palette became a named set of values that teams could reuse in Figma and code. Semantic roles distinguished actions, surfaces, text and feedback, making colour choices consistent and easier to update.
Set up color tokens with proper naming conventions.
Use color tokens everywhere, with their proper usage defined.
Maintain colors for the UI as per brand guidelines.
TOKEN STRUCTURE
Spacing Tokens
A shared spacing scale gave layouts a predictable rhythm, from the space inside a control to the gaps between sections.
TOKEN STRUCTURE
Typography Tokens
Typography tokens defined a repeatable hierarchy for headings, body text and labels, keeping size, weight and line height consistent.
Checking for WCAG Compliance
Accessibility belonged in the component foundations. Contrast, readable typography, clear feedback and usable interaction states needed to be considered together, then checked where components were used in real workflows.
Status
Review components for clear, usable interaction.
Accessibility Score
Use WCAG 2.1 AA as the review benchmark.
Ongoing validation
Validate components in real product contexts.
Unification of the app's look and feel
Reusable components turned the visual foundations into a practical interface language. Teams could compose familiar patterns rather than solve the same styling and behaviour decisions in every product.
Modular and Reusable Components
The library separated the reusable structure of an interaction from its product-specific content. Components could support different contexts through defined variants rather than one-off copies.
Naming Conventions and Semantics
Clear names made the library easier to navigate and discuss. Tokens described a role, icons described a purpose, and components and states followed a predictable structure that designers and engineers could share.
IMPLEMENTATION OF DESIGN SYSTEM
Colour scales
Dark green, purple and cyan are organised into numbered shade scales. Each step gives teams a repeatable colour value, from subtle tints to stronger accents.
The numbered palette provides the foundation; semantic tokens then assign those values to backgrounds, text and borders.
IMPLEMENTATION OF DESIGN SYSTEM
Brand background tokens
Background tokens connect the palette to its purpose: purple for the brand, dark green for Marcura and cyan for an alternative branded surface. These shared roles keep colour choices consistent across product interfaces.
colour-bg-brand
colour-bg-marcura
colour-bg-cyan
IMPLEMENTATION OF DESIGN SYSTEM
Feedback text tokens
Feedback text uses four semantic roles: information, warning, risk and success. Blue, amber, red and green make each message recognisable, while named tokens keep the same meaning wherever that status appears.
Surface colours and states
Cyan, Marcura dark green and brand purple each have defined base, hover and secondary treatments. Pairing these surfaces with a consistent text treatment makes interaction states feel related across the product family.
Borders for status feedback
Border tokens extend the same information, warning, risk and success roles to component outlines. Matching border and text colours gives fields and feedback containers a consistent visual signal for each status.
Documenting components for everyday use
Documentation made the library usable beyond its creators. Each example exposed the structure, options and behaviour teams needed to compose an interface, review an implementation and use the right pattern consistently.
DOCUMENTATION
Date input anatomy
The date input specification defines its label, field, icon and spacing so the control can be built consistently.
DOCUMENTATION
Text area anatomy
Text areas use a defined label, input region and supporting text, making the relationship between content and control explicit.
DOCUMENTATION
Breadcrumb structure
Breadcrumbs define the label and separator that help people understand their position in a product.
DOCUMENTATION
Attachment structure
The attachment pattern brings the file label and action together in a compact, recognisable unit.
DOCUMENTATION
Select control anatomy
The select control defines the value, trigger and supporting message within a consistent field structure.
DOCUMENTATION
Input anatomy
The input specification identifies the label, content area and supporting text so each element has a clear role.
DOCUMENTATION
Feedback banner anatomy
Feedback banners align the message, status icon and spacing to make important information easy to recognise.
DOCUMENTATION
Form field structure
The field anatomy connects labels, values and descriptions, showing how each part supports a clear input experience.
IMPLEMENTATION OF DESIGN SYSTEM
Component Naming
Spacing specifications align icons, labels and control boundaries, giving implementation a precise visual rhythm.
IMPLEMENTATION OF DESIGN SYSTEM
Component Naming
Atomic Design Approach:
Atoms: Basic building blocks like buttons, inputs, labels. Example:
‘btn-primary’
‘input-text’
‘label-default’
Molecules: Combinations of atoms like form groups, navigation items. Example:
‘form-group-login’
‘nav-item-link’
Organisms: More complex components like headers, footers, product cards. Example:
‘header-main’
‘footer-basic’
‘card-product’
Templates: Page-level structures that include organisms. Example:
‘template-homepage’
‘template-dashboard’
IMPLEMENTATION OF DESIGN SYSTEM
Component Naming
Atomic Design Approach:
Atoms: Basic building blocks like buttons, inputs, labels. Example:
‘btn-primary’
‘input-text’
‘label-default’
Molecules: Combinations of atoms like form groups, navigation items. Example:
‘form-group-login’
‘nav-item-link’
Organisms: More complex components like headers, footers, product cards. Example:
‘header-main’
‘footer-basic’
‘card-product’
Templates: Page-level structures that include organisms. Example:
‘template-homepage’
‘template-dashboard’
Pages: Specific instances of templates with real content. Example:
‘page-home’
‘page-about-us’
IMPLEMENTATION OF DESIGN SYSTEM
Component Naming
Atomic Design Approach:
Atoms: Basic building blocks like buttons, inputs, labels. Example:
‘btn-primary’
‘input-text’
‘label-default’
Molecules: Combinations of atoms like form groups, navigation items. Example:
‘form-group-login’
‘nav-item-link’
Organisms: More complex components like headers, footers, product cards. Example:
‘header-main’
‘footer-basic’
‘card-product’
Templates: Page-level structures that include organisms. Example:
‘template-homepage’
‘template-dashboard’
Pages: Specific instances of templates with real content. Example:
‘page-home’
‘page-about-us’
IMPLEMENTATION OF DESIGN SYSTEM
State Naming
Naming conventions for UI states are standardized names used to describe different states of UI elements (such as buttons, inputs, and cards) within a design system.
‘is-active’
‘is-disabled’
‘is-hidden’
‘is-loading
IMPLEMENTATION OF DESIGN SYSTEM
CSS Naming Conventions
BEM: Provides a structured way to create reusable and modular components, ensuring a consistent approach across a project.
‘button-primary--primary’
‘card--highlighted’
‘navbar__link--active’
Results and Benefits
Post-implementation, Shipserv saw a 30% reduction in design time and a significant improvement in user satisfaction due to consistent UI elements.
Design Time Reduction
Finding: Designers previously spent an average of 5 hours creating and iterating on new UI components.
Result: With reusable components, this time was cut down to 1.5 hours.
Impact: 70% reduction in design time for new features.
Development Speed
Finding: Developers took 8 hours on average to build and style new components from scratch.
Result: Time reduced to 2 hours using pre-defined design system components.
Impact: 75% reduction in development time for new features.
Update Efficiency
Impact: 70% reduction in design time for new features.
Result: With reusable components, this time was cut down to 1.5 hours.
Finding: Designers previously spent an average of 5 hours creating and iterating on new UI components.
Conclusion
The new design system has become a cornerstone of Shipserv's product development process, ensuring a cohesive and efficient design approach moving forward. Implementing a design system has improved team velocity by streamlining design and development processes, resulting in quicker product launches. Its standardized components and accessibility considerations ensure faster iterations and compliance, enhancing efficiency and reducing time-to-market.
