This time I will tell you how the micro-module approach will help you structure layouts, build a clear documentation system, and get a semblance of versioning.
As it usually happens-the product consists of modules, modules consist of screens (screens consist of blocks, and blocks of components). All this is tied up with flows, in which the designer shows transitions between screens within specific scenarios. And, it seems, everyone is happy.
Problems appear when you need to keep up-to-date a large number of scenarios (flow), each of which has dozens of screens and their States.
It turns out that you need not only to store the current layout of each screen with all its States somewhere, but also to constantly update the images of this screen wherever it is used.
If the product has more than twenty screens and they are not in the same file, then the task can be safely considered tricky due to difficulties with synchronization. If you store many layouts in one figma file, then working with it will cause pain, both for the designer and for everyone who interacts with this design later. Still, of course, you can score and pass the point of truth to the development, but this is not the way of the samurai.
Suppose we have the usual banking application, for simplicity, there is only one account, and you can pay only for the water. To do everything in an adult way, we need the following sections::
These sections will become the main modules. Let’s assume that a module is a set of related functions.
Enter the following rule — a module is assigned to each screen. The actual screen design can only be found in the module’s figma file and nowhere else. Such is serfdom.
Usually, if the product already exists, then there are not many completely new flows. Basically, existing chains are being finalized, where one or two screens are new or changed, and the rest of the layouts are needed only to show the whole picture.
Let’s take a simple scenario —
– the User, scrolling through the list of operations in Analytics, opens information about the transaction and decides to repeat the payment. He pokes the button on the transaction screen and gets to the “Payments and transfers” section with pre-filled payment parameters, confirms the transaction with an OTP code and sees the session screen
we have all payments passingt.
Let’s assume that previously there was simply no “Repeat payment” button on the transaction screen, and … so we added it. It turns out that for a feature from a single button, you need to make a new flow, describe it, and conduct a bunch of consistent testing rituals with a new scenario. But the worst part is that if you just throw all the participating screens into a new chain every time to demonstrate the script, we will get an infinite number of duplicate layouts and, as a result, out of sync. We don’t need that.
To do this properly, we will take screens from different parts of the system and distribute them to our modules. And in order to still be able to somehow use screens from one module in scripts from another, let’s start using links.
Since payment for water lives in the module “Payments and transfers”, we will simply refer to a specific scenario from this module. And all.
The flow is still clear — we went to the payment history, selected a payment for water, poked repeat, and then it will somehow pay itself, this is a different scenario.
There is no longer a problem with outdated layouts in the flow and duplication. Now the modules do not need to be synchronized with each other, as we physically move from one file to another. Good.
To make layouts within the module easier to describe, transfer to development, and even versioning, you should divide the module into submodules. Immediately it should be quite good.
Typically, a module has several custom tasks that it serves. For example, the module “Payments and transfers” in our banking application should allow the user to enter payment details, confirm the action with an OTP code, and be able to report the result of the operation. Well, there should also be some kind of screen from which the user can launch the script they need — a screen with a list of all available payments and transfers (where we will only have “Pay for water”).
It turns out that we need the following pieces::
We also need a thing that the user will use to confirm the operation, even if it is an OTP code. But since, most likely, with the help of this thing, he will be able to confirm anything at all, we will not push it into the payment and transfer module.
It is noteworthy that these things do not need to know about each other’s existence at all. This isolation is done for this purpose.
– Once, and we began to confirm the payment by drawing a heart on the screen with our finger. I don’t think it has anything to do with things for entering banking details or displaying status.
By changing the isolated micromodule, we probably won’t have to change any of the flows that used it. This saves a lot of time and solves a lot of communication problems.
The micro module should have its own area of responsibility, preferably it should be a specific action that it should be able to do. Single responsibility all cases.
The thing for “confirming an action” should be able to be embedded in any flow where confirmation of an action is required. Because it can confirm an action, but it can’t do anything else — just provide input for entering a password and say OK/not OK. Well, it can still initiate sending the code again, if you ask it well 🙂 In the desired part of the script, the micromodule microservice will take control of this script, process user actions, and, if necessary, transfer control to the next element in the chain.
It turns out that the “confirmation of action” micro-module is absolutely not important inside which scenario of any of the modules it may be required.
This approach seems obvious for things like SMS validation, but there is an opinion that it is applicable to all tasks solved by the application. Some micro modules are reused frequently, some almost never, and this is approx.
Any user case can be divided into subtasks so that each one is served by only one or two screens. such mini-chains are most likely candidates for micromodules.
Important! The logic of operation and processed cases of the micromodule are described in the framework of its documentation. The States of incoming screens are described using descriptions of blocks and the States of these blocks. No 100500 home screen layouts to show
hover States for all search bar buttons or different widget States. The documentation should describe enough context to clearly understand what the micro module can do and where it is appropriate to use it. Then everything will be fine.
Division into modules allows you to get some kind of figma-versioning.A little explanatory whining
Each module has three versions — three pages in the file:
Each version consists of the necessary versions of the corresponding micromodules. For example, if there are only 10 micromodules in a module, but changes in the nearest CR affect only three of them, which means that there will only be 3 of these micromodules on the CR page.
As soon as the CR is released, the modules in the PR are changed to current ones, and changes for the next feature are added to the CR.
Having moved to this approach in preparing layouts, you can almost completely mow down the duplication of screens, which breeds chaos and inconsistency. Micromodules will significantly speed up the design of new features, if, of course, the entire team can reach a higher level of abstraction.