From Idea to Implementation: Business & Product Tips for Developing a Demand-Responsive Transport
Want to jump on a wagon and build a fantastic new DRT service? Then read the do's and don'ts we learned the hard way while creating an ambitious DRT service in Prague. You'll thank us later, we promise.
But before we dive in – what is DRT in a nutshell? DRT stands for Demand Responsive Transport – a flexible means of commuting that adapts to your needs.
It is something between a taxi and a bus. A taxi takes you wherever you want and when you want it. A bus has a fixed route and schedule. DRT sits in the middle: imagine a bus that comes to a location near you when you need it and takes you in the direction you need, but you share it with other passengers traveling in the same direction.
DRT services have been appearing and growing worldwide in the last few years, but there are still many countries and cities where more traditional ways of transportation dominate. That's why DRT is exciting!
Jimmy's insights come from the recent project we've been working on and from studying similar existing ventures around the globe like MOIA, Via, Shotl, and many more. Our client's mission was to launch the DRT service in Prague and its suburbs. What are our takeaways? Let's find out!
Concept and research tips
Tip 1: Align everyone on what the DRT concept means
There are many different types of DRT services, and it may be challenging to describe them in simple terms to someone who hasn't heard the term before. Come up with something simple, so the phrase can be easily remembered, and then explain it in more detail.
For example: "shared minibuses on-demand."
Although these words are usually clear to everyone on their own, it may be hard to imagine their combination.
When you elaborate on details, it's good to come up with simplified analogies. In fact, the idea has a lot of similarities with other known services, which makes understanding easier.
For example:
- Compare DRT with a taxi. The ordering process would be similar. You select your destination, confirm the current location and wait for the car to arrive. If you're familiar with shared taxis where multiple people hop on a ride, that is even closer to many DRT services.
- Delivery services can also serve as an example. A courier picks up packages while roving through the city and drops them off at their destinations. The service we built deals with people instead of parcels, but the mechanics is similar, especially from the driver's point of view.
Similarities and differences help in the development and marketing processes. However, they can make some details tricky.
Since there are a lot of popular taxi apps and the ordering process is the same in many aspects, the UI design and some of the operational best practices can be reused from them. Or at least you can get inspired by them. Adopting such interfaces and features by users is also smoother because they feel familiar.
At the same time, similarities should be approached with caution. The concept is still different from a regular taxi app, for example. Since minibuses are shared, passengers need to select a number of seats. Also, there may be certain areas where the service operates and others where not. So guiding passengers through the ordering process or letting them understand differences upfront is very helpful.
Tip 2: Design the main flow connecting all types of users early
This is valid for any product you're building.
DRT services often target multiple types of users at the same time:
- Passengers who want to travel have a mobile app.
- Drivers who want to participate on the platform and make money by completing rides have a mobile app.
- For administration purposes and/or for customer support, there is usually a web application.
They all work within the same "flow" but from their own angle, having different goals, screen time, etc.
It is crucial to design that single flow in the early stages and get feedback from all types of users. Because a change in the process identified for one kind of user may trigger an evolution of the process for another.
The sooner you can design a stable process, the easier it will be to develop all the apps around it.
Implementation and testing tips
Tip 3: Start building the whole system from the beginning
Once you know how all the types of users need to interact with each other, let's build something functional.
If you're working in an agile way, you should know that every increment at the end of your delivery cycle should be a working product. So start building the entire system from the beginning instead of working on a single app and then another. Of course, it will not be a fully functional service from the start, but incrementing all parts of the solution together lets you have it in a consistent state.
The sooner you have a working system, the sooner you can start testing it live – not just internally but even with a limited group of users of each type. Early on, the app will have fewer features that every user would want, and some parts of the ordering process might still need to be completed. Nevertheless, it will help you prioritize the following updates in a better way.
Tip 4: Experience it yourself
You must hit the road when you're building a service for commuters and travelers. Spending a few hours in a car gives you tons of new insights you can't get from sitting in the office or at home for weeks.
Nowadays, teams are distributed around the world and are far from the location of the actual business. That makes it even harder for everyone in the dev team to experience how the product works. Try to use as many tools as possible to help simulate real-life situations. But even with those tools, going outside and walking around with a mobile phone is priceless. You can grasp how apps would function in real life and if some essential details are not overlooked.
What really helps is to have at least the product owner and designers at the location of the pilot launch. If you do, they naturally learn how the transportation system works and will keep this experience in their head while designing the service.
If the design team is also distributed and can't travel to the location, it complicates the UX design process and related communication.
Tip 5: Test a lot
Besides going outside to find out how the solution can be designed and developed, you should go out there for testing. In the perfect case, the delivery needs to be tested right in the area of operation.
Ensure that everyone in the team knows how his part fits the entire product, not just how it connects to one or two other pieces. This way, the testing becomes more comprehensive on all levels.
Product tips
When you advance with your product, many curious details will appear along the way. Make sure you track all ideas, feedback, concerns, and doubts to analyze them together and deliver the highest value to all users.
Here are some tips that may not be obvious to you initially but ones you may find handy when building a DRT solution.
Tip 6: Be prepared for traffic
You can accidentally experience a sudden increase in traffic on the road. In Prague this happens daily, and other big cities are no exception. Ensure that the system has at least some way of reflecting the current road situation. If you cannot source current traffic data automatically and count it in, make sure you have other ways of delay indication. It could be some manual actions from drivers, showing the driver's location to passengers, or an option to let the driver call a passenger to inform them about delays.
Tip 7: Anticipate connectivity issues
Some mobile network providers have uneven or poor internet coverage in suburban areas. So if the service needs to work in these areas, your apps should be prepared for connectivity issues and still ensure smooth operation when the signal is temporarily lost. Such things are also hard to discover when you're not testing on the spot.
Tip 8: Test in various locations and with different devices
DRT services are location-based and usually have a limited coverage area. That means users' devices (drivers and passengers) should have their location within that area to use the service. To test these limitations remotely means to fake the location of the mobile phone. However, it's challenging to fake the location on an iOS device. Make sure you're prepared for that.
Tip 9: Research your map data provider thoroughly
Some providers may cover specific areas, cities, or countries with more detail than others. So for a multinational service, it makes sense to design a system that switches map providers based on location.
Tip 10: Move around as fast as your users
When testing in real-life, make sure you move around as the actual user would. So to simulate a driver's experience, you need to move as fast as the car. This will show you how frequently you need to update the screen and how smoothly this update happens, especially on slow devices.
Tip 11: Help drivers identify key information by making it big
Drivers are obviously focused on the road most of the time, so when they switch focus to the screen, they need to get the most important information as quickly as possible. The big text size and actionable elements help identify what's essential and act on it quicker. Even the contrast of specific components may make an impact.
Tip 12: Design for different types of gestures depending on the actions
When a driver needs to accomplish an action that is not reversible (confirm something), it is much better to use a sliding element instead of a clickable one. A clickable component may be misclicked, but it is almost impossible to slide something by mistake. Such gesture patterns are used by other transportation apps, so you can learn upfront which gestures are more common for specific actions in the app.
Tip 13: Focus drivers' attention just on the next action
Since rides are usually shared, there is a plan for drivers to follow, not just one individual ride. However, showing the whole course at once is not a good idea. Instead, highlight the following action in the schedule to keep the driver's focus and even hide the rest. The upcoming action is the app's most critical information drivers want to see. So limiting the number of details on the screen and highlighting the forthcoming action reduces drivers' distraction.
Tip 14: Use sound notifications
The driver's manual actions in the app should ideally happen when the vehicle is not moving to ensure safety. But because of the shared nature of the rides, new events also occur on the road – new rides are entering the plan, and others get canceled. Such changes should not require manual action (like a confirmation) from the driver. However, it is crucial to notify the driver about these changes. The driver may not notice a visual notification while driving, so sound notifications may help point out a new change. This way, the driver can check the update later when it's safe.
Epilogue
On a high level, many of these tips aren't new and can be applied to any project. But each domain has its specifics, and when you develop mobility and transportation applications, you see how certain details matter.
The future of projects like this is to build better, greener, and more accessible transportation. So with every challenge we face and overcome, this future comes closer to all of us. Good luck!
Reach out for more information.
Nikita Lamonov, product owner
