Measure Ground Control Web Application
New map features for multispectral image data analyzation and collaboration.
Product Management
UX/UI Research & Design
Business Development
Measure Ground Control is an industry leading drone software solution, which offers a complete suite of tools for businesses that operate and manage a drone program, or for drone service providers hired by companies that do not have their own internal drone program.
Part of the software ecosystem available to Measure’s enterprise account and pro subscription users is a map viewer tool that projects orthorectified image maps and multispectral index files, comprised of larger raw image data sets collected by drone flight capture, seamlessly showing the total intended area of interest. The benefit of multispectral image data is that it captures all wavelengths of light, including the one that go beyond the what is visible by the human eye. This can produce an almost infinite amount of combinations, by reordering the individual color bands, enabling early detection of issues like disease, water stress, pest infestation, nutrient deficiencies, or growth prediction models.
By giving users a convenient and intuitive interface with all the necessary tools for visualization, juxtaposing multiple data sets collected over different time periods, reporting, and collaboration, Ground Control has become one of the leading tools for multispectral analysis.This helps to improve the outcomes for farmers and agronomists, by using less natural or chemical resources to maximize the efficiency of crop growth. Additionally, this is becoming rapidly more important due to regulation for companies that require land vegetation management for things such as reducing forest fires started by power lines through forests.
Ground Control was not capable of projecting multispectral indices or reflectance map generated composites onto its map viewer. The version from which we were improving had thermal map projection capabilities, but it was a known limitation of the tool that we were underserving the agriculture and vegetation management market. Additionally, Measure’s parent company, AgEagle, was interested in creating full stack solutions that could be contrived from the different product categories of its sub brands.
Multi brand stakeholder workshops were the first step in understanding the MicaSense’s legacy software offering, and the market it served. There was a healthy amount of data points collected by them about the market, target audience user research, and customer feedback that gave the project a convenient starting point. Included was documentation for the development process of their tool, Atlas, as well as product usage data.
Leveraging the earlier mentioned research of MicaSense, we interviewed non Ground Control users and experts in the field of agronomy and agriculture. This included academic researchers from major universities, leading global agriculture companies, as well as market experts from MicaSense and their channel partners. A smaller pool of current Ground Control user interviews were also conducted, where there seemed to be a potential market fit.
These interviews were very conversational in nature. I wanted to to give the users the opportunity to explain their workflow, including the hardware they used, from end to end. While the audience was very targeted, and use case was very specific, I wanted to understand the similarities and differences between the different institutions that utilize multispectral technology. Lastly, I wanted to understand the frustrations in getting to the outcomes they were trying to achieve, including what they did with the information that they were gleaning.
The user interviews put me in the a position of better understanding for what the user was trying to achieve at each step in the process. Although much of that was not related to what we were going to initially implement on the software side, it gave me a sense of how to accommodate and correct for pain points and frustrations on the front and back end of their workflow.
Some of these pain points were due to the drone hardware and flight software not being able to affect control over the embedded sensor software. The other major issue I observed is that there were many different constituent hardware and software components needed to support the capture, processing, and visualization side, causing a lot of user confusion and subsequent mistakes for how to appropriately configure the data for the specific use case.
Research notes and next actions were documented in Confluence where a long list of features were discussed with internal stakeholders. It was made clear this was going to be a “product within the product”, or in other words a complete product release protocol was going to be implemented, which meant that beyond the explicit features I knew we needed to include to view multispectral imagery, I would need to consider including other missing tools to complete their workflow, or this would only be a one-for-one replacement to their existing software solutions, which didn’t necessarily improve upon their general user experience.
The main competitor we considered was the Atlas software that MicaSense had recently stopped supporting. While it had a nice user experience, the workflows did not go far enough beyond its own hardware support needs, which created a reliance on other software for specific tasks. Some of these features Ground Control did already have in its feature set, but some not, or at least not perfectly implemented for this segment. In order to capture the most market share, we would need consider other competitor hardware.
There was an open source tool called QGIS, which was primarily used in the academic world. It required a lot of scientific and math knowledge, but its capabilities were virtually endless by allowing users to code their own algorithm’s and build their own custom workflows.
This is great if you’re a scientist, but terrible if you want to make quick use of multispectral data for a larger portion of the customer segment. Aside from the level of complexity, and steep learning curve, the user experience left a lot to be desired.
The other major competitor is Drone Deploy, which makes a bunch of claims about how it supports the primary customer segment. On the surface it is a well designed product, but far too expensive for the primary market, and the tailored tools are limited for this use case. After asking users during the interview process if they’ve ever used Drone Deploy, most responded that they went through Drone Deploy’s free trial, and felt that even the tools were there, like plant count, they did not work as well as much less expensive alternatives that cater to their intended outcomes.
The customer affinity for Atlas, and the custom tailored functionality included to accommodate our sister company’s hardware, seemed obvious to take a lot of cues from. The research also concluded that we needed a tool that would cater to a large audience, while not concerning ourselves with the “cork sniffing” academic world that was mainly using the open source platform. It’s hard to beat free, but we could over come advanced and difficult to use. From our user input and competitor analysis, we drafted a punch list of features that were immediately crucial to include, such as a histogram tool and map tiler that could project index files and composite maps. Secondarily, there were additional features that were not directly related to visual analysis of multispectral data sets that, according to the interviewees, were items that needed to be included for them to convert to using our products. These were features like adding annotations to data products, exporting data sets, and share links for collaborative analysis.
I mapped the primary workflows identified by the user interviews, and created flow diagrams from acquisition to evangelist. This helped me identify key areas where I would need to draft suggestions for architectural improvements and backend refactoring, so that the tool would be able to accommodate new functionality, and give us a competitive advantage. In order for our system to be more performant, the backbone of our mapping architecture needed a complete overhaul. So, I worked with engineering leadership to get this part in development to be ready for new features that would require a snappier user experience.
The next phase was to redesign the sidebar panel, which contained the file management system, interactive tools, and most of the functionality that users would interact with to call up and manipulate their multispectral data. This included several design iterations and reviews that I conducted with our internal team, and our sister team at MicaSense, to flesh out the new functionality outlined in the new features punch list. I used this work as an opportunity to rethink our existing user experience and the user interface design, which had become very clunky and outdated. Since I determined that this work would require a backend refactor, I made it clear to the stakeholders that the design needed to pay off some design debt, too.
The prototypes were then used to demo with potential new users that I had previously interviewed, as well as the smaller pool of existing users that I knew would benefit from some of the primary and secondary new functionality.
Since I make time each week to talk with at least one of our enterprise customer drone program members, I would always use those talks as an opportunity to showcase any functionality that may apply to them. In this case annotations, export, and share were all relevant, so I garnered quite a bit of useful feedback from non-primary users for those individual components.
The main bits of feedback gave insights about what features were missing, like specific multispectral indices and file formats needed. I was also able to observe and see what functionality in the flow had to be iterated on and dialed in correctly first, like the histogram tool, and ability to generate color gradients on the map more precisely, before I could focus on the usability of other tools like export and share, which seemed to have a more straightforward development and design path, and could likely be a fast follow to get the crucial parts of the system in place first.
Once the prototypes had been properly vetted with our core users, the potential new user base, experts from our sister company, and internal stakeholders, I built out Confluence pages with product design requirements. This included clickable prototypes for each of the seven main feature additions, complete with developer asset kits, and annotations. I also worked with our development team to break down the units of work in Jira.
Initially, I comped designs that were too aggressive of a change. This would have added a lot of extra development time, and would have cannibalized the a lot of other parts of the site. With the current development capacity, while we needed to improve the design, we needed to keep it at a practical minimum to add value while adhering to internal bandwidth and capabilities. There were other technical limitations for how inputs had to be entered before the next screen could load, so there was only so many screens that I could reduce the flow to while staying compliant to the API requirements. In a perfect world I would have blown up the whole flow, and reimagined it from the ground up, but the world is full of healthy compromise.
