Healthcare | Enterprise SaaS
This was a co-op project with a usability validation scope. The outcome numbers come from a live customer feedback session with formal sign-off, not post-ship analytics. The constraint of working within an existing component library and a clinical user base shaped every decision.
Introduction
What is Evoya and why does datagrid filtering matter
Evoya is a Lab Information Management System built by Revvity. Clinical labs use it to track patient specimen records from collection through to results. Every record lives in a datagrid. Lab technicians, nurses and admins return to these datagrids dozens of times a day.
Filtering is how they narrow thousands of records to the ones that matter right now. When it broke down, users had no reliable way to know if they were looking at filtered data or everything. In a clinical environment, that is not a minor inconvenience. It is a trust problem.
The Problem
Several datagrid performance issues reported
Multiple issues were open against the datagrid. On the surface they looked unrelated. Grouping them by the underlying behaviour revealed they all shared the same root: the datagrid gave users no reliable picture of its own current state.
Challenge
Fix four compounding usability failures in a B2B clinical tool, without introducing a single new pattern clinical users would need to learn.
The constraint was the design. Any solution that required retraining had a real cost: clinical staff mid-workflow, a product team absorbing support load, and adoption risk on a platform where trust in the data is non-negotiable.
Design principles
Growing Pains
The old filtering experience.
The original datagrid was functional in isolation. But as the platform grew and user workflows became more complex, the filtering system could not keep up. Users adapted by reloading the page to get back to a known state — a behaviour that showed up across every Jira ticket we reviewed.
Diagnosis
Thematic analysis before any ideation
The default move would have been to fix each Jira ticket in order. I pushed for thematic analysis first. Every open ticket went into FigJam, grouped by the underlying behaviour driving the complaint — not the surface symptom.
A ticket logged as a performance issue turned out to be a filter design problem. The full dataset was loading on open because there were no defaults in place. Thematic analysis gave us a root cause worth solving, not a list of symptoms to patch one by one.
Research
1. Competitive Analysis
I analysed six tools known for handling large datasets: Jira, Tableau, Salesforce, Amazon, Indeed and one additional tool. The goal was a single question — how does each product show users what has been filtered, and how easy does it make changing it.
I included consumer tools alongside enterprise ones deliberately. Finding the same filter visibility pattern across Jira and Amazon meant we could defend our direction as convention, not just preference.
Two patterns emerged clearly from the analysis:
1. The Table First approach loads a meaningful default view and lets users refine from there.
2. The Progressive Search approach requires users to enter criteria before anything loads.
2. Task Analysis
Using the Nielsen Norman Group framework for data table tasks, we mapped what Evoya users actually do in the datagrid and how often.
More than half of all usage is about acting on data already in view. The design needed to optimise for clarity and speed, not search power. Table First was the clear fit for users returning to the same workflows every day.
Design Decisions
Six concepts. Two worth testing. One clear call.
We explored six lo-fi concepts across side panels, drawer filters, inline row controls and modal editors. Each was evaluated on three questions: does it make filter state visible without extra navigation, can a user change a filter in two steps or fewer, and is the difference between reset and clear all immediately obvious.
After a feasibility review with PM and dev, two concepts went into testing.
Decision 1 — Modal vs in-column filtering
The modal was the stronger long-term solution in isolation. But in a B2B clinical tool, adoption cost is a design input, not an afterthought. Every new pattern requires training, and that cost falls on the product team. In-column filtering landed from day one with no onboarding overhead. I documented the modal as a future direction so that decision would not have to be relitigated later.
Decision 2 — Saved Search
Saved Search came up during ideation as a valuable long-term capability. We chose not to include it in this scope.
The in-column redesign solved the immediate trust problem. Adding Saved Search would have extended the timeline and introduced complexity without addressing the root cause. The decision was documented and handed off as a defined future initiative, not a dropped idea.
Final Solution
Introducing in-column filtering with pills
The redesign surfaces filter state inline, within each column header. Active filters appear as removable pills directly in the table. No side panel. No modal. No extra navigation step.
High-Fidelity Prototype
I built the final interactive prototype in Figma covering the full filter workflow end to end. It was used as the live demo during the customer feedback session.
Proprietary content
Final designs cannot be shared due to confidentiality. Screens shown here are low-fidelity wireframes from the design process.
Measuring Success
Testing to see what users could trust
Before the customer validation session, we defined three signals to watch for. We were not testing for preference. We were testing for trust: could users tell what was filtered, change it confidently, and reset without hesitation.
Outcomes
Validated by customers, shipped with no new overhead
The prototype was validated in a live customer feedback session. The design received sign-off and was cleared for handoff to engineering. Implementation was completed within the existing component library with no new components required.
The What Ifs
The directions we explored but did not ship
The final product reflected real constraints like timeline, component library, adoption cost. But two directions had genuine merit and could inform a future iteration
