In the last months automotive world is talking a lot about autonomous and self-driving vehicles both for private and public transportation. During my day researches one day I found the exciting call for collaboration for Olli, the self-driving vehicle produced by Local Motors.
Designing the autonomous bus user experience is a complex task: for first because self-driving buses will serve the traditional public transportation diversified and multi-age target; second because without the driver and, in some cases, without a fixed route, passengers will have some new functional and informational needs.
The first part of my project started with a Service Design session focused on what kind of transportation services a self-driving bus can serve.
Personal on-demand shuttle
It’s like a Taxi/Uber, but less exclusive and more spacious. It brings one or more people from A to B. It can be reserved days in advance and can make various stops during a single dedicated service. The served area is restricted.
Shared on-demand shuttle
It’s like public transport service except for the fact that passengers can add a personalized stop to the route within the bus pertaining area. The route is dynamically optimized depending on users destinations and pick-up calls. The high level of complexity makes this service ideal for closed areas like small districts, big companies, entertainment parks etc.
It’s exactly the same public transport service as we know it.
It’s like sending objects using a shipping company, but instead of giving the package to a human, users will schedule the shipment using an app or a dedicated device in the bus, and then they store the package in a secured housing inside the vehicle. The recipient will track the shipment in real-time and will be alerted when the bus is at the delivery point (or in front of his door). This service can be added to the “Shared on-demand shuttle” one, or it can be configured as an automated delivery service with customized buses and dedicated physical hubs.
This delivery service model is useful for companies that need to transport small parts within a relatively big space, or in modern cities creating a sort of fully automated shipping/delivery hubs for connecting wholesale shops and retails stores.
After this first Service Design session, I started a User Centered Analysis focused on the self-driving bus passengers needs. For designing a real accessible service, I defined only “analogue” needs excluding all the information/functions that a smartphone app could have. What you read is what my grandmother or a manager with a dead smartphone could need for using an autonomous bus.
What self-driving bus passengers need outside the bus
– Passengers need a purchase and reservation system that should be both digital (app), physical (street’s stops signs) and gestural (raising the hand for asking to catch the bus).
– Passengers need to know the destination area first to catch the bus.
– Passengers need to know from distance the service availability and if it have free space.
Here a led lights solution based on the Olli’s exterior design. The lateral lights are designed for the day-light; the lower lights are designed for the night service and the light pollution reduction.
What self-driving bus passengers need inside the bus
– Passengers need to see and interact effectively with all the informational/interactive devices inside the bus.
Here an example of the informational screen and the touch tablets positioning. The screen is above the entrance door; the tablets (red) are designed and positioned for being used from almost all the seats and from the entering passengers first to sitting down.
– Passengers need to know their position, the bus itinerary, the next and previous stops and the arrival time.
Here the animated prototype of an informational screen with more contents than usual for compensating the driver’s absence. The screen must be accompanied by vocal announcements.
– Passengers should have the opportunity to select/reserve their destination and validate their tickets/travel cards using some dedicated devices.
Here two animated prototypes of the validation/reservation device. On the right there’s the area dedicated to the NFC or swiping validation. The rest of the device is a touch tablet where the informational screen’s contents are interactive. The most important function of this interface is the fast reservation process that in the following animation is based on the “Shared on-demand” service model (described before). On these prototypes a passenger can reserve his destination choosing from a geographical area (first animation) or a Point of Interest (second animation) in three taps, letting then the system to choose the most convenient route and the exact stop’s location.
– Passengers should have a fast and easy way to contact the human assistance, for example via interphone.
– Passengers should have a dedicated storage space for putting away abandoned objects.
This small project gave me really a lot of fun. Obviously during the design I had the desire to work even on the Control Room System, but it couldn’t be possible because I don’t really know the Olli’s technologies.
As a Product Manager I’m satisfied enough of this post and I hope that it could be useful for all the companies that are working on the self-driving vehicles communication systems.
For any kind of information, feel free to contact me.
After that I posted all this content on the Local Motors co-creation sit, Jonathan Garrett told me that they are facing the overcrowding problem. Following I paste a part of my answer because it could be useful for all the self-driving vehicles designers.
I admit that first to post my article I deleted everything I wrote about the Control Room because I didn’t know what kind of control systems you already have.
During my analysis indeed I found that Olli’s Control Room had to have the following:
– a system to avoid bus overcrowding
– a system to avoid evasion
– a system that monitor the vehicle hygiene and vandalism
I’m not an engineer. I’m a digital expert that uses a “technical imagination” for finding solutions that, at last, someone else must build or code. This means that I can’t really produce nothing, but that I can search for solution in a real open way.
That said, I’ve some creative solutions for you.
For the overcrowding you could use a weight sensor that alerts the control room when the established limit is passed. In this case a the Control Room should activate a cam inside the bus and talk directly with the people inside Olli.
For the evasion a similar system could be used, but the algorithm should be a bit different because it should match the ticket/travel cards validation with the weight variations. Considering the Olli’s dimension all the new passengers should have the time to validate and sit (I positioned the tablets thinking about this), but considering the hypothetical short time of use, there’s an high evasion risk. So the evasion system couldn’t be sensible like the overcrowding one, but it could have two steps of intervention. At first Olli could simply say something like “Hey someone forgot to validate the ticket” and if nothing happen, the Control Room activate a cam inside the bus and talk directly with the people inside Olli. For identifying the evader the Control Room could watch the recorded video and finding him/her. What to do then, I don’t know, but I hope that knowing that Olli have a heavy anti-evasion system could be enough to discourage that kind of people.