Action represents a meaningful activity that a user can perform in a given Context (or page). It comprises of logic involved in realizing such an activity. While there is no restriction on how you define boundaries for such Actions, it is important to follow certain guidelines. Here are the benefits of a well designed Action
- Maximize reusability and modularity
- Minimize ongoing maintenance
- Provide a business focused orientation for Scenario
Consider following flow in QBank application for the examples listed in this article.
1. An Action should indicate business semantic
For example, "Login" is an Action. "Enter username", "Enter Password" etc. are not Actions. From the end-user point of view, "Enter username" is not of business significance. It is just a step in achieving Login.
2. Logic in an Action should be exclusively limited to only one Context or Page
One given Action can work with multiple Views of a Context, but never more than one Context.
For example, in the QBank application, "Provide Funds Transfer Info and Verify Confirmation" is happening in two different pages. Do not combine them together. Break them into two actions - "Provide Funds Transfer Info" and "Verify Transfer Confirmation".
3. Even within a single Context, do not combine multiple independent functions in to one Action
For example, lets say in a given Scenario you need to verify recent activity and current balances in the Account Summary Page. In this specific Scenario, it might look meaningful to provide this as a single Action. But evaluate from reusability point of view. Verifying recent activity and verifying current account balances are two different tasks. Separate them into two actions and call both Actions from the scenario. It makes for a better reusability and maintenance.
4. Extent of logic should not dictate Action boundaries
For example, in the Account Summary page, "Initiate Funds Transfer" is an Action that just involves clicking a button to go to next page. But still it qualifies as an independent Action as it switches the user to another page. Navigation actions typically involves just one or two statements such as hover, click etc. But they are perfectly valid as independent Actions.
5. Effective parameterization can eliminate lot of Action duplication
If not designed properly, you may end up creating multiple duplicate Actions for each combination of input data. For example, "Transfer funds from Checking Account to Mortgage Account" should not be defined as an Action. Instead, "Source Account" and "Target Account" are the parameters to "Transfer Funds" Action.
6. Pay attention to how you name an Action
Name the action in such a way that it can be understood in the reference of the entire application. For example, "Verify Funds Transfer Confirmation" is a better name than "Verify Confirmation". When building a Scenario, Action names should be self explanatory.
Also, name the action based on what it is accomplishing rather than "how" it is accomplishing. For example, "Initiate Funds Transfer" is a better option than "Click Funds Transfer button". The nature of "how", can change in the future as the application evolves.
Finally, Action indicates a "verb". Name it accordingly!
"Funds Transfer Information" is a poor choice compared to "Provide Funds Transfer Info".
7. Share an Action where it makes sense
For example, "Logout" functionality in QBank is available in every page after the Login. Do not define this Action in every Context. Define in one of the Contexts and share with all others.
Apart from these considerations, some times an Action may be broken down into multiple sub-actions for technical maintainability. Such Actions are "called" internally by the main Action. They are not necessarily relevant from Scenario point of view.
Actions should be meaningful from the Scenario perspective, so that Scenario truly behaves like a business process. Too much granularity with definition of Action at a field level or combining multiple un-related activities into one Action results in lack of reusability/modularity and increased maintenance overhead.