...

• Consider that your audience will consist of developers, power users, customers and newbies with a mixed background. 
• Try to make your topic understandable for a broader audience - at least in the initial section of the article so that everybody has a fair chance to understand what it is about.
• It's fine if your article is addressed e.g. to an advanced audience. However, don't forget to mention this fact in the initial section.

When it comes to writing

Clearly state

...

the starting situation

• if you want to publish a solution that you found are proud to have invented then don't forget to mention the underlying problem that you solved.
• A good approch is to start an article by clearly stating a problem:
  • Most problems stem from user expectations that have not been met. 
  • In other words, clearly state the gap between user expectations and the effective behaviour of the product.
• A perfect approach is to elabore the user requirements in your article. This sounds simple, but in fact it is not:
  • Most users would tell us what they want, not what they need. 
  • There's a subtle difference between these terms: 
    • Users who request a functionality tend to suggest some solution how a function or operation should work. This is what they want.
    • Users who describe their usage scenario state what they would like to achieve. This is what we call a user story and is a functional requirement.
  • Development of a solution always starts with valid requirements, not with a wishlist. There is no chance in developing a sustainable solution when skipping the requirements elaboration.
  • If the solution that you describe in your article would not satisfy all thinkable requirements then this is not a disaster. At least if you clearly state to what extent the solution meets the requirements of the starting situation.

Define the scope

• The scope of the solution that you describe in your article should be clearly sized concerning
  • the type of problem that the solution is applicable for,
  • the extent to that requirements will be met and
  • the limitations that apply.
• Scoping should include the information for what releases of a product the solution is applicable, e.g. starting from version ...

After writing

Have someone review your article

• It is always a good idea to have someone review your article.
• Receiving a second opinion might help to discover aspects of topic that were out of your radar.
  • The famous saying that there is more than one way how to do it, is particularly true for our products.
  • Use the share operation that is available on every page in the knowledge base to invite other users for review.

...

• So you think you're done having received some feedback on your article? Definitely not.
• Articles tend to become inaccurate and even obsolete by ageing. . This might be due to newer versions of the product or updates to the environment.
• Therefore add an expiration date to your article, e.g. for six months later. When that time has come then you will be notified by mail that your article has to be reviewed or otherwise will be marked as invalid.