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
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.
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
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 MacphersonGuidelines 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.
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.
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.
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?
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
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>
);
};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 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.
