Back to Work
Product Design
UX research
Prototyping
User testing
Product Design
UX Research
Prototyping
User Testing
New Data Sources Page
Connecting multiple data sources for seamless integration
Timeline
6 months (2024)
Role
Product Designer
Contribution
Full product design role, from the requirement to QA testing and iterative changes after implementation
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.
Definition & Ideation
Wireframing
The project had multiple ideation phases that needed to be validated with stakeholders and engineers, as well as being validated by users through testing. The project had multiple ideation phases that needed to be validated with stakeholders and engineers, as well as being validated by users through testing.
First and foremost, dividing the wireframes following the different defined user stories.
The wireframes described the potential solutions for the Overview page, as well as different setup scenarios for all the different types of integrations or data ingestion
User research and testing
After the initial wireframes and flows were finished, it was important to validate them with our users before starting the Design of the high fidelity screens. We interviewed power users (heavy users of the integrations features that had feedback from their use), as well as less experienced Taxdoo users that did not have any connections setup yet. Both these interviews were not moderated and consisted of showing the users lo-fi clickable prototyes from the wireframes. We wanted to get clear directions and understanding of users pain-points before continuing with the High-Fidelity design phase.
The prototype required for the full interactive setup, as well as relevant contextual information (such as tooltips) as the setup is very complex and information heavy.
The RUT (Rapid User Testing) were performed by our researcher and with the reported specific issues that were unaccounted for and unforeseen. Users instinctively chose to start the setup in a way that complicated the setup. This demanded some conceptual reworks.
Some new user flows were made to improve on the specific pain point discovered.With some discussions with engineering and different stakeholders, my solution to automate the ERP data exclusion to make an already complex setup leaner, avoiding the critical issues the user could unwittingly cause, while keeping options and settings to allow user to cater to their exact setup need, was accepted.
Validation & Testing
Ideation validation - Usability testing
To move with to the final phase before the designs were finalised, we decided to make another user test to check the idea of the overview page, to check that the users understand and can easily navigate the list of integration cards, as well as the filter bar.The prototype for this test was extremely challenging technically. The prototype was to be done in Figma but really pushed the limit of what is technically possible within Figma. For this prototype, I needed multiple advanced techniques to work together smoothly to create a smooth and realistic product experience to test with the users. I made heavy use of variables and conditionals to allow for the persistent state of connected cards, as well as for accurate success toasts.
The prototype also needed a fully functional filter bar to test how intuitive it would be for the users.
UI design phase
After this last round of user testing and collecting feedback internally as well from internal stakeholders like customer support the final designs were finalised with a great attention to proper implementation of the design system components.
The final page is designed in 2 main sections:
an Integrations section containing all of our in-house integrations. The section also includes multiple features that help future-proof the eco-system, for example adding a pagination and a filtering system allows us to ramp up the number of integrations we can develop in the future and simply add the respective cards into the integration list in this section. Using the card approach also allows the user to understand the status of their systems at a glance and to focus on what is important to them without being distracted by other systems that are not important for them.
a Connections via API token section that consolidates multiple pages together, centralising the connections that use the API token together. Thus, the third party documentation (that require use of the token) are now placed next to the token so that users can access all the information they need about the connection in the same page. The token itself also received multiple feature improvement, like a button to rotate the token and some security best practices.
Upon clicking on a card, the user accesses the integration’s detail page. The detail pages were designed to support a wide range of options, as well as the connection of multiple accounts.With so many integrations with very different connection options and import filters, the detail pages need to support more complex forms, as well as multiple connected account for a system, that can be differentiated with accordion items.
Implementation
Implementation & Scope iteration
After some strategical changes, the scope of the release was divided in multiple release iterations, in order to free up some development work for some other priorities that came up.
After some discussions with the CPO, CTO, Engineering Manager and the Product Manager, we discussed and divided the back-end heavy features by priority for the first release. This allowed us to plan engineering efforts while being flexible to react to external changes in priorities and resources.
After the rescoping and some slight desings adjustments to reflect this iteration scoping, the development phase started, with me and the PM heavily involved in testing the features and making sure the new pages are an accurate implementation of the designs.
