When designing, we also lay down additional “rudiments” - components necessary for a particular case. They can be reused in the next stages, when the corresponding features appear. At the same time, the largest part of the interface is built on conditional 3-4 components, which are customized for the necessary tasks - the so-called "stupid components".
The concept of project organization implies a breakdown into smaller components according to a tree structure:
The files are divided into pages by navigation tabs or by features.
In working layouts, each scenario or page has its own status - a tag.
All layouts on the page are linked to each other in such a way that the team does not get confused. Layouts have a numbering and state name or a label that describes it.
Specifications are attached to the screens on the pages. Markups and specs are designed to briefly describe the behavior of an element or screen in a given situation as conceived by the designer. It also helps to communicate small but important things that may affect the development. For complex screens, we attach a spec that reflects the behavior or interaction, and also add an animation with a link to the prototype or video.
The UI library is divided into subgroups with state tags so as not to confuse other designers and tell developers what can or cannot be touched.
Our task is to create conditions in which the design can be significantly changed without effort, not only in layouts, but also in code. Including after the end of our work and the transfer of the project to the client.
The client can change his mind. Today he wants a blue light theme, and at the end of the project, a dark red one. You can refuse it or include revision as a separate item after the release. But it will take time again: reworking the library, layouts, naming, new styles and tons of development hours. Therefore, we lay such cases every time when there is even the slightest suspicion that this could happen. We may never need a dark theme, but we are no longer stepping on our own rake and designing for scaling.
It is good practice to design a design system after the entire design has been created. It is also useful to design a UI kit before the start of rendering, remembering to organize and maintain a single navigation system on each project. We use the third option - our own, taking into account these features.
First we create the basis of the library and only then we start designing the final layouts. Then we fill it as it is drawn, but only with those elements that reuse early components and will work more than once.
Suivre le flux RSS des articles
Suivre le flux RSS des commentaires