Transaction Details
When I joined the project, much of the backend work had already been developed, leaving limited room for changes to improve the frontend experience. However, with the support of UX research, we identified areas for improvement, conducted a competitive analysis, and worked to gain buy-in from the product team for future enhancements while focusing on building interim states.
Here are a few key areas where my role involved identifying improvements and presenting concepts to the product and tech teams:
1. Confusing Statuses
Through research, we confirmed our hypothesis that the current "open" and "closed" statuses for transactions were unclear and did not accurately convey the transaction's progress. We suggested more descriptive status labels, such as "authorized," "voided," "canceled," "refunded," "disputed," etc., to better reflect the actual stage of the transaction. Additionally, we reviewed how other companies displayed their statuses for reference.
2. Improvement to Information Hierarchy
In this use case, transaction details were organized according to the lifecycle stages. However, much of the information could be better presented at the transaction level instead of being tied to a specific lifecycle step. For example, why should customer details be associated only with the authorization stage? The customer information is relevant to the entire transaction, not just one step.
3. UI Issues and Patterns
Several UI improvements could streamline the flow, such as replacing the details drawer with a full page view. Additionally, converting other actions into pop-ups would help users stay focused when performing tasks.
Key Learnings
Delivering a seamless product experience from day one can be challenging due to various constraints. As a designer, it’s crucial to influence the process by presenting a phased approach and defining both target and intermediate states to help the team visualize the full vision