“I’m terrible at UI design,” said every business application programmer I’ve ever met. “I’ll do the backend stuff, but frontend design should be done by someone with an eye for it.” When I say that every business application programmer I’ve ever met has said this, I mean it literally. I count my former self in this group. I used to stay as far away from UI design as I could, hoping someone else would “make it pretty.”
The good old days of Windows applications…
Design used to be relatively easy for the Windows application developer. Microsoft would produce UI design guidelines, programmers would follow these guidelines while using Microsoft-provided tools such as Windows Forms, and out would pop yet another gray-themed application with a strip of buttons and menus on the top and data entry/data visualizations on the bottom. There was almost always a subset of File, Edit, View, Window, and Help menus at the top of the application, and the Save button would always be in the same place. The application would almost always be battleship gray, for the simple reason that this was the default Windows background color and developers would never bother changing it. Very boring, but it was a dead simple design paradigm that developers never had to worry about. The arrival of the World Wide Web changed all of this.
Innovative design doesn’t necessarily imply good design.
Modern web application design. Attractive and functional.
So now Windows application developers were put into an uncomfortable situation. They never had to seriously worry about the finer details of UI design or any innovation before; most of the hard decisions were made for them by Microsoft. That world was fading, though, and the new world was much freer from a UI design standpoint. They now had choices, and the choices mattered. Creating unique-looking designs was now a good thing. The paradox of choice that this new world presented froze many developers dead in their tracks. What once was “Yeah, I can design that application” became “We should hire a designer to design the user interface for that application, I’ll just stick with the code.”
At Water Sage, our dev team does not have access to a full-time designer. I’d imagine this is the same boat that many smaller dev teams find themselves in out there in the real world. We have made use of some part time designer work to help do things like pick basic color palettes and some of the simpler layouts, but most of the UI design choices have been made by the dev team working with the product team over the course of the last three years.
Our approach to the UI design has been to follow a simple philosophy. We imagine being in our users’ shoes, going through very specific use cases. From there we imagine how we would want an ideal application to work. Then we build that application.
A lot of the time this comes down to “how should the application work to get my job done as fast as possible,” but this isn’t always a practical way for an application to work. If we designed an application that was streamlined for every possible use case, we would end up with something akin to a Task Based UI (UI is short for User Interface). An example of this is would be Windows Control Panel (seen in the picture below):
Windows Control Panel
There is a link for every common use case that the designers would think a user might have. For example, if I am a user and want to change the Windows theme, I would click on “Change the theme.”
This kind of UI is a good idea when there are a small number of use cases and they are very well defined. In my opinion, there are too many use cases on this Control Panel screen, and they are too broad. For example, the “Add a device” link. What does this mean, like “add a mouse?” I just plug the mouse in and it works, right? It turns out that Windows can automatically recognize some devices and not others, so they came up with a use case task link for the later. This nuance is not represented in the link text, so the link is too vague. This kind of nuance with use cases is a reason that Task Based UIs aren’t always the best fit. With an application as complex as Windows, it would be very hard to come up with a solid list of specific tasks, and I think therefore the Windows Control Panel is not a good UI, or at least not a good fit for a Task Based UI.
Water Sage has so many use cases, each with its own nuance, that using a Task Based interface seemed to be a bad fit. This grew out of the requirement that we support a diverse set of users and market segments, from farmers to real estate agents, to water engineers, and so on.
So, what other options did we consider? One option was to make the application work like popular GIS tools like ESRI ArcMap and QGIS. Water Sage is in many ways a GIS tool, so it would seem to make sense to follow the lead of the most popular GIS tools on the market. The dev team all had different levels of experience with these tools, so we looked for what we felt those GIS tools did right and what they did wrong, at least regarding an application like Water Sage. One thing that you may notice if you look at the screenshot of ArcMap below is that this looks a lot like a classic Windows desktop application (see the screenshot at the beginning of this post of the Windows WorkPad application from the 90s). There are some benefits to designing an application around this classic desktop application model. First is user familiarity. Users that have used older Windows desktop applications would instantly know where the “Save” button is, so we wouldn’t have to educate them. This goes for many of the other elements of the application, such as the menus, the Print button, etc. Another source of familiarity comes from the basic layout and mechanics of the application. You have “layers” that you can turn on and off and objects on the map can be interacted with simply by clicking. A big downside to this kind of UI is that it can appear overwhelming to the novice user. When I look at ArcMap, I don’t know what two-thirds of the buttons do. If I wanted to do some basic land and water rights research, I would spend half my time clicking the wrong buttons, searching through menus, and probably screwing the whole thing up in the end.
ESRI ArcMap – so many buttons
So, we decided that this kind of interface, the classic GIS desktop application interface, was too complex for our average target user. If I was a user of a system with a user interface like that, I would be impressed but confused, a lot. That wasn’t the experience we wanted our users to have.
The other end of the complexity spectrum for a GIS application is occupied by web-based tools like Google Maps (screenshot below). Google Maps is a combined search application with a map visualization. This sounded a lot like what Water Sage was. Google Maps is very map-centric, as most of the screen is occupied by the map, with the search functionality and navigation functionality floating on top of the map. This type of interface is much more approachable for the average user than the ArcMap interface. The amount of data presented to the user at one time is kept to a minimum, following Google’s general style of application user interfaces. We all really liked this concept. However, Water Sage was in part an analytical tool and it had to be capable of much more than what Google Maps was capable of. Still, the ideas of having the application focus on the map, and limiting the amount of information presented on the screen at any given time, inspired us.
Google Maps – so nice and simple
Not every UI idea was inspired from other popular mapping applications. We also spent a lot of time thinking of the ideal way that we, as users, would want to interact with the system, and coming up with our own ideas based on this.
An example of designing functionality based on how we would want to interact with the system would be our multi-layer selection ability. When there is more than one object or layer on the map covering up another object or layer on the map, the user sometimes wants to see everything that is at that location, but they can’t. We are stuck with a 2-dimensional display, so it’s not like the user can turn the map on its end and see all the layers of information in a cross section, at least not without some fancy map-rotating mechanic. The way ArcMap and QGIS handle this problem is by asking the user to first select the layer that they are interested in from their respective layer managers, and then clicking on the map location. You can only have one layer selected at a time, so when you click on the map, you only see what is at that map location for that one selected layer. We found this to be terribly confusing and backwards. So, we flipped this on its head and designed this functionality to start with the user clicking at a location, and then we show everything at this location in a stacked list (see the screenshot below).
Items at Location feature – viewing everything at a location
This seems like a much more natural process for finding out what is at a map location than first having to select the layer you care about, at least in our opinion.
So, our central design inspirations came from desktop GIS applications and Google Maps. We didn’t end up copying any specific functionality, but we did make use of the general UI ideas when we got down to doing our own design. From the desktop GIS applications we took the idea of familiarity. The application should have a familiar layout and have some familiar interaction mechanics with other GIS applications. From Google Maps we took the idea of focusing the application on the map itself and also by hiding as much information as we could from the user, unless the user showed explicit interest in something by selecting it. We also put ourselves in our users’ shoes and tried to answer the question of how we would want the application to work, in a perfect world. These techniques got us to where we are today, with the most usable land and water research application on the market. We are very proud of what we have produced and welcome any feedback you have to make the system even better.