Driver Inbound

Project

The last mile of any delivery is the most dangerous, and information on how to deliver shipments in busy cities and intersections is scant and poorly distributed. Driver Inbound lets drivers tell other drivers how to delivery to tricky destinations, and rate existing explanations for accuracy.

Effectively, Driver Inbound is an AR Social Media app used as a professional tool.

Early Concept

I started work on Driver Inbound with the initial client pitch. I needed to make an app that let drivers share delivery instructions with other drivers. The traditional method of sharing delivery information was to huddle around the Google Maps app, point out potential hazards and physically indicate the best angle of approach. This method of sharing only really worked in person. Sometimes drivers would share printouts with information drawn on.

Driver Inbound needed to have at least this functionality but be available remotely, and stored and accessed later. One experienced driver repeating themselves to every newer driver was inefficient. At the same time, the entries needed to be able to change, as sometimes road conditions and even delivery methods changed. 

We decided on a social media app using the Google Maps API, letting the users make posts tied to Google Place information (Google place names or street addresses). Each post would include a description of the delivery process, one line for the final parking location, and two longer lines showing the set-up and approach method. Posts would also include icons of potential hazards and equipment required for the delivery.

Users could vote on existing posts as useful or unhelpful, allowing posts with inaccurate or outdated information to fall out of view, with a slight weight towards newer posts being presented first.

Planning

With the initial concept approved, I began work on the first design of the app, prototyping both in paper and in Figma a UI prototyping app. In Figma I was able to lay out the methods that Users would log in, search for existing posts and create their own posts.

This helped in recognizing what data was needed to be collected and stored, and what data could safely be skipped. It was very important to collect less information, to better comply with upcoming GDPR, and store requirements.

 Early prototyping also helped us identify what API were needed, what methods of storage could be used, and to see how those ongoing costs fit in with the client’s business model.

Collaboration

Even with the scope reduced from the initial pitch, Driver Inbound was too large of a project to work on alone. With client approval, I started searching for additional team members, including a UX Designer/Artist, a programmer and eventually a web designer.

 From there, we started having regular planning meetings and I started taking on a producer role, making sure that everyone had clear assignments and objectives, and when the team had questions, finding out the necessary answers.

 In addition to regular scrum meetings, I maintained and updated the group HacknPlan, writing up new tasks, developing formats and tracking ongoing issues and bugs as they developed.

Testing and Plans

As DriverInbound developed, we had to get the app working on both Apple and Android and meet the demands of both App Stores (PC release was delayed). This required extensive testing on both Apple and Android and a testing plan for both platforms.

I developed the main two test plans, with multiple variations depending on the level of changes we had in the upcoming release, and the urgency of any fixes.

I also performed extensive testing on both Apple and Android. 

Tool Development

 As DriverInbound was developed, it became clear that internal tools were needed. As it is a social media platform, however limited, there is always the risk of abuse. Additionally, GDPR and App Store requirements meant that we had to be able to delete user data, either anonymizing previous posts and comments, or removing them entirely.

 For this, I developed a tool that interacted with our database, allowing us to receive customer reports, investigate problematic content, edit (with notification) or delete problematic content and apply user restrictions on posting.

 Additionally, the tool needed to be able to search through and either anonymize or delete user data on request. For this, I worked closely with our programmer to make sure the tool could delete or anonymize user data without causing problems for the database and the app as a whole. 

Changes and Release

DriverInbound is now released and available on Android Phones, Apple Phones and Apple Tablets. While challenges were encountered along the way, and the PC release was postponed, DriverInbound is now being used for its intended purpose, helping drivers share information on the last mile of deliveries, reducing the amount of time it takes to deliver and lowering the chance of accidents.

While the initial plans for Driver Inbound were intentionally focused on light social interaction, it was discovered that outdated posts weren’t being removed from the front of search results quickly enough, or that many times, otherwise accurate posts would have only one or two errors.

As the product developed, we added user comments in addition to user posts, letting users post direct corrections upon another user’s post without having to make a new post entirely. While there was an increased risk of user hostility in these corrections, ultimately the added information and context was worth the changes.