When I first joined Tread, there were 2 thoughts running through my mind as I acclimated myself. The first was how grateful I felt that someone had put in the work to build a design system; the second was how none of the design files followed the design system and practices.
As the weeks rolled by, I started to understand why none of the files followed the structures and systems set in place. Whenever I tried to implement the system I often found my workflows heavily impeded or worsened, often having to rebuild minor components or fix odd colouring issues. The last thing I wanted was to have design be the major bottleneck in the product pipeline or to have our quality of work drop, so I took it upon myself to investigate the issues with the design structures and see how I could remedy them. These were the main issues that I felt we could internally improve and change.
One of the fundamentals of good UX/UI Design is proper layering and component building. A well built component should be flexible enough to handle the inherent variance within design, while being static enough to be consistent with the overall branding. The components built in the design system was anything but.
Layering was often non-existent, meaning that it was easy to move an item out of position. Nothing was fixed positionally or in auto-layout, so spacing and padding was almost always incorrect, and everything was grouped instead of framed, meaning that resizing the component would stretch and elongate everything inside of it.
Figure showing the poor layering system for a modal component
While the style guide did include a proper typography hierarchy, it was scaled in a way that was confusing and lacked proper increments. Rather than scaling each font size with a root value as the base unit, the fonts were seemingly sized at random and often times would be nearly identical to one another. This meant that the wrong font size would often be used when building a design, resulting in inconsistent and oddly spaced features.
Figure showing the odd size scaling for the typography system
The next major issue was the naming conventions used on the style guide and components. Names of colours and fonts would often just be named numerically, meaning that there was no context provided on when to use the font and colours provided in the design system. As many of the fonts and colours were very similar they’d often be used interchangeably, meaning that components would often have conflicting parts and styling, making it very difficult to maintain consistency across different design files.
Figure showing the vague naming structures for the colour system
Another major problem I found was the unusually high number of repetitive assets, meaning assets or components that fulfil the same role but are styled differently. This would often result in a huge amount of variance between features and pages, weakening the overall usability and branding of the Tread platform.
Figure showing 3 different types of data tables used within the tread platform
Beyond the UI library and style guide, I also noticed some gaps within the practices used within the product and design teams to build and handoff design files. Flows would often be mislabelled, and forgotten, engineers were given free reign to poke around and reference iterative work that wasn’t clearly labelled or complete, and the status of a design file was always up in limbo as changes would be made on important pieces on the fly.
Lastly, I found the page structures within figma files to be far too complicated and excessive. There would often be multiple features and subpages placed within a single design file, and often times its unclear what parts are completed and meant for handoff, additionally, archives would often lack dates or labels making accidentally designing on obsolete designs a common occurrence. These problems not only heavily slowed down designers as scope creep would build quickly, but also made it extremely confusing for engineers and PMs to find the correct file to reference.
Figure showing the different page structures in figma across design files
The first step to making a functional design system was making sure everything was where it needed to be. Previously, design files were split based on what part of the design process they were in, ie: design, research, ideation. However, because the design process always ended with design, this meant that the bulk of the core files always ended up in the design folder making it bloated and difficult to navigate.
I started by splitting the design files into folders corresponding with the 3 product teams within Tread, allowing the lead designer for each team to better track their ongoing features. I then additionally split the design files into ongoing and completed folders; this bypassed the problem where one folder held the bulk of figma files and made it clear to designers and PMs what features were actively being built. I then consolidated all research artefacts and design system files into their respective folders, making it much easier for designers to identify and find any reference documentation without cluttering their feature design files.
Figure showing the basic figma organisation structure
The next step in my process was to refine our design file page structure. As it stood, the page structure was extremely inconsistent and often times excessive, making it to easy for designers to mistakenly work on the wrong version of a design.
Figure showing the issues with poor page structures, showing that engineers were mistakenly referencing the wrong page
After consulting the design team and exploring our ideal work processes, I ended up simplifying and standardising the page structure into the core steps of our design process. This meant that rather than having an open page where ideation and high fidelity designs share the same space, they would now be clearly separated. This drastically reduced the chance of someone accidentally working on the wrong version of a feature, and gave the designers a clearer sense of progression in their design work. Once the design is nailed down and complete, the handoff page is then used as the final version that engineers and PMs will refer to.
Figure showing the simplified standardised page structure and what each page holds
One major problem the design team faced was engineers and PMs misunderstanding a flow or referencing an incorrect design. This was due in large part to a lack of consistent handoff structures and poor communication. In the past, once ready for handoff, the designers would group all the respective frames and write a sentence explaining the intended behaviour. This was not only very inconsistent as the specificity of the description was dependent on the designer, but was also very confusing for engineers and it was unclear what item on the page was handoff ready.
Figure showing the similarity between 2 design sections on the same page, where one is incorrect and the other was handed off
To keep the handoff file as final and clean as possible, I made an effort to reduce the page content for handoff pages down to 3 key components, the core screens for engineers to inspect, core workflows with specified impact points, and any specification or logic that was not immediately apparent on the designs.
Figures showing the new handoff sections, the top one highlights the core screens and the bottom highlights the flow and impact points
One of the key flaws of the old UI Library is now expansive it is, one a single exportable library, we’d find buttons, colours, fonts, modals, filters, tables, and calendars. This makes it difficult for designers to find an object, and it also makes it difficult to keep every component up to date when a change is made to a root component/style.
The first thing I did with our new UI library was rebuild the lowest level of components using our new style guide and systems. Once I had the foundational component pieces built I then became layering the components on top of one another to create a robust and consistent atomic library.
Simple diagram showing the basic atomic structure behind the new design system
The foundation of any robust design system is well defined design token structure. I wanted Tread to move away from naming objects at face value, and move towards a nomenclature system that was based on core functions and parent components. This allowed us to update styles without affecting other components that may share the same root value.
Diagrams showing the difference of how styles are named between the old design system and the new design system
This new implementation made our style guide much more purposeful and much more robust as now we had clear defined roles for each hex code which are independent from another object that might share the same value. The result was much more consistency within designs, the removal of repetitive styles, and a clearer understanding of a colour’s use.
Figure showing the number of colour styles found in a single component from the old design system vs the new design system
Arguably the most complete section of the old design system was its component library, it was large, inclusive, and generally quite versatile. The main issues with it was that it lacked variability, meaning that small variations to a parent component would result in its own separate component. This was largely just a technical issue which could be resolved via better variable building in figma components.
Diagrams showing the variability of the new design system button vs the old design system
The last and largest part of the new UI Library was to create an up to date template library that would serve as a reference point for all designers and PMs. This was important as I had noticed that even with the new and improved style guide and component library, designs of the same page would often vary between features. This was largely because designers would often build based on the most recent design build they used, and this was rarely the same as what was in production.
Figure showing how the same page differed between 3 separate design files
The solution was therefore to have a set of screens that match whatever in production and have that be the starting template for designers to pull from, and thus templates was created. The idea behind templates was that it would be a living document that would update every time a feature was successfully released, however it was very difficult to keep track of what products were being released and making sure production matched the handoff design files completely. Therefore, the workaround for this was implementing a rotating system where designers alternated every month to validate and check the validity of the templates.
The implementation of design structures was something that was rolled out over the span of months with several iterations and changes, but the final result was an organised and consistent folder and file structure that was easy for designers to use. It was substantially easier to track feature progress and the action of moving completed files into a separate folder not only gave the product team a clearer idea on what had been released but also added to a sense of pride and accomplishment.
The new simplified page structure bought some much needed consistency and clarity to the designers, making it a lot easier to keep track on which version of the file they’re working on is the final version and having a safe space to ideate and design features without fear of losing track of reference materials.
The new handoff standards also greatly improved communication between engineers and designers, as now engineers had concrete flows and impact points to reference when building the features, and designers didn’t need to continuously be ready to explain and hand hold engineers through basic placement and flow questions.
The new UI library had an immediate effect on the consistency of the designs, there was much less random variation between features and the products started to more accurately reflect the brand guidelines set out by the company. Design speeds were initially slow as designers took time to adjust to the new library and learning how to make the most of variable components and templates.
However, once designers acclimated to the new UI library, the design speed on features increased noticeably as designers spent less time on rebuilding components and more time on fleshing out new features and workflows. This had the side effect of making design work more focused on product work, resulting in stronger solutions and final designs compared to when we were using the old design system.
The implementations of the design tokens and the rotating template system greatly democratised the design system, allowing updates and changes to be made much more liberally without fear of affecting other components and pieces.
Change is hard, and sometimes we as designers lack the patience to shift our habits and structures especially when its been working for us up until now. But its important to take a step back, assess if we can improve ourselves and experiment to see if theres a better way to design and communicate. When I started on the new design system, I struggled with wanting to just change everything just because I felt it was needed, but I often caught myself overbuilding a feature or not communicating my ideas with the design team simply because I thought it was the most obvious solution. I've learnt to take a step back from time to time, reassess why structures are important and go back with renewed fervour.
Design systems are never complete, they are living documents that flex and change with time and people. Its important to remember that design systems are made to ease the burden of design, to allow designers to focus on details that are important to the user and not fuss over pixel perfection and component variability. There were several times where I felt defeated that my research and implementation of a system resulted in failure due to over-complication or just outright being badly thought out. I had to learn to tell myself that this was an ongoing project that has no deadline, and as long as I'm working towards the goal of making design easier for designers, then there is no such thing as a failed system.
