Though search began as the core product for such prolific companies as Google, today, it’s ubiquitous. One can imagine the countless engineering hours spent fine tuning search as a product—how data would be indexed, how to best prioritize and display results. A truly engaging search experience requires planning and designing specifically for search; it can no longer be considered simply an add-on.
Companies that focus primarily on search have set the bar very high. These days a variety of search interfaces beyond text are available to get people the info they need when they need it, including voice (e.g. Siri, Cortana etc.).
Keep in mind these four key considerations when planning for search:
1. What do you want to search?
2. What Enterprise system(s) is the data stored in?
3. What’s the quality of the source data?
4. What’s the end user’s expectation in finding the information?
For example, let’s say you’re designing a mobile app that audits employee performance. It needs to be able to display an employee list while also allowing the user to search the entire employee-list for the company. It turns out this data is stored in the company’s active directory, but as three different fields: first name, last name, and display name.
First you should discuss the data quality with the team in charge of managing the data. Are the records complete for every employee? If not, how will you manage end user expectations when the mobile app surfaces data of poor quality? At what frequency is the information refreshed? Are there other apps that use employee names? What fields do they leverage?
Now consider the end user experience. When searching for someone, the most common expectation is to enter the person’s first and last name and find them. Sounds simple enough. But if you are using a ‘starts with’ search and your data in the display name field is formatted “last name, first name,” you won’t return any matches. Further, the presense of ‘starts with’ will prevent you from finding matches even in the individual first name and last name fields. In this example, though the app is designed to engineering specs it won’t deliver the best user experience. From a technical perspective one solution is to break apart the search term at the spaces and then query them separately, filtering out any duplicate results. And remember, despite all the technical work, from a user perspective it’s still very simple: enter someone’s name and find them.
Once you have defined what you are searching for, the source system(s), quality of source data, and end user expectations, there remain several mobile-specific factors to consider. Think about what happens during a search (as the progress-wheel is spinning): the app hits the backend with a request, databases are searched, and a formatted result is returned. This result is then downloaded back to the device before being interpreted and displayed. All in a matter of seconds. But this spinning progress-wheel, it feels slow, even the ones on travel apps that use animated icons to distract you from the boredom of waiting.
With any network search you must also accommodate latency issues by providing a way for users to re-initiate the search should they lose their connection.
To solve these issues and dramatically improve the user experience, find out if a data subset exists that can be pulled down to the device in advance to reduce backend work for the entire query. For example, if the offices are small enough the app can download the entire employee office list and then query that locally. This will return results far quicker than a large company-wide search across the entire system.
In recent years much progress has been made with contextual search. In the consumer space, for example, displaying data related to the user’s friends or connections is commonplace. So the app isn’t searching a large data set, but only the most relevant information for that user. This results in a closer match, quicker results and an overall better experience.
In the Enterprise, this capability can only evolve to further improve the user experience; a user searches for an employee in another office, then performs an audit on that employee, then searches and performs an audit on another employee in that office. The app recognizes a trend forming and uses a search-threshold to download the employee list from that office. In other words, the app is anticipating the user will search for other employees in that office in the future. It’s predicting user-behavior. And when he does, the search experience will be real time and seamless.
Many opportunities exist for improving enterprise mobile search. After addressing the key considerations of developing a well thought out search plan, companies must decide the extent to which they want to build out search in their mobile apps, keeping in mind the potential return of a greater investment. If you’d like some help optimizing your company’s mobile search experience (or anything else mobile for that matter), be sure to check out our App Scoping and Prototype Kickstart or simply give us a call at (888) 405-2820. We’re here to help.
Mobile Strategist / Mobile Product Manager