# Designing a Scalable List Component for a Complex Banking Ecosystem

> How I turned a one-off need into a systemic component that anticipated future use cases and made cross-team reuse across the product easy.

- Human version: https://www.augustosalazar.com.ar/project/dise-ando-un-componente-de-lista-escalable-para-un-ecosistema-bancario-complejo
- Author: Augusto Salazar — https://www.augustosalazar.com.ar/llms.txt
- Tags: Design System, Component, Banking

## Context

In large financial organizations, design fragmentation is a recurring problem. Multiple teams working in parallel tend to produce ad-hoc solutions that work but lack systemic coherence.

This project started from an observation: several flows needed to display information as a list, but there was no standardized component for it in our Design System. Each team solved the problem on its own, creating visual and technical inconsistencies that hurt both the user experience and development efficiency.

**My role:** UI Designer  
**System:** Santander Flame AR (derived from the core Design System in Spain)  
**Tools:** Figma, React, FigJam

* * *

## The Problem

![](https://avuznkwizwhkmqshhucp.supabase.co/storage/v1/object/public/media/media/1759730298352-tnsgs.png)**_List 1.0:_** _The first iteration of the component we found in our Design System, with 3 variants._

The lack of a standardized list component created three critical problems:

**Visual fragmentation:** Each implementation had its own take on spacing, hierarchy and interactive behavior.

**Technical debt:** Development teams duplicated effort building similar solutions from scratch.

**Inconsistent UX:** Users ran into different interaction patterns in different parts of the product.

What looked like a minor need was actually a symptom of a deeper structural problem in our design system.

* * *

## Research and Discovery

![](https://avuznkwizwhkmqshhucp.supabase.co/storage/v1/object/public/media/media/1759728340578-tabrs.png)

### Internal Audit

I started by mapping every existing case where information was displayed as a list. I identified recurring patterns and documented the solutions each team had implemented. This inventory revealed shared needs, but also legitimate variations depending on the context of use.

### Design System Review

I did a thorough review of Flame AR and the core system from Spain, identifying existing atoms and molecules that could serve as a foundation. I also studied reference implementations in products like Mercado Libre, whose list components scale remarkably well.

**Key insight:** We had the basic building blocks, but we were missing the "organism" that would bring them together in a coherent, flexible way.

* * *

## Design Strategy

![](https://avuznkwizwhkmqshhucp.supabase.co/storage/v1/object/public/media/media/1759730666818-gmovnu.png)**_First draft:_** _Architecture diagram for the List 2.0 component_

### Systems Thinking vs. a One-Off Fix

I made a strategic decision: instead of designing for the current cases, I would design for a wider range of possibilities. In large organizations, a component is rarely revisited after its initial implementation. This was the chance to build a robust solution that would stand the test of time.

This approach wasn't unanimously supported at first (some preferred a narrower solution), but time would prove the forward-looking decision right.

### Variant Matrix

![](https://avuznkwizwhkmqshhucp.supabase.co/storage/v1/object/public/media/media/1759728688735-ri51cr.png)**_Variant matrix:_** _Every natural pattern we found for the List component, laid out with its variants and possible combinations._

I structured the component along three dimensions:

**Interaction types:**

-   Simple list (read-only)
    
-   List with chevron (navigation)
    
-   List with checkbox (multiple selection)
    
-   List with radio button (single selection)
    

**Content configurations:**

-   Title only
    
-   Title + subtitle
    
-   With badge
    
-   With secondary actions
    
-   With avatar/icon
    

**Sizes:**

-   Small
    
-   Medium
    
-   Large
    

> The "medium" variant was part of the original design, grounded in an analysis of use cases that called for an in-between option. However, during the review and approval process it was dropped in order to simplify the system. Later, when real scenarios came up that would have fit naturally with that intermediate size, the component needed additional adjustments.
> 
> This reinforced the importance of clearly documenting the reasoning behind each variant, and of agreeing with stakeholders on shared criteria for when to prioritize simplicity versus flexibility in a design system.

* * *

![List component variant matrix: interaction types, content configurations, sizes, states and versions](https://www.augustosalazar.com.ar/images/santander-lista-variantes-en.png)

**Caption:** Four interaction types by five content configurations, with their sizes, states and versions.

## Design Process

### Iteration and Validation

The design went through multiple iterations. Each variant was prototyped in Figma with the full set of states: default, hover, pressed, focus, disabled. I used Auto Layout and variants to streamline the handoff and ensure a consistent implementation.

I worked closely with the content team to define the typographic hierarchy and tone of voice. This part wasn't especially challenging, but it was crucial to keeping the bank's institutional consistency.

### Accessibility as a Priority

I built accessibility into the design from the very start:

-   AA contrast verified with specialized plugins
    
-   Minimum type sizes (14px base)
    
-   Clearly defined visual focus states
    
-   Correct semantic hierarchy for screen readers
    

I also had feedback from the internal accessibility lead, who validated the technical aspects of the implementation.

* * *

## Implementation

![](https://avuznkwizwhkmqshhucp.supabase.co/storage/v1/object/public/media/media/1759816783768-xs38ii.png)_Part of the List component log (Bitácora): technical definitions made before the handoff to Development._

### Handoff and Development

I documented the component with surgical precision: color tokens, spacing, typography, interactive behaviors and specific use cases. The React team received complete specs that made a faithful implementation of the design possible.

During development, edge cases came up that hadn't been considered initially. That feedback led to real-time adjustments, showing that design systems are living entities that evolve with use.

* * *

## Reflections

### Design and Programming: Converging Paradigms

This project reinforced a personal conviction: Design Thinking principles have a direct parallel in object-oriented programming. Just as OOP aims to encapsulate behavior and create reusable objects, component design pursues modularity, abstraction and scalability.

Each variant of the List component worked as an "instance" of a parent object, with properties that changed depending on the context. Concepts like inheritance, composition and reuse translated into Figma structures, tokens and UI architecture. This convergence didn't just speed up development; it strengthened the systemic vision of the design.

### The Nature of Patterns

Atomic Design resonated deeply throughout this process. Patterns are everywhere in nature, from planetary systems to molecular structures, and our job as designers is to observe them, abstract them and systematize them. On this project I felt like a "digital biochemist", analyzing components in their most fundamental form in order to build complex organisms.

* * *

## Key Learnings

**Designing for the future pays off.** In corporate settings, especially in large organizations, the first version of a component is often the last one for a long time. Anticipating future use cases creates long-term value.

**Documentation is design.** A well-designed but poorly documented component will fail to get adopted. Time spent on handoff and technical specs matters as much as the visual design.

**Living systems require humility.** No matter how much you anticipate, cases you didn't account for will always come up. Designing systems means staying open to constant iteration.

**Context is king.** Understanding organizational dynamics, technical constraints and other teams' workflows matters as much as mastering Figma or design principles.

* * *

## Impact

![](https://avuznkwizwhkmqshhucp.supabase.co/storage/v1/object/public/media/media/1759817020400-tdge4d.jpg)

**_List 3.0:_** _Properties view of the List component in Figma. A refinement built entirely on version 2.0_

The List component was successfully integrated into Flame AR and adopted by multiple teams across different projects. Its forward-looking design proved its value when new use cases came up that fit naturally into the variants already planned.

Beyond the specific solution, this project set a methodological precedent: the importance of thinking in systems, not just screens.

**_This case study is part of my ongoing learning in systems design. If you're working on similar problems or want to swap ideas about complex components, let's connect._**