UX DESIGN / WORKSHOPS / PAYMENTS

Activity list

Job to be done: As a user I want to understand that my transaction paid the invoice intended to pay.

The design idea was to create a confirmation to the user to show that their action on the page was successful. The action being a making a payment. Successful mening either scheduled or sent money to the chosen receiver.

The scope is a result of a larger design project of re-designing a Resurs mobile app. Previously there was no indication to show the user that the payment towards an invoice was successful or not.

Activity List as project became a never ending story. Despite countless efforts of workshops we kept on misunderstanding each other.

The project shines light upon the team work of back-, front-enders and UX. The balance of being in sync together yet standing your ground as a UX designer ground and not folding for every technical difficulties which in the end results in the user suffering.

First Iteration

 

All was quite simple in our UX heads. We were not reinventing the wheel and we felt it was a straightforward process. Looking back, we should have been better at picking up the early warning signals. The developers kept on asking questions that to us, was either here or there. After user testing the design in various preference tests, we went live with the first version. Quickly to realize that it was not what we had hoped for. The job we had set out to accomplish for the user was far from done. Invoices couldn’t be linked to transactions; we were showing both in and out payments and we realized that a larger issue was at scale here. We as a team had a no common understanding on our definitions. An invoice for us in UX was not the same thing as an invoice for the developers. Neither was a payment. Or a transaction.

 

We gathered the team for a workshop in defining various items that we often use in our products. What is an invoice? What is a debt? What is a payment for us as a company versus a payment for a user? Great discussions and interesting conclusions. With minor design updates we released the product again. However, this time I had an unsettling feeling that the developers were too involved in the design and that we had adjusted the product too much to our technical shortcomings. Which we had. Since the original job to be done was still not reached. The users didn’t understand when their invoice had been paid or not. We had made a simple design problem and solved with a much to intricate solution. Not daring to tell the user that the invoice had been paid since our developers couldn’t with absolute certainty tell us that it had.

Workshops

In the end.

 

Long story short. We, UX, went back to the drawing board and made the most simplest design, limiting the user somewhat in what they could do with payments once they were sent, but sticking to the original story: show me that my invoice is paid. And so we did. Stay tuned to the iteration stories.

Next
Next

Marked as paid