Designing a new component — Turning table data into a singular element
The process from understanding the problem to the conception of a new UI component
TL;DR: This article tells the design process I faced, alongside the design team, about turning data shown in a table into a structured card component, giving it a much needed “unit identity”. Instead of being just spread data in columns and rows, we aimed to provide relevant information and enable precise decision making.
Displaying information can get hard. We often have too much data, and it can easily get cluttered. On top of that, information often guides us through decision making, so showing the right data in the right time with a functioning way to compare it can help the user with proposed tasks and reduce busywork.
So, what should we do when we want to improve the way information is displayed?
1. The problem
Usually, we use tables to convey information. It’s an acknowledged and easy way to see and compare different data, which can give meaning to information that doesn’t tell much when standing alone. Using and consuming spreadsheets has become somewhat the norm when dealing with a lot of data, and designing an alternative could pretty much backfire.
Why would the user go for whatever solution you designed instead of an app he’s familiar and have been using for years, like Excel?
But since tables and spreadsheets are so versatile, they are also pretty much generic. Sometimes information can get cluttered, and If we want the user to take action out of the information that is provided, the data needs to be precise and easily comparable. So the problem was: “how do we design an alternative way to reveal meaningful information, allowing the user to take one or more actions in a easier way than he would with a structured table?”
2. Studying the would-be component
This problem emerged when we (the design team) were redesigning and combining 3 old company products into a single platform. The company works as a LegalTech, and the information displayed were from all kinds of judicial and administrative disputes, coming from many sources (hence the 3 products). Those different disputes (or conflicts, as we liked to call them) would need to be distributed in lists, each with it’s own context, as the platform goal was dispute resolution through non-judicial means (list A would have conflicts to be resolved with negotiation, list B is resolution through mediation, and so on). Since each type of resolution has a different flow, each list could have different actions, different aspects to stay up do date, etc.
So, we needed a way to display different information and allow different actions depending on the subject and source. Basically, we needed a generic enough component that could accommodate that information, but still specific to our users needs while agreeing with the company’s business rules.
Our focus was in understanding a way to relay insightful information, providing the necessary data to whatever specific action the user needed to take. With that said, that data could pretty much change depending on the type, origin and stage of a conflict (along with many other factors). So, we couldn’t focus on the data itself, but in a way to display any kind of data.
The first step taken was to understand what kind of information was available to be shown within the component, it’s similarities and diferences, and what was really needed to in evidence.
What’s the type of information that deals with dates? Locations? Is there specifics IDs? What kind and range of data is tied to a person, or to the conflict itself?
We studied and crossed data coming from the 3 merging products’, from future additions planed to inhabit the platform in the near future, alongside feedback from sales and costumer experience teams. To gather this feedback, we created a direct channel with CS, CX and product teams. Therefore, we were able to achieve a clearer view, to understand what was important and what acted simply as clutter.
The following step was to understand how that information could be shown. This definitely wasn’t the first time this kind of problem emerged, so a good benchmark was in place. Gathering examples of solutions created to deal with this kind of situation was the goal. This step was pretty much an “open study”, since we observed a lot of different approaches to this matter, coming from all kinds of sources. We looked not only on how to display information, but also how to approach actions taken directly from the table view.
About 10 systems/apps composed this benchmark, and were studied in detail. All finds and inquiries were consolidated in a Figma board, so it had an easy access and it could be shared with the whole product team.
The study was rich, showing us the paths we could take to design our component. We came to understand that tables aren’t that strict, and it’s logic of columns and rows could be translated in many different ways.
The way was laid out to us, so we went to the drawing board.
3. Designing the component
With all the necessary knowledge gathered, we started to conceptualize the component. First, we laid out what would need to be shown so it could work as we intended:
- An ID — A singular identifier that would own all the data pertinent to that conflict.
- Access — A way to access the full range of data about a single conflict (the “details page”).
- Status — A way to show the different stages of the conflict’s lifecycle.
- Select — A way to select/unselect different conflicts in a list.
- Markers — Custom markers that the user could add to help him with filters and organization.
- Actions — A way to store all the different tasks/actions one could do with (a single or with selected) conflicts.
- Data — And finally, the pertinent data that gives reason to all above.
All those elements in unison would constitute as a conflict-component.
After some time prototyping, we understood that the best way to portray it was to use a card-like component, with structured elements housed inside it. With the components distributed in lists, instead of rows and columns, data needing more context would have labels, and anything else that could work on it’s own would be shown in a particular way, creating a defined hierarchy.
Having the component to be a card gave us the ability to structure the data, giving it a much needed identity as a single element, since being singular gives each component it’s own context. In a table, they would all inhabit the same container.
About the relevant data, through our past study we understood that no more than 8 instances would be enough, besides what was already accounted for (like ID, status, etc), allowing the user precise decision making and/or just to stay up to date. All extra data could be found in the conflict’s details page.
We studied and prototyped it a lot, settling in a version that was both feasible and cherished.
4. The component now realized
The final version of the component was a card divided in two sections: header and body.
Within it’s header, we encased the information that could stand on it’s on (without the need of labels) and would help identify the component as a single unit. Those being: the Entity ID which also was a link to the conflict’s details page; the conflict’s current status; user created markers (now as tags); and a icon-button with a menu containing all the options/actions which could be applied to a single or all selected components. Selecting it was achievable through a checkbox placed to the left of the card.
In it’s body, we settled in only 4 instances of labelled data (which we started to call “proprieties”), creating a leaner card. Furthermore, anytime the user needed extra information, clicking the component expands it, revealing additional 4 proprieties. By giving it this feature, we reduced visual noise without sacrificing lesser relevant data.
Also the components in a list:
5. Results and implementation
After it was settled, the conflict-component kickstarted our Design System, being the first one to be implemented. It was kind the milestone for us.
We managed to present it to the whole company, gathering positive feedback from peers and stakeholders along the way. While dealing with the conflict’s lists we presented, people no longer had trouble discerning from one instance to another, a recurring problem when dealing with the old tables.
We also tested with users through a guided presentation, without facing any problems. Still, since the platform was a big project, it hasn’t been launched yet, not enabling us to test it within real life scenarios.
By the end of it, the whole product team was happy with the results, understanding the evolution we achieved when presenting one of the most important elements of our products. Dealing with conflicts is one of the centerpieces of the whole userflow, and having a clear and streamlined way to manage them was a achieved success.
