Table of Contents
"Design systems define a collection of design patterns, component libraries and good design and engineering practices that ensure consistency in the development of digital products. We've found design systems a useful addition to our toolbox when working across teams and disciplines in product development, because they allow teams to focus on more strategic challenges around the product itself without the need to reinvent the wheel every time they need to add a visual component." |
Summary
A shared, clear Design System will help us have consistency among contributors w.r.t. how things should look. This is especially important given we don’t have dedicated long-term UX resources. We want it to be fast for devs to contribute meaningful work.
...
Users want a consistent, professional front-end UI. | A shared, clear Design System will help us have consistency among contributors w.r.t. how things should look. This is especially important given we don’t have dedicated long-term UX resources. |
We want it to be easy for new volunteers to contribute meaningfully. | We want it to be fast for devs to contribute meaningful work. An OpenMRS-specific style guide increases the learning curve. Of course, there is a learning curve when using a 3rd party resource as well, but the flip side is that this gives the developer experience using a much more widely-used Style Guide. Knowledge of that particlar style guide, or how to navigate mature style guides in general, may help the contributor later in their career. |
We have limited Design Resources - and the designers that become available, we want to use very efficiently. | We don’t have the resources to build/maintain our own design system. There are not enough skills, resources and knowledge within to build, maintain an internal style guide, and its better to leverage work and investments done by others in the industry. Requiring designers to start from scratch or maintain/change our own custom Style Guide(s) constrains the ability for implementors to leverage non-OpenMRS UI designers and contractors to extend and implement UIs, and places extra burden on implementors to learn the OpenMRS way. While having our own style guide is very attractive to move fast, it becomes a weight that slows down advancement in the future. |
Cost of maintenance | Building our own style guide may not seem like a big task (in fact a lightweight one can take a few people a few weeks), but building and then maintaining a full-fledged design system is a much bigger task. Our experience with the ESM style guide (discussed more below) shows that the maintenance didn't really happen in a concerted way for a light-weight style guide, but more importantly, it wasn't enough to solve the core problems of the how something should be implemented. This then required many more conversations and costly re-work of engineering efforts. |
Engineering Concerns
As engineers, we’re centrally concerned about the API—how usable is it, how familiar is it. We’re secondarily concerned about other technical questions, like maintainability and weight. With an independent style guide, all the technical and API questions are mooted. The only meaningful difference between 3rd party libraries to imitate becomes “how should it look.” In that case, if the designer says they like a particular look (ie Carbon), I’m happy to follow that. But if we don’t keep an independent style guide, then all of the devs’ concerns about API etc become very important, and we should choose according to the prevailing preference on those grounds, which is Bootstrap.
...