Payments and Invoicing
Generative Research
Generative Research
The business's core product was a two-sided marketplace to connect consumers who need a job done with local service providers (e.g. carpenters, photographers, removalists, etc.) who are available to do the work.
As a result of the organisation pivoting to a different revenue model, there was a business need to collect transaction data (which often occurred offline).
Establish the existing mental model regarding payments for jobs. Ascertain why certain payment methods are preferred and if there are any opportunities to improve the experience in an online setting.
In-person contextual inquiries were not feasible but I compensated for this by doing them remotely (screensharing on Skype) during some of my interviews, so that even if I couldn't observe the physical context/environment, I could at least observe their digital behaviour/environment with real data.
I set up a survey asking users about how they paid for a specific job and why, as well as their general preferences with payments. This way, I elicited both preferential data and the actual outcome.
CustomersBusinesses
- What was the last job you hired someone for?
- How did you pay for this job?
- Why did you choose that method over the others?
- If different to the above, what is your most preferred method and why?
- Which industry do you work in?
- Which payment methods do you accept?
- Which is your most preferred and why?
- Which do you NOT accept? Why not? (Optional)
Some considerations I made while writing the questions include the following:
In addition to the survey, I added a modified version of the questions to one of the customer support call scripts and used the call centre to get volume around the research. I also conducted my own phone and/or Skype interviews to delve deeper into the reasons why and also things like invoicing.
I affinity mapped the research findings, grouping them by payment method and then by reasons/themes. I was able to identify patterns in cases where each payment method was the most preferable and why. I also paid attention to when the preferential data was different to their actual behaviour, as that suggested an unfulfilled need. We were able to uncover some insights about the payments process and validate the existence of a problem to be solved regarding credit cards.
Although customers had preferences for payment, the actual payment method used was generally influenced by what was easiest or asked for by the business, especially if there was rapport.
The words "easy" and "quick" featured prominently in the research results, and cash and bank transfer were considered the most convenient.
There are a number of circumstances that influence which method is preferable including
The big drawcard for cash is that it's instant and universal. Customers knew that cash would always be accepted (and sometimes they even got discounts). For businesses, it saved them a lot of hassle. And for both customers and businesses, paying cash meant that it was over and done with. However, a big dependency in this advantage is having the cash on hand. The larger the job, the less likely the customer would be to have enough cash on hand. Likewise, for jobs where the cost is not known in advance. Having to withdraw cash, particularly large amounts, was a disadvantage (and withdrawing may not even be feasible for jobs where everything takes place on the same day). In these cases, bank transfer was preferable.
Bank transfer was advantageous in that it didn't require the customer to have the cash on hand (which is useful when the amount is large and/or not known upfront). It also had the advantage of being traceable, which provided the customer with a sense of security. With cash jobs, there was not always an invoice or receipt, but traceability was not as big an issue for smaller value jobs. For businesses, it allowed them to go home after they've been working all day and take care of the invoicing and admin tasks later (as payment by bank transfer doesn't need to be done face to face). Additionally, for some businesses, their accounting systems were set up to automatically match bank receipts with accounting revenue.
However, since the payment is not settled then and there, there is a risk of dragging the process out as customers do not always pay promptly (and in some cases, they don't pay at all).
While the majority of payments were by bank or cash transfer, very few businesses offered credit card as a payment option. This was because of the cost and equipment associated, which businesses could not justify given the size of their business and the ease of alternatives. Credit card did feature prominently in the preferential data from customers, however (particularly for larger jobs).
By far, the pervading theme of business's frustrations with the payment process was anxiety about getting paid, including not getting paid on time (or at all), customer resistance to payment, and the feeling of uncertainty that came along with all of it. Moreover, chasing customers up for payment was time consuming.
There was an opportunity to save business's time and ease their anxiety by combining the certainty that came with settling the payment immediately, and the traceability and flexibility of bank transfers. It also reduces admin by utilising the information we already have about the initial quote, the business's bank details, the customer's contact information, etc. Furthermore, if the barrier to accepting card payments was cost and equipment, that was something we could address using mobile and absorbing the credit card fees (this was possible as the businesses paid a commission that was greater than the cost of the credit card fee).
We saw some patterns emerge in the data, which we captured by creating personas. In summary, our main personas were:
I gathered everyone who would be working on the payments project and we storyboarded the different scenarios (price known/unknown, settled immediately/later, etc.) based on the research and the personas we had identified. We looked at when the pain points happened, and the surrounding context. Then we iterated on the storyboard with the proposed solution. In our scenarios we were particularly interested in:
The main problem points we identified were:
We also came up with possible variations for other scenarios:
We knew broadly what were going to do, and we had described it in prose. We had an invoicing system on the site that we could adapt for some of this project (this made it a lot easier for the developers, and we could make changes based on feedback). However, for the more substantive parts that we were starting from scratch, we began the design process with an ideation workshop. It has been proven that groups outperform individuals when performing creative tasks, and the design studio technique allowed us to harness this effect in eliciting creative ideas from a cross functional team.
One example is the workshop we conducted for escrow. In preparation, we looked at competitor's offerings (e.g. Airtasker, Freelancer, Odesk) to see how they implemented theirs. Together, we analysed the merits of each, and identified the differences in context (e.g. Freelancer's solution was good for Alana, but not so great for Mick). A variety of ideas came out of the workshop including:
It was decided that for practicality, we would adapt the existing payment flow for escrow in the short term, with a view to fleshing it out with the other ideas (e.g. contract metaphor) in the long term (subject to any learnings in the interim).
Sometimes a design studio was considered overkill if the problem was fairly straightforward, such as allowing Julie to access her transaction history and receipts. In cases such as this, I would look at the research we had done and sketch the required flow for the user goal, either on my own or with my payments colleagues. At this stage, the aim was to come up with the framework, rather than the specific interface details. I would come up with a couple of alternatives and discuss it with the team. Once we had a shared vision, we began prototyping.
Before we began building anything, I first built a prototype to validate it and identify any issues. The method for prototyping depended on the maturity and/or scale of the concept. For some of the larger and/or more novel portions, such as the mobile solution, I used paper prototyping. For smaller, higher confidence interfaces, or where it would otherwise be easier to start directly from an Axure prototype, that is what I did. For instance, for the original flow (business requests payment, customer pays), we had decided to leverage our existing invoicing system. As such, I was able to reuse my Axure prototypes, and I made the relevant changes.
Once the prototype is built, it's then a matter of usability testing and iteration. For instance, to speed up invoicing, I originally had the due date prefilled and uneditable (the business would set their terms in their settings and this would be applied across all invoices). However, in testing, it was revealed that the terms could be different depending on the type of customer (a business customer vs. a residential customer). This meant that we needed to allow businesses to set the due date of each invoice, which we fixed for the next iteration.
After iterating, we got the developers to code up the minimal viable product, so that we could learn from people actually using it.
Once the MVP was released I monitored how it performed. For example: