The purpose of this page is to give you the best conditions for setting up and building a protocol from scratch. These insights are based on experiences working with different protocols across our customer base. Some of the tips/tricks may be more useful to you than others. So feel free to use the guide to the extent you desire.
Tip: Before starting any protocol editing work make sure you only have one tab open within the protocol editor, and that no one else is making changes in the protocol simultaneously. Failure to do so may results in lost protocol work.
There are many different options for how to design the view node, and while this guide offers some best practices based on existing customers, you can of course deviate from it, if your specific organization has other needs/wishes. However, the first basic rule for designing view nodes is consistency.
Be consistent with how you structure and design the nodes, as that is key to how the card and actions are interpreted by the call taker. Random, inconsistent copy and format will confuse the call takers and allow for too wide an interpretation of what action the card/node calls for.
Suggested best practices for designing protocol nodes
- Keep the cards short, to avoid the need for call takers to scroll through a card. Hover-on-text, and collapsable paragraph blocs can be helpful in reducing card-length (read more in the Styling section below).
- Avoid having more than one call for action pr. view node e.g. only add one question for each node. If you believe that grouping questions in one card is optimal in your case, then make sure that they are at least related to each other.
- Use select blocks as much as possible over e.g. free text blocks, as they are optimal for reducing the documentation-burden for call takers and reduce call duration and/or call-handling-time.
Formatting and styling the cards
- Key information that needs to be collected within a card should be written in bold.
- Direct instructions to the call taker should be written in italic.
- Hover-on-text can be used to add more context to a text piece, for call takers that might not completely remember the SOP-details. This is especially helpful when building select-options that are less suited for text-heavy selections.
- Headings: Cards that entail a conclusion, such as Criteria Code for PSAP clients, or coverage-evaluation for Health Insurances, should include a paragraph-block with a heading with the name of that conclusion (see pic below from a PSAP), to ensure that call takers have a good overview of where they are in the flow.
Bonus info: You have the option to make paragraph-blocks Collapsable if there is additional helpful information to a card (see pic below). This allow you to add elaborative information, without impacting the overview and node-length.
