UX/UI Redesign for Efficient Journey

--- ## Statement of Work (SOW) ### RNPL Flow UX/UI Redesign for A/B Testing ## Project Objective Analyze the current RNPL flow on [login to view URL] and redesign it into an improved **B-flow** for A/B testing. The redesigned experience should reduce redirection, eliminate unnecessary user drop-off points, and create a more guided, reliable, and mobile-first journey. Since the design work will be delivered in **Figma**, the scope must clearly define the expected **pages/screens**, screen states, and how the flow should be consolidated into as few screens as reasonably possible. --- ## Current Behaviour The current RNPL flow is spread across multiple route-based steps, including: - RNPL landing page - Lead capture/submission - KYC page - Document save / progress-dependent states - Screening flow - Consent flow - Result states - Resume/re-entry path - Thank-you/completion page This creates a journey with multiple redirects, fragmented transitions, and possible bounce/error points when progress is not saved correctly. --- ## Expected Behaviour The redesigned RNPL **B-flow** should aim to convert this fragmented experience into a **screen-efficient, mobile-first guided flow**. ### Expected UX Direction - Minimize the number of unique pages/screens - Reuse the same screen structure across multiple steps wherever feasible - Use dynamic content states inside a single screen rather than redirecting users to entirely new pages - Keep redirection at **zero to minimal** wherever possible - Use step-based progression, inline transitions, modal/card states, progressive disclosure, and state changes within the same screen - Ensure each screen can adapt to multiple stages of the RNPL process without feeling repetitive or confusing --- ## Screen Design Approach Because Figma design workflows are typically organized **per page/screen**, the RNPL redesign must define: 1. **How many unique screens/pages are required** 2. **Which steps can be combined into one adaptive screen** 3. **Which screens need multiple states** 4. **Where screen transitions are necessary vs. where inline state changes are preferred** The goal is **not** to create a separate screen for every small step if that increases fragmentation. Instead, the goal is to design a flow where **one screen can continue changing contextually** to support the process, as long as usability remains clear and practical. --- ## Proposed Design Expectation for Screens The designer should explore a structure such as the following: ### 1. RNPL Entry / Introduction Screen Purpose: - Introduce RNPL - Explain value proposition - Present CTA to begin eligibility/application flow Possible states: - default intro - calculator/eligibility teaser - CTA state ### 2. Lead Capture / Basic Eligibility Screen Purpose: - Capture initial information - Start user qualification - Reduce friction in the first conversion step Possible states: - initial form - validation/error state - success/progress state ### 3. Multi-Step Application Screen Purpose: - Act as the **main reusable application container** - Handle most of the RNPL process within a single evolving screen where feasible This screen may accommodate: - personal details - rent details - employment details - KYC prompts - document upload states - screening preparation steps - review/confirmation substeps Possible states: - step 1 - step 2 - step 3 - upload empty state - upload success state - save in progress - saved/resume state - validation/error state ### 4. Screening / Bank Connection Screen Purpose: - Handle financial verification-related actions with clear guidance - Present connection and consent steps in a simple, low-anxiety format Possible states: - screening intro - connect bank state - waiting/processing state - retry/error state - consent required state - success state - pending review state ### 5. Outcome / Result Screen Purpose: - Show approval, pending review, declined, or next-step messaging clearly Possible states: - approved - pending review - declined - additional action required ### 6. Completion / Thank You Screen Purpose: - Confirm completion - Reassure user about what happens next - Present next steps or support options --- ## Expected Page/Screen Strategy The design should aim for **a limited number of primary screens/pages**, ideally grouped into: - **1 entry screen** - **1 lead capture screen** - **1 core reusable multi-step application screen** - **1 screening/consent screen** - **1 result screen** - **1 completion screen** So the expected design system should target approximately **5–6 primary screens/pages**, with multiple states inside each screen instead of many disconnected pages. ### Important Note The exact number of screens can vary based on what is practically feasible from a UX perspective, but the expectation is: - **fewer unique screens** - **more reusable/adaptive screen states** - **zero to minimal redirection** - **clear step progression without creating page fatigue** --- ## Scope of Work ### 1. Current Flow Review Review the current RNPL flow and identify: - existing step/page structure, - redirection points, - bounce points, - save/progress dependencies, - failure-risk moments, - areas where one step could be absorbed into another screen. ### 2. RNPL B-Flow Redesign Design a mobile-first RNPL B-flow that: - reduces fragmentation, - reduces number of screens where feasible, - uses one evolving screen for multiple steps wherever practical, - minimizes redirects, - improves completion confidence, - is suitable for A/B testing against the current experience. --- ## Deliverables **Figma only – no code** The deliverables should include: - Current RNPL flow breakdown - Current behaviour vs expected behaviour comparison - Screen/page architecture for the new RNPL B-flow - Defined number of primary Figma pages/screens - High-fidelity UI for all key screens - State variations for reusable screens - Interactive prototype showing: - screen changes - inline transitions - step progression - minimal redirection logic --- ## Designer Instruction / Design Principle The RNPL B-flow should be designed with the principle that: > **One screen should continue evolving to accommodate the process wherever feasible, instead of redirecting the user to a new page for every step.** New screens should only be introduced where necessary for: - clarity, - security, - technical separation, - or significantly different user context. --- ## Success Goal Produce a Figma-based RNPL B-flow that is optimized for A/B testing and improves on the current flow by reducing screen fragmentation, minimizing redirects, and creating a smoother guided journey using as few core screens as reasonably possible. --- If you want, I can now turn this into a **very sharp client-ready final draft** in one polished version, because right now this is structurally correct but still a bit internal/working-doc style.

Project ID: 40354483