Job finder application

Overview

This case took place at an employment agency. The internal users at the agency used a desktop application to help clients to look for jobs. The application was developed in the 90s and had not been redesigned since then because of the technical complexity behind.

Windows 95 fyller 25 år – ett arv som lever vidare än idag
It looked a lot like this.

The goal

But now it was time! The agency wanted to get rid of that old desktop application and turn it into a modern user friendly web application.


The research

For starters I really wanted to know what the users struggled with the most. So I went really open minded into my research. Yeah, the user interface was ugly, but that doesn’t necessarily mean that it’s an user problem.

Observation study
I have to give all the credit to the UX-lead that worked there at that time for choosing this method.

We were a group of UX-designers traveling around Sweden visiting all the offices of this job agency. We followed several users and looked how they worked during several days. Everything was very well documented in an excel document. We knew which applications they used, how long time things took and which common problems the users had.



Interviews
The observation study was more of a quantitive method. We had a lot of data, a lot of problems, but we didn’t really know why or how critical those problems really were. So I decided to do some interviews before starting to sketch.

I did nine semi-structured interviews with the agents at the office in Stockholm. I wanted the users to talk openly about the problems with the application, but I wanted them to focus on the process of finding jobs for clients (which was only one of their many daily tasks), since that was the part that we were going to redesign.

These were the nine interview persons for that session.

Other methods
It’s funny, because you cannot imagine that a lot of the meetings and coffee talks that you have in your everyday as a ux-designer are actually part of this research phase.

In this job I worked close to people that used to work as agents and I got a lot of valuable information from them. I also used surveys that were done by my UX-colleagues and other material that were at hand.

The findings

The process of looking for jobs
So the goal of the agents was to find a fitting job suggestion for the clients. They selected a client, did a search, selected a couple of interesting jobs, reviewed them and sent them. Then they went for the next client and did the same.

Not enough information about the client
So what were the biggest user problems? I did my best to visualize those in a customer journey. Apparently the biggest issue was that the agents didn’t have enough information in the system about the clients to find a fitting job (that’s the first black cloud in the picture below). I learned that this was a well known issue that was very hard to solve technically.

Jumping between windows
The users also struggled when they had a search result, and then hey had to go back to read the client information, see if it was a match, change the search parameters, and search again. This generated a lot of jumping between windows and this was, according to our quantitive data from the research study, what took the most time for the users when finding jobs for the clients (it took about 5 minutes to send a job suggestion to a client).


Customer journey

Ideation and sketching

Turning the process into a web application interface
Since the goal of the agency was to develop a web application and the users struggled with the jumping between windows, this was the main focus when I started to sketch. It was basically trying to transform the current flow into a flow that would fit a web application interface. I did a user flow just to see it in front of me.

User flow


Solving the jumpling-between-windows-problem
The user had the need to compare the client information with the jobs that the search result generated (this was what caused a lot of jumping in the desktop application) so I decided pretty fast that the information about the client and the search result had to be beside each other.

The users didn’t only go back to read information about the client, they also went back to do changes in their search. This process had to be more flexible. So therefore, the search parameters had to be there editable all the time and as the user changed the parameters, it changed the result.

Lo-fi sketch

Selecting jobs to read later
I noticed that the behavior of the agents was to do a search, select interesting jobs and then read them, select the best ones and send them to the clients.

I wanted the design to fit this behavior and therefore I included a list that the jobs could be added to. The user selects interesting jobs, changes the search parameters, select more interesting jobs and after that they’re ready to be reviewed.

Hi-fi sketch

User testing and validation

Instant feedback
The user testing was more of an ongoing process all the time. I had contact with users almost everyday, sent sketches and got feedback. The users were very involved in the design process. It was a very informal and iterative way of work.

User tests
Other times I conducted more formal user tests, to make sure a whole flow actually worked in a real scenario. Doing user tests helped us discover the concept of the list (which was not clear in the beginning). It made us change the label of the button to ”add to list” instead of just ”add”.

These user tests showed also eventually that the process of finding a job for a client went from taking 5 minutes (in the old desktop application) to 1 minute (in the prototype). This was all because the user didn’t have to jump between windows to read and edit information.

Design studios
We involved the users so much that they were involved in the designing of the upcoming features of the application. We took for example the problem of not having enough information of the client and asked the users to design that for us. It was an amazing experience!

So what was the effect?

Well, I really don’t know. We were about to release the application when I had to leave the project. But the prototype showed that the new application really could save time. The users were also very happy and excited to see the application they had designed up and running.

But the biggest and most important thing that we achieved was that we included everyone in the design process and increased the knowledge about design thinking within the organization.