Back to Work
Product Design
UX research
Prototyping
User testing
Product Design
UX Research
Design System Improvements
Improving states of Design System components to respond to user feedback.
Timeline
1 sprint (2024)
Role
Product Designer
Contribution
To respond to user feedback, I reworked systematic solution for semantic and disabled states of the internal Design System
Introduction
For a product based on the evaluation of data for compliance and accounting reports, having strong data ingestion features is critical for the users.
As the Designer assigned to the Taxdoo Integrations team, I consolidated multiple features in one new Data Sources page. Close collaboration with Engineers, the Product Managers and the Regulatory analyst was the key to deliver to our users seamless data ingestion flows despite the complexity of all the different integration systems and technical limitations.
Challenge
For Taxdoo, the data "ingestion" meaning importing data from the user through different sources is fundamental to the product and the good setup and function of the product's integrations a core part of the user experience, that can cause a lot of painpoints and sometimes requires heavy involvement of Tech and Customer support.
The platforms' "Shop Connectors", "Payment Connectors" and "API" pages, were all in dire need of refactoring, all being built on an older php framework and causing issues both on the back-end and on the front-end. The pages had very poor usability, and used a tab system to let users select different connectors, limiting the company's plans to have an ever growing amount of connectors releasing consistently.
Duration
6 months
My Role
Product Designer
Contribution
Full product design role, from the requirement to QA testing and iterative changes after implementation.
Key Outcome Metrics
📉 65 %
Reduction in Data-Setup Support Tickets
🚀️ 73 %
Faster user onboarding and activation time
⌛ 12 mins
Average time for a new user to successfully setup a primary data source (down from 45 mins)
👩🏻💻️ 62.5 %
Reduction in front-end development time for new integrations.
Results
Created a consolidated self-service solution for users, reducing the manual efforts by our Customer Support during user onboarding by around 40% (estimated with onboarding list and average ticket time)
Giving user clear status visibility on their integration connections, solving one of the biggest user pain-points reported by Customer Support.
Refactored and consolidated pages together, bringing older php pages up to date with our React design system library greatly reducing the amount of effort needed to bring a new integration to the front-end by around 60% (estimated with front-end tickets estimations).
Future-proofed our data ingestion system, creating a front-end framework supporting the business goal of releasing more integrations much faster to our users.
The new pages offer the users all filters and options directly in the front-end, reducing the amount of integration related Support tickets. (This is hard to quantify as of now, support tickets relating to issues with integrations are between 15% and 20% of the total support tickets).
Discovery
The ingestion process is complex and composed of multiple potential flows. The most important one is the setup. The product is very "setup" heavy, as it is critical to setup all the data sources properly first for the good function of the product. There are also different levels of complexity and requirements for each different system integration, and all these cases and options need to be carefully considered to create a solution that lets the user setup any kind of configuration easily, while taking into account all those different setup complexities.
After the project requirements were defined by the PM, I started defining user flows for the different user stories. The ingestion process is complex and composed of multiple potential flows. The most important one is the setup. The product is very "setup" heavy, as it is critical to setup all the data sources properly first for the good function of the product. There are also different levels of complexity and requirements for each different system integration, and all these cases and options need to be carefully considered to create a solution that lets the user setup any kind of configuration easily, while taking into account all those different setup complexities.
Terminology clarification & Translations
In order to ensure clear collaboration during the project and clear communication with engineers and stakeholders, I mapped out the terms that were used to discuss the topic. A lot of terms were used interchangeably (integrations, connectors, API, systems, data source etc.) and causing confusion between stakeholders. This work also helped with the early copy work of this project by mapping what terminologies are better for what types of user personas and to decide what copy should make it to the front-end and to our users.
Disabled state update
After some user feedback about the styling of our disabled buttons, I designed and oversaw the implementation of a rework of the disabled states for our Design System.
Background
Users and Customer Support colleagues reported issues with disabled buttons, that it was too prominent and was confusing users.
The problem
The customer feedback was that the dark-grey colour for our disabled states was too prominent and easily confused user.
Indeed, our primary button, even disabled, was very visually strong and would distract, despite its disabled state, from other action (like secondary buttons) that the user could still perform. We want the user to focus on what they can do and what they can interact with in the UI, instead of calling their attention to what they cannot interact with. The secondary button also brought issues, with its grey outline not differentiated enough from its “active” state counterpart.
Having all those differently styled disabled states also didn’t contribute to a clear visual pattern for the user to get used to in our UI.
The goal
Create a clear, consistent and recognizable pattern for the disabled stateDefining an appropriate styling for the disabled state that clearly communicates its state without distracting the users from other actionsDesign a solution that can be systematically deployed for our Design System
Designing the systematic solution
After some initial experimentation and ideas, I settled on a simple yet effective solution. Using a light grey for component background color and a darker grey for texts, icons and interactive elements. This makes the components less visually prevalent, so that the user can focus on what they really need to perform on each page, as well as giving a globally consistent behaviour so that users can easily recognize disabled components throughout the product.
My solution was thoroughly tested for every single interactive component of the library, as well as for all relevant variants and possible use cases (e.g. checked and unchecked checkboxes etc.).
Delivery
Once the solution was devised, thoroughly tested and validated by the Design Lead, I created a visual card to inform all relevant stakeholders and to be shared in product and tech channels.
I also discussed the changes with the Engineering Manager responsible for the Design System so that the changes could be ticketed and picked up in the next sprint.
Conclusion
The final solution is simple yet perfect solution that works for all components of the company’s design system to provide a consistent visual language throughout the product as well as helping focus the users visually away from disabled components and achieve what they’re looking for in the product.
