AFTRAS
Accounts Payable File Translator System
Replacing a manual Excel-macro workflow with an automated tool, and cutting processing time by 90%, by designing it with the people who used it every day.
Role
C#/SQL Developer · Technical Writer · Support, with embedded UX research
Timeline
April 2020 – July 2022 · 3 development phases, support throughout
Team
Myself, a co-developer, and a senior developer for occasional support
90%
less time spent
Team-wide estimate: About 10 hrs/week down to about 1 hr/week
+ Add AFTRAS UI Screenshot
Application walkthrough / key screens
Background
The situation
The client’s finance department converted accounts payable invoice downloads from their work order management system (API Pro) into Oracle Fusion upload files using Excel macro workbooks. Every step of processing and editing was manual, and all the data lived in spreadsheets, which made it hard to manage or adjust. The task took about two hours a day, five days a week.
“It is busy work that is easy, but takes way too long”
The goal
Reduce the time the finance team spent exporting accounts payable invoices and creating Fusion files.
“We have other important tasks to get to”
Scope
In scope: SQL database setup, local application access, uploading API Pro files, saving data to the backend, surfacing invoice data errors, exporting missing invoices, reprocessing invoices, and zip-file processing for download.
Out of scope: personal account information and update logging.
Constraints
• Customer invoices expire after a set period, so delays risked missed payments
• A two-person development team, with occasional help from a senior developer
• Each customer had different invoice requirements, so the backend had to validate against them before zip files could be processed
Research & Process
With only three end users, research was part of the build cycle. Every phase was shaped by conversations with the people doing the work.
3
AP specialists, the full user base
~3
moderated usability sessions per phase
Weekly
design reviews and check-ins
2
fresh-eyes reviewers for walkthroughs
01 Discover
Workflow and requirements
Virtual contextual inquiry
Walked through the legacy Excel-macro workflow with users.
Semi-structured interviews
A script anchored to leadership’s requirements, flexible enough to follow what end users raised.
Requirements documentation
SRS, training documentation, and implementation plans agreed with the client.
02 Evaluate
Iterative Testing
Moderated usability testing
Typically with all three AP specialists, about three sessions per phase.
Weekly design reviews
Informal first-click and comprehension checks on designs and builds.
Cognitive walkthroughs
With a senior developer and a point of contact outside finance.
03 Iterate
Keep the loop open
Weekly check-ins
System status and open conversation about their processes.
Email log
A running record of new requirements, findings, and bugs.
Agile delivery
Three phases of iterative build and redesign.
04 Measure
Quantify the change
Time-on-task benchmarking
About 10 hrs/week down to about 1 hr/week, team-wide.
Post-launch request patterns
After phase 3, requests were mostly one-off errors and support.
Timeline
Phase 1
4 weeks · April 2020
Dev product tested on backlogged data, SQL database set up.
Phase 2
8 weeks · May–June 2020
Upload and download with live data, invoice update features.
Phase 3
3 weeks · November 2020
Finance’s reimbursement process added.
Ongoing support
Through July 2022
One-off fixes and customer-specific changes.
Who I worked with
3 AP specialists
The end users. They rotated who processed files, sometimes working in pairs.
Finance leadership
The CFO and financial manager, who provided top-level requirements.
Development team
Me, a co-developer, and a senior developer who gave occasional support and a fresh-eyes walkthrough.
Outside reviewer
A point of contact outside the finance department, who joined the cognitive walkthroughs.
From Findings to Design Decisions
Each decision traces back to something users told or showed us.
What I learned
What we changed
Users spoke in AP terms like “API Pro” and “Zip Files.”
Labels and buttons use the AP department’s own terms.
More buttons with each phase meant more reading, and more confusion.
• Color with contrast: red for errors, green for progress, blue/purple for always-present controls
• Necessary actions centered and largest, on a simple, uncluttered layout
• Conditional actions (“Fix row errors,” “Export missing invoices”) appear only when needed
Users wanted to know zip-processing status and the invoice count per file.
Progress bar labeled “X of Y invoices,” and zip files named by date and invoice count.
Each customer had different invoice requirements.
Backend validation against each customer’s rules before processing, with errors shown in the UI.
Leadership focused on speed, but users also needed clarity within each step.
Clearer labels and grouping per step, alongside overall speed.
The designed system
+ Add screenshot
Color semantics: error, progress, and always-present controls
+ Add screenshot
Hierarchy: necessary actions centered, conditional actions on demand
+ Add screenshot
Progress bar with invoice count, and date-and-count file names
Results
90%
less time spent on the task
10 to 1
hours per week, team-wide estimate
Beyond the numbers
After phase 3, incoming requests dropped to one-off errors tied to customer-specific requirements and application support.
Figures are team-level estimates. The three AP specialists rotated the task and sometimes worked it together, so they reflect elapsed time rather than per-person hours. Dollar impact was not tracked.
Reflection
Our users are our experts.
What the project taught me
Leadership had strong opinions on how the product should look. By the third phase, I’d built enough trust with end users that conversations became candid, and that surfaced fixes leadership hadn’t asked for, like clearer labels and grouping within each step.
What I’d do differently
One end user with carpal tunnel struggled with the volume of mouse clicks. With more scope or budget I’d explore keyboard shortcuts, right-click options, and fewer confirmation pop-ups. I’d also run formal usability testing with task success rates and a SUS score.
In hindsight: heuristics
This project is where I began thinking in terms of usability heuristics. Looking back:
• Progress bar: visibility of system status
• AP vocabulary: match with the real world
• Conditional buttons: minimalist design
• Error pop-up and row fixes: recognize and recover from errors