CASE STUDY
Data Overload
A User Experience Study
Use of Accordions to Create a Clean Interface for Complex, High-Volume Data
Overview
The presentation of records information – for maximum user relevance and system efficiency – is a common hurdle for industries or business models that run on complex, data-heavy transactions. Organizations often, reflexively, assume that a client prefers more data points and more layers of detail than actually is the case.
Does the client truly desire deep-dive familiarity with the ingredients and steps required to make the sausage? For example, does a customer want to know absolutely everything about the processes and data behind an Amazon order?
• What shelf housed the item?
• What was the warehouse temperature?
• Which employee pulled the order? Was he/she left- or right-handed?
• Which conveyor transported the order from warehouse to shipping?
• How was the best packaging option selected?
This case presents a UI-based solution to navigate large quantities of records when a business defaults to cataloguing robust, occasionally irrelevant data detail.
Problem
Simply slimming down the types of information or cutting back volume of data, is often not an option. The detail that is relevant for a customer might differ from what other types of system users require. The most pressing problem becomes how the UI is presented. In this scenario, a blue hyperlink connected to a new page that presented basic order information. Users clicked on additional blue hyperlinks to open more windows. As a result, the act of exploring a single order could create a minimum of three new web pages.
A work sketch captures the UI weakness. The links open new pages, and those pages send users to other pages.
Collaborative Goal
The optimal UI outcome is a terminus where the user can reach an order and inspect its details by accessing and staying on a single page. Without the time, resources and authority to audit content – presumably with an eye toward eliminating data or restructuring hierarchy – it was necessary for the development team to retain the original structure of a three-level parent-child relationship
Charting the order structure and the parent-child hierarchy demonstrates that an order can be very complex.
Solution
Working with space limitation on page the orders are stacked creating a very long work order.
Under the original scenario, clicking an order line item triggered sub-items that opened in new pages, making it easy to lose the context for the order. The approach also detracted from user experience because most users don’t close windows as they progress through a record. When the interaction involves looking up multiple orders, the user can become confused about which line item relates to which order.
Moving all order information to a single page was the optimal solution. Utilizing accordions became the most effective technique to dive deeper into the order sub-items yet still retain the overall context for the order. The accordion UI structure also enables the user to view multiple items at one time or hide items that are not necessary to see.location in a data stack.
Simple accordions package complex, high-volume data records for presentation in single windows using expandable and collapsible line items.
Outcome
The UX improvement was dramatic. Users no longer open a new page for every order they select. Instead, the entire order experience lives on a single page. Loading orders into a spreadsheet allows users to sort and filter. The ability to maximize or minimize an accordion enables users to compare orders and simultaneously select individual line times they want to research.
In addition, an unforeseen (but positive) issue occurred on the system backend. The new UI popularity required more servers to keep up with resulting user demand. Increased demand likely indicates that the instability of the old method influenced users to avoid looking up orders. By improving UI friendliness, users began to benefit from the service as intended.
Final Thoughts
It is advisable that an organization study user preferences in order to validate the development team premise that typical users don’t require the high volume and multilayer depth of transaction detail that companies assume. In this case, user studies during the original process, and involvement of the UI development team early on, could have helped predict the UI weaknesses.