Design systems

I craft design systems that teams actually want to use, systems that are reusable, composable, and scalable. By working closely with designers and developers, I ensure both Figma and coded components align from the start, embedding tokenisation, accessibility, and flexibility into the foundation.

A great design system isn’t just documentation; it’s a living, evolving product that enables teams to build faster while maintaining consistency and quality. My focus is on reducing friction, increasing adoption, and helping teams create with confidence.

Muibook

A Native, Flexible Design System Built for Trusted Customisation

📖

Continue Reading on Medium

Thanks for checking out this post. You can also read it on Medium, where it’s part of my design system portfolio. Feel free to leave a comment, share your thoughts, or save it for later. I’d love to hear what you think.

Muibook.com is the home of the MichaelUI Design System (MUI), a collection of native Web Components built for composability, performance and trusted customisation. It helps you write less code with more flexibility and empowers teams to build quickly without losing control.

Muibook is designed to be framework agnostic, portable and future-friendly. It removes the bloat and rigidity found in traditional libraries with no forced conventions and no unnecessary abstractions. Instead, it offers clean patterns you can shape to fit your product.

And yes, when we say MUI here, we mean MichaelUI. Not the one owned by Google and their ad empire.

Fun fact: mui is a Māori word that means “to swarm round, infest, or flock to.” It’s a fitting name because, just like great components, a good design system naturally draws people in and becomes a hub for creativity and collaboration.

Why I Built This Design System

Design systems are hard to demonstrate in a portfolio sense. The work spans many touchpoints, Figma files behind logins, coded components inside private Storybooks, and internal docs that rarely see the light of day. And even when some of it is public, it’s often just a slice of the full picture.

Muibook is my way of showing what I believe a design system should be: not just UI components, but the full experience. That means Figma components, code, tokens, UX guidance and AI integration.

This is also my chance to highlight the kinds of details that are not easily showcased in portfolios, such as:

How I handle accessibility across both design and engineering, with live working examples of keyboard navigation
Usage and understanding of ARIA and role attributes are demonstrated through technical documentation and by reviewing the public code repository on GitHub.
My approach to multi-brand experiences using CSS variables
How I build for performance and composability
How I see AI shaping the future of design systems by exposing prompts and keywords through the system’s NPM package.

I’ve been writing front-end code for years, but I’ve always chased simplicity and clarity. I care deeply about how systems perform, how developers use them, and how design decisions flow into code. That’s why I chose Web Components over React. They offer native, reusable, framework-agnostic power.

This system started years ago as a personal component library. In 2025, I decided to take it further, turning my collection of ideas into a full design system. It includes categories like Inputs, Content, Layout, Feedback, Actions, and Navigation. Some of my favourite components are the ones that enable composability, such as Stack, Responsive, or Slat.

Muibook also became a playground for me to explore where this space is going. I created:

A demo site with documentation, live examples, and system recipes
A Figma UI Kit that mirrors the code
A multi-brand theming engine powered by design tokens
A part override strategy to support trusted customisation
An AI Playground, where the system can generate layouts from prompts
And an NPM package, complete with helper tools, AI metadata, and CDN support

This project taught me more than I expected, from publishing packages to building AI-aware component systems. The prompt and keyword work is just getting started, but I plan to expand it. I want to see if UX guidelines can be embedded into AI prompts, helping agents design responsibly, not just quickly.

Why Web Components?

In addition to preferring Web Components for their native, reusable, and framework-agnostic qualities, I also wanted a styling approach that didn’t rely on runtime CSS compilation via JavaScript. While I love the developer experience of libraries like Emotion and Styled Components, they can introduce performance overhead that isn’t ideal for every project.

Web Components offer the best of both worlds. They provide encapsulated styles through Shadow DOM and expose styling hooks via design tokens and ::part selectors. Inside a component, I can write scoped CSS with direct access to component props or attributes, enabling logic-driven styling without relying on class toggling or external utilities. This approach allows for flexible, dynamic theming without sacrificing performance or portability.

What I’ve Built So Far

🧱Core System

Built 30 Web Components focused on composability, flexibility, and a strong developer experience, with consistently applied prop types across components to make adoption easier over time
Encapsulated styles via Shadow DOM ensure visual isolation and prevent unintended style leakage across components
Components grouped across key categories: Inputs, Content, Layout, Feedback, Actions, and Navigation
Accessibility is built in, with support for ARIA roles, keyboard navigation, focus management, and screen reader alerts
Included a React Type Element file to enable clean usage in React without TypeScript errors
These components power internal products including muibook.com, play.muibook.com, guides.muibook.com, create.muibook.com
The projects mentioned above use either a lightweight vanilla JavaScript setup (via Vite) or the React framework, demonstrating that the system is framework agnostic

🏗️Styling Architecture

The system includes three core CSS files: Reset, Base, and Tokens, each playing a specific role in ensuring flexibility and consistency
Reset and Base CSS do not pierce the Shadow DOM, and are intended to set up a solid application foundation, providing sensible defaults and reducing browser inconsistencies
The Tokens file (CSS custom properties) can be inherited by Web Components, allowing for theming, overrides, and trustworthy customisation within a design system

🧩Design Tokens

I spent time carefully considering how tokens fit into each category. While the lines can be fuzzy, the real value of these groupings is in helping teams manage and scale theming. The categories aren’t the goal. The main objective is enabling consistent, flexible theming. Getting the base mapping right is what ensures your themes hold up without breaking the system’s core.

Supports Light and Dark mode theming
Enables brand theming through token customisation
The token system allows visual flexibility without editing the component source
Tokens are structured into: Brand, Semantic, Contextual, and Component-specific
Includes guidance for teams to customise tokens for different brands
Demo site showcases working examples of Light, Dark, and brand themes
The typography decisions displayed below are informed by my thinking around web typography, which I walk through in the video workshop

📘Demo Site

Designed & Built a demo site for browsing and testing components
Includes technical documentation for each component, usage examples, and live demos
Serves as a central hub with links to UX Guidelines, Create App, Theming, and more
Features real-world compositions to demonstrate UI recipes and best practices
Enables testing of theming, dark mode, and other system tokens in context
Validates the system internally and helps uncover gaps through dogfooding
Builds upon the baked-in accessibility of the components to create an inclusive demo site experience
Accessibility was considered when composing the demo site experience, including keyboard navigation, ARIA roles usage on components, and clear focus indicators
Demonstrates a commitment to inclusive design, even in internal tools, and showcases the ability to embed accessibility into component-based systems

🛠️Create App

Provided a starter template using Vite for quickly building lightweight apps with Muibook components
Demonstrates framework-agnostic usage via vanilla JS or React setups

📦NPM Package

All 30 agnostic components
Reset, Base and Token CSS styles
Type definitions
AI prompt and keyword tooling
React helpers to prevent TS errors when using Web Components
part-map util to enable part styling on selected components

🎨Styling System w/ CSS Parts

In the past, I experimented with React-based approaches like styled-system for styling components. While it felt useful at the time, I wouldn’t reach for it again. Instead, I now prefer encapsulated styles — applying layout classes directly to the host element. For cases where internal layout adjustments are needed, I introduced CSS Parts. This approach lets me extend and adapt components cleanly, which proved especially helpful when building composed components and the demo site.

Added a part-helper mode to select components for custom styling support
Introduced a structured ::part override strategy that makes overrides clear and intentional
Currently supported components include Link, Button, Stack, Grid, Body, and Select, with opportunities to extend support based on use cases
CSS Parts are structured into: Text, Spacing, Layout, and Visual
Read more in my article on CSS Parts

📚UX Guidelines

Guru Guides is a tool I built to help design system teams, especially smaller ones, publish UX guidelines directly inside Figma so designers can access them when needed, reducing context switching.

It provides ready-made templates and CMS integration to streamline content creation. I used it to accelerate the Muibook guidelines and dogfood the product, showing how it can be a cost-effective alternative to platforms like Zeroheight, especially since it is free.

Used Guru Guides (Read article) to serve the UX guidelines in Figma via a dedicated plugin
Whitelabelled Guru Guides to integrate Muibook Web Components, replacing React components to demonstrate flexibility and dogfood the system
The UX Guidelines at guides.muibook.com are actively in development as of this publication and will continue to evolve with the project

🖼️Figma System

Built 1:1 Figma components to match the coded components
Maintains consistent props and naming between Figma and code for smoother collaboration
View the Figma UI Kit , a work in progress that will continue to evolve with ongoing updates planned beyond this publication

🤖AI Integration

The MUI Playground dogfoods the CDN build published to NPM, allowing Web Components to load dynamically within the Agent’s sandboxed modal. This enables a lightweight, zero-install method for making the design system available in runtime and AI-driven environments

Built a MUI Playground that leverages AI to explore and interact with design components
Architected and exported a comprehensive set of keywords and prompts through the NPM package
Empowered AI tools with a deep understanding of the design system to enable smarter, context-aware usage
Launched the live AI Playground (Alpha) at play.muibook.com as a proof of concept
Additional defined prompts and broader component coverage are planned, with continued iteration expected after publication

What’s Next?

Muibook is a personal project, but it’s also an invitation. If you want to explore it, test it, or contribute, you’re more than welcome. It’s not perfect, and it’s not finished. But it’s real, and it’s growing.

This is my vision of what a connected, modern design system can look like, and the kind of system I’d want to use every day. I’ll be taking some time to reflect on what I’ve built, and I’ll continue to iterate and expand Muibook as the system evolves.

Explore Muibook

🌐 muibook.com — The technical component docs and examples

🌐 guides.muibook.com — Web access to the UX Guidelines for the Mui components

🌐 create.muibook.com — Kickstart your project with a lightweight scaffold built on Vite

🌐 play.muibook.com — The live AI playground (Alpha)

📦 npmjs.com/@muibook/components — Install and use the components

💻 github.com/michaeltrilford/muibook — Source, issues, and contributions welcome

Maturing Feelix

The Beginnings

In early 2018, MYOB launched a company-wide initiative to modernise its digital products and customer experiences. A key part of this transformation involved establishing a funded design system team focused on delivering tools, components, and guidelines to support consistent, high-quality experiences across product teams.

The Opportunity

I was part of the founding team behind the Feelix Design System , helping shape the system’s vision, foundational principles, and implementation strategy. My work included early discovery efforts, setting a clear roadmap, defining the contribution model, and guiding key decisions around whether to build or buy components. I also led work on token structures , tooling and responsive strategy.

Feelix Source of Truth — Source of Truth - feelix.myob.com

The Result

Feelix became the foundation for the rebuild of MYOB’s accounting software. It provided a complete set of UI building blocks used across the new platform, enabling teams to compose interfaces efficiently. The previous static Bootstrap interface was replaced with a fully responsive design that worked seamlessly across mobile, tablet, and desktop — and customers loved the experience.

Internally, shifting to a mobile-first, device-agnostic architecture was a major change in how MYOB approached front-end development. My work supported this architectural vision, the creation of a single source of truth portal, and the broader guidelines that enabled the system to scale across teams.

My Role

As a core contributor to the Feelix team, I played both strategic and hands-on roles — shaping the system from the ground up to ensure it could scale with MYOB’s evolving needs.

My contributions included:

Ensuring components follow atomic design principles
Restructure the design system to use scalable, modular CSS
Introduced responsive design across our components
Embedding a baseline grid for vertical rhythm
Defining a typographic scale with CSS
Designed the design token structure and naming convention
Leading the move to React layout components
Designing Feelix page templates and layout components
Expanding usage and technical guidelines
Explored automating the UI-Kit to reflect the Design System

MYOB Incite: New Essentials using Feelix

Essentials is fully mobile responsive. Was very cool to see the desktop screen resize to a tablet and then again to a mobile. Props, MYOB

digitalfirst.com - Sholto Macpherson

Guidelines at Your Fingertips

To maintain consistency across products at Airwallex during the design exploration phases, we closely integrated UX Guidelines within Figma, ensuring they were always accessible as designers prototyped new experiences. This approach helped designers utilise common patterns across products and avoid introducing multiple variations of similar approaches, aligning design intent with development execution from the outset.

Learn more about how I created high-quality guidelines.

What I learnt

While embedding guidelines directly in Figma made them highly accessible, it also introduced a significant performance challenge. Opening component pages would often trigger the memory warning, with noticeable lag and, at times, instability. This primarily affected the Design System team maintaining the content, but we quickly pivoted to avoid impacting other teams’ productivity when accessing those pages.

In response, we reduced the amount of visible guidance on component pages, replacing it with direct links to the relevant documentation in our central guideline workspace.

Moving forward, I was interested in exploring ways to make guidelines easier to access within Figma, even if the tool itself didn’t yet offer the features needed to support that kind of solution. That’s where the idea of a plugin to deliver guidelines directly in Figma began to take shape.

Introducing Guru Guides

Install Plugin • gurusuite.xyz

During my sabbatical in 2024, I began exploring more modular, on-demand approaches to delivering documentation. This led to the creation of Guru Guides, a Figma plugin that provides contextual access to Design System guidance without the performance overhead of embedding content directly into files. It allows designers to reference documentation as needed, without disrupting their workflow or slowing down the Figma experience.

Guru Guides is a free tool to help teams begin documenting their design system guidelines. The main goal is to increase engagement with guidelines during the design process, making it easier for designers to maintain consistency across products as teams grow. By bringing guidelines directly into Figma, we reduce context switching and help designers stay focused in their tool of choice, with guidelines at their fingertips whenever summoned.

Read the article: Guidelines at Your Fingertips

Customising Guru Guides

The plugin is highly customisable, allowing other teams to surface their own on-demand guidelines within the tools they already use. Guru Guides was designed with findability and scalability in mind. By integrating with Contentful, rather than embedding large volumes of content directly in Figma, it avoids the memory issues and crashes that can come from overloaded files. This approach keeps performance smooth, while still ensuring designers have access to the guidance they need, when they need it.

Feelix Roadmap

To create the Feelix roadmap, I employed a mix of techniques to support discovery, distil insights, and define a clear vision for the Design System to work towards. This approach drew on methods from James Kalbach’s Mapping Experiences, Jeff Gothelf’s blog on Agile product roadmapping, and the principles outlined in Outcomes over Output .

1. Discovery

The most important part of curating the roadmap was to visit the MYOB offices and run workshops to understand the pain-points within the Front-end space at MYOB.

1. Process Diagrams

In our workshops across MYOB, we asked the Front-end participants to map out the end-to-end journey when building experiences at MYOB. Once the journeys were mapped out, we asked a representative from each group to talk through the process. From the qualitative feedback collected, we were then able to begin the next phase of curating our roadmap.

The format of the workshops:

In groups, map out the current end-to-end journey when building products at MYOB.
Highlight pain points within the process
List some ideas on how to improve the areas of frustration

2. Organise Clues

The notes, audio recordings and process maps were analysed to uncover clues. I organised the findings into horizontal Do, Feel & Think lanes, with each note capturing a single customer point. Together, these lanes contributed to the development of overarching insights.

3. Distill Insights

The next task was to distil the lanes into clear insights. I grouped related clues into vertical lanes based on emerging themes. This structure helped surface key patterns, allowing me to craft a single sentence that captured the essence of each theme. These summaries were then placed in the Insight column for easy reference when shaping the roadmap.

2. Shape the Roadmap

With the discovery phase distilled into key Insights and Themes, we gained a clearer understanding of the high-level challenges within the Design System. The next step was translating these findings into actionable objectives that would inform our Roadmap.

We used Airtable to organise our findings by categorising insights under relevant themes and linking them to our draft roadmap items. This approach helped clearly illustrate the relationship between the problems identified during discovery and the objectives we planned to address. It also made it easier for team members and stakeholders to understand the rationale behind our strategic focus areas.

1. Insights

We grouped and categorised all insights uncovered during the discovery phase within Airtable.
These insights, along with their overarching themes, served as the foundation for defining objectives that would feed into our quarterly planning for the Design System team.

2. Roadmap Items (Objectives)

Each Roadmap Item is directly informed by the insights and themes from the discovery phase.
As we defined and refined these items, we mapped specific insights to each objective card in Airtable. This provided transparency and clear justification for our decisions.
The themes driving each objective came from recurring patterns in discovery.
Each roadmap item includes OKRs to help us measure progress and demonstrate impact.

Title: Unify Component Repositories

Objective: Migrate core styles into the widgets package to streamline development and contribution workflows across teams. This will help reduce friction and make it easier for teams to contribute new components to the Design System.

Insight: Engineers expressed frustration with managing two separate repositories. One for components (JS) and one for styles (CSS); which slowed progress and discouraged contributions to the shared system.

Key Results:

Complete migration of shared styles into the widget package.
Reduce average time to contribute a new component by 30%.
Increase cross-team contributions to the system by 50% quarter-over-quarter.
Collect feedback from 3+ engineers to validate the impact of the migration.

3. Backlog Items

Before we had a dedicated Design System team, there was a communal backlog of tasks. We wanted to ensure we captured the items that aligned with relevant themes and made sense to carry forward.
We reviewed and mapped relevant backlog items to the new roadmap objectives. This allowed us to prioritise meaningful work while still making use of previously identified opportunities or “nice-to-haves.”
By taking this approach, we ensured our work was intentional and strategic, avoiding reactive or disconnected task planning.

3. Outcome Roadmap

With priorities established and roadmap items defined, the next step was to align each objective to a strategic theme within a quarterly-based roadmap.

We adopted the Outcome Roadmap format inspired by Jeff Gothelf, structured around a Strategic Theme, supporting Objectives, and measurable Key Results. The roadmap uses a simple lane format with Upcoming, Doing, and Finished columns to track the duration and progress of each cycle. Each objective includes clear outcomes to demonstrate progress and indicate whether key customer behaviours are being positively influenced.

While our goal was to complete two objectives per quarter, we often included additional objectives to allow flexibility based on team capacity and shifting priorities.

Strategic Theme: Consistency and Scalability

Theme Description: Ensure design and development consistency across products and platforms, enabling the system to scale as the organisation grows.

Time Period: Q1, 2019

Title: Automate the UIKit in Feelix

Objective: Automate the Product Design UI Kit so it maintains a 1:1 match with the components available in the Feelix Design System. This alignment ensures Designers and Engineers are always working from the same source of truth.

Insight: Enhancing or creating new Feelix components requires Visual Design to manually update the Product Design UIKit. Maintaining a perfect match between design tooling and the live system is essential to avoid misalignment and unnecessary debate around deviations.

Key Results:

100% of components available in the chosen design tool
60% of collected design feedback is positive
Time spent by Visual Design updating the UI Kit is reduced to zero hours.
60% of developer feedback is positive and outweighs negative responses

Feelix Design Tokens

In late 2015, MYOB decided that React is our default engineering environment for building applications. When we formed as a Design System's team, our decision was easy; we were to move away from supplying traditional HTML and CSS snippets and provide a library of components built in React.

With this move to React componentry, it was our duty to enable teams to have access to the foundation of our design system still. Hence, we needed a way to easily gift foundational styles to align with the brand on any technology stack.

This ability to being agnostic is made possible by the concept of Design Tokens, which are stored design decisions or variables that consist of a single design decision, such as a defined colour or font size.

The introduction of Design Tokens also allows the Feelix Design System to use, so we can ensure the scalability and effort of adjusting the visual aesthetic of the system is most efficient.

If a brand update was to occur, the values defined in the root Design Token file could be adjusted; then the design decision will ripple across all of the instances it is declared.

Feelix used a tool called Styled-Dictionary, which uses a JSON file to create the range of Design Tokens Feelix offers. The structure of the JSON file influenced how we went about the naming convention of our design tokens, which follows this pattern.

flx-font-size-button

Feelix prefix

Property name

Component name

Since the introduction of Design Tokens, there have been numerous feature requests related to our Design Token offerings, thus showcasing the impact and value this single feature can provide.

Contribution Models

Every organisation is unique, and contribution models must reflect how teams operate. At MYOB, this was no exception. We recognised early on that while some teams were enthusiastic about contributing directly to the design system (Feelix), others lacked confidence or the capacity to create production-ready components.

At the same time, MYOB was undergoing a full platform re-architecture. This created both a challenge and an opportunity of how could we enable teams to innovate quickly, without creating silos or introducing one-off patterns.

In collaboration with lead architects and the design function, we developed a flexible "Harvest" model that respected each team’s autonomy while maintaining alignment across the organisation.

Principles of the Harvest Model

Empower teams to move fast with design and implementation.
Ensure visibility of new patterns within the design function.
Promote maturity and standardisation before formal adoption.
Minimise bottlenecks and reduce reliance on the core design system team.

Creating New Components

Release customer value

Test with the market

Maintain quality of the system

Harvest the successful components

Phase 1

Design, test & align

Prove that Feelix can’t solve your problem
Critique the alternative solution(s) to Feelix
Circulate the alternative solution(s) to Feelix
Document the new solution in Labs
Follow the "Design, validate and align" steps

Phase 2

Build & use the component

The designer has completed the required supporting component documentation and there is clear alignment within the team Leadership
The development team can begin building the new component and then use the new experience to release the to market.

Phase 3

Submit to the DSC

Designers can propose a validated component for the Feelix Design System.
Submit the working component and documentation outlining the problem it solves to the DSC.
The DSC will review and decide if the proposal is appropriate for Feelix.

Phase 4

Feelix adopts it

The data is showcasing broad adoption of the component
A significant customer problem is solved
The component will be added to Feelix.

Phase 5

Team replaces it

Feelix has added the component to the Design System.
The Design System team has requested the development team to upgrade to the Feelix version with the newly added component.

Challenges

Misalignment of expectations: Some teams saw the Feelix team as a delivery function for their roadmap work, rather than partners in maintaining a shared system. This limited shared ownership and led to unrealistic assumptions about our role.

Cultural resistance: In parts of the design function, there was hesitation to follow the contribution process. Some teams tried to offload work to the system team instead of collaborating, slowing down adoption and shared learning.

How We Addressed This

Roles & Responsibilities: We introduced clear documentation outlining what the Design System team owns, supports, and doesn’t take on. This helped set expectations and encouraged accountability, though it also revealed a need for deeper cultural alignment.

Education & Coaching: We ran hands-on DSC sessions focused on contribution practices, supported by designers and engineers from Feelix. By pairing with teams to shape components and build together, we reduced friction and built capability.

Enhancing Existing Components

Create Prototype

Test with the market

Maintain quality of the system

Harvest the successful enhancement

Phase 1

Design, test & align

Prove that Feelix can’t solve your problem
Critique the alternative solution(s) to Feelix
Circulate the alternative solution(s) to Feelix
Document the new solution in Labs
Follow the "Design, validate and align" steps

Phase 2

Submit to the DSC

Designers enhancing a Feelix component must add usage guidelines and the Sketch file to the shared library.
They should share the design direction and component template, explaining the problem it solves.
The DSC will review and discuss the enhancement. If there are no concerns and all documentation is complete, the enhancement is approved.

Phase 3

Feelix adopts it

The successful enhancement will be added to the Feelix Coordination Board and can be prioritised accordingly.
Once Feelix has completed the enhanced Feelix component, teams will be notified what version of Feelix it has been added to, so they can begin the next phase.

Phase 4

Update & test Feelix version

The team has been notified what version of Feelix the enhancement has been added to.
The team(s) can now plan for an appropriate time to upgrade their version of Feelix to access the new feature or behaviour.

Phase 1: Design, validate and align

Test with the market

Step 1

Prove that Feelix can’t solve your problem

Touchpoints

Variant testing with users
Assigned critique

Suggested actions

Show why current components can’t solve the user problem.
Demonstrate how alternative solutions address the issue.
Gather evidence to support your decisions.
Seek critique early.

Step 2

Critique the alternative solution(s) to Feelix

Touchpoints

Team
Assigned critique

Suggested actions

Show why current components can’t solve the problem.
Demonstrate how alternative solutions work.
Share success/failure results of both.
Confirm technical feasibility.

Step 3

Circulate the alternative solution(s) to Feelix

Touchpoints

Team leadership
Design team on Slack

Suggested actions

Show how current Feelix components fail to solve the problem.
Show how alternative solutions work.
Provide evidence that alternatives solve the problem.

Step 4

Document the new solution in Labs

Touchpoints

MYOB Confluence
Design team on Slack

Suggested actions

Create a new page under “Labs components” on Confluence using the “Labs template.”
Add the Sketch file for the component to the page.
Inform the design team and link them to the new component for your engineering team.

Reflections

The harvest-based contribution model at MYOB helped shift the mindset from designing for the system to designing for customers first, then bringing proven solutions back into the system. It enabled teams to move quickly, validate ideas in market, and share learnings that shaped the evolution of Feelix. While success relied on strong communication, cultural buy-in, and a shared sense of ownership, the result was a more adaptive, scalable, and relevant system. One that could keep pace with the diversity of product needs without sacrificing cohesion or quality.

Build or Buy

At one point, our stakeholders raised the question: should we continue investing in our in-house system, born from a labour of love, or adopt an off-the-shelf alternative?

To explore this, we ran a structured assessment of both options. We considered what would best support MYOB’s teams and deliver long-term value to our customers. After looking at technical fit, brand alignment, scalability, and user experience, we decided to continue investing in the Feelix Design System.

Originally launched in 2018, Feelix had already become a more mature and reliable solution by 2019. It offered stronger brand alignment, better developer experience, and a more consistent customer experience. Continued investment in Feelix meant MYOB could deliver high-quality experiences faster and with greater confidence.

Kendo overview
0% open-source components
0% brand alignment
10 React components
31 jQuery components
41 total components

Feelix overview
**24%** open-source components
**100%** brand alignment
44 React components
0 jQuery components
44 total components

Typography on the web

This workshop provides an introduction to the history of typography through letterpress and how we can use this foundation to inform our decisions when creating a typographic vertical rhythm with the use of a baseline grid.

Embed these techniques within your foundational CSS file, which will be within your websites, web-apps or preferably a Design System.

By setting these decisions with the foundational CSS file, it will ensure there is a well-balanced and rhythmic experience across the entire product range.

Designing for Better Developer Collaboration

My name is Michael Trilford, and I’ve been working in a role known as a Design Technologist for the past two and a half years, leading the Design System thinking at MYOB within Product Delivery.

During my time working with the Product and Delivery groups, I have observed opportunities to improve help improve relationships between Design and Development. I want to share the observations, and provide thoughts on how we, as Product Designers can make some small tweaks in our design and collaboration processes to improve the relationships between Design and Developers significantly.

Reduce developer confusion during hand-over

My role allows me to consult both Product and Delivery on Design System related questions. Through this consultation, I have gained insight into the Product Delivery Teams, as they are often confused around an experience they are building because a component they need is not in the Design System.

For example, the designed experience has:

a Design System adjustment which doesn’t match the Design System; or
an unbuilt component is included within the design artefact.

Often these adjustments or new additions are not disclosed to the Product Delivery Team during the planning and only discovered once the work begins.

Our team is looking for this component in the Design System, why can’t I find it?

The example above provides insight into how a simple deviation from the Design System or including a new component without a proper hand-over can raise some confusion among the Product Delivery Team members.

I have seen this confusion impact the teams productivity directly, as the group is using their time to unravel the mystery of what is in the Design System, and what is not. Unfortunately, the confusion is met with frustration, as often the experiences don’t exist.

The Product Delivery Team will have to:

find a way to complete the task themselves; or
revisit the designed experience to use what is in the Design System

Either option can be frustrating for all involved:

as the task has grown in scope; or
the Product Designer needs to revisit an existing design.

A simple way to avoid unknown requirements or rework of the design is to learn about the constraints sooner in the process. To ensure Product Delivery Teams understand what is required to build the experience, you can ask yourself some simple questions from the hand-over checklist below. These questions will help you drive the conversation with your Product Delivery Team around the details for the experience you intend to build.

Hand-over checklist:

Are there any Design System adjustments in the workflow/task you have created?
Do you have any newly designed components in the workflow/task that are not in the Design System?

If a question is answered as ‘Yes’, it is important to highlight these critical areas of the experience to your Product Delivery Team so that the team can have a conversation about the work and make a plan.

If you’re indicating a Design System adjustment is required for the designed experience, it is essential to know who can adjust the Design System within your organisation.

Some organisations may have:

a dedicated Design System team with existing priorities; or
the responsibility is shared across teams to adjust the Design System.

Depending on that governance model, it may impact the ability for your Product Delivery Team to deliver on their forecasted timeline as expected.

If there is:

work required outside of your Product Delivery Team, there is no guarantee that work will be completed in time to release the team objective to market; or
if your Product Delivery Team is expected to adjust the Design System, please check with the group involved first, as it may not be a task they are comfortable or have the specific skills required to complete the job.

Once it is known who can adjust the Design System, it is now time to understand the effort involved with adjusting a Design System decision.

Understanding of the effort that is required to adjust the Design System

Stages of adjusting a Design System:

Designer designs the Design System change
Design System implements the change
Design System regression tests the change
Design System releases a new version
Product Delivery Team upgrades its Design System version
Product Delivery Team regression tests the update
Product Delivery Team can now start the objective
Product Delivery Team can complete the experience
Product Delivery Team releases the experience to market

From start to finish, a Design System change can take 1–2 weeks, then best case scenario it will take another 1–2 weeks for the website or application to upgrade their version of the Design System. Worst case is the application is highly complicated and have many dependencies, and the time on task to upgrade could change from weeks to a month or more.

Until that upfront work is completed, is when the Product Delivery Team can even consider finalising the experience and releasing value to the market.

This insight may allow you to reframe and ask whether:

is the Design System change necessary; or
is the existing Design System suitable for now?

Please remember, Design System changes can be made outside of a Product Delivery release, as the Design System is product agnostic.

The adjustments can either be:

briefed to the Design System team to review and complete the work in a separate stream of work. The next time your application goes through their upgrade cycle, those adjustments will be inherited into the past released experiences automatically; or
if your team is responsible for Design System upgrades, the team can plan for the work as an iteration to the main feature release.

In closing

By reducing confusion during hand-over and gaining an understanding of the effort that is required to adjust the Design System, we, as Product Designers, can drive a more collaborative/supportive/positive relationship between Product Design and Development. This new dynamic provides the Product Delivery Team with an opportunity to deliver faster, and learn from those experiences more regularly, gaining more time to fine-tune the end experience that benefits the end customer.

Please remember to:

Highlight key areas of the designed experience that don’t exist in the Design System.
Use the Design System version your Product Delivery Team is tied to, as updating and upgrading a Design System is expensive.
When you do find an opportunity to improve the Design System, separate the concerns and introduce the improvement outside the current stream of work.

Design sprints

Early on in my career as a designer, I was fortunate enough to move from the Waterfall process to an Agile way of working. Instead of working separately, the agile process enabled a lot more collaboration much earlier in the process, which allowed for fresh ideas from different disciplines to be suggested.

With the popularity and collaborative nature of a Design Sprint, it has helped eliminate wasteful upfront design and replace it with a collaborative process where we generate, discuss, test and discard ideas until we know we are solving the customer problem successfully.

Rural accounting sprint

In this design sprint, the cross-collaborative group looked to solve known and unknown problems within the Accounting rural space.

1. Discovery

Before kicking off the design sprint, I undertook discovery sessions with Accountants within the Rural domain. The Rural area was very new to me, so I researched the space by talking to internal resources at MYOB, which helped shape a mindmap of questions that helped me formulate the basis of the interview script.

2. Lightning talks

The Product Manager and I each gave a 5-minute talk to the group involved in the design sprint. My role was to present the customer problems, which I referred to the findings from the interviews carried out with the rural accountants. Supporting the talks, we also used storyboarding to tell the more complex experiences from the discovery sessions.

3. Journey map

From the lightning talks, this enabled the cross-collaborative group to map out the customer journey from the initial user discovery. Once a journey was mapped out, this provided the group with an informative view of the customer's experience. This new perspective allowed the group to identify problem areas within the journey and then eliminate them from the journey.

I transformed the group activity of prototyping the customer journey into a high-fidelity version so that we could reference it later with stakeholders or new additions to the team, which would help with onboarding them to the domain.

4. Prototyping

Once we identified opportunities within the journey map, the group worked together to formulate hypothesises, which the group could start to ideate using the crazy eight exercise. The task consisted of dividing an A3 sheet of paper into eight sections, and then the task of generating ideas would commence. Once completed, each person would share their ideas, and another round of conceptualising would begin, where the presented approaches can be used for inspiration. This exercise is a great process to gain alignment and come up with new ideas.

5. User testing

After completion of the lo-fi prototype, the cross-collaborative team was able to create a hi-fi prototype rather swiftly. While the prototype was being prepared, I created a script for the user test and recruited users for the validation exercise to prove or disprove the hypothesis. When the user testing sessions were underway, the cross-collaborative group attended the session and recorded notes, which I then grouped into relevant sections to extract the insights from the user test so that we could analyse the success or failure of the prototype.

Storytelling

To support the rural accounting initiative and sprint at MYOB, we visualised the current user journey to educate the engineering team. This helped the team collaborate effectively and contribute to the project’s goals. Storyboarding proved invaluable, transforming verbatim insights into an engaging, shareable format.

E.g: Rural GST period

E.g: Rural operational advisory

Build or Buy

At one point, our stakeholders raised the question: should we continue investing in our in-house system, born from a labour of love, or adopt an off-the-shelf alternative?

Technology

My portfolio website has been through many exciting iterations, as this is the playground for personal growth within the Front-End environment.

When I decided to iterate on my website, I looked to use my personal reset and base CSS, MUI native web component project to provide base elements to build the experience, React CLI for bringing life to the website, CSS Variables to define Design Tokens and Styled-Components to introduce specific page layout and application component styles.

Mui reset & base styles

Over the years of creating websites, I have meticulously crafted a CSS file overtime that has many design decisions embedded within it. I have used it at the very heart of this website since its inception, and I continue to use it today.

The way people think about styling websites and applications has changed, and my latest addiction is to understand how that consolidated list of styles can be broken down into a lightweight base for any modern day website.

When simplifying the Mui Reset and Base styles, I also had reusable chunks of CSS that would help speed up the process of building familiar UI, and we call these components. In the next section, I will talk about how I extracted these styles and arranged them in a way that can be ported to any modern-day Front-End stack, such as Native Web Components, Vue or React.

Mui web components

I quickly found an issue using the web components within the React framework, as referencing the CSS reset within the shadow-dom fails to work. I have yet to determine the cause, but I'm assuming it has something with how React compiles the CSS files and the path shifts.

@import url("css/mui-reset.css");

I can either refactor my native web component project to have more of the reset styles directly within the component or look to port these native components over to a React component, which was my first intention.

What I decide will certainly help shape the future for that personal project.

React CLI, Github and Netlify

When I tweak my website or update some content, I will do the following to push the changes live.

Run a build in the terminal
Commit that change to my personal Github account
Netlify will then deploy the changes to michaeltrilford.co.nz

CSS Variables

Since I'm only supporting modern browsers on my website, I have opted to use CSS Variables as my Design Token Library. The naming convention adopted here is different from the Feelix approach, as I wasn't limited on the JSON structure.

The tokens consist of a foundational set, which reference colours, font sizes, etc. Then these foundation tokens are mapped to specific uses cases, such as the colour of a link.

Styled-Components

Working with Styled-Components is terrific, as I find it helps to improve the overall architecture of the codebase.

If you are familiar with Sass, then you will feel right at home, as you have access to nesting and other useful techniques. The bonus with Styled-Components is that any style introduced is encapsulated within that specific file.

You can continue to use classNames to style your custom elements or slight modifications to existing components.

Alternatively, you can use Styled-Components to declare a component that has specific styles associated with it, that you can reuse within that document.

const ContainerElement = styled.div

The great thing about this, it helps identify new components that you could lift out of the specific file, and add globally to your website or application so that you can use it elsewhere.

Styled-System

Styled System provides style API's to give users a way to attach additional styles to React components when wanting to craft spacing, layout, the typography of an experience.

Utilising the theme

With the CSS Variables (design tokens) I mentioned earlier, I have mapped them to the styled-components `Theme.js` file. I have opted for a more refined naming convention, which I will introduce to my CSS Variables in future. The good thing is, they're agnostic, so I can map them together, and iterate on that naming convention at another time.

// Theme.js snippet

space: {
  largest: "var(--spacing-x-large)",
  larger: "var(--spacing-large)",
  large: "var(--spacing-x-medium)",
  medium: "var(--spacing-medium)",
  small: "var(--spacing-small)",
  smaller: "var(--spacing-x-small)",
  smallest: "var(--spacing-tiny)",
  clear: "var(--spacing-clear)",
}

Simple styled-system components

You can create powerful layout components by simple combining Styled-components and Styled-system together. The seemingly inline style will transpile into the application head element, so the CSS is performant.

const Box = styled.div`
  ${space}
  ${layout}
  ${color}
  ${flexbox}
`;

<Box marginBottom="small" /> `;

Complex styled-system components

Remember to spread the props when installing styled-components inside your React components. Additionally, add the styled-system API's at the end of the styled-components styles, as this will allow the custom styles to override the foundation styles naturally.

const LinkElement = styled.a`
  ... relevant styles ...
  ${space}
  ${layout}
  ${color}
  ${flexbox}
`;

const Link = ({
  children,
  ...props
}) => {
  return (
    <LinkElement {...props}>
      {children}
    </LinkElement>
  );
};

Modernising My Foundations

Over time, my approach to foundational styling has shifted to favour simplicity and composability. I have moved away from applying rigid base styles, such as default margin-bottom on elements, in favour of context-aware layout patterns using components like Stack or Box. This gives me greater flexibility, particularly when creating custom layouts. For example, while a marketing website might still benefit from consistent vertical rhythm, web apps often require more control.

While I previously used Styled-components, I now prefer Emotion.js for its flexibility and seamless integration with component libraries. I also explored Styled System, but ultimately found that embracing native CSS - with variables and composable patterns - offered a cleaner, more intuitive way to scale design. In my opinion, Styled System adds unnecessary complexity when modern CSS and a thoughtful component architecture can already do so much.

Code reminders

Inline If with Logical && Operator

Below is an example of showing an element only if the property is defined on the component.

// If this property is used, render this element. {propNameHereUsed && (<div>{propNameHereUsed}</div>)}

Inline If-Else with Conditional Operator

Below is an example of how styled-components uses the condition.

// If this condition, render true and then false.twoColumns ? "1fr 1fr" : ""

Exporting Data in React

Separating data from the application and making it available to import

export const codeReminders = [ ... ];

Importing data in React

import { codeReminders } from "./data";

Fixing React Route Refresh Issues on Netlify

When deploying a React app with client-side routing, refreshing on a subpage (e.g., /about) can lead to a 404 error because the server doesn’t recognize the route. On Netlify, this can be fixed by adding a `_redirects` file with the rule:

/* /index.html 200

Handling state in React

Previously if you needed to access state in your component, you would need to utilise a class component and add additional code to initialise state with the constructor. With the introduction of React Hooks, you can use your function-based components and keep your code lean and straightforward.

Old

Handle state with the constructor method.

New

Handle state with Hooks.