Back to home
The platform team’s main goal is to improve the developer experience. This is mainly accomplished through providing centralized, completely customizable, pages and components (providers). Our work allows engineers throughout Indeed to contribute to these providers, easily and safely. This in turn increases velocity and enables rapid experimentation.
Featured
Why do the work
Before adding multi-select filters, job seekers had to run multiple queries in order to see how a search would surface jobs with a certain filter applied. Needless to say, multi-select filters had been a long time ask.
More context
Multiple teams in the past had attempted to implement multi-select filters, but ultimately the tests failed for various reasons. The team however, had just unified the backend that powered search and filtering. This served as a great opportunity to show the company how the new architecture would enable us to more rapidly and successfully run new experiments.
How I started
I first revisited the previous tests. What were the insights, what could we learn from them? I also worked with the engineers to better understand the current capabilities and dependencies of our current filters. In addition I conducted a full audit of all available fitler categories and associated options.
Laying the groundwork opened up a path forward
It was clear from the previous tests that the feature had failed for two main reasons. First, they tried to change everything at once. Second, there were various interaction design patterns that job seekers didn’t fully understand. These insights allowed me to make recommendations to product on how we could strategically approach the project to be more successful.
The challenge
I have implemented a multi-select pattern in the past and went into it thinking it would be pretty straightforward. It turned out to be a bit more complex than anticipated, but because of our approach we were able to limit the amount of complexity.
One of the big challenges I faced was trying to reconcile the mix of AND and OR logic (a constraint of the backend). TBH, there are some edge cases with that logic, that I was not able to solve as well as I would have wanted. Since they consisted of about .004% of total searches, we decided not to split hairs.
The other big challenge was trying to reconcile all the patterns that had been explored by other teams and finding a good way to ensure we led with the right experience off the bat.
For example, a lot of people were pushing to utilize a chip pattern instead of checkboxes. It’s a cool pattern, but since a good majority of our strings are longer and our lists can be longer, I was able to push back against that effectively.
The Outcome
After releasing the feature, we quickly saw wins coming through. Before we had even reached a 50% rollout we were seeing double digit metric increases. When we are dealing with 200m plus users, a 1-2% lift is a good win, but double digits, that is a huge win! We were also able to prove that the recent architecture revamp had done its job and allowed other teams to rapidly scale their experimentation.
Over the years of Indeed's expansion, teams cloned and forked the search input many times. They were all more or less the same, but each had varying styles and behaviors.
This lead to several immediate and down-stream implementation problems. Our team took on the task of consolidating it to one instance, one code-base.
Most of my time was spent auditing and uncovering disparities and working with teams to align. I also worked on updating interaction design patterns and ensuring we were A11y compliant.
We slowly rolled out the unified experience to all relevant platforms. We saw mostly neutral metrics (which is what we wanted) with surprising lifts in job seeker applications.
If a team wanted to make a change to the job card, they would have to develop it at least two separate times (one for mobile and one desktop). The years also brought on several permutations of the job card spanning many products.
The team's goal was to take all those instances and boil it down to one one centralized codebase. My goal was to align teams around a unified design.
I started by cataloguing meta-data display logic and inconsistencies between mobile and desktop. This allowed me to have a holistic view of the job card and make better recommendations on interaction design, display logic and visual design. We were successful in getting alignment with our cross-functional partners and re-launched the job card.
Our work yielded neutral key metrics with some lifts in job clicks and job applies. This was a great win for us. We did no harm to the current experience and we gave teams the ability to quickly test ideas on the job card.
Back to top
