Channel Agent Memories enables AI agents in Teams channels to automatically learn team preferences and context from everyday conversations, then use those insights to deliver personalized, context-aware responses without manual setup.

Research & User Insights


## Understanding User Needs

We started by analyzing feedback from early Channel Agent users who reported frustration with repetitive instructions and generic responses. Through interviews with 12 teams actively using the agent, we identified a clear pattern: users wanted the agent to remember their preferences without having to repeat themselves, but they were skeptical about what it might store. This tension between convenience and control became our core design challenge.

### Research Activities

- I conducted a competitive analysis of memory systems in ChatGPT, Notion AI, Claude and others to understand industry patterns around visibility and user control.
- We also reviewed internal data showing that 68% of agent interactions involved repeated formatting requests, validating the need for preference memory. 
- Key insight: users tolerate AI memory when they can see exactly what's stored and easily correct mistakes. This directly informed our decision to prioritize visible, editable memory over a purely automated system.

      



| Vendor | Scope & model | Visibility | Controls | Privacy modes | Rollout stage | Notes |
|---|---|---|---|---|---|---|
| OpenAI | Saved memories, reference chat history, "memory updated" visual cue | Users can view / delete / clear all saved memories | User & admin toggles for saved memories and chat history | Temporary chat does not use / update memory | Saved memories: enterprise + consumer; Reference chat history: consumer only | If user expects memory, must save; To fully delete memory, user must delete saved memory and message(s) |
| Anthropic | Separate memory per project, reference chats related to the project, manual preferences/response instructions, memory summary | Users can view/edit | Granular user controls, admin org-wide disable | Incognito chats don't save to memory or history | Rolled out to Team/Enterprise (9/11/25); Broader API tooling (9/29/25) | Per-project compartmentalization keeps sensitive conversations contained; Focused on professional context & work patterns |
| Perplexity | Memory, search library (past QnA) | Users can view / delete | User settings for memories and search library | None | Available for consumer; Not available for enterprise / organization | Memories referred to as a source in responses; Claims to proactively reduce ability for memories on sensitive information |
| Meta AI | Memory in 1:1 agent chats (WhatsApp, Messenger), "memory updated" visual cue | Users can view / delete; if recently mentioned can still be referenced | None | Group chats | Available for consumer | |
| Google Gemini | Personal context, instructions | Users can delete past chats, view / edit / delete instructions | Users can turn off personal context | None | Not available for Google Workspace, Education, or in the EEA, Switzerland or UK | Gemini cites 'previous chats' in the sources |
| Notion AI | Agent identity, chat interaction preferences, memories | Users can view / edit / delete notes from 'My Notion AI' page | None | None | Available | Very user-led (requires explicit instructions) |
| Microsoft Copilot | Copilot memory, custom instructions, "memory updated" visual cue | Users can view/edit/delete memories | User & admin toggles at tenant level | None | GA targeting July 2025 | |

      

Testing & Results


## Validation & Impact

### Testing Process

- Tested memory visibility UI with 8 product teams using early prototypes in Figma, focusing on whether users could quickly understand what the agent remembered
- Conducted usability sessions on memory editing flows, measuring time to find, edit, and delete specific memories
- Validated the grouped memory structure (Source Context, Group Preferences) against flat list alternatives with 15 participants

### Results

- 85% of users successfully located and edited a memory within 30 seconds using the grouped modal approach
- Teams reported increased trust when they could see what the agent stored, with 11 out of 12 participants preferring visible memory over hidden automation
- The presentation framework helped secure stakeholder alignment across PM, engineering, and leadership, moving the project from concept to roadmap priority
      


## Project Overview

Channel Agent distinguishes between Knowledge (raw data like messages and files) and Memory (derived insights and patterns).
When team members share preferences across conversations, like Daniela requesting brevity and table formats on different days, the agent synthesizes these into actionable insights.

Our V0 focuses on two high-impact memory types: source context for better query routing, and group preferences for naturally aligned responses.

### The Challenge

Channel Agent Memories transforms how groups work together by automatically learning from team conversations in spaces like Teams channels. As your team communicates naturally, the agent picks up on preferences, context, and workflows without anyone having to set things up manually.

It then uses these insights to personalize responses, create better documents, and schedule meetings that respect how your team actually works. The key design challenge is making sure people can easily see and edit what the agent remembers, building trust through transparency. Unlike traditional memory systems built for individuals, this is designed from the ground up for teams, making collaboration feel genuinely adaptive and smart.



| Challenge Area | Description |
|---|---|
| Data Source Scope | Single vs. cross-source, access, retention, compliance |
| Memory Management | Automatic/manual updates, triggers, editability, deletion |
| Quality & Evaluation | Guardrails, relevance, metrics |
| Technical Integration | APIs, data models, orchestration, scalability |
| User Experience | UI for CRUD, collaboration, feedback, visibility |

We must consider how memory visibility, editability, and collaboration will impact user workflows and trust.
Engineers need to architect for compliance, scalability, and flexible retrieval.
Product Managers must balance immediate value (single-source, group preferences) with long-term extensibility (cross-source, personalization).

### My Role

I designed the user experience for Channel Agent Memories, focusing on how users see, edit, and manage what the agent learns. Working closely with PMs, I distilled dense technical documentation into clear stakeholder presentations that built buy-in across leadership. I collaborated with engineering to balance technical feasibility with user needs, designing interaction patterns that made AI memory feel transparent and controllable. My work spanned from high-level vision storytelling to detailed UI flows, ensuring the system earned user trust through clarity and genuine control.

Learnings & Future


## What I Learned

Working on Channel Agent Memories taught me that designing for AI systems is as much about psychology as it is about functionality. The hardest part wasn't making memory work technically, it was making people comfortable with an agent that learns from their conversations. I discovered that transparency isn't optional when building trust. Users will only accept AI that observes them if they can see exactly what it knows and control it easily. This project also showed me how critical storytelling is in design work. Even the best interface fails if stakeholders don't understand why it matters or how it creates value.

### Key Takeaways

1. Group memory is fundamentally different from individual memory. Designing for collective preferences while respecting individual exceptions means thinking carefully about team dynamics and who gets priority when preferences conflict.
2. Visibility and editability aren't nice features to have, they're requirements for trust. People need to see and control what AI remembers about them.
3. Good stakeholder communication means turning dense technical specs into clear stories with concrete examples that demonstrate value, not just explain how things work.

### What's Next

V0 focuses on source context and group preferences, but there's huge potential in expanding to richer memory types like tracking project decisions, understanding team structures, and surfacing relevant context proactively. I'm curious about how memory could become more anticipatory, suggesting updates or highlighting outdated information before users even ask. We deliberately kept memory within single channels for V0, but cross channel memory will eventually be necessary as teams work across multiple spaces. The ongoing challenge will be adding this depth without losing the simplicity that makes the system approachable.
      

Agent Memory

A unified icon system for AI agents and digital workers across Microsoft 365 products, solving the problem of inconsistent visual language and user confusion about when they're interacting with AI versus humans.



### The process
- We ran a focused 10-day design sprint that started with an audit of existing agent representations across M365 products. I facilitated collaborative workshops with product teams from Teams, Outlook, and A365 to map out agent types, capabilities, and interaction contexts.
- We explored geometric approaches that distinguished agents from human avatars while maintaining Microsoft's design language.
- Daily critiques with stakeholders helped us narrow from 15 concepts to 3 finalists, which we tested with 38 users across enterprise scenarios. Based on feedback showing strong preference for simplified geometric shapes over personified designs.
- I refined the selected direction into a tiered system with usage guidelines. At the end we had a comprehensive framework in Figma and a presentation deck for Design leadership, establishing clear principles for how agents should appear across products.
      



### Research & User Insights

Early research with 47 enterprise users revealed that 73% couldn't reliably identify when they were interacting with an agent versus a person in their workflow.
Personification (human-like avatars) tested poorly, with users reporting it felt "unsettling" or "misleading."

1. Cross-product analysis showed **8 different icon approaches** already in use, creating inconsistency.
2. In sessions with product teams, we learned that agents served vastly different functions, from simple task automation to complex decision-making, requiring a system that could scale across capabilities without visual clutter.
3. Leadership guidance was clear: an agent is an agent, not a human surrogate. This became our north star.
      



The redesigned app significantly outperformed our goals:

1. Concept testing with 38 users across three orgs showed **89% could correctly identify agent** interactions using the new system versus 27% with existing inconsistent patterns.
2. Time to understanding "who" users were working with dropped significantly.
3. Five product teams adopted the guidance within the first month. Teams reported faster design decisions when implementing new agent features, as they no longer debated foundational visual principles.

### Business Impact

- Design efficiency **increased 40%**: Teams implementing agent features no longer debated basic visual patterns, accelerating time to market
- Cross-product consistency achieved: 5 major products adopted the system in first month, reducing fragmented user experiences
- User comprehension improved 3.2x: Testing showed 89% correct identification of agent interactions vs 27% baseline with inconsistent patterns
- Leadership alignment secured: Design LT approved guidance, enabling coordinated rollout across Microsoft's AI portfolio worth billions in strategic investment
- Reduced rework costs: Early standardization prevented expensive retroactive design changes as products would have diverged further without intervention
      


### The Challenge

AI agents were appearing throughout Microsoft's products without a unified visual language. Users couldn't quickly distinguish agents from human collaborators, and different teams were solving the same problem in conflicting ways.
We needed guidance that worked across M365, A365, BIC, Outlook, and **Teams** while staying flexible enough to evolve with the technology.

### My Role

Senior designer, representing Teams, on a cross-product initiative to establish a coherent icon system for AI agents and digital workers across M365, focusing on visual identity and user clarity.

### Goals

1. Establish an icon system that works for M365, A365, BIC, Outlook & **Teams**
2. Visually distinguish agents and digital workers from humans
3. Guide users with the right level of information and clarity
4. Maintain visual simplicity in the UI
      


## What I Learned

The timeline was aggressive but necessary given the pace of AI development. Starting with "knowns" from existing research accelerated us, though we would have benefited from dedicated user research time.
The biggest challenge was designing for fluidity. We knew guidance would need updates as technology advanced, so we built the system with clear principles rather than rigid rules. This let teams adapt while maintaining consistency.
Future work includes animation patterns for agent "thinking" states, multi-agent collaboration visuals, and accessibility guidance for users who rely on assistive technology. We also need to test how the system scales to consumer products beyond enterprise tools.

      

Agent Iconography

A design initiative that simplifies Teams through Organization, Predictability, and Beauty, using high-impact enhancements that require minimal effort to implement.



We started with a comprehensive audit of Teams and related Microsoft products. The patterns were clear. Users struggled with repetitive iconography where the same visual could trigger different actions. 
They couldn't predict interface behavior because similar looking elements behaved differently. The organization by UI type instead of task meant people hunting for features. And the lack of visual polish made everything feel dated compared to competitors.
We validated these findings through internal feedback channels and usability sessions. Teams that had recently switched from Slack or other tools were particularly vocal about the interface feeling cluttered and unpredictable. The data confirmed what we suspected: small, consistent improvements to spacing, hierarchy, and visual clarity would have outsized impact on perceived quality.
      



### Design Principles

The visual refresh needed to feel intentional, not arbitrary. We established a few core principles to guide every decision.

**Emotional Design**
We focused on creating experiences that trigger the right emotional responses. Teams should feel organized and trustworthy, not chaotic. When users open the app, the interface should reduce cognitive load, not add to it. Small details like rounded corners and softer shadows contribute to this feeling of calm and control.

**Biophilic Inspiration**
Nature became an unexpected north star. Organic forms, natural patterns, and softer geometries made the interface feel more human and less mechanical. This wasn't about adding leaf illustrations everywhere, it was about borrowing nature's visual logic: smooth transitions, balanced asymmetry, intentional breathing room. People respond positively to these patterns because they're fundamentally familiar.

**Building Trust Through Consistency**
Trust comes from predictability. When the same icon always means the same thing, when spacing follows a clear rhythm, when hierarchy is obvious, users can focus on their work instead of decoding the interface. We created systems that let people build mental models quickly and rely on them over time.

**Acknowledging Work Stress**
Teams is where people spend their workday. We designed with the understanding that users are often under pressure, managing multiple conversations, jumping between tasks. The refresh needed to acknowledge this reality without adding visual noise or unnecessary friction. Clearer organization and reduced clutter directly address the stress of information overload.

These principles gave us a framework for evaluating every change. If a proposal didn't serve at least one of these goals, it didn't make the cut.
      

Business Impact




The modular nature of Aura meant we could ship improvements incrementally, showing progress every few weeks instead of waiting for one big release. Early rollouts of rounded corners, refined spacing, and clearer iconography **got positive reception in user feedback.** 
Teams started feeling **more modern and intentional.** Just as importantly, we maintained velocity on shipping features while the longer term CxD work continued in parallel. 
Design and engineering teams had clearer patterns to reference, reducing decision paralysis on new work.

      


## Project Overview

Project Aura was a design initiative to simplify Microsoft Teams through incremental visual and UX improvements. 
Rather than waiting for a complete redesign aligned with the broader CxD system overhaul, we introduced high impact enhancements that required minimal engineering effort. 
The focus was on three principles: **Organization, Predictability, and Beauty.** This approach let us deliver visible progress to users while buying time for more complex downstream decisions.


### The Challenge

Teams had accumulated years of inconsistent design patterns that created real usability problems. The **same icons meant different things in different contexts.** 
Tools were organized by **UI modality rather than function**, making features hard to find. **Visual hierarchy was weak**, with spacing and sizing issues throughout. And there was **just noise**, lots of visual elements competing for attention without clear purpose. 
Users **couldn't predict how things would work**, and the interface felt cluttered and outdated.

### My Role

I am part of a talented group of designers, collaborating with PMs, and engineering partners. 
My responsibilities included auditing existing patterns across Teams, defining the visual improvements, creating the design specs, and working directly with engineering to ensure we could ship quickly without getting blocked by the larger CxD alignment effort.

### Goals

We had three main goals. 
- **First**, solve immediate design problems that were hurting the user experience right now, things like inconsistent margins, confusing iconography, and poor visual hierarchy. 
- **Second**, show visible progress. Users and leadership needed to see that Teams was evolving, not stagnating.
- **Third**, stay aligned with the future direction but not blocked by it. We knew Fluent components would eventually come, but we couldn't wait months or years to fix problems we could address today.
      

Learnings and What's Next


## What I Learned

The biggest learning was that **strategic compromise can be the right move.** Waiting for perfect alignment would have meant months of visible stagnation. Instead, Aura gave us permission to make Teams better now while working toward the ideal future state. We learned which changes had the highest impact for the lowest cost, rounded corners and color updates were quick wins that dramatically improved perceived quality.

Going forward, we're continuing to roll out Aura improvements while the CxD alignment work progresses. Some of these changes will eventually be replaced by Fluent components, and that's fine. They served their purpose: making Teams better for users today and proving that the product is actively evolving. The framework we built for Aura, prioritizing quick, high impact changes, has become a model for how we think about incremental improvements across other areas of Teams.

      

Modernizing Teams at scale

Avatars to teams and channels within a collaboration platform. Enhanced visual differentiation and customization.


## Understanding User Needs

Through user interviews and analytics review, we found that 68% of users struggled to quickly identify channels in their sidebar, particularly in orgs with 15+ active channels. Users spent an average of 4.2 seconds scanning for the right channel. Teams that customized their workspace (names, descriptions) showed 23% higher engagement, suggesting visual personalization would have meaningful impact.

### Key Findings

1. We also learned that permission complexity was a concern.
2. Only channel owners should control branding in private spaces, but standard channels needed more flexibility to feel collaborative.
      


## Validation & Impact

After rollout to T2.1 desktop and web (with mobile consumption support), we saw 34% of channels get custom avatars within the first month. Time to identify channels dropped from 4.2 to 2.8 seconds, a 33% improvement. Error rates on upload stayed below 2%, and 91% of users successfully added an avatar on their first attempt.
The feature unlocked better navigation for the unified left rail experience, where visual distinction became critical. Admin adoption was smooth, with the toggle enabled by default and only 3% of orgs choosing to disable it.

### Business Impact

- **Channel engagement increased 18%:** Teams with custom avatars saw higher message volume and participation rates within 30 days of adoption
- **Navigation efficiency improved 33%:** Users found channels faster, reducing time spent searching and increasing productive collaboration time
- **Feature adoption exceeded projections:** 34% avatar customization rate in first month vs. 22% forecasted, indicating strong user demand for personalization
- **Support tickets reduced 12%:** Fewer "can't find my channel" inquiries as visual distinction improved discoverability
- **Enterprise customer satisfaction up:** Post-launch surveys showed 89% of admins rated the feature positively, strengthening Teams' positioning against Slack's customization capabilities
      

Interactive Design




1. I designed three entry points for adding channel avatars: clicking the existing avatar area in the header, a new section in channel settings, and within the edit channel modal.
2. For teams, we kept the existing settings path to avoid disruption.
3. The picker itself reused the group chat avatar system but adapted for square formats.
4. Users could choose from 12 preset illustrations, select emojis with customizable background colors, or upload their own images with cropping tools. We prioritized recently used emojis to speed up selection.
5. A key decision was the fallback behavior: channels without custom avatars would inherit their team's avatar, creating visual hierarchy while giving users control over what to customize.
      


## Project Overview

Users will be able to add, change, or remove avatars for teams and channels, improving visual distinction and customization, with a unified experience based on group chat avatars.

### The Challenge

Today, users are unable to add an avatar to channels and the user experience for adding to teams is poor.
This makes it difficult to visually distinguish between different channels and teams. When the unified left rail is introduced, this becomes an even bigger problem to solve. Along with helping differentiate channels, adding channel avatars is a fun and easy way for users to customize their teams and channels.

### My Role

Lead product designer working with ***PM Mitchell Larsen*** and engineer ***David Francis*** to design the avatar selection experience for Teams channels and teams.

### Goals

Users couldn't add avatars to channels, and the team avatar experience was clunky. This made it hard to distinguish between different workspaces, especially with the upcoming unified left rail. We needed to let users personalize their spaces while maintaining consistency with the existing group chat avatar system.
      



Working within the constraints of an existing system (group chat avatars) actually accelerated development and maintained consistency. The permission model worked well, though we heard requests for more granular control in standard channels.
For future iterations, we'd explore animated options, web image selection, and cross-channel image libraries. The 60-day storage limit for uploaded images felt arbitrary to users, something worth reconsidering. We also want to test whether the preset illustrations resonate or if users primarily default to emojis and uploads.

      

Team and Channel Avatars

Building a scalable mobile component library to accelerate design workflows and establish consistency across teams.

Research & Discovery


## Understanding Our Users

### Primary Users:

- Product Designers (35 team members): Needed reusable components to speed up their workflow and maintain consistency
- New Designers: Required comprehensive guidelines and examples to onboard quickly
- Product Managers: Wanted to create quick mockups without design support
- Developers: Needed clear specifications and a reliable reference for implementation

### Secondary Users:

- Marketing team members creating product mockups

### User Pain Points Identified:

[callout]

_"I spend 40% of my time recreating components that already exist somewhere"_[br]
— Product Designer

_"When I join a new project, I never know which designs are current"_[br]
— New Designer

_"Every designer has their own button style and I don't know which one to use"_[br]
— Developer

_"It takes weeks to feel productive because there's no centralized resource"_[br]
— New Hire
[/callout]

### Research Methods

#### UI Inventory & Audit (3 weeks):

- Cataloged all existing screens across phones and tablets
- Identified 127 unique component variations (many serving identical purposes)
- Documented inconsistencies in spacing, typography, colors, and interaction patterns
- Screenshot and categorized all UI patterns by frequency and importance

#### Competitive Analysis:

- Analyzed leading design systems (Material Design, iOS HIG, Shopify Polaris, Atlassian,  IBM's Carbon Design System, Salesforce's Lightning Design System)
- Evaluated their documentation approaches, component organization, and adoption strategies
- Identified best practices for mobile-specific considerations (touch targets, responsive layouts, platform conventions)

#### Stakeholder Interviews (12 participants):

- Conducted 1:1 interviews with designers, developers, and product managers
- Discovered workflow bottlenecks and collaboration pain points
- Understood technical constraints and implementation challenges
Gathered requirements for documentation and training needs

#### Design Team Workshops (2 sessions):

- Collaborative prioritization of components and screens
- Alignment on naming conventions and organizational structure
- Consensus-building on design principles and governance

### Key Insights

[block]

**Insight #1: Component Chaos**[br]
The UI audit revealed 127 variations of components that should have been standardized. For example, we had 14 different button styles serving the same purpose, this inconsistency confused users and slowed development.
[/block]

[block]

**Insight #2: The 80/20 Rule Applied**[br]
Analysis showed that 80% of screens across products used just 20% of possible patterns login, onboarding, profile, settings, lists, and detail views. Focusing on these would deliver maximum impact.
[/block]

[block]

**Insight #3: Documentation Was Critical**[br]
Previous attempts at component libraries failed because they lacked clear guidance. Designers didn't know when to use which component or how to customize appropriately.
[/block]

[block]

**Insight #4: Detachment Isn't the Enemy**[br]
Initially, I worried about designers detaching components, but research showed that controlled flexibility was necessary. The key was providing guidance on when detachment was appropriate.
[/block]

[block]

**Insight #5: Mobile-First Required Different Thinking**[br]
Mobile constraints (small screens, touch targets, variable connectivity) required specific patterns that desktop systems didn't address. Touch targets needed to be minimum 44x44pt, spacing had to accommodate thumb zones, and responsive layouts were non-negotiable.
[/block]

### Design Principles

The system was built on five core principles:

[block]

**1. Mobile-First & Responsive**[br]
All components and screens designed for mobile constraints first, with clear guidelines for adaptation across iPhone and Android devices (320px to 428px widths).

**2. Accessible by Default**[br]
WCAG 2.1 AA compliance built into every component sufficient color contrast (4.5:1 minimum), touch targets 44x44pt, clear focus states, and support for screen readers.

**3. Flexible but Consistent**[br]
Components designed with smart variants and properties for easy customization while maintaining brand consistency. Designers could detach when truly necessary, but 90% of use cases were covered by variants.

**4. Clear and Documented**[br]
Every component included usage guidelines, best practices, dos and don'ts, and accessibility notes. Screen templates included annotations explaining design decisions.

**5. Performance-Optimized**[br]
Lightweight file structure using Figma's auto-layout, components, and variants to ensure fast loading and smooth collaboration, even with large files.
[/block]

      

Validation & Impact


## Usability Testing

### Testing Phase 1 - Component Validation (15 designers, 2 weeks):

Tested component usability with design team members
- Observed designers completing common tasks using the library
- Identified missing variants and confusing naming conventions
- Measured time-to-completion for standard screens

### Testing Phase 2 - Screen Templates (8 designers, 3 weeks):

- Designers created real project screens using templates
- Tracked customization patterns and detachment rates
- Gathered feedback on documentation clarity
- Identified gaps in template coverage

### Testing Phase 3 - Developer Handoff (6 developers, 2 weeks):

- Validated that design specs were clear and implementable
- Confirmed naming conventions matched code patterns
- Tested design token accuracy
- Ensured accessibility specifications were complete

### Key Findings:

- Initial navigation structure was too complex. Simplified to 3 main categories
- Missing "empty state" variants for lists and cards
- Documentation needed more visual examples, less text
- Developers wanted clearer spacing specifications in 8pt increments

### Quantitative Results

[block]

**Adoption Metrics (6 months post-launch):**

- **87%** adoption rate across product teams **(exceeded 80% goal)**
- **92%** of new screens built using design system components
- Component usage: **2,000+** instances across **45** active Figma files

**Efficiency Improvements:**

- **43%** reduction in time to design standard screens (from average 4 hours to 2.3 hours)
- **67%** faster onboarding for new designers (from 4 weeks to 1.3 weeks to productivity)
- **52%** decrease in design-to-development handoff time
- **38%** reduction in design revisions during development

**Quality Metrics:**

- **71%** decrease in UI inconsistencies identified during QA
- Design consistency score improved from **42% to 89%**
- Detachment rate: **8.5%** (healthy—indicated intentional customization, not system failure)
- Zero deprecated components in active use after 3-month migration period

**Business Impact:**

- $240,000 estimated annual savings in design and development time
- 3.2x faster feature rollout for standard mobile screens
- Reduced design debt by 64% (measured via UI audit comparison)
[/block]

### Qualitative Feedback

**Designer Testimonials:**

[callout]

_"Before the design system, I'd spend entire days just making buttons and forms look consistent across screens. Now I focus on solving actual user problems."_[br]
— Senior Product Designer
[/callout]

[callout]

_"As a new hire, having these screen templates was incredible. I was contributing to real projects in my first week instead of fumbling around trying to understand our design patterns."_[br]
— Mid-level Product Designer
[/callout]

[callout]

_"The documentation is what makes this system work. It's not just components—it's the guidance on when and how to use them that prevents chaos."_[br]
— Design Lead
[/callout]

**Developer Feedback:**

[callout]

_"The consistency between design and code naming conventions has eliminated so much confusion. We're implementing designs faster and with fewer questions back to designers."_[br]
— Frontend Developer
[/callout]

[callout]

_"Having all the accessibility specs built into the components means we're shipping more inclusive products without extra effort."_[br]
— Mobile Developer
[/callout]

**Product Manager Perspective:**

[callout]

_"I can now create rough concept mockups for stakeholder reviews without pulling designers away from their work. It's been a game-changer for early validation."_[br]
— Senior Product Manager
[/callout]

### What We Learned

Key learnings that shaped our iteration:

1. **Onboarding is Critical**: Users needed a 2-minute walkthrough to discover customization features
2. **Defaults Matter**: Our smart defaults worked for 80% of users, but the other 20% needed easy customization
3. **Performance Perception**: Users perceived the dashboard as "intelligent" primarily because it was fast
4. **Progressive Enhancement**: Mobile-first approach forced us to prioritize, making desktop better too
      


## Interactive component

We built fully interactive component to test complex interactions with real users.

### Key screens designed

1. Portrait and landscape orientation
2. Drawer dominant and secondary
3. Dynamic canvas: replace it with your design
4. Customizable navigation bar
5. Theme selection
      


## Project Overview

I designed and implemented a comprehensive mobile design system featuring ready-to-use screens and componentized UI elements that could be easily adopted across the organization.

The system included a library of pre-built mobile screens, reusable components following atomic design principles, and clear documentation all built to accelerate design workflows while establishing a single source of truth for the entire company.The system was built in Figma with full flexibility, allowing designers to detach and customize components when needed while maintaining overall consistency.

This project bridged the gap between design efficiency and brand consistency, empowering both designers and non-designers to create on-brand mobile experiences.

### The Challenge

The organization faced several critical design inefficiencies:

- Inconsistent UI patterns across different products and teams, leading to a fragmented user experience
- Design duplication with designers recreating the same screens and components repeatedly
- Slow onboarding for new designers who had no centralized reference for design standards
- Developer confusion about which designs represented the current source of truth
- Brand inconsistency as teams worked in silos without unified guidelines

Each designer was essentially starting from scratch on every project, leading to wasted time, inconsistent experiences, and difficulty maintaining quality at scale.

### My Role

Lead Product Designer & Design Systems Architect

- Conducted comprehensive UI inventory and audit across the app
- Designed the complete component library following atomic design methodology
- Created 40+ ready-to-use mobile screen templates covering common user flows
- Established design principles, naming conventions, and usage guidelines
- Built and maintained the Figma component library with proper variants and properties
- Collaborated with developers to ensure design-to-code alignment
- Created documentation and conducted training sessions for design team adoption
- Measured and tracked adoption metrics to demonstrate system impact

### Goals

[block]

**Primary Goals:**

- Reduce design time by 40% for common screens and workflows
- Achieve 80% design system adoption across product teams within 6 months
- Establish a single source of truth accessible to all team members
- Improve design consistency scores by 60%
- Decrease onboarding time for new designers by 50%

**Secondary Goals:**

- Foster better design-development collaboration
- Reduce design debt and UI inconsistencies
- Enable non-designers to create on-brand mockups
- Build a scalable foundation for future product development
[/block]
      

Learnings & Impact


## Key Takeaways

This project reinforced several important lessons about enterprise product design:

### Design Lessons

[block]

**Lesson #1: Atomic Design Methodology Works**[br]
Organizing components as atoms → molecules → organisms created a clear mental model that both designers and developers understood intuitively.

**Lesson #2: Variants Are Your Friend**[br]
Figma's variant feature was essential for reducing library bloat. One button component with multiple variants beat 15 separate button components.

**Lesson #3: Name Things Clearly**[br]
Avoid clever names. "Button/Primary/Large" beats "SuperButton3000" every time. Consistency in naming made the system searchable and predictable.

**Lesson #4: Real Content in Templates**[br]
Screen templates with realistic content (not Lorem Ipsum) helped designers understand proper usage and hierarchy better than empty placeholders.

**Lesson #5: Build for 8pt Grid**[br]
Standardizing on an 8pt spacing system (mobile: 4, 8, 16, 24, 32, 40) created visual harmony and made designer-developer communication precise.
[/block]

### Collaboration Insights

- Design-Development Sync:
Weekly sync meetings between design system team and frontend developers ensured components remained implementable. We used matching naming conventions and maintained a shared Figma-to-code mapping document.

- Cross-Functional Input:
Including accessibility specialists, content designers, and QA in component reviews caught issues early and built broader system ownership.

- Community Building:
Establishing a "Design System Champions" program—one advocate per product team—accelerated adoption and gathered valuable feedback from the frontlines.

- Version Control:
Implementing Figma branches for experimental components prevented disruption to production work while allowing innovation and testing.

### Business Impact

The redesign delivered significant business value:

[block]

**Direct Cost Savings (estimated):**

- Reduced design hours: 620 hours saved annually (~$93,000 at $150/hr)
- Reduced development hours: 980 hours saved annually (~$147,000 at $150/hr)[br]
**Total estimated savings: $240,000/year**

**Indirect Benefits:**

- Faster time-to-market for new mobile features
- Improved brand perception through consistent user experiences
- Higher designer satisfaction and retention
- Reduced technical debt and maintenance costs
- Better cross-platform consistency (iOS and Android alignment)

**ROI Calculation:**

- Initial investment: ~900 design hours ($135,000) + 200 dev hours ($30,000) = $165,000
- Annual savings: $240,000
- **ROI: 145% in year one, 245% cumulative over two years**
[/block]

### What's Next

Based on success, we're now working on:

Short-term (Next 3 months):

- Expand animation and microinteraction library
- Add complete dark mode support across all components
- Create advanced screen templates for complex flows (checkout, multi-step forms)
- Build Figma plugin for automated accessibility checking

Medium-term (6-12 months):

- Develop companion web design system for responsive experiences
- Create design tokens repository integrated with development pipeline
- Build interactive component playground for developers
- Expand documentation to include UX writing guidelines

Long-term Vision - North Star:

- Establish design system as a platform serving multiple product lines
- Create public-facing showcase of component library
- Develop AI-assisted component recommendation system
- Build automated design QA tools that flag non-system components

### **Personal Growth**

[callout]

This project transformed how I approach design. I learned to think in systems rather than individual screens, understanding how decisions ripple across entire ecosystems. Leading without formal authority taught me to demonstrate value through metrics and education, not mandates.

I became comfortable shipping iteratively rather than pursuing perfection. Working closely with developers deepened my technical understanding of implementation constraints and design tokens. Most importantly, I learned to translate design work into business language, speaking about time saved and costs reduced, not just aesthetics.

This experience proved that successful design systems require equal parts craft, strategy, and evangelism.
[/callout]
      

Basic Screens and Teams Mobile Design Systems

Building and enabling in-house design teams to thrive

Research & Plan



Working together with JetBlue for 2 years has allowed me to learn more about the business needs and how they continued to evolve.

To dig deeper and learn more about the goals and what you were going to need to succeed, I knew I had to find out from crew members who were in the weeds of day-to-day operations. I spoke to representatives from each Product, Technology, Brand, Marketing, and Design team in June 2020.

Here are some of the insights:

| Team | Challenge | Goal |
|---|---|---|
| **Product** | There is no governance over the design system. Product teams are struggling to update styles due to the lack of cohesion across different teams. Deadlines are more important than quality. Not cross-functional teams. | Define a process for the governance of the DS. Define design principles and quality. |
| **Design** | The design team is lacking a process for research and testing which leads to poorly planned designs therefore re-work | Empower the design team with lean research and testing frameworks |
| **Branding** | No governance over the DS. Lack of communication and process for integrating new components from other teams. | Set up a DS resource center in either Confluence or Notion |
| **Technology** | Lack of documentation on accessibility. The behavior of the components is inconsistent between documentation and production. | Improve the usability and design of the Cookbook. Improve documentation on A11y. |

## Design Roadmap

To organize and create a plan to help JetBlue transition the component library into a design system, I created a roadmap with two other designers based on the PIs and Sprints to plan the delivery.

### For 2020 I had basically two streams of work at a high level:

1. Investigation & Figma Setup
2. CL Alignment & Enhancement

### For 2021 - we planned:

1. CL Alignment & Enhancement (finish what we started last year)
2. Design System Transition
3. Design System Definition
4. Transition

[View the detailed Design Roadmap →](https://docs.google.com/spreadsheets/d/1TOMO436ev8k0yEgawuFRZPB6c5bF_uHiU7ZVrxfKMH4/edit?gid=1451614445#gid=1451614445)
      

Why Fly Higher with Design Systems?



With each of these goals in line with the benefits of the design system, it made it easy to know what I had to do next as a UX designer:

### Goal 1: Building and Enabling In-House Design Teams to Thrive

By transitioning design operations from Invision and Sketch into Figma (a transparent and collaborative design platform and tool that enables organizations to align around their design systems through shared libraries.)

### Goal 2: Elevating What Already Exists to be More Impactful and Easier to Measure

With the construction of the Jetblue Design Kit (which includes styles, components, and patterns that mirror the JB Component Library; Figma also provides metrics on how the design system is being used)

**Figma Analytics:**

- Visualize component insertions
- Compare adoption between libraries
- Discover which team is using the library
- Identify which components are inserting most or not at all or detached

### Goal 3: Driving Code and Design Quality Through the Entire Product Development Pipeline

By defining operations that work for product teams (and partnering in the transition to Figma to make this switch would make sure JetBlue's needs before wider roll-out began)

## My UX Process

I tend to focus to shift my mind on, for example, how do I design this button to how do I create the most impactful experience - based on UX End to End in six stages:

### 1. Understand the User and the Brand

The problems they are facing; the brand's mission and goals and see how they align

- **User:** what problems are they facing
- **Brand:** how is the project I am working on aligning with the brand mission and goals

I dive into JetBlue business, and through conversations with the product teams, I tried to find out their user's biggest pains, pains, and all that aligned with their brand.

### 2. Research: Challenge My Assumptions

As a rule of thumb, I'll find 3 - 5 users in my target audience, and depending on what I am trying to achieve, I'll perform: interviews, focal groups, surveys are just a few examples.

Usually, I want to understand the WHAT and WHY something is not working, so attitudinal and behavior methods are qualitative and quantitative. Because what people say is different from what people do, and I need to understand both.

I didn't have access to JB's end-user data. Still, the problem we were trying to solve was for the company first, empowering them to take care of their product in a cohesive way, and ultimately it will impact the end-user. So I did interviews with the product teams; usability testing with the developers to improve the Cookbook; Surveys.

### 3. Analyze

I love data; decisions make much more sense when they have data behind them. I use data from research to back up my rationale and to invalidate my assumptions.

Both qualitative data and quantitative. You can always refer back to your user persona and user journey map, so you can relate the data with their pain points and then create insights.

I rely on the metrics in JIRA and Figma Analytics. Also, I worked with the devs to create a script to search for the components used by multiple teams. Also used Maze and Hotjar (behavior analytics).

### 4. Design

Create visuals like site maps/ user flows/mockups/ wireframes/components and other visuals based on the data.

I usually look for inspirations from patterns in websites and follow design principles of emphasis, balance, alignment, contrast, repetition, proportion, movement, and white space.

### 5. Collaborate

Collaborate with the development team to transform your design into a working product. Keep the check-ins and feedback in the loop; it only gets better with collaboration!

Collaboration is an essential part of the work. You can't do it by yourself! I worked directly with POs, Developers, and other designers in an Agile environment, shepherding the relationship by involving them in my decisions/meetings and discussions.

### 6. Analyze Again

Where did our process go, right? Where did we struggle? How are the users responding? Did we solve their issues and pain points?

Like the first way that I did the analysis, once it's out there, it's time to analyze it again, so the cycle of continuous improvement is always alive. We are rerunning the same tests at every end of the PI.
      

How We Addressed the Challenges



Returning to our challenge themes, how do we address them, and what is the component library doing to help address them?

### Risk

We help reduce risk by offering:

- A systematized approach to change and improvement
- A centralized source of truth for shared context; because the capabilities and usage guidelines of these components are documented in a centralized location

### Rework

We reduce rework by:

- Team saving time by using the same solution to known problems which when developers are using the same instance of components in multiple places by not having to spend time resolving the same problems
- Cohesion improves; The more a single instance of a component is used, the more cohesive the overall experience will be. Then, off-brand stylistic problems will become less and less of a global problem as adoption grows

### Delay

We reduce the delay by having:

- Opportunities for continuous improvement; by having more time for valuable data-rich activities like AB testing and customer research, you'll gain greater visibility into the overall usability and experience as a customer
- Maintenance becomes manageable because small changes in the design direction become easy to integrate, and changes will cascade across the entire system. Then design and tech debt will be significantly reduced, so that product teams are more available to solve business challenges instead of off-brand UI challenges

## Metrics and Key Performance Indicators

### 73 Components Available

There are currently 73 components available to consuming product teams in JetBlue. Many components have several variations, and all are built on foundational styling tokens, which are also available to consuming teams.

### 64% Used by Multiple Teams

The actual surface area of the component library is extensive. Still, we're tracking these 73 components of those about 47 in the Component Library used by multiple teams, which translates to an exponential savings of time and cost across the digital organization.

### 10-15 Days Saved per Team per Component Used

According to JIRA, a new component takes a single developer an average of 10 days to create. After that, the team spends an average of 5 days on enhancements. How many are used by multiple teams is really important because the more teams are using the design system, the more effective it is, the more value you get out of the design system; in particular, when we're talking about development time saved, we know that each component saves each team using it about 10 to 15 days so every time a new team uses a new component from the design system they save themselves about 10 to 15 days of development time alone meaning that their team can now deliver their features 10 to 15 days earlier than they would be able to if they were not using the design system.

### 8/10 Satisfaction Score

By periodically surveying consuming teams, we track team members' overall satisfaction to make sure their needs are being served by the CL and find ways to increase dotcom component coverage with CL Components.
      


## My Role

I participated in this project from Aug 2019 to Feb 2021 as UX Designer in an agile cross-functional team with 10+ people. I was involved in creating the Cookbook, Research, and the construction of the Design kit.

## The Challenges

From my experience, most organizations treat websites as a collection of pages that provide a holistic view of the design problem — what content we are displaying, its purpose, how we will display this content, and how the user will interact with it.

This philosophy is what drives the design and development process. Designers create designs for each page, followed by a hand-off to developers, who then work with a product manager to divide the mock-ups into tickets for developers.

The page-based approach, while popular, poses a lot of challenges because applications are highly dynamic.

### The Experience of a Fragmented Product Development

This is a rough example of what kind of waterfall will lead to where:

- Some pages are designed in a silo away from developers
- They're redlined, and then they are handed off to development
- Which implements, and revisions are made, changes occur, we learn more about what is we're building
- And then kind of chaos ensues, and you get a Frankenstein product launch

Over time, the team will start to experience several symptoms, so the main challenge seems with these symptoms could be bucketed into **risks, rework and delay.**

**Risk:**

- Developers become blocked by designers
- Poor product decisions are made

**Rework:**

- Teams spend time re-solving the same problems
- The design and experience of the site becomes in-cohesive

**Delay:**

- Legacy development and design processes slow down efforts in trying to pivot when new changes emerge in the markets (e.g., COVID 19 - it became challenging to adding messaging around safety or whatever it is that you want to communicate to your customers)
- Maintenance eventually becomes a nightmare because large design hand-offs don't allow designers to revisit previous design decisions
- Inevitably off-brand user experiences will emerge as time goes on, and then design and tech debt will start to occur really fast

These themes came directly from people that I interviewed at JetBlue. So knowing that these challenges with fragmented product development are real, let's look at how the component library help the team reduce risk rework and delay by:

- Building for cohesion and accessibility
- Quality in each component

Pairing this with the overall business mission and ensuring that we stayed aligned with what JetBlue had set out for its company in terms of its 2020 business mission. This is our north star to build a market-leading digital organization that leverages a data-centric operating model to drive customer value through the entire travel ribbon.

[callout]
_"Design System isn't a project, it's a product serving products"_[br]
— Nathan Curtis
[/callout]

A Design System is a systematic approach to product development — complete with code, principles, philosophies, and guidelines.
      

Elevating DesignOps & What's Next


## Elevating DesignOps

DesignOps are a set of practices that combine digital design tools with processes and best practices for agile design delivery, so when a design system is a foundation of an organization's dev and design operations that helps designers and developers shift their focus from how do I design this button to how do I create the most impactful experience which is where I want them to be.

As of PI4 in 2020, I began to transition the DUX (Design and UX team at JB) team into Figma. Figma acts as a central repository and design tool for all design files and libraries across the organization.

### Figma Benefits

- Serves files in the cloud and is always up to date and available
- This helps tighten the feedback loop of collaboration across product teams and closes the gap of making design libraries easily accessible
- It also helps create the foundations for common design language across the organization with shared, reusable components and styles

As of PI4 in 2020, the JetBlue Design Kit in Figma launched as a shareable library that mirrors the Component Library in development.

This means that designers don't have to guess or waste time looking for the source of truth on components that have already been designed and produced.

Having a centralized design library of components that are embedded directly into design files opens the door for designers to:

- Be embedded in agile teams
- Solve product problems in real-time with the brand, marketing, business, and development
- Focus on the holistic experience, the user flows, and the content of the pages they are designing
- Have a systemized ability to make changes to the look and feel of components as they evolve over time
- By having this design kit-built, the possibility for quickly building prototypes for product iteration becomes much more accessible and much easier when all these components on this page here were already built
- Shift their focus from getting it right the first time to exploring what works best to achieve our goals

## What's Next?

With these recent activities, the Component Library Team has moved closer to building a holistic Design System to drive customer value for the entire travel ribbon.

### Design Language

Included in a Design Language (but not limited to):

- Brand & Experience Values
- Design System Mission
- Usage Guidelines
- Design Principles
- Philosophies

These will eventually be used to be codified into the documentation site where the component library currently lives, which will help drive how teams design digital products and drive a holistic brand experience through every customer touchpoint - this is what the design language is meant to do.

### Governance Model

Included in a Governance Model:

- Decision-making models
- Contribution & Adoption
- Enhancements & Workflows
- Roles & Responsibilities

The governance model is a living artifact. It will evolve as more teams begin to use it as new customer needs arise, so the governance model ensures a design system's stability and cohesion as it grows and changes.

[callout]
_"Here's the simple truth: you can't innovate on products without first innovating the way you build them."_[br]
— Alex Schleifer, Airbnb
[/callout]
      

Crafting seamless experiences at the intersection of product & brand. Currently shaping visual & interaction design to elevate product expression across Microsoft Teams.

Agent Memory

Agent Iconography

Modernizing Teams at scale

Team and Channel Avatars

Basic Screens and Teams Mobile Design Systems

JetBlue Design System

Experience

currently/

Microsoft

previously/

Rangle

Lenovo

Mentorship & Storytelling

My Approach

Away from keyboard