Ethr Design System — Creating Complex Graphs (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
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.
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.
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