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.
Maturing Feelix
In early 2018, MYOB began a major project to shape its future. A key part of this was creating a funded design system team to provide tools that help teams build consistent, high-quality experiences efficiently. With this team’s formation, I had a great opportunity to help shape the future vision of the Feelix design system.
My Feelix involvement
- Ensuring components follow atomic design principles
- Restructuring the design system to use scalable and modular CSS
- Introducing Responsive web design across the Feelix foundation and components
- Embedding a baseline grid for vertical rhythm
- Defining a typographic scale with CSS
- Designing the Feelix design token structure and naming convention
- Leading the shift to React layout components instead of using Bootstrap classes to create a layout
- Driving the design and experience of Feelix page templates
- Expanding usage and technical guidelines
- Automate the UI-Kit to mirror the Feelix Design System
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 MacphersonIntegrate Guidelines in Figma
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.
Designing the roadmap
With the discovery and roadmap creation tasks, I used a few methods that range from James Kalbach's Mapping Experiences and Jeff Gothelf's Agile product roadmap blog post and Outcomes over Output publication.
1. Discovery
The most important part of designing the roadmap was to visit the MYOB offices and run workshops to understand the pain-points within the Front-end space at MYOB.
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 designing 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
Distilling insights
The notes, audio and process maps were analysed for clues. Each clue captured consisted of 1 customer point per post-it note, and as many as the collected data can provide. To simplify the data analysis, I arranged the clues horizontally into Do, Feel & Think lanes.
The next task was to distil the qualitative data into actionable insights. I began organising the clues into vertical lanes that represented common themes. This arrangement allowed me to write a single sentence that captured the essence of each topic, which is then categorised into the Insight column.
2. Prototype
After distilling the insights, we had a clear picture of the macro problems within the Design system. With the higher-level issues, it enabled the ability to start mapping to existing backlog items and fleshing out the order of the backlog and roadmap items.
3. Agile roadmap
With a clear priority of the backlog and order of the roadmap items, it was now time to align the defined milestones into an OKR format. Our stakeholders and interested parties will know at a glance, what the objective is, and how we're tracking to complete the roadmap item(s).
Example OKR
The main objective is to automate the Product Design UIKit to be a 1:1 match of what is available in the Feelix Design System.
Key Result(s)
- 100% of components available in the chosen design tool
- The Design feedback of the provided solution is overwhelmingly positive (> 60%) that outweighs the negative feedback.
- Time spent by Visual Design updating the UI Kit is 0hrs.
- A Developer can 100% correctly implement a Feelix designed experience without design involvement.
- The Developer feedback of the provided solution is overwhelmingly positive (> 60%) that outweighs the negative feedback.
Improve relationships between Design & Development
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.
Build vs Buy a Design System?
Our stakeholders asked the question whether we should continue to use our current system that was born from a labour of love, or start fresh with a system off the shelf.
We kicked off a series of tasks to understand if building or buying was a viable option for MYOB and our customers. In the end, the Feelix Design System had many positives that determined the continued investment, which we have been iterating on since 2018.
Feelix is much more mature and a better experience for our customers in 2019. We continue to improve this system in our day-to-day work, which will enable MYOB to deliver quality experiences to our customers faster.
Kendo overview
- 0% open-source components
- Branding 0% completed
- 10 React components
- 31 jQuery components
- 41 total components
Feelix overview
- 24% open-source components
- Branding 100% completed
- 44 React components
- 0 jQuery components
- 44 total components
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
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.
MYOB contribution model
MYOB adopted a contribution model where teams interested in creating or enhancing Feelix components can do so directly within their applications or in a hosted repository. This approach allows teams to deliver value to end-customers without relying on another team.
Components: Creating New
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.
Components: Enhancing Existing
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: 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.
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.
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.
Story telling
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
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.divThe 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>
);
};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 200Handling 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.
