A Review of the WorkBC Job Search Page
Today we’ll be looking at the WorkBC Job search experience. WorkBC hosts job postings from employers on a board that is accessible from the BC government website’s home page. From the job search page, British Columbians who are looking for work can use one of the search engine’s many filters to narrow down results by location, salary, industry, education level required, and other criteria. Like any good search experience, users can sort their results on a number of fields including job title (A-Z), date posted, and salary.
When I was using the service, my first inclination was to use the keyword search to look for roles. Anyone who uses keyword search will immediately notice how slow it is. I measured an average of 28 seconds for 5 different keyword search queries. While the search is underway, it is impossible to know whether or not the system is querying besides the loading animation in the browser tab. This lack of responsiveness may cause the user to click the ‘find jobs’ button multiple times, and according to the dev tools network tab, each click causes the query to restart.
Keyword search does not handle spelling mistakes. If a user misspells ‘mechanic’ as ‘mecanic’ search will return zero results. This would not be such a problem if the time between a misspelling and the results were shorter. Upon learning that the query was unsuccessful, a user could refine their query and fix the typo. Refining a search query is something we do all the time with even the best search engines and is all a part of seeking relevant results.
Luckily, the empty state for search results provides useful advice for query refinemnt.
The good news is that filter-based search (although they are technically facets) can be between ten and a hundred times, faster than a keyword search. With filter search, users may select a number of filters and apply them to the whole job database, narrowing results to those that match the criteria. The filters and subfilters live in a bar just above the search results. After surfacing results, users can easily remove sub-filters to broaden their search or apply new filters for fast re-queries.
The filters are a little overwhelming, It feels like a lot of information to stack into what already feels like an encumbered upper section. But given the poor performance of the search bar, it is easy to understand why having control over so many criteria is a good idea. The performance gap should also make us wonder why keyword search is positioned above the filters, or, why keyword search feels like the place to begin a search for a new user.
The search results are well balanced and allow searchers to quickly parse out appealing roles by providing information on job title, employer, salary, location, and posting expiry date,
There is also a map search that allows users to search geographically for roles by dragging through a map. The map search begins from a totally zoomed-out position, and after zooming into BC users can see roles in the region represented as little bubbles. Only after drilling into individual jobs (bubbles with a 1 in them) are you able to see what the roll is. It doesn’t work as a filter on search results either, the results do not update as you scroll into a new region, they remain static based on your last filter or keyword search. That is to say, the map search and the search engine results page are 2 different systems that don’t interact or respond to one another.
Recommendations:
If I were rebuilding this product, I would start by considering the what the job to be done is. Is a keyword oriented search really the best way to help people find jobs given techncial constraints that impact perfromarnce? Not likley. I would investigate the viablility of a simple job preferences form that operates on the same logic as the filters, at the end of the form I would ask the user if they would like to recieve emails about roles that match their preferences. This alert would not require them to create an account, only to provide their email. Following the submission of the form, users would land on the search results page with all filters and facets positioned in a sticky sidebar, allowing for easy search refinemnt no matter where they are on the page. I would also remove the keyword search bar to avoid awful user experiences, and scrap the map search unless we could get it to search results as the user scrolled (see AirBnB map search)
