But very often a small aspect of search is neglected: The zero result page, or the zero results strategy (There are many reasons for this, I’ll explain one later*). Yesterday I came across a search that I think could benefit greatly from zero result strategy. I was reading an article about some really good Norwegian authors, and decided to buy some of the books at a Norwegian E-book store called ebok.no.  The E-book market in Norway is not very big, even if the general book market is. Few books are published as E-books and you often have to wait a while before a book is available as an E-book. I was lucky and found two out of the three books I wanted. The last one: “Bergeners” by Tomas Espedal I misspelled a couple of times before I got it right. Even then I had to check a regular bookstore to see if it was actually correctly spelled.

Solution: Monetize search

What if ebok.no, every time a user got a zero result, did a lookup in a database to check if the search query matched an actual book. If yes, say the following:

Sorry, we don’t have the book “[title]” by [author] available as an E-book.

Would you like us to send an email when/if it is available as an E-book at ebok.no?

It the user agrees, you have achieved one and maybe two things. Firstly, you’ve made your users do a one time subscription to pay you money even if you slapped them with a zero result. Secondly, if the user wasn’t a registered user already, you may have convinced him or her to become a registered user later on because of good customer service.

*One reason a zero result strategy often is neglected is that you need the search to be in production for a while before you have enough data to analyse your zero results. In most cases, by that time, the project has ended.

Målet vårt er ofte å lage en “intern Google” for kundene våre. Det betyr at vi må forstå hva brukerne leter etter.

Når du søker på “365″: Leter du da etter en kollega med internnummer som slutter på 365? Leter du etter personen med ansattnummer 365? Eller leter du rett og slett etter eksperten på produktet deres som heter “365″?

Jeg er en stor tilhenger av ett stort søk for bedriften din! Og jeg vet at jeg har flinke kolleger som kjenner veien frem til god relevans og en smart søkemotor.

Men: Min teori er at et godt søk blir enda bedre, jo mer vi vet om hva du egentlig leter etter.

Vi har to ganske tydelige retninger for personsøk: Enten søker du etter kontaktinfo eller så leter du etter områdeeksperten.

Lek at vi skal lage et internsøk for Willy Wonka. Målet vårt er å la Oompa Loompaene bruke mest mulig tid på å lage  fantastisk godteri, og minst mulig tid på å lete etter oppskrifter, eksperter og telefonnummer.

I tillegg til å ha laget et stort “internt Google”, har vi også laget to app’er for Loompaene. En telefonbok og et ekspertsøk.

Først telefonboken:

Willy Wonka PhoneBook er akkurat det det høres ut som. En app på datamaskinen, nettbrettet eller smarttelefonen som lar Loompane søke internt etter et telefonnummer eller en Lync-kontakt. I eksempelet over husker ikke brukeren fornavnet på kollegaen, men vet at han heter Loompa til etternavn og at han jobber i sjokoladeavdelingen. (Og slapp av! Selv om du ikke ser forskjell klarer en Oompa Loompa å skille ansiktene fra hverandre.)

Dette løser et problem vi ikke bare finner på sjokoladefabrikker, men hos de fleste av våre kunder; å finne telefonnummeret. Og på denne måten har vi enda større sjanse for å gi dem rett svar på topp i resultatlisten.

Fordi brukerhistorien er så enkel som “jeg vil finne kontaktinfo til kollegaen min”, kan vi også strippe løsningen for sortering og fasetter – og ende opp med et enda enklere brukergrensesnitt.

Når en Oompa Loompa på den annen side vil finne eksperten på sorbet kan han derimot starte app’en “Willy Wonka Expert Search”:

Ekspertsøket søker gjennom alle dokumenter som ligger på filserveren til Willy Wonka, og søker gjennom alle diskusjoner, statusoppdateringer, grupper og diskusjoner på Willy Wonkas “interne Facebook”. Gjennom å finne hvem som har skrevet mest om fagområdet sorbet, kan vi mest sannsynlig også vise frem at “Roger Loompa” er eksperten på området.

Når vi i tillegg ser at Roger på Iskrem labratoriet har nevnt sorbet i sin siste statusoppdatering … kan vi vel si at vi har en vinner.

–

Målet er ikke å lage en haug med app’er. Langt i fra! Målet er derimot å gi brukeren rett svar på spørsmålet sitt – hver eneste gang.

Å lage løsninger som forteller oss mer om hva brukeren leter etter, gjerne allerede før de har gjort et søk, øker sannsynligheten for å gi det rette svaret med en gang.

Our goal is often to make “an internal Google” for our customers. That indicates that we must understand what you are looking for.

When you search for “365”: Are you looking for the person with the internal phone number 365? Are you looking for a colleague with the employee number 365? Or are you actually looking for the expert on your product, named “365”?

I am all for making one big search for your company! And I know I have colleagues that are magicians enough to solve these kinds of traps.

But: My theory is that a great search gets even greater when we know more about what the users are looking for.

These  are the two directions of people search:

Let’s pretend we make a search solution for Willy Wonka. Our goal is to let the Oompa Loompas spent as much time as possible making candy, and as little time as possible searching for recipes and phone numbers.

In addition to having one great search where they find everything, we also made two apps for the Loompas. One PhoneBook and one ExpertSearch.

The PhoneBook is exactly that: An internal app on the Oompa Loompas desktop, smartboard or smartphone, where they can search for the phone number of the loompa in the chocolate department that they don’t remember the name to. (Chill! They can separate their colleagues from each other even if you think they all look the same.)

This solves a common user need  that we find not only in candy factories, but at most of our customers. And we have a lot greater chance to give them the right answer doing it like this.

Because we take away all other user stories then “I want to find my colleagues contact information”, we can also take away almost all navigation and refiners – and end up with a much cleaner interface.

When an Oompa Loompa on the other hand needs help on refining the sorbet in the ice cream room, he can start the ExpertSearch app on his desktop, smartboard og smartphone.

The ExpertSearch searches within all documents written in the Willy Wonka Factory, and goes through all the discussions, social updates and communities on their internal collaboration system. From finding who has written and talked the most about sorbet, we can most likely end up with suggestion “Roger Loompa” as the subject matter expert.

When we see that Roger in the Ice Cream Lab. in addition mentions sorbet in his latest MySite Status, I guess we have a winner.

–

Making a lot of apps isn’t the goal in itself. Not at all! The goal is to give the users the right answer on top of the search result list, every time.

But making solutions that gives the user the opportunity to tell us more about what kind of an answer he is looking for, even before he makes the search, increases the likelihood of giving the correct answer right away.

User driven content and search

The 1-9-90 principle makes you understand who you have to build for: The super user.

Check out the presentation on LinkedIn: “Ideas on how to find a movie to watch“.

Thanks to Harald, Johannes and Tone for feedback and valuable input.

I decided to use a website that lots of people use – or at least; a kind of page that people could relate to. So I redesigned Netflix’s search result in an hour – using the Phi spiral.
I made the first design, showing the result of a search for the actor Kevin Spacey.

This is the design:

When user testing the design at FiveSecondTest.com the 15 first test results showed me that the design was spot on. Of course, it would be more credible with a lot more tests, but seeing a clear trend in the first ten results often points out how the next 150 results would look like.

This is the result of the first and second clicks:

As the results show: My colleague’s theory is spot on.

But … when we look closer at the result we see that people are clicking at the face of Kevin Spacey. It that because the people we tested knew that we where looking for him, and that our mind then automatically looks for his eyes?

I made another search result. This time for the search query “horror movies”.

This is the design:

And this is the result:

As we see, the spiral still works – but not as distinct as test number one. But the power of human eyes draws our attention, I guess. So using images as the search results can give us challenges.

Still. Espen Klem’s myth: Confirmed!

Using the phi-spiral as a visual relevancy hierarchy

So, how could the Phi spiral help us?

A search engine list out what it thinks is the most important first. But the list has several issues:

• You could, but should you?
  Just because your template really want you to render a logic list as a visual  list, doesn’t mean you have to do it like that.
• Not representing the information well
  A news article looks like a news article, no matter which version you see: The front page teaser, a short version or the full blown thingy. But a search result almost always looks like just that: A dull list of items.
• Too many items
  Results at the bottom of the list tends to get higher click rates than just above the bottom. I guess this have to do with how people scan web content in F-shaped patterns and that a list of 10 items is too much information for the user to digest.

So, what if we started to use space and position to show relevancy? The Phi spiral, building on the Fibonacci sequence would make a nice search result.

Phi spiral as a search result. We’ll get all sorts of other issues, but I think it’s a good start to getting somewhere better.

You would maybe not be able to show more than 5 result items, but we could put the search box in the middle of the page and then get 6 items.

Looking less like a search result and more like a content filled page.

So, what do you think? Others are using treemaps: Newsmap.jp. Not a very usable implementation, but a nice idea.

A few weeks ago, my colleague Harald and I carried out user interviews at a customer for their “internal Google” solution. Before starting to developing concepts and interaction design, we wanted to properly figure out their users’ actual needs.

One of our findings was that the users generally know the type of content they are looking for. When caseworker Paul searched for “Vietnam Workshops” he knew that it was an application he was looking for – and not a colleague, a PowerPoint file or a news article on the intranet.

Armed with this knowledge, we got some ideas about how to improve their current search experience.

Previously, we thought that this was a good results page when searching for “Vietnam Workshops”:

But maybe this is the way to give Paul a better answer?

By asking Paul to help us decide on the “search mode” before we begin to guess his answer, we will most likely be able to give him a more accurate result.

However, when we user tested this a few weeks later we received clear feedback that the tiled design left the user feeling a little “cheated”. They had searched, but still needed to make a choice before finding the answer. This is also a well known search pattern – even explained by Monty Python.

Turns out Winnie the Pooh has the answer: “Yes please, I’ll have both” is the solution! The search results present a clear call to action to select a category, but with some results already presented on the first page:

A good argument for displaying results in the various search modes right away is to show Paul that we “know more than what he thinks.” By quickly scanning the results page, he may learn something new about his colleagues, see who’s associated with “Vietnam Workshops”, or maybe he’ll find something interesting in an intranet article; hopefully making his current task simpler and quicker to carry out.

But making it clearer that he has the opportunity to choose a search mode, can help Paul to help us give him a more accurate answer.

They say that everyone dies twice. First when you actually die, and then finally when your name is mentioned for the last time.

Back before online search revolutionized ranking algorithms, people sorted their search results by date, alphabetically or by any other static metadata. The concept of a relevance-based result set, where items are evaluated against your search terms at query-time, was rare. Now, we’ve gotten used to sorting things by relevance. A concept as easy to understand as it is hard to implement.

Rank models, i.e. the math behind calculating a metric for relevance, sparked an interest in me the moment I first heard of them. And ever since, every time someone wanted to sort a result set by the “old-fashioned way”, e.g. by date, I always cringed. But I swallowed my search geek-pride and moved on.

How search engines calculate relevance and rank is way out of the scope of this post, but because of my long-running loathing of non-relevance based sorting, I want to highlight a small but glorious thing in the new SharePoint 2013 search GUI, that may have bypassed even early adopters in the findability scene. My heart almost skipped a beat when I first noticed it at one of last week’s sessions at the Microsoft SharePoint conference in Las Vegas.

Alternate sorting in SharePoint 2010

In the search center in SharePoint 2010, both the one for Enterprise Search and FAST, the default was to sort by relevance. Great, but there was a drop down that allowed you to change over to sorting by date or, in the case of FAST, any other managed property which had been enabled for sorting. Even so, I’ve experienced time after time that the drop down was not used very often. Why? Probably because dates and many other metadata is several times better navigated using drill down facets, and this is something that comes natural to many end-users over time.

Of course there are exceptions and occasions when an alternate static sorting over a single metadata property makes sense, but for a good portion of search centers, I’m very convinced that the drop down adds little more than just some clutter to the GUI.

In the SharePoint 2013 search center, you can still sort by any property, of course. But the drop down in the default GUI is not there anymore. You’re encouraged to sort by relevance, and that’s it. There are two things to this:

• Firstly, the functionality to sort on a single static metadata property is still there behind the scenes, and very easy to expose to the user if it’s necessary in your solution.
• Secondly, the engine driving the relevance calculation is much improved and it’s now easier than ever (in the SharePoint world) to tune your relevance model; allowing it to span over several metadata and dynamically evaluate search words against the index corpus.

But not having that “sort by” drop down in the default GUI is a huge step.

The search box in SharePoint 2013, no static sorting to be seen

This is not only about getting a cleaner GUI, but more importantly also about getting to a point where users have started to assume that sorting by relevance just works. Silently, but surely, search engines are maturing, and we’ve – equally silently – started to assume they work better and better.

My inner search geek has started to wonder that perhaps static sorting first died when the rules of online search changed with PageRank, and people got accustomed to sorting by relevance. And with having that alternate sorting drop down removed from the default SharePoint 2013 GUI, perhaps this is the time when static sorting fades into obscurity – and dies the second time.

Dear static sorting, R.I.P.

If you have read everything else of interest – and want to pump yourself up on enterprise search – look no further. We have compiled our ultimate reading list for search enthusiasts, a comprehensive collection of the most interesting books on search thinking and search doing written to date. Hopefully you’ll find something worth reading here aswell.

We would love to hear what you think of these book, and please feel free to share your own suggestions in the comments below. Happy reading!

Search Thinking

Lovely books on the softer, more fluffy side of enterprise search.

Everything Is Miscellaneous by David Weinberger – the human side of information, and why tagging is better than classification.

Ambient Findability by Peter Morville – search in a wider perspective, and possible futures.

The Search by John Battelle – the story of how Google revolutionized web search and Internet business.

Search Doing

Rock-solid and down-to-earth practical advice on search design and implementation.

Search Patterns by Peter Morville – the definitive guide to design patterns for search.

Search Users Interfaces by Marti A. Hearst – a textbook packed with useful examples of search user interface designs.

Designing Search: UX Strategies for eCommerce Success by Greg Nudelman – the how-to on eCommerce search design and implementation, with a lot of helpful guidelines.

Search Analytics by Louis Rosenfeld – a thorough and comprehensive guide to working with your search logs.

Faceted Search by Daniel Tunkelang – a crash course in one of the most enigmatic challenges of enterprise search.

Exploratory Search: Beyond the Query-Response Paradigm by Ryen W. White & Resa A. Roth – the academic perspective on information seeking behavior and Human-Computer Information Retrieval (HCIR).

Update:

Martin White has published two additional books on enterprise search that you may want to check out:

• Successful Enterprise Search Management
• Making Search Work: Implementing web intranet and enterprise search