E&Y’s Data Tables
Context
There were multiple data table types used across different teams, on different frameworks, all within the same company. The goal was to provide a consolidated solution, ensuring consistency, people friendly and simple enough to use.
Biggest Problem
While there was a an existing internal design system in place, it was too basic. Majority of the designers struggled because there were a multitude of use-cases and with their own requirements that each of the teams needed. This was the biggest problem because this is what EY employees used to make important decisions.
Project Goals:
- Create reusable table components for designers to use across multiple projects within the E&Y organization.
- Table design recommendation needed a consistent look with function consistently across different frameworks
Challenges:
- Satisfying multiple use-cases across the diversified company.
- Components needed to work seamlessly across varying frameworks.
- Reuse as much as of the existing design system and only introduce progressive components when necessary.
- Create Sketch components from existing markup and CSS.
Opportunities:
- Develop a concise experience for those interacting with important decision making content.
- Evangelize the overall experience across multiple teams and frameworks.
- Offer new ideas the internal design team could adopt into their system.
Team + My Responsibilities:
My team consistent of four designers and two project managers. My responsibilities were to:
- Develop reusable Sketch components from existing product markup and CSS for designers to use in their layouts.
- Educated the team of designers on how to use tools like Abstract and Zeplin for collaboration, consistency and handoff.
- Provide strong recommendations based on my findings.
- Developer handoff.
Insights + Research:
- Products were built on different frameworks including , React and Angular.
- We were going to be working with different dev teams both in-house and offshore.
My Design Process:
Having absorbed the provided research and relevant screens, I interviewed the designers and BA’s. I asked them to walk me through their current problems and known issues. I noted the patterned pain points and how we could redesign solutions to support the multiple use cases.
Exploring Solutions & Considerations:
When working with smaller design teams, I encourage a scrappy approach and gain inspiration by looking at how other organizations have solved similar problems.
I also look at everyday tools used during work (i.e. Outlook, Slack, Google Docs etc). I look for those interactions that we’re use to and require little effort when completing tasks and see how they can be applied into the problems I’m trying to solve.
Basic Design Principles
After concluding my research, I came up with a couple of basic design principles to follow when making design decisions:
- Reduce distractions
- Increase response time
- Increase overall usability and satisfaction
The Solution:
- Reduced the noice and distraction from the decision-making context.
- Decision making context: Highlighting table data to increase response time.
I broke up the toolbar even further.
- Actions that affects how data is viewed.
- Actions that actually affect the data.
Legacy Actions:
There were some legacy actions that I decided to tuck away to help highlight the most common used ones.
Filters:
Originally the filters were buried within the search field. I felt there could be a simpler solution and decided to separated the two.
Each dropdown filter required you to apply the selected. I felt this could all be applied at once and also kept all actions (including “Clear”) in the same area.
- Text updates to show how many filters are applied.
View:
We had a lot of requests from customers about being able to view only certain columns or expand certain branch level. After speaking with them and the team, I decided to add this functionality but keep it separate from “Filters” as we felt customer sometimes didn’t want to necessarily filter data but just control how they viewed it.
- Text updates to show how many filters are applied.
Export/Import:
Whether you were exporting the data for Excel or sending it to another part of the platform for review or submission, I felt they both fell under the “Export” bucket. The current design had these two actions far apart from each other.
I decided to introduce a split button that is common in the enterprise world but did not currently exist in the pattern library. On the left side of the button, I choose an “Import/Export” icon to communicate that this button as a whole could do both. The left side was labeled “Export” because when clicking on that side, the exporting options would appear.
I added the most used settings as default options to increase response time. There were requirements to export only the visible data and so those fit nicely within the settings modal. I reintroduced the yellow primary action buttons here because this is where the attention is at this decision making time.
The right side dropdown gave a lot more options to answer for all the different types of requests we were getting from the customers. I organized these into two buckets “Export” and “Import”.
Data Changing Actions:
I used the bottom part of the tool bar to hold all the actions that actually affected the data as it was the closest to the table.
- Add, New, Create.
We had also gotten request help speed up the process by making bulk actions. The existing design actually allowed this but it was more known to power users and was something you had to discover. Having clear actions out in the open would help the novice employees.
- Single actions, including fresh, delete etc.
- Bulk actions for multiple rows selected.
Learnings + Insights
Designs were presented to the internal E&Y design team. I explained all the different requirements and use cases that we were trying to solve for. The team was very receptive and loved the overall thought process. They are currently in the process of adopting some of our solutions into their system.
