Ethr Design System — Creating Complex Graphs (2022)

Asma Riaz Malik
6 min readAug 25, 2022

--

Designing graph components for any fintech application can be a challenging task. Sometimes we deal with a lot of statistical data that is otherwise hard to decipher, if not visualized in the most efficient and effective manner.

That’s why we’ve come up with a detailed pre-built fintech design system called Ethr and in this case study, I’ll walk you through how we built complex graph components in Figma.

The Challenge

As designers, we’re all guilty of using static graphs in our fintech products to save effort. But what’s the downside of that?

  • It’ll lack structure and functionality
  • It won’t meet accessibility standards
  • Developers won’t always be clear on what to design

That said, Figma comes with its own limitations on building components. But, as Nelson Mandela once said:

“It always seems impossible until it’s done.”

Our experts at the Ethr team left no stone unturned while pulling all the strings to build components that are scalable and easy to work with.

The Process

Like any good design, building complex graphs also involves a design thinking process.

  • Research on data visualization
  • Defining criteria for best practices
  • Building the components
  • Testing the components
  • Documenting the process
  • Review sessions with stakeholders
Component creation — Design Process

Research

We started off with some good old-fashioned research by:

  • Getting familiar with data visualization

The first step we took was to learn all there is to know about data visualization. We identified the correct type of graphs/charts to display the various forms of data available.
For example — A data set containing values related to time is better visualized as a trend rather than as a composition.

  • Exploring fintech solutions

We dug deep into several fintech applications to thoroughly observe how they use graphs to depict data and users’ interactions with these graphs. To further define the use case, we compiled all our findings onto a mood board.

  • Identifying the faults

Visualizing data in the form of a graph doesn’t always mean that users will understand it. In fact, some graphs can make it more difficult for users to understand data.

We noticed that there are some applications that don’t use the correct methods of visualization. This helped us define points on what NOT to do when creating the components.

Define

Once we had a good understanding of the playground, we began to define the best practices we’d be following along with our criteria for success.

  • Graph Limitations

Designing graphs and charts for mobile devices required us to limit the information to display per single view such as 06 data values per axis, options to switch between graph views, filtering of data, etc.

  • Properties and Variants

Each version of the component had its own number of properties and variants. For components with many variants, we used basic mathematics:

2n to define the number of variants we needed to create. Power set P(S)={a,b,c,d,e,f} to define the visible number of properties per variant

  • Component Structure

Each version of the design had its own component structure. We wireframed each component and defined how the component will be structured using auto layout

  • Interaction

We defined the interactive states that the component will have and how these interactions were to be displayed on the graph

Design

With a basic understanding and a roadmap prepared, we started designing the components.

Design 01 — Setting the stage

The first version of the component had 127+ variants. The component followed a parent-child hierarchy and was completely responsive adjusting to all mobile sizes

But then came the changes! And everything went into chaos mode.

Lesson Learned — Even though the component worked as expected, we realized that it was not scalable enough, and making a single change required changing 128 variants!

Design 02 — One structure to rule them all

In version 02, we decided to follow the atomic structure and broke down the component into molecules. This time, we reduced the variants down to 64 and made it easy enough to modify the component if any changes occur. This single structure was reusable for all kinds of graphs and charts!

Lesson Learned — Atomic structure solved the problem of scalability but the variants were still too many to update when incorporating any fixes

Design 03 — Keeping it up to date

By this time, Figma released its new update! This allowed us to reduce the number of variants to 02 variants per graph! By this time, the component became more scalable.

Lesson Learned — After putting the component through a number of tests, we discovered that there were some limitations that we could overcome. Example: Introducing options to select the number of values on the X and Y axis! Also, instance swap produced more bugs than before!

Design 04 — Simplifying

In version 04, we solved the problems occurring due to new Figma updates, which made the component even more simple, scalable, and easy to use for the designer!

This version of the component became the version we decided to publish. We look forward to adding on more improvements as Figma introduces new features

The Testing

After the components were created, we decided to test them by defining a number of metrics. Each component had to pass through a test case consisting of over 30+ metrics and obtain a score of 04 or higher to be moved into a stable state. The stable state stated if the component was ready to be published.

Component Testcase

The Documentation

Finally, when each component was created, we decided to document it. The compilation consisted of guidelines on the anatomy and structure of the component. The types, component use cases, best practices, and a playground for designers to get familiar with the component properties.

Component Documentation

Using the Component

Ethr Design System contains templates where all the created components are utilized together to form design patterns and pages. We placed the graph components in these templates and create solutions related to fintech to see if the newly created components worked well in actual designs.

The Next Steps

We were ecstatic to release our first version and receive tremendous support from the design community. The support enabled us to look forward to more updates as the graphs/charts that we have created are only the MVP version of the Ethr Design System. Our constant efforts to create exceptional features and advancements in the existing components will help us introduce more data visualization components soon!

Get your free copy of the Design System https://www.figma.com/community/file/1134023223825957652

Meet the Team!

Shuayb Khan: Head of Design
Muhammad Osama: Sr. Design Manager

Asma Riaz Malik: UX Designer
Raazia Nadeem: UX Designer
qudsia zearlish: UX Designer
Saad Jameel: UX Designer

Osamah Mahmood: Visual Designer

Special thanks to Muhammad Ahmad and Adina Humayoon for their support in writing this case study

--

--