Data Previewer Improving search and location visualization for Factual’s front facing search interface.
Redesigning the Data Previewer, Factual’s location search interface 14 Week Internship Project – Worked as interaction design lead As a product design intern, one of my two main projects at Factual was redesigning their public facing search interface called Data Previewer, which takes Factual’s location data set and organizes it into a visually and contextually digestible format.
Factual is a location data startup, and Data Previewer is their tool to search locations. Data previewer started out as a hackathon project, designed to query through Factual’s location dataset and display it’s information in a more legible way for internal business, sales, and partner service uses. However, as the company grew, it started assuming the role of showing clients and partners a cut of Factual’s data.
Brinton H Business Development at Factual
“Many of the fields are never used and sometimes confusing.”
Kyle V. Partner Services at Factual
“The tool shows others a lot, but sometimes too much and becomes a liability”
Endpoint pages are a big liability for scrapping as it is easily exportable and accessible to third parties Data previewer is divided into two experiences: the navigation/search experience and the information/endpoint page. The endpoint page is a static page that houses all the information Factual has attached to a coordinate. This static page becomes a common place for competitors or scrappers to extract proprietary information
Above is an example of an endpoint page, where the name, location, address, phone number, and other attachments are displayed. Scrappers have been caught creating bots and scripts that crawl these pages and download the information.
Location in Data Previewer are not digestible for non-technical users Because the interface was originally built for internal users with data literacy, locations are communicated through lists, tables, and convoluted tags. While this may be useful to more technical users, textual representation is not a commonly familiar or impactful form of data communication to general users
As the landing search page, Data Previewer shows results in list with a lot of information such as ID's and Latitudes that general users are not familiar with. The search filters / parameters also adopt these technical jargons that make them hard to learn.
Data Previewer's interface no longer abides to Factual's current visual guidelines Data Previewer's UI is disjointed from Factual's visual guidelines. As part of improving both functionality and visual appeal, Data Previewer should adopt Factual's more matured and developed visual language, especially in a public facing use case.
Data previewer's interface uses color pallets and typography that are no longer used in other products, making it inconsistent from Factual's branding.
Improving search experience, visual aesthetics, and information security After our kickoff with engineers, I outlined Data Previewer’s problem space: product experience and security. Current product experience is affected by convoluted search forms and visual inconsistency. Security is compromised by the easily scraped and copied endpoint pages.
What is the best search experience for locations at different granularities? After our kickoff with engineers, I outlined Data Previewer’s problem space: product experience and security. Current product experience is affected by convoluted search forms and visual inconsistency. Security is compromised by the easily scraped and copied endpoint pages.
For this test, I wanted to know what types of syntactic patterns people use when searching for different location types. I created a fake "search field" and asked people to type their search terms based on my questions.
For another component of search, I wanted to understand how users interact with search and advanced filters. As a test, I created 3 different variations of search forms and asked people to complete different search prompts
Search fields should have labels hinting on the type of query being performed Although the iterations I presented had validated features, my stakeholders found the tool confusing due to the omni-search bar being too ambiguous. The main concern was the lack of indicators in terms of what types of queries or search that the search bar supports.
Brinton H Business Development at Factual
“How do I know that I am search gas stations as a category rather than a name?”
Kyle V. Partner Services at Factual
“It’s not clear on how I can filter my search – do I have to start a search or after?”
For this onboarding experience, I showed users a start-up dialogue that features textual examples of how to use the search bar. Users liked having a sample to help them quickly understand the search bar's capabilities.
For this example, I took inspiration from Google's search suggestions and provided pills of preloaded queries. This allows new users to click on different searches to see the different search granularities.
For this test, I wanted to combine both visual and contextual clues to help people understand search capabilities. Although all users agree that this is the most detailed method, many of them were initially confused about how to use the cards.
People need a balance between filter and typed input for flexible search After looking at how people were interacting with the prototypes, I learned that many were familiar with the verbal approach to search. Instead of using parameters as the primary way of searching, people were more comfortable typing in what they want to see in a single search bar. However, people still favored having different forms to refining their search.
Provide supporting text on search fields to teach users how to use the search bar Initially I assumed that people would be more receptive to having images and visual cues to learn about different search capabilities. However, because people mainly interact with the search bar, textual examples with icons as support were most effective in prompting people on how to format their query terms.
Simplified search experience with a single search field with suggestions Integrating Factual’s auto-complete capabilities, people have more flexibility in how they search, with more flexible syntax structures. The on-boarding screen also surfaces hints to users on what types of search terms they can perform, making the experience more clear and convenient.
Visualizing density through bubbled counts and size to reduce pin clutter Instead of showing clusters of pins on a map, the new previewer clusters them under a numeric bubble to show density and distribution. This gives the users a second layer of information regarding where most locations are most concentrated and dispersed.
Fine tune search results with built-in dropdown menus The new data previewer only features 3 filtering options: locality, region, and country. This allows people to more easily adjust how granular they want location searches to be in terms of scale.
Centralizing information to the sidebar for better readability and security The updated previewer tool eliminates the need for endpoint pages. Instead, information will be passed from the database to the tool sidebar, which better protects against scraping while improving readability. Additionally, data previewer now requires separate permissions to access features like exporting locations or sharing data.
Currently under development for internal release in mid to late 2018 The design changes have been pitched to stakeholders and approved. The final design has been specced and is currently under development and will be implemented for internal release in the middle of 2018. The full release will most likely happen at the end of 2018, incorporating feedback and design changes from internal testing.