athena healthIMPROVING FOUNDATIONAL QUALITY OF A PRODUCT
Athenahealth –Design System
Role: Design Lead
Company: AthenaHealth Inc
01 Context
Athenahealth’s mission is to unburden the practitioners that take care of all of us. Doctors, nurses, administrators, and others in healthcare are overwhelmed by day-to-day tasks such as documentation, scheduling, and collecting insurance and bills. Athena’s cloud-based solutions promise a bright future for healthcare, connecting 100,000 providers with 100 million patients.
02 Problem
With such a large platform serving so many disciplines, how do you maintain consistency in design patterns and ensure best practices are implemented? How do you avoid duplicative work and help teams work efficiently?
A Design System.
03 Approach
When we started creating Forge, we had two underlying goals: to create something useful enough that teams would be excited to adopt it, and to ensure that every designer and developer at Athena would feel like they owned a piece and could contribute to Forge.
We took a blended approach to achieve these goals. We created a lot of well-thought-out design and code elements, but we also piloted or collaborated with teams to help them build what was on their current roadmap. This approach helped us build trust across many teams and reduced the cost of moving to a new system.
Design Audit & Workshop
We assembled a small group of product designers who worked on different areas of Athenanet to conduct an audit. We analyzed screenshots of the existing interface, with two main objectives. First, we identified the common patterns used throughout Athenanet. Second, we cataloged instances where those patterns were being used differently.
Next, we asked this team to redesign key screens of Athenanet's interface. We used these redesigns to inform the building blocks for the design system.
The Baseline System: Tokens and Components
There are a limited number of HTML-based elements. Since our product was web-based, we primarily focused on these elements to create a baseline set of components. In addition, we established a token set (colors, typography, icons, etc.) that these components could draw from simplifying the decision-making process for designers and engineers in their daily work. This reduces the use of random values and bespoke elements, which can make maintaining a product more challenging.
Documentation
No system is complete without documentation. Its users need guidelines to understand the intent behind the system and all its intricacies. Only then could they use it effectively. Good documentation includes guiding principles as well as detailed information on when and how to use components, and ways to implement them.
Guiding Principles
Simple & Concise
Healthcare professionals have complex and busy jobs. We can help by decluttering their workspace. Be consistent, remove what is unnecessary. Be a minimalist.
Relevant & Helpful
We provide information in meaningful, digestible chunks.
Put expertise at their fingertips (a hover or click away). Just enough, and not all at once.
Approachable & Inclusive
Athenanet users work hard to provide care for us. We can care for them by using accessibility best practices. Speak to them directly; dial back technical talk and software terminology. Be warm, be respectful, and be clear.
Adoption & Contribution
Getting buy-in on a new design system can be the trickiest part, as it requires teams to work differently. Depending on the size of your team, you need to be flexible and take on different roles. In this case, we included designers, engineers, and product managers at every possible step to enlist champions who would support the use of the system.
We started with a centralized model: The Design System Team created guidelines and components and shared them with other teams, supporting colleagues as they adopted the new system. The goal was to evolve to a federated model where members from each team championed the design system. They could identify elements they were developing that would be suitable to refine and make available to all the other teams.
Establishing a system and moving it through different contribution models requires relationship-building. It also means continually reinforcing value to leadership and other stakeholders.
A design system is not a project, but a product just like any other. It is constantly evolving and requires design, research, engineering, and product resources. A good design system can enable an organization to make better products, faster. It can also bridge the gap between brand/marketing and product, a traditionally difficult chasm to cross.
04 Impact
We created a shared language for Design, Development, and Product of 250 agile scrum teams and a design team of 90+
All teams now could work from a single source of truth. Communication improved. And we increased overall velocity by using components that had design and dev parity.
