Movilizer: Transforming Frustration into Functionality
A Crucial Tool for Public Transport Mechanics
Unless you're elbow-deep in the workings of maintaining Sweden's public transport system, you might not be familiar with Movilizer. Yet, for the mechanics responsible for keeping buses, trains, and trams running smoothly, Movilizer is an indispensable tool. It's their go-to for managing work orders, tracking tasks, and recording measurements.
Or, well, it should be.
When I first laid my eyes on it, though? It was an app that was a constant source of frustration for the mechanics who had to use it in their daily work.
This is the story of how I (& my team of trusty developers) fixed that.
Team
1x Project lead | 1x UI/UX designer (me) | 2x Back-end dev | 3x Front-end dev
Outdated and Outpaced: The Initial State of Movilizer
Since Movilizer was already in use, I began by closely going through and examining the existing solution. Just from a first glance some problems immediately came to light. The app was slow, cumbersome to navigate, and with an out-of-date UI that was hard to decipher; Clearly falling behind in the fast-paced, user-centric world of today. Its lackluster user experience and lack of accessibility stood out as pain-points needing to be addressed.
Taking a look at the content of the existing solution also gave some insight into what the purpose of the old app originally was intended to be. However, it also raised even more questions due to confusing language and lack of user support.
I documented these issues as hypotheses to be validated and explored before proceeding to stakeholder & focus-group workshops and in-context user interviews.
Diving Deep: Understanding the intended role of the existing app
Going into the user research phase, our mission was to not only dissect the existing app's use but to immerse ourselves in the mechanics' world. We aimed to uncover their broader needs and daily challenges. We also wanted to take the temperature of the opinion of the old app.
Our initial phase involved talking to stakeholders involved with the current solution, these were the same people that would conduct training sessions with the mechanics about how to use the existing app. These stakeholders gave us insight into what the intended role of the app was, which was not just to serve as a tool for the mechanics, but as a way for managers to gather data on things like material usage, time spent on tasks and keeping track of wear and tear of vehicle parts. Having this data on hand would help with planning, increasing efficiency, as well as making sure that all needed equipment could be purchased with less need of estimating need.
This also gave us a lot of insight into the language used in the industry. A lot of the words were very specific to the industry, and getting an understanding for it helped not only for me in correctly identifying work tasks, but also understanding what was essential for the user to keep and where clarification could be provided.
Mapping out features and functionality of the old solution in Miro
Research in Context: Immersing in the Mechanics' Environment
We (me and an assisting designer specifically brought in to help taking notes in interviews) stepped into the mechanics' shoes, spending time at their workshops. During the course of 3 days, we visited 3 different workshops for buses, trains and trams. Here we got the opportunity to get an understanding of the work that was carried out in these workshops, and to get better acquainted with the people that worked in them. We engaged with 16 individuals across various roles, gathering rich qualitative data. Their insights were instrumental in understanding their needs and desires for the app, as well as the pain points with the old one.
This firsthand experience was crucial for grasping their workflow, challenges, and how they coped with the app's limitations.
Afterward we transcribed the interviews and compared notes. We then had a workshop where we transferred the insights to post-its in miro and conducted a thematic analysis where we clustered the different insights.
Eureka Moments: Research Insights
Our findings were illuminating. Some Pain Points we identified:
Speed and Efficiency
The app's sluggishness was a major hurdle.
Navigation and Clarity
The interface was unintuitive, with obscure language and visuals.
Accessibility Issues
Difficulty in reading and following tasks was a common complaint. As was finding instructions.
Inefficient Task Logging
The cumbersome process of logging tasks, with its confusing process, led to redundant work, frustrating users. In one workshop, mechanics had taken to entering their measurements on the desktop.
Lack of Enjoyment
The app wasn't just hard to use; it wasn't enjoyable either. It frustrated people to the point of finding alternative routes, just so they wouldn’t have to use it until they absolutely had to.
Training Overload
The company was excessively investing in training due to the app's complexity. This training material was helpful, but mechanics would not have access to it on the workshop floor. Training was also costly and took a considerable amount of time.
Unused digital potential
Visiting the workshops also gave the insight that lots of the allocation of tasks was still done off the digital platform. This had some advantages, as a board is a great visual aid at morning meetings. However, a lot more of the assignments could be given digitally, giving a mechanic better oversight of the jobs-to-be-done and help plan their work.
Daily planning of tasks
Key Insight: Reducing Human Error
I mentioned earlier that even people with good eyesight found the app difficult to use. Then add to the equation that you’re trying to use this app on a small-ish device on a busy workshop floor, with plenty of both visual and auditory distractions. What was the result? Most used pen and paper (or even their own skin).
Not only is this a waste of perfectly good devices and a lost investment for the employer, but the larger issue is that it will cause issues in keeping track of data needed to be input and increasing the margin of human error causing damage to the public transport vehicles or creating unnecessary extra work for the mechanics, with no established standard of keeping track of that data.
“If you jot it [measurements] down on your hand you might easily lose it if you wash your hands, or maybe you lose a piece of paper you wrote it on, and need to retake all the measurements. Or you misread a hastily scribbled 0 as a 6 and input the wrong measurement in the app. It's not ideal.”
— Anton
Tram mechanic
Mechanics scribbled on their hands rather than using the digital solution
This was an important insight for the mechanics, the business and all users of public transport as this “workaround” of the current solution could have the consequence of causing unnecessary wear and tear on equipment, or even failure of expensive public transport vehicles. It could even cause important gear such as brakes to fail, which could lead to damages or, worst-case, serious injuries or casualties.
Early explorations & determining a solution
When we looked at our user group for this project, we identified that our user group was highly specialized and homogenous. This got us thinking: would traditional personas actually help us here? Typically, personas serve as a tool to encapsulate and empathize with diverse user needs and behaviors. However, considering the specificity and uniformity of our user base, we anticipated that the creation of personas would not add this intended value.
So, we decided to take a different route. We shifted our focus towards a more nuanced understanding of the roles and tasks in the user interaction with the application. This way, we could focus on what mattered most: creating a user experience finely tuned to the operational and functional needs of the mechanics.
This switch from thinking about personas to focusing on roles and tasks really made our design process more straightforward. It meant we could spend our energy on tweaking the app to fit exactly what our users needed to do, without getting sidetracked. By tailoring our approach, we ended up with a product that felt like it was custom-made for our user group, which was a great fit for this specific project.
We also developed a comprehensive systems map of the existing app's functionalities, and a separate map of the functionalities and requirements identified in the early exploration stage for the new solution.
Low-Fidelity Prototyping: A Glimpse into the Future
Next, we crafted low-fidelity prototypes, focusing on refining the app's features, later iterations focused on the app’s look and feel and creating a clickable version for testing purposes. With this we conducted early user testing consisting of semi-structured interviews and letting the user navigate the prototypes while thinking aloud in order to gather feedback on their experience.
Early-ish sketches of solution
Refined Testing: Aligning with Real-World Tasks
We conducted multiple sessions with a focus group consisting of five users and two business stakeholders, aligning the app's features with the mechanics' actual work tasks and the business´ needs. This process proved easier to do with interactive prototypes, as it was easier for the users to connect the dots with the use of a device and a clickable prototype, rather than showing individual screens which would often disorient the users due to lack of context and the prototype not meeting their mental model or expectations.
Interactive prototypes were constructed for user validation
Iterative Development: Fine-Tuning for Excellence
The development phase was iterative, involving continuous testing and refinement. We ensured the app was compliant with established Android design standards/patterns and optimized the app for various devices, including Zebra which was the kind of device accessible to the mechanics, but with keeping future scalability in mind.
High-fidelity flows for development, complete with comments and arrows
The Final Outcome: A Resounding Success
The revamped Movilizer was met with great reviews. It stood out for its ease of use. Mechanics found the app both more efficient and user-friendly.
Later feedback from business stakeholders also told us that the new app had significantly reduced, or rather eliminated, the need for training. The users were able to use the app intuitively without training, saving the users frustration and saving VR having to spend resources on extensive training sessions.
We did not have any metric of how much we had managed to reduce human error - but we could confirm based on the final qualitative interviews we conducted that the app was considered far easier to use in daily work on the workshop floor and reduced the need for “work arounds” like taking notes on the back of your hand.
Accessibility
Although we wished to explore designs accommodating various disabilities, the physical demands of the job limited our focus to addressing the primary disability identified in our user research, mainly that older and/or visually impaired users had trouble navigating the old app.
It was monochrome, messy and hard to both read and navigate, it was difficult for even users with good eyesight to differentiate between visual elements and navigating the app. Not ideal.
To address this we made sure that we established a clear visual hierarchy in the design. The colours were chosen with minimum AA, but with the majority of the app meeting AAA WCAG 2.2 standards. We also took into account font-size, clear labels and copy as well as avoiding designing a cluttered UI.
Learning: Communication
While writing this case study I realized I skipped over a pretty big hurdle we had: getting the decision-makers on board to actually let us meet with the users was tougher than we anticipated. There was this gap in understanding about how product development works. We kept running into “We’ve told you what we want, just build it!”. It seemed like the idea of why we were chatting with users or tweaking things along the way didn’t really 'click' with them.
In any project, but especially this one, it's all about showing why these steps matter. Not only can they save lots of time and resources in the long run, but they also make sure we’re on the path to the right solution. This project was a classic example. We did end up working well together, but I can’t help wishing we had built a solid trust foundation a bit earlier.
It reaffirmed that very important lesson I've run into many times throughout my career:
Never assume.
In this case, it was easy to head into the project thinking everyone’s on the same page about what digital product development looks like. I think a bit more of an alignment of expectations upfront, diving into the nitty-gritty of why we do what we do and why each step is important, could have bridged that understanding gap sooner. When you’re deep into this way of working every day, it’s easy to forget it might not be so obvious to everyone else.
