Complex operations do not happen in isolated modules
HR ran payroll in one place. Operations managed expenses in another. The data overlapped, but nothing connected it. A leave request logged by HR still had to be reflected in payroll by hand. A fine issued to a driver had to be copied across more than one system before it landed where it mattered.
HR ran payroll in one place. Operations managed expenses in another. The data overlapped, but nothing connected it. A leave request logged by HR still had to be reflected in payroll by hand. A fine issued to a driver had to be copied across more than one system before it landed where it mattered.
The loop was the same on every module: understand the product and its risks, break the problem down, design flows and structure, plan the work, build alongside developers, review regularly with the founder and cross-functional team, test, document thoroughly enough that developers rarely had to come back with questions, hand off, retest, and collect feedback for the next cycle.
Each module had its own hard part. Here is what that was, and what I did about it.
(Bb5® — 04)
Payroll Looked Simple Until It Wasn't
Every company has its own payroll rules, including our own. I rebuilt the payroll logic more than once as new edge cases surfaced. The fix was to stop designing one fixed payroll and design per-company settings instead, so the product could bend to each business without a redesign.
Designing finance workflows around the events that drive them.
The finance stream covered payroll, expenses, loans, fines, cash deposits, allowances, reimbursements, deductions, liabilities, cash balance, and vehicle-management data. The challenge was to create a product experience that could support connected financial records while remaining flexible enough for different company policies and operational rules.
I designed workflows that helped users:
Understand where financial information originated.
Manage finance-related actions without losing operational context.
Review exceptions, statuses, and dependencies more clearly.
Configure settings based on company-specific needs.
Rather than treating finance as a separate destination, the design considered it as part of a wider operational system.
REASULT
HR-logged leave now flows into finance automatically, and fines connect through to the driver app.
Learning Bookkeeping to Design It
Accounting
↗
Accounting
↗
Accounting
↗
Accounting
↗
Accounting
↗
Accounting
↗
Accounting
↗
Accounting
↗
Accounting
↗
Accounting
↗
Accounting
↗
Accounting
↗
An internal accounting workspace that brings financial records, reconciliation, and reporting into one connected operational system.
Designing for accuracy in an unfamiliar domain.
Transportech needed internal accounting capabilities so users would not need to rely entirely on external accounting platforms. Accounting was a new domain for me, so I began by learning its fundamentals and studying established tools such as Microsoft 365, Zoho Books, and Xero.
One of the most important challenges was bank reconciliation. Small mistakes can affect later records, so I designed clearer matching, confirmation, and validation states to reduce the risk of errors propagating across connected modules.
The module was still in design and development when my engagement ended, so this case study focuses on the product decisions and workflow design rather than post-launch metrics.
This research informed the design of workflows including:
Journal entries and general ledger accounts
Trial balance and closing-journal processes
Bank accounts and bank reconciliation
Purchase orders and sales orders
Asset management and financial reports
REASULT
A clearer accounting foundation for tracing financial logic, validating critical workflows, and reducing risk before release.
Making government data actionable
Controller
↗
Controller
↗
Controller
↗
Controller
↗
Controller
↗
Controller
↗
Controller
↗
Controller
↗
Controller
↗
Controller
↗
Controller
↗
Controller
↗
A B2G monitoring workspace that turns dense transportation data into clear signals for faster, more informed action.
Designing a B2G dashboard for attention, not data overload.
The B2G Controller product enabled government stakeholders to monitor transportation companies, fleet activity, incidents, compliance-related information, trip trends, revenue, and operational performance.
The core challenge was data fatigue. Government users needed visibility, but not a dashboard that forced them to interpret a wall of numbers before understanding what required attention.
I applied a “5-second dashboard” approach and a three-tier information hierarchy:
Immediate status
High-priority signals, exceptions, and key indicators.
Decision layer
Trends, comparisons, and drill-down paths.
Immediate status
Reports and operational records for deeper investigation.
REASULT
(e4® — 01)
Improving quality across multiple product streams.
Alongside hands-on product work, I supported the HR and Operations streams by helping the design team work with more structure and consistency.
My responsibilities included:
Reviewing flows, states, requirements, and interface consistency.
Identifying missing scenarios, unclear handoff details, and design gaps before implementation.
Supporting team members through feedback, guidance, and regular design reviews.
Bridging communication between founder, stakeholders, designers, and developers.
Participating in implementation checks and UAT.
| RESULTS |
(e4® — 01)
Data-silo overlap eliminated
Fewer design implementation errors and less rework
(Bb5®)
03
/ 05
Meranto
