robertsanta
Case studies
Button revamp
Purple product
Blue product
Green product
Role
Product Designer
Company
GoTo
Team composition
Product Designers
Software Engineers
Community Manager
Design System Manager
Director, Software Engineering
Tasks
Scoping
Ideation
Stakeholder management
Tokenization
Research
Project outline
Overhaul all button components in the design system to address existing problems and ensure future scalability.
Project origins & scope
Why it was the right time
Problems with the existing buttons
Aesthetics - too much contrast, no reinforced brand identities
Discoverability - some buttons looked too similar to plain text
Importance - unclear hierarchy, as the variant naming did not match the visual weight
Inconsistency - variants with the same name across different components looked different
The mobile component library effort
We had an ongoing priority to bring our component library to mobile. We quickly realized that we did not want to carry over the aforementioned issues to mobile, so we needed a solution that would serve us moving forward.
Scope
Create new visuals for our button components
Bring consistency to all component variants
Streamline the variant naming
Communicate all major milestones, and align with leadership teams
Release the new buttons in Figma, with the least amount of disruption to designers
Coordinate the release of the buttons in code, with the least amount of disruption to product engineering teams
Guiding principle
To ensure a successful transition, we would have to do it right, while putting the least amount of additional effort on other product teams.
Tokens, components, and communication
Systematic, scalable foundations
A significant part of the design phase was ensuring that the new solutions will not break the existing system - and products that are using it - while creating and adjusting system foundations in a way that they can be easily understood, scaled, and maintained in the future.
pre-existing,
robust system
token names that are descriptive and clear
utilizing existing primitives, following a set logic
Design critiques
Once we had the first version, we wanted to collect buy-in, and make sure all design use cases are covered - all members of the design organization were invited to give their feedback
Key insights
The general direction of the new visuals, and the variant naming structure, was liked by designers
Designers praised the consistency of different components, both in appearance and the added and deprecated variants
Concerns around some of the more neutral-looking buttons appearing as disabled
Colors seemed disconnected from each other, almost like they were not part of the same palette. This also resulted in unclear hierarchy in some cases
Technical improvements specific to how the component was built in Figma were welcomed
After analyzing the feedback and looking at our options to refine the buttons' colors, we decided to expand the scope and include color palette improvements as part of the project, following internal discussions.
The improved button structure
Purple product
Blue product
Green product
Key to the smooth progression - communication
"Let's make sure to carry these over to our future projects!"
We set up a recurring meeting with key team members to discuss updates
Every milestone was communicated in advance, multiple times
The project's high-level timeline was laid out for all stakeholders to see
Then, the goal post moved
As the new components were finalized, we realized as an organization, that switching from the old to the new buttons was not going to go as easily as planned.
Teams needed additional manual effort because of various product environments
this caused roadmap conflicts
Testing the products' look with the new buttons was not comprehensive enough
this caused unexpected design blocks
After mapping the real impact of the update, we moved forward
We iterated on the components and made sign-offs more explicit
We discovered how to lighten the load of the update process
We involved leadership in a more detailed manner
Takeaways
I learned the valuable lesson of validating hypotheses - even ones that seem to be universally accepted. Being more explicit about what exactly I want from a review and the impact of a change are also vital, especially for projects that affect multiple product teams.