Trustpilot
Rebranding Trustpilot's digital products using our new design system
Project Duration
10 months
Shipping Date
October 2022
Role
Product Designer, Project Management
Brief
Final design and outcome
The Trustpilot rebranding initiative was widely considered a success. Our product team's experience and collaborative approach allowed us to successfully deliver a refreshed suite of web products that enhanced user experience, and reinforced Trustpilot's new brand identity. This project highlighted our ability to work as a team to solve a larger challenge.
For me personally it was a growth opportunity. Working with a team who were receptive to a systematic approach to design, and leaders who encouraged and trusted in my abilities, I was able to produce some of my best work to smoothly support a critical business initiative in a fixed time.
Systems in action - our updated homepage, using design system tokens and components
In our final week, ahead of deadline, the engineers merged changes from the development branch into our main design system, and once deployed to our test environment, everyone spent a little more time to ensure the quality of the work.
For the most part, as a result of care and attention up until that point, the transition went incredibly smoothly.
You can view the various applications live: B2C, B2B (requires account), Business Marketing, iOS App.
Measuring my contributions
Some key stats, taken from the Constellation (design system) Figma library, towards the end of the project:
536 tokens (colours, typographic, shapes, elevation etc.) - managed by Tokens Studio
Including 10 interchangeable colour themes
70 published components
Used by 18 different teams
6.5k average inserts per week
These numbers combined with feedback from our teammates, and results from our rebranding exercise, make me feel very positive when reflecting on the work I was able to produce during my time at Trustpilot.
Regrets
Whilst the majority of teams were collaborative, and both contributed and gained from the design system, the business marketing team took great liberties with their approach.
Whilst it’s fair to say their business goals are perhaps a little different, I was able to work closely with various other teams to support their requirements. There was much greater resistance from that team specifically, which could possibly be from a leadership angle (CPO vs CMO), and whilst the team’s designer made some efforts to work with us, there is a noticeable difference in approach which I feel dilutes the consistency we strived for.
Furthermore components in this project are not managed by a system, so miss out on the benefits of shared maintenance, testing (including accessibility) and future updates.
The background
When I joined the design system team, my main responsibility was to unify various asset libraries to help create a single design system. Multiple B2B, B2C and some marketing asset libraries featured inconsistencies which reduced the overall quality and cohesion of our products and services.
Soon after joining, we were informed that our marketing department would adopt new branding, and had partnered with contemporary design agency, Barkas.
Time for a change
I believe the driving reason for this bold rebrand was to better support Trustpilot’s first steps into the US market. Whilst their previous branding by Venturethree was robust and reliable, it was also a little conservative, and perhaps lacking the impact which would make it memorable and more competitive outside of Europe.
The fairly corporate looking Trustpilot homepage as of December 2021
The challenge
Whilst Barkas delivered a wonderful set of guidelines and illustrations for brand and marketing, these weren’t usable for product and UI.
I was able to address some concerns ahead of marketing sign-off, regarding colour accessibility for web marketing, but otherwise it would be our responsibility.
New colours and typography gave us plenty of choice, but without the correct application in product, it was difficult to imagine how they would be used.
Trusting the process
The product team were given 6 months to define and apply our new branding to the entirety of our B2B and B2C products. It was decided that this would become the responsibility of the design system team, as a central contributor to all feature teams, to define and coordinate the implementation.
During this time, development of new features was ongoing in parallel. As such the process had to cause as little disruption as possible.
The company had also recently switched to using Figma from Sketch, and as such had limited shared resources in terms of design visualisation and prototyping.
A lot was happening at once, so we needed a plan.
Evaluation through component auditing
I worked alongside the team’s senior engineer and various feature teams to unify various patterns, without detriment to existing implementation.
The resulting work produced a comprehensive audit of our components and dependencies.
Understanding dependencies through elements, components, component groups and features
Whilst some of this was a visual exercise, a lot involved creating spreadsheets with names, statuses, and various other notes.
As well as components, I detailed every token (colour, type, spacing and more) from the design side, and compared values with our engineer from our various code repos.
We were able to determine inconsistencies between projects, and importantly between design and code, so we worked to align them.
Using sprints, we planned the initial scope of work, based on priority and dependency
Whilst I was creating the library of UI components in Figma, our engineer (with support from volunteering feature team engineers) was simultaneously consolidating inconsistencies by using a single component from our new library, and adding library support where previously there was none.
This was vital to the timeline of our project, as we needed to be able to adapt and deploy to support our new guidelines simultaneously ahead of our deadline. Only through complete coverage would this be possible.
We would have weekly check-ins with the wider design team to update them, answer questions and address any concerns.
Discussions with stakeholders
During this process, we regularly communicated our progress, through our Slack channel and in design meetings.
We intentionally sought out feedback from the design team, about the shortcomings of our pattern libraries, and how we could improve on them with a unified design system.
To review the adoption and effectiveness of our design system over time, I collaborated with our user research department to create a System Usability Scale (SUS). We would later send this to the production team members every quarter, and compare the outcomes over time. Ideally we were looking for an upward trend in usability and user satisfaction.
Though I left before we created a means to review this data easily, anecdotally, I saw improvements over 18 months, and received some very kind feedback about how our team were supporting various individual's efforts and reducing repetitive smaller tasks. Nice!
Atomic methodology
We followed the atomic design methodology by Brad Frost. Starting at the smallest scale, and using these to build bigger more complicated UI.
Rather than using the Atomic labelling (most of us weren't from a physics background), we used plain wording instead: tokens, elements, components, component groups, features, layouts. Despite this, we created a system of dependency, where everything was reused.
We tried to create as little ambiguity as possible, and use terms that everyone on the product team could understand.
How many shades of grey?
We were also able to review naming structure as part of our consultations - to make styling and property naming choices much easier in Figma.
One of the valid concerns raised, was that designers wouldn’t know which of the 10+ shades of grey to use for which type of text. Why do we even have 10 shades of grey?
Knowing which colour to use when there are names like “grey-10”, “grey-20” etc. is maddening. It puts too much of the responsibility on the designer to remember, when they should be using their energy to solve real problems.
Sensible naming and systems thinking
I reviewed the implementation of colours with our feature team product designers, and we determined that there was a lot of inconsistency as a result of confusion.
Base value (eg. hex code)
Token
Semantic Alias
Application of semantic alias in UI
Our previous set up didn’t grow beyond the second step, as such designers and engineers had to remember very unspecific colour names (eg. grey-10).
I introduced the semantic aliases, partly as a means to create descriptive names. It also means that the this value can later be changed to a different token value, without disrupting other implementations.
For example, Foreground/Primary might use the same token as Border/Primary - but if we decide our borders should have a lower contrast than text, this can be changed without affecting the base value.
With more resources, I would consider extending this further with Component token aliases, which would define the token values in the styles at the component level. This offers further redundancy and flexibility, however we determined that given the scope of this work, it would not be an immediate requirement.
Sizing with fewer surprises
Another place where we unified naming, was with size properties. Using s, m, l with a sensible scale, we could unify expectations across various components and type properties.
To the best of my abilities, and through consultation with various teams, I tried to make sure that medium was considered default, and most common size for the majority of our UI elements (eg. typographic scale, input fields, buttons etc.) and that these aligned to one another.
With typography specifically, rather than associating font sizes with specific heading names (h1, h2 etc.), I wanted to separate the sizing from markup tags. Naturally with semantic markup, it’s not always the case that H1 is the largest text on the page, as such we should use size names that reflect the style and handle Search Engine Optimisation (SEO) separately.
We split type into 3 categories: display, heading and body - each with their own scale.
Using a sensible scale for typography meant that we could extend higher or lower also. Our design team found this much simpler to use in their work, and engineers were happy to define the heading tags additionally, as required.
Communication
Ahead of every pending design update, I created a brief announcement (a heads-up), in our Slack channel, with an estimated publish time. This normally wouldn't surprise most readers, as the design process was also communicated transparently in weekly meetings. Following the changes, a second announcement would be made with a detailed change list.
This was useful for adoption, and fostered trust, but also offered a direct route for feedback from stakeholders. It created accountability and visibility, which could be also reviewed in future.
Soon we had a library of various UI assets, all of which were being used in design exploration.
Encouraging designers to use our library components, we were able to publish updates directly to various teams’ explorations. Naturally anything which could be disruptive was communicated and scheduled ahead of time using Slack.
Team explorations
Through workshops and explorations with stakeholders, we were able to determine the direction of new branding, and through careful iteration, we could push this into various designs.
We tried to balance our four new primary colours using theming support, but determined we needed rules when to use which.
We were able to refine and adapt over a 2 month exploration process, during which time feature teams also made improvements to search, filtering, and general layout using our new design system.
Changes, once approved, were communicated with engineers and styles were quickly updated, mostly with minor amendments to our design tokens.
Because we wanted to push these changes at once, work was completed in a separate development branch. We could build and test these changes long before they were scheduled for a production release. All feature teams did their part to review and report on our work in progress.
Opportunity from uncertainty
2 months into my employment (before rebranding), the product manager for the design systems team announced he would be leaving. Shortly after that, the team's other designer also quit - which left me, one senior engineer, and a principle engineer who joined the team largely in an advisory capacity.
Until his point, our manager had been the go between for our small team and the wider business. He was able to generate excitement and support from senior leaders within the company, and was generally a good person to work with.
At this time, I was still learning about our products and processes, so these changes were fairly disruptive.
But it also presented opportunity for my role to grow beyond its original responsibilities:
I became directly involved in the hiring process, for an additional designer on my team, but later for feature team designers and engineers also
As a result of working with all product teams, I was able to better understand the challenges teams faced and then communicate the value we presented to senior management
I assisted with Figma training and mentoring for those less confident in its features
I worked directly with marketing and our external design agency to better understand our new brand guidelines as they developed
These and other opportunities presented themselves, in part from the autonomy I had, and from the desire to better support our product team.
Personal highlights
Birth of an icon (library)
After deliberation, I took it upon myself to review and expand our icon library, based on the guidelines and samples presented by the design agency.
Time was still a factor, and the team needed assets to proceed with their work.
I personally curated a collection of over 200 functional icons. These replaced various icons across all of our projects, and in some cases consolidating variants which represented the same function.
With the originals being lost, I also recreated our 36 categories icons, to align them with our guidelines. It meant we could now also adjust the line thickness.
This felt like a personal achievement, firstly for removing that uncertainty, but also in creating graphical assets which were well received by the team.
Reducing Figma costs by thousands ($)
When my manager left, I took over Figma admin and billing responsibilities. This represented a great deal of trust in my capabilities, as it was the first time I had been in this situation, managing roughly 90 users at the time.
So I was surprised when I was alerted to the first annual invoice.
With every user billed for the year in advance, costs were high. I reviewed each of the users, many whose names I didn't recognise. Though I asked various team leaders and even with HR, there seemed to be little consensus in how to manage users.
Figma admin offers insight into when a user last accessed the application. I decided this would be used to prune inactive users, with some not using the software for more than 9 months. Were they even still with the company?
I filtered by users who had not used the application in over 3 months, and removed their editing access. This immediately reduced the number of "active" users a significant amount, lowering our annual operational costs by roughly $24,000.
I exported the email addresses of those who had access removed, and contacted them to explain the situation, and reassure them their files were still accessible. Should they need access again, it could be granted.
Finally I documented this process, partly to reduce frustration and confusion, but also in the hope that costs can continue to be kept down.
Appreciation rounds
A practice I hadn't experienced in the past, appreciation rounds were held occasionally by one of my colleagues during design catch-ups.
Not only receiving, but having a process to thank others for their contributions and support felt very gratifying.
Below are some of the kind words from my co-workers.
I will carry this positive feedback with me as a reminder that I was able to improve the working lives of my colleagues during my time at Trustpilot.
It's something I'll continue to do wherever I end up next.
