DroneDeploy is the leading drone software platform for autonomous flying, mapping and sharing map data.
I began working at DroneDeploy, a drone SASS company based in San Francisco in 2015. I initially designed a dashboard where users accessed all their data at the dashboard level. At that point of time most users only had a few data sets however a few years later in 2017, the number of users with an unmanageable amount of data quickly became a problem. The solution would need to support all end-users and specifically enterprise level customers. We needed a model that would allow users to quickly access and share data. This introduced challenges such as creating a hierarchy model that would be flexible across verticals yet keep data secure when sharing.
At the time I was serving dual roles as the sole Product Designer of DroneDeploy as well as the Visual Designer. I was responsible for delivering solutions from early exploratory research to providing an MVP to the engineering team for development.
I am a big fan of design sprints, a similar approach as referenced in the book “Sprint,” by Jake Knapp. The process I use varies depending on the level of understanding and scope of the problem. Generally, at a high level, the design process consisted of:
Understanding the Problem -> Sketch Solutions -> Prototype -> Validate -> Iterate if Needed
Users were not able to group and organize relational data sets within their dashboard. The solution needed to support various verticals such as agriculture, construction, and drone service providers. The solution was essential to current and potential enterprise customers from a business perspective. Users needed a method to quickly group associated data and share it. The following will focus on the solution of organizing data:
Another factor to consider were the data types and how data was used in end-users day-to-day jobs. The main data types were:
- Plan: A plan included geo-referenced waypoints that the drone would autonomously fly over and capture data via images.
- Upload: Once a plan was completed and data was captured the images were ready to be uploaded to create an orthomosaic or 3D model. The images were processed by a map engine on the cloud.
- Map: Once the images were stitched and the model was ready, the user would be able to access a map that can be analyzed with various tools at a 2D, 3D and point cloud view.
Users and Audience
- Construction: Drone pilots, analysts, or administrators that utilized drone data to report site updates, review site status, and identify actionable data.
- Agriculture: utilized drone data to increase crop yield.
- Drone Service Providers (DSP): had contractual work across various verticals.
I needed to further understand how end-users and customers organized their data within the DroneDeploy application. It was vital to comprehend who needed to access the data, the user’s role, the type of data that needed to be accessed, when in the project phase it needed to be accessed and ultimately how data is applied in the users’ day-to-day functions.
I normally target five candidates that I identified to have a specific group of attributes. My go to tool to identify potential candidates was Intercom. It yielded about a 20% conversion rate so I knew how many users I need to contact.
The target audience included the following attributes:
- Users that had created more than 20 data sets.
- Users with enterprise accounts and non-enterprise
- Users within construction, agriculture, or drone service providers verticals.
- Users that had previously shared at least 15 maps and had not shared any data.
After the user research data is collected I synthesize data via stickies or a spreadsheet. The example below illustrates the synthesis process:
Through this process I found that users within agriculture and construction had a similar mental model of organizing data, however drone service providers utilized a different hierarchy model. Another factor that differentiated drone service providers is that most of them serviced various industries.
Other findings revealed that enterprise customers needed to quickly access and share data within their organization and with third parties such as contractors.
I noticed re-flying locations and sharing flight plans was not easy. Enterprise customers needed a way to re-fly areas at different resolutions. For example, they needed to group various map locations in a nearby location based on construction sites.
After validating that users within the targeted verticals had a diverse approach to organizing data, we decided to adopt a more flexible model using “folders”.
Folders provided the needed flexibility to support various mental models of organizing data. It also allowed users to quickly share all assets within a folder. There were various edge cases that also need to be considered, such as:
- How many layer of sub-folders would we allow?
- Who would own the data across an organization if any?
- What would happen if data was moved?
- Were users able to delete data and place it within a bin?
- What happens when a folder or a file within a folder is shared?
The complexity grew as we explored. We decided to adopt a similar model as DropBox for sharing and accessing data. Users trust other users not to delete or move data responsibly. The MVP only allowed users to create folders at the root level. Users were not allowed to create sub-folders as this would increase technical cost significantly. Initially users were not allowed to drag assets into folders as this also involved a higher technical cost.
Now that we fully understood the problem and user needs, we were ready to sketch the folder solution.
Sketch of creating a folder:
Creating a folder video:
The folder feature was a success and easy to use. Enterprise users are now able to organize data with ease and quickly share internally and externally. This has also helped increase sales for enterprise level accounts.