Design System at Lenford Homes.
Building for consistency and speed.
SUMMARY
Lenford Homes was modernizing and consolidating its internal applications into a single platform. With over 300 internal tools and multiple teams designing independently, the company lacked a consistent visual and interaction language. This project focused on creating a scalable design system to standardize UI, accelerate delivery, and improve usability across products.
TEAM
4 Designers
2 Developers
1 Design Head
1 Technology Lead
CLIENT
US-Based Home Building and Buying Company
(Fortune 500, NDA)
TIMELINE
13-14 Weeks
Sprint Format
MY ROLE
Leading design execution within a cross-company team.
Lead designer from the contracting team
Owned key foundations and core components
Defined documentation standards
Collaborated with client design leadership
Partnered with developers for future implementation
CONTEXT
The absence of a unified design language led to reinvention, inefficiency, and inconsistent employee experiences.
▶
Fragmented UI Patterns
Over 100 internal applications had different
layouts, interactions, and visual styles
▶
Inconsistent brand experience
Lenford’s brand was diluted as each tool looked
and felt disconnected from the others
▶
No shared design OR development foundation
Designers and developers had no single source
of truth for UI patterns, branding, or behavior
▶
Slow and inefficient delivery
Teams spent time reinventing components
and hunting for guidelines instead of building
▶
Poor employee experience
Lenford Home employees had to constantly relearn
interfaces when switching between applications
KEY USERS
Our focus was to give designers and developers a single source of truth.
UX DESIGNER
Contract designers from various agencies collaborating to design Lenford's applications
FRONT END DEVELOPER
In-house and contract developers responsible for coding Lenford’s applications
OUR GOAL
To create speed, consistency and a shared language.
▶
SHIP FAST
Build a usable design system within a tight, real-world timeline using design sprints and phases
▶
ALIGN TEAMS
Establish a single source of truth for designers, developers and business stakeholders
▶
PLAN FOR LONGEVITY
Define governance and maintenance models to keep the system scalable over time
▶
DESIGN FROM REALITY
Base components on actual application needs, not assumptions
▶
ENABLE RESUSE AT SCALE
Support multiple product teams and internal tools with shared components
▶
ENSURE ACCESS AND ADOPTION
Make the system discoverable and usable through an internal website
SPRINT PLAN
We worked in 2-week sprints that balanced quality with speed.
DISCOVERY
The design system was grounded in real workflows, not assumptions.
▶
UI AUDIT
Reviewed 7 ongoing & pipeline internal applications
▶
PATTERN MINING
Identified the most common components and flows
▶
GAP ANALYSIS
Flagged inconsistencies and usability issues
▶
SCOPE DEFINITION
Prioritised components to include in the first phase
The design system
Foundations
The design system
Components
ANATOMY
TYPES
INTERACTION STATES
SIZES
LAYOUT
USAGE GUIDELINES
COMPONENT LIBRARY
THE WEBSITE
Hosting the design system on the company intranet
DOWNSIDES & REFLEECTIONS
Speed enabled delivery, but limited validation and flexibility
▶
Speed enabled delivery, but limited validation and flexibility
Components were built and documented rapidly, with limited real-world testing across applications before expansion.
▶
Early decisions became rigid
As the system grew quickly, foundational choices (tokens, structures, naming) became harder to evolve.
▶
Parallel execution reduced depth
Dividing ownership improved speed, but limited collective critique and cross-component cohesion
▶
Sprint-driven approach vs system thinking
The sprint model prioritized output, while design systems require slower iteration, validation, and architectural alignment