Management Page Filter Design
Overview
Workhuman is a SaaS business that sells recognition programs for other companies. (Colleagues award each other for good job performance or life events. The awarded colleague gets points which can be spent in merchandise or gift cards)
Problem statement
Our Recognition Program Managers needed to action a big amount of awards that were stuck in the approval chain or that for some reason weren't working. As the data was overwhelming filtering was key. But it was complex filtering what was needed as we are talking countries, departments, people, roles, text, award value and hundreds of different pieces of data to take in consideration.
High Priority Solution
This problem needed to be solved since the ones experiencing it were the people in charge of renewing the subscription with us, and the revenue stream was being affected by this, lowering our client retention rate.
Process
Research
Analytics
Qualitative Research
Define
Affinity mapping
Workshop with designers
Workshop with stakeholders
Ideate
Workshop with designers
Workshop with developers
Prototype
Sketching
Low-fi
Hi-fi
Test
Low-fi testIterationLow-fi testIterationHi-fi TestFeature
Research

Current solution Analysis
We used Heap to analyse our usage, and identify a key metric; what pieces of data our users were most interested on?

Discoveries
We discovered that the current solution wasn't fulfilling user needs as we had a high bounce rates.
We could detect the most used actions
We defined a patter of usage
Qualitative research
4 Users (big and small clients)
We wanted to find out what their needs were and what type of usage they give to this page.
Discoveries
1. Users needed to search by Approver, nominator and recipient
2. Users needed a quick way to jump from one search result to another, as they perform several actions at a time
3. They asked for other searching criteria that we couldn't even think of like country or department
4. Some extreme users needed even multiselect fields for people
As our client base and their databases are really different one to another, and we allowed some level of personalisation we needed to address the most flexible solution without losing the focus.
Competitive analysis
We analyse other products in order to identify:
Filtering patterns
Layout behaviours
Design possibilities
Extreme cases
Workshop with Stakeholders
To align every aspect of our team, we ran a workshop with our Stakeholders and Principal Engineers. We as a team created a framework in which at the beginning of each project we would align using the Business Canvas workshop
Business Canvas Workshop
User outcomes we are looking to achieve
Hypotheses
What are the metrics
User benefits and values
Need to learn first
Storyboarding
Easiest most important next steps
Discoveries
This kind of workshop allow us to discover possible constrains, points of view from different parts of the team and allocate a problem that we would experience in the future depending on the execution.

Affinity mapping
We put together all extracted data in order to understand it better.

Workshop with designers
We sat together and started ideating.
Some methodologies we used:
1. User Flows
2. User map
3. Storyboarding
Discoveries
This really helped us to sort out our ideas and clarify on our expectations. We were overengineering the solution in our minds. but it was identified at a really early stage which these things are for.

Crazy 8s Workshop with developers
To understand the possible architecture and structure nothing better than aligning with developers in your team. I facilitated a Crazy 8s workshop to see what their ideas were.
Constrains
It was hard for us to address the correct solution, Why? An award is sent by someone, approved by someone and received by someone. The problem was that we needed to allow a way to search for each role, in a multi-select fashion and by name, employee number and email. This was a huge problem we needed to solve. Our first approach was a search fill to look for a person and then a drawer where you would select the role.
Sketching
Low-fi
Putting ideas in Low-fi makes it really easy to share with people, for early stages I like keeping things simple to focus on the experience and not on the UI.
Hi-fi Design
We decided that drawers were a good solution for this filtering system and our constraints. So we started testing it.
Test round 1
6 Users
Moderated remote testing
KPIs: SUS scores, task achieved
Results
Very poor task success for Task 1
Splitting the filters into two sections seems to confuse users. Their mental model expects all the filters to be together. This is based on the fact 2 users tried to return to the initial search criteria page.
Also, the current design does not support the use case for investigating reciprocal giving.
SUS SCORE: 81.25
Iteration
We did a new iteration to include a more flexible approach, as some of our use cases weren't fulfilled. We iterated from using a search field and filters to create a "heap" or "jira" approach where we would allow the user custom their search criteria by adding or extracting filters. This way it is not just
1000 Explorations later….
Test round 2
4 Users
Moderated remote testing
KPIs: SUS scores, task achieved
Results
Generally good feedback. “No, no it seems all very straight forward, self-explanatory, so I wouldn’t foresee any kind of issues there at all, it’s all very straight forward and easy to follow”
SUS SCORE: 95
Iteration
Some little touches and tweaks and our solution was ready to land…
Hi-fi Prototype
Once we have gone through all the steps and the experience got approved it is time to set a hi-fi prototype to test and iterate.

Designs System Contributions
As we were designing based on a Design System we needed to approach all our decisions based on the available components. Due to a specific need, we needed to contribute with the creation of components for the design system taking in consideration use cases, scenarios and design system constrains.
Results and KPIs
Product area estimated revenue increase by 2023
+36%
NPS Metric
+3 pts
SUS Score
95
There is nothing more wicked than filters, specially when you have big chunks of information and a hundred of use cases and scenarios.
One thing that makes filtering specially difficult is that there are well established patters out there, and they might not fit your needs, so you need to address those, if not users won't understand flows.
The more we tried to cover the more difficult it was to deliver something comprehensible enough, the more localised something it is the simpler it is.