Quick Summary: In part 1 of this article we defined the problem: store locators often suffer from poor usability. Here in part 2 we continue our look at ways to improve them.
Let’s continue where we left off with our examination of improving store locators.
Store locator best practices, continued
Avoid too many search criteria; offer flexible entry. Keeping the initial search simple and usable requires focusing on the essentials. A sensible minimum amount of information for most store locators is:
- ZIP code or City and state
- An optional search radius with a clearly defined default setting
Presenting separate fields for City, State and ZIP code is common, but it’s better to display a single field that can accept a variety of inputs.
The PetSmart store locator below meets these critera, though as I mentioned in part 1 of this article the minimum search radius is too large for areas with many stores. PetSmart would do well to add a 5 or 10 mile radius option then examine their log data to determine if customers use it.
In some cases it makes sense to also offer additional options. For example, a bank website may wish to enable users to search for ATMs or branch locations. PetSmart has veterinary services at some stores, and they wisely enable users to search only for these locations
Reiterate the search; enable follow-ups. Once the user has initiated a search, it’s always wise to reiterate the search criteria as part of the search results display. This reinforces successful completion of the action and reduces the chances for problems if the user has made an entry mistake (for example, entering the wrong zip code).
As I mentioned in part 1, it’s also sensible to make it easy for users to quickly change the parameters and conduct another search if needed.
Display a list view as a default. Some store locators display nothing but a large map for their store locator search results. Others use a list of stores, map with a list of stores beneath or beside it. It’s important to remember that some users may not want or need to see the map – some may want only to see a street address they can plug into their GPS. Or, they only wish to find the nearest store’s hours. So it’s sensible to include a list of stores – and to make sure it’s easily visible.
Use a good map. It seems silly to even point it out, but store locators should incorporate good maps. With a number of mapping APIs to choose from it’s a wonder some websites still rely upon relatively primitive and inflexible mapping services. Consider the difference between this map from the Circle K convenience store website and a map from their competitor 7-11:
This Circle K map of Mesa, Arizona locations is generated by MapQuest and has no options for user control at all. Users who wish to zoom or otherwise change the view are out of luck. They must conduct a new search with a smaller radius.
By comparison the 7-11 map, generated by Microsoft, is sophisticated and offers a great deal of user control:
Which would you rather use?
Consider making maps optional. Large map displays work well for users connecting from their home or office. But what about those with mobile devices? What about users who are looking primarily for the hours or a phone number?
For these and other use cases a very large map can be problematic.
One good approach is to default to a list, but also enable users to quickly see a map. Websites for Staples and its competitor OfficeMax both do this:
Note the prominent link to “View map of all stores…” located above the Staples search results, and OfficeMax’s prominent large green “MAP” buttons next to each listing. This is a better balance of information than the default large maps displayed by many store locators.
Both of these store locators work well on mobile devices. In fact Staples.com wisely displays a separate mobile-friendly version of their website when it detects a mobile device.
Avoid rich media for store locators. A number of store locators rely upon rich media like Flash to display search results. This is usually a bad idea*. In most cases Flash doesn’t add any real value to a store locator, and more importantly, some computers and mobile devices don’t support it at all.
The Bass Pro website employs Flash within its store locator search results. Here’s how it looks on a computer equipped with Flash:
But here’s how the same results appear on an iPhone, which doesn’t currently support Flash:
On first glance the user might well be drawn to the large blank area of the screen and assume that the store information can’t be displayed. As it turns out the store address and hours are displayed – to the left of the image. Still, this isn’t exactly an optimal experience.
Flash is a sensible technology for some applications, but store locator search results is not one of them. It’s preferable to use a simpler display that’s more widely supported.
* Side note: I’m not one of those “All Flash is bad” people. But I am a Flash skeptic and believe strongly it should only be employed where it adds necessary flexibility, and where it is widely installed among the intended audience. I don’t mean to pick on Flash, either. I apply the same logic to any use of rich media (videos, animations, etc.)
In part 3 of this article we’ll cover some additional best practices and wrap things up.
Photo by Alberto. Creative Commons licensed.
Related posts:
{ 4 comments… read them below or add one }
Nice article. I agree with you about the use of Flash; it’s usually used in places where it doesn’t help the user experience much.
Thanks for the article. I like the what to do / what not to do comparisons. The visual examples are great. Very helpful.
Thank you for this concise, clear and insightful post on locators. The specific information is useful; I looked up the examples to try them myself.
We’ve been through several iterations of our dealer locator, yet usability issues persist. We do not have the resources for extensive user testing. Instead we’ve learned a great deal by allowing users to comment via a link on the locator page. The insights have been eye-opening, and will continue to shape future refinements to the locator.
I would be interested in the author’s and others’ thoughts on using feedback links to collect usability information. Is this information useful or too subjective?
Thanks for the comment Michael. Glad you enjoyed the article.
In my view nearly all user feedback can be useful in one way or another. User feedback of the kind you’re describing is certainly subjective on a person-by-person basis, but that’s ok. As the number of feedback contributors increases it becomes possible to spot trends and similarities. That eliminates much of the subjectivity and transforms a random group of opinions into a usable set of data. In other words, if many people tell you that (for example) they didn’t notice the help link and would like it to be larger, it doesn’t really matter that each person’s opinion is subjective. In the bigger picture you’ve spotted a useful trend and can act on it.
One way to give structure to user feedback is to enable people to provide general, “open ended” comments as well as more constrained feedback via questionnaires that address the points you feel are most important. That way even before you start to spot trends in the general comments you can see statistically how users feel about the site’s effectiveness in certain categories.
One other thought before this becomes an article all by itself
I usually advocate enabling users to submit feedback anonymously, and to create very few required fields on a feedback form. That makes it quicker for someone to share their opinion (which means they’ll be more inclined to do so). It also reduces the chances they’ll feel awkward about sharing a critique or concern.