Dron is a peer-to-peer drone delivery system, designed to help deliver everyday things between people. This futuristic app was created in response to a design brief for a university assessment, with a team of 3 other students. You'll find my documentation of our design process in creating this service below, as well as an interactive protoype of the final application avaliable here.
"Although completely self-driving cars are still estimated to be another 20 to 35 years away, recent first attempts at mass-producing autonomous vehicles for today’s cities demonstrate that as designers we need to start thinking about how people
in the future will interact with autonomous vehicles. The aims of the design project are to acquire and apply practical skills in designing and prototyping interactive products and services, and to understand and apply principles of graphical
user interface and interaction design that enable interactions with autonomous vehicles."
There was a wealth of different directions that our group could have selected when choosing the technology we would be designing for. Among the options we laid out were autonomous crop harvesters for farmers, a rural postal delivery service to fill in the gaps left by traditional services, and delivery drones that would operate between a network of peers. Ultimately, we decided to go with the peer-to-peer delivery drone concept, as we felt it would afford us the most opportunity for creating an exciting and useful interface - so long as we could verify there was a user need for that type of service. So, naturally, the next step was to take a look at some of the existing services, and begin our user research.
Great for transporting people - but not small objects. However, Uber has a set of similar design patterns in their mobile app that essentially solve the same design problems we're looking at in our own service.
In the context of posting a job to send an object somewhere else, Airtasker falls victim to the same problem Uber does - it's extremely inefficient, while still being expensive.
Australia Post is much cheaper than the other services, which makes sending smaller items much more feasible from a financial standpoint. However, Australia Post is also significantly slower at delivery, usually taking a full business day or more to deliver even locally.
The biggest takeaways I had when looking at these services were:
I decided to use a variety of research methods, to ensure I could best identify the user problem and user needs.
A questionnaire was sent out to a number of participants in a variety of channels. 15 responses were recorded.
5 subjects from different age groups and occupations were described the concept of delivery drones, and interviewed using a loose structure.
A set of academic papers detailing already existing research were selected as part of the data set.
1. To identify if there exists a user need to deliver small packages faster than existing services.
2. To determine the reasons that a user would be likely or unlikely to use a drone delivery service.
3. To determine what functionality a user would want from the final interaction.
Researching online, I was able to find out some more information on how the public views drones. One of the most interesting insights I found was this:
“From a survey of 604 participants, selected randomly from different age groups, it was concluded that people are significantly less concerned about military or police drones than they are about commercial and hobby drones”
My survey questions were designed to gather qualitative data about how people felt about leaving their valuables in public utilities (like public lockers), as well as how people would feel about using a drone delivery service. Overwhelmingly, I recorded that my participants would use a drone delivery service, despite concerns about safety.
For my interviews, I decided to go with a loosely structured approach. I roughly described the concept of the product to participants, then asked a series of questions, letting the conversation flow naturally. I recorded audio and took notes by hand, which assisted me when I began the analysis process.
With my data collected, I used a variety of evaluation methods to pull out key insights and answer my research questions. I created an affinity diagram from my interview transcripts, developed a set of personas representing different use cases for the product, and created storyboards walking through each personas unique use case.
There are unmet user needs in the current system of deliveries. Small items that only need to go a short distance slip through the cracks of this system, and users want them delivered faster and cheaper than existing services.
These first sketches were drawn up to give a super rough idea of how our interface would function. More of a user journey than an interface, they represented the basic steps that the user would need to take to progress through ordering their delivery. This interface would serve as a basic starting point for moving forward with our visual design of our UI, as we did not test this interface with users.
This was the first testable version of our interface that we created, refined from the previous concept. This version again represented each major step the user would need to take to order a delivery drone. Included in this prototype were concepts such as package size selection, delivery address selection, and live delivery tracking overlaid on a 2D map.
In order to test this concept, we implemented our UI in Marvel Pop, which was a quick and easy way of creating clickable interaction. We also cut out our interface on paper to conduct hand testing, by having users tap on the cut-outs and manually changing the screens.
In summary, after testing this prototype, we concluded that we had not built the UI to the level of fidelity that it required to be functional - both in the sense of providing the wholistic drone delivery experience we had imagined, as well as being able to evaluate that experience. This was our main consideration when moving forward to the next phase of prototyping.
Moving forward from our previous prototype, I implemented the next version of our application in Adobe XD. As discovered during the testing of our low fidelity version, I added many of the features that were needed to demonstrate a fully functional delivery application. These included location pins for each contact, a dynamic map with a visible drone icon and status updates, a size and price confirmation screen, and search bar for delivery selection.
For this round of testing, we decided to further test how useful our application would be by bringing it into the physical world. We asked one user to deliver a hat to another, playing the part of the drone with a cardboard box to demonstrate how it would work when fully functional. This proved extremely useful, as we were able to see the physical pain points that existed outside of the digital interface.
After this round of testing, several pain points were realized in the existing application that would need amending. Such pain points included confusion over how contacts differed from addresses, uncomfortable screen interactions, and lack of clarity in the way ETA information was being displayed. In order to fix this, my group and I moved back to the drawing board.
When I tested the prototype on my Samsung Galaxy S7 Edge, users often complained that since the phone is quite large (especially compared to older iPhones) the search bar was hard to reach with their thumb. The solution was just to simply move the bar from the top to the bottom of the screen.
Users expressed that they'd like to be able to see where their friends are on the map (a feature similar to Snapchat), and be able to differentiate themselves from other contacts. So, we added each contact with their initials to
the map. with an option to start a delivery.
Peer to peer drone delivery is peer to peer, not address to address - someone will always need to be there to put stuff in and take stuff out of the drone. So, we scrapped the old address system in favor of delivering to contacts
by default.
Users seemed to be confused by the way the route of the drone was being displayed - so we opted to display the entire route, provide an ETA at the bottom of the screen, and add animation to the movement of the drone.
With these concepts reworked, we decided to move forward in creating our final interactive prototype. This would include implementing the changes detailed above, reworking the color scheme, and adding animation and transitions to help highlight the interaction.
The final prototype was created and animated using Adobe XD, which allowed us to design and animate simultaneously in the same environment. Overall, myself and my group was very impressed with the look, feel, and overall quality of the final interface. A demonstration of the final protoype is available on the web, and the XD file can be downloaded to view the fully animated version.
.jpg)
