Ordo Pay. A payment-request service for the Open Banking era.

01 — OverviewOrdo Pay

In early 2019 I was asked to help out Ordo with the user experience of their newly developed payment system. I learned that in the UK a new system called the Open Banking API would be launched for all major banks that summer. It’s a new and simpler way to pay that allows building all kinds of functionality on top of it.

Ordo Pay is designed for small business owners — think about boiler engineers, cleaners or gardeners. It’s a niche that has a lot of problems and zero solutions to digitalise and manage their business. On the other side, we have their clients, who are moving away from independent sole traders for the same reasons: lack of a default way of communication, a multitude of channels (I will explain this a bit later) and support.

How does it work?

Ordo Pay gives you the options to register as a sole trader (limited company or other similar legal entity) or as a household user.

As a business owner it allows you to send payment requests to a household user you are working with. When the household user receives the payment request, they have the main option to pay, or a couple more options like extending the deadline or payment in instalments. Once the request is paid, the system automatically detects it and notifies both sides as paid — so a lot of hassle is spared, like constantly checking the bank account, messages and missed calls.

This will make Ordo Pay the one-stop place, in the case of a household user, to pay for cleaners, electricians, mechanics etc. As for the business owners, it will act as their management tool for business.

02 — ProcessResearch & Testing

As a start

I had to familiarise myself with the business and walk through existing user journeys. As it had a lot of complexity around the tech side of things, a priority was to treat the flow in such a way it would pass the strict banking regulations.

In development they had a development version of the app that was available to beam in TestFlight, and I started a heuristic overview evaluation of it. Lots of functionality was there, but it was created for debugging the iOS and backend environment.

Research

Things we liked:

• Open magic email link — Slack
• Household tasks — TaskRabbit
• Bidding for an item — eBay
• Arrivals and departure flights to an airport — Flightradar

User registration flow

Prototyping

As we were constrained by time, after we nailed down the user flows we jumped straight into prototyping. Lots of screens were designed directly in Flinto, a Sketch-like software that allows you to rapidly prototype apps with a complex set of interactions like swipe back, scroll and variables.

Testing

In order to learn more about how small business owners relate with customers, the team recruited around 7 small business owners and 8 household users to test the app.

It was interesting in testing to learn how hard it is to manage a business, as most of the small business owners are mobile users and they don’t pay for a proprietary software or use the Google Docs suite.

Results

In testing I encouraged every member of the team to write down their observations and ideas on post-it notes and stick them up on a whiteboard, grouped by stages.

We then used Miro RealtimeBoard to track them, count duplicates and write them in text form in a spreadsheet. After that we discussed how we prioritise them with the tech team.

Iteration

After the testing we decided along with the CTO to prioritise the issues that we encountered. With all these I started the process of solving the design.

03 — DashboardDashboard

One interesting feature was to create a tailored dashboard that works for both household and small business users, as long as a possible niche of multiple-use users.

In the app we’ve designed a series of interaction modes like Notifications, Confirmations and Info Bubbles. Even though they are similar, they each have different attributes:

Notifications will be visible on top of the dashboard and they will require an action — in fact they act like buttons. Confirmations are just text only, and they will not trigger any action. Info bubbles are part of the learning curve; they are designed to fill areas that are blank or first time to use — often we can use cool imagery and copy.

Tab navigation

There are two tabs on the bottom nav, the Homepage and the Profile. While the (+) plus is on the nav, it acts more like a button rather than a tab. Once clicked it will prompt a request takeover screen that will cover the menu.

Now the two main journeys are really split up. We had people that would receive requests and send them themselves, so when they see ALL transactions on the homepage they will either see their paying requests (for Household users) or they will see their payment requests (for Small Business users).

Request button

The whole point of the app is to push users to make requests; without requests sent and received the whole service is obsolete and risks getting lost within the apps on your phone. The success of the service depends on having a big chunky (+) Plus button that will be easily seen and accessed all the time.

On the first run — The user will be asked to grant access to the contact book.

Recurring — Easily access the request for further usage; the aim would be for users to keep it in the same folder on their phone as their everyday banking app.

The plus button will launch the payment request journey. Once tapped, the next step is to select your contact, add a new contact, or see the remaining requests.

Send request

I will break down in steps what you need to do in the case you want to send a request — starting with the first thing that comes to mind when you are sending a request, which is the person you are sending it to.

If we don’t have access to the contact list and we intend to always enter the details manually, we can start with an input field to add the telephone or email of your recipient.

Profile

The profile page is an aggregated view of settings and should contain heuristic links to the most important settings.

• Profile Section 1 — Identity
• Profile Section 2 — Request Credit
• Profile Section 3 — Funding Sources (My Accounts)

04 — FunctionsMake a Request

Here are the user journeys when you are dealing with making requests, where we have our main scenario and a couple of edge cases — like when you need to add a new contact, when you don’t have any requests left, and when you haven’t been granted access to the address book.

User journey wireframes

Explanation

Make a request — In the first journey we have Jane making a request to Marleah of £670 for her MacBook repair services.

Add new contact — The second journey shows how to add a contact and send a request. We have input fields for name and surname, a tab option for email or phone number, and an option to add this as a contact in the address book.

No requests left — The third journey is when you don’t have enough requests left.

No access to address book — The fourth screen represents when you did not grant access to the address book, and shows an empty contact list with an info bubble to explain how to give access manually.

Prototype

05 — FunctionsView a Request You’ve Previously Made

You have already made a request — here are the options that you have.

User journey wireframes

Explanation

Jane sent a request to Adam on 20 March 2019 for £1000. In the first journey Jane opens the request and sees her options — in this case the option to change the date or withdraw the request.

In the second journey Jane chooses to withdraw the request. Once she taps ‘Withdraw Request’ a pop-up confirmation appears in order to confirm the action. Once confirmed, the screen jumps to the homescreen and the card changes, showing a ‘withdrawn’ message in the due box.

In the third story we have the option to change the due date. Once the ‘Change Due Date’ CTA is tapped, a new screen similar to the one from making a request appears, with an option to edit only the date field. Once you confirm the change you are directed to the homepage and you see a confirmation of your change. The due date on the card is updated but the rest remains the same.

Prototype

06 — FunctionsPayments

Here is an example of the payment flow. In the first route we show how a full payment works, and in the second how to part-pay a request.

User journey wireframes

Explanation

John had previously sent a request to Jane for the office cleaning services he provided, of £670, with the option to part-pay on.

In example A, Jane fully pays him; in option B, she part-pays him £500 and later the rest of £170. In the prototype the user can always check the history of the transactions in a timeline.

Prototype

07 — FunctionsSend an Extension Request & Respond

These screens show how a user sends a payment extension request to another user. The user has an option to agree with the request or decline it.

User journey wireframes

Explanation

• Route 1 — Jane sends John a request for extension
• Route 2A — John approves the request
• Route 2B — John declines the request

Prototype

08 — FunctionsDecline a Request

In this case Jane (the client) will decline a request sent from John (the biller) for an office cleaning job of £670 he did.

Jane’s screens have a thin purple tint while John’s screens have a green one. The timings are the following: John sent a request on the 18th of March, and the action — in this case the client declining — happens on the next day, the 19th of March. We can always check the timeframe of events by accessing the history screen on each transaction, clicking on the ‘See history’ button next to the main text field.

User journey

09 — Wrap-upDesign & Conclusions

Design

In design I led the way in a clean, minimalistic style. I worked with their brand designer in order to set colours and tones.

The wireframes were already modular components in order to ease up the skinning process.

Conclusions

Press