How to Create a Web Tool People Will Actually Use
Developers, it’s time to kill the assumption that the end user of your product is as technical as you are.
This is reality: Web editors or people in similar positions using web services, e.g. analytics, most likely have absolutely no technical or even analytical marketing background. They are more likely to come from a communications or marketing background and for them the task of monitoring and analyzing their website’s data is a role that has been delegated to them. Usually either due to the lack of a designated web analyst, or simply because they’re already working with their organization’s website on a daily basis.
So with this in mind, what should product developers do to ensure a positive user experience (UX)? In my team, we operate with three overall aspects when it comes to developing a user-friendly service: 1. Understanding, 2. Support, and 3. Usage.
Making a web tool easy to understand includes using intuitive visual presentation; layman’s language; and recognizable iconography.
Take the front page dashboard of a tool, for instance. The main purpose of a dashboard is to visually present data, usually through the use of charts and graphs. From a UX perspective not all charts are equally effective. The pie chart for instance is hopeless; cognitively it’s simply too difficult to make sense of. (Admittedly: our users are very much familiar with having a pie chart in their Analytics dashboard, which is why we keep it there, for now.)
This ties in with choosing the right terms: Label a chart based on what it shows, not what it is. Call it ‘Website visits over time’, not a ‘Histogram’. A web editor should not have to recall high school math classes in order to understand their analytics dashboard.
In regards to iconography, there’s no need to reinvent the wheel: If the globally used icon for search is a magnifying glass for instance, and this is used on 99% of all websites, you might as well use it yourself: That’s the whole point of iconography.
User-friendliness is also about support. Or rather, the better the UX, the less need there should be for continuous support and training. If you’re managing a web team, this is an aspect that could really save you resources. When deciding whether to purchase a web tool, consider the following: Is the tool so intuitive that it keeps the level of training required for your current and future team members to a minimum? Will you have easy access to personal support should this be needed? To what extent can you set up the tool yourself and begin using it?
The single largest obstacle of most web tools are that once the users have gained some understanding of them, and maybe even received training in them, they never actually begin using them. The reason for this being that the abovementioned aspects haven’t been thought through by the developers. Take Google Analytics for example. Clearly this was developed by techies for techies. There is too much information with unclear labels, too many cogs and wheels to consider, and the initial setup is rather cumbersome. This is enough to discourage the average web editor from ever getting started using it.
It’s simple, really: For a web tool to be used, the joys of using it have to be greater than the pains of using it. In other words, the satisfaction gained from converting a data report, for example, into a tangible improvement of your website’s content has to outweigh the perceived trouble of setting up said report.
Another way to encourage actual usage of a tool is to consider which channels to utilize for delivering data, reports, etc. to the end user. Perhaps a summary through a mobile app is a better medium than sending PDFs or spreadsheets to an email.
How We Work with User-Friendliness
On my team we always develop the Siteimprove Analytics module with two fictional personas in mind, based on customer interviews and observations; Carina the Web Editor and John the Web Manager. Both of them are end users of our product, but we develop it mainly with Carina in mind. The main objective for us is for Carina to have an enjoyable experience in her daily usage of our Analytics module.
Myself, as well as the other Product Owners at Siteimprove, go out to physically meet our end users, to spend time with them, and to see how they use our product. I once spent a day with a prominent American university and immersed myself in their web management work to get a better understanding of their daily usage of our services; which challenges and issues were raised in website-related meetings and how they ensured the necessary training etc.
Furthermore, we allocate quite a large portion of our team’s resources specifically to UX design, and make sure that UX and Development collaborate in an integrated manner on our product.
Finally, we often allow for direct user feedback through beta testing as is currently the case with our exciting upcoming features!
Speaking of which, we have a major update of our Analytics service coming up, which will give you even more business-critical information about what visitors to your website actually do when they’re there. To be the first to know about Siteimprove updates, please sign up for our monthly newsletter.