INTRODUCTION
DocX (Docs relationship explorer) is an inquiry tool for Accounts payable clerks, to easily and quickly locate all related documents across types within Procure-to-Pay process based on visualized document relationships.
ORGANIZATION
D365 Finance team: AP Automation
PPMG Design Studio
TOOLS USED
Figma, Balsamiq, Xmind, Whiteboard,
Teams, Office Word + Excel + PowerPoint
PROJECT TEAM
UX designer: Me (0-1 build a feature)
1 PM, 3 SDEs, 1 QA
Design studio lead: Kevin Honeyman
Program manager: Zezhang Zhao
Principal group manager: Kacper Rzepecki
Mentor, Sr. UX designer: Alina Lin
PROBLEM
No shortcuts and unclear document relationships make it time-consuming and troublesome to locate, review and compare all related documents across types. Each query session usually costs more than 3 min.
SOLUTION
DocX is a centralized panel to
-
filter and access all types of related documents
-
visualize their matching relationships
It covers more than all use cases (20+) and adapts to 4 edge cases.
DESIGN PROCESS
*During 3 months in MS, I was responsible for 2 projects. Here I only take the main one to elaborate.
C H A L L E N G E
CHALLENGES
Design universal interaction patterns for all use cases.
Different use cases have multiple variables, this requires a consistent pattern to adapt to them.
MY APPROACHES
Creating sitemaps and discussing with engineers (pilot tests) to be aware of edge cases and frequency.
Start with the simplest cases and add on incrementally to keep the tool adapting to fit all cases.
Facilitate user onboarding to new concepts.
Elaborating on new features requires self-explanatory UIs and interactions to lower the learning cost.
Using Fluent UI design language, and iterating interactions based on A/B tests feedback.
Work cross-functionally to tweak and find a "just-enough" balance from info insufficient to info overload.
R E F L E C T I O N
Why do we reduce the prototype fidelity when testing?
-
Prototypes used for testing do not necessarily need super high fidelity (such as mimicking all data and business cases). Otherwise, it is easy to shift their attention to feedback on business rather than experience.
-
Coding qual and quant data from testing: Qual data needs to be better analyzed and synthesized (excel sheets to organize user feedback would be helpful). For quant data, it requires users to give straightforward scores on different metrics (ex. likeability, confidence, and value scores).
-
Moderate and control the conversation: The very beginning is to set the tone of the user test and emphasize to the user that it is not to test the person but to test the tool which makes users relax.
Having more self-drive and collaboration made my project a greater impact.
-
By discussing with interns in the upstream and downstream business, I found that we could string together a story. So they helped me develop some workable design concepts, and I helped them apply my design framework's interface design.
-
The collaboration supports me to onboard myself on the project better, as well as cook a nice storytelling of the whole flow from both the engineers' perspective and the user experience designer's perspective.
MY ULTRA-HAPPY TIME AT MICROSOFT X)
