Finance Design System

Yoyo_Yoyo

大连/UX设计师/332天前/28浏览

版权

Yoyo_Yoyo

2023 Mar - 2024 Dec

Collect

How might we create a scalable design system that evolves with our brand while maintaining a consistent user experience?

Disclaimer:
Due to compliant restrictions, company details have been omitted. Let's connect for more details!

The single source of truth website

Collect

OVERVIEW

Finance Design System (FDS) is a true design system for a financial company, built from the ground up to support our entire digital ecosystem. FDS provides creators the resources and guidance they need to design consistent, accessible user experiences at scale. The system is flexible, adaptable, and will evolve as the needs of our organization does. With this integrated and systematic approach, we can maintain and project a unified brand identity.

Timeline：MVP1 - 6 months, Post MVP1 - 12 months
My role: UX Designer - Lead (sole mobile designer)
Deliverables: design kit, design tokens, documentation and coded component library

PROBLEMS AND CONSTRAINTS

Problems

Inconsistent design standards

In the past development of this company, several design standards have emerged and were widely adopted by products in different BUs. The absence of a unified design system has led to inconsistent design standards across different products, creating confusion and a lack of brand cohesion. See the legacy design standards gallery in image below.

Increased maintenance costs

Maintaining multiple versions of similar components across different projects increases maintenance costs and complicates future updates.

Constraints

Tight schedule and limited resources for MVP1

Our ramp up went from announcement of enterprise initiative, to onboarding external agencies, to crowdsourcing use cases, to consolidation, design iterating, testing, developing, and finally releasing. We had to prioritize more common known use cases then individual product use cases. The scope for each component is also limited to ensure we could meet the deadline. This became a challenge with initial reception and product teams impacted by prioritization.

Consolidation and reduce migration effort in future

Due to the massive adoption of legacy design standards and code, we couldn't abandon just what we had but think about consolidating and inheriting the direction of part of the existing assets to reduce the future effort of migration.

Parallel efforts

As a new team, we navigated a variety of instances of ambiguity with leadership changes, contracts ending and merging with other teams.

APPROACH

Research and analysis

Based on what we learned from status quo and existing assets in this company, we have the following findings and recommendations:

Findings and recommendations

Collect

Our methodology

Scope definition

In MVP1, we identified a list of components for each channel (iOS, Android and Web) and plan them into Sprints in the 6 months schedule. For each component, we set the function scope to meet requirements in major and common use cases. We took the "quality over quantity" mindset to ensure our deliverables are usable and robust.

Post MVP1, we started to expand the scope of components according to feedback from pilot teams, and we prioritize new requirements by collaborating with product team.

Platform equivalence

To deliver a design system that works for all channel (mobile, web, and maybe hybrid in future), we tried to align as much as possible but also respect the best practices on each platform. This requires a balance between consistency and channel-specific capability, and it is really a case-by-case analysis sometimes. Overall, we would pursue function parity than pixel-level similarity on appearance (this doesn't mean style consistency is not important).

Design and code parity

We have strict control on component name, style and function between design and code. But based on reality, our Figma and design guidance needs to provide extra utility components than code library. These utility components are components that can't be considered as a real component from code perspective, or consumers should use native capability instead. Examples: Alert, Segmented control in iOS. To clarify and reduce gap, we mark utility components in Figma library and call out that in our documentation.

Accessibility

Accessibility is integrated in every stage through our process, including requirement triage, design, coding and documentation. Therefore, the build-in accessibility could lay a solid foundation for experience design of digital products. Accessibility testing in context is also essential before major release.

Team structure

Our team of 20+ members is organized into two smaller squads to break down the bulk of work into smaller increments. As an individual contributor, I worked across both the "Delivery" and "Enablement" squads, splitting my time 50/50. Delivery focuses on operational component functions such as design tokens, design toolkits, and coded catalogs, while Enablement focuses on adoption and engagement.

Component creation process

Collect

Consumer adoption

Adoption diagram

Consumer adoption diagram

Collect

Adoption strategy

To encourage adoption and improve the scalability and flexibility, we worked with key platform teams to distribute the design system. Product teams might employ some or all these options:

It looks the same - Apply FDS visual styles

Using FDS tokens, Figma tools, and guidelines, squads can update any existing experience to "look like" FDS regardless of code base.

It works the same - Design with FDS UX patterns

Our layouts and interaction guidelines will provide standards for common experiences such as transactions, account summaries, and data reports.

It's built the same - Use FDS coded components

Components sourced directly from FDS or from one of our "Platform Partners" are tested for accessibility and automatically updated over time.

OUTCOME, IMPACT AND HIGHLIGHTS

Outcome

Here are the outcome for both "Delivery" and "Enablement" squads:

Outcome

Collect

Here is a design example of new design adopting FDS:

Design example

Collect

Impact

Our initial near-term focus on measurement is based on availability and adoption. This ensures we're meeting our immediate consumer needs while paving a path for features like our centralized token pipeline with theming capabilities.

Impact

Collect

Highlights

Accessibility compliant for style and function
A single token pipeline to distributed across Android, iOS, Web and Figma
A single source of truth website to consolidate all design system output
Collaboration with platform team to meet consumers where they are

TAKEAWAYS

Lesson learned

Deepened my understanding of accessibility requirements, especially for AA compliant, screen readers and motion.
Collaborate with content strategy as documentation in guidance can be bridged across the enterprise.
Demos are critical to the success of instilling confidence in design adoption. The increased in design tool updates created a gap for consuming designers to navigate features integrating with iterative releases.
Strengthened my strategic thinking and decision making ability by collaborating with different roles to solve complex problems.

Some potential next steps

Expand pattern documentation efforts to be centralized across business units.
Refine data visualization guidance by leading with an emphasis when to use vs just a data table as well as expanding guidance to not rely solely on color strictly as visual distinction.
Continue to lean in and listen to design community feedback and dive deep into understanding component limitations not meeting their use cases.

Report

声明

原创Works 工业/产品人机交互设计系统