8. User Flow Diagram_Architecture

GiveHope Platform: User Flow Documentation

8. User Flow Diagram

An end-to-end map of every path a user can take through the GiveHope platform — from the moment they land on the homepage to the final donation confirmation screen. It covers three types of users (Guest, Registered Donor, and Administrator), all entry points, the campaign browsing and discovery experience, the full 6 to 7 step donation wizard including cause selection, Ramadan objectives, split payment scheduling, Fitrana and Fidya add-ons, payment processing, and post-donation actions. The donor dashboard journey is also mapped, covering donation history, recurring schedule management, fund breakdown, and profile settings. This diagram answers the question: what can a user do on the platform and in what order do they do it?

Diagram: User Journey Flow Diagram.png

This eighth diagram is a User Journey Flow Diagram (also known as a Logic Flowchart). While the previous seven diagrams focused on the system's "guts"—its servers, databases, and data movement—this diagram focuses on the Human Element. It maps the logical decision-making process of a user as they navigate the UI, illustrating the "happy path," error states, and branching logic (like the difference between a Guest and a Registered user).

1. Entry Points and Branching

The top of the diagram establishes the initial state of the user:

• Authentication Check: The first major diamond (decision node) asks: Is the user logged in?

• The Fork in the Road: If Yes, the flow leads to the Donor Dashboard. If No, the flow branches toward the Public Landing Page or Guest Checkout.

2. The Discovery Phase (Campaign Navigation)

The middle section (often grouped in light blue or yellow boxes) represents the browsing logic:

• Search & Filter: Users interact with category filters (Zakat, Sadaqah, Emergency Appeals).

• Campaign Selection: The logic flows into a "Campaign Detail" state.

• The "Add-on" Logic: A unique branching point where the user chooses whether to add a platform tip or split their donation across multiple causes.

3. The Transactional Core (The Checkout Wizard)

The long vertical column of decision diamonds represents the high-stakes checkout process:

• Information Gathering: Is this a guest or a returning user? (Determines if the "Address/Contact" fields are auto-filled).

• Payment Method Selection: Branches for Stripe (Card) vs. PayPal.

• Validation Loops: If a payment fails (the red "Fail" branch), the logic loops the user back to the payment step rather than kicking them out of the process entirely.

4. Success and Post-Action States

The bottom of the diagram shows the "Exit" logic:

• Receipt Confirmation: The system displays a success message.

• Account Conversion: A specific logic branch for Guest Donors—asking if they would like to save their details and create an account based on the donation they just made.

• Redirects: Sending the user back to the dashboard or the home page to start a new journey.

🏗️ User Flow Phase Evaluation: The "Donor Experience" Audit

This User Flow Diagram is the final "layer of the onion." In the context of a charity, this is your Conversion Funnel. If this flow is clunky, donors will abandon their Zakat mid-way.

1. The "Guest-to-Member" Bridge

• The Strength: You identified a specific logic branch for "Account Conversion" after the donation.

• The "Perfect Build" Check: This is a psychological masterstroke. Donors are most invested right after they give. The flow should allow them to "Claim their Account" with a single click using the email they just provided.

• Developer Note: "On the 'Thank You' page, if the user was a Guest, the UI should offer a 'Save my details for next time' button that triggers the Auth Service to create a password for the existing Donor record."

2. The "Validation Loop" (The Stress Point)

• The Strength: Your diagram shows a loop back to the payment step if a card fails.

• The "Perfect Build" Check: A "perfect" build preserves the user's data. If a card is declined, the user should not have to re-select their Campaign or re-type their name.

• Developer Note: "The Donation Wizard must use Persistent State. If a payment fails, the UI state must remain populated so the donor only has to fix the credit card number."

3. The "Fitrana/Fidya" Logic Fork

• The Strength: You’ve mapped specific "Add-on" logic for Islamic-specific giving.

• The "Perfect Build" Check: These often have "per-person" costs. The flow needs a "Quantity" selector that updates the total dynamically.

• Developer Note: "The Donation Wizard should include a 'Multiplier' component for Fitrana. If the user selects 5 people, the Calculation Engine must update the sub-total in real-time."

🛠️ The "Frictionless Flow" Checklist

🎯 Final Conclusion: The Complete "North Star"

You have now reviewed eight foundational pillars of your charity's digital architecture: