A lazy developer is a good developer. Creating documentation is a waste of time. So a good developer does not like documenting.

A lazy developer is a good developer. Creating documentation is a waste of time. So a good developer does not like documenting.
Knowledge base is a critical part of any product documentation . It provides a library of the main information, keywords & features about the product.
According to Wikipedia, a knowledge base (KB) is a technology used to store complex structured and unstructured information used by a computer system.
In plain English, it is a condensed list of the main keywords, topics and questions that are requested by users.
A knowledge base is normally used for external users as e.g. customers and users.
Internal knowledge bases can be used by departments, teams or employees from sales, marketing, product management, development, QA/testing & support to collect and describe information, specific knowledge and typical procedures.
Knowledge bases can also be differentiated by the target – it can be e.g.
For new and existing users and customers, they provide a structured and always available self-service help.
The support department can forward and link incoming requests and inquiries to static, well-written knowledge base entry, providing additional information and links to related content.
Such a focused entry page can be used and linked to as reference in the product documentation, providing additional background information about a specific topic.
A public, well-written and strong knowledge base entry page for a specific keyword or topic will rank in search engines and attract new visitors, and customers.
The following steps describe basic steps to create and maintain a knowledge base.
… or how to write a good knowledge base page.
Remember – be precise and consistent. Do only write relevant information.
For each entry, the following parts should be present:
Depending on the type of knowledge base, these topics and categories could be present
There are various solutions and products available. Providing a complete list is not possible, since new products and features are added every month.
To choose the suiting product, a short evaluation should be performed. Here are some criteria that could be taken into account:
Typically, the following categories will evolve
You can find more information about knowledge base processes and best practices on the follow pages
Start now, if you are not sure if you need a knowledge base or not for your product. Your customers, your marketing, your sales and the support department will thank you.
Get all relevant stakeholders on board, and start with a first effort.
Schedule regular improvement sprints e.g. every month or every release. The users search queries, rated entries and support requests are very helpful to focus on the relevant topics.
What makes a perfect product documentation? Is there any exceptional documentation example? How much effort should be put into?
Product documentation is always outdated, hardly to understand and only written for the DAU or power user, and thus does not help the average user.
The fictional user
Looking at the average user of a product, the typical usage pattern is: buying the product, unboxing it, starting and using the product, running into a problem and calling the support for help – of course with highest priority and requiring the solution ASAP.
The documentation, help system, manuals, technical document or operation instruction are used only by probably 30-50% of the users, depending on age, gender, background and the product itself.
In the past, the product documentation was not very “user friendly”, written with technical terms, long and hard to understand sections, screenshots and step by step instructions. It was teaching the program and application, from the creators perspective.
Looking at todays user that interacts with a new application, web page or mobile app – they only search for a help button or linked online manual in case of emergency. The product itself is expected to be simple, user-friendly and easy to grasp – even for complex tasks or features.
Reading a big book or textual folder of written pages is no longer accepted. Also big Word or PDF files with hundreds of pages are not user friendly.
Different user persona as e.g. the new user, a power user or administrator of the customers IT department need different type of documentation.
Today a multitude of application, software and apps are used together. They are running somewhere in the cloud, or are installed on-premise in the local network. Often, the products use different concepts of the user interaction and usability differs. So, the user is confronted with a set of totally different “things” to solve the tasks on hand, in a very short amount of time.
Todays customer is expecting regular updates of the product with change logs and release notes. The modern, agile development environment produces new product version in short frequencies – with monthly, bi-weekly and even multiple updates every day.
Keeping the documentation of a complex, advanced product up to date is very challenging. Technical writer or other experienced employees need to keep track what changed and update the manuals.
Often input and knowledge of the development, testing, sales or support teams needs to be incorporated into a well-written documentation.
For multi-language products, requiring additional translation and verification steps, the process gets more complex and delays the production of the final documentation even more.
Advanced manual incorporate screenshots, videos and other resources. Keeping them up to date with every product update is nearly impossible – especially in a multi-language application.
The manuals, onboarding resources, knowledge base and more user-product-related information can be handled by the support platforms as Zendesk or Freshdesk. They are focused on providing Q&A information, and help the customer in need. Mostly, providing product documentation is only a part of the whole support platform.
Looking at the market, there are various product documentation products and platforms available.
This could simple as e.g. providing PDF file-based documents or even written folder.
If an online-based solution is required, a Sharepoint site or a hosted WordPress website could good enough.
For a more complex product with a bigger user base, a support platform with build-in product documentation and knowledge base could be a good fit.
A developer-centered approach as using Asciidoc-based files during the development- and QA phase is also possible.
Specific, stand-alone documentation platforms providing multi-language, versionized user manuals are on the other side of the market.
As always – there is not one perfect solution. Depending on the product, target market, the companies structure and departments a different approach is better suited.
Starting with a simple approach, targeting the customer needs and problems at hand, and improving the tooling and processes over time is often the best way to solve this problem