Design System for EHR
- Industry: health care.
- Product type: Design System for Electronic Health Record System (EHR).
- Duration: 6 months.
- Tools: Sketch, Zeplin, Confluence.
Project manager, 3 designers, 2 developers.
Our team has been working on the EHR system (see the case here) for almost 2 years.
We received a request to create an interface for telemedicine products, which will be integrated with the EHR system but still will be an independent product.
A design system is a collection of shared design patterns, practices, and interactions that allow our team to build quality consistent interfaces. Design systems function as an ever-evolving central source of truth. They instill order, enable consistency, and improve efficiency. As of recent years, they are becoming the rule rather than the exception.
This wave of popularity explains why 69% of designers surveyed in the 2017–2018 Enterprise UX Industry Report said that they either already had a design system or were currently planning on building one.
We have always to keep the Design System actual. We work on the Design System as long as we work on the product. Because in the process of product creation we always create new patterns. After the product is launch — the system is done. And we can improve the Design System while we improve the product. And have a new version, as we have new versions of the product.
It takes time and money to create and support the system.
But on the other hand, the Design System saves a lot of hours in the future.
Make research and just do it.
Confluence for all
Sketch library for designers
Zeplin library for developers
Let’s stay on the basics:
How does it look?
How does it work?
Where it is?
Let’s keep entities versions
🖼 See the picture
After four months we have started to understand what we are actually doing.
So the next question was HOW we are actually doing?
So we conducted the research.
We believe, that developers and designers have a need to learn the Design System before they start working with it. We can resolve it with DS on-boarding.
We believe, that developers and designers use Zeplin only.
We can resolve it by adding an entity description to Zeplin.
We believe, that developers and designers don’t use Confluence to work with the system. We can resolve it by moving the system to a platform where the description and code are stored together.
We believe, that it’s difficult for developers and designers to navigate the system entities. We can resolve it by creating a system map.
We created a system that helped a huge product. The product is 16 years old. During this time, it was created and improved by various experts.
Thus, the product was extremely inconsistent and not user friendly.
A design system became a collection of shared design patterns, practices, and interactions that allow our team to build quality consistent interfaces.