Hi everyone!
I’d like to start a thread to discuss an idea that I have for maintaining consistent UIs throughout future feature development within OpenEMR. In this post, I will propose the ideas for a Design System and outline the steps I will be taking to document the “current state” of the OpenEMR UI and how we might be able to incorporate a cohesive set of UI components and interactions into this year’s OpenEMR Project Core Roadmap - #7 by vlorenzi .
The problem
As a designer who’d like to contribute ideas on how new features can fit into OpenEMR, I find myself not knowing exactly what types of components are used throughout the site. In my recent work on Units Support - #27 by MatthewVita I spent some time going through the Patient Flow board and intake procedures that currently exist within the platform. What I found was modals that did not look like each other, buttons that did the opposite of what I expected and disconnected UIs that were difficult to string together within a single workflow.
This is expected, given the way that open source software is developed, that features do not necessarily fit together all “neat and tidy”. Since each feature contributor(s) has their own set of goals and method of implementing any particular interaction, some workflows may utilize a “radio button” where others might end up using a “dropdown” (for example).
Without a consistent method of implementing a certain user interaction, however, users are left with a less-usable experience and the risk that future features may end up copying the same patterns that lead to user error. In addition developers who may not care about the “front end” end up getting stuck on choosing the right interaction instead of spending their time on the parts they’d rather work on.
The pattern
One way to combat this problem is to develop a “Design System”:
A design system is a collection of documentation on principles and best practices, that helps guide a team to build digital products. They are often embodied in UI libraries and pattern libraries, but can extend to include guides on other areas such as ‘Voice and Tone’.
Quote from: GitHub - alexpate/awesome-design-systems: 💅🏻 ⚒ A collection of awesome design systems
Similar to a code style guide, a project’s design system can provide the basis for collaborative development by establishing a set of patterns that designers, developers and users can point to and say “that’s the way we do X”.
The best way to bring this to life within a community as vibrant and long-running as this one would be for someone to jump into the existing platform and catalog all of the UI/UX patterns that currently exist. I was thinking I could do this in a google doc and get others to contribute their own screenshots of interface elements to create an “interface inventory” - an introspective document that allows for (the community / those who care) to comment on what is “the best way” to:
- Display a patient to user
- Allow the user to check a person in
- Edit global admin settings
… etc.
Most applications end up with a lot of different ways of doing the same thing… here’s an example from a “major bank website”:
The goal of this process is to “Lay the groundwork to a sound interface design system”:
the interface inventory is an important first step for setting up a comprehensive pattern library. It’s essential to capture all existing UI patterns to determine which patterns will make the final cut in the living design system. The interface audit exercise also helps teams establish a shared vocabulary, which will be crucial for the success of the eventual design system.
Quote from: The Atomic Workflow | Atomic Design by Brad Frost
How you can help
If you’re working on the Bootstrap Standard - #66 by sjpadgett project, please let me know how I can check out the current stage of your work and follow your progress. I have read through the themes readme and don’t quite have a feel for what’s changed and will have changed by the end of the bootstrap reskin.
I think this work can run in parallel to the re-theming of OpenEMR with bootstrap so if others who aren’t involved in that effort want to contribute to this conversation, please do chime in here! The purpose of this effort is not to tie the Design of the platform to any particular technology, but rather understand how we present the system to its users…
Once we’ve analyzed the patterns that make up the OpenEMR interface, it will be straightforward to decide what elements, components, or workflows need to change to meet user’s expectations of a consistent and usable electronic health records system.
