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
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.
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
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.
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
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.
Key to the smooth progression - communication
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
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
Testing the products' look with the new buttons was not comprehensive enough
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
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.