Wednesday, January 22, 2014

I'm watching you, watching me... (Part 2)

I posted a blog entry a while ago about the LinkedIn feature that allows me to see who has viewed my profile. In that post, I made a passing reference to Facebook, and wondered what would happen if they did the same thing. Since writing that, my mind has been stuck on this notion, and it's gotten me completely distracted. So I need to get this out of my system.

Facebook. It's a lovely tool for sharing photos and saying what's on your mind, but who hasn't used it to secretly peak into the lives of someone else? We can use Facebook like this is because it allows our voyeurism to remain a secret from the target individual (unlike LinkedIn).

But what if that changed? We know that Facebook has the data - they know who viewed whose profile and when. What's keeping Facebook from one day exposing that information?

Did you just turn pale?  The thought of your ex-whatevers knowing that you were poking around their Facebook page is horrifying, no?

Well, if we know that Facebook has this data and that this data has value, why do we assume that they would not want to capitalize on it? They are, after all, a public company now - answering primarily to their shareholders - and shareholders want return on investment.

So, if Facebook decided to cash in on this data, how would they do it? I imagine they could do two things;
1- Announce to the Facebook community that they will be exposing this data and, if you want to have your view history kept secret, you can pay a fee. 

2- Announce to the members that, if they want to see who has been viewing their profile, they can pay a fee.

With this approach, they'd have thousands of people deleting their profiles completely, and a whole lot of people who are willing to pay to a) keep their activity private and b) see who's been looking at their profile.

From the Facebook Data Use Policy at the time of this writing: 

Granting us permission to use your information not only allows us to provide Facebook as it exists today, but it also allows us to provide you with innovative features and services we develop in the future that use the information we receive about you in new ways.

"The information" could be anything they gather, which is everything. "Innovative features" could be a fee-based service that shows you who's been poking around your profile and/or keeps your activity a secret.

Of course I have no idea if this will ever happen - but it could. 

Thursday, January 16, 2014

Software Documentation: Delivering the Unicorn

When you use enterprise software, you are going to need help (even if you have received training). It goes by many names: documentation, help, the docs, user guide, manual, etc. Let's go with documentation, the value of which can be put into 2 buckets; effectiveness and efficiency. 

Effective documentation gives the user the correct answer every time. This is all about content. Software systems can be so flexible and dynamic that it's impossible to anticipate all the ways a user may want to do something. The technical writer has a mountain to climb in this regard. A user needs to be able to first understand what the feature is for, then how to use it, and also understand how that feature impacts outcomes as well as other features.

Efficient documentation doesn't force the user away from their task. The traditional documentation fails here. Clicking a link to access the documentation takes my vision and focus away from the software and into a sea of content.

So what would be the best user support scenario?


Here's the best thing I can imagine: the software vendor's product manager sits next to me and answers any questions I may have. This would maximize effectiveness and efficiency, but it's a fantasy, so let's call this the Unicorn Model.
Here's what we have today: I use the software and, when I need guidance, I click a "Help" link to find answers in the documentation. Sometimes it's effective but it's rarely efficient. I have to leave my task, search, read, interpret, apply the information to my specific needs, then go back to the task and see if I can do it. And if that doesn't work, I need to seek other resources; customer support, message boards, online tutorials, colleagues, etc. Let's call this the Mule Model; it works for the most part and we accept it, even though it isn't the most effective or efficient.

From the perspective of the software vendor, our goal should be to give the users of our software the best self-serve user support possible. By doing this, we reduce the burden on helpdesk and training groups and, perhaps more importantly, we foster customer satisfaction. If we indeed have this goal, we should strive to provide user support that is as close to the Unicorn Model as possible.

Effectiveness is really in the hands of the technical writer and the support they receive as they write the content. Let's stipulate that the content is perfect and can address all of a user's questions. The content represents the Unicorn Model, so let's turn to efficiency. How can software deliver the perfect documentation in a way that does not distract a user from their task within the software itself? 

I think this is the million-dollar question but it's not a new one. 

Remember Clippy, the animated paper clip that Microsoft introduced into Windows and Office? This assistant was an attempt by Microsoft to move closer to the Unicorn Model - to provide more efficient user support. And it failed. Users (this one included) found it annoying and distracting.

So what is the answer?

If I were starting an enterprise software company, here's what you'd see:

1) Software design specifications that included explicit user support functionality. This would be much more than a little question mark icon that popped up a sentence. It would be rich and dynamic. Maybe the software offers various modes of operation - beginner, intermediate and advanced - and provides on-screen user support that correlates with each mode. The key here is, don't make the user leave the software to get documentation. Put it in the product.

2) A role within the development team whose job it is to code user support functionality into the product itself and work intimately with the technical writer and interface designer.

This would move us from the Mule Model to something better. Not the Unicorn, but definitely in the right direction. But it's easier said than done. It requires business leaders who share these values and are willing to support them when budgeting. It also requires a product development model that includes user support as a major consideration in the development of user experience.


I would love to hear from you on this. Are help authoring tools getting in the way? Is user support (documentation) ever going to get a seat at the product management table?