Design guidelines for Actions in the web client

Actions

When users interact with the CRM, they often engage in various manual tasks, including creating new objects, updating existing information, or adding notes for future reference. Some of these actions are straightforward, like clicking a "SAVE" button or selecting options from a menu, while others are more complex and involve multiple steps, such as preparing an invoice or sending a document for signing. Regardless of their complexity, all these actions share a common need – a visible element in the user interface that allows users to initiate the process.

This guide aims to provide you with insights into what's possible and how to make informed decisions, when you're developing new features for a customer. We strongly recommend consulting a designer for further assistance!

Types of actions

The Web Client's user interface provides predefined locations for various types of actions. However, when you're working on developing new features for a customer, deciding where to position the trigger element for your intended action can be a challenge.

To simplify this decision-making process, the first step is to categorize the "type" of action your feature will provide to the end user. Once you can clearly define this, determining the appropriate placement for the action trigger becomes straightforward. In essence, there are only two categories of actions: Promoted Actions and Un-promoted Actions.

Promoted actions will show up in the Contextual Action Bar on cards (Red box). Un-promoted actions are discreetly accessible via the ⋮ menu at the top right corner. (Blue box)

1. Promoted Actions

There are some actions that are very straight-forward and their effect is immediate. Users frequently need quick access to these actions without being forced to navigate or scroll to a certain area of the user interface. This means that the actions should be easily discoverable by the user. We refer to these as "Promoted Actions". They are thoughtfully grouped and displayed in an action bar on an object card, referred to as the "Contextual Action Bar". This contextual action bar is consistently visible across all tabs.

Think of these actions as if we are telling the end user:

It is very likely that you want to do one of these things with the record you have in front of you.

or,

We thought that right now, you’d be looking for one of these action, and next time you come here again, you’d most probably be looking for the same things. So, we've bundled them here for easy access.

Promoted Actions are inherently contextual. They are relevant here and now! Hence, we've aptly named the designated area for these actions the "Contextual Action Bar" and ensured it's consistently available across all tabs. Consequently, it's crucial to remember that actions lacking immediacy or relevance to the current context should not be placed within this section!

While Promoted Actions are easily accessible through the Contextual Action Bar, it's crucial not to overwhelm this area with every possible action that can exist on an object card. The term "contextual" is essential, indicating that the actions displayed should be relevant to the user's current needs, right now.

We intend to encourage and or guide the user to pick one of the presented actions. First of all, we cannot display too many actions at once, because that would only confuse the user and make it hard to find the most relevant action amongst the presented ones. Secondly, there can’t be too many actions at a given context that are all equally important, in demand, and relevant.

When deciding which actions to display, always ask yourself:

• Ok… what are the most relevant top 5 actions that the end-user might want to do in this specific context?
• What are the most relevant Jobs-to-be-Done in this particular context?
• When the user comes here, what is it that they are most likely intending to do?

Examples could be “moving the record forward” in a linear process, such as in "ticket handling". Examples could include actions like:

• “Close” (on a Ticket card), or
• “Re-open” (which should only be shown when a ticket is "closed"),
• “Send for e-Sign” (on a Document card),
• "Sign a document" (on a Company card),
• “Mark as Done” (on a Todo card),

So, try to hide the actions that are not relevant now. We call them Un-promoted Actions, and there is a specific place for displaying them in the CRM.

2. Un-promoted Actions

Actions that you prefer not to emphasize should fall under the category of un-promoted actions. These are actions such as "Archive" or "Anonymize," primarily intended for infrequent or specialized use cases.

Furthermore, certain actions may carry a significant level of risk, irreversibility, or potential harm, making it advisable not to promote them to the user. The most common example could be "Delete".

This rationale is why some views do not display un-promoted actions on the presented records. For instance, in the "List View," you won't encounter un-promoted actions, but in the "Card View," they are discreetly accessible via the ⋮ menu at the top right corner.

✅ Do. Promote actions like "Assign me" and "Close ticket" that the user is likely to perform, here and now. "Assign me" should only show if I'm not already assigned ans "Close ticket" shold only show if ticket is open. The other actions should be considered not as relevant here and now and fit well in the ⋮ menu.	❌ Don't. Putting all actions as promoted actions causes noise and encourages the user to do actions that are most likely not relevant here and now. One can only hope that "Merge duplicates" is not something that needs to be done at every ticket.

✅ Do. Actions related to GDPR are most of the time not relevant here and now. Therefor, they should be kept within the GDPR widget or shown as un-promoted actions.	❌ Don't. Actions related to GDPR are most of the time not relevant here and now. Therefor, they should not be shown as promoted actions.

Use verbs in imperative mood

The imperative mood is a grammatical mood that forms a command or request. The imperative mood is used to demand or require that an action be performed. Thus, actions are always communicated in imperative form, as a verb, encouraging the user to do something (or sometimes from the user's perspective, they are commanding the system to to something by pressing the action button). "Create", "Write", "Add", "Download" or "Open" are examples of good words to use.

It's crucial to recognize that the context plays a pivotal role in selecting the most fitting verbs, sometimes in conjunction with other words. For instance, "Send for e-Sign" suits a button on a Document card, while "Sign a document" is a more appropriate title for a button that triggers the same process, albeit from a Company card.

✅ Do. Use verbs in imperative form such as “Add” or “Upvote”	❌ Don't. Do not use nouns since it is hard to understand what such a button would do.

⚠️ Not Everything Is an Action!

Not everything qualifies as an action, and not every action needs to be represented as a button that opens up an ugly modal or redirects to a new browser tab, in which the user can perform what they want.

In many cases, thoughtfully designing a widget is more suitable choice. Keep in mind that modals are very intrusive elements, since they block the user from interacting with the rest of the page or see the visible content.

So do not mistake Actions for just being “buttons that do things”. The contextual action bar is not a slot for “buttons”, but for for genuine "actions" – actions that, when initiated, are swiftly executed.

The question of "what is a better design then?" is a complex one, with the answer often varying according to the specific use case. Consulting a skilled designer is an excellent approach to addressing this question, as there are numerous potential solutions.

Nevertheless, a typical solution to this design challenge may involve considering whether the task that the user intends to do qualifies as a "promoted action" or "promoted task". If the user frequently needs to perform a particular task in a specific context, and that task should be easily accessible, a minimalist user interface (referred to as a "widget") can be designed for seamless task execution. This widget can be positioned in the designated widget area on top of the Object Cards, providing a streamlined and efficient user experience.

✅ Do. Use actions for simple, straight-forward things.	❌ Don't. Do not use actions for things that are not "actions". "GDPR" and "Form" are not actions. "GDPR" for example is a "menu"; a group of options that are related to the GDPR law.

✅ Do. Sometimes a widget, such as a map, is useful. A widget could, as in this example, hold a contextual action such as “View larger map”.	❌ Don't. “Get directions” is somewhat out of context and not related to the information it will use (the address).

Use icon colors sparsly

Please do not apply an icon color, just because you can! Only add a color if you really intend to communicate meaningful things with colors. Concepts such as Danger, Caution, Warning, Safety, etc…

✅ Do. Only use icon colors when you really need them.	❌ Don't. Do not apply colors to icons just because you can.