Authors can speed up and increase the quality of Module-building by adhering to the best practices the BRYTER team has put together. For more inspiration and to see how these best practices are applied, head to the Templates section or ask your Customer Success Manager for additional tips and tricks.

Download the attached complete Module building: Best practices guide (please scroll to the bottom of this article) or read through selected best practices below.

End-user interface

Layout of Input Nodes

General best practices

Headlines	Keep formatting style, wording, and syntax of a headline in every Input Node consistent throughout the Module.
	Headlines should be concise: A headline briefly summarizes the content of an Input Node (e.g., "Personal details"). Refrain from using full sentences and keep it as short as possible with keywords.
First Input Node	Use a Module name (e.g., "Commercial Contract Assessor") in your first Input Node in a standalone Module. If the Module is only one component in a Service with several Modules, only use the Module name in the Module that would be used first and do not mention it again in the first Input Node of other Modules.
	Use Heading large for the title of the Module in the 1st Node. Subsequently, use either Heading large or Heading medium.
	Do not use a welcome message in the text body of the 1st Node (e.g., "Welcome to the Contract Assessor [...]"). Instead, describe the purpose of the tool and what it can be used for (e.g., "With this tool, you can assess commercial contracts with regard to [...]").
	Do not use a generic Module name such as “BRYTER tool” but rather explain the functionality, e.g., Assistant, Assessor, Questionnaire, Generator, etc.

Multi-Input vs Single Input Nodes

Multi-Input Nodes	Group a set of inputs that are logically connected, e.g., “Personal Details” or “Address”, into one Node under the same heading.
	Multi-inputs generally look more appealing as the screen looks less plain and are more user-friendly because they reduce the number of clicks through Single Input Node screens.
Conditional Multi-Input Nodes	When collecting information from end-users that depends on previous input in the Module, use the conditional multi-input feature. This will keep the Module streamlined and ensure the user only see's what they need to see.
	When you need to collect multiple pieces of information from end-users that are conditioned on one or several previous inputs or values, it may be better to use a new input Node for this to reduce the amount of nested or second layer logic.

Language

Language settings	If possible, select a language & region in the publishing settings (currently English and German) to match the language used in your Module. Note that this setting also affects how numbers are formatted.
Capitalization	Keep capitalization of titles and info blocks consistent.
Tone	Depending on your audience, keep the tone informal or formal throughout the Module and Email or Handover Nodes.

User experience

Call-to-action	Keep the question or call-to-action close to the actual input field in Single Input Nodes.
	The styling of the call-to-action should be consistent, so either choose headline small or headline medium or keep it formatted in italics, bold, or *both*. The format you choose also depends on the theme you have selected.
Info blocks	Decide how you will use info blocks and keep this style throughout the Module as much as possible, e.g., info blocks as hints or info blocks for definitions.
	Depending on your Module’s theme, format the headline of an info block as either bold or regular. Apply the formatting consistently throughout the Module.
Images	When using images, use the aspect ratio 2:1 and keep the aspect ratio the same for all images.
	Keep the color tone of images consistent or only use black and white images.
Tables	Use a table when displaying a collection of information to the user. For instance, showing a summary of inputs or outputs using a table will produce a neater front-end that is easy to read and compare.
	Ensure the titles of the columns in the table are bold to distinguish them from the rest of the information in the table.
Emojis	Depending on the intended audience, emojis can be used in Modules where appropriate. This can make Modules more visually appealing and more intuitive to use.
Videos	Use videos as early as possible in your Module. This will decrease the skip rate.

User navigation

Content Nodes	Use Content Nodes when no end-user input is required. For example, Content Nodes should be used in the first screen, which provides a summary of the tool and its value proposition.
	Use content Nodes to structure your Modules and provide preliminary results – especially in long Modules.
Confirmation page	A confirmation page in a Result Node should only be enabled if you want to give end-users a visual indication that they have entered all necessary inputs and want to allow them to click on the back button. Note that enabling the confirmation page might encourage users to not complete the Module and drop-off too early.
Linkbacks	Use linkbacks to allow your end-users to go to a certain input Node, e.g., a selection menu. Linkbacks will overwrite the content that was provided when skipping back to a certain Node, so use them only in Modules where this does not affect the Module stats adversely.
Handover Nodes	Always provide clear instructions in both the upper content field and the lower email action. The upper content field should state what the end-user reaching this Handover Node can expect, e.g., who will now be informed, how long will it likely take, etc.
Redirect Result Node	Use a Redirect Result in combination with a Single-Select Node to allow users to easily restart the Module (Redirect) or conclude the session and Module (Result only).
	Use a Redirect Result instead of a link in the content field when redirecting to an external URL, e.g., an intranet page or official guidelines at the end of your Modules.

20211027_BRYTER_Module building best practices.pdf
600 KB Download