Design guidelines for Actions in the web client¶
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.
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.
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.
|✅ **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.|
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 "Mark as done" and "Postpone" that the user is likely to perform. These should only be shown for undone to-dos. "Duplicate" and "Delete" should be used as un-promoted actions, as users seldom perform these actions.||❌ **Don’t.** “Resume” and “Add next todo” should only be visible when a to-do is done. Hence, they are not relevant here and now.|
|✅ **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.
only to be confronted with a modal housing a complex or multi-step user interface (often referred to as a "wizard", a more complex user interface for performing a multi-steps jobs), this should prompt a critical evaluation of the design.
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.** 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).|