Payments portal (web app)

Payments portal (web app)

DT Digital, Macquarie Bank – DEFT, 2014

This project was the ground-up design of a new payments management application for DEFT, a company owned by Macquarie Bank.

‘DEFT: est. 1995.’

Once an innovative front-runner in providing simple payment transfer services to small businesses (particularly real estate and strata business customers), our client was facing stiff competition in the market they had previously led:

  • There was no real time feedback for business clients to know that a bill had been paid. While their customers used the service to receive payments, they couldn’t check they’d been processed in real time. This meant they’d have to wait until funds had been deposited into their bank accounts (a wait of 1–3 days) to see if expected payments had been made.
  • There was no way for business clients to see or manage their customers. The system used to distribute account numbers to payers was a paper-based one. Businesses (e.g. property managers) handed out cards with unique account numbers, which payers had to then set up in an antiquated online system.
  • Business clients had no control over payments. This also meant that the responsibility for setting up accounts and recurring payments rested solely with the end customers, not the businesses receiving them. This would frequently lead to payments being missed, or incorrect — and left businesses without a feeling of control over their accounts.
  • The overall experience was weighted in favour of payment methods that didn’t generate revenue for the business. The increasing dominance of the electronic bill payment service BPAY in the Australian market meant that they were forced to support transactions using this popular service — at cost— or else lose business customers.

Our challenge: build a better product.

The user experience mission was clear:

  1. Design a product experience to surpass competitors, and meet basic customer expectations for real time visibility of transaction data, and control over their accounts.
  2. Design an overall service that’s easier to use than BPAY, shifting primary choice of payment method to direct debit or credit card instead.

Initial concept generation involved talking in depth with business stakeholders and reviewing existing research, and producing user journeys for key tasks needed by the product as a whole.

We went through a process of creating and discussing user journeys of customers using DEFT — trying to understand the key “threshold” or “trigger” moments when they were likely to be persuaded to become users.

Out of this initial work came insights about new ways to integrate the service into the everyday lives of tenants and new workflows for allowing billers to do most of the work to make it easy for payers to choose other payment methods.

  • For billers: this was when a payment had not been received (usually identified by an external source) and they wanted to quickly check recent transactions. DEFT had to help them find this missing info in shortest time possible.
  • For payers: this was the moment when the first email arrived from their real estate agent, confirming that they’d won the property they wanted — and needed them to make the initial holding deposit. The opportunity to change their behaviour was linked to their willingness to quickly make that initial payment and seal the deal.

I’m particularly proud of the user journey below. It imagines the on-boarding of a new payer, initiated by a real estate agent:


I really like this journey because it:

  • suggests integration with the ‘1form’ tenancy application system for easy entry of user data,
  • identifies and simplifies a key moment in the experience of quickly paying the holding fee — to drive use of DEFT,
  • uses the initial account setup (now initiated by the agent) to communicate payment details to the new customer.

Application maps and screen flows


We also produced detailed application maps and screen flows to shape the application design. Before moving on to detailed wireframes, high-fidelity designs, and a full front end prototype.

Detailed screen flows: Documented the steps users would take in the system, and the information they’d need to see. — Application map: Showing the structure of the proposed application, and breaking out key processes to be designed.

Detailed Wireframes and clickable Axure Prototypes


We produced detailed wireframe documentation, and for many of the more complex interactions also produced clickable Axure prototypes to aid the communication of our ideas with the wider team.

Detailed documentation in Confluence


For this project we thoroughly documented our design solution in the client’s Confluence Wiki as we worked, linking everything we did back to business requirements in accompanying Jira tickets.

This gave us a single source of truth for the documentation, and also a clear place to track feedback, design options, and agreed sign-off with the client-side project team.

A highly collaborative build

Build screenshots

One of my favourite things about working on this project was our high level of collaboration in the process of detailed design.

A tight team of UX, design and front end worked collaboratively and concurrently on the final prototype build that would be delivered to the client.
Very proud of the final result. This is a stand-out project for me, and probably my favourite to date.

My involvement:

  • I conducted meetings with key stakeholders and reviewed the existing research documentation.
  • I helped our team write a clear reverse brief for the client, clearly defining the problem we were solving and planning out how we were going to work on it.
  • I reviewed existing solution design documentation created by client-side BAs and challenged existing flows to simplify and refine the approach.
  • I created user journeys and then the detailed process flows for key user tasks within the system, allowing us to focus closely on the most important moments of the experience that we needed to influence —considering the experience for both our customers (billers), and their customers (payers).
  • I produced extensive wireframes in Axure for every template, documenting the final approach. I annotated these within wiki pages in confluence.
  • I worked closely with design and front end development to craft an interactive HTML prototype to deliver to our development partners.