LPT Design System – Mehak Qureshi Portfolio

Design System

Overview

LPT Realty was scaling fast — new agents onboarding, new products launching, new teams working in parallel. The design system they had wasn’t built to scale with them. Components were inconsistent across products, documentation was either missing or out of date, and the development team was spending significant time recreating elements that should have already existed.

I was brought in to restructure the system from the ground up — establishing token foundations, rebuilding brittle components into cascading ones, creating contribution standards, and building documentation that the whole team could actually use.

Problem

As the product grew, teams faced increasing challenges:

Inconsistent UI patterns across features and teams
Duplicate design and development efforts
Lack of shared standards and documentation
Slower product delivery due to fragmented workflows

Organizational Impact

Designers spent time recreating similar components
Engineers reimplemented inconsistent UI patterns
Product teams experienced delays in shipping features

Key Insight

The problem was not just inconsistency—it was a lack of a shared system to scale design and development efficiently.

Designers

Needed reusable, consistent components
Required clear guidelines for building new features

Product Teams

Needed faster delivery and scalable solutions
Required consistency across the product experience

Engineers

Needed predictable, standardized UI components
Required alignment between design and implementation

Solution

I helped design and implement a scalable design system that:

Standardizes UI patterns across the product
Aligns design and engineering through shared components
Establishes governance for long-term scalability
Improves speed, consistency, and collaboration

System Architecture

This project focused on building and scaling a design system for a complex data-driven platform, enabling consistent user experiences and faster product development across teams. The goal was not just to create reusable components, but to establish a scalable system that aligns design, engineering, and product teams.

1. Design Tokens

Defined foundational elements such as:

Color system
Typography
Spacing and layout rules

Purpose:
Ensure consistency across all components and screens

2. Component Library

Built reusable components including:

Forms and inputs
Data visualization elements
Navigation patterns
Interactive components (e.g., accordions, modals)

Each component included:

Variants and states
Accessibility considerations
Usage guidelines

Purpose:
Enable rapid, consistent design and development

5. Design + Engineering Collaboration

To ensure alignment between design and development:

Integrated components with Storybook
Worked closely with engineers to ensure accurate implementation
Established shared standards between design and code

Impact:

Reduced handoff friction
Improved implementation accuracy
Increased efficiency across teams

3. Patterns and Layouts

Defined patterns for:

Dashboard structures
Data-heavy interfaces
User workflows

Purpose:

Ensure consistency at the system level, not just component level
Governance &
Contribution Model
One of the most critical aspects of the system was governance

4. Key Initiatives:

Established design critique sessions for system contributions
Defined contribution guidelines for new components
Introduced shared ownership across teams
Enabled Figma branching and version control

Impact:

Reduced duplication of components
Improved consistency across teams
Created a sustainable system that evolves over time.

System Architecture

The previous system’s components were brittle because they were built on hardcoded values. Changing a brand color meant finding and updating it in dozens of places. Spacing adjustments broke layouts unpredictably.

I restructured the foundation using a three-tier token system. Primitive tokens held raw values — hex codes, spacing numbers, type sizes. Semantic tokens named those values by purpose: color/action/primary, color/feedback/error, spacing/component/padding. Component tokens referenced semantic tokens and never primitives directly.

This meant that when LPT Realty needed to update brand colors, the change cascaded automatically from one place rather than requiring manual updates across every component. It also made the system dramatically easier to extend — new components inherited the right values by default rather than requiring manual alignment.

In Figma, this was implemented as Variable Collections with aliases connecting the tiers, enabling the cascade and making future brand updates a configuration change rather than a rebuild.

Governance Model

The most important decision I made early on wasn’t about components — it was about process. A design system without governance becomes a component graveyard. I established three practices that kept the system alive and trusted.

Critique and Review

I updated our design template to include a dedicated space for any component variations or additions. Designers brought proposed changes to design critique before they were merged, and engineers had early visibility to provide feasibility feedback. This kept component creep low and decisions intentional — we were forced to justify every addition rather than defaulting to “let’s just add a variant.”

Contribution Standards via Figma Branches

I used Figma’s branching capability to create a governed contribution model. Any designer could propose a new component or variation in a branch. Changes were only merged into the main library after passing a structured review: anatomy, accessibility, token usage, and documentation. This kept the system open without creating chaos — designers were unblocked, but the library stayed trustworthy.

Accessible Documentation

While engineering updated Storybook, I built a Figma prototype that served as living documentation — navigable, searchable, and embedded directly in the tool designers were already using. Every component included usage guidelines, constraints, and contribution notes. No one had to leave Figma to understand how to use the system correctly.

Impact

The restructured system had measurable effects on how the team worked. Development cycles shortened because components no longer needed to be recreated from scratch for each new product feature. The contribution model reduced rogue component creation — designers had a clear path to get new patterns into the system rather than working around it.  

The documentation prototype became the team’s primary reference during onboarding of new designers and during handoff to engineering. Previously those conversations happened in Slack threads and were lost. With the Figma documentation prototype, decisions were recorded, searchable, and version-controlled.