About Acumen Rounder
Interwell Health is the parent company responsible for the Acumen Rounder product and it’s other related offerings. Specifically, the Acumen Rounder application allows kidney care providers to make their “rounds” digitally while caring for patients and for healthcare staff to attribute the correct billing codes to patients’ healthcare treatments. Rounder connects with the well known healthcare documentation platform “Epic” to achieve accurate patient information that is available throughout the kidney dialysis healthcare system. Rounder is available both as a desktop web platform, and as an iPad and iPhone app, with Android planned as a fast follow.
The Ask
A former colleague of mine that knew of my love for organization and interest in design systems reached out to me to ask if I was interested in helping him create a design system for the Acumen Rounder product in Figma. He stated that he was the lead designer for a team of developers and QA analysts, and did not have the bandwidth to dedicate to making a functional design system while also handling the consistent UX work that was needed on the product. He offered me the ability to make this design system on a 6 month contract and do whatever I felt was best practice. I was very excited to make a design system from scratch on an already built UI, so I said yes and hit the ground running.
The Method
As I got up to speed, I found a few issues we’d need to address in this design system:
Font, color, icons, and foundational component styles were disorganized and not documented
We would need to transition from Open Sans to the Inter font family
Web and Native mobile were sharing styles from using .NETMaui as it’s tech stack and Android would inherit what was generated for iOS, so we’d need to document any differences
A screenshot of the audit document I created in Excel, showing the text styles used in the application
Now knowing the big problems I needed to solve, I started getting organized. I started my approach with an initial audit of the existing font, icon, and color styles in the web version of the application, using the web inspector tool and asking my front end developer pal for an export of what’s being used in the front end. Web was the first on the radar because it was the most finalized version of the UI and also easiest to audit. I threw a list together in Excel and started comparing prod with the figma design styles, documented them with a sample screenshot, the name of the style, and the token name. I paired down the redundant styles and deleted any unused styles to create the beginning of what I called the “Foundations” portion of the design system: The building blocks of the entire system!
On the left: The colors used in the UI being paired down to reduce redundancies and then included in the finalized Color documentation page (on right)
A look at the organization of components: The list of the component names, a link to where they were housed in the workspace file, and it’s completion status
The next phase was creating a system for organizing the system itself and for naming components. I started with my list of styles from the previous step and worked with the lead designer to make names that made sense for his usage. We also referenced many other design systems from other companies (Goldman Sachs, IBM, and UI Kit just to name a few) to draw inspiration for organizing the pages of the system, building components, and grouping them into logical categories. From here we created the full library of web components, grouped into pages in Figma based on naming conventions and usage logic. Every component required variants, used variables, required Auto Layout and boolean properties (which really grew my knowledge and abilities in Figma) all so that the components could be used in their various needed states and statuses. This required many hours of tweaking and creating sub-components which were also properly documented and hooked into the system.
A look at the “Dropdowns and Combo boxes” page. This housed all the same components, displayed all their possible states, and even included helpful documentation on the left on how to configure the component in the Figma inspector.
After the web portion was complete, we moved into native mobile components. iOS was made first—using a similar approach of audit, organize, then document— and was very influenced by the web styes, but still required it’s own documentation and components. Android was mostly adopting the styles from iOS thanks to .NETMaui, but labels were made in the native mobile library to distinguish any differences between the platforms. Once the native mobile components were complete, the design system was done!
When the system was completed, we explored solutions for documenting and sharing the design system more wildly outside of Figma; Themebuilder, ZeroHeight, and Storybook. Themebuilder worked with the tech stack that we were working with, but required a lot of manual importing of styles and components, despite Figma integration, and the other tools we were not able to fully explore due to needing some developer bandwith to implement. We ended up putting the basic styles in Themebuilder and leaving the rest in a future story for a developer or two to investigate as the best solution for them.
The Result
After creating the components and buttoning up the last of the system, I was able to publish and share the library with the team. My lead designer was able to start working with them immediately and replace outdated, one-off components in his mockups, and iterate faster than ever before. In several instances, he was able to put multiple versions of a new screen design in front of providers (the user base) and get their feedback while toggling properties on the components used in the UI to give them a better understanding of interaction patterns. My design lead and developers were very pleased to have this shared documentation to reference to reduce confusion and create more consistency in all platforms.
You can explore the final design system through the Figma embed here on this page, and if you have questions, feel free to send them my way!
The improved device preview images for the app store, made in collaboration with the lead designer.
Since I was able to finish on time, I was also able to assist with some other projects including making new screen mockups to create promotional images on the Apple App Store for iPad and iPhone, as well as make some new graphical illustrations to use in the UI based on others already documented in the system.
I had a wonderful experience working with the lean, but very mighty, Rounder team. I enjoyed creating something that would bring them more clarity and improve their design workflow. If you aren’t convinced that a design system would benefit your team, let this case study be the first to change your mind!
The iterations of making a “No Records Found” graphic. Reference graphic in the top left, versions I explored below that, and the finalized, approved version on the far right.
The finalized ‘No Records Found’ graphic in its usage context.