Design Systems & Governance
Scaling a shared product language
Contributing foundations, reusable patterns and accessibility thinking across a growing product ecosystem.
Role
Senior Product Designer
Period
Jan 2025 – Jun 2026
Duration
18 months
Team
Designers and engineers across products
01
Why a shared language was needed
At Akur8, I contributed to the shared foundations and interaction patterns behind a growing product ecosystem. As the organisation moved from one product to several, the way consistency was being maintained started to break down.
A shared Figma file offered reusable components, but limited guidance on how to combine them into coherent patterns. Without shared code or centralised documentation, engineers often recreated solutions independently.
My focus was on recurring product problems, particularly colour, forms, navigation, tables and feedback patterns, while working closely with designers and engineers to make those patterns usable in real product work.
Consistency could no longer live inside a single product.
02
What I owned
I was one contributor to a broader system. My strongest ownership sat around foundations and recurring product patterns, while other areas were led by different people. Here is how I think about where my contribution sat.
Focused on
Semantic colour foundations
Form components and interaction states
Navigation patterns
Table components and usage guidance
Feedback patterns
Influenced
Accessibility reviews
Adoption inside product work
Icons and iconography guidance
Collaborated on
Component documentation and guidance
Implementation discussions with engineering
Ongoing evolution of shared patterns
The objective wasn’t simply consistency. It was making good decisions easier to repeat.
How I think about a shared product language
03
Making the system useful
Building components was only a small part of the work. The real challenge was helping people understand when, why and how each pattern should be used.
Component library alone
C
Button
Primary, secondary, disabled variants
C
Input
Text, number, select variants
C
Modal
Small, medium, large variants
Teams know what components exist. They don’t know when to use them or why decisions were made.
Shared product language
P
Pattern: Data validation
When to show errors, warnings and success states, and why
P
Guidance: Empty states
How to help users understand what to do next
P
Principle: Progressive disclosure
When to reveal complexity and when to defer it
Teams understand the reasoning behind decisions. Reuse becomes a natural choice rather than extra work.
I noticed early that most of the inconsistency wasn’t from people ignoring the components. It came from not knowing what to reach for, or not understanding why a pattern existed. That pushed me toward writing guidance alongside the component work.
Forms and interaction states
Problem
Inconsistent feedback across products made it hard for users to understand what had happened and what to do next.
What I contributed
I standardised loading, validation, empty and disabled states so the same situation always looked and behaved the same way.
Navigation patterns
Problem
Navigation components varied between products without a shared rationale, creating inconsistent mental models for users working across multiple tools.
What I contributed
I worked on patterns that could flex to different product contexts while keeping the underlying behaviour consistent.
Table components
Problem
Tables appeared in multiple products with different structures, sort behaviours and density options.
What I contributed
I designed a table component and usage guidance that addressed the most common scenarios, with enough flexibility for product-specific needs.
Feedback patterns
Problem
Feedback was inconsistently placed, varied in severity and did not follow accessible contrast standards.
What I contributed
I connected feedback states to the semantic colour system and reviewed them against accessibility criteria for contrast, focus and ARIA.
04
Working across design and engineering
I worked closely with designers and engineers to test patterns against real product needs, discuss implementation constraints and improve guidance when something did not translate cleanly into product work.
The most useful conversations happened when a pattern met a real product problem that it wasn't quite designed for. Those moments pushed the system to become more specific and more useful.
How collaboration worked in practice
Testing patterns against real product problems before publishing them
Working with engineers to understand implementation constraints
Updating documentation when guidance didn't translate clearly
Reviewing implementations to catch accessibility gaps early
05
Making shared work sustainable
I learned that a design system becomes much more resilient when decisions are understandable beyond the person who first made them. That pushed me to put more emphasis on rationale, documentation and collaboration rather than treating the design file as the source of truth.
When ownership became distributed across the team, the parts of the system with the clearest reasoning continued to evolve. The parts that relied on implicit knowledge were harder to maintain.
1
Weekly committee
A regular space for shared decisions and continuity.
2
Slack support
Questions and implementation issues stay visible.
3
Product syncs
Product needs shape the system’s next priorities.
4
Roadmap
Shared priorities become a sustainable direction.
06
What I took forward
Patterns need product context
A component is only useful when it solves a recurring product problem. The strongest system work happened when I was close enough to real product decisions to understand what was actually needed.
Consistency needs explanation
Reuse improves when people understand the reasoning behind a pattern, not just where to find it. Documentation that explains the why is more durable than documentation that describes the what.
Systems are collaborative
Some of my strongest design-system work happened in the conversations between design and engineering, where a gap between intention and implementation revealed something the pattern hadn't accounted for.
A design system isn’t successful because it has great components. It’s successful because people trust it enough to build with it every day.
Next case study
Making complex reserving workflows easier to navigate
Read on →
Design Systems & Governance
Scaling a shared product language
Contributing foundations, reusable patterns and accessibility thinking across a growing product ecosystem.
Role
Senior Product Designer
Period
Jan 2025 – Jun 2026
Duration
18 months
Team
Designers and engineers across products
01
Why a shared language was needed
At Akur8, I contributed to the shared foundations and interaction patterns behind a growing product ecosystem. As the organisation moved from one product to several, the way consistency was being maintained started to break down.
A shared Figma file offered reusable components, but limited guidance on how to combine them into coherent patterns. Without shared code or centralised documentation, engineers often recreated solutions independently.
My focus was on recurring product problems, particularly colour, forms, navigation, tables and feedback patterns, while working closely with designers and engineers to make those patterns usable in real product work.
Consistency could no longer live inside a single product.
02
What I owned
I was one contributor to a broader system. My strongest ownership sat around foundations and recurring product patterns, while other areas were led by different people. Here is how I think about where my contribution sat.
Focused on
Semantic colour foundations
Form components and interaction states
Navigation patterns
Table components and usage guidance
Feedback patterns
Influenced
Accessibility reviews
Adoption inside product work
Icons and iconography guidance
Collaborated on
Component documentation and guidance
Implementation discussions with engineering
Ongoing evolution of shared patterns
The objective wasn’t simply consistency. It was making good decisions easier to repeat.
How I think about a shared product language
03
Making the system useful
Building components was only a small part of the work. The real challenge was helping people understand when, why and how each pattern should be used.
Component library alone
C
Button
Primary, secondary, disabled variants
C
Input
Text, number, select variants
C
Modal
Small, medium, large variants
Teams know what components exist. They don’t know when to use them or why decisions were made.
Shared product language
P
Pattern: Data validation
When to show errors, warnings and success states, and why
P
Guidance: Empty states
How to help users understand what to do next
P
Principle: Progressive disclosure
When to reveal complexity and when to defer it
Teams understand the reasoning behind decisions. Reuse becomes a natural choice rather than extra work.
I noticed early that most of the inconsistency wasn’t from people ignoring the components. It came from not knowing what to reach for, or not understanding why a pattern existed. That pushed me toward writing guidance alongside the component work.
Forms and interaction states
Problem
Inconsistent feedback across products made it hard for users to understand what had happened and what to do next.
What I contributed
I standardised loading, validation, empty and disabled states so the same situation always looked and behaved the same way.
Navigation patterns
Problem
Navigation components varied between products without a shared rationale, creating inconsistent mental models for users working across multiple tools.
What I contributed
I worked on patterns that could flex to different product contexts while keeping the underlying behaviour consistent.
Table components
Problem
Tables appeared in multiple products with different structures, sort behaviours and density options.
What I contributed
I designed a table component and usage guidance that addressed the most common scenarios, with enough flexibility for product-specific needs.
Feedback patterns
Problem
Feedback was inconsistently placed, varied in severity and did not follow accessible contrast standards.
What I contributed
I connected feedback states to the semantic colour system and reviewed them against accessibility criteria for contrast, focus and ARIA.
04
Working across design and engineering
I worked closely with designers and engineers to test patterns against real product needs, discuss implementation constraints and improve guidance when something did not translate cleanly into product work.
The most useful conversations happened when a pattern met a real product problem that it wasn't quite designed for. Those moments pushed the system to become more specific and more useful.
How collaboration worked in practice
Testing patterns against real product problems before publishing them
Working with engineers to understand implementation constraints
Updating documentation when guidance didn't translate clearly
Reviewing implementations to catch accessibility gaps early
05
Making shared work sustainable
I learned that a design system becomes much more resilient when decisions are understandable beyond the person who first made them. That pushed me to put more emphasis on rationale, documentation and collaboration rather than treating the design file as the source of truth.
When ownership became distributed across the team, the parts of the system with the clearest reasoning continued to evolve. The parts that relied on implicit knowledge were harder to maintain.
1
Weekly committee
A regular space for shared decisions and continuity.
2
Slack support
Questions and implementation issues stay visible.
3
Product syncs
Product needs shape the system’s next priorities.
4
Roadmap
Shared priorities become a sustainable direction.
06
What I took forward
Patterns need product context
A component is only useful when it solves a recurring product problem. The strongest system work happened when I was close enough to real product decisions to understand what was actually needed.
Consistency needs explanation
Reuse improves when people understand the reasoning behind a pattern, not just where to find it. Documentation that explains the why is more durable than documentation that describes the what.
Systems are collaborative
Some of my strongest design-system work happened in the conversations between design and engineering, where a gap between intention and implementation revealed something the pattern hadn't accounted for.
A design system isn’t successful because it has great components. It’s successful because people trust it enough to build with it every day.
Next case study
Making complex reserving workflows easier to navigate
Read on →
All case studies →
Design Systems & Governance
Scaling a shared product language
Contributing foundations, reusable patterns and accessibility thinking across a growing product ecosystem.
Role
Senior Product Designer
Period
Jan 2025 – Jun 2026
Duration
18 months
Team
Designers and engineers across products
01
Why a shared language was needed
At Akur8, I contributed to the shared foundations and interaction patterns behind a growing product ecosystem. As the organisation moved from one product to several, the way consistency was being maintained started to break down.
A shared Figma file offered reusable components, but limited guidance on how to combine them into coherent patterns. Without shared code or centralised documentation, engineers often recreated solutions independently.
My focus was on recurring product problems, particularly colour, forms, navigation, tables and feedback patterns, while working closely with designers and engineers to make those patterns usable in real product work.
Consistency could no longer live inside a single product.
02
What I owned
I was one contributor to a broader system. My strongest ownership sat around foundations and recurring product patterns, while other areas were led by different people. Here is how I think about where my contribution sat.
Focused on
Semantic colour foundations
Form components and interaction states
Navigation patterns
Table components and usage guidance
Feedback patterns
Influenced
Accessibility reviews
Adoption inside product work
Icons and iconography guidance
Collaborated on
Component documentation and guidance
Implementation discussions with engineering
Ongoing evolution of shared patterns
The objective wasn’t simply consistency. It was making good decisions easier to repeat.
How I think about a shared product language
03
Making the system useful
Building components was only a small part of the work. The real challenge was helping people understand when, why and how each pattern should be used.
Component library alone
C
Button
Primary, secondary, disabled variants
C
Input
Text, number, select variants
C
Modal
Small, medium, large variants
Teams know what components exist. They don’t know when to use them or why decisions were made.
Shared product language
P
Pattern: Data validation
When to show errors, warnings and success states, and why
P
Guidance: Empty states
How to help users understand what to do next
P
Principle: Progressive disclosure
When to reveal complexity and when to defer it
Teams understand the reasoning behind decisions. Reuse becomes a natural choice rather than extra work.
I noticed early that most of the inconsistency wasn’t from people ignoring the components. It came from not knowing what to reach for, or not understanding why a pattern existed. That pushed me toward writing guidance alongside the component work.
Forms and interaction states
Problem
Inconsistent feedback across products made it hard for users to understand what had happened and what to do next.
What I contributed
I standardised loading, validation, empty and disabled states so the same situation always looked and behaved the same way.
Navigation patterns
Problem
Navigation components varied between products without a shared rationale, creating inconsistent mental models for users working across multiple tools.
What I contributed
I worked on patterns that could flex to different product contexts while keeping the underlying behaviour consistent.
Table components
Problem
Tables appeared in multiple products with different structures, sort behaviours and density options.
What I contributed
I designed a table component and usage guidance that addressed the most common scenarios, with enough flexibility for product-specific needs.
Feedback patterns
Problem
Feedback was inconsistently placed, varied in severity and did not follow accessible contrast standards.
What I contributed
I connected feedback states to the semantic colour system and reviewed them against accessibility criteria for contrast, focus and ARIA.
04
Working across design and engineering
I worked closely with designers and engineers to test patterns against real product needs, discuss implementation constraints and improve guidance when something did not translate cleanly into product work.
The most useful conversations happened when a pattern met a real product problem that it wasn't quite designed for. Those moments pushed the system to become more specific and more useful.
How collaboration worked in practice
Testing patterns against real product problems before publishing them
Working with engineers to understand implementation constraints
Updating documentation when guidance didn't translate clearly
Reviewing implementations to catch accessibility gaps early
05
Making shared work sustainable
I learned that a design system becomes much more resilient when decisions are understandable beyond the person who first made them. That pushed me to put more emphasis on rationale, documentation and collaboration rather than treating the design file as the source of truth.
When ownership became distributed across the team, the parts of the system with the clearest reasoning continued to evolve. The parts that relied on implicit knowledge were harder to maintain.
1
Weekly committee
A regular space for shared decisions and continuity.
2
Slack support
Questions and implementation issues stay visible.
3
Product syncs
Product needs shape the system’s next priorities.
4
Roadmap
Shared priorities become a sustainable direction.
06
What I took forward
Patterns need product context
A component is only useful when it solves a recurring product problem. The strongest system work happened when I was close enough to real product decisions to understand what was actually needed.
Consistency needs explanation
Reuse improves when people understand the reasoning behind a pattern, not just where to find it. Documentation that explains the why is more durable than documentation that describes the what.
Systems are collaborative
Some of my strongest design-system work happened in the conversations between design and engineering, where a gap between intention and implementation revealed something the pattern hadn't accounted for.
A design system isn’t successful because it has great components. It’s successful because people trust it enough to build with it every day.
Next case study
Making complex reserving workflows easier to navigate
Read on →