As one of the biggest connected car companies in China, PATEO always takes 'extreme quality, extreme experience and extreme interaction' as priorities. PATEO keeps bringing new opportunities to connected car industry with high technologies and constant innovation. Innovation and extreme user experience are the key of operation and development of PATEO.
A news was seen online that a shared car was driven away in expressway service area. A lively discussion was held among PATEOers from Silicon Valley, Frankfurt, Beijing, Wuhan, Nanjing, Shenzhen, and Changchun on 19th August on user experience optimization. PATEOers broadly discussed and shared their ideas on user interface design, user experience and other relative aspects.
During the discussion, Ken Ying, the chairman and founder of PATEO, led the team to talk about how frontiers like car sharing, bike sharing, intelligent parking services and shared parking services can impact affect people. He firmly believes that 'A proficient engineer is better than 1000 mediocre engineers' and treasures the value of elites and fast learning. Many teams are providing innovative ideas and creating extreme user experience every day in PATEO. The entire PATEO believes that product culture is more than mere words.
Some insiders believes that user volume of car sharing service will keep developing with a growth rate of 40% in the coming years. The car sharing industry is still in the startup stage. Business model and other user experience problems still remain to be solved.
We strongly believe that extreme user experience for car sharing is an inevitable trend. Following is the content of the discussion.
How will PATEOers solve the problem in this case and how will us make the user interface better? Please feel free to talk about it.
In this case, the former user was forced to terminate service. A suitable return mode needs to be adopted to determine how to define terminating service (by simply locking it or through smart phone operation)? We can set up 3 keys on mobile phone interface: 'Return Car' (users will be prompted to confirm and then pay to avoid misopetaion), 'Leave temporarily (To lock and leave)' and 'Continue to use (to unlock)'. We may also set a hold button inside the vehicle, enabling users to leave temporarily or continue to use. Users should also be able to terminate the holding mode remotely from smartphone to terminate the service. As long as the fare meter is running and the driver is keeping charged, the users should be authorized to take a rest as he wants without worrying if the car will be driven away by other people. This is a good example for our future cooperation with other car sharing platform.
This case is probably caused by a bug in the program. This shared car APP only allows users to rent and give back cars in assigned places. We can simply prohibit returning the car if it is not in specific place.
The user interface is not designed properly. It should be set that the car cannot be scanned and driven away within a certain period of time (e.g. 1 hour).
It is necessary to lock the car when leaving temporarily since shared cars are not equipped with keys. In order to prevent the problem in this case, we may consider using a QR code for door opening. Users may get notifications from relevant WeChat official accounts when they leave temporarily. If other people scan the code, the former user may get reminders and choose whether he will continue to use the car. We can also set a holding period (e.g. 30 minutes) to solve the problem.
The key is to find out if the user terminated the service or temporarily held the service (e.g. if the user is still paying for the service).
It can also be solved by checking the vehicle position. If the user did not reach the set destination, he will get a voice reminder from car and a message from smart phone APP to confirm if it is a temporary stop.
Will user be charged for temporary stop? If so, user can save money by terminating the service and starting again. However, the user may have to take the risk in this case. If not, car rental companies will bear some losses. Users will probably choose to park temporarily instead of terminating and then start over if the fee for temporary stop is acceptable.
It depends on whether the user terminated the service initiatively. If the trip is over, others can surely use the car. If not, even if other users scan the code, they will get a message saying that the car is still in use. The situation in the case is quite abnormal.
Theatrically, it is impossible for two people to use one car at the same time. The next user can only use the car if the former user is not being charged.
It is not practical to terminate the service once the car is locked.
Users will leave the car during service period for lots of reasons. No users will be willing to scan QR code every time he gets out and gets in the car. The user interface should be improved.
Users may receive notifications from App when parking the car in expressway service areas and then select whether he is going to terminate the service or hold the car.
Electric shared cars are generally required to be returned at assigned places for battery charging. The problem in this case can also be solved.
The essence of the problem is that there are very few shared cars. If there were plenty of shared cars in the service area, the problem would be solved easily. 'Share' is the key of shared car service.
Too many cars may cause parking problems.
If the user parks the car temporarily, he is still renting the car and the other users should not be authorized to scan the QR code and drive the car away. The users should also be authorized to see if the former user terminated the service or just stopped the car temporarily.
The point is that if the car is not locked, it will be easily driven away like a shared bike. However, if the car is locked, the user has to terminate the service. Is it possible to set up two options in the App after locking the car to determine whether the user intends to terminate the service? One is 'Park temporarily', which allows a holding period of 20-30minites. If the time limit is over, the service will be terminated automatically. Another option is 'Terminate the service'. Users may terminate the service via this button.
Shared cars can be viewed as taxis without drivers. If you want to get off the taxi halfway, you will probably ask the driver to wait for a moment and the sign on the taxi will still show 'busy'. We can also set up a sign in the shared car when users want to park temporarily.
I guess there is no time limit for temporary parking no corresponding user name.
User can even park for a whole day if he pays for it.
A button could be set for users to choose if he would like to take a rest or terminate the service. When he is taking a rest, his rental car cannot be scanned and driven away.
We can refer to the settings of shared bikes and set a key for parking temporarily in the App. When this button is activated, his rental car cannot be scanned and driven away.
The operation mode should be as simple as possible at the beginning. If the user did not terminate the service initiatively, he will still be charged. The service operator will still get paid. The operation mode can be updated rapidly according user feedback on the App.
A different charging mode can be adopted for temporary parking. Rental car cannot be scanned and driven away when temporary parking mode is activated.
In the first stage, it is better to charge driving and temporary parking at the same rate. Since the amount of shared cars is still limited, a higher rate for temporary parking may make users terminate the service immediately once he needs not to continue using the car. User experience can be optimized in the later stages with the knowledge of users' pain points.
The problem can be solved by parking mode setup (e.g. temporary mode, service area mode, normal mode, etc.) payment mode setup. Users should be authorized to set up route in advance and get estimated travel time through shared car service.
We can limit the time of temporary parking, for example 0.5 or 1 hour. If the time limit is exceeded, the user will be charged with the rate of normal driving mode, or other users will be authorized to scan and drive the car away.
I don't think it's necessary to set up another charging mode for temporary parking. User should pay for car rental service no matter driving or not. Charging mode of Shanghai taxis can be followed, i.e. both driving distance and period should be considered when calculating. If the users are charged based only on service period, it is not necessary to consider if he is driving or parking since he is paying for the service in a certain period of time.
There is a more intelligent way. The service can be terminated automatically if the car is locked in parking and charging area. When the car is parked somewhere else, it will be viewed as temporary parking (and he will still be charged). The user will also get a reminder from APP, asking if the user plans to terminate or continue the service.
The user should be charged no matter if he is driving or parking. The case indicated a big problem in user experience design. Thus, I also suggest to consider both service period and distance when charging.
A reasonable process should be: Parking-> Locking-> QR code cannot be scanned (for 5 to 30 minutes, still being charged). The car cannot be scanned and driven away within this period of time.
The operation mode of current shared cars is similar to that of share bikes. The service is terminated once the car is locked. The case above was just an extreme example. In fact, such problems also exist in shared bike service, since in most of the areas, the shared cars cannot be sufficient. I had some suggestions for Mobike on holding bikes before, shown as follow： 1.The rule of terminating service when locking bikes should not be changed since most of users are used to this mode, it is not necessary to change the rules for very few people. After parking, the bill will be shown and the charged period will be terminated. 2.Once the car is parked, a reminder will pop up to ask the user to decide if he would like to hold the vehicle. The vehicle cannot be scanned and driven away if 'hold' is selected. The 'hold' service will be free of charge for the first 5 minutes, and the user will be charged afterwards (with differential pricing system, the maximum price for parking will be the same to that of driving).
Lending or returning the car is totally different from locking it. Both driving distance and period should be considered when calculating the payment. The user will be charged no matter he drives or not, but he will be charged more if he drives more since the vehicle will be worn more when driven. Total price = driving mileage * unit price (distance) + parking period * unit price (time).
If the car can be temporarily locked by APP, the user will still be charged and other user will not be authorized to use the car.
The more complex the mode is, the more problems will be brought. A lot of complaints on calculation error will come.
It can be judged by whether the engine is switched off.
All possible situation should be considered and equipped with simple operation modes and reminders.
Both vehicle status and user operation should be taken into consideration. If only one of the aspects is considered, the problem in this case may occur. Vehicle status: Vehicle stopping status should be classified into 'waiting at traffic light', 'temporary parking', and 'terminating service', etc. User operation: User can choose mode in APP. We need to test all the possible cases to design a reasonable, feasible and beneficial strategy.
Can we integrate the sharing operation with navigation?
We can integrate the sharing operation with navigation. If the preset trip is not finished, unless the user terminate service initiatively, other users will not be authorized to use this car.
Unlike shared bikes, specific parking areas and management staff should be equipped for shared cars. Service can only be terminated if the car is parked in a specific area. Navigator should remind users of available parking area to terminate the service. Users can also select a parking area near destination in advance.
The QR code should be displayed in a matrix with lights. Thus, if the light is off, other users will not see the QR mode. The light will also make service at night easier.
Add a 'Pause' key on the App.
The lively discussion benefits me a lot and I would like to share some of my ideas. With the increasing popularity of various kinds of trip sharing, sharing economy become the hit. Moreover, car sharing services are closely related to PATEO business. The car sharing business is just emerging. It will meet challenges from multiple aspects, e.g. car use regulations, civilized driving, safety and user experience, etc. For us who work in connected car industry, we care most about user experience from both the user and operation perspectives, which are also the user pain points in this case. If PATEO starts to operate shared cars, will we be praised or criticized even more? PATEO, a company with mature technology and talented engineers will bring customers better user experience in the following aspects: 1. PATEO is well known for its great user interface. The user interface for shared car APP can be improved with messages like 'Welcome to our shared car service', 'Are you sure you want to give the car back?' etc. 2. PATEO is able to provide intelligent IVI for shared cars and user can access mobile phone APPs through IVI. For example, user can input destination when renting car. Once the car is activated, in-vehicle navigator will recommend the best route to user. Intelligent IVI will also record the historical data of cars used, routes traveled and songs heard by each user. Messages like 'Good to see you again, do you still want to listen to xxx (song name)?' will probably pop up. 3. PATEO will take full advantage of connected car. Shared car can be further shared to fully utilize the resources (e.g. Uber like commuting service). Moreover, if a shared car is locked by multiple people, it is less likely to terminate service wrongly, the expense for car usage can also be reduced. 4. PATEO will employ massive data platform to analyze user behaviors intelligently. For example, it is not likely that a user will terminate service in service area. The developer should filter content or remind user of the situation. Moreover, the IVI should analyze regular routes and parking spots of the user and recommend available vehicles for them to improve user experience. Although PATEO is not strong enough in terms of capital, market and operation, the extreme user experience will help PATEO stand out in the field.
After reading the discussion on shared cars, it suddenly occurred to me that what we should do if the shared car is locked up with a private lock some day?
Shared cars should be parked in assigned places for easier management. It will be better if there are more parking spots. A report system should be added to the App just like the shared bikes, enabling users to report parking offence or other problems.
No user of EVCARD, a shared car brand in Shanghai, has ever locked the cars with private lock since the service can only be terminated once the car is parked at the charging points and being charged.
Shared car companies can cooperate with resident areas and plan for parking areas in each neighborhood. From the App, we can clearly see the available vehicles and parking spaces in each area and the commute service can also be realized. Users can even reserve parking space 10 minutes before reaching the destination. This will really bring convenience to residents, especially when they are going to a distant place with luggage. The number of vehicles and parking spaces must be well planned to avoid traffic jam or too much cars in one area. Intelligent control over parking spaces should be implemented as well. If there is no parking space available, shared cars will be kept from entering the area. Maybe in the near future, with the development of car sharing, we will step into the sharing era.
Though the user in this case selected to return the car and caused the problem, the case can still inspire us a lot. We could learn things concerning voice command, navigation data, express way service area, user experience design and bug fixing from this typical case.