Maintaining Design Health: the support surrounding Design Systems
“Keep New Zealand Beautiful” was a campaign which kicked off in the 90s alongside the tagline to “Be a tidy Kiwi”. A pertinent reminder that what we have in nature is stunning and worth maintaining, and we should do what we can to keep it that way.
We want to maintain what we have at Trade Me as well: we’re in the phase where we have a new platform to build on, a new design system it’s based on, and the luxury of an essential blank slate as we bring features to the new-look Trade Me. This means that things can only go downhill when it comes to cohesion of design, maintainability of code, and knowledge management. 😁
20 years of design and code evolution has slowed our ability to move quickly on the current trademe.co.nz: button styles and hierarchy vary across pages and flows so it’s difficult to know which pattern to follow on new features, and we’re hesitant to improve or modify existing code for fear of upsetting the delicate fabric of the site.
Our squads are considering code and design health now, so that in 20 years’ time we have an evolved, stable, easily maintainable and quick-to-build-on application. So how do we ensure that we keep the new-look Trade Me’s current levels of quality over time?
Design Systems
Tangram (Trade Me’s Design System) is the key to ensuring maintainable and beautiful design and code: right now to keep cohesion across the many areas of Trade Me, and in the future by ensuring improvements to tech and design patterns are easily implemented site-wide.
Tangram is very flexible as far as design systems go; giving much more power and trust to the designers and developers than other design systems.
In Tangram, components are tightly coupled to the developer experience: a component is a component in both an abstract concept as well as implementation.
In our design arsenal we have a fantastic Sketch App toolkit, which gives us the Sketch equivalents of the components including their built in spacing, helpers for spacing (Tangram is based on an 8px unit system), and many other common elements as easy-to-drop-in symbols.
Where a component is used, and how it’s used, is not in the language of our current design system at this time: we need other methods of informing leading practice behaviour of this component, or what considerations there are when coupling pagination with other components.
When designing around ad units, we drew on existing patterns: space around it and other areas of the site need to be taken into account, as well as impact on our member when their primary focus is to paginate through results.
These are things which our design system intentionally does not dictate.
While the Design System is the hub of the wheel, it needs some well structured spokes to support it and keep us rolling with design health as well as feed into it to evolve the system.
Over the past year, we’ve been relying on Design Principles, processes for iterating on Design Patterns, documented UX Research, and experimenting with tighter cross-discipline squad collaboration and a design history rationale to help support building trademe.nz with Tangram.
Design Principles
Let’s start at the top. How do design principles help support a product beyond the system?
There are two key areas for design principles to relate to product design health:
- We assume that that the design system is built on the same principles, with strong ties to the brand it’s conveying.
- They’re flexible: not prescriptive in terms of solutions, but guiding in their voice and go beyond a ‘best practice design’ (usable, helpful, etc.). There’s a great article on this here from the head of design at Bulb.
Adhering to our design principles means that our designs will not get stale. For the foreseeable future anything that gets added to Trade Me, or Tangram, will be aligned by ensuring that products across the new-look Trade Me and its design system follow these principles.
New additions will be considered as a whole (being Human centred), clear and considered (Effortless), further our business by being Successful and embody what it is to be Trade Me (On brand).
Design principles are a great sanity check for any design: does my current solution fit the high level points we (as designers at an organisation) have agreed to adhere to?
Great! The implementation of a given feature or enhancement will have a lasting impact even if it doesn’t get touched again for years, because any future enhancements also adhere to the principles, it will fit well in the wider context of a journey through Trade Me. No matter the specific implementation.
Design Patterns
Rather recently (we’re still at step 6 below), we’ve been looking in depth at loading and progress indication states.
Our central design team was asked about the best practice for showing a loading state for file uploads: Trade Me Jobs (one of our business units) needed to ensure users completed the upload of their CV before continuing.
Without showing a loading state, it would be possible to submit the form without an attachment, and frustrating to not know whether anything is happening.
This is a rough outline of the process we’re following:
- Background research: based on our tech stack, guidance on ‘ghost’ states suggests what’s being loaded (e.g. Facebook, Slack).
- Where else do we have this need, or an existing pattern?
- Uploading pattern: using a shaded placeholder for the photo that’s being uploaded
- Another business unit, Property, needs to show progress through a slider of cards which auto-advance
- Existing usage of ghost states throughout the new-look Trade Me - Share the problem with all our web designers, where we find more use cases and interested designers
- Form a group (designers and UI-developers who have been involved so far)
- Share current state and future problems in the group
- Discuss similarities, potential patterns
- Apply and test
- Write guidance
- Include in our Design System site
- Iterate
To support design health going forward, what’s really important are steps 8 and 9.
Design patterns such as loading states can partially be solved by inclusion as design system components (in the form of ghost colour tokens or animations), but the usage of those colours and animations are tightly coupled to the resulting loaded state of the application and are best defined as reusable, recognisable patterns to be implemented application-side.
The best place to communicate these patterns is where consumers from all disciplines (be it design, product or engineering) will look for the initial building blocks: in the design system itself alongside the design system components and tokens.
UX Research documentation
We’re very lucky to have a UX Research team at Trade Me who pull together pertinent research across our various business areas: for immediate need testing and validation as well as long-term explorative research.
But how can we effectively surface this information at the right time?
- Links to our internal wiki written by the UX Research team in our Design System: As a designer or any other squad member, looking up a component will give me the relevant background to why this component is the way it is, and how its usage has been tracked throughout its product usage.
- Abstract history. We’re using Abstract to manage our Sketch files across all of design for the new-look Trade Me, which gives us the ability to add pertinent historical data alongside designs. When branching off an existing design, relevant UX research is linked right there in the project so that we, as designers, are able to see how the combination of components in a user flow have been tested, researched and validated so far. This way, we’re not re-testing past mistakes unless we make the informed decision to do so.
DHR (Design History Rationale)
Which leads into the entire history of a particular piece of work. Where would one go to discover why and how previous decisions have been made?
In an ideal world, I’m a designer who cares about why and not what.
In the above example, I’ve merged a few cases into the Master branch of a design project using Abstract. It clearly states what I’ve merged in but not why it was done in the first place, and how this has improved the project.
So I propose more explanation as to what our design commits hope to achieve: a purpose with user implications as well as the concrete changes made to a file or project:
In the same way in which design principles guide us to make good decisions about the quality of our designs, so do the past decisions and rationale behind changes and improvements to projects.
Our projects are based on user flows at Trade Me: many pages brought together by a user need. By using descriptive commit messages which include purpose means that their history is easily understood by our futures selves as well as other designers working on these flows.
Squad collab
How about saying ‘no’ to designers? It’s a controversial thing to say as a designer, but it’s healthy to be challenged on the implications we have on our squads.
As much as we discuss our work and decisions amongst design teams, so too should squad members ask why their code is harder to implement, or their test automations no longer easy to run because we’re not using standard components or an already established, easily-understood pattern.
Much like our design principles are a great sanity check, so too are our squad members: if the chosen deviation from a pattern is because of user research, an intentional change to call attention to a critical message, or perhaps even an application-implemented solution to a future design system addition, then great! These are good answers and there are many other exceptions to following a design system.
If we’re not able to answer adequately, then why are we wasting development time, reducing code maintainability, and deviating from patterns we’ve educated our users on?
This sanity check with all other disciplines we work with is invaluable to ensure we have a well-rounded, long-term product for the next 20 years.
Keep (New Zealand’s) Trade Me Beautiful
We have tools to bring to the forefront the areas which our design system currently doesn’t house: either by tapping into the day-to-day for our designers (like including sensible commit messages to Abstract) or by adding to the breadth and depth of Tangram (by adding UX research and more design patterns to it).
We’re in a formative period of our design system and the new-look Trade Me: it’s easy now because everything is fresh and untainted but that won’t last long. Very quickly we’ll have deviations from patterns, many non-Tangram elements creeping in, and more.
We’re planning to minimise this. The supporting structures around our design system hub (which will be fed back into) will go far to keep Trade Me beautiful: not just visually and consistently for our users, but for the benefit of our future selves and others who continue to build out our product.
