My role
Solo product designer throughout the end-to-end process: analytics, design, prototyping, usability testing, support through development for desktop web application
Team
Product Manager
Product Owner
The development team consist of 15 engineers
Product Owner
The development team consist of 15 engineers
Problem definition
When a job offer is done to a prospective employee in the HR system, the HR recruiter among other inputs has to select (within a company property directory) the company office where the new employee will be working. HR recruiters complained that the process was too complicated and took too much time to complete.
First, I walked myself through the current process to understand it and prepare for the user interview
1. the property directory was a list of addresses of office buildings arranged into a hierarchical tree of folders just like a file directory. To find the right address the user had to proceed by selecting first the region then the city and then the street & number.
2. the users often did not have complete and accurate information about the office address as this was provided through an email from the hiring manager who did not have access to the property directory system. The information the users had was often approximate or wrong.
3. the address information within the directory was not standardised according to a map database but had been created over time as users were making new entries. So it had a lot of errors.
4. furthermore, a lot of irrelevant information about the buildings was presented on the selection screens, like floors, corridors, restrooms etc.
5. therefore the process was cumbersome for the recruiters and often resulted in errors.
User interview
I prepared the question list for the user interview to identify the context and frequency of use, how they get the information they need to find and the major difficulties that they face. Also to investigate if there is any other way to solve the problem.
The interviews revealed some problems common to all users:
Searching for the solution
It appeared that the problem was not only in our design but also technical on the side of the property directory owner as the database was originally designed for architects and building engineers.
It was clear that to improve the process we needed to add an address search field like in Google maps or similar so that users could type address information that they already have instead of clicking on trees and branches with unknown names and hierarchies.
This could work well provided that the property directory was indexed according to the following Office Building fields: city, street, building number, room number.
Together we the development team we verified with the directory owner that he could upgrade the directory and provide the necessary indexes so we then had a feasible solution.
Prototyping and testing
Before going to end-users I created a barebones prototype for internal testing. After approval by the development team, I put together a test group of end-users to ensure not only the feature is feasible but also it solves the pain.
Based on feedback from colleagues and users, we didn't have any huge problem areas but rather a few minor issues in the interface. After a few more tweaks and iterations, I established the final hi-fidelity prototype and it was ready for development!
QA and design review
I needed to make sure the feature we built was according to specs in terms of functionality and usability. Since Figma prototype testing was not possible with real data, we had to test the most complicated user flows. To ensure full testing I collected the most difficult cases by end-users for QA.
