KISS SEARCH

KISS SEARCH

This post was written after two years spent helping companies to build their own search engines.
My goal has always been helping those in charge of integrating enterprise searching solutions to define a clear path they can follow when ther are too many users, too much data and hard-to-manage processes.
Every one of you knows Google search engine, but who can say they feel ready to design a "Google for Companies"?

--

Have you ever wondered why, in almost 20 years of commendable service, Google has never changed its home page, except for a few minor design tweaks?
And why does the result page still looks like a terribly boring list of links ordered by relevance?
Google has indeed tested many different functionalities, some of which were even interesting, but, for some usability reason or another, they’ve always come back to their initial idea.

There was a time when Google allowed registered users to customise their home page using widgets (e.g. weather reports, sport news, notes). Another interesting feature, that was dismissed a few years later, allowed users to preview the chosen website before deciding that the suggested link was indeed what they were looking for.
Try and ask yourselves:
Why has the most used search engine in the world kept its design and features almost the same through all these years?
This said, let’s try putting ourselves in the shoes of a business integrator in charge of designing a corporate search engine. 


WHO ARE MY END USERS
The first question we need to ask ourselves is: who are my end users? 
To answer this question you’ll need to keep what I think of as the golden rule firmly in mind: a search engine needs to answer to any kind of user’s queries to be efficient. 
This has to work irrespective of their needs, their technical knowledge and, harder still, irrespective of the information you want to index. A corporate search engine can only be said to be a success when every browser on every work computer has it as a home page instead of using the company’s intranet home page.

This brings us to the second rule, that you need to accept as gospel: by definition, there should always be only one search engine, different versions or projects should never exist. Just one for everyone. A user opening their browser to look something up should never ever have to ask themselves: which search engine should I use? Reflecting upon how many times a user is going to repeat the same task over and over in a working day, it’s easy to realise the importance of having a single entry point. You could be led to believe that, reasons such as language, location and clearance levels could be enough to justify the existence of different projects, but that is simply not true.
Nowadays technology allows us to manage all of these aspects easily, and if that were not the case, you should be looking for a different technology! Let’s move on.


WHICH DATA SOURCES SHOULD BE AVAILABLE?

After having pinpointed our audience, the second question we should ask ourselves is: which data sources should be available? Most likely, we will choose the sources users access the most. Since we’re working in a corporate environment, this information is usually available. This doesn’t mean that minor sources aren’t as important, but we need to consider budgets and development schedules. The reasons why we’re forced to have a list of priorities are merely economical and logistical. This goes hand in hand with the scalable nature of search engines: we’ll start from a subset of information that we’ll expand in time.

Be careful: the more end users get used to using your search engine, the more they will complain when something isn’t available in it! It will come to a point where, whenever you’ll decide to develop new solutions in a company (e.g. a new CRM or DMS), one of the first questions to be asked will be: can this technology be integrated with the search engine?


ENTERPRISE INFORMATION IS MUCH MORE STRUCTURED THAN THE ONE WEB AS WE KNOW IT.

Behind a business document there are many attributes that can be identified and consequently that are potentially searchable.
A knowledgeable business integrator could make the mistake of interviewing users to ask them which the most relevant information are and which help them identify a document more easily. At this time, the business integrator is put to the test and they could make the second worst possible mistake (the first one is thinking of developing different search engines for different scopes/units/projects/teams). The mistake in question is to try and satisfy every user’s requests. Given the scalable nature of a search engine and its near-to-endless computing power, we could be deceived into thinking that piling information upon information won’t be a problem.
Wrong! A search engine should never completely replace any data source, it should only ever be a useful tool to access them more quickly. Moreover, if we were to try and acquiesce to every user’s requests, information would pile up to the point of making searching itself too complex.

Just think about Google’s result page: a list of links, the document’s URL, a snippet of the content and little else. We are taking this example to the extreme but think about how much information gravitates around a DMS: the document’s title, an abstract, its content, author, editor, version, update date, old versions, etc. There will always be at least on user who’s interested in each of them, but it’s up to you to understand which ones truly matter.


REMEMBER: A SEARCH ENGINE'S GOAL IS TO MAKE YOU WORK EASIER, NOT HARDER!
How to react, then? Standing your ground without giving in to the temptation of making every single user happy (in an average-sized to large corporation they can be far too many!). Interviewing users should only pinpoint a subset of minimal, albeit incisive, information; everything else should be handled by its own native source application, that is there to answer any doubt. A search engine should only be a bridge, a shortcut to information, not information itself (although this statement could be in question if we think about cognitive search engines, but let’s accept it as true for the time being).

So I’m talking to every business integrator when I say: relax, don’t think that planning every requisite of the project right from the start will help you solve every problem and allow you to sleep soundly. A search engine is different from the stiff technologies you usually work with. Search engines are versatile and they get better with time, just like fine wine, undergoing a series of consecutive adjustments, the result of experience built on the field.
What to do then, if you lose your way? Just think back to Google and its minimal but effective interface and ask yourself: does it truly makes sense to make things more complex? Being end users of your own tool  is the only way to understand whether a new request makes sense or is just the whim of a user being a little too lazy.

>>>

If you got to this point you can now understand the title of this post: KISS Search, where KISS is an acronym for Keep It Simple, Stupid. It’s a way to remind yourself that the hard part isn’t adding features and complexity, but it’s doing the exact opposite. Designing a global corporate solution is going to be hard, but a good consultant will be able to help you go in the right direction. Beware a consultant acting like a YES MAN! Maybe he hasn’t truly understood what the essence of a search engine is. You’ll know you’ve made the right choice when your users thank you for making their lives easier. Every day.

 

17/Jul/15