Why giving the users what they want is not enough
Did you know that giving the users what they want is not the right thing.
Why? Because, often, the users don’t know really what they want.
often, the users don’t know really what they want
Example
Consider the following example:
A Restaurant
A large restaurant chain has restaurants across the globe.
Each restaurant needs to maintain documentation such as construction plans for each restaurant, recipes, procedures, and methodologies, etc.
The “critical” documents are kept in a legacy ECM system and several SharePoint repositories store the non-critical documents.
These systems are located centrally and are all globally accessible.
The business users work primarily with the legacy ECM system, but often also need to work with the documents in SharePoint.
When a document was needed, a search was either done in SharePoint, or in the legacy system, using its rather complicated search feature.
Performing searches in two different places wasn’t easy, or efficient. And so, the users cried out “Give us a one central place where we can perform a search”
When asked for more details the business users replied “Make it like Google”.
The restaurant’s IT-people (who might have been a little too enthusiastic) swung into 
They found a tool that would allow SharePoint to “talk” with the legacy ECM system and crawl all the documents, indexing everything it could.
After working many weeks getting things set up, and configured, the IT-people sat and watched as SharePoint crawled through the content.
Once finished, initial tests were done to ensure that a search action would actually return content. It was working perfectly.
And it was “just like Google”.
A demonstration of the Search system was given to the users, who were ecstatic. They were able to easily enter search terms, and get results from SharePoint as well as the legacy system’s repositories.
It was fantastic. It was easy to use, and there was no extensive training required. There was much cheering and showering the IT-people with small gifts.
After further testing, the search facility was officially moved into production.
For the first couple of months, the users were keen to use the “enterprise search facility”.
Complaints
But then, gradually, complaints started being heard. “The search results contained too many hits”, “Why wasn’t it more like the search feature in the legacy system?”, or “the search results were just showing the title of the document.”
Users went back to using the legacy system’s search feature for the “important” documents, and the SharePoint search was just used for the documents in the document libraries.
The “central” search facility was a failure.
What went wrong?
What had gone wrong here?
The business users wanted a single search facility, and they wanted it “like Google”. And that’s what the IT department had delivered.
There was a single box where users could type in words that they wanted to find. And the search would return documents from all the different document repositories.
In this case, however, the users didn’t really know what they wanted.
the users didn’t really know what they wanted.
Yes, they wanted “easy”, but they also wanted something that allowed granular searches to be done (just like their “old” search tool).
They also wanted to know where the search results came from – the legacy ECM system, or the SharePoint repositories. And they wanted the “important” documents to appear at the top of the search results.
And they wanted the “important” documents to appear at the top of the search results.
What should have been done
The IT team should have asked more, and then they should have listened more.
And then they should have repeated this process. ntil it was understood what the Business really needed.
The team had followed a Waterfall approach, where requirements were asked up front, and then were not allowed to change.
Agile programming techniques could have been used where a “finished’ product is shown to the users several times during the project. The users could give feedback which would lead to a better understanding of what they want, as well as the ability to refine the solution.
Happy Ending
Fortunately, the IT team had the opportunity to improve the search system. They did add a small button to the search result screen, where users could provide immediate feedback. Working with this, as well as sending out regular “satisfaction” questionnaires, the IT team was able to identify areas of improvement.
These include not only changes that were required on the user interface, and results screen, but it also allowed the IT team to see where further refinements were needed in the indexing process.
Every four months, the improvements were presented to the business, and then implemented.
Now, the business users don’t use anything else.
Want to learn more?
Below is a selection of resources that I personally feel are relevant to this blog post, and will allow you to get more in-depth knowledge. I do earn a commission if you purchase any of these, and for that I am grateful. Thank you. (Important Disclosure)
