User research, user flows, wireframing, user testing, prototyping, QA.
They're doing a lot of laborious and time-sucking manual tracking. (Using spreadsheets and follow-up emails)
Existing performance review software is either too simple or too ridged (no customization).
Every company's org structure is unique. No one-size-fits-all in terms of reporting lines.
A company could have multiple types of performance reviews, depending on the type of employee. Ex. Full-time vs contract workers
A Linear Experience
Users should move linearly:
The process of creating a performance review had to be step-by-step, which would minimize the chance of getting lost within an array of sections.
Customization is a must:
Different companies will conduct their reviews based on their unique organizational structures, thus it is necessary to allow for customization at every step.
Performance reviews run over the span of months, so a notification system is needed to notify users when an action is required, instead of relying on the admin to manually remind people of deadlines.
I previously assumed that the review creation should be a linear path in order to cut down on the overwhelming nature of the review. However, I discovered that admins actually prefer the opposite.
They prefer to see all the steps in the review creation and then select which section they want to edit. Otherwise it was "like trying to build a puzzle without having any idea of what the final image is suppose to look like".
Since each section is quite involved, this would allow the admin to create the review based on what information they had available.
"[This user flow is] like trying to build a puzzle without having any idea of what the final image is suppose to look like."
-HR Manager during user testing
But we could not build everything for them in the available time.
It was difficult to distill all the wants down into the core necessities and decide what features made it to the our minimal viable product, and what could wait until a later version. There was always someone on my team yelling “scope creep!” or “V2!”.
There were several features that I was so certain needed to be in V1, but they ended up being cut in later iterations due to time constraints on the development cycle. This taught me that there are always ways to simplify, and to never be too attached to any one feature or design element.
During this project, I found myself jumping to conclusions and solutions a lot. If I were to redo this project, I would take more time brainstorming and researching a larger variety of ideas, instead of succumbing to the pressures of a time crunch and jumping so quickly into a solution. I would also spend more time tracking my assumptions and trying to identify and validate them before getting too deep into the solution.
At first, we wanted to give employees and reviewers the ability to do everything in our feature, even facilitating discussion. However, after much brainstorming and many failed designs, my product manager and I realized that allowing reviewers and employees to pass comments and edits back and forth made the design unnecessarily complicated.
We realized that face-to-face time was the most effective way for employees and their reviewers to discuss and learn from performance reviews. After all, performance is a very personal subject matter. So we only gave reviewers the option to approve objectives on the platform, and instead added copy that encouraged employees and reviewers to discuss the review offline, as sometimes the best solution is a tried and true offline solution.