EZ Registration: Rebuilding APL eZRx's Customer Verification Process | Case Study

Phase 1 : Understand

APL's team came in with a clear picture of their existing process. They shared their current registration flow, the expected improved flow, and the document requirements for each business type. Our job was to dig into that material, ask the right questions, and map out what a unified digital system would actually need to handle.

I worked closely with the Business Analyst to go through the requirements for all 30+ business types, using a spreadsheet to map similarities and differences across forms and steps. This early mapping was what made the design phase manageable. Rather than treating every business type as a separate design problem, we could identify where forms could share structure and where genuine variation existed. We also conducted interviews with APL's internal team to understand how approvals actually worked in practice, including the regional differences that were not always visible in the documentation.

Phase 2 : Ideate

Before touching the interface, the team mapped detailed flows for each user role in Draw.io. With a system this complex, involving multiple approval levels, regional variations, and 30+ form configurations, jumping straight into wireframes would have created gaps. Getting the logic right first meant the wireframes would reflect how the system actually needed to behave.

Existing Flow :

Expected Flow :

Low-fidelity wireframes covered both the customer-facing registration flow and the admin-side approval interface. These went through several rounds of review with stakeholders before we locked the direction.

Phase 3 : Decide

One of the more significant process decisions came when we hit the challenge of designing for 30+ business types. Creating a separate prototype for every variation would have been both time-consuming and difficult to maintain. Instead, I maximized Figma's variants and variables to build modular components where similar forms shared a base structure and variation was handled through component properties rather than duplicated frames.

Using Figma's variable modes to define visual properties separately from the structure meant that moving from low-fidelity to high-fidelity still required adjustments, but nowhere near the effort of rebuilding from scratch. The core logic and layout carried through, so the transition was mostly refinement rather than reconstruction.

Phase 4 : Prototype & Validate

High-fidelity prototypes were built in Figma and presented to stakeholders for review. This phase was about confirming that the design held up against real requirements before anything went to development. Feedback from these sessions fed back into the final designs, ensuring the flows were intuitive and the logic was sound for both the customer-facing side and the admin CMS.

Phase 5 : Handover & Iteration

Once the designs were validated, I worked directly with the front-end and back-end teams through the build. The component system built in the early stage made the handoff more precise, giving developers and QA engineers a consistent, well-documented set of components to reference. As development progressed, I stayed involved to make sure the implementation stayed true to the design intent and to address any gaps that came up during build.