Seeking Advice on Knowledge Article Structure for Improved User Experience

[Kohei Tominaga1]

Hi ServiceNow Community,

I'm looking for advice on structuring knowledge articles to improve the user experience for our employees. Currently, we have two sets of documentation: system-specific manuals (e.g., for SuccessFactors and ServiceNow) and process-specific manuals. Employees follow process manuals, but these constantly require them to jump to the relevant sections of system-specific manuals for operational instructions.

For example, the employee handbook for a transfer process might direct users to the SuccessFactors manual for checking position information and then to the ServiceNow manual for submitting the transfer request. This requires employees to navigate multiple documents, resulting in a poor user experience.

One potential solution is to integrate system-specific instructions directly into the process manuals. However, this raises concerns about double maintenance – any update to a system-specific manual would necessitate updating the relevant process manuals, leading to redundancy.

We also want to keep our knowledge articles concise, following ServiceNow's best practices for Now Assist functionality. Therefore, lengthy articles are undesirable.

Considering these constraints, what strategies would you recommend for structuring our knowledge articles to provide a seamless and efficient user experience? Any advice or best practices you've implemented would be greatly appreciated.

[Mark Manders]

Check on what your employees are really searching for. It sounds weird that you need two documents to do something. 
The 'how to submit a transfer request' should contain the info 'check here in SuccessFactors for your position information if needed'. It shouldn't say "check the SuccessFactors manual to see where you can get position information".

You can link from one article to another ("if you need assistance in getting your information, see this article") but I guess your biggest issue is that you are not having functional and technical information separated. Your separation on system and process makes it hard for end users to get the correct information. Knowledge should be setup from the user's perspective: I need to do A, so all information for A needs to be available. If I need B for A, I need a link to get B if I don't know it. 

If a process uses two systems, you should have 2 articles: functional and technical. One for the end user in need of the process and one for an engineer to check on what is or can go wrong.

[Kohei Tominaga1]

Thank you for your reply.

So, you mean that for end user the manual should include every instruction of systems they need to access in the process?

In the example of Transfer request, the manual for end user should include how to get position data in the SuccessFactors, how to login and every steps to access position menu and how to search the data they need to confirm, correct?

[Mark Manders · Accepted solution]

Yes, indeed. What is it that your end users are looking for. That should be in the knowledge article. (Almost) no end user is looking for a manual of a (software) system. He or she wants information on how to do X. X should be explained in one article and not tell them to look for the answer somewhere else. Let's keep it with the transfer request:

Knowledge article should explain what the transfer request is and what is expected from the end user when creating one. It should have the link to the catalog item/record producer in ServiceNow and should tell them the information needed with a link to where that information is stored. Not a link to the product documentation of either platform.

Another knowledge article (you could link to, if needed), is there to explain what to do in SuccessFactors if you don't now yet where to get the needed info. But that's a separate thing, because you probably need it for other requests as well. If it changes, because it works differently after an upgrade, or something like that, you only have to update that one article.