Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata


Purpose of This Page: Compare a number of Design Systems and see how well they meet a number of criteria.

Why We're Doing ThisA shared, clear Design System will help us have consistency among contributors w.r.t. how things should look. We don't want to spend precious technical time deciding details of how widgets should look and behave - we want to focus on the clinical use/workflows for those concepts, and allow another community to worry about the rest of the details. 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. And, it’s much better to figure out our design framework and styling sooner rather than later. We don’t have the resources to build/maintain our own design system. Group consensus is a 3rd party Design System makes the most sense in our case. More OMRS context here; and an Overview of Design Systems here.

  • Goal: High-level recommendation for UX contractor by when they start on August 18, to then hear their feedback.

Style Guides vs Design Systems

Style Guide: The visual guide to how things should look and behave. The world we ground our design decisions in.

Design System: The Style Guide linked to code you'll use in your actual code base - the how.

Design Systems for Analysis

  1. Twitter's Bootstrap - (Priority due to ease of use and community history)
  2. IBM's Carbon - (Priority due to documentation & UX consultant recommendation)
  3. Google's Material - (Priority due to prevalence of Material UI in the daily lives of our users, and because already being used by OCL for OpenMRS)
  4. Salesforce's Lightning Design System - (If time)
  5. Atlassian's ADG - (If time)

Summary of Analysis

Overall Grade

Noteable StrengthsFamiliar to many devs

Very strong/clear web documentation on how things should be done

Familiar UI for many users

Comprehensive UI.

SalesForce software is quite similar to an EMR. Target users are professionals, use data tables, need data input/forms and display trends etc... So we can feel safe  that all tools are there.

Noteable Weaknesses or Differences

Are all necessary components already there?

(relative to Base Set of Components)

Missing core data table support (may be options via plugins)

No header

No card view

Missing core data table supportYes.

Is the default style acceptable?

(Can be adjusted with minimum effort; friendly for end users/used to what end-users see in their daily lives; responsiveness)

Mobile-first. Doesn't perform well on desktops. 

Is it framework agnostic?

(Usable without framework lock-in)


Not coupled to any frameworks

Is it easily configurable?

(Can style easily for RefApp or whatever org/branding you want to have; how it can be customized; how it works (out of the box vs. possibilities, e.g., could we have CSS variables that would allow runtime configuration)

Implementation considerations

  • Stability of API
  • Documentation


Already used by ___

Documentation harder to use

User Interviews: Community Developers

User Interviews: Implementation Leads

User Interviews: End Users

Base Set of Components

Compare systems' available components with a list of components we rely on.

CriteriaOMRS Style GuideESM Style GuideBootstrapCarbonMaterialLightningADG

Headers/ Text






Buttons in general

Confirm/ Save buttons




I can't find any card components.

Collapse/ Accordions/ Expanders





Navigation: General

Navigation: Menus


Navigation: Rails

Navigation: Tabs

Navigation: Progress bars



Form: String Field

Form: Field Units

Form: Text Field (Longer)

Form: Validation

Form: Helper Text

Form: Date Picker

Form: Radio Button

Form: Dropdown

Form: Checkbox

Form: Toggle Buttons

Form: Sliders

Graphs or Charts


Deeper Analysis Notes

Twitter's Bootstrap

Google's Material

IBM's Carbon

Salesforce's Lightning Design System

Atlassian's ADG

  • No labels

1 Comment

  1. I'm in favor of adopting a design system where developers can focus their efforts on weaving components together for needed application functionality instead of building or maintaining the widgets themselves. OpenMRS needs to run well on all major browsers & platforms and building/styling/maintaining UI elements that do this well is a lot of work, so the number of UI components we manage should be limited to a small set of special cases where it's absolutely necessary. To this end, I'd favor any approach that allows other communities (not OpenMRS) to worry about rendering details & supporting/maintaining robust browser/platform compatibility and let our devs focus on applying those elements to improving healthcare worldwide.