Blogs

Back in the early 1980’s I worked for a partner at KPMG (then, PMM & Co) who always stressed that we “should start writing the final report the minute we begin an engagement.” I hated hearing that admonition, but I have given that advice, in some form to every employee I’ve had ever since. My latest adaptation of that bit of wisdom is to try to get people to think about how they will describe a system when it’s ready to be delivered. If your future marketing collateral includes phrases like: “includes dozens of views” or “supports complex search patterns” or “makes full use of SharePoint’s advanced features” you may be heading in the wrong direction. You want to be building something that will allow you to use phrases like: “intuitive interface” and “simple but effective design” or “a wonderful user experience”.

Just as my daughter has a list of banned marketing words, I am forming a list of descriptive terms that I don’t want to see in our documentation, at least not in bold print. Here are three from the top:

Advanced Search – Don’t get me wrong, search is a powerful feature in SharePoint, but you should not get comfortable thinking that your users will find what they need using search. I would go so far as to say that if you’re relying on advanced search capabilities to save the day, you skipped an important design meeting. I would prefer to see a parameter driven search web part that is working off of the metadata you’ve made people enter, but I would work to keep the list of options pretty simple. By the way, I’m not alone in this thinking, (see one of my favorite articles on this subject).

Logical Operations – I would suggest that most users don’t want to have to “and” two conditions together to build a filtered view. I have led training sessions where I have shown people how to build views, and by the time I start “and-ing and or-ing” conditions together, I could see their eyes staring to roll. I don’t think anyone wants to start combining Boolean (and please, unless you want to be confused with the guy who asked NASA’a Curiosity Rover to the prom, don’t ever actually use that word) operators like “A and (B or C)”. It’s nice that SharePoint views include this capability, but take the time to determine what views are really necessary and build them before you deliver your solution.

Drill Down – Most of my users seem to feel that this phrase is another way of saying “I didn’t actually build any reports.” They like the fact that the content in SharePoint is organized so that they can refine what they are looking at, but they don’t really want to be the person operating the drill. We have seen the same think in Excel; people love the results that can be rendered by Pivot Tables, but when you tell them that they can build a Pivot Table, they are the ones yelling “shut up!”

All of these, as well as many other features in SharePoint are wonderful tools, but you can’t rely on their being used as a way of satisfying requirements. There are many ways to pre-package these tools and activate them from links, in web parts and in dashboards, and when you deliver solutions that contain those features, your users gain confidence in their ability to use the system. It’s the difference between having a jack and a spare tire, and having AAA.