Teams Automation

Time: Winter 2019 - Spring 2020

Background

Teams are a way of grouping users. They play a key role in Inkling Learning Pathways.

Members of teams have a role: manager, supervisor or learner. Teams allow managers to assign courses, and allow the managers and supervisors to review the members progress of courses.

Currently, team creation and team membership management is done entirely manually, generally by managers “in the field”. Customers have expressed interest in having teams managed by admin users “at HQ”. This is particularly valuable at enterprise scale where organizations wish to enforce standard processes across their many different locations. Unfortunately, the current manual system is infeasible to manage at enterprise scale. In late 2019 I began leading the design work of this project.

Purpose

Teams Automation allows Inkling administrative users to create and manage Learning Pathway teams based on user attributes, to improve admin efficiency at enterprise scale.

The Concept

The main steps to create teams based on user attribute(s) are:

1. Use Inkling's User Attribute Criteria (as used in other product areas) to define the user pool - users who will be split into teams (step 1 in the chart above).

2. Group users(from step 1) into different teams by selecting 1 or more attributes (step 2 in the chart above). For example, selecting attribute "DepartmentID" might create teams "Product", "Sales", "Engineering".

If more than one attribute is selected, the teams are the Cartesian product of those attribute values - but limited to only non-empty teams. Optionally, specifying a set of User Attribute Criteria to define who will be given the Manager and Supervisor roles are encouraged in teams creation process.

Concept Testing

After a few white-boarding sessions with PM and Engineering lead I built an Invision prototype for concept testing with our administrative users. We shared the prototype link with users and asked questions to understand how would they use attribute(s) to group users and define team member roles, while walking them through the creation flow.

The need for teams automation and HQ control.

People preferred, and saw value in teams automation, they expected teams to be dynamic and can be synced automatically. People also love the idea to auto-generate team names by attribute values. Every customer we talked with said they would like the control of field edit permission, they wanted teams edit out of "fear" not "efficiency".

Data quality and the confusion of attribute grouping.

A lot of customers said their data wasn't clean enough for this solution or were just unsure how accurate their data is without taking a closer look. This includes inconsistency in attribute values, which is key given our solution utilizes grouping by attributes approach.

Many customers have mapped their teams to a hierarchy/people reporting structure in other tools. How the group-by feature of automated teams worked wasn’t immediately obvious to customers and took some pretty lengthy explanations about how it works on our part.

We did see some consistency among the customers we talked with how they’d want to organize their teams. Most teams would be location-based, grouping by region/district.

Why we are not exploring the full hierarchy/HRIS integration approach.

The full hierarchy and HRIS integration were alternative approaches that we talked about, as they are familiar to administrative users. We decided against going this route because, while familiar to the HQ admin, we’re not confident that this is actually what they need. We are not trying to create an HR system - we’re creating a tool to allows our users to better assign courses & review course reports. Another reason for staying away from a hierarchy approach is that people’s defined roles may not map perfectly to a role in Inkling.

As we realized some users seemed unsure about their data and truly understand how to use attributes group teams, which is critical to ensure this feature's validity and success, we planed to invite our Design Technologist to help build a working prototype with real customer data for further validation.

Working Prototype & More Research Testings

I next worked closely with Design Technologist to build the working prototype. We decided to use as much existing components as possible for faster build. I iterated the mocks from the concept testing prototype and created mid-level fidelity mocks for her to use. I also added new ideas like Attribute Value Mapping which helps users to clean up their redundant data.

For this round of research testings we sent the working prototype link (with each customer's user data in Inkling's system) 10 minutes prior to research calls and asked one admin participant to create teams during the session. We were able to test the first time user experience as well as understand the users' thinking processes.

The issue of data quality is still there and will probably never go away.

What became apparent in these calls was that there isn’t just the problem of dirty, messy data - something we hope Attribute Value Mapping will help to alleviate. There is also the downside of HQ admins not being familiar with their user data. We noticed some HQ admins didn’t have a strong grasp or understanding of their user data, and consequently might not even be aware of what problems and inconsistencies exist.

Help users be more successful where we can.

What we can do, in light of this complexity, is to help users identify where things may be going wrong. Surfacing relevant feedback to help them troubleshoot is going to be really valuable. This includes:

• Showing the number of teams, managers, supervisors that will be created.
• Allowing HQ Admins to preview every team.
• Identifying what teams will not have any managers.
• Showing a list of users who will not be sorted into a team.

We heard in research, that some HQ Admins want visibility into every team created, particularly the Do-all HQ Admins. As such, we will add the possibility for an HQ admin to select a list of named users who will be added as manager on every Team.

Build for flexibility.

Inkling supports multiple industries and organizations, who will have different ways to organize their teams and different philosophies for managing them. Some will want to have everything managed at HQ, while others trust their field managers. Additionally, our customers need to have tools that allow them to keep up with internal business decisions and changes that will cause them to need to restructure their teams. By creating something that is flexible enough, Inkling can meet the needs of several types of customers.

Ways we are doing this with the first phase of Teams Automation:

• Making the team managers permissions configurable.
• Attribute Value Mapping to account for inconsistencies in their data.
• Allowing for manual edits after creations.
• Adding a new role - “Global Manager/Supervisor” to help Do-all HQ admins have visability into every team create.

Final Design

What's Next

We enabled Teams Automation v1 to 2 customers in May 2020. They were pleased with how easy it was to create teams and already set to go with the rules! The team was glad that they used Attribute Value Mapping to help identify and fix dirty data. We also heard the requests of proving lists of users from the rule creation warning section to help troubleshoot more quicly (which was scoped in v2 launch), as well as the ability to delete individual teams that aren't relevant to their use. The team re-prioritized v2 scope and continued collecting feedback internally and externally.