Research and Planning

I engaged in interviews with both internal stakeholders and users of the current system to delve into their perspectives and specific use cases.

Through these interviews, we developed two distinct user personas that play crucial roles in our design: A standard internal user and an admin level user, who will require additional functionalities and access levels within the system.

Drawing upon these interviews, I fisrt created a persona named Beth. Beth is a GIS professional, specialising in content creation & distribution for customers. She seeks to avoid the burdensome task of manually creating / starting the content creation process. This persona serves as the focal point for our application design.

To cater to Admin level users, we developed a persona named Peter. Peter possesses limited knowledge regarding the content creation process, but he is keen on obtaining real-time reports on the ongoing processes.

Many of our initial design and functional decisions for the MVP were made with Beth in mind. Additional functionality for Peter would be added at a later stage.

Project aim

This project stands out as the first of its kind to be developed internally.

The Automation Dashboard was an idea to enhance our team's efficiency and reduce manual effort. It involved a group of individuals, including myself, working on the back-end, API integration, Frontend development, UX & UI.

Designing the Solution

User flows

As a product team, we worked hard to develop concise and targeted user flows within the app that worked for the user's needs. One major objective was to provide useful visual feedback during the editing process 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.