.png)
LendInvest Design System
Building and maintaining a new design system for use across all design and development projects to drive consistency and efficiency across the brand.
My Role(s):
Design System Designer, Hybrid Product designer/Product Manager
Responsibilities:
Strategising with stakeholders | Collaboration with Designers, Product Managers and Developers | User research including interviews, understanding the problem and gathering insights | Component auditing | Design system management, contribution and upkeep | Component design and documentation | Design QA | Design system governance
🙍🏻♂️ Business problem
A slow product delivery to market
LendInvest operated with an immature design system, often treated as a side project, leading to UI inconsistencies, development inefficiencies, and slower product delivery. The team faced implementation issues and higher development costs due to incorrect code for common UI elements. This hindered product scaling, caused user experience disparities, and forced designers to create UI elements from scratch, slowing down the design process and introducing misaligned component properties.
🤷🏻♂ User problem
Mixed levels of understanding and adoption
Mixed understanding of the design system caused significant issues. Designers needed frequent reminders to use the correct components, and developers were unsure when and how to implement them, causing disparities and affecting JIRA ticket delivery. Developers had to build components from scratch in an unfamiliar language (LWC), and designers faced uncertainty due to legacy components. Figma updates outpaced Storybook builds, leading to outdated components and no single source of truth, contributing to low adoption of the design system.
⛹🏻♂️️ Team problem
Unfamiliarity with utilising a design system
Platform development was slowed by the need to manually build and update components, leading to inconsistencies and repeated design QA. Developers lacked familiarity with reusable components. As teams grew and personnel changed, it became clear that documentation was needed to explain each component's form and function. Education on design system benefits and improved communication were essential to address inconsistencies, issues, feedback, and workflows. Processes were needed to determine how and when components were updated.
⛹🏻♂️️ Team problem
Unfamiliarity with utilising a design system
Platform development was slowed by the need to manually build and update components, leading to inconsistencies and repeated design QA. Developers lacked familiarity with reusable components. As teams grew and personnel changed, it became clear that documentation was needed to explain each component's form and function. Education on design system benefits and improved communication were essential to address inconsistencies, issues, feedback, and workflows. Processes were needed to determine how and when components were updated.
🧠 Assumptions and hypotheses
Validating assumptions to drive team priorities
I aimed to use these hypotheses to drive the team's priorities and ensure the design system's success:
-
Unified design system: Reducing UI inconsistencies and improving user experience.
-
Comprehensive documentation: Increasing adoption rates among designers and developers.
-
Streamlined processes: Accelerating development time and reducing design QA needs.
By validating these hypotheses, I aimed to align our efforts with the most impactful areas for improvement.
🧐 Solving the problem
From side project to independent product
The Wiley Waving Whales team aimed to make the design system an independent product, requiring dedicated resources, autonomy, strategy sessions, stakeholder communication, and DesignOps. Workshops with designers and developers led to implementing well-documented components, streamlining updates, creating a roadmap for new and legacy components, conducting a component audit, and enhancing stakeholder communication.
🌍 Discovery work
Comprehensive discovery to inform problem areas
The discovery work for the design system involved several strategies to ensure its effectiveness. Stakeholder interviews aligned the system with business goals, and competitor analysis provided insights from industry leaders. A component audit identified inconsistencies, while usage analytics highlighted prioritisation patterns. Workshops and focus groups facilitated collaborative solutions, and an accessibility review ensured WCAG 2.1 compliance. A technical feasibility study assessed integration constraints, and research into emerging trends aimed to future-proof the system, keeping it adaptable to industry standards.
👷🏻♂️ Building a process
Deciding how to work as a new team
I conducted workshops with the team to understand their preferences, areas for improvement, and desired workflows. The team agreed on a thorough process covering:
-
Idea discussions and roadmap assessment
-
Ownership assignment and communication
-
Research, reviews, and proof of concepts
-
Detailed specs creation and scope locking
-
Code review and QA
-
Component release with notes and onboarding
-
Testing and performance evaluation
-
Roadmap evaluation for post-MVP features
📜 Let the documentation begin
Twenty components documented and launched
Documentation was pivotal in evolving the design system into a robust product. Collaborating with designers and developers, I authored comprehensive documentation for each component, detailing styling, accessibility, dos and don'ts, usability guidelines, device and browser rules, and other considerations. Over five months, approximately twenty components were released or pending sign-off, with some undergoing subsequent iteration and updates.
🧪 Testing the design system
Enhancing user experiences, meeting WCAG standards
Components were crafted to enhance user experience with a focus on perceivability, operability, robustness, and understandability. Collaborating with individuals with visual impairments, we ensured our designs adhered to WCAG 2.1 guidelines. Testing included feedback from end users to verify contrast and text legibility met a minimum AA 4.5:1 score for small text and 3:1 for large text. Usability sessions assessed user acceptance, cross-browser and cross-device responsiveness, and keyboard navigation. User feedback validated the effectiveness of `aria` tags and alt text, ensuring the design system truly met users' needs.
🥳 We achieved some success
Teams achieved quicker product release cycles
Ultimately, the design system began meeting its goals. Educated designers and developers led to faster designs and improved build times. Reduced challenges in usage enabled faster product releases with less need for design QA. Onboarding of new team members was expedited, and the new process facilitated seamless transitions between tickets. Developers gained skills, a single source of truth was established, and disparities between designs and builds decreased. Additionally, I developed new skills in a Product Manager role.
😤 Challenges along the way
Despite best efforts, adoption remained low
This project faced challenges as stakeholders remained sceptical of dedicating time to the design system, and adoption stayed low despite enhancements in documentation and processes. Misuse by some users undermined its purpose, and stakeholders occasionally prioritised speed over quality. Salesforce's Lightning Web Components (LWCs) imposed customisability constraints, resulting in compromises and quality variations, with details lost due to translation or LWC limitations. Engagement with the design system was not universal, and I had to balance time between previous projects and the design system.
