App Job Roles Dashboard

Project date: May 2022.

Role: Lead Product Designer.

As Product Design lead, I was responsible for each stage of the design process, right through to implementation.

Overview

This project was completed for a supply teacher recruitment platform. It aimed to devise an improved process for our users to find and respond to jobs, creating better consistency and a more reliable experience.

Responsibilities

Conducted meetings with stakeholders.
Executed a range of competitor research, focussing on information architecture and semantics of job postings.
Assessed analytics of the current product to understand patterns of engagement and conversion, and reveal potential problems.
Coordinated ideation meetings and design reviews with key stakeholders.
Devised wireframes and prototypes.
Coordinated handover meetings, followed by fidelity checkpoints, to ensure that objectives were being met and to continue to advocate for user needs.

Stakeholders

CEO
CTO
App Developers

Tools used

FigJam
Figma

Problem Statement

Our dashboard failed to provide clear visibility of system status, due to ineffective information architecture. This meant that users were likely to miss job posts and offers as they were not clearly indicated on the screen. The existing dashboard also did not meet the desired consistency guidelines, as the UI was a remnant of our MVP and did not match the rest of the app. Finally, the semantics of job roles were inconsistent between the dashboard and the rest of our communications; we were using language that related to how data was named within the platform, and that wasn't necessarily easy to understand for our users.

Users & Audience

Our primary users were teachers; since they were app users, they would be engaging with our platform on the go. They would need clear visibility of system status and minimal cognitive load because they were likely to be using the app whilst engaging in other activities. As supply teachers, they would have other commitments which would mean that their full attention could not always be granted. They would also need to be able to quickly engage with competitive roles, so as not to lose out to other applicants.

User Empathy

Constraints

Developers

Time

Time cost was an important factor as our developers had a lot of important projects to deliver within the time frame. We could not afford to spend too long iterating on this project before it was released.

Traffic

As a startup, we had a relatively small amount of traffic to our website, and less to our app. This restricted us in terms of user testing, as we would not be able to rely on quantitative data to outline a clear solution in terms of usability. To combat this, we would opt for more qualitative forms of testing.

Being a startup company, we were somewhat constrained by the development resources we had, and had to consider how long the project would take as the time cost was more of a concern to us.

Scope

Changing the semantics of our job roles would have wide-reaching impact to all areas of our platform and communications. We would perform a complete audit of our language. This would be the part of the project with the greatest scope.

We would focus specifically on how different role states were conveyed and how these were organised on the screen.

We would scope any changes to UI and information architecture to the app at first. We had found success in limiting our first round of improvements to the app in the past; as we had fewer users here, we could reduce risk to the business. We would be able to perform usability tests and track changes to conversion post-implementation, and could then decide if we wanted to scope the changes to the website.

Design Process

Understanding

Project briefing. I discussed the project with our core stakeholders, to understand business goals, and to scope out the project.
Competitor research. As a supply recruitment platform, we'd need to ensure that our experience felt native and familiar to the user as they were likely to have engaged with other, similar platforms in the past, or present. I conducted competitor research to understand the semantics that were being used by competitors relating to jobs and their states. I also set out to learn the popular methods of organising these jobs.
Identifying issues and aligning goals. I took screenshots of each step of the existing flow and annotated them, making note of any usability issues. I assessed analytics that we had for app usage, to try and identify any useful metrics such as bounce rate, which could be used to pin down the problem. I discussed the project with our customer-facing staff to see if I could align any of the problems I had spotted with actual insights from our customers. I also understood the language that our staff and our customers were already using to describe our jobs; if we could align our new language with the language of our customers, we could make it more intuitive.

Ideating

Idea generation. I ran a series of ideation meetings, with members of the development team, and any other stakeholders that wanted to participate. We used these sessions to generate ideas and experiences with the current platform and to propose any potential solutions. We also used these sessions to discuss the current semantics, and to synchronise our thoughts on this. We came to the realisation that we were using data-oriented language and that this was not necessarily the right language for our users.
Proposed solutions. We came up with 4 potential solutions which included a range of different language, which we would later test internally within the team. This gave me the foundations for building wireframes and mockups.

Diverging

I then began diverging these ideas in a series of low-fidelity sketches and wireframes using FigJam and Figma. We had already generated 4 potential solutions, so used these to devise our artefacts. I explored a range of methods of organising the jobs, including using tabbed layouts, filters, and an accordion style. These were based off of patterns we had identified in our competitors, as well as patterns we had seen in other apps that could be of use to us. We also explored different methods of sorting through jobs, including a 'swipe to show interest' feature which was modelled off Gmail's mail sorting process. During this process, I conducted design reviews where the proposed solutions were shown to stakeholders. This phase involved a lot of iterating to ensure that we had a strong set of solutions to be able to test with.

We chose to model our experiences off apps that we knew to be native to our user, based on insights we'd received from our customer-facing staff, and from previous user interviews.

I generated a series of wireframes from which I built some high-fidelity mockups to present to our stakeholders.

Testing

Due to the scope of the project, and the constraints we had previously identified, we decided it was best to conduct our testing post-implementation. We focussed on acquiring qualitative feedback from our stakeholders and customer-facing staff prior to development, as they had a good sense of which experiences would align best with our customers' goals. As a startup, many of us had built rapport with the users and so were able to pose these solutions in a casual manner for feedback. From this, we discovered the most appropriate solutions to semantics and information architecture.

Deciding and Developing

We selected our final design based on feedback from our internal employees. It was chosen for its simplicity; it featured a two-tab layout which categorised jobs into 2 intuitively named categories, which were now going to be used platform-wide to refer to jobs. We generated a range of subcategories which were linked to semantically-coloured labels for increased affordance. With more time and resources, we would have ideally tested with our users prior to development. However, we tested the designs for accessibility and legibility, and ensured that UX laws and heuristics were at the core. The designs also featured an increased focus on details that promoted our value proposition as a business.

Final Design

Testing Process

This project is currently in the development phase, however we have outlined clear steps for how we will measure the success of this feature. We aim to track the analytics of this feature after it goes live, to compare whether we saw an increase in the conversion of job applications. We will also measure the speed at which our app users respond to jobs, and accept offers. We also aim to continue to gather qualitative feedback from our users as this remains the most valuable source of information as a business.

Reflections & Next Steps

Our previous projects began by implementing an improved user experience on the mobile app, which reduced risk to our business and allowed us to test the success on real users before we committed the changes platform-wide. Following the implementation of this feature, we intend to bring this new process to our web platform, where it will impact a greater number of teachers.