Shelter App, Tier operations
Tier is currently the leading micro-mobility company in Europe, already serving more than 100 cities across Europe and the Middle East, and expanding rapidly.
All maintenance and repairs are handled
in-house, so we rely on our own mechanics working in all the cities where Tier is present. Tier mechanics are using the Shelter App on a daily basis.
Shelter app
The main purpose of this app is to record all damages and symptoms of vehicles entering the warehouse, and eventually to mark the damages as fixed and allow the vehicles to be deployed by Rangers back to the city.
Shelter App it’s also tracking the repairs per mechanic per day, including the hard fixes and the easy ones, plus it informs about the periodical maintenance on the vehicles.
It also allows some action, such as unlocking or ringing the bell and ejecting the battery.
There are also other functionalities, as the update of the spare parts QR code, and the front fork ID.
Goal and project
At the beginning of the project I interviewed our stakeholders to understand their objective.
In the current situation they can see when a vehicle enters and leaves the warehouse, but they do not have a full understanding of what is happening inside the warehouse. For example, if a vehicle remains in the warehouse for a long period of time, they do not understand why the vehicle is stopped.
Discovery and research
To understand how mechanics handle repairs, I visited different warehouses: Berlin, Stockholm, Lathi and Helsinki.
I chose these four because each has different characteristics. Berlin is the biggest one with the largest fleet, Stockholm has the best numbers because it has the lowest percentage of out-of-service vehicles, Lathi is a very tiny warehouse with only 2 mechanics and Helsinki has one of the highest percentages of inactive vehicles stuck in the warehouse.
My goals: to find out what they have in common and define the differences between them, plus to discover and understand their workflow.
Highlights
During the first two weeks, I travelled to the four cities and interviewed sixteen mechanics, gathering various information on their demographics, motivation, objectives and pain points. This information allowed me to define my User and empathize with them.
Regarding their workflow, I was able to define their modus operandi in 3 main phases: diagnosis, repair, final inspection with distribution. The Shelter App is used at the beginning to scan the vehicles as they arrive from the city and mark the damage. It is then reopened at the end to mark the vehicles as repaired. The health check is not present on the App, but it is a step they always do to check that the vehicle is working. Usually the mechanics drive the vehicle for a short trip in order to verify that the vehicle is safe and healthy.If everything is in order, the vehicle will be marked on the Shelter App as Ready to Deploy.
Workflow definition
After interviewing the mechanics, I reconstructed the entire path of a vehicle entering the warehouse highlighting the actions that are done offline and those marked on the Shelter App. As you c an see from the flowchart below, the App is used at first to register the vehicle and add damage, then at the end to mark the damage as resolved and trigger the deployment action.
If a vehicle has to wait due to lack of parts, or a complicated repair, this information is not visible through the App. It is also not possible to have an understanding of the time spent by the vehicle at each stage of maintenance or when it is sitting idle waiting.
Ideation
In the warehouse there is no visibility of the various repair processes followed by the mechanics, moreover you can only see when the vehicle goes in and when it comes out. If the vehicle has to wait due to lack of spare parts or other reasons, this type of information is not visible.
How can we make more visible all the maintenance processes — including holdups and slowdowns — performed in the warehouse?
After several workshops that I facilitated, in which I had stakeholders, team members, and mechanics participate, we came up with a basic idea: the task-based system.
Following the existing repair flow, we decided to adapt the App to the 3 main phases, and allowing mechanics to start and close the different tasks and also communicate through the App when a vehicle cannot be repaired.
Diagnose
Repair
Health Check
User Flow
Test and conclusion
I conducted these tests using Maze.com and interviewing the mechanics about their impressions in using the App. The first thing I had to improve was the ergonomics of some of the buttons; the “ring”, “eject battery”, “unlock” and the “start repair” and “resume repair” actions located at the top of the screen were creating the annoying thumb-stretching experience, which I really want to avoid since they use the App most of the time in one hand and other tools [drill, hammer etc.] in the other hand.
I also changed some text to make it less “intimidating”. For example, I received this feedback from a mechanic:”I press on confirm: so am I responsible for this? Do you confirm? It means that TIER is not taking responsibility for the action but it’s mine. So I would never click on that button in order to aviod risks”.
Certainly, making mechanics suspicious is not my goal, so I switched to a more aseptic text, that wouldn’t make them fear for their actions.
In addition, mechanics highly appreciated some features such as “No Damage” as it reduces manual reporting work. In addition, The task of health check was seamless, however, users asked if it is possible to activate the damage while reporting the failure.
