PROJECT OVERVIEW

The Mission

The Ankor Design System (ADS) is a collection of UI foundations, components, patterns and standards used to create harmonious product experiences. We’re on a mission to make it easy for teams to design, develop and deliver high-quality user interfaces. This project was getting the Ankor Design system from 0 to an open beta.

Ankor Software
Role: Product Design Lead
Key Responsibilities:

• Own end-to-end release to Open Beta
• Conduct user research with design leadership
• Create design system tooling
• Publish documentation and educational material
• Drive adoption
• Deliver roadmap for further development

PROJECT OVERVIEW

The Problem

The existing workflow relied on a component library built with Tailwind and a handful of scattered engineering documents. However, these resources weren’t centralised and didn’t cover the full scope of Ankor’s products. When teams encountered roadblocks, they often created bespoke components rather than building on what already existed resulting in duplicated effort and inconsistent features across products.

This setup was manageable when the design and engineering teams were small, but as Ankor grew, it quickly became inefficient. The lack of a unified system created unnecessary friction, slowed delivery, and made scaling difficult. Without a proper design system, designers had no clear visual guidelines, and the products began to drift apart stylistically. Hand-off errors became more frequent, highlighting the need for a cohesive, scalable system to improve speed, consistency, and collaboration.

User Sentiment

01 The framework – Flowbite and Tailwind didn't meet their needs.

02 Don’t know how to set it up

03 Not sure where to apply it or capabilities

04 Missing features and components we need

05 Documentation and tooling to use are none existent

Business Impact

01 Inconsistent looking products

02 Unresponsive products leading to poor user experience

03 Development speed - Design and engineering miscommunication

Product Continuity

Our products were diverging at an alarming rate. We needed a design system and we needed it fast.

PROJECT OVERVIEW

The Solution

Define a new design system standard and tooling, enabling designers and engineering to drive consistency across all products, breakpoints, modes and meet accessibility requirements.

Addressing User Sentiment

01 Fit for purpose – meets the needs of designers for each product

02 Easy to use – easy to set up, supported by documentation

03 Flexible and adjustable – Guidelines on when to follow the rules or break them

Business Impact

01 Consistent looking products – drives visual design consistency across products

02 Responsive design – ensures usability for all screen sizes, modes and meets accessibility requirements.

03 Improved productivity – a shared language for design & engineering

PROJECT OVERVIEW

How is a Design System Structured?

Drawing from the work of Bradfrost in their work of Atomic Design, the design system needed to function as a working biome with integrated ecosystems, organisms, modules and atoms.

The atoms represented design tokens such as colours, fonts, shadows, spacing, icons, etc. These elements never exist purely on their own and instead combine to form molecules, simple UI components like buttons or form fields.

Molecules then join to create organisms such as navigation bars or cards, which together form complex templates and ultimately fully realised pages. This structured approach ensured scalability, consistency, and a clear hierarchy across the entire design ecosystem.

Atoms
Atoms are design tokens like colours, fonts, and shadows.

Molecules
Molecules are small, reusable components such as buttons, inputs, or avatars.

Organisms
Organisms are larger UI assemblies like forms, cards, or navigation bars.

Ecosystems
Ecosystems represent layouts or templates that combine multiple organisms.

Biome
Biomes are the overarching pages that unify all ecosystems under consistent UI pattern, workflow and brand identity.

PROJECT OVERVIEW

My Impact

As the Design System Lead, I delivered and organised, the foundational research, technology architecture, component library, documentation /instructions with tooling to improve visual design quality at scale for 5 current products (and future ones) for a team of 12 developers and three designers. I also assisted and conducted QA alongside the engineering team on components inside Storybook with stress tests that checked accessibility, device compatability, dark mode and workflows

Addressing User Sentiment

• Provided tooling for our designers, improving productivity with a component+styles library and external facing documentation
• Outlined the engineering friendly component library, to Open Beta release, delivering landings and stretch goals ahead of schedule
• Delivered customer-led solution, using research, interviews, workshops, competitive analysis, and audits
• QA on storybook components, Conducted audits on the parallel development of components inside storybook

Organisational Influence

• Reduced organisational chaos, aligning teams and designers around a consistent Design standard
• Improved design efficiency, reducing cognitive load and ambiguity with scalable design systems tooling
• Upskilled Ankor designers, with internal and external training materials Reduced manual design escalation, with self-service components and documentation

PROJECT OVERVIEW

Design Process

I approached this design challenge with two different types of thinking:

• Divergent: Keeping an open mind
• Convergent: Narrowing down to the best idea

DISCOVERY

Layers

Traditional design systems are made up of:

• Design Language
• Design Kits
• Component Library
• Dev Sandbox
• Docs & Guidelines
• Feedback Loops
• Governance Model

We had a few of these pieces but they needed to be unified and consolidated.

DISCOVERY

Competitor Analysis

I evaluated industry Standards and best practices for design systems technology.

Key Insights

• Storybook dominates
• Figma is standard
• Governance is structured
• Most use public documentation portals

DISCOVERY

Technology Review

I evaluated industry leading Development Sandboxes and best practices for design systems. Since we were already using Flowbite and Tailwind I needed to verify that Story book would work with those frameworks.

Key Insights

• Story Book is the best Development Sandbox Tool for our requirments

Tool	Tailwind/Flowbite Friendly	Developer Experience	Docs & Design System Use	Testing Fit
Storybook	Fully supported	Mature ecosystem	Easily publish component libraries for team use.	Strong — interaction tests, a11y, visual regression support (e.g. Chromatic).
Histoire	Works natively	Lightweight, minimal config.	Less enterprise editorial control than Storybook.	Basic visual checks only — no native interaction/a11y testing.
Pattern Lab	Possible but manual	Heavy config required	Strong for atomic design concepts but not modern Tailwind component libraries.	No integrated testing.
Zeroheight	Doesn’t render Tailwind itself	Docs and design guidelines are authored by non-devs easily.	Excellent for editorial, design tokens, guidelines.	None — purely documentation layer.

DISCOVERY

Internal Audit

I conducted a internal audit of our current working files and found

Key Insights

• The Figma Library needs more comprehensive componentry and documentation
• A story book workfile needs to be planned for and started immediately
• Feedback loops need to be clarified
• Guidelines on what makes it into the design system needs to be clarified
• Overall refinement of truth, tokens used and updates need to be addressed

Designer Based Tasks

• Guideline on what makes it into the Design System
• Define Version control
• Build token variable library -> export to Json for development
• Guides on how to use each component -> concurrent creation of components within figma and when to prescribe them
• Refine and expand on agreed Component Library in figma to include commonly used components we already or plan to use in the future

Developer Based Tasks

• Guideline on what makes it into the Design System
• Define Version control
• Agree on naming convention between design and engineering teams
• Refine and expand agreed apon Component Library in storybook to include commonly used components we already or plan to use in the future

Criteria For success

• Ease of use & adoption by development and design team
• Reduction of hand over errors
• Design consisteny and responsivness across apps
• Ongoing upkeep & growth
• Accessibility and analytics friendly components to track user interactions.

Work process & testing

The design system is a collaborative exercise between the design team and the engineering team.

DEFINE

Technology Architecture

In collaboration with our Chief technology officer, we were able to define the technology architecture for the design system

Global Parameters

• Breakpoints
• Sizes

Tokens

• Colours
• Fonts, sizes, weights, breakpoints
• Spacing & Radii
• Elevation & Shadows
• States
• Density - Line heights, padding

Priority items - Components

• Buttons (variants + sizes + loading + icons)
• Input + Label + Helper/Error + Validation patterns
• Select / Combobox (accessible)
• Checkbox / Radio / Switch
• Tooltip / Popover
• Modal / Drawer
• Table (with bulk actions, pagination, empty/error/loading states)
• Avatar + User chip (consistent sizes)
• Badge / Tag
• General Empty states
• Alert / Toast

STARTING THE DESGIN

Applying UX Laws

I reviewed the foundational UX laws - a series of best practices for building user interfaces. Using psychology in design helped shed light on user expectations, improving the overall user experience.

UX laws applied

Fitt’s Law
Large buttons placed in the thumb zone ensure users can quickly, easily and accurately access major functions

Hick’s Law
Highlight compulsory fields to avoid overwhelming users, and place optional fields in separate location

Jakob’s Law
Use familiar UI patterns for input fields such as dropdowns, error states, etc to leverage existing mental models

Von Restorff Effect
The distinct Ankor brand colour (blue) guides users through each step of the core task flow

Zeigarnik Effect
Stepper bars at the top provide a clear indication of progress to motivate users to complete tasks

Gestalt Principles

• Similarity: cards that look similar have the same function
• Proximity: elements that are close together are more related
• Common region: elements located in the same area are grouped together
• Simplicity: abstract symbols and icons require less mental effort

Sizes

Tshirt sizes used to apply to tokens for quick parameter changes based on specific breakpoints or contexts

Breakpoints

Breakpoints in the design system were determined using the Tailwind and Flowbite guide

DEVELOP

Colour Tokens

I developed a framework for managing and maintaining our colour token library within Figma which could be exported to JSON

It handles

• Colour Primitives: Hexs values translated to token named tokens from 0-9
• Colour references: Colour name groupings using token named colours
• Light & dark mode

Switch between light and dark mode using the layer panel

Colour along with an icon, thicker border, and background are used to indicate an error.

Tested colour variables to comply with WCAG 2.1 level AA.

DEVELOP

Guidelines for Colour Use

Instructions for using the colour tokens are outlined within the figma file

Key Highlights

• Using colour purposefully/ sparingly
• Hierarchy: Foreground vs background
• Light Vs Dark Mode
• Accessibility & Contrast
• Don’t rely on colour alone to convey meaning

DEVELOP

Typography

Working with HTML's 6 typography sizes, I designed a scale that accounted for different breakpoints within the product

DEVELOP

Border Radii & width

A set of pretermined borders that have specific use cases for design elements.

DEVELOP

Shadows

A clear indication on shadow levels for adding dimension within the application.

DEVELOP

Buttons

The button component is likely our most complex component with seven different types of buttons, four seperate states, text and icon options, five different size options and drop down options as well.

Versitility

Most components have been built to for flexibility so breaking the component is almost none existent.

DEVELOP

Timelines

Timelines were essential for our YachtListings application, but Tailwind and Flowbite had nothing out of the box, so we as a team combined and cusotmised our our timeline component to be used within the application.

DEVELOP

Shells

In UI pattern design, a shell is a basic layout structure used to create a consistent and cohesive interface across different screens. The shell provides a framework that includes essential components like padding, content areas, navigation bars, and heading bars, as well as optional functionality like toolbars and overlays.

DEVELOP

Bulk Actions

As it stood there were no out of the box component that would allow us to do bulk actions so we made one.

DEVELOP

User Research

I interviewed engineering and designers across a variety of Ankor products to understand the problem and build confidence in our direction.

Workshop notes - Coming soon

DEVELOP

Data Synthesis

Common themes were identified, by organising insights from the usability study into an affinity diagram.

DEVELOP

Governance Model

Governance ensures the design system stays consistent, scalable, and trusted. It defines who can make changes, how decisions are made, and how contributions flow from idea → review → adoption.

Core Goals

• Keep the system structured (not chaotic).
• Make contribution easy but accountable.
• Balance central ownership with distributed input.
• Ensure changes are documented, reviewed, and communicated.

Role	Responsibilities
Core Team	Maintains design tokens, components, patterns, and documentation. Sets quality standards, reviews contributions, and approves releases.
Contributors	Propose, design, or build new components and patterns. Follow contribution guidelines and collaborate with the core team during review.
Consumers	Use the design system in products, give feedback, report issues, and request improvements. Help validate real-world usage and surface gaps.

Decision Tree

The decision tree allows the core team to decide what components go into the design system (DS) and what stays out.

Designing for accessibility: A practical guide for WCAG 2.0 AA standards

Tiara Dobbs - Medium

Introduction to Grid Systems in Web Design

Tiara Dobbs - Medium

Organise and manage your Figma Design Files

Tiara Dobbs - Medium

NEXT STEPS

Road to bigger and better workflows

After the successful launch of the Design System, the team and I planned the next phase of development to grow the system. 

Monitor help center

Monitor help centre searches to improve content, address user pain points, and guide feature enhancements. 

Drive user onboarding and adoption

Drive adoption through educational workshops, champions program, and incentives.

Monitor Feedback

Provide feedback channels and actively review user critique about the design system. Conduct more usability testing if necessary.

Measure Impact

Evaluate key metrics such as decreased handover errors, activity and adoption.

Build Video Content

Video content that work in tandem with the help centre articles.

Drive feature request roadmap

Continue building, testing and refining feature roadmap and workflows within the app.

Research to validate pain points: The foundational research to confirm user frustrations and ensure we were addressing the right issues.

Progress over perfection: By focusing on solving the biggest pain points first, we reduced major friction and miscommunication between design and engineering significantly and improved overall project error rates by 50% within 3 months of adoption.

Flexible components: The platform was designed with adaptability in mind, making future updates and adjustments smooth and efficient.

StoryBook work has slowed: Upkeep of the storybook infustructure has slowed, meaning a large amount of tech debt has acumulated. A better process for managing updated needs to be clarified.

Refine documentation: Users have expressed concerns about a few of the documentations on the components. These concerns need to be looked at in more detail with suggestions made to improve the workflow.

Refinement of Governance model: The initial launch of the design system went smoothly however, after a few months of using the system, many designers workflows have decended into breaking component links and or building their own. Reasons why need to be further investigated.

NEXT STEPS

Testimonials

Jess - Sales

It's great to see a consistent experience across our applications. Each has similar patterns and ways of doing things making the explanation of each super easy

Elliot - CEO

The applications are looking great and the team seems to be humming really well with this new workflow

Ces - Newest addition to the design team

Doing my onboarding was super easy. I was able to get up and running within a few hours as everything was clear for me.

Mikael - Engineer

We still have a long way to go but I'm realy happy with the structure we have worked out