Case study

Enabling the acknowledgement of performance reviews for a multi-user process

Company
Culture Amp

Year
2023

Project type

Employee engagement, customer retention

Lead design direction, design planning, prepare and facilitate usability testing, iterate flows for implementation

My role

Cross-functional team of 10 including the Product Manager, Tech Lead, Delivery Lead and FE/BE Engineers

Team

Iterating on the proposed user flow after a key point of friction was identified during usability testing. Articulating product design decisions and changes to the team and internal stakeholders. Planning for a phased release approach and measuring success.

Summary

Customer retention focus

Background

Culture Amp is an employee engagement platform that encourages quality conversations and tracks performance progress. The product suite can be accessed by employees across an organisation who may have different levels of access permissions depending on their role or department.

With customer retention as a key focus for the business, my team and I investigated opportunities within our product domain in the performance review space.

Based on our market research and feedback from customers, the ability for employees to acknowledge a performance review was highly requested. It was an opportunity we identified and explored for this project.

Purpose

Closing the loop

The Human Resource administrator (HR admin) of a company is usually responsible for overseeing and managing the performance review process.

For HR admins, the ability for employees to acknowledge their performance reviews is the desired final step of the process to close off a cycle.

Besides record-keeping, this step encourages best practice for managers and their direct reports to have a conversation about the content of the performance review and to discuss actions or next steps.

HR admins wants to have better visibility over task completion, but the process also need to be fair for employees to have an opportunity to provide their input as part of the acknowledgement.

Role and responsibilities

Joining the team

When I joined the team as Senior Product Designer, I paired with the Product Designer on the team at the time for a project handover, to transfer product knowledge and historical context.

From there on, I led product design for the project, sharing work-in-progress with the design team at design reviews and providing regular project updates for internal stakeholders through meetings and in relevant channels.

I worked closely with the Product Manager to plan the tasks and activities for discovery. This was to ensure we were aligned on our approach and all necessary steps were accounted for.

Uncovered during discovery phase

Challenges

Working with constraints

There were known points of friction in the product. We needed to determine what was in and out of scope for the project and what the constraints were.

We needed to take into consideration the as-is product experience, user pain points, what they were accustomed to and how changes to the flows will impact users.

How we handle change management and communications were all factors that needed to be addressed as part of the project.

Multi-user flows

There are steps in the multi-user flows that are dependent on sequential actions by different users. It required a thorough understanding of the user groups and their current experiences in order to provide a well-considered solution.

This added complexity to the scope of the project, therefore strategic planning for design and delivery was crucial to ensure success for launch and subsequent planned releases.

Multi-user flows explored in Figma

Usability testing and validating assumptions

Research

Through usability testing, it was apparent there was a point of friction in the proposed flow which was a blocker for users.

Our assumption was that the ability to control when to enable the feature would provide flexibility for users, but participants considered it to be an unnecessary additional step and expected it to be automated as part of the workflow.

This was a shared sentiment that was consistent even from a small sample of participants.

Feedback from participants invalidated our assumption

From an experience perspective, it was clear that the proposed user flow needed to be revised. After discussing with the Product Manager and sharing the feedback with the team, we decided to pivot our approach and iterated the designs.

Communication and collaboration

Approach

Communication was key throughout the project to ensure all team members and stakeholders were informed and updated on the changes required.

Keeping the team informed during stand-ups about research plans and what assumptions were validated during testing. This was to ensure everyone was aware of potential changes and can provide input and flag any concerns or considerations.

Changes to the designs and flows meant we needed to regroup and sync to make sure the changes and rationale were communicated clearly within the team as well as outwards to stakeholders.

Working with the Delivery Lead, Tech Lead and Engineers to estimate effort and scope the project into slices and release phases. This took several revisions especially with the shift in direction but was much needed to stay on track.

Screen flows showing how the feature would be enabled and what users would see

Measuring success

Planning

Working with the Product Manager, we devised a combined list of success metrics from the business and user experience perspectives. We reviewed the tracking plan with the team detailing why and what we wanted to monitor, and the Tech Lead and Engineers provided their input on how to implement the tracking.

Clear and timely messaging will play a key role to ensure users are notified when their action is required at each point of the process.

External factors such as time of the year (performance reviews usually occur 1-2 times a year) needed to be taken into consideration when measuring success.

Noting down ideas of what to track to discuss with the team

Phased release approach

Planning

As a team we agreed that a phased release approach was appropriate to meet committed timeline, considering the project goals and technical feasibility.

The Product Manager and I collaborated to prioritise what to include for the initial release and what can be implemented in subsequent releases, while working closely with the rest of the team for their technical input. The whole team was involved with end-to-end testing for a thorough review of the flow.

We needed to manage expectations within the cross-functional team, as well as communicate outwards to stakeholders across the business and customer-facing teams.

Monitoring the number of completed acknowledgements as a metric

Monitoring usage and metrics

Outcome

The feature was piloted internally to gather initial feedback across the organisation. We then released the feature and worked closely with our customer-facing teams post-release to monitor the feedback from our customers.

Measuring against the metrics we identified, we assessed how the feature was being used upon release, and continued to monitor usage overtime as performance reviews happen typically 1-2 times a year.

Together with the qualitative customer feedback, we reviewed the usage statistics and discussed how to improve engagement and completion rate. As a result, we identified a number of UX improvements and product enhancements in preparation for prioritisation for future phases.

Capturing customer feedback after initial launch

Post launch

Reflection

This project was a good example of how important usability testing is to validate assumptions. It was made possible by factoring in time for research and testing during the planning phase.

As the team leads, we needed to be aligned on our approach and clear about the project goals and outcomes. We wanted to take the team along on the journey, to keep everyone updated throughout the discovery process which made pivoting and iterating as smooth as possible.

As a result, we were able to validate our designs and assumptions early to resolve potential blockers as part of development rather than a fix after release.