Tipps for creating content in Q.wiki - Process description vs. Work instruction

Modified on Thu, 2 Apr at 4:19 PM

Good process descriptions and work instructions are the backbone of a functioning management system. In this article, you'll learn how to structure content in Q.wiki, which template to use when, and how to write a well-structured process description – your "recipe".

6 Basic Tips

Define your goal clearly: First, think about who you want to reach with your description. Are they experts or people new to the topic? Is the process complex or straightforward? Adjust the level of detail accordingly.
Choose the right level of detail: Only go into as much detail as necessary. A simple workflow needs less detail, while an error-prone process requires more information. Your description should enrich daily work, not just meet external requirements.
Create a process-oriented knowledge portal: If you want to use Q.wiki as a knowledge portal, it's important to explain not just what to do, but especially how to do it. Explain the steps clearly, as in a recipe, and link each step to all the important information and "ingredients" needed to carry out the process (documents, links, etc.).
Design it decentrally: Give all employees in your organization the freedom to add information and new insights. This keeps your documentation alive and helps it adapt quickly to current circumstances and needs.
Remain flexible: Keep your description flexible so it can adapt to new requirements. A rigid description quickly becomes unusable. Bullet points are easier to update than lengthy, grammatically complex prose.
Don't overemphasize the "why": The question "Why do this?" is often less important. It usually only matters when onboarding new employees. What really matters: How do I do it? Use active voice. Write "Train employees" instead of "Conducting employee training." This clearly conveys the purpose of each process step and prevents misunderstandings.

The Key Points at a Glance

Good to know: A well-written process description documents standard cases. It is clear, relevant, and adapts to your organization's current circumstances.

✓	Use bullet points, not prose
?	What do I do? – Active phrasing in 3–5 words
→	How do I do it? – As much detail as necessary, as little as possible
?	Link documents and systems
?	Only one role can be responsible for a step
⚙	Design your content process-oriented

Process Description vs. Work Instruction

Both templates have their place in Q.wiki. Which one you choose depends on the nature and scope of the activity:

Process Description	Work Instruction
Cross-functional workflow with medium level of detail in individual subprocess steps	Narrow scope with high level of detail in individual work steps (step-by-step / click-by-click instructions)
Changing responsibilities frequently, but not necessarily	To be performed by one person – no changing responsibilities
Activities not necessarily connected in time over a long period	Activities connected in time over a limited period

How Do You Write a "Recipe" in Q.wiki?

Use the "Process Description" template and structure your content in three columns – like a recipe with instructions, ingredients, and responsibilities:

Column 1: Description of Steps

Describe the individual process steps in bullet-point format:

Link the upstream and downstream processes at the beginning and end of the table
Detail the sub-process steps
- Modeled as bullet points
- Enriched with employee experience and insights
Comment on deviations from the actual process and spontaneous improvement suggestions, or submit them directly as a change proposal

Column 2: Tools and Documents

Link all necessary documents and systems here:

Input: < (the arrow goes "into the process step")
Output: > (the arrow goes "out of the process step")

Documents to upload in Q.wiki:

Email templates
Templates (e.g., forms in Word, Excel, PowerPoint, etc.)
Checklists

Important: What should not be in Q.wiki? "Living" documents (customer documents, completed templates, etc.). These belong in a folder in your file management system (e.g., the SharePoint folder where the document is stored – this should be linked).

Column 3: Responsible and Involved Parties

Clearly define who is responsible for each step:

Clearly defined responsibility in the form of a role
- Do not enter names, but use role descriptions (e.g., Purchasing Manager)
- Develop a role concept – enables centralized management of role holders
Enter any other involved roles under "Involved Parties"
Benefit: Interfaces become very visible quickly
- Optimization opportunities can be identified
- Risks can be minimized

Structure and Template Selection in Q.wiki (Video)

This video shows you practically how to structure Q.wiki, select the right templates, and build and maintain your human-centered management system sustainably: