12 User interface and design system

 

This chapter covers:

  • Examining how a design system can help deliver a consistent experience to your users
  • Developing a design system and how it can affect the autonomy of the micro frontends teams
  • Technical challenges when building a pattern library that should be technology-agnostic
  • Distinguishing if a component should go into the central pattern library or stay under a product team’s control

In a micro frontend architecture, every team builds its part of the frontend. A team can plan, build, and ship new features without talking to its neighbors. But how do you deliver a consistent look and feel for the user? The different frontends should use the same color palette, typography, and grid layout. These measures ensure that the website does not look weird. But it typically doesn’t stop there. There’s also button styling, spacing rules, breakpoint definitions to support a variety of screen sizes, and a lot more.

12.1 Why a design system?

12.1.1 Purpose and role

12.1.2 Benefits

12.2 Central design system versus autonomous teams

12.2.1 Do I need my own design system?

12.2.2 Process, not project

12.2.3 Ensure sustained budget and responsibility

12.2.4 Get buy-in from the teams

12.2.5 Development process: Central versus federated

12.2.6 Development phases

12.3 Runtime versus build-time integration

12.3.1 Runtime integration

12.3.2 Versioned package

12.4 Pattern library artifacts: Generic versus specific

12.4.1 Choose your component format

12.4.2 There will be change

12.5 What goes into the central pattern library?