Chairlift

“A performance management solution that elevates company engagement”

My Role

Design Director (Lead Product Designer)

Objectives

  • Design and build a holistic performance management solution suite of products.

  • To empower companies and HR professionals to better communicate within the performance management processes.

Background

Traditionally, the process of evaluating and organizing performance had been a messy, not-well-liked and stressful part of business operations. One of the primary problems to solve was to help keep all the moving parts of talent management organized, seamless and transparent. In essence, lower the surprises and stress for not only HR professionals, but all employees across the company.

Key problems to solve (workshop sessions)

  • Most Performance Management software focused on 1 to 2 feature sets or solutions, hence not integrated or seamless metrics

  • Assumption that there is low motivation for non-HR professionals to engage and feed data into the systems

  • Getting valuable and actionable data is a challenge

Stakeholder interviews

  1. Establish a clear understanding of all the types of stakeholders and what their perspectives, motivations and goals, challenges, and vision is for the product.

  2. Identify and begin to articulate the actionable goals, tasks, and roadmap.

Stakeholders

  • Executive Team

  • Marketing team

  • Engineering team

  • Design team

  • Subject matter experts (HR professionals)

  • Third party systems (integrations)

  • Potential Customers / End-users

  • Regulatory structures (app stores)

Key stakeholder questions

  1. What’s your role with respect to this product?

  2. Who is this product for?

  3. Problem(s) to solve for?

  4. How will it streamline or improve the current process or facilitate a new process?

  5. What is the product vision? Business goals?

  6. What needs to be added?

  7. Start from scratch or leverage API’s?

  8. What should the application be able to do (ie. functionality)?

  9. What is the monetization or business model?

  10. Are there branding and design guidelines that are need to be followed?

User interviews & personas

  1. Establish a clear understanding of the types of users, their perspectives, motivations, goals, challenges, and needs related to Performance Management processes and solutions.

  2. Identify, articulate and validate ideas, potential features, goals, tasks, and roadmap.

Interviewees

(Assumed potential end-users)

  • HR professionals-primary user

  • Executives

  • Department Heads

  • People Managers

  • Project Managers

  • All other employees

Key interviewee questions

  1. What’s your role/job title at your organization?Do you like HR processes and software for Performance Management?

  2. What don’t you like about HR Performance Management processes and/or software (pain- points)?

  3. Could the following tool sets provide value to you and your organization?

  4. Objectives and Key Results (OKR’s)
    - 360 continuous Feedback
    - Coaching (mentorship)
    - Improved Performance Reviews
    - Reporting, Analytics, and Info Graphics, Recognition board

Questions for Human Resource professionals

  1. What are you trying to get done as part of your daily tasks? (context)

  2. How do you currently do Performance Management in your organization? (workflow)

  3. What could be better about how you do Performance Management? (opportunities)

Key Discoveries

Identified 5 primary roles/user types

  • HR Admin

  • Department Head

  • Reporting Manager (Director level)

  • Team Manager (people manager)

  • Employee (standard user)

Quantitative analytics

  • 72% like the idea of Objectives and Key Results (OKR’s)

  • 53% like the idea of 360 Feedback

  • 76% like the idea of Coaching (mentorship)

  • 65% like the idea of improved Review Cycles

  • 94% like the idea of Reporting, Analytics, and Info Graphics

  • 35% like the idea of a Recognition Board

  • 65% of interviewees that work in HR are not satisfied with the processes or software they use.

“How will this dashboard provide value to me? Daily, weekly, monthly, quarterly?”

Roles, requirements, and permissions matrix

As part of foundational part of the product design and evolution, I created a table and list of customers, feature sets and permissions. This was on-going documentation in collaboration with dev team.

Information architecture and data sharing

I created a “living and breathing” data map to better understand and keep track of all the data points and how it was moving across various feature sets.

Design Challenges

  • Create personalized but scalable dashboards for each user type/role.

  • Data fields and future integrations are unknown

  • Find a balance between enough information without overwhelming the user(s).

  • Need inputs of data to show data...how to gather/show data if we don’t have much data to start with?

Approaches / Solutions

  • Design modular layouts (responsive design) to allow for scalability and customization.

  • Leverage existing data as much as possible from users and other HR systems / API’s.

  • Onboard users with easy and painless experience to input basic data required to build from.

  • Use data visualization information to clearly communicate

User journeys and wireframing

Once the initial data and architecture was laid out based on business and user requirements, I started iterating on wires and user journeys to be evaluated and tested.

Qualitative feedback

  • “Layout 2 feels more like other applications I have used.”

  • “I think layout 3 feels like it would look nice on my phone.”

  • “Could I customize my dashboard a little bit?”

  • “How much would I have to manage this dashboard?“

Quantitative feedback

2 / 11 liked Layout 1

6 / 11 liked Layout 2

3 / 11 liked Layout 3

Usability test and interviews

As wire-framing progressed, we continued to gather feedback and analytics to incorporate into the high-fidelity designs and builds.

Questions

  1. How long does it take the user to understand the dashboard?

  2. Is the user confused?

  3. How long does it take the user to take action(s)?

  4. Does the user ask questions before taking action?

  5. What are the most common questions?

  6. Where do users ask the most questioins?

Observations and feedback

  • Usually takes around 5 seconds to start asking questions.

  • Most users go through tabs first before navigating down the pages…“Whats the data mean and what do I do with it?” Where are the infographics?

  • “How does the Objectives feature work? That sounds interesting...”

Analysis

  • Users understand tabs and primary navigation structure.

  • Data labels, interactions, and call to actions need to be clearer.

  • Layout is perceived as modern and clean.

  • Would like to see more info graphics.

A/B testing and metrics (Google Analytics)

Prior to releases, select clients and users were provided demo accounts for testing and feedback on desktop and mobile builds.

Feedback and analysis

  • More data to read and horizontal scrolling requires more engagement

  • Some users said “to much data, other users said “they need more data” • More tabs and CTA’s result in more clicks/taps

  • Objectives is of high interest to our user base

  • Are high bounce rates a bad thing for our Dashboard?

  • “I left the dashboard in search of more data and reports!”

Design decisions

  • Dig deeper into the amount of clicks and if that is resulting in task completion and value for the user

  • “Objectives“ data and interaction should be explored more and its hierachy on the dashboard

  • Apply these findings to building out Objectives functionality

  • Set target bounce rates based on user types

  • Build out more Reporting and data analytics functionality

Success metrics

  • Focusing on Reporting and Objectives UX resulted in an increased session rate by 8%.

  • Decreased bounce rate from dashboard to 23% during the first week of release (lower then A/B testing).

  • Identified and created design and interaction system for the rest of the feature sets - which was an early goal for dashboard testing.

  • Established 75% TCR after first quarter of product life cycle.

Iterate, improve and ship

While iterating on 1-2 week sprint cycles, designs & builds were spec’d out and shared to collaborate with the dev and sales teams to continue gathering user feedback.

Below: Gmail integration flow - we also worked on how to integrate data into existing application workflows.

More sample deliverables…