Overview
OneView DPS is a mobile application used by nephrologists to manage kidney disease patients. As the product scaled, UI inconsistency and improper component usage increased, creating rework, defects, and ongoing file maintenance overhead. I led an effort to evolve the existing component library and establish clear, cross-platform standards, reducing UI defects and freeing design and development time to focus on new features.
My Role
Designer
Tools
Sketch
InVision
Timeline
3 months (2022)
Problem
User Impact
The application's inconsistent UI and accessibility failures eroded user trust and satisfaction.
Frequently utilized components such as tabs and call-to-action buttons had inconsistent styling and failed accessibility standards due to low contrast ratios.
Several incorrect variations of tabs and buttons existed in the implementation.
Team Impact
Designers spent about half of their time recreating or fixing inconsistent components.
The design system excluded many components, which led designers to rely on copy-pasting elements. This required tedious, manual updates for each instance and diverted valuable time away from solving user problems, ultimately delaying feature releases.
Technical debt from incorrect UI implementation stifled product development by diverting resources to maintenance.
A lack of developer awareness and access to the design system meant each new feature introduced more component variations, creating a growing backlog of UI defects.
As shown in the left panel, most files did not utilize reusable components from the design system. This required tedious manual updates for each individual instance.
Approach
To address these issues, I led a 3-month initiative to audit, consolidate, enhance the existing design system, and implement the redesigned components. My focus was on reducing UI inconsistencies, eliminating the backlog of component-related enhancements, and creating a sustainable foundation for the team.
My Role
I led the design work independently. I facilitated brainstorming sessions with 2 other UX designers and several development stakeholders to gather their input. For the implementation of the enhanced components, I partnered with 1 iOS developer, 1 Android developer, and 2 QA analysts.
Goals
Reduce component-related enhancements: Reduce number of UI defect tickets from 2-3 per sprint to 0-1 by establishing clear UI standards.
Clear the existing backlog: Resolve 8 outstanding component enhancement requests.
Speed up design workflows: Reduce time spent on manual component updates.
Create shared understanding: Establish alignment across design, engineering, and QA on correct UI implementation.
Scope
My work focused on evolving the OneView DPS style guide and component library using Sketch and InVision, to prepare for future code alignment. Live code was out of scope given the timeline and resources available.
Process
Gather Input & Identify Pain Points
I began by facilitating two brainstorming sessions with key stakeholders to identify pain points with the existing design system and prioritize improvement opportunities.
Designers
I organized insights from the 2 other designers who use the design system, into a prioritization matrix. This helped identify high-impact, achievable improvements to tackle first, while planning more complex work for later phases.
Priority 1 (High Impact, Easy): Research design system best practices, document design principles, assess existing style guide.
Priority 2 (Medium Impact, Easy): Enhance style guide documentation, define structural components, research design kit possibilities.
The matrix guided my priorities, starting with research into design system best practices and an audit of the existing system.
Developers & QA
I then conducted a focus group with several mobile developers and QA analysts to learn how they currently used existing resources.
Critical issues: Developers and QA analysts were eyeballing designs rather than using accurate specs because they lacked InVision access and they reused the code for the incorrectly implemented components.
The session revealed that some developers and QA analysts lacked access to the design system and they did not know how to extract specs from it.
Build Foundational Knowledge
Following Priority 1 tasks, I began by studying industry design systems like IBM Carbon, Google Material Design, and Apple's Human Interface Guidelines alongside articles from Nielsen Norman Group to understand design system best practices.
Key Takeaways
Effective systems require both reusable components and comprehensive documentation that explains when and how to use them.
The system should live in a centralized and easy to navigate location.
Gaining support for the system is a continuous process. It's important to provide updates and maintain visibility to keep stakeholders invested.
Audit the Design System and Implementation
Over one week, I audited the design system and the application, documenting component variations, color inconsistencies, spacing issues, and typography problems.
Design System Issues
The library contained outdated components, lacked loading and error states, was not properly linked to design files, and provided little to no guidance on proper usage.
The library did not yet encompass all OneView DPS UI elements.
Details such errors, loading, and empty states were missing.
Implementation Issues
During the audit, I found 15 call-to-action button instances with inconsistent styling and accessibility failures. Tabs had up to 6 variations. There was inconsistent spacing, fonts, and iconography throughout both applications.
CTA buttons and tabs had the most variation across the app. Many instances failed contrast accessibility.
Design & Document the System
I rebuilt the component library in Sketch, starting with high-priority elements: buttons, tabs, patient banners, and typography. I prioritized frequently used, broken components and foundation elements based on the initial impact assessment.
Standards were based on accessibility requirements (WCAG), usability heuristics, team input, and industry practices. For example, I maintained 4 button states (enabled, active, loading, disabled) to provide clear system feedback. I included comprehensive documentation such as component definitions, usage guidelines, platform specifications, and implementation examples.
I enhanced the component library and style guide by including various states, adding usage guidelines, and meeting accessibility requirements.
Launch & Drive Adoption
Upon launch, I presented the updated system to the full OneView DPS product team and led hands-on training to drive adoption. This included how to use the component library, reference documentation, and access developer specs.
After launch, I reinforced adoption through regular designer check-ins, clear ownership documentation (copy, legal, marketing), and by positioning the system as the single source of truth in team forums.
Addressing UI Defects
I partnered with development to implement component improvements, clearing 8 UI defect tickets and producing reusable, accessibility-compliant code.
Solution
I re-designed and launched a design system that standardized 63 UI components across iOS and Android. The system established a shared foundation for consistency, accessibility, and platform standards. A living style guide in InVision helped support consistent use as the product evolved.
Foundations
Color and typography were standardized to support consistency and scalability. I included accessibility considerations such as color contrast and text sizing.
The Foundations section contained color and typography details.
Components
The component library covered core UI patterns, was organized alphabetically, and clearly labeled by platform (iOS and Android) within a single library for easier access. iOS components followed Apple Human Interface Guidelines and Android components aligned with Material Design.
Detailed Guidelines
I provided clear guidance on how and when to use each component. Platform-specific specs and implementation examples reduced ambiguity during hand-off and kept designers and developers aligned.
Platform Specific Details
I documented Android and iOS styling differences to enable accurate, consistent cross-platform implementation.
System Feedback
I established a single source of truth for errors, loading states, and haptics, standardizing system feedback to improve clarity, predictability, and trust across the app.
Errors
Loading States
Haptics
Impact
The design system delivered measurable improvements within 3 months of launch:
Standardized 63 components across iOS and Android & consolidating buttons from 15 variations to 4 states and tabs from 4 variations to 1.
UI defects dropped from 3 to 0-1 per sprint, reducing QA burden and allowing focus on functional testing rather than visual inconsistencies.
Cleared backlog of 8 component enhancements that had accumulated over time, allowing the team to focus on new features.
100% designer adoption, with new hires onboarding directly into the standardized system.
Made accessibility the default by embedding WCAG standards directly into reusable components, ensuring consistent, compliant interactions
Developers gained accuracy and efficiency through exact specifications, eliminating guesswork.
"The style guide helped me understand the correct styling. Before, I'd re-build the components from scratch and guess the hex color. Now I have the accurate values."
— Android Developer
Reflection
Meeting People Where They Are Drives Adoption
Some developers were accustomed to their own workflows and initially overlooked the style guide. Introducing new systems requires persistent communication and demonstrating value in stakeholder terms. Sustainable change comes from meeting people where they are, not just presenting a better solution.
Design Systems Need Evolution Plans
My focus was solving the immediate problem by cleaning up files and providing visual references. In retrospect, I'd outline a roadmap for live coded components from the start. As we hired developers, reusable code would have accelerated onboarding significantly. Design systems are living products requiring governance and long-term thinking.