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.
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.
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:
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:
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.
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.
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.
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.
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.
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
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.
🌐 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
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.
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 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.
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:
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.
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.
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
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.
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 .
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.
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 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.
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.
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.
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:
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:
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.
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.
Test with the market
Harvest the successful components
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.
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.
Test with the market
Harvest the successful enhancement
Test with the market
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.
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.
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.
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.
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.
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.
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.
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.
Depending on that governance model, it may impact the ability for your Product Delivery Team to deliver on their forecasted timeline as expected.
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.
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.
Please remember, Design System changes can be made outside of a Product Delivery release, as the Design System is product agnostic.
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.
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.
In this design sprint, the cross-collaborative group looked to solve known and unknown problems within the Accounting rural space.
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.
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.
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.
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.
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.
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.
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.
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.
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.
When I tweak my website or update some content, I will do the following to push the changes live.
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.
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 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.
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)",
}
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" /> `;
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>
);
};
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.
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>)}
Below is an example of how styled-components uses the condition.
// If this condition, render true and then false.
twoColumns ? "1fr 1fr" : ""
Separating data from the application and making it available to import
export const codeReminders = [ ... ];
import { codeReminders } from "./data";
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
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.
Handle state with the constructor method.
Handle state with Hooks.