ANODA Discuss your product

Charitable bill payment, seen four ways

Payyro lets donors pay a family’s overdue bill to whoever sent it.We audited it, shipped its first version and redesigned it for four roles.

Payyro vendor Help Requests for Oakwood Property Mgmt: customers with status, amounts requested, donated and left to go, and a row menu open; Payyro customer Help Requests on a phone, Pending tab: a rent request from Oakwood Property Mgmt awaiting the customer’s approval
4
roles Customer, Vendor, Donor, Super Admin, around one request
Shipped
first release on Webflow and Wized, before the redesign
400+
screens designed for Payyro

Payyro is a crowdfunding platform for household bills. A family, or the company they owe, posts a Help Request for a real bill; donors fund it. We started with a UX audit of the existing product, built and released its first version on Webflow and Wized, then did a complete UX and UI redesign for four roles, the public website , a refined brand and one design system behind all of it.

What moves through Payyro

One chain, from a bill to a paid vendor:

  1. The bill

    • Vendor invoice
    • Category
    • Amount

  2. The request

    • Story and video
    • Eligibility proof
    • Customer approval

  3. Verification

    • Documents checked
    • Published
    • Or rejected

  4. Giving

    • Browse and filter
    • As a guest or signed in
    • Anonymous gifts

  5. Funding

    • Raised so far
    • Still needed
    • Fully funded

  6. Payout

    • Payout queue
    • Paid by hand
    • Marked as paid
Plain Thorough
Short guided steps for a stressed applicant, and still every document the check needs.
Private Trusted
Donors see a first name, a story and a verified mark; bills and documents stay with Payyro.
Shared Separate
One request and one status underneath; each role sees its own part and its own next step.

A donor’s decision, top to bottom

Found
A donor is about to pay a stranger’s bill. Unsure who is asking, who gets the money or how far the request is from done, most people close the tab.
Decided
One column in the order a donor’s questions come: who and what for, whom Payyro pays, how much is still missing, the amount, then how the gift will appear and where it goes.
For the user
The donor knows the money reaches the clinic, not a personal account, before choosing an amount.
Payyro Give help screen: James C. from Pflugerville asking for a clinic co-pay, Austin Family Clinic marked as the vendor Payyro pays, $480 needed, $210 received, $270 still needed, amount buttons of $10, $25 and $50, and notes that the gift appears as Anonymous and goes to the clinic, not to James
After: a donor giving to a medical request; names and figures are example data

  1. Who asks, and who is paid

    A first name and town, the bill in plain words, and the clinic Payyro pays.

  2. How far along

    Needed, received so far, still needed.

  3. The amount

    Three quick amounts or any sum, with the limits under it.

  4. Where the gift goes

    Shown as Anonymous, paid to the clinic rather than to James, then one action.

How the work progressed

Personas and role flows first, then wireframes, the full UI and its system, the website at four widths, and a handoff with the rules written beside the screens.

  1. Discovery

    Who the four roles are, what each needs from a request, and on which device

    Artifact An audit of the existing product and a persona for each role

    Donor persona: Sarah, 29, a spontaneous and empathetic giver, with her photo, a quote, occupation, location, income and devices, beside cards for her pain points, motivations, core needs and technology use

  2. User Flow

    Every path for each role, and the point where one role hands a request to the next

    Artifact Role user flows with their states and error branches

    User flow fragment: updating an email, phone code verification with a resend branch, and adding a bank account with its error states

  3. Wireframes

    What each step asks for, settled before any visual decisions

    Artifact Black-and-white wireframes of the request flows

    Black-and-white phone wireframes: completing a request with an address, then a contract number, title and description

  4. UI & Design System

    How four roles look like one product, and how a status reads the same everywhere

    Artifact Final screens for all four roles, a UI kit and design system, and a refined brand

  5. Adaptives

    How the public website holds from a wide desktop down to a small phone

    Artifact Website layouts at 1440, 1024, 768 and 375, with motion

  6. Delivery

    What engineering needs beyond the screens: the rules, the states and the edge cases

    Artifact Interactive prototypes, dev notes on every flow, and a documented website

Three roles, three key paths

Found
Each role comes to the same request from a different side, and a path designed for one would stall the others.
Decided
Each role’s key path was mapped as its own flow, with the step where the request passes to the next role made explicit.

  1. Customer: applying in five steps

    Basic details, the bill, proof of eligibility, a story and an optional video, then a clear pending state.

    Open the full map
    Customer application on a phone: basic information, request details with the bill, eligibility proof, your story, a short video, then Application Submitted

  2. Vendor: a request on a customer’s behalf

    Who the bill is for, the bill itself, then review; the customer approves before anything goes live.

    Open the full map
    Vendor creating a Help Request in three steps: the customer found by phone, the bill with its amount and invoice, then review and submit for the customer’s approval

  3. Super Admin: paying the vendor

    A funded request waits in the payout queue; the admin pays from the invoice and marks it paid.

    Open the full map
    Super Admin payouts: the queue of fully funded requests with a row menu, the payout details with the instruction to pay from the invoice, then Payout marked as paid
Payyro navigation: the Super Admin sidebar with counts per section, and the top bar in its vendor, guest donor and signed-in donor versions

Each role finds its way differently

The Super Admin’s sidebar with a count on every section, and the top bar for a vendor, a guest donor and a signed-in donor.

  • Role user flows
  • Navigation for each role
  • Interactive prototypes
  • Dev notes on every flow

Six jobs across four roles

The Customer first, then the Vendor, the Donor and the Super Admin. Names, bills and figures on these screens are example data.

A request the customer can follow

Found
Someone waiting for help with a bill wants one thing: to know where the request stands and what is theirs to do next.
Decided
Requests in three tabs, Pending, Active and Completed, each card with its status, funding and next step; inside, who is paid, what was donated, and what can still be changed.
Help Request Details on a phone: overdue electricity bill, active, paid to City Power & Light, $432 needed, $100 donated, the invoice, and Cancel or Edit Request

Many requests on a vendor’s desk

Found
A landlord or a clinic may carry dozens of overdue accounts, and a request lost among them is money nobody collects.
Decided
Every request in one table with its status, amount requested, donated and left to go, search and a status filter, and a row menu for the rest; each request opens to its funding and the bill behind it.
Vendor Help Requests table for Oakwood Property Mgmt: customers with status, date added, requested, donated and left to go, and a row menu with Edit Request, View Attachments, Send SMS to Customer, Contact Payyro and Cancel Request
Vendor request detail for Marcus Bell: active, $900 raised of $1,450, $550 to go, and the bill and customer with category Rent and the invoice

Nothing goes live without the customer

Found
A vendor can post a bill for someone, but the request carries that person’s name and circumstances.
Decided
The customer receives an invitation showing the bill, the amount and who is paid, and approves or declines it; on a vendor’s request the amount and the invoice stay locked.
Invitation on a phone: Oakwood Property Management wants to help you pay this bill, rent of $1,180 with its invoice, a note that nothing goes live until you approve, and Approve & Continue or Decline This Request
Edit Help Request on a phone: the amount greyed out, the title and the reason editable, the invoice attached, and Save Changes

Strangers worth trusting

Found
Donors are asked to fund someone they will never meet; without evidence they don’t give, and with too much of it the family loses its privacy.
Decided
Requests to browse without an account, filtered by category, amount, vendor, place and date, each with a first name and initial, a Verified by Payyro mark and the vendor Payyro pays; a profile adds the story and a video.
Help Requests for a guest donor: filters for category, amount, vendor, location and date, and three request cards with funding progress, the requester, the vendor Payyro pays and a Verified by Payyro mark
Customer public profile for Olivia J., verified by Payyro: amount raised, requests, member since, her story, an active rent request with Give Help, a completed past request, and photos and a video

A donor’s own giving

Found
A donor who can’t see past gifts, or can’t give quietly, tends to give once.
Decided
An account with what was given and to whom and a switch to stay anonymous; a failed payment says what happened and offers a retry.
Donor My Account: total given, people helped, recent transactions by category, the Stay anonymous switch, personal information, help and account controls
Payment failed: the donation could not be processed, with Try Again and Back to Help Requests

Checked before anyone sees it

Found
Every request carries a real person’s documents and a real bill, and one unchecked request going public costs trust across the platform.
Decided
Help Requests and Customers as tables, with counts in the sidebar; each opens in a panel with the request, the requester and the payee, admin-only notes, the eligibility documents, and verify or reject.
Super Admin Help Requests with a request panel open: a pending phone bill of $95 that activates once the customer is verified, the requester in verification, the payee Metro PCS, the invoice, and Reject or Delete
Super Admin Customers with a customer panel open: identity under review, SSDI letter eligibility, phone and address, admin-only notes, the customer’s story, profile photos, and Verify Eligibility or Reject

One design system for four roles

Found
Four roles on phones and desktops would drift into four products, each with its own idea of a request and a status.
Decided
One UI kit: universal components, a desktop set, a mobile set and the website’s own, so a request card or a status badge means the same thing everywhere.

One request, two cards

A request as a donor browses it on a desktop, and as its customer follows it on a phone.

  • Help Request Card component for the donor browse view: category, Give Help, the title, funding progress, the requester, the vendor Payyro pays and the Verified by Payyro mark
    Donor, desktop: Category, funding, the requester and the vendor Payyro pays.
  • Request Card component for the customer’s phone: an active request with its funding, and one awaiting the customer’s approval
    Customer, phone: Status, funding and the next action: view, or review and approve.

Every status, one badge

Draft to Paid in three sizes, with the category badges beside them.

  • Status badges for pending, draft, under review, active, funded, error, paid, completed and cancelled in large, medium and small sizes, and category badges for rent, medical, mobile, education and utilities
    Status and category badges

The public website, from desktop to phone

Kept
The promise first, then Give Help and See How It Works, and the two proof cards: transparent giving and verified families.
Changed
The navigation folds into a menu on a portrait tablet, and on a phone the page drops into one column, the cards under the actions.
For Donors page at 1440 pixels: Give Help. Change Lives. with Give Help and See How It Works, and the Verified Families and Transparent Giving cards around a family photo
1440 · Desktop Navigation in full, proof cards around the headline.
The same page at 1024 pixels
1024 · Tablet, landscape Full navigation, the same order, tighter.
The same page at 768 pixels: the navigation in a menu, the headline, both actions and the two cards over the family photo
768 · Tablet, portrait The menu behind a button; cards over the photo.
The same page at 375 pixels: one column with the headline, both actions and the cards
375 · Phone One column, the cards under the actions.

A website that explains the model

Found
A platform that pays bills on strangers’ behalf needs explaining before anyone signs up, and families, donors and vendors each ask a different first question.
Decided
An About page for the whole model and a page for each audience, each opening with that audience’s reason to join, built from the same design system as the product.
Payyro About page: Give Help. Get Help., the note that donations go to vendors, the categories of help, and a list of families who need help with filters
For Families page: You Don’t Have to Face It Alone, with Get Help and See How It Works
For Vendors page: Accelerate Collections for Your Business, with Become a Vendor Partner, and cards on strict data privacy and data protection

  • Brand refinement

    Colours, visual style and the logo, refined rather than redrawn.

  • Motion

    Interactions and animation for the website.

  • Four widths

    Every page at 1440, 1024, 768 and 375.

  • Website documentation

    Behaviour notes for building the site.

What engineering received

One client file, organised by role, with the rules written next to the screens they govern.

Interactive prototypes
The main flows for each role, clickable end to end.
Dev notes and edge states
Validation, empty, pending, blocked and error states, each with its rule beside the screen.
Design system
Universal, desktop, mobile and website components, with usage notes.
Website documentation
Responsive behaviour and motion for every page.

Flows in the handoff

  1. Customer: applying in five steps and following a request
  2. Vendor: requests on a customer’s behalf
  3. Donor: giving help and their own giving
  4. Super Admin: checking requests and paying the vendor
  5. Design system: universal, desktop, mobile and website components
  6. Website at four widths, with its animations
  7. Website documentation: responsive behaviour and motion
Customer sign-in screens on the Figma board: phone entry, phone errors, code verification with its resend timer, blocked accounts, and yellow dev notes under them
Dev notes on the screens: Customer sign-in: phone entry, code verification and its timer, each with the rule engineering needs.
Payyro UI kit pages: primary, secondary, accent and destructive buttons in default, hover, pressed and disabled states, text inputs and text areas in each state, and the one-time code input
UI kit: Buttons, inputs and the code field, every variant and state with its usage.

Where the product is now

Payyro went from an audit of its existing product to a first release on Webflow and Wized, then to a complete redesign: four role-specific experiences around one request, a public website for families, donors and vendors at four widths, a refined brand and one design system, handed over with prototypes and dev notes on every flow.

The client approved the redesign, and its second version is being built in Next.js, React, Node.js and Supabase.

screens designed
400+
roles, each with its own screens
4
website widths, from 1440 to 375
4
first release, on Webflow and Wized
Shipped

In the client's words

ANODA helped organise a product with several distinct roles into a shared design direction. We appreciated the attention to the journeys between requests, support and administration, so the product could be discussed through concrete screens and flows.

Craig London Payyro

5.0

Do all your roles read a status the same way?

In Payyro, a Customer, a Vendor, a Donor and a Super Admin act on one request, and the vendor is paid by hand only once it is fully funded. One status has to mean the same thing in four views. Show us where your roles meet, and we’ll find where they’d read the same record differently.

Discuss your product Explore more case studies

What we brought to Payyro

The product

The interface and the build