Design the back office application that helps SIXT staff process the cars on offer as efficient as possible
SIXT is broadening its portfolio by launching a community platform for customer-to-customer car rentals. Ride my Auto provides people with an online marketplace that facilitates the renting of privately owned vehicles.
All car offers that are uploaded by the community will run through a lean, but manual, review process. During the pilot phase of the project, selected SIXT employees will take care of this task in addition to their usual assignments.
Goals & Objectives
1. Design a back office software application, with this tool, our colleagues should be able to evaluate the offers users want to upload to the customer facing platforms.
2. Since the selected employees will have a busy schedule, the focus of the back office application should be on a quick and clear review process.
3. Different countries have different market places. Users review vehicle offers for one country at a time. This country can be switched at any point if another point of sale needs support.
4. Work on the solution within 4 working days.
Key users
Alex works as a manager for the SIXT branch at London Heathrow Airport. He is responsible for 4 different counter locations in he airport as well as the teams in the parking lot. Alex is constantly on the move between these locations. He is able to work on the “Ride my Auto” backlog during train rides between terminals and on his lunch break.
Alex is very enthusiastic about mobile devices like smartphones or tablets and heavily uses all kinds of gadgets on a daily basis.
Regina works as a customer service agent for the SIXT call center in Rostock, Germany. She takes care of 60–70 customer requests per day. In between “rush hour” periods, she completes some reviews for “Ride my Auto” as she can do this while sitting at her desk waiting for the next customer to call.
For Regina, a “digital detox” is important when she is not at work. She does not use her smartphone very much and doesn’t own any other devices like a tablet or smart watch.
Jean works as an intern in e-commerce at the SIXT headquarters in Munich, Germany. While working on delivering various projects on top of trying to both improve his skills and acquire new ones, he should spend about 5–10 hours per week to support in reducing the “Ride by Auto” backlog.
Jean is a very tech savvy guy and is comfortable using social media on his mobile devices to keep up with his friends and uses technology frequently in his personal life. However, this is his first professional experience and he has never used tech or an internal application for business purposes before.
Design process
Empathize with users
To know what they are going through as each user has different and specific daily routines that they need to combine with the task to evaluate the offers from Ride my Auto.
I organized all user information provided and mapped all pains and possible gains for each user, and their touchpoints.
I also built an empathy map to collect what they feel, think, say, and do to create inputs to guide through the ideation process and don't miss what each user demands the solution.
User journey
With this journey map, I can visualize and clarify the user experience and user expectations based on the user's research.
Also, this will help to set up the product manager expectation of what we included on the MVP, to start designing the Backoffice. When the project is more advanced we could do another user journey using other scenarios and specific touchpoints.
Back-office analysis and References
I had already worked with back-office systems, so I did a quick back-office analysis, to get a broad understanding of how each back-office is optimized for the need of the user and how they are arranged.
This analysis also serves to clarify where we could improve about others.
I also recorded interesting patterns and useful resources related to the subject.
I also recorded interesting patterns and useful resources related to the subject.
Sketching
I decided to start working on Alex's use case, which required a mobile solution, as he is the busiest of all the key users and the mobile experience requires more attention since he is reviewing with a lot of distraction (e.g.: commuting on the train) and needs to keep an eye on his progress.
From this point, I started to generate ideas to identify solutions to the challenges and issues we identified in the prior process. I outlined some initial ideas on paper bearing in mind the empathy map and the whole process and steps needed to approve or deny the inclusion of a vehicle.
After finishing the sketches, I hoped to build a few wireframes from the mobile site and later I moved to the Desktop version.
First sketches
Vehicle review process
Dashboard data from all regions
WIth this data all managers will be able to know when the backlog is too big and could invite more people to work on the backlog.
Wire-framing
Dashboard
Make it possible to start the task focused on the region where it most needs, being more efficient.
1. Easy access to data, filtering by time, enabling analysis of new offers for evaluation.
2. Option to view the number of offers in the backlog of each region and access to check which markets need help.
3. Performance indicator by regions, as each employee needs to share their time with everyday tasks and offers review, this data can help managers to invite more employees on demand. Shows data according to the selected region and time filter.
4. Current details of how many offerings were analyzed and their respective status.
5. An analytical chart on the individual performance of each employee, through him the employee can quantify his work reviewing offers, the manager can use this data to estimate how much time is left to complete the review of all offers.
Overall data for all regions available
An analytical chart on the individual performance of each employee
Offers
Allow the user to change the region, the filter offers by status or by waiting time in the backlog queue to start the task quickly.
1. Status filter, in case reviewer needs to re-check or access Open, Accepted, Declined, Rework or Closed offers.
2. Access to different market places. Users review vehicle offers for one country at a time, this country can be switched at any point if another point of sale needs support.
3. Sorting by newest or oldest will help user review offers that are waiting to be reviewed longer, or filter out the newest ones first.
List view
Card view
Vehicle page
The most important area, the goal was to keep information easily accessible with status visibility, good at error prevention providing simple validation, and direct review processes. But also providing the publisher feedback of the status of his offer and for the reviewer a direct and simpler way to select all reasons to justify the status.
1. Anchor links fixed on top to bring a better navigation experience.
2. Publisher's data are pre-checked by API but need to be reviewed by SIXT employee.
3. Call to action to add observation in case there is something wrong with the offer, all reasons listed are related to each part of the offer, so the publisher receive proper feedback.
4. Photos are displayed in a horizontal scroll which makes the navigation easier on the mobile, especially using one hand.
5. Only one click to reprove any of the pictures, in case of accidental click the reviewer can undo the action
6. Every problem the review may find can be reported by adding an observation, which is listed, so the reviewer just needs to select.
7. Save button only enables if any of the reasons are selected, this avoids mistakes to be saved.
8 & 9. The important CTA position was planned to stay between comfort and reachable zone to be reached easily when the user is navigating, considering that 49% of users hold the phone with only one hand.
10. After the reviewer adds any observation, it can be accessed by a fixed button at the bottom, containing a badge indicating how many problems were found.
11. When clicking, a pop-over goes up the screen showing all the listed observations and can already set the offer status and saving, if necessary.
12. The status can be: Accepted, Declined, Rework needed, and Closed. If there are any saved remarks the "Accepted" status will remain deactivated to avoid errors.
For desktop version, it was important to keep as much information visible, as Regina works in between customer's call, so she will probably be interrupted many times, but whenever she return to review she could have an overview of what she have done.
13. Each observation button is close to the content, so the reviewer can see only relevant observation for each part of the offer.
14. All observations added to this offer will be visible on a fixed box, in this "check-out" reviewer can check and remove observations.
15. The status can be: Accepted, Declined, Rework needed, and Closed. If there are any saved remarks the "Accepted" status will remain deactivated to avoid errors.
Prototype
After designing the wire-frames of all key screens I started to build a low fidelity prototype using the User Journey Map and run some usability tests to validate all solutions based on the user's pain points.
User Interface
Dashboard
Offer list
Vehicle to be reviewed
