0 to 1 Enterprise Delivery
Architected an end-to-end, 8-step invoice approval flow spanning 250+ screens in just 8 months, handling complex, multi-account edge cases.
Human-in-the-Loop AI
Designed a contextual review layer for AI-extracted OCR data, eliminating the need for fragmented third-party workflow tools.
Design System Expansion
Designed and integrated 50+ net-new components into the early-stage design system to support high-density data tables and multi-step approvals.
PayEm is a global spend and procurement platform built for finance teams managing corporate spend end-to-end. I joined as the sole product designer for an 8-month engagement to design a tool that didn't exist yet: invoice checking and approval, from the moment a bill arrives to the moment it's paid.
Because nothing like it existed on the platform before, there was no pattern to extend - the entire flow had to be shaped from business goals, backend constraints, and real user behaviour, all at once.
Eight months later, that blank page was a working eight-step approval chain spanning 250+ screens, handling real enterprise complexity instead of just the happy path - the decisions that got there are the actual story.
PayEm's platform was powerful, but missing something core: a way to take an invoice from upload to paid without leaving the product. Customers were stuck piecing that process together with third-party tools, inside an otherwise unified spend platform.
This wasn't a small feature gap. The finished flow needed to walk an invoice through eight distinct stages - invoice details, PO matching, accounting details, bill approval, payment creation, payment approval, payment schedule, paid - while staying usable for finance teams who touch dozens of invoices a day, and flexible enough to handle enterprise clients whose payment-handling rules rarely looked the same twice.
Solving three hard problems
Trusting AI-extracted data without trusting it blindly
Users could upload an invoice as a PDF or fill everything in by hand. When uploading a document, a third-party OCR tool automatically scanned and pre-filled the corresponding input fields. However, I deliberately implemented a "friction-by-design" verification step: the system never auto-skipped the review phase, even if the AI returned a 100% data match. By forcing this human-in-the-loop interaction, users explicitly confirmed the extracted data against the source document. The AI did the heavy lifting of the first pass, but the user always retained final control, eliminating the anxiety of blind automation
Capturing spreadsheet-level detail without breaking the flow
Bill lines needed to hold an unlimited number of excel-style columns - far more detail than a single invoice-level form could hold. I designed them to open as a bottom drawer on desktop that kept the source PDF visible the whole time, so users could cross-check line items against the original document without ever leaving the main flow. More on this below - it's the decision the rest of the case study centers on.
Keeping an eight-step approval chain feeling like one flow, not eight
Bill approval, payment creation, payment approval, and payment scheduling all involve different people with different permissions - only specific approvers could sign off on a bill, and a separate step handled moving money once it was approved. Each stage had to be legible on its own while still feeling like a continuation of the same process, not a chain of disconnected forms
Discovery
Alongside that, I ran a competitive analysis across roughly five invoicing and spend-management tools, mapping their flows to find genuine opportunities rather than copying patterns wholesale. To ensure enterprise complexity didn't derail the project timeline, I drove early alignment between product and engineering by facilitating cross-functional Customer Journey Map workshops. This exercise proactively surfaced critical backend dependencies and technical constraints, effectively de-risking the build and preventing expensive scope creep before a single screen was ever designed
The decision I had to defend
Bill lines were the hardest part of this to get right, and there were a few real ways to build them. The simplest to build would have taken users to a separate page or step dedicated entirely to line-item entry - more room to work with, easier for a table full of custom columns. I pushed against that. Bill lines are part of the same task as reviewing the invoice, and sending users somewhere else to do it would have broken that continuity right when they needed the source document most.
I designed the drawer instead: it opens over the current step rather than replacing it, and the PDF stays visible the entire time so users can scan the document and fill line items without losing their place. It was the harder layout problem to solve - fitting a genuinely complex, unlimited-column table into a drawer instead of a full page - but it kept bill lines feeling like a continuation of the flow instead of a detour.
Building it
From there: full information architecture for the eight-step flow, low- and high-fidelity prototypes covering everything from invoice upload to paid, and 250+ screens accounting for the edge cases a system like this actually has - no PO on file, custom payment methods, multiple approvers, and more. Usability testing ran throughout, including sessions specifically on the bill lines drawer. One finding that came directly out of those sessions: since we couldn't predict every scenario a finance team might need to capture, I added a custom bill fields option so users weren't boxed in by the fields we'd anticipated. It tested well and shipped.
Designing for complexity, not around it
Real invoices don't follow one path. If there was no purchase order on file, users could request one from an admin instead of getting stuck. If there was a PO - which was true most of the time - they selected it from a list instead of re-entering data that already existed. Once a bill was approved, creating a payment meant choosing a "from" account (which had to already exist), a "to" account (which could be selected or created on the spot), and a payment method - ACH, iACH, or Wire - before the payment itself went through its own approval step. None of this was designed as an edge case bolted onto a simple flow; it was the actual shape of how enterprise finance teams work.
Including concepts which didnt work
The flow didn't start at eight steps. Early on, we were designing toward something closer to ten - payment-related actions were split across more individual stages than they needed to be. It made sense conceptually, but in practice it added friction without adding clarity. We simplified by merging the separate payment-related steps into a single payment creation step, which cut real steps out of the flow without losing any of the functionality behind them.
The final design carries a genuinely complex process - upload, review, match, approve, pay - without making users feel the complexity at every step. Bill lines, custom fields, and multi-account payment creation all sit inside the same eight-stage structure, built so that later additions could extend it without requiring a rebuild.
Most of the interface drew on PayEm's existing design system, which was still early-stage when I joined. Wherever the invoicing flow needed something the system didn't have yet - the bill lines drawer, the multi-step approval indicators, the account selection patterns - I designed the missing components in consultation with the rest of the design team, adding roughly 50+ new components to the system along the way.
I delivered a fully functional, end-to-end invoice approval flow from a zero state in just eight months. By front-loading backend constraints through journey mapping, I effectively de-risked the engineering phase, allowing development to execute a highly complex, 250+ screen flow without expensive architectural pivots mid-build.
The final product successfully absorbed the fragmented, third-party workflows enterprise teams were relying on, unifying upload, OCR review, matching, and multi-tier payment approvals into a single native environment. Additionally, I expanded PayEm's early-stage design system by delivering 50+ new, scalable components that now support complex data tables and routing logic across the broader platform.
The hardest part of this project was never any single screen - it was making an eight-step process feel like one continuous flow instead of eight separate forms. If I did this again, I'd push to test the full end-to-end journey earlier rather than validating each step in isolation; some of what we only caught late, like the need for custom bill fields, might have surfaced a stage sooner.
Said is very competent. He has great practices when it comes to his product design workflow, and he's very serious about it. His solutions are always the result of in-depth explorations and thorough analysis of the problem.
He made himself available whenever I needed some help and responded quickly to messages. I felt I could always count on his feedback whenever I needed it, which is really nice.
I really enjoyed his engagement when it came to sharing feedback and helping others. His ideas often helped to progress in complicated tasks.
Julien Cordat-Auclair
Senior Product Designer, Netguru
I really really enjoy working with Said on both aspects: personal and professional. Throughout the period we have been working together, he knew how to take feedback and brought great solutions to tasks he was working on. He is also a comfortable person to work with in the sense of communication.
Arthur
Lead Designer, PayEm