From Road to App: Exploring the Intersection of User Experience in a Moped-Sharing Service
Remember the days when experiences were purely physical — renting movies, ordering pizza, or booking a doctor’s appointment? It’s funny how our instinct to get any of these things done now is to grab our phones and open an app. Almost every single service is supported by an app and a big part of our everyday life is ruled by how well-designed our screens are. This is why when we talk user experience, we tend to think about the digital first. But take any journey from end to end: it will always include both digital and physical interactions. UX discussions don’t mention enough how the screens we design will connect to and sometimes clash with human actions that follow. We obsess over screen flows or where to put clickable buttons but what about the moments when the user glances away from their screen, or pick their phone up again for a quick check? And how do we consider the way the environment might affect their experience? (see situational disabilities to understand how context impact someone’s experience).
I work at Cityscoot — a French free-floating e-moped company — as a User Researcher. I had never worked with IoTs before and this interconnexion between physical and digital throughout the user journey had never been so strongly at the forefront of my work. Over the past year, every research project I’ve tackled has highlighted how these two elements lean on each other and it’s transformed the way I treat the feedback I receive and run my tests. It’s made me reflect on how to create a seamless experience for a flow that goes back and forth between the app and the moped itself.
To trust or not to trust the user: the dual nature of feedback
Since I started working as a user researcher, the one thing I was repeatedly told was: “We’re not the experts, users are!” A grounding reminder of who we design services for. Yet, this doesn’t imply that we should unquestioningly accept every word they say. Users are indeed experts, but their expertise lies primarily in themselves. They bring a unique understanding of
- how they interact with our service (usability)
- how it makes them feel (emotions)
These aspects are our primary focus when we seek feedback, anything beyond these dimensions should be approached with caution, users can make assumptions too!
My scope at Cityscoot was clear, I was to join the mobile app team. Just as I always had in the past, I started with getting to know our users and hearing their thoughts about the app. Very early on, I realised that none of the feedback was about the app only. As a moped-sharing service, the app acts as an enabler, it unlocks the service but a big part of the experience remains in the real world. So how do you make sense of what your users are going through, or more precisely, what they claim they are going through?
The “front stage” part of the service blueprint (blue and yellow in the image above) shows all the physical and digital interactions the users need to go through to access the service. They can be digital (book a moped in advance, take a picture at the end of the rental), physical (start the moped, get the helmet out of the case), or both (unlock/lock the moped). Identify where the pain points come from at each of these steps can be quite challenging.
A Cityscoot example - When the user becomes a mechanic
“I will never use this service again. The moped didn’t start, it is obviously broken and should be taken to the garage.”
Let’s break down this feedback:
- I will never use this service again. ️Intent ✔ → I can trust the user about how they feel.
- The moped didn’t start. Observation ✔ → I can trust the user about what happened.
- It is obviously broken and should be taken to the garage. Assumption ❌ → This requires more careful consideration. While it’s easy to assume that a moped that doesn’t start is broken, we’ve learned from past feedback that the issue isn’t always a mechanical one. One counter-intuitive element on the moped is that if the button on the handlebar is already switched to the ON position, it requires the user to toggle it back to “OFF” and then back to “ON” again to start. In cases like these, we need to delve deeper into the user’s experience: is the user a first-timer and does this moped have a history of being malfunctioning?
One of the questions I ask myself a lot is Is it because of the app or the moped? When looking at feedbacks, having additional context is crucial for distinguishing between perceived mechanical problems and usability issues. It’s one thing to discover our app isn’t intuitive but another to discover one of our moped could potentially be unsafe to ride.
Testing or roleplaying? Usability tests and the importance of “real life” conditions
At least, the advantage with immediate feedback is that it’s true to the user’s real experience. In usability tests, however, we build a scenario and ask them to imagine themselves in specific situations. The feedback is inevitably influenced by the design of the test: the format, defined tasks, goals and observation choices.
I have extensive experience in testing apps with users. I’ve talked to hundreds of people on the street, a lab or through a virtual platform, tested both low and high-fidelity prototypes, even once had someone’s ferret crash a session. Usability tests are a tricky balance between the reliability of a live product observation, and the real-world behaviour of users outside the test setting. When the journey you test is fully digital, finding this balance and being aware of the biases it induces is already pretty challenging, but when the journey goes back and forth between the app and the hardware, there are a lot more factors that can impact the validity of what we see.
A Cityscoot example - Test scenario: “hmm… imagine you kinda teleported here”
Not really but almost.
Let’s say we want to test the series of screens that shows up when a user ends a rental (1. End rental — 2. Take picture — 3. Rate ride — 4. Add comment)
When defining a task, it’s essential to outline the specific part of the journey it covers. Unlike purely digital tests where the starting point might be as straightforward as engaging with the first wireframe of a prototype, the scenario is more complex when merging the digital and physical aspects of the user journey.
For instance, imagine a scenario where a user has just completed a Cityscoot ride to get home from work. The straightforward approach might be to begin the observation at the point where the user interacts with the first wireframe which would be “Finish rental”. But in reality, the actions leading up to this stage — such as parking the scooter correctly, returning the helmet, or closing the saddle — can significantly influence this interaction. Failing to meet the necessary conditions, like properly putting back the helmet in the saddle, may result in an error screen. It becomes essential to understand how the user physically concludes their ride and adapt the test accordingly. If a specific condition is unfulfilled, the screen flow isn’t the same.
Because it was important to me to observe how the user would carry out all these little actions, my script was basically:
1. Tell user “You just got back home from the office.”
2. Hand them over the helmet they’re supposed to have worn during their imaginary little trip.
You see the challenge: maintaining the authenticity of the user’s experience. We know that most issues our users encounter during the end of the rental are also due to the context, they’re in a rush for a meeting or to catch a train, they get frustrated more quickly, have less patience or pay less attention. This test is like a make believe game that might misrepresent the real-life behaviour of the user. Should the research instead simulate an entire ride and start at the rental stage to capture a more holistic view? These are the intricacies that demand careful consideration when designing the format of the tests.
Eyes on the road, not on the phone: the app role in a mobility service
Once we’ve uncovered pain points in the journey, there’s an important question we need to ask ourselves before trying to solve them. It’s not only a matter of tweaking the design and content to improve intuitiveness, it’s determining whether the app itself is the right platform to increase user satisfaction.
In the context of a primarily physical service like moped rental, the innovation lies in the sharing, which is what can be supported by the app. However, the fundamental user need that Cityscoot as a service satisfies is still ultimately moving from point A to point B. This is a great part of the journey that isn’t tied to an app. “Sharing” serves as an access to this core service, positioning the app as an assistant, or an enabler, rather than the service itself. The app should only intervene when it’s needed, not be the default tool to navigate through the entire journey.
However, as we’re stating that enhancing the digital part might not be the best solution in this kind of hybrid journey, another issue arises: how do we maintain coherence when pushing users to toggle between digital and physical?
A Cityscoot example - The keyboard great debate
Cityscoot has tremendously changed the mobility landscape in Paris as it was a pioneer in the electric moped-sharing industry. And as the first of its kind, everything had to be built in-house, including the main character: the moped. There was no app to be created around a connected object, the object had to be made “connectable” to an also homemade tech system. Ending a rental through the app might seem to be a no-brainer now, but this wasn’t how it used to work with Cityscoot. Many actions could be done through the moped directly, and namely, the finish of the rental. Previously, users could only tap the “END” button on the moped’s keyboard.
Introducing the option to terminate this process via the app was logical but came in later. However, this gave us a differentiating element: two distinct ways of ending the rental, one physical and one digital. In today’s tech-driven world, prioritising the app would be the first choice, but offering two alternatives made us realise that each path had its own set of advantages depending on the context and the environment the user is in. But if a process constantly demands to switch between the phone and the moped, how do we make it to be seamless and intuitive? Or should we prioritise digital approaches even in physical experiences? These reflections are the reason why there’s still an ongoing discussion on the subject. (In the Cityscoot language, this would translate as should we ban the END button and stick to the app? Historic users love it but new users are confused).
This is especially complex when talking about an experience that will always be, by essence, physical, like the action of using a moped to move around the city.
User feedback, usability tests, mobile-first strategy, these are all some very specific challenges I had to tackle while working as a user researcher for the mobility industry. Where the tangible meets the digital, we need to rethink our approach at every phase of our work to make sure that the intricate and sometimes blurred boundaries between both worlds are thoughtfully considered.
