The primary question we need to address when designing the TransEditor function is how to allow tax accountants to establish logic like a programmer without having to write code. Our previous user research found that users consider the existing design unclear. They struggle to see the hierarchy between parent and child TransEditors, and the 'and/or' relationship isn't clearly represented due to a flat visual style. This makes it difficult for them to preview and verify the logic they've set up. Like in coding, a minor error in logic can have a significant impact, so resolving this issue is a top priority for our users.
Old TransEditor Interface
I initially approached this problem with our users in mind. As they are not professional programmers, they may struggle with understanding plain text codes. Therefore, adding visual cues and simplifying the design could not only address the issue of presenting hierarchy but also enhance user experience overall. This is particularly relevant as we plan to redesign the feature, which will likely result in changes to the layout.
My first idea was inspired by visual programming tools used to teach children coding. The assumption was that if children could understand and learn from these tools, so could our users. Therefore, in my initial low-fidelity draft, I explored the concept of a tree view editor. However, as this would be a significant change requiring substantial effort - since it's a completely new approach - we agreed that we needed more comprehensive research to validate its user benefits before investing in it. Moreover, we must always adhere to the standards and consistency of corporate products. Consequently, we opted for a less innovative but safer design, which is an improvement on the current one. This way, users would not be disoriented by the change.
First visual programming idea
Idea of nodes editor
Back to the central issue, which is the presentation of hierarchy. TransEditor incorporates two main hierarchy concepts. The first is similar to the relationship between parent folders and items contained within. The system reads the parent TransEditor and then moves to the first child TransEditor under the parent, if any. However, as shown in the left image of the old design below, it's difficult to discern this parent-child relationship among TransEditors, which is a significant problem. To address this, I explored various UI patterns and ultimately recommended using simple lines as visual indicators, as shown in the right image below.
Old design of TransEditor list
New design of TransEditor list with decorative lines
Another hierarchy concept related to condition logic, which is very common in programming. If the desired data has to meet two or more conditions, 'and' is used to link these conditions. However, if the data only needs to meet any one of the conditions, 'or' is used. In the old design shown on the left, there's little difference between the 'and' and 'or' relationships, as they're at the same level. Therefore, my design goal was to distinguish between the two clearly for users, allowing them to identify each type at a glance to save time and reduce errors.
First, I searched for various references online and decided on a concept that aligned with the TransEditor level hierarchy. This concept involved a group and its items. A relationship chip links all conditions in the same group, so all conditions share the same 'and' or 'or' relationship. Users can easily switch between these two relationships by clicking on the chip. They don't need to think in reverse and consider what adding a condition under another implies anymore. Whenever the relationship changes, indentation is applied automatically. Users can also intuitively drag and drop to move the conditions and adjust the groupings. I presented this to all stakeholders, including product and technical team representatives. They liked the idea and decided to proceed, which was encouraging. I felt confident about this new design and looked forward to its potential benefits for users. At this point, we were unaware that we had made a significant mistake.
Old design with no visual clue except for numbering
New design of conditions with decorative lines and indentation
We proceeded with the design and passed it onto the technical team for development. Initially, everything went smoothly until they began implementing the new condition relationship design. The technical team found that this design didn't fit with the existing backend logic. Instead of rebuilding the logic—which would require more effort than initially estimated—they requested an adjustment to the design.
Meanwhile, an opportunity arose for our internal users, the Professional Services team who support users in setting up the platform including TransEditor, to review the upcoming enhancement. We seized this opportunity to gather their feedback. During the call, we received many positive responses. They appreciated the new visual design for the hierarchy presentation, considering it much clearer than before.
However, when we presented the new condition relationship logic involving a group and its items, they immediately pointed out their familiarity with the original logic. They expressed concern that the conceptual change would require extra learning time. This feedback made me realise that while I had focused on making the function easy for new users to learn and use, I overlooked the needs of our existing users. I initially saw this as a user experience improvement, but in reality, it introduced unnecessary changes to a system that was functioning well.
Redesign what doesn’t work, not what works well
Recognising the discrepancy between our expectations and the users' actual needs, we promptly decided to revert to a design that follows the original logic. I adjusted the design swiftly in two days, as it was still under development and had to meet the project timeline. I maintained the visual design, which had proven to be simple and clear, but applied it to the previous logic.
Final design of conditions with updated grouping logic
After a year of iterative work, we successfully launched this new feature. With this enhancement, we saw a significant increase in the Product Net Promoter Score (PNPS) from -32 to -20. This reaffirmed the importance of measuring success as it evidenced our achievement in addressing user problems and gaining their trust, which was very encouraging. We received additional feedback on minor functions, indicating that this project will continue with another iteration. We learned from our mistakes, recognized the importance of testing and validation, and understood that we should not hesitate to pivot if necessary. After all, it's always better late than never.
