A four-year-old building search suddenly no longer delivers an optimal sequence of buildings found. In the worst case, users have to scroll through hundreds of buildings until they find the one they are looking for. Technically speaking, the search runs correctly because it always finds the desired result. From the user experience point of view, however, the feature is flawed. Using this building search as an example, we now want to show how we optimised the faulty feature in three steps and thus significantly improved the user experience.
1. Analyse the current state
For four years the search has been successful, what has changed? The underlying data! So far, the search only had to cope with 16,229 buildings, all of them from the Canton of Appenzell Ausserrhoden. Now, however, the search must also cope with the Canton of Zurich (225'660 buildings) and the Canton of Graubünden (69'984 buildings). It becomes evident that the order of the search results played a minor role for 16,000 buildings, but now with the larger data volume of almost 300,000 buildings, it becomes essential. Another problem became the overlapping of several attributes of the buildings. For example, the building number, the property number, the insurance number, the street number and the postal code can be the same number. Certain numbers can be alphanumeric and vary according to the canton. In concrete terms, the search for the number «10» can find several independent buildings beyond the cantonal borders, which is not in the users' interest. With these two identified problems we entered the next phase:
2. Planning the target state
How do the users search in this example? They enter either an identification number or an address. An address usually consists of more than one word. In both cases, users expect only a handful of results. What measures can we take to achieve this?
First, we decide what happens if a user enters only one word: In this case, only the identification numbers are searched first and only in the case of no results the street and town are consulted. The postcode and street number are excluded, because they overlap with the identification numbers and give too many results as a single search word. This also does not correspond to typical user behaviour. We also decide to search the streets and towns only with a so-called «fuzzy search» instead of with all attributes as before. This measure leads to significantly fewer results, since identification numbers must now be exactly right. The postcode and street numbers are only used if several search words are used and must now be exactly the same. If both numbers occur, the building must have both numbers. The new search logic is shown in this flow chart:
Based on the new search logic, we further decide to implement the search logic from scratch to eliminate the architectural weaknesses of the previous search. In doing so, we have to make sure that the new search still meets the old requirements but also the new requirements. A perfect task for test driven development:
3. Test driven development
Together with the product owner of the project, we work out 169 different tests in which the building in question must appear first. The test cases are structured per street and brought into a readable format. They are then run through with around 2,400 buildings, which have a lot of overlaps in particular. An excerpt from the test cases shows Allmendstrasse in Wallisellen and Wallisellenstrasse in Dübendorf (not visible, but present, Allmendstrasse in Bülach):
Based on the planning and the test cases, we can now efficiently implement the search and significantly increase the user experience. Thanks for reading and let us know, what you think about our solution!
