CASE STUDY

Transaction Viewer

PROJECT BRIEF

The transaction viewer aims to provide details about all transactions that have occurred between the software, third parties, and manufacturers. Initial view of the transactions will display top-level information and include the ability to drill down for more comprehensive details.

CLIENT NEEDS

  • Improve transaction history security by transitioning the viewer to the client support portal

  • Audit users/roles who have viewed, copied, and/or downloaded transaction history

  • Copy or download XML files as part of audit

USER NEEDS

  • Filter transactions by date range, type, customer, manufacturer, health, method, direction

  • View, copy, and/or download transaction history

  • Clear visual communication if the transaction is successful, has errors or warnings

  • Search by any transaction detail (transaction ID, correlation ID, vendor, integration, manufacturer)

PHASE 1: Discovery

We analyzed the current workflow, conducted market research, and collaborated with clients to identify their pain points:

  • The user must define an end date and decide which invoices to display without knowing if they are paid/unpaid.

  • Once the user has begun the process, it must be completed. There is no way to save progress.

  • The only way to view the total per vendor is to preview the print queue.

  • All invoices must be paid using a check. No additional payment options are available.

  • Duplication of payments by multiple users in the system simultaneosly.

PHASE 2: Definition

We focused on a practical strategy to set a clear direction for the design process.

  • Developed detailed, empathy-driven profiles representing the target users to create personas:

    • A/P Clerk, Accounting Manager

  • Formulated actionable problem statements to articulate the core problem and guide the solution:

    • Users need a way to flexibly manage, reconcile, and save progress on vendor payments, as the current rigid, check-only workflow lacks visibility into invoice status and prevents collaborative processing, leading to manual errors and duplicate payments.

  • Mapped the user journey by diagramming the required steps, highlighting obstacles, and featuring opportunities for improvement.

  • Translated user needs into specific functional requirements for the software that were viable within the project scope.

    • Filter invoices by vendor name/number, invoice number, due date

    • Reconcile individual vendor invoices

    • Queue invoices for payment at a later time

    • Freeze activity on a vendor when multiple users are active on the screen

    • Add payment options: cash, credit card, EFT

Wireframes

To translate functional requirements into a tangible interface, I first designed a series of low-fidelity wireframes. These sketches focused on establishing a logical hierarchy and spatial organization. By mapping out the main steps of the process in this static format, I ensured the structural integrity of the solution before moving into interactive prototyping.

PHASE 3: Ideation & Design

Prototype

Once the Agile team aligned on the structural layout, I developed an interactive prototype to simulate the final user experience. By incorporating functional transitions and precise interactions, I created a high-fidelity model that clearly demonstrated the software’s behavior. This served as a critical reference for both developers and QA teams, ensuring technical implementation remained faithful to the intended design.