I’m reminded of the power of the product site by this post from the meeblog, the meebo blog. Meebo is a web-based Instant Messenger for multiple IM platforms such as Google Talk and AIM together in one interface. It’s extremely handy, but apparently a product website redesign has really pushed their visibility even higher. I thought, that makes perfect sense. When people understand the uses for a tool, they use the tool even more readily. Here’s their new product site. The meebo repeater apparently got even more attention lately due to this redesign. I don’t think it’s that they made it easier to use, it’s that they explained a scenario for its use – When meebo access is restricted, install this small piece of software on your home computer to access meebo anywhere. Simple and elegant.
I’m now looking for short explanations for why you do things with the product I document, iMIS. A task overview is part of our templates now, an overview that states the principle of why you want to perform the task. In my mind, though, there’s a subtle difference between a task overview and a scenario for why you’d want to do a task. This forced question, why? is helping me write the correct tasks for the user’s goals. It’s not necessarily part of the product site, but it is helping me understand what
Another reason why I’m reminded of the power of the product site is because of the summary in Scriptorium’s white paper, Web 2.0, Friend or Foe? Four out of six of the bulleted list of integrations that summarize the paper refer to the product web site. We need to remember that unless we integrate our help systems, we risk not answering the right “why?” questions for our users.