BofA Site Search
Site search at Bank of America didn't work well: results were often inaccurate, relevant content was not crawled, no personal data was accessible, and the UI was unnecessarily complex. For a large, deep site like bankofamerica.com, search is a critical tool to help users find what they need quickly, especially when they may not know or guess where it lives within the navigation structure.
The needs were obvious, but finding great solutions was neither obvious nor simple.
Search is a fundamental tool and experience on the internet. Whether considering Google or, say, Amazon search, search tools are ubiquitous, of stellar quality, and drive customer expectations. For our new search tool - which we'd be building from the ground up, in-house - we knew these qualities were critical:
- Relevant results - Nothing else matters if you cannot provide accurate results
- Familiar conventions - Site search systems do vary from the web search UIs of Google and Bing, but there are many conventions that users expect. No need to reinvent the wheel.
- Know the customer - We recognized it could be of great value to our customers to bring personal information - account profiles, balances, transactions, and more - to bear in search results. This could move the search experience from good to great.
- Keep it simple - While we had powerful tools at our fingertips, we didn't want to create a 'power search' UI. We aimed to keep things obvious, relevant, simple and familiar. This drove us to resist the temptation to use filters, specialized search modes, and other frivolities.
We began with a broad competitive survey of the best search sites and tools around. There are not many stellar examples among banks, so we focused on web search - Google and Bing - as well as highly trafficked consumer sites: Amazon, Etsy, WalMart, Home Depot, REI, Toys R Us, to name a few.
Testing a search engine presents a unique challenge, since search by its nature allows users to enter queries that are inherently unique. Building a 'prototype' search engine isn't really a good option. So for early usability tests, we simulated the search experience and provided test subjects with specific search terms to enter. Rather than testing the search engine, we focused on evaluating the UI and asking users about their expectations and behavior.
Our research provided a great deal of insight. Key lessons were:
- Users aren't interested in 'advanced' search tools - filters, facets, or other controls. They understand that the best way to improve your results is to modify the query itself.
- It is impossible to predict how a user might structure a search. There is no finite list of search terms or keywords. Don't expect an average user to use your industry or company's terminology. Need to set a travel flag? Perhaps "Will my card work in China?" or "let me use my account abroad".
- People know how to search. Tutorials are not necessary, nor likely to be used.
- Dynamic tools like type-ahead, keyword matching, and search history are well understood and welcomed aids.
- The most important thing is the first few results - especially the very first result. Everything else is merely polishing the edges.
We had several months to plan, design, iterate and define a clear direction before the agile sprint cycle commenced. This was an important stage in our design process and allowed us to try some more experimental concepts, including a modal search experience similar to OS X Spotlight. From the competitive research and an examination of our needs, we drafted a number of UI concepts and ran several usability tests, using simulated search results, to test them.
Site search has significantly different use cases than web search. Namely, the result set is finite. And in our case, the universe of banking-related terms, concepts and content is limited. Unlike, say, Amazon, which might have a million or more products, a banking site has something more like a thousand possible user intents, with the vast majority of searches covering just a small percentage of that set.
This constraint meant that we were able to provide customized search results for many queries. It also meant that our search interface often would not require a full-page UI as seen in most search engines.
Click thumbnails to view full-resolution images of the final design in production:
The existing site masthead included a search box on all pages. We decided that we'd take advantage of this layout, and allow users to keep context when possible. That is, the search would be performed asynchronously and the initial result set would be returned in a dynamic page layer attached to the search box. For the large percentage of searches where we either had a customer answer card, or where the top organic results were what the customer was looking for, this design would save a page load, keep the search experience lightweight, and allow the user to keep context.
The search tool is currently in limited pilot, with full customer rollout in April 2015. Usability tests of the final UI scored very well, although there remain some items to address. While the initial ambitions included mobile and transaction search, we chose to push those functions to a later release, in order to ensure focus and high quality execution for our initial product launch. The search logic and function were built 100% in-house, and demonstrates extremely high success rates for a broad swath of scenarios. The new search tool is a massive improvement, which will certainly help users locate and use important financial tools and information in an easier, more pleasant way, when site navigation isn't their first choice.
With increasing percentage of usage and growing content and functionality coming on mobile, it is critical to bring the search function to our mobile app. As a conceptual exercise, I took some essential concepts and solutions from our desktop design, and applied context of mobile to how we might approach a mobile solution.