Olli: self-driving, cognitive electric shuttle

Task: Propose universal interface improvement

Given that the Olli is going to provide a plethora of experiences and opportunities to interact for both occupants and pedestrians, what are the most appropriate solutions for these interfaces points? 

Elements to keep in mind include the following: Many people nowadays own a smartphone capable of running Olli apps, putting the interface in the person’s hand. Additionally, not everyone who rides the Olli will respect the vehicle. Public transportation is not typically the best place to have the most expensive electronics exposed. Not only might it be stolen, but it also may simply be defaced.

  • graphical-user-interface-development
  • user-interface
  • graphic-design

Will you help with this task?

11 people are working on this
Yes, I'll Help
Solutions 12

One big interface button like on an iphone that you have to touch or hold down to get Olli's attention to engage Watson... this can by replicated in many usable locations in one vehicle.


Large scroll-wheel made of anti-bacterial metal that goes down a list of options with audio signalling and reading the entry after a short pause. Buttons optional


Eye tracking
Use a couple of cameras to track occupants eyes. There can be 3-4 signs in distinct locations that read: 

"Explain a little more / Next"
"Talk to me" (visible when you enter cabin).

Combine with speech for: What am I looking at? Allows census/veto with multiple occupants. [You also get boatloads of additional data that way, and it works in a machine shop where everyone has their hands full, hint, hint.]


Software Defined Radio.

Why limit yourself to smartphones and a handful of standards? Just take everything from 100 kHz to 3.8 GHz. Kudos go to a friend who pushed my nose into this: https://www.crowdsupply.com/lime-micro/limesdr#


Using focused audio signals (LRAD) to enforce right-of-way:

Unless Olli will be limited to grade-separated roadways, it will eventually encounter pedestrian traffic conflicts -- some have talked about this as the "ethics" of a driverless vehicle coming into play, but I'd contend the best short-term solution is technical.

Granted, this idea is based on vehicles that would be traveling at higher speeds, so it's probably best taken as a discussion-starter and not as an optimal solution. But, as real-world tests of Olli in crowded streets will likely show that peds have no incentive to yield to it, having an audio signal such as a de-tuned/short-range LRAD device can effectively "sweep" the immediate area of pedestrians.

Since the nature of something like LRAD is that it becomes increasingly louder as you become more of an obstacle, it could be a useful educational tool that leverages human physiological instinct to create respect for the vehicle's right-of-way.

Thanks to @nowbreakit for notifying me of the Olli thread.


My idea is simple:

a touch screen monitor with the armored glass screen / unbreakable.
A smooth surface is easy to clean.


Automotive glass is mostly made with layers of laminate and glass to be resistant to various hazards. Why not embed OLED's, capacitive touch, and Electrochromic layers with the glass and laminate that way all glass on the Olli becomes a privacy glass touchscreen. 


Really big electrophoretic displays (e-ink). Consist out of a mosaic of COTS screens. Very little power use, long lasting, can eventually be resold for down-cycling. No glare and no hectic/intrusive ambience. 
Helpful for visually impaired people.


I would encourage the maintenance of fixed-route scheduling. The advantage of Olli is that it can reduce the cost of running transit vehicles. If they run frequently (5-20 minutes) on a grid-shaped network, people can board the system, navigate and transfer with confidence. This removes the problems raised due to having to interact with smartphones. This may also ease security concerns.

Transit consultant Jarrett Walker has some relevant material on his blog:
Grid Network Design:http://humantransit.org/2010/0...

Disclosure: I helped Jarrett with the illustrations of San Francisco's grid. :)

If Olli is serving an improved version of a system which is already effective, then Olli's interface needs are reduced. I would assume a payment system (cash box? contactless? I believe in London you can purchase Oyster cards at convenience stores) and "next stop" button / cord, an "assistance" button and a video camera / speaker for assistance from dispatch ... dispatcher should be able to route the assistance link as a call to directly to Emergency Services, with a minimum of vehicle location, ideally video access for the Emergency Services dispatcher, or a conference call with the Olli dispatcher who can relay whatever information is revealed via the video uplink.

Another advantage of a fixed-route network is that if making the vehicle kneel sufficiently low for roll-aboards (wheelchairs, strollers, luggage) is impractical, then building elevated stations / ramps along the route could service this accessibility need. Given that Olli allows the ratio of vehicles to stops to increase, making stops accessible might be the more cost-effective approach ...

(Sorry for the mind dump I think about this stuff too often..)


Have a "rating" on the app for defaced or stolen components of the car. Have a prompt such a "Is something wrong with the Olli?" within the app, and have the person explain in text and take pictures to explain the issue. 

It's important to have preventative measures as well. Perhaps have a quick prompt at the beginning of the ride to the extent of "How is the condition of your Olli?" If the rating is low, ask the question above.


Hi, I'm a product and software designer. 

Obviosly all the interaction should happen on a smartphone. There is no need to design for the exceptional user who won't have one. People enjoy working from their own phones and don't want to go over to a screen somewhere, push people out of the way, and start typing. 

The app needs to be designed as follows. 

 You need to start with two goals. Yours, and the user's. 

The user: Get me somewhere. 

Yours: Think of anything that you can do to help make the user happier, or to give you more money. 

You need to require users to set up an account to ride, so that each time they ride they don't need to set up payment. You can also have them call Olli with the app (and tell them when Olli will arrive). 

Simplicity always wins. 

The first screen for the user must be: Add a stop. 

The second screen must be: Calculating... You'll arrive in 4 minutes...

Now comes the fun: 

You can offer entertainment, but that would be pointless, since everyone has that already. 

You can offer ride enhancements to make the ride even better for extra money. For example, you could allow users to play games with other riders, or have some sort of social Olli rider interaction, so that riding Olli isn't just about the ride, but about the community experience. 

You can also offer food on the Olli, brought to you by a flight attendant at the click of a button. (Movie theaters make their money off this alone.)

You can partner with local venues and offer info/rebates to the user. 




With a video camera and True Key software users can be automatically identified and payments processed automatically without any smart phone and any credit cards or cash. When citizens register at their local Department of Motor Vehicles or other civic organizations they can safely establish a free account using their govt issued id's. Even Passports wouldn't need to be used any more. If you need any further assistance I'm here to help TDavidFranklin@gmail


put a big QRcode over the windows and let people analyze that even though they're a far distance away and watch a short video of olli, or even have short online chat with watson IOT if that is possible....


Hi co-creators and Local Motors team.
Following a copy of my post "Self-driving bus service models and passengers User Experience" that I wrote for thread.
I hope that you like and that it will be useful. Looking forward for your feedback.
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.

Public Transport

It's exactly the same public transport service as we know it.

Delivery service 

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).
Here some examples of a simple bus stop sing with a call button (left) and an advanced stop sign with an integrated ticket machine and a digital screen (right).


- 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.


Credits: Olli, Spoorzone Blog, Design Google, Icons8Seattle Transit Blog.