Locator Planning Guide

This guide provides a concise framework for planning a typical Enterprise locator project.  It outlines a plan for organizing resources, stakeholders, data and user experience.

Introduction

This document provides a framework for planning and executing a Locator project.  A Locator Project in this context is loosely defined as a web-based application that allows users to find the nearest location to them.  The location might represent a store, dealer, repair center or installer.

This is not required reading prior to engaging with MetaLocator.  The Enterprise services team walks the customer through each phase in a white-glove engagement.  This is a great way to look ahead at what topics will be covered and understand what to expect.

This guide is not specifically designed to only apply to a project that involves our software.  The steps outlined should be applicable to any locator project, large or small.  This document can be used prior to engaging a partner, such as MetaLocator, to implement your locator.  Implementing the steps in this guide will provide a comprehensive baseline of information and raw material for efficient implementation of your locator project.

Intended Audience

This guide focuses on the processes germaine to Enterprise-class projects.  The amount of planning and consideration for a world-class, global locator that can generate millions of dollars of annual revenue is often overlooked, or underestimated.  This guide seeks to itemize those planning steps essential to success in larger organizations; however, the concepts apply to organizations of all sizes.

Timeline and Resources

Early in the project it will be necessary to set expectations regarding the total amount of time and resources needed from all parties involved.  MetaLocator projects can last from 15 minutes to 15 weeks depending on scope.  However, a typical Enterprise project that includes design, planning and execution is commonly 12-15 weeks.

A client-side project manager may dedicate a significant amount of time toward collecting requirements, gathering consensus, approving work and performing basic acceptance testing.  In MetaLocator Enterprise projects, we establish a weekly meeting to report on progress. 

Other members of the project team might include stakeholders from marketing and IT departments.  We commonly work with a point of contact responsible for visual elements and marketing, a technical contact responsible for the Website and data-focused contact who is responsible for collecting data for the locator.  Larger projects include Quality Assurance and Web Analytics stakeholders.  These points of contact can be entire teams or individuals depending on the size of the client and project.

Summary

• Set expectations for a 12-15 week project.
• Set a weekly meeting and plan for approximately 40-100 hours over the course of the project.
• Involve stakeholders from IT, Marketing and Data.

Data Specification

A complete data specification is a critical aspect of a locator project.  It involves enumeration of each data point in the locator ensuring that there are standards established on how that data is to be collected and stored.  The taxonomies that define lists of products, services or amenities at a given location should be codified across the organization.

In MetaLocator there are a few essential classifications of data to consider for each location:

1. Address data – The geographic street address, including street, city, state and country code.
2. Business data – The name, description, hours, social media, primary image and gallery images.
3. Contact information – The email address where lead inquiries should be routed and the various phone numbers stored separately for mobile, landline and fax.
4. Segmentation data – Larger organizations will have a series of segments such as Group, Division or Brand.  Segment fields can be used to determine which locator, or locators, the data will appear on.  They can also be used to determine audience, such as Commercial v.s. Residential.
5. Category data – The lists of products, services, industries, brands and other multi–valued attributes that will be displayed on the results or available as search options. 
6. Territory data – In a Sales and/or Distributor locator, a specific territory is often specified
7. Unique identifiers – A way of identifying each record in your organization.  E.g.  SalesForce Account ID, or other ID.
8. Custom Fields – Custom attributes that might not fit other categories above, such as a Store Manager Name, Toll-free Number or Profile Photo.

The above list is not entirely exhaustive, but includes the most common data attributes that MetaLocator encounters on a typical project.  The support article on preparing data for import into MetaLocator is a great place to start. 

A spreadsheet should be created to track the specific column names used for each type of data outlined above.  In contract implementations, MetaLocator leverages an internally curated Data Preparation Worksheet. A preview is shown below:

The data preparation worksheet includes the following, at a minimum:

1. The name of the field
2. The specific data type and length
3. What control type will be used to input the data
4. What output type will be used to display the data
5. Whether the field is required 
6. Field and Row Validation
7. Sample data

In MetaLocator, the data is used in many places to actually build parts of the user interface.  For example, the drop-down lists of products and services are populated directly from the data.  Therefore, it is important to ensure that the actual values imported are appropriate for end users.  Obscure product names or organizational/industry jargon should be avoided.

Contact us for a copy of the spreadsheet pictured above.  It is a great resource for gathering a complete data specification to ensure data is ready for import into MetaLocator, or likely any other similar locator platform.  

Collecting data for a locator project can often overlap with defining what features the locator will offer.  For example, searching by product type requires that each result be categorized by product type.  This interplay is natural but can result in conflicts between the locator feature requirements and the available data.  It is critical that the designers of the user experience (UX) are in regular contact with the staff responsible for organizing and collecting data.  Expect to update the UX designs based on data that is actually available.

Summary

• Consider data from the 8 key data categories above.
• Create a data specification worksheet.
• Ensure UX teams are working with real data.

Data Sources and Updates

Data in a locator needs to be updated on a regular basis.  The process of updating data can sometimes involve multiple data sources.  In MetaLocator Enterprise projects, we commonly have different data sources based on the team or division within the client organization.  For example, one department can maintain data in Salesforce while another is making manual updates directly in MetaLocator and a third is using Google Sheets.  

Regardless of the source, the data should be presented to the locator according to the Data Specification determined above.  MetaLocator provides a mapping facility to help transform data from one system to another.  Enterprise ETL tools can also provide an intermediary layer for assimilating data into a standard format before synchronization with a locator platform such as MetaLocator.

The MetaLocator platform itself is also a data source.  It provides data quality and enrichment tools such as email, address and phone validation.  Assimilating these corrections into the organizational source of truth for the data ensures that data quality, accuracy and completeness improves over time.  MetaLocator provides facilities via manual exports, APIs and SFTP endpoints to help with data exporting.  

This below graphic shows a handful of important data sources that might contribute to a locator project.  

Summary

• Identify all sources of data for the locator.
• Ensure all data sources can produce a close representation of the data specification.
• Plan for regular updates to the data.
• Data should come out of the locator better than when it went in.

Product Data 

Locators are often positioned as the answer to the question “Where to Buy”.  In order to properly answer that question, importing product data into the locator becomes necessary.

Products can be represented in a few different ways.  Most MetaLocator customers actually use Categories to represent the products, brands or families available at a given location.  This is a relatively simple approach when maintaining product data is too cumbersome or the data may not be accurate.

MetaLocator also supports importing a complete, SKU-level inventory for each location, with its own categorical hierarchy.  However, we often find that our customers don’t maintain data at that level of granularity, or that it is not very reliable.  

See this article for the various options available for importing product data.

Summary

• Consider what sort of product data is available within the organization or whether it should be purchased.  
• Select a strategy for answering the “Where to Buy” question.

Buy Online

MetaLocator commonly combines a locator into online and in-store options as shown below:

MetaLocator can even provide the data for buy-online applications.  During planning for a project that includes buy-online, the list of supported retailers and their Websites should be identified on a per-locale basis.  See this article on choosing good retail partners.

Ultimately “Where to Buy” can and should be both online and in-store.  Providing a hybrid locator option gives users a single, convenient user interface to make the buying decision.

Summary

• Choose retail partners based on best practices.
• Consider outsourcing the buy-online data as it can change often

Wireframing

Wireframing is the process of creating (very) approximate visual representations of the primary user interfaces in the locator.  The wireframing stage is used to capture requirements from the business stakeholders and translate them into a working user interface.  The wireframe should represent the final product in all manner of functionality and content.  

A good wireframe has the following properties:

• It contains a complete representation of data and actionable UX elements
• It is organized with primary, secondary and tertiary user objectives in mind
• It avoids design details and minutiae, but considers element placement and visual hierarchy.

MetaLocator uses Balsamiq, Figma and Invision to support our wireframing projects.  When choosing a wireframing tool.  Ensure that the resulting wireframes are:

1. Easy to modify
2. Simple to share and provide comment
3. Retains a version history

Two essential rules when creating wireframes bear repeating:

1. Wireframes are supposed to be skeletal and structural and should not be burdened with design standards or particulars around spacing, fonts and details.
2. Wireframes should include a complete content inventory.  Each and every data field in the data specification created above should be represented.  The length of lists should be based on actual data.  The contact forms should include the actual fields required by the marketing team.  

A complete set of wireframes can be handed to the design team for execution while minimizing the need to go back to business stakeholders to request clarification regarding the function or role of interface elements.  An example wireframe is shown below.

This is one of many wireframes in a locator project.  A typical wireframing inventory consists of mobile and desktop views of the primary user interfaces in the end product.  We also include various “empty” states, such as when no results are available, or when a certain result is missing data.

The wireframes should be reconciled with the data team before moving forward.  The data team should look at each data element separately and ask, “Do we have this data, in the format shown here?”.  If the answer is “No”, then either the data team should seek to supply the required data or the wireframes should be updated accordingly.  There is a natural and productive tension between the wireframing/UX team and those responsible for the data.  The wireframing team should be focused on UX, which ultimately serves the customer.  The data team should ensure the locator will have the data needed to support the content, search and sorting rules inherent in the design.

Approval of the wireframes is an essential part of the planning process.  Wireframes are inherently “sketchy”, in that the layout is supposed to look rough.  This can sometimes confuse stakeholders into thinking that they are inconsequential or not final.  The wireframes should represent the complete and final package for both functionality and layout.  The resulting design and final product will look materially similar to the wireframes; of course with the organizational branding applied and an overall boost of creative energy.  Before proceeding to design, ensure that all involved have invested the time and energy to vet the wireframes and ensure all requirements are met.

Summary

• Wireframes are a complete specification of the locator project.
• Wireframes should be complete and comprehensive but avoid design and creative topics.
• Sign off should indicate the end of the planning process.

Integration Points

A locator can and should tie into various parts of the Web site outside of the locator itself.  Consider the below screenshot which includes a link to the locator as part of a Nearest Location widget.  

This integration point is an example of how the locator can be tied into various other aspects of the Web site.  Other integration points include:

• A Where to Buy button which might link from a product detail page.
• Deep Links from Products and Services pages that link to the locator with pre-set searches. 
• A Nearby Widget as shown above that might be placed in the header of every page on the Website.
• Language selections should carry through to the Locator.  The user should not have to select their preferred language again if the Website has already determined it.
• Links from the locator results to various places on the Website, e.g. to a description of a product or service.

These integration points may impact the overall Web design strategy and may involve other teams and resources outside of the locator project.  Involving those teams early in the process will ensure collaboration and buy-in. 

Summary

• The locator should include inbound and outbound connections throughout the Website.
• A nearby widget may impact the header of the entire Website.
• Content teams should know how to link into the Website and take every opportunity to create deep links.

Asset Inventory

Before moving into the execution phase of the project, the following resources should be identified.

1. A test page should be created on the Website where the locator will be installed.  MetaLocator will request that our installation code be added to this page.  The test page should be identical to the final page that will be used in production.
2. Design assets including font files, high resolution versions of the logo and photography.
3. Brand standards such as color palettes, logo placement and spacing requirements.

Design

The preparation work done up to this point is the lion’s share of the work.  The Wireframes and Data specification are typically where the most time is spent in our planning and requirements gathering.  Once Design begins, we have moved into the execution phase of the project.  

The objective of the design phase is to create a pixel-perfect representation of the final product.  The primary output of the design phase is a design file for each wireframe.  A sample is shown below.

Designs are hard to modify as compared to wireframes.  However, gaps in the wireframes and data specifications can sometimes arise.  When that happens, MetaLocator will update the wireframes first before integrating a change into the design.  Another sign off is obtained and the design process resumes with the changes.  Rigid adherence to this process ensures that changes are not wedged into the design, but instead consider the full breadth of the planning and consideration of the wireframes.  A series of what some may consider to be small changes can often aggregate to diminish the overall user experience. 

Summary

• Create a pixel-perfect, developer-ready copy of each wireframe.
• Consider empty and edge states, such as very long location names, missing data or minimal data.
• Sign off should re-affirm that the final product will look identical to the design.

Internationalization 

A multi-language locator application is common in global deployments.  Internationalization is defined as the process of making the locator highly usable in multiple languages, geographies and cultures.   When planning for internationalization the following topics should be considered:

1. Create an inventory of each language the locator will be translated into.
2. Measure distance in units appropriate to the locale (miles v.s kilometers)
3. Orient the display appropriately for languages that are written right-to-left.
4. Link to directions applications that function in the target locale.  For example, Google does not operate in China, so Baidu maps should be used for directions there.

Tip: We don’t usually recommend translating your address data.  The address itself should be local to the geography of the address itself.  Consumers of the local data are commonly familiar with the local addressing system.  The overhead of managing multiple language versions of the address data can often be more trouble that it is worth.

Accessibility

Locators should meet WCAG AA accessibility standards at a minimum.  Depending on the client’s compliance requirements MetaLocator may also recommend federal section 508 standards as well.  

Analytics

Locators, such as MetaLocator, are often single-page applications, where the user takes multiple actions on the same page to reach their goal.  This makes measuring the activity within a locator unique.  Consider the following visits to a locator, each of which includes a user reaching their desired goal.

Use Case 1

1. The page loads and the locator displays nearby results automatically.
2. The user immediately sees a nearby location and dials the phone number to reach the location.

Use Case 2

1. The page loads and the locator displays nearby results automatically.
2. The user searches for a different postal code than what was automatically detected.
3. The user clicks a “Contact us” button and completes a form to request a quote from a kitchen remodeling contractor.
4. The user clicks a different  “Contact us” button to complete a second request from a different remodeling contractor.
5. The user zooms and pans the map to get a sense of how many nearby locations are available.

In both of these scenarios, the user obtained the information they needed; however the analytics tracking scenario may look very different.  Some analytics packages might look at Use Case 1 as a “bounce”, which in this case would be incorrect.  There are many other use cases to consider beyond the above examples.

The most valuable action is to decide on meaningful definitions of success that matter to your organization.  MetaLocator commonly recommends focusing on outcomes such as Clicks to Call, Leads Generated, Directions, Purchases and other measurable actions that are conversion-focused.  

Conclusion

Locators overlap with many different technologies, processes and standards.  MetaLocator helps organizations of all sizes navigate a successful locator program.  The planning resources outlined in this guide will assist in uncovering the myriad areas where the locator can advance the organization’s goals.  The items in this guide include the fundamental, essential planning aspects, yet there can be more to consider; such as search-engine optimization, text-messaging and voice applications, mobile app integrations and much more.