Started With Features, Ended With a System Fix
The Octave MS Care app and program helps people with multiple sclerosis manage their treatment and connect with care teams.
I was brought in to design and test new features for the patient experience, but early on, it became clear the foundation needed work. The design system was inconsistent, difficult to scale, and not meeting accessibility standards. This was especially critical since low vision and color blindness are common symptoms of MS.
I rolled up my sleeves, ran a full audit and worked with engineers to fix color, components, and functionality. With product, I showed how a stronger system made features easier to ship. With leadership, I made the case that accessibility and scalability were investments in better care and faster product growth.
Together we shipped a refreshed design with new patient features, while building a more inclusive system and a stronger foundation for the product to grow. The work went on to be recognized by Fast Company’s Innovation by Design Awards and the UX Design Awards.
How I Tackled It
Started with an honest audit
I mapped the current UI across screens, workflows, and navigation patterns. I looked for anything that felt clunky, inconsistent, or inaccessible. From color contrast issues to duplicate components, it quickly became clear the system needed cleanup before we could confidently build on it.
Designed with flexibility in mind
I followed atomic design principles to build modular components that could be reused and rearranged across different parts of the product. The goal was to create a system that could scale and adapt.
Made documentation part of the work
Along the way, I built a guide that captured specs, usage rules, and accessibility notes. It became a go-to resource for both design and engineering. It helped keep everyone aligned and cut down on back-and-forth during implementation.
Worked in the open with the team
This was never solo work. I partnered closely with PMs, engineers, and other designers to shape the direction and prioritize updates. Some of the most useful conversations came from digging into accessibility edge cases with engineers. We debated how to handle color in data visualizations for low-vision users. Those discussions helped us land on stronger patterns and a more thoughtful system overall.
Creating a System People Could Use
So I built what I wish had existed from day one. A clear, centralized system that laid out the foundation. The goal wasn’t just consistency. It was to give every designer and engineer a shared language to build from, no matter the feature or use case.
I pulled everything into a single source of truth. Colors, type, components, and patterns were all documented in one place with clear examples. Not just what to use, but when and how to use it.
Because the app had so many different use cases we created flexible rules that could work across the board. The documentation became a key part of how we worked. It helped designers move faster and gave engineers fewer unknowns to solve.
