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:

1. We assume that that the design system is built on the same principles, with strong ties to the brand it’s conveying.
2. 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:

1. Background research: based on our tech stack, guidance on ‘ghost’ states suggests what’s being loaded (e.g. Facebook, Slack).
2. 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
3. Share the problem with all our web designers, where we find more use cases and interested designers
4. Form a group (designers and UI-developers who have been involved so far)
5. Share current state and future problems in the group
6. Discuss similarities, potential patterns
7. Apply and test
8. Write guidance
9. Include in our Design System site
10. 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?

1. 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.
2. 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.

Maintaining Design Health: the support surrounding Design Systems was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Trade Me does a lot. For millions of people in billions of ways.

Let’s look at how Trade Me’s internal structure works and how we bring our design teams together to best serve our members.

Our structure

Trade Me is split into 4 main business areas to serve their distinct challenges: Marketplace (new and used goods), Property, Jobs, and Motors. Supporting those 4, there’s also a wealth of underlying and supplementary business units and functional areas. This is not a new structure: TaMedia, Unilever and the BBC all divide themselves into core business areas to target the needs of their respectively unique users.

How we work

We work in an agile environment using scrum and kanban processes. Each business area has a number of squads working towards project outcomes to improve the lives of Trade Me’s members. Our design team is integrated in these squads, working tightly with Developers, Testers, Business Analysts, etc. This is what good design in agile looks like at Trade Me:

This deserves further writing, perhaps another post, but in short: Trade Me embeds design in every squad, aligning user needs with business goals and fostering better collaboration between product, design, dev, test and business analyst roles. This is an effective structure for the day to day process of agile within these business areas, but what about cross-project or cross-squad work? How do we ensure design cohesion throughout the organisation?

Our part in the process

Dave and I are in the Central Design team. We look after those aspects of Trade Me that apply to the entire business such as the homepage and ‘My Trade Me’ (the manage-the-things-I’m-selling-and-buying area). We also oversee brand, type, colour, and style consistency from a traditional design perspective. We’re fortunate to have a phenomenal living style guide in place to assist us in managing and implementing this consistency, and communicating it throughout the company (you’ll hear more about the evolution of Tangram in Part 3).

What matters is that our designers, our developers, our testers, our everybodys are spread throughout various areas of the business focused on improving pieces of Trade Me that make their areas great. They are the experts in these areas. But how can we effectively leverage this expertise to create one cohesive experience for Trade Me members? And what other things might we need to take into account? There are no end to tools, but one stood out in particular…

Seeing the whole and its parts

Kim Goodwin spoke about how to adapt design to various organisational sensibilities at Webstock 2017: how to assert yourself and best influence the matrix of organisational stature (pictured below) as a UX designer. Trade Me identified as a Clan; our central design team works best with the greater Trade Me, when heavily consulting on projects, bringing as many people together as possible, acknowledging input and in the end feeding back any and all design decisions made.

But there’s an ‘And’. Throughout Trade Me each business area, team, squad, and even project has its own unique subculture. In the same way that our business areas identify their core users with personas, this matrix is helpful in assessing the structure and sensibilities of a team or project before we begin the actual work. As central facilitators or proponents of a project, we can best approach design problems by figuring out where that project or team may fit in this matrix.

Treat your internal project teams like your users.

Identify their needs, and how they operate. How do they think? How can you best resonate with their goals and methods of getting good work done?

Once you’ve got those fundamentals in place, you can effectively work together to design a cohesive experience in a way that, in turn, best serves your users.

Design cohesion for varying team sensibilities was originally published in Trade Me Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.