/ Introduction and genesis
PayBox solution for Authorized car services
PayBox is a response to the market demand for non-contact customer service at any time of the day throughout the year.
PayBox is used for contact-free payments for servicing at authorized car dealerships.
It can work together with the KeyBox solution or completely independently.
When a user receives an invoice to be paid from a consultant, he can easily pay for it using this solution, using the payment method of his choice.
The main purpose of this product was to replace the cashier’s desk at the car dealership and reduce the number of payment terminals to one in the form of a virtual cashier.
/ Automotive PayBox solution
The process of designing a product
/ Think — Discovery Stage
The first step in the product design process was to gather initial project information and expand our knowledge of the industry, analyse it and prepare for a workshop with the client.
We then conducted design workshops with the business and the client where we gathered the overall assumptions and goals of the project. To do this, we used a variety of tools such as the Value Proposition Canvas, protopersons and user stories.
By conducting workshops, we were able to gather the necessary knowledge about our project and build solid project assumptions, define problems, identify technical possibilities or legal restrictions.
The next step was a market analysis in search of similar solutions on the market and the definition of a product strategy for the Polish market. This allowed us to make a preliminary estimate of the market demand for this type of product.
/ Think — Ideation Stage
In order to deepen market and product knowledge of good practice in the design of similar solutions, I carried out research and analysis of products from intermediate industries such as parcel machines, manufacturers of screens and digital signage solutions, self-service checkouts, ticket machines and kiosks of various types.
Based on the information gathered during the workshop and the analysis of related solutions, we were able to determine what the final product would look like. From the on-screen functionality it is to have to the physical elements needed for the service payment process, such as a physical payment terminal and QR code reader. Another important issue was the design of different brackets to allow the solution to be mounted in different areas of the car showroom.
The biggest challenge of this stage was the integration with the car showroom’s sales systems, which translated into the design of the interface where the invoice number was entered.
To measure satisfaction after service at the dealership, we also designed a series of questionnaires at the end of the payment process, which the user could optionally complete. These were to complement the questionnaire that the customer receives by SMS or e-mail after using the KeyBox solution.
/ Make — implementation stage
After gathering all the required information about the product, it was time to map the user’s path through the application using the user flows tool. This allowed me to map the path the user takes when paying for a service, including predicting error handling during payment and planning the path accordingly for this eventuality.
I then approached the design of the app in such a way that I first performed a review of trends in the design of various apps and used the knowledge I had gained from researching competitors in the field of digital signage and related apps.
I began designing the app by experimenting with different versions of the app’s UI for different car brands in order to design a look that was as universal as possible and required as little personalisation as possible when deployed to different customers.
After designing the final UI for the app, I consulted the design with the client and made some minor adjustments based on their comments.
The next step was to collaborate with the developers on the implementation of the project, here I actively collaborated with them so as to deliver the project in the highest possible quality, while also explaining how certain UI elements should work and behave.
At the end of the development, we planned internal tests of our solution, which already took place in the customer’s showroom as the payment process requires integration with external systems.
Thanks to these tests, we discovered some bugs and shortcomings in our product, which we corrected first.
We also carried out a series of ‘corridor’ tests on salon employees to identify usability errors for our solution.
/ Learn — delivery stage and main problems.
At this stage, we focused mainly on collecting feedback on our product from salon staff and customers and correcting errors.
After just a few weeks of the solution being operational, the first comments about our product started to come in from the client.
In order to deepen the information obtained, we conducted short interviews with salon employees, which revealed a few key errors with our solution:
The first such rather serious error in terms of product usability was problems with reading QR codes from customer invoices. To compound the problem, we conducted full-scale usability tests on the service’s customers, which took place directly at the customer’s premises in the showroom. To illustrate the issue, a test on five customers was enough to show the same problem with the reader in each customer.
The main conclusion of the test was that the QR code reader was poorly positioned, which in some screen positions meant that the customer could not locate it because he could not see the laser beam underneath. Such a usability error was mainly generated by a screen positioned in a directly vertical position. The solution to this problem was stickers on each screen indicating that the code should be scanned below. And in the next iteration of the product, replacing the screen readers with a laser beam more visible to the user.
The second problem reported to consultants was the occasional hang-up of the screen as well as the reader, an issue we resolved in the next iteration of the product by changing the supplier of the screens as well as the code readers to a more reputable manufacturer.
The third problem was the lack of a taken care of case when a user wanted to cancel a service payment, after the first failed transaction already. The solution to this problem was to add a cancellation of the payment process after each failed transaction.
One technical problem we also had to deal with was the system of marking invoice numbers with different suppliers, which translated into a different way of entering them on our start screen.
