Emiola Banwo
Bringing performance management to groups - Emiola Banwo.png

Betterworks Groups

Bringing Performance Management to Groups

 

 

The systems we interact with derive purpose from pursuing and achieving goals. These systems can be physical like factories, circuits, and animals, or abstract like policies and even relationships. They all have desired outcomes - the goal of a factory for example, is to build a quality product. The system will follow processes to achieve its goals: convert raw material into parts then assemble those parts to a whole. A metric like Yield, is used to measure, define, and differentiate this kind of a system and can track its performance improvements over time.

An interesting goal seeking systems we are familiar with is us human beings. As a product designer, I follow a defined process with the goal of designing a usable, desirable, and functional digital product. Interestingly, most of us human systems, operate as defined roles within larger systems, organizations, with their own sets of goals. I work at Betterworks, a company with a vision to help people reach their full potential at work. As a system we’ve built a product roadmap and declared a set of key results for how we are going to achieve our short and long-term goals.

Betterworks’ product, a Continuous Performance Management software, is designed to help people define, track, and gain feedback on workplace goals. With limited time and resources in competitive landscapes, large organizations like Walmart and Schneider electric have hailed Betterworks’ features like Goals, Conversations, Feedback that enable managers to see how their direct reports are performing, and help them reach their goals.

 

The Design Task

It’s important to note that organizations are simply systems composed of individuals, each of whom have their own defined roles and goals that overlap and compete. To account for this, large organizations are segmented into groups and departments with shared goals and/or capabilities - a system of systems within a larger system. Systemception if you will.

 Mindblown!

Mindblown!

Currently, the Betterworks suite has limited functionality that respects this kind of group dynamic. To accurately represent the way people work together, my design task (read: goal) was to design a set of features that allowed system administrators to build groups and use those groups to run their company’s Betterworks program.

 

The Process

Research

My team’s process kicked off the project with a problem brief that highlighted the issues faced by Betterworks clients. When deploying Feedback and Conversation cycles, large organizations like Walmart are forced to manually build groups by uploading employee emails as a CSV. This process is very error prone and nearly impossible for enterprise accounts to handle without help from our support team. In addition, once uploaded, the CSV of employees does not change over time as people gain or lose relevancy to the goal of that grouping.

It’s estimated that solving this issue will impact upwards of $1.2 million of Betterworks’ ARR. We also anticipate a significant reduction in support tickets, so system administrators, our target users, will benefit greatly from the ease of usability!

With that motivation and context, we then brainstormed ideas for how group segmentation might work to give us a framework of questions and edges cases. We decided the most straightforward structure for forming groups is through adding individuals by name as well as people who fit certain attributes, like department, location, and/or the date they were provisioned on Betterworks. With these and other attributes, people would automatically fall into and out of groups. How glorious!

With group creation now conceptualized, we also needed to allow admins to edit, clone, and delete a group, as well as view and organize a list of all the groups they’ve created. Most important and obvious of all, an admin should be able to easily use these groups across their Betterworks program and understand the implications of dynamic inclusion and exclusion of group members.

At this point, this list of product requirements we had developed was built on a foundation of assumptions and guesses. Before I proceeded to design each feature, I needed to meet with our Customer Success (CS) department. They work directly with our clients to understand their unique needs and requests, and they would be able to help check the validity of our assumptions. The insights we gained from CS helped us form a knowledge framework that was very integral to this project - taking guesswork and estimation out of our design rationalization.

Ideation and Prototyping

This project had 3 major components (epics) that needed to be designed, each with their own set of smaller stories. The epics included:

  • Group Management
  • HR Admin Scope
  • Conversation and Feedback Participant Selection

Group Management

With our new knowledge framework, I could begin generating product designs to meet requirements. Our framework for Group Segmentation had the following set of stories:

  • Create a group
  • Edit a group
  • View details about a particular group
  • Clone a group
  • Deactivate and reactivate a group - we learned from CS that it was best to deactivate than delete a group.
  • Switch between my list of active and deactivated groups
  • Organize my list of groups by details

Each of these stories were themselves made of a small list of requirements. For each requirement, I sketched a few different possible solutions and analyzed their benefits and drawbacks to determine the most viable solutions to mockup. Different requirement solutions (page elements) came together to tell the above stories (page layout and flows). Combining the best elements into digestible pages required another cycle of exploring the solution space and settling on viable solutions.

‘Create a group’, for example had the following requirements:

  • Give a unique name to a group
  • See the full list of attribute types that I can use to define a group
  • Select attribute type and value
  • View the list of attributes that I have included or excluded from the group
  • Add individual members to the group by name

When exploring the options, selection process, and visibility of attributes I generated the following 3 viable solutions (among many others):

Option 1: An early exploration that met the requirements described above. You could clearly see the attribute options available to you, as well as the ones you’ve selected - displayed as pills that denoted attribute type and value. Selecting attributes required clicking the categories tab then searching for a specific value; there were even suggested departments based on usage history. However, a drawback with this version was that the tabbed menu wasn’t very scalable - it worked for a max of about 5 options. “No go!”

Option 2: Met the requirements and mediated the above drawback by including a global search bar. From this one place you could search for ‘Sales’ directly without having to select department first. There were however, 2 new drawbacks with this solution: Although it’s rather simple to use, it had no other affordances besides accompanying copy for admins to know the full list of attributes possible. The second is that the search field does not work for time based attributes. “Oh, what could have been!”

Option 3: A very simple implementation that met all requirements. Using a series of dropdown menus, the admin can pick the type, and then value for each attribute. The include/exclude behavior, increased flexibility of group creation without difficulty to use and understand like AND/OR operators might have been. The dropdowns also worked for every kind of attribute; for example, picking the ‘Provisioned more than’ attribute type would change the value-selection dropdown to a number input field. We chose, Option 3 because it allowed us to reach our goal. “Winner Winner! Chicken dinner!”

 

HR Admin Scope

In Betterworks, there are 3 different types of administrators permissions each with varying scopes of capabilities: Admin, Super Admins, and HR Admin. The HR Admin in particular has a scope that can be set to a particular department; although this is quite limiting since this isn’t the most accurate assignment for many companies.

The goal here was to give Super Admins more flexibility to define an HR Admin’s scope using both departments and the newly created groups concept. I followed a similar design process as above, but since the page already existed, it was more straightforward. The story, ‘Select Groups and/or departments as a scope for HR Admins’ meant I only had to change the existing selection interface to account for groups. The real challenge here was the child-parent dynamic with departments. At Betterworks, a department like Design falls under the parent-department, Product. If Product is selected, Design should also be selected, and it’s necessary to communicate that to the admin.

The current dropdown respected this, but with the inclusion of groups, this could complicate the interaction. I explored 3 different solutions for HR Admin scope that both included groups as an option as well as respected the child-parent dynamic of departments.

Option 1 featured dual dropdowns that allowed the admin to narrow down to departments or groups and then select within those subsets. Rather straightforward and functional, however this solution didn’t allow both departments AND groups to be selected in an easy way. “Get outta here!”

Both option 2 and 3 fixed the above issue by combining both sets into a single dropdown and delineating which is which. Again, it was important that the child-parent department dynamic be respected - When an admin selected a parent-department, it’s they needed to know why other departments were auto-selected.

Both option 2 and 3 met this requirement but we settled on the third option since it was a component that we have already built somewhere else in the product. This design reduced the engineering cost of this story overall and it fit into the grander epic, HR Admin scope. “Eureka!”

 

Conversations and Feedback Participant Selection

Paraphrasing Ira Glass: Your careers is a journey of going from producing work you know is bad, to producing work that matches your taste. Your taste after all, is the thing that inspired you to set the career goals that you have.

That’s where Betterworks features like Conversations and Feedback come into the picture. Who better to evaluate your progress than the people who work within the same system as you? Within Betterworks, admins are able to deploy conversation cycles with a framework of questions that start a dialogue between managers and their direct reports.

Currently, admins are limited to deploying a cycle to ‘All Employees’ (upwards of 10s of thousands of employees for some companies) or a ‘Custom participation list’ via CSV upload. The story here, ‘Select Groups and/or departments for conversation and feedback cycles’ is similar to one in the ‘HR Admin Scope’ epic above. Since we had already decided on the best solution for this, our task seemed simple enough.

However, what seemed trivial was quite complex, there were several edge cases that had to be considered - like what happens if:

  • A conversation cycle has been deployed to a group but new people get dynamically added to that group
  • A conversation cycle has been deployed to a group but people get dynamically removed from that group

To account for these cases we had to develop strict rules for including or excluding people from conversations. People in the middle of conversations would never be pulled out of them - no need to disrupt the dialogue that has already begun. Employees could join a group at anytime, either due to time passing, new hires, or reorganization in the company. To cover these cases, we put the control in the admin’s hands by making it clear - through copy and a link to the group management page - that they need to change the group’s attributes to prevent unwanted additions to the conversation cycle. Problem solved!

With the goal of empowering system admins with groups, I believe we succeeded! We followed an iterative process and produced designs that met the requirements. This was a fun project with a challenging organizational dynamic. It was a challenge to balance newer designs with business value, and technical costs. There are interesting ideas that we didn’t get to implement in this first iteration, but I’m proud of the developed solution and look forward to gaining feedback from my team and our clients on what needs to be improve. As a reader, you’re also welcome to give your feedback! :)