Key UX practices in building geospatial applications

When building geospatial applications, the User Experience (UX) often takes second place to functionality. This is not an issue if simplicity is the aim, but it’s rarely ever the case for geospatial apps and when navigation is both an essential function and the heart of the experience.

While the processes of application development remain the same, such as defining a customer’s problem, user testing and iteration, there are a number of other considerations when it comes to geospatial applications. To provide some guidance, here are my top tips.

Establish clear objectives

Establish objectives that address a customer’s problem. Taking the example of a utilities company, objectives may involve making workers safer, reducing disruption to road users during site digs, and reducing the time to access information.

The ideal scenario for any application developer when it comes to UX is to be given free rein to size-up the users’ wants and needs. For geospatial applications, a userbase will typically span multiple platforms and contexts. A B2B application for a utility organisation will necessitate usability for field workers via tablet and mobile devices, as well as in-office team managers, who may need to work with the same interface and information via a PC.

Sometimes, features must be sacrificed or prioritised when it better suits a certain userbase. For a web-based application to work across all formats, there must be compromise. But the compromise should always favour users whose problems most inhibit reaching the objectives agreed upon at the project’s beginning. If a certain feature massively reduces the time it takes for teams in the field to complete a job, but is less than ideal for in-office personnel, the former should take precedence.

Initial interface concepts and wireframes that unearth where compromise is made must be workshopped before the first round of user testing can begin.

Make workshops inclusive

Workshopping ideas with as many stakeholders as possible is an important step in developing any application. Workshops allow designers and developers to play back their interpretation of what the stakeholders and users say they want. This gives everyone the opportunity to tell you where your understanding of the problem might be going wrong. The next set of wireframes can then be updated to include the core functionality identified in the discovery session, and so the process of iteration begins.

Formats, capabilities and the inherent restrictions of users must be taken into account to achieve optimal UX. Put simply: the application must be as inclusive as possible. The most simplistic mapping interface, and one with which most people are familiar, is a 2D bird’s-eye view of an area. But when building a data-rich geospatial application with interactive features, zoom capabilities, compelling visualisations, etc., designers must consider factors that might exclude users or compromise functionality.

Overlaying information in mapping and location applications is standard, but how many layers before clarity and legibility are compromised? Are there existing precedents for design for the user’s industry, such as colour schemes and graphical representations?

Designing for inclusivity means considering these inherent design factors, but also those relating to the users themselves. Age, physical limitations, role and technical knowledge need consideration. Take infrastructure projects. There will likely be dangerous features that must be made conspicuous in a geospatial application for workers. Might a colour-blind user’s life be endangered if they cannot identify a warning colour? UX designers will tell you that colour should not be the sole identifier.

Again, the most effective means of determining the most inclusive result is to engage with users, which is where user testing comes in.

Be cruel to be kind

When testing your application with the people who’ll use it, it’s easy to fall into the trap of coercing them into the experience you want them to have. Effective user testing is almost entirely hands-off. This avoids leading questions and a linear set of tasks that give the game away. Then you can simulate (as much as possible) what it would be like for this person to see the application for the first time.

During testing, answer every question with a question. For example, answer: “What happens if I click on this?” with “What do you think should happen?”. Answer, “Where do I find the map?” with “Where would you try to find it if I wasn’t here?”

Wait until the user is clearly stuck before helping them on to the next part of the journey, so you can test the next part of the application, after noting down that the user got stuck at this stage.

Let the user know it is system you are testing … not them. Make that clear at the beginning of the test, and again, every time a user looks flustered or uncomfortable. Simply letting users know that others have experienced similar difficulties, and that their feedback is valuable, highlights that their inability to work your interface is your problem, not theirs.

Testing for flaws

An effective way to expose some of the flaws in any early interface design is to test with whoever is to hand. Do this testing before visiting your customer. When you test with people in your own organisation first, you must accept that they are not the actual users, so you will only learn so much.

Finding and solving navigation, or terminology issues before sitting down with real users makes that second round of testing with real users more valuable and less liable to be derailed by things that could have been solved earlier at the office.

Open the design process to all

Too often the design process is seen as the domain of the designer. Breaking this preconception and ensuring UX researchers, interface designers, developers, technical architects and product owners are included in early engagement with users and the creation of early concepts is a tough, but worthy cause.

Earlier collaboration leads to better outcomes and more beneficial engagement from every area of the project team. Involving everyone creates empathy for the people you’re building for, leading to more productive arguments over features and screen designs.

Geospatial applications vary wildly in their scope and functionality. They can get unwieldy quickly, with complex requirements and interfaces. Therefore, robust, collaborative design practices must be in place to deliver outstanding geospatial applications.

To assist, Ordnance Survey has released a wealth of new free open data downloads (https://osdatahub.os.uk/downloads/open) as well as open data and premium data available as new APIs (https://osdatahub.os.uk/). It has also published quick start guides, documentation and code example at http://os.uk/developers

Steven Attewell, Senior User Experience Designer at Ordnance Survey, has designed many geospatial applications for industry and government, and was part of the team behind Ordnance Survey’s award-winning app, OS Maps.