Research and Planning

The simplest starting point was to survey some existing Esri UK customers to learn about their current editing processes, pitfalls and how we could design and develop a solution to overcome these.

We also had a number of internal stakeholders and interested parties that we interviewed to try a gauge the functionality, and usability of the product.

We asked them about the current tools they use to do this process and what are do they like most about these tools (if any).

Finally, we asked them to use their imaginations - what if there were an applicaton they could use to easily edit their data and how do they think it could work?

As we collected the data from interviews and survey responses, distinct patterns started to surface. Our potential user base expressed significant importance towards aspects like data quality and the quality assurance (QA) process for editing spatial data.

While Sweet had no intention of substituting any Esri Platform products, we did consider the high familiarity of our target users with the apps provided by the Esri platform. This led us to contemplate the essential features and interactions found in the main platform applications.

Designing the Solution

Many of our initial design and functional decisions were made with Sarah in mind. We were aware that to get traction behind the product we had to get a user base with strong GIS knowledge to adopt our new editing tool, we could then adapt the application to cater for less GIS heavy users such as John.

In other words: making Sarah our primary persona allowed us to address the needs of both.

User flows

As a product team, we worked hard to develop concise and targeted user flows within the app that specifically catered to the user's immediate needs. One major objective was to provide useful visual feedback during the editing process as to eliminate any misconceptions about the current status of any editing tasks.

Following several rounds of user feedback on visual mockups, we had successfully developed a number of compact and highly effective UI interactions. These features elegantly presented the editing rules to users in a concise and easily understandable manner. It received an overwhelmingly positive response from both stakeholders and users, making these micro-interactions a resounding success.

We also decided to test the idea of encouraging more confidence in capturing and editing spatial data within the application by allowing users to create business and topological rules aswell as user flow interactions such as a reliant undo and redo stack, something which was unavailable to our customer base previously.

Early sketches

The application goes beyond mere UI elements; it is a comprehensive app equipped with advanced geospatial editing capabilities. However, during the initial stages of development, we had to simplify and return to the fundamentals. We created early sketches and designed the user interface from scratch, taking into account both Desktop and Mobile solutions.

Conclusion

Throughout its life-cycle, Sweet for ArcGIS has grown from £0 to £2.5M ARR, this has been in part because, as development team we focussed on User Experience as a core principle of the product.

If I could do this project again, there are a few things I would have done differently:

1. Perform more heuristic evaluations of the app throughthe product lifecycle.

2. Advocate for more usability testing of the existing product and workflows before adding new features.

In hindsight, I think there were opportunities where we could have made the case for us to shift our focus to UX research. Instead, we continued to design and iterate upon new features.