Brief
I was asked to look at the design of a search mechanism for an app-based information system. The current implementation was outdated and lacked a number of features that were considered important by the business, in particular the ability to link into follow-up actions within key apps. The proposal was to build a new UI with a refreshed look and new functionality. It was hoped that this would increase use of search and thereby drive further use of the app ecosystem.
Review
I began by reviewing the existing UI and exploring the current functionality with users.
The key issue with the existing interface was the lack of an ‘All Results’ page. This meant that users had to choose from one of the result types before running a query. Users tended to miss this choice and were surprised to get results that did not match their expectations.
The results were also hard to scan and loaded with filtering options that users did not find particularly useful.
Beyond the design, there were significant challenges with the results that were returned. In many cases it was not clear why particular items were returned, or what determined their ranking. There were also regular instances of missing data.
Search Logic
To understand the behaviour I tested the search with a range of different keywords and filters. I was able to establish that the search logic was different for each of the three data types.
The app search used an implied Boolean ‘OR’ for spaces. This meant that adding words to a query increased the number of results and reduced their overall relevance and value. I recommended that all of the searches used Boollean ‘AND’ by default, as this is the most familiar behaviour for users and provides the most power with no requirement for specialist knowledge.
Deeper Investigation
I worked with the technology group responsible for search in order to understand the ranking issues in more depth; to explore the feasibility of implementing some of the desired features; and to understand the investment required to build the new UI.
It became clear that there were significant challenges in maintaining the existing infrastructure and that addressing some of the key existing problems (as well as implementing new functionality), was not feasible without significant investment. Building a new UI at this stage would draw investment away from these necessary developments. To help management understand the situation, I created a dependency matrix, illustrating where desired features sat in terms of whether they required a new UI, whether they needed significant backend work, or both.
Using this matrix, I was able to demonstrate that building a new UI would deliver relatively few benefits without delivery of backend upgrades that would require significant investment. However, current prioritisation was spreading limited investment across multiple streams of work. In response, management agreed to focus investment in addressing the key backend requirements, reserving significant UI development for later in the cycle.
Wireframing
In order to continue the discussion around the new UI, I began wireframing in parallel with the backend work. Given that complex features would be contingent on additional backend work, I proposed a simple design that could be incrementally improved as new work was done. The focus was on a clean and simple presentation of results and the implementation of an ‘All Results’ page, whilst ensuring that the first version could be delivered using only existing capabilities.
Martin Colebourne 