This covers 3 separate pieces of work I did with different engineering teams at Totaljobs.
Creating a report for internal sales and Customer Services, and later for our recruiter clients.
Badly written job adverts on our sites negatively impact the performance of our client’s advert. This has flow on effects to job seekers on our site looking for relevant adverts; better written ads mean more relevant views and applications.
The business had identified 9 criteria that would improve the performance of ads. Previously teams had created an email alert to users to highlight these, this had a small improvement in users providing correct data.
At the same time, the sales organisation was undergoing a change to a more relationship focussed model with clients. In order to support this change we wanted to enable our Account and Sales teams to do a quick ‘health check’, prior to calling clients and enable them to add value through improving a clients ad performance.
Account Managers & Sales - want a quick way to check a clients live ads and if they can help them by letting clients know about the issues and why they should fix it.
Customer Services - When dealing with clients who’ve contacted them, they are able to get an understanding why an ad may not be performing as expected.
Business users - Be able to access reporting on their jobs adverts and enable their teams to take action.
Through speaking with CS and a small group of clients using the existing emails as a starting point we understood that getting a grasp of how many ads had issues in one space was an issue. Which combined with the data we had led us to consider creating a since source of truth.
User feedback that drove the design was limiting the 9 facets to just the top 3 or 4 most critical types that had the highest impact on ad performance. As well as giving users the option to expand the reporting period, the default report focused on most recently posted ads. This is because amendments to those would have the biggest impact on performance, rather than say a 3 week old ad.
Though inline editing was not able to be implemented for technical reasons, this was highlighted to the business as a key improvement for future work on this report.
This was well received by the CS team, and helped in providing our clients with a more proactive service. For our clients the results were mixed, for recruitment agencies they felt providing more information such as post code of the job would reveal their clients to other recruiters. So they preferred not to add this information to an ad, forgoing more views. Our direct clients (hiring businesses) did appreciate the information to get better job performance, and saw a small increase in these advert quality.
A way for internal stakeholders to understand at a glance if their clients needed some help with job ads.
In order to get a clear picture of how their job adverts were performing our clients needed to get in touch with our customer service team. For our CS team, there was no easy way to see this information on site and they’d generally get back to the client after getting the information.
CS team needing to spend large amount of time collating data and working with clients, as a result of clients not being able to self serve on the site.
I was the sole Product Designer, working with a UX Researcher and sharing facilitation of interviews and user testing sessions. One Product Manager and a team of 4 Engineers.
Pen and Paper, User interviews, Sketch, Invision
Enable users to see at a glance how their ad is performing. Provide context to this data and how they compare to their competitors. Give them clear actions to fix performance where applicable.
Legacy pages in the B2B site, made development expensive, the designs needed to account for this.
Conversations with several people across the customer services and account management teams as well as UX research helped me to capture the more frequent questions users would have. This also helped us build a clearer pictures of the type of users coming to the site/having these questions and who would be most likely to use this sort of report. These were smaller businesses that used our b2b site for posting and managing their account, vs our larger clients who had more complex needs.
Focused on providing clients with basic data about the job. Highlighting work from a previous report showing users gaps in their listing that would increase performance. As well as some data around advert impressions and clicks on apply, shown in a graph.
I tested some of these concepts with the CS team, done remotely with a UX researcher. We took turns to run the interviews and testing of the concepts, using InVision and a video calling client.
Though CS got requests for impressions, bounce rates and clicks through to apply, the feedback on this was that the majority of our users wouldn’t understand these terms. Also we identified other stats that were of more use to recruiters (Ad impressions, click through rate)The graph was the first thing the users saw, and immediately wanted to interact with it, at the expense of missing the other information on the page. This was relocated from the left to the right to give the actionable items priority. Testing these pages after the changes we fared better with users recognising the actions to improve their advert.Enabling users to take action and fix issues without leaving the page was considerably easier than the current alternative, which required CS or the client to navigate to listing, edit the page and repost the advert. The report then updating with the ‘to-do’ list on the report was much easier to perform.
Creating a self serve report to understand credit usage during a contract period.
Our clients needed to either get in touch with our CS team or wait for a monthly report to see their teams credit usage. Some high-level stats were available on site, but no users knew where they were.
We wanted to free up CS capacity and enable some of our clients to self self.
Sole Product Designer working with a UX Researcher, 3 Engineers and Product Manager.
The Researcher and I started out with some conversations with our CS teams, to get an appreciation for the frequency and type of information our clients would ask for. We quickly identified two core types of businesses that regularly sought out this information. One was large complex accounts, who would have monthly reporting custom built. These were typically supplied with commentary and insights from the CS team, merged from multiple data sources, due to legacy contract arrangements.
The second were smaller clients who had smaller teams of recruiters. The wanted to ensure their team was using all credits in the contract period, so wanted to stay on top of usage of our services. It was this group that were our target users as they’d be more likely to self serve, and the work required to address the complex accounts users would’ve been too expensive.
Whilst I looked into potential designs and continued talking with CS and customers, the engineering team looked into the data they could get to display to users.
From an initial workshop they created a basic live report for us to take into some further discussions with users. We decided to take this approach as the users could see their real data. Which would give us a clearer steer on the report and needs of users.
Remote testing done with users by myself and the Researcher (sharing note taking and facilitation of the interviews/testing). I prefer to work closely with Researchers and get involved in these sessions so that I’m able to participate with users directly and it speeds up the whole feedback loop and design iterations.
Focused on providing clients with basic data about the job. Highlighting work from a previous report showing users gaps in their listing that would increase performance. As well as some data around advert impressions and clicks on apply, shown in a graph.
While the dev team made the changes, I worked on another iteration. Whilst some users found the graph intuitive, others did struggle with interpreting it. So I wanted to see if a potential solution could be found that could be easily used by a wider group of users.
Quick testing a few solutions we settled on this final design. A single graph that addressed how many credits remain, showing how many were purchased on the contract. This included a table indicating usage rather than a line graph, a clearer download CTA and clear headers copy (based on how customers feedback). Due to an internal change in the company structure, the delivery of this work was paused. So the report exists as a live page with some of the easier recommended changes I made in the final iteration.
Our smaller clients found this report useful and helped TotalJobs group a little bit towards improving their transparency of contract terms with clients.
