¿Cómo se realiza un seguimiento y se gestionan los patrones de diseño de la interfaz de usuario en múltiples proyectos y productos?

I've found that having a personal library of UI design patterns helps a lot. I regularly update it with new patterns that I stumble upon or create during my design explorations. As design trends evolve, so do UI patterns. I make sure to review my design patterns regularly to ensure they're still relevant and effective.

A design patterns library can be a game-changer when it comes to building a product for reuse and scalability. Having a robust design system and UI patterns library within your team enables rapid development and scaling of the product. This shared resource, complete with documentation encompassing layouts, user flows, components, visual elements, tokens, and brand language, ensures that everyone stays aligned. Moreover, it significantly streamlines the workflow for the entire team, granting designers more time for creativity and allowing developers to swiftly assess and enhance their CSS libraries. Sounds amazing, right?

To effectively manage UI design patterns across multiple projects and products, establish a centralized repository or design system. This system should document standardized components, layouts, and interactions. Regularly update and maintain the repository to ensure consistency and accuracy. Collaborate with team members to gather feedback and iterate on design patterns based on evolving needs and best practices. Implement version control to track changes and revisions over time. Additionally, establish clear guidelines and documentation on how to use and implement design patterns to ensure consistency across projects. Regularly review and audit design patterns to identify opportunities for improvement and optimization.

Within my design system, I categorize patterns based on their function and use. For example, navigation patterns, form patterns, content display patterns, etc. This makes it easy to find the appropriate pattern when I need it.

One of the ways to keep the design system up-to-date is make it a part of your process. For instance if you are building the design system for a product, maintaining the same must be a part of your product work routine (sprint plan/weekly plans etc..). This will help you ensure consistency in maintaining it.

There are different 'levels' of design system, and not all products require the most complex system – lest the documentation become more effort than the project itself. Creating a modular design with reusable patterns is the least complex 'systemisation' of design. Add documentation as you need it, creating a style guide, pattern library (in design tools and/or code), tokens et al and work your way up to a complete design system microsite if you need to. Design first, then systemise the patterns that emerge.

Like most pattern data, design patterns can have multiple classification schemes. It is best to use a tag based organisation system, where one pattern can belong under multiple categories and that makes it easier to discover and locate for designers looking for patterns.

Design systems are highly dependent on the clarity and organization of the team behind them. As maintaining an in-house, custom developed system is often a difficult task, teams decide that everyone is responsible for building and organizing it. While this is true, the practice shows that there should always be one person who owns the process and nourishes it. This person is the design system champion — the one who is passionate about it and is helping with the alignment of changes, with updates, and with organizing any new parts. Make sure you find someone on your team who can continue the growth and organization of the system and align everyone in the organization.

Think of your design documentation as a product – and ask, "how will this be used?" Putting yourself in the shoes of the designers, engineers and CMS editors that may use your patterns will help you elaborate what content needs to be included in your documentation. Some common examples are when/how to use a pattern, accessibility and SEO concerns, content/microcopy guidance and live code examples. As with all products, the best way to know what your users' need is to observe and ask them.

Additionally, to make using the design patterns intuitive, it's good to add context and use-cases as reference (this can be the part of the documentation). This makes it easier for the team member using the design patterns to understand the why, what and how part of the design patterns applied to elements and components, which further helps in meaningful reuse of these patterns at relevant instances rather than using it literally.

Chronicle design system and by not documenting it can help other team members understand the various steps and procedures used in implementing it

In my design systems, patterns usually are documented by the following aspects: 1. Tags - metadata which lists the categories which the pattern falls under, the tags are linked to search results by that tag. 2. Description - a general outline of what the pattern is and does. 3. Demo - a demo of the pattern being used with figma and storybook links if available. 3. Usage - the common situations where that pattern is usefuls and dos and don'ts for using the pattern. 4. Alternates - if there are other patterns which do similar things, they're linked here. 5. Components - a list of links to all the components used in the pattern, to make it searchable by components and point to component documentation for further use.

The ideal way to share patterns is through a self-hosted site or microsite but for most teams the optimal solution is a cloud-service such as InVision DSM, Frontify or Zeroheight combined with Storybook. The latter has less operational overhead, at the cost of out-of-the-box functionality. As an agency/consultancy you'll need to consider the cost of locking in a client to a particular platform and cost. The most important thing is to remember to bring content for all users together and make it discoverable. Design artefacts, coded components and content guidance.

There are two common reasons to not reinvent the wheel; matching user expectations and efficient production. Objects tend to standardise over time, e.g. gamepads with buttons right / directions left. Deviating from shared expectations, e.g. push doors with pull handles, can impair usability. Per Jakob's Law; "users spend more time using other's products", so match users expectations. Products are also easier to create and maintain when they use fewer, reusable parts. Reduced complexity makes production more efficient. There's also third reason. When you spend less resources on table-takes features it leaves more time for differentiators – signature moments where the lack of standards allows you to impress, at the cost of more research.

There are two common reasons to not reinvent the wheel; matching user expectations and efficient production. Objects tend to standardise over time, e.g. gamepads with buttons right / directions left. Deviating from shared expectations, e.g. push doors with pull handles, can impair usability. Per Jakob's Law; "users spend more time using other's products", so match users expectations. Products are also easier to create and maintain when they use fewer, reusable parts. Reduced complexity makes production more efficient. There's also third reason. When you spend less resources on table-takes features it leaves more time for differentiators – signature moments where the lack of standards allows you to impress, at the cost of more research.

Some of the most expressive uses of grid-based design came from print going back to Neue Grafik and the international style. I also encourage people to read The Graphic Artist and His Problems. Then jump forward to Ray-Gun and David Carson in the 90s to really get a good contrast.

In my experience, I encourage all front-end engineers to read "Atomic Design" by Brad Frost. This book showcases how adopting atomic design methodology starting at the most foundational level enables scalable design patterns and allows all team members to accept or challenge the presented designs. Atomic Design compliments a cross-functioning team by offering a language that is easily understood across the board.

Version Control: Implementing a version control system helps track changes to UI design patterns over time, allowing for easy rollback to previous versions if needed. It ensures consistency across projects and facilitates collaboration among team members working on different aspects of UI design. Version control systems also provide insights into usage patterns and trends, enabling continuous improvement and refinement of design patterns.

User Feedback Integration: Incorporating user feedback into the management of UI design patterns ensures that patterns remain relevant and effective. By soliciting feedback from users through surveys, interviews, or usability testing, designers can identify areas for improvement and iterate on existing patterns accordingly. This iterative process fosters a user-centric approach to pattern management, leading to better user experiences and increased satisfaction.

The power of patterns comes from cross pollination. A pattern library entry should link to design assets, development assets, implementations and suggestions for modifications whenever possible.