The Search revolution

Why the Search UI is a big deal?

The idea of a “Searchable Index” seems like it would be obvious, and a search field near the top of a page appears to be a rather ubiquitous design element on the Internet today. It wasn’t always like this, and there are still many systems using a hierarchical menu approach as the first thing a user sees after logging in. Let’s practice some design thinking, and make intentional observations about the topic.

Early days

It seems a bit odd to think of the early days of the internet as something that most engineers entering the field today don’t remember. This screenshot from the wayback machine shows the Yahoo! front page in January of 1999. As you can see they were creating a hierarchical view of the internet, like creating a huge Table of Contents for the whole Internet. This design had been prevalent in software systems from the early days. File systems had been organized hierarchically since the very early days of hard drives. When GUI’s emerged, file system UI’s were introduced with a collapsible list on the left side of the UI. Having a “drill down menu” was a feature of almost every business application developed since the advent of the CRT monitor. However, the vast scale of the internet quickly exposed multiple critical weakness when this pattern was applied at scale. The need to “drill down” through multiple layers, not knowing if you made a wrong turn along the way, was not a desirable user experience, and the organization of content was increasingly expensive to maintain.

Google shakes things up

This wayback machine screenshot of Google from February of 1999 shows that they publicly launched a beta program (rare even today), but more importantly you can see that they just have a search bar near the top of the page and nothing else. They shifted the work of finding a page left in the experience. This completely eliminated the drill-down user frustrations. It didn’t take long for the world to see the benefits of this approach. Google was the giant slayer and continues to be the default landing page for the internet to this day.

Default search as a Dashboard / Landing Page

I’ve often wondered why Google doesn’t use a default search resultset as the landing page for google.com, instead of the simple search box. By not using a default search they are missing out on the opportunity to eliminate the frustration of entering an incorrect search term. They also miss valuable user analytical insights, and advertising revenue. To be fair, training the machine learning models it would take to effectively predict what you want to see on the entire internet is a tall order. I guess that the “creepy factor” of having Google automatically find what I was about to search for could also be a design concern that outweighs these values. 

Search takes off

Once Google had made it obvious that search was a superior interface, it was adopted widely. My research into when Microsoft and Apple added a search feature to their file system UI and productivity apps looks like it was either inspired by Google or a great example of convergent evolution. Most of the social platforms have taken the idea of a default search landing page and run with it. Sure you can still search for things, but you start out with the list of things that they want you to see, or rather that their algorithms think you will want to see. The explosion of Search as a feature seems to have overshadowed the innovation of Search as a dashboard, and slipped past many designers.

Why doesn’t my company’s app have a search dashboard?

There are many possible reasons, some designers have failed to recognize the true impact of this innovation. It is pretty subtle, and easy to miss. The relative simplicity of the landing-page experience makes this easy to overlook. Compound that with the familiarity of a hierarchical menu and it’s actually not a surprise that few business applications leverage search as a dashboard. Even those file systems that added a search feature still hold on to a hierarchical organizational structure. The familiarity of this pattern still drives designers to create menu based solutions.

This is a great example of an Engineering perspective (file systems) that is not aligned with a User perspective (finish fast). I think most users would find it more efficient if their landing page was just a list of index cards with links to the things they need to see or do. Recognizing the innovation, intentionally observing the impact, reflecting on how it might be leveraged, and having sponsor users to validate ideas are the design thinking tools that can mitigate this type of missed opportunity for innovation.

There are engineering challenges, both in designing algorithms and building infrastructure to support search. Use of micro-service architecture patterns, separating out search as a bounded context, will allow you to address scale concerns and isolate performance impacts.

Search as a Strangler Dashboard

Search as a dashboard is a well defined bounded context, leveraging CDC event streams to establish eventually-consistent data across service boundaries will isolate the performance impacts. Implementing a database copy of the searchable information from other production systems will also allows you to index data from multiple systems. This has the potential to introduce significant new value to users who often have to cross between systems to get their job done. This is also an opportunity to establish an event backbone for integrations between future micro-services.

There is at least one design pattern that can impede the ability to implement search as a dashboard. If your legacy application does not support inbound routing, then search may not be the best place to start. What is meant by “inbound routing”? Some legacy systems will not allow you to jump straight to a task or page, but require that you follow a specific path to get there. Refactoring a legacy application to support routing can be a significant effort. Configuring search to understand and automate navigation can make the link from search to subject very complex and fragile. Both of these factors may make the Search Dashboard a less desirable candidate to start a strangle with.

If you now find Search more significant than when you started reading this article, please reach out and schedule a call to share your thoughts and learn how I can help you implement this pattern, or help you recognize the value in other subtle innovations that you may have overlooked.