Scaling shared mobility software – Part 2: UX and operational challenges

We continue to analyse the process of scaling shared mobility software. In Part 1 of our series, we focused on technical and architectural aspects. In Part 2, the final article, we shift to UX and operational challenges: from creating a seamless user app experience to admin tools and expansion into new regions. 

We hope you’ll find these insights practical.

UX design needs to evolve as the user and fleet size grow

As the fleet grows and user numbers increase, shared mobility customers often face not only backend issues but also interface-related challenges. Without proper UX optimisation, maps can quickly get cluttered with markers, mobile app performance may degrade, and users might not know whether unlocking is just slow – or hasn’t worked at all.

Maxim Leykin, PhD, Chief Technology Officer at Bamboo Apps:

Building on Maxim’s recommendations, AWS guidelines, and shared mobility best practices, let’s take a closer look at key UI/UX challenges and how to solve them.

Reducing map clutter and simplifying vehicle discovery

The challenge: as fleet sizes grow and vehicle density increases, maps can become visually overloaded. This makes it harder for users to quickly find a vehicle or interpret different route zones, leading to a slower and more frustrating experience.

Possible solutions:

• visual clustering: grouping nearby vehicles into clusters to reduce map clutter and improve readability at different zoom levels;

• heatmap overlays: using colour-coded indicators to show vehicle density and help users locate available options more efficiently;
• dynamic filtering and prioritisation: hiding irrelevant vehicles based on route selection, vehicle type, battery level, or service zone;
• customisable filtering: allowing users to set personal preferences to hide irrelevant objects and options.

Handling latency

The challenge: peak loads or unstable connectivity in dense urban areas can lead to a “frozen” UI and a noticeably poorer user experience.

Possible solutions:

• app startup warnings: when delays are expected (e.g., due to high server load), users should be informed upfront at launch;
• clear waiting state indicators: using animations and progress indicators supported by meaningful messages (e.g., “Unlocking may take up to 10 seconds”);
• alternative flows in case of delays: retry, select another vehicle, end the trip manually, or contact support.

Optimising the in-ride experience

The challenge: during a trip, users often miss important alerts about key events, such as approaching service zone boundaries, speed limits, or low battery warnings. This can lead to stress or unexpected charges.

Possible solutions:

• distraction reduction: only essential trip data should remain visible on screen (time, fare, battery level, etc.);
• notification prioritisation: low-priority alerts appear as subtle, non-dismissible banners that fade automatically, drawing the user’s attention without disrupting the ride. High-priority messages are more prominent and may trigger push notifications;
• proactive alerts: users receive early warnings about approaching service zone boundaries, speed restrictions, no-parking zones, or low battery levels, accompanied by vibration signals.

Harvard students applied a similar approach in a campus shuttle app redesign, adding proactive alerts to help reduce stress linked to missing a stop.

AWS best practice guidelines also highlight the value of real-time feedback and proactive communication to improve user experience.

Operating without a signal or vehicle response

The challenge: losing connection during a ride can leave users uncertain whether the session ended, if they’ll face billing errors, and if the vehicle is available for others.

Possible solutions:

• connection loss alerts: displaying a prominent visual indicator combined with push notification;
• offline fallback UI: showing the last known ride state with clear action indicators and a message explaining that updates will sync once the connection is restored;
• offline critical alerts: geo-based warnings for restricted or paid zones work without connectivity using cached data;
• emergency end-trip option: if available offline, this should be visually prioritised with a larger size and contrasting colour;
• confirmed ride status on reconnect: automatically updating trip progress and payment details, with clear feedback (e.g., “Trip successfully ended”) and a push notification;
• bonus data preservation: bonus parking areas, SwapSpots, and other incentives are visible during signal loss for informed decision-making.

Tier app UI upgrade: redesigning for predictability and clarity

A practical example of how some of these principles can be applied comes from a graduation project at the Ironhack bootcamp in Berlin. The project covered the whole UX process, from contextual research to prototype testing.

As part of their research, the designers were given access to wireframes from Tier’s internal UX team and compared them with over 200 screenshots from competitor apps and user reviews. They also conducted a series of surveys and interviews. What became clear was that the challenge wasn’t just about visual design, but about creating more predictable, consistent behaviour across different usage scenarios:

• before the ride, users couldn’t see relevant information about service zones on the map and weren’t sure whether the battery charge would be enough for their planned route;
• during the ride, the main issues were the lack of timely alerts for restricted zones and sudden battery drain without any warning;
• after the ride, many users said they were missing key details about parking and rewards, and that fare calculations lacked transparency.

As Tier updated its navigation and addressed some of the pre-ride information issues, the project team shifted their main focus to the ride and its completion.

As a result, the designers created a system of banners and push notifications divided into two levels of urgency:

• subtle, unobtrusive messages for restricted zones;
• bright, unmissable alerts for leaving the service area or running low on battery.

New ways to introduce tips and bonus information were suggested – not through endless slides shown during first use but gradually, as users got to know the app.

To address complaints about unclear fares, the team tested alternative pricing displays to improve clarity.

The prototypes were tested in near-real conditions: participants were asked to imagine they were riding a scooter while screens and notifications were shown to them in rapid succession. Their reactions and next steps were carefully observed.

Among other findings, the testing confirmed that: 

• bright red banners for critical events are significantly easier to notice while riding;
• low-priority signals don’t disrupt the ride but still remain visible;
• users respond more calmly to negative scenarios when the interface explains what’s happening and offers an alternative;
• excessive or duplicated notifications quickly become annoying – beyond prioritisation, they should be consolidated and finely tuned;
• users want to see information that’s relevant to them in the moment;
• users are only interested in bonus offers at the end of the ride if they’re truly relevant (e.g., “Bonus parking available 150 metres away”);
• users want to understand how their fare was calculated clearly.

This experience led to the conclusion that, as a shared mobility service scales and becomes more complex, its UX design must inevitably adapt. That means simplifying visual scenarios, ensuring consistent feedback transparency, and making the interface more predictable in every possible situation. At the same time, the design should also support operators in managing growing system complexity – a topic we’ll return to later.

Scaling across regions requires adaptable, rules-driven platforms

Expanding into new regional or global markets in shared mobility is rarely just about localisation or currency tweaks. Behind the scenes are thousands of evolving rules and operational details, from parking zones and service restrictions to helmet laws. Such requirements can vary not only between countries but even from city to city, and they often change. Staying compliant means constant monitoring and quick adaptation.

All of this results in a considerable operational burden for the business – and a significant technical one for the product, spanning architecture, UI/UX, and hardware.

Maxim Leykin, PhD, Chief Technology Officer at Bamboo Apps:

To address these challenges without compromising user or operator experience, companies need a modular and intelligent shared mobility technology platform with flexible rules for zones, pricing, and service policies.

While many ready-made platforms include built-in multi-region support, they rarely provide complete control over business rule configuration or integration with local APIs. Custom-built solutions, though more demanding, offer the flexibility to tailor every component – from zoning logic to pricing rules – to the specific needs of each market.

Drawing on the AWS Connected Mobility Lens, the Middleware ’24 study mentioned above, and insights from our CTO, Maxim Leykin, we’ve identified the following key principles for designing platforms with multi-region scalability in mind:

• rule-based business logic, not hardcoded dependencies. All service zones, pricing, taxes, and compliance checks should be defined as configurable policies stored in a database – not embedded directly in the code. This way, business logic can be updated in real time, without code changes or redeployments;
• real-time geofencing and configuration updates. The platform should support remote updates to rules and configurations across regions. For example, new parking zones or speed limits should be synchronised in real time, without requiring app updates;
• regional isolation of data and services. As highlighted in Middleware 2024, a multi-cluster architecture with event-based business synchronisation helps prevent cascading failures. If one market becomes overloaded, it won’t affect others;
• regional admin panels and RBAC. Operators and moderators should only interact with data relevant to their region. AWS recommends distributed admin interfaces with zonal filtering and fine-grained, rule-based access control;
• flexible API integration with local systems and services. Using API gateways and abstraction layers for payments, identity verification, and regulatory systems makes it easier to enter new markets and reduces the need to modify the platform core.

Maxim Leykin, PhD, Chief Technology Officer at Bamboo Apps:

Scaling operations through smarter dashboards and control

As fleets grow and service areas expand, the pressure rises not only on backend systems but also on fleet operations teams. Clunky admin panels, limited remote access and analytics, and the lack of scalable tools for multi-location management can block even a well-built shared mobility management solution platform.

To stay effective at scale, mobility operators need a platform that offers advanced filtering, anomaly detection, and override capabilities – all accessible through intuitive dashboards that can handle city-wide or multi-region data in real time.

Moreover, high-scale operations require close, well-aligned integration between software and business processes: from granular fleet control to performance metrics, SLA tracking, and proactive incident management.

Having explored backend and data infrastructure principles earlier, we’ll now shift our focus to operational frontends and monitoring. Based on AWS guidelines, industry best practices, and insights from Bamboo Apps’ CTO, Maxim Leykin, we’ve identified several practical recommendations for designing admin panels and managing operations.

We’ve grouped them into main focus areas.

Recommendations for dashboard design and operational management

User-oriented interface:

• study the needs of operators, managers, and analysts to tailor the functionality to their specific tasks;
• use clear, consistent layouts, naming conventions, and a microfrontend approach to simplify panel updates and future development.

Operational security and isolation:

• enable role- and region-specific views and actions to keep admin panels focused and secure;
• set up alerts for potential threats (e.g., suspicious admin activity, repeated access attempts), based on real use cases and security indicators.

Data prioritisation and update frequency:

• highlight key metrics (e.g., SLA, vehicle availability, zone-level KPIs) without overloading the interface with secondary data;
• set different update intervals: critical incidents and metrics should refresh in real time, while financial summaries and reports can update less frequently;
• use predictive alerts for upcoming events that require operator attention.

Clear visualisation and interactivity:

• choose visual formats that best fit your data. We would recommend:

– line charts for time series;

– histograms for distribution;

– maps with filters for geospatial data;

• implement filters by region and time, drill down to specific vehicles or incidents, and dynamically show/hide map data layers;
• integrate real-time geofencing and heatmaps for effective monitoring of service zones and fleet conditions;

• allow manual placement of event and vehicle markers or zones on the map (e.g., incidents, area overloads).

Anomaly detection and critical alerts:

• implement real-time anomaly alerts and emergency triggers based on predefined performance metrics and operational traces;
• reduce alert noise through clustering and prioritisation: group similar events or events within the same region into a single summary notification.

Maxim Leykin, PhD, Chief Technology Officer at Bamboo Apps:

Cost and load optimisation:

• enable monitoring of aggregate infrastructure costs and performance metrics. Regional and service-type loads must be visible in a single view to detect inefficiencies early and optimise resource use.

End-to-end visibility of requests and transactions:

• operators should be able to track the full trip management lifecycle of any request or transaction across all platform components;
• enable log auditing and regular review of business metrics to ensure ongoing relevance and accuracy.

Emergency intervention and communication:

• built-in tools for remotely ending a ride or disabling a device must be reliable, intuitive, and easily accessible at all times;
• each intervention should be clearly visualised, showing the device ID and the responsible operator;

• ensure reliable multi-channel communication with dispatchers and users via push notifications, SMS, or email in case of emergencies or incidents.

Together, these practices form the backbone of a shared mobility management solution platform – one built for scalable, secure, and responsive operations across fleets and regions.

Conclusion

Bottom line: scaling shared mobility software isn’t just about more servers, smarter IoT, or launching a new app. These things help, but they won’t make a real difference if the core architecture is still MVP-oriented and doesn’t account for the full spectrum of scaling risks. If a system isn’t flexible, resilient to failure, or able to redistribute load, scaling will almost always require a more profound transformation. At the same time, as shown in this article and broader practice, most failures don’t happen inside components – they occur at the seams: between modules, interfaces, and external providers.

The answer lies in platform thinking – designing the digital ecosystem as a cohesive, interconnected whole at the level of architecture, data, and interfaces.

It’s built around several key approaches, including:

• event-driven architecture with asynchronous data exchange;
• end-to-end observability – from IoT to UI, with full transaction tracing;
• configurable business logic that doesn’t require constant code changes;
• adaptive UX designed for on-the-go use, unstable connectivity, and peak loads;
• operator-focused, well-tuned admin panels that provide fast access to critical insights and actions.

At the same time, the architecture of a scalable shared mobility technology platform should adhere to four resilience principles:

• distributed-first: monolithic systems have scaling limits and don’t grow linearly. Horizontal scaling with modular microservices and intelligent load balancing is essential;
• offline-first: critical features, such as unlocking or ending a ride, must work locally and sync data when a connection is available, rather than relying on real-time connectivity;
• eventual consistency: constant synchronisation between the client and IoT devices is unrealistic. The system should be resilient to temporary desynchronisation and include compensation mechanisms;
• predictiveness and security: the system should be able to forecast load spikes and potential attacks, with protocols in place to respond proactively.

That’s why custom-built solutions are often a better fit for scaling than off-the-shelf SaaS platforms. While the latter work well at the MVP stage or for quick market entry, they rarely handle the demands of a mature product. Custom architecture not only supports growth but also helps anticipate limitations before they become bottlenecks.

Ultimately, a well-architected shared mobility platform is also an investment in the future of urban mobility. Only adaptable platforms will stay relevant as technologies, infrastructure, and new vehicle sharing models evolve. Consequently, the technical foundation laid today will define a service provider’s ability to scale, integrate, and lead in tomorrow’s mobility landscape.

For mobility providers seeking a technology foundation that can grow with their business, Bamboo Apps offers a trusted partnership. The team designs and scales platforms that grow without compromising quality, resilience, or user experience – from backend architecture to frontend interfaces.

Book a consultation to discover how Bamboo Apps can help you build a shared mobility technology platform for scalable, reliable operations and a seamless user experience.