Trying new things - especially new software products - can be both intimidating and time consuming.
You face a challenge when introducing a product in the marketplace. The forces of nature are working against you, since almost everyone but "early adopters" resists trying new products.
A major reason people resist trying new products is the learning curve. People simply don't have the time or patience to wade through pages and pages of documentation just to figure out what a product does, envision what it's like to use it, and how it would disrupt the way they live their lives.
One thing you can do to minimize this obstacle to adoption of your product is to provide the shortest path. Providing the shortest path means minimizing the time and effort necessary for a first-time prospective user to obtain demonstrable value from your product.
To provide the shortest path, you do some combination of the following:
You face a challenge when introducing a product in the marketplace. The forces of nature are working against you, since almost everyone but "early adopters" resists trying new products.
A major reason people resist trying new products is the learning curve. People simply don't have the time or patience to wade through pages and pages of documentation just to figure out what a product does, envision what it's like to use it, and how it would disrupt the way they live their lives.
One thing you can do to minimize this obstacle to adoption of your product is to provide the shortest path. Providing the shortest path means minimizing the time and effort necessary for a first-time prospective user to obtain demonstrable value from your product.
To provide the shortest path, you do some combination of the following:
- Make available a "quick start" guide that a prospective user can read in under ten seconds and get a feel for how she would use the product.
- Provide a demo (or full-fledged product) that enables first-time users to accomplish their primary goals with almost no time or effort.
Comments
http://tynerblain.com/blog/2006/10/10/use-case-driven-documentation/
So many FAQs are actually IAQs (infrequently asked questions) and provide little or no task-centric help to new users.