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, with one clear mission: design and ship an entirely new invoicing module from a blank page, while also improving the experience across the rest of the platform.
Because invoicing didn't exist yet, there was no existing pattern to extend - the entire experience had to be shaped from business goals, backend constraints, and real user needs, all at once.
PayEm's platform was powerful, but missing something core: native invoicing. Customers were stuck bolting on third-party tools just to get invoices done, which meant a disjointed experience sitting inside an otherwise unified product.
This wasn't a small feature gap. It meant designing a foundational pillar of the product from zero, while also holding onto three things at once: complex customization for clients with their own payment-handling rules, a visual language sharp enough to differentiate the product, and an architecture flexible enough to carry a full roadmap of future features without needing a redesign later.
Solving three hard problems
Trusting AI-extracted data without trusting it blindly
Part of the invoicing flow relied on OCR to pull bill line data straight from scanned documents - but OCR is never perfect, especially with real-world paperwork. I designed the human-in-the-loop layer that sat between the AI's first pass and the final invoice: a review interface where finance teams could check, correct, add, or delete extracted bill lines against the original source document before anything was finalized. The AI did the first pass; the person stayed in control of the outcome
Designing for enterprises that don't work the same way
Every client had different payment-handling requirements and approval structures. The invoicing flow had to support that range without turning into a maze of settings - flexible enough for enterprise complexity, simple enough that finance teams weren't fighting the tool to get a straightforward invoice out the door
Building for a roadmap that didn't exist yet
None of this could be designed as a one-off. I built the information architecture to absorb future features without a rebuild - proven when "Bill Lines Mapping" was added post-launch and slotted into the existing layout without reworking the core structure
Discovery
I started with a UX audit of the existing platform to understand what was already working and where the gaps were. Alongside that, I ran a competitive analysis across roughly five invoicing and spend-management tools, mapping their flows to find real opportunities rather than copying patterns wholesale. From there, I ran workshops with developers and stakeholders to build a Customer Journey Map - which turned out to matter less as a deliverable and more as the thing that got backend dependencies and technical constraints on the table before a single screen existed.
Building it
From there: full information architecture for the invoicing system, low and high-fidelity prototypes covering the flow end-to-end from invoice creation to payment processing, and 250+ screens mapped to account for the edge cases and user states a system this complex actually has. Usability testing with target users validated the design before handoff, and I worked closely with developers through implementation to keep the shipped product true to what was designed.
Designing for complexity, not around it
Most invoicing tools solve for the simple case and bolt on exceptions later. PayEm's users didn't have a simple case - multi-step approvals, varied payment handling, and enterprise-specific rules were the normal case, not the edge case. Mapping 250+ screens wasn't about coverage for its own sake; it was about making sure the system held together once real-world complexity hit it, instead of falling apart at the first client with unusual requirements.
Including concepts which didnt work
The final UI focuses on making a genuinely complex process feel manageable: creating, sending, and managing invoices smoothly, with customization available but never forced on users who don't need it. It was built with scalability in mind from day one - the reason a feature like Bill Lines Mapping could be added after launch without anyone needing to rethink the core layout.
Extending the design system
I delivered a fully functional, end-to-end invoicing feature from a zero state - 250+ screens covering the real complexity of enterprise payment operations, not just the happy path. The design supported custom payment-flow logic, including integration with third-party tools clients were already using. Running the CJM workshops early meant backend dependencies were clear well before development started, which cut down on rework later in the project. The system was built to extend - new features since launch have slotted into the existing structure rather than requiring a redesign.
The slowest part of this project wasn't the build - it was the first few weeks, spent refining ideas in the design room before I'd properly sat down with the people who'd actually use the tool. If I did this again, I'd skip straight to that conversation. The fastest way to design for a room is to sit in it.
I think there's much more for me to learn about Said, but he strikes me as an independent and self-organised designer. He's open to discuss his design ideas and decisions, able to show pros and cons, when talking to the client he's very open and capable of presenting the solution.
Kajetan Izycki
Senior Product Designer, GetApril
Said is highly professional as a UX designer. I enjoyed working with him as a part of our team for the last 6 months. He's communicative, skilled in his designs, open-minded- many things that one only hopes for in a designer.
Adina
Senior Product Designer, GetApril