I’m a UX/UI Designer with a front-end development background.
I'm a designer with 2 years of front-end development experience. I love transforming complex workflows into easy and productive experience. Currently, I'm working at a data analytics startup, designing for complex data and business needs.
I’m a UX/UI Designer with a front-end development background.
I’m a UX/UI Designer with a front-end development background.
I’m a UX/UI Designer with a front-end development background.
Stratifyd Taxonomy Editing Experience
The Stratifyd Platform is a machine learning powered Data Analytics platform. It helps businesses analyze, categorize, and visualize structured and unstructured data sets.
My Role - UI/UX Designer - research, design, prototyping, testing, css implementation
Project Duration - 1 Sprint (2 weeks)
Team Members - Product Manager, Front-end Engineers, Internal Product Owner, Internal Users
Impact
Collaborating with my Product Manger and Internal Product Owner, I designed the taxonomy preview feature, which greatly improved the taxonomy editing experience and helped our users to do their job more efficiently.
Who we design for
Majority of our users are customer experience(CX) professionals. They use our platform to uncover insights into how consumers, partners and employees view their products or services. Taxonomy is a tool that they use to help categorize their textual data into topics that they care about.
In order to understand how users modify their taxonomy rules, I interviewed internal product owners who frequently helps our customers build taxonomies. I learned that users often know what kind of keywords they would like to add or remove from the topic rules.
Taxonomy Rules Example
For example, for a topic like "account opening", a user might want to match all the customer review data that contains the word "account". But sometimes the word "account" was not spelled correctly in the data, so the user would add all the possible misspells to the topic rules, in order to improve the matching results.
Problems
Our users often modify the rules in each taxonomy topic to improve their data matching results, but they could not do it efficiently.
-
Time consuming and changes were permanent : When users edit taxonomy rules, they would have to save the changes, reprocess, and then wait for the taxonomy to run, which can take very long if it the data was huge.
-
It was hard to tell what has been improved: Users would have to go into a dashboard to look at the results in verbatim and essentially guess what changed as the result of what they have done in the taxonomy.
User journey map
So my Product Manager and I landed on 3 key requirements for this project:
-
Allowing users to see matching results immediately before saving
-
Providing an overview of how the matching results were improved by the changes
-
Providing data samples that reflect the changes in the taxonomy
Uncover an existing solution
As we were having a discussion about how to solve the problem as a team, one developer who originally designed and built the taxonomy editing feature, pointed out that there was already a solution in-place for the problem we trying to solve.
So with a little help from the developer, I found the feature and played around with it.
The solution does solve the majority of the problem, however, it was not utilized by our customers, because of the following issues:
The taxonomy debugging tool entry point - before
The taxonomy debugging tool matching results view - before
1. The entry point icon was not very intuitive: the entry point of this feature was a small button with a bug icon on the main menu bar. The feature was called "debug", which is not a term that our clients are familiar with.
2. Users did not know whether the overall coverage increased or decreased: The tool only shows the total number of records matched by the taxonomy, but it did not tell users whether their edits improved the overall matching results or not, and yet this is the most important functionality that users are looking for.
3. Users had to remember the key terms they would like to add or remove in the next edit: Since the matching results were displayed in a modal dialog, they cannot edit the taxonomy while looking at the matching result. So they would have to reopen the dialog every time they need to check the results, which can be annoying.
So the design goal became this - how to solve for the user pain points while utilizing our existing functionality?
User task flow
So based on the users' current taxonomy editing journey and the existing solution, I came up with the initial user task flow:
User task flow
Design explorations and iterations
After discussing the user task flow with the team, I started to create some low fidelity wireframes to help illustrate my ideas.
Challenge - Finding the right feedbacks
When this project started, the product team was a relative new team and did not really have a good design review process in place. We also didn't have users that we can reach out to test the design. This created some challenges on getting the right feedbacks for my designs.
Since the feature was originally designed by our lead front-end engineer, who was very familiar with the taxonomy experience and the original requirements for the feature, I worked with him to get feedbacks for a few iterations early on.
However, I soon realized that some of his feedbacks were not very aligned with users' goals and behaviors that I defined at the beginning. So I took the design to some of our internal users who could think from users' perspectives, including the product owner and a couple of product mangers who were familiar with building taxonomies for customers.
With their help, I was able to get back on track and improve my design in each iteration.
V1
V2
V3
Final wireframe
After creating the high fidelity prototype, I took the design to the team for a final review and approval.
HiFi design
Final design
Final Interactive Prototype
Outcome
We were able to ship the improvements to our customers, and it was very satisfying to see people actually use the feature that I designed. According to our customer success team, the improvements have significantly reduced the time that our customers spend on editing their taxonomy.
What can be improved
After launching the feature, I watched a few recordings of how people use the preview feature. I noticed that, before editing any taxonomy rules, some users would check a visualization, which showed them how many records were not captured by the taxonomy and see why they were not captured. Then they would open taxonomy and add keywords that were missing from the taxonomy rules.
This was a case that we didn't capture in the current design. I reported this observation to my product manager and the director of UX. So in the next iteration, we will add the number of records of unlabeled data and allow users to review the unlabeled data within the taxonomy editor.
What I learned
1. Always referring back to user goals and task flows if got lost.
In this project, user goals and task flows that were defined at the beginning of the project helped a lot for me to gain users' perspective and prioritize the feedbacks, especially when there was a lot of perspectives given within the team.
2. When the testing resources are limited, getting as much feedbacks as possible is very helpful.
Since we are a small company, we don't really have a user testing process in place with external users. In order to validate my design, I showed my design to different internal team members and internal power users. As a result, I was able to get valuable feedbacks and improve my design.
3. It's valuable to observe how users are actually using the product.
Asking users about how they use a specific feature can sometimes result in missing other use cases. The initial interview was too focused on one use case of the taxonomy editing, which is opening the taxonomy editor and start editing. By observing how users use taxonomy in a different context, I could generate better ideas for helping users to achieve their goals.