01 Overview

We introduced the concept of user states into JumpClouds user lifecycle management. Users could be set to staged, active, or suspended and admins could immediately move users through the states or schedule state changes for future dates and times. This allowed admins to create and setup user accounts before an employees start date and automate their onboarding into their organization to remove some of the mental load they have on a day to day basis.

02 Goals

Create an Automated Process
Allowing admins to schedule user state changes ahead of time there is less need for them to be manually activating users on their first day to ensure they’re getting access to their accounts. Users seamlessly transition between states and have access to the right resources at the right time.

Onboard Efficiently
Allow admins to onboard user accounts before an employees start date. This creates less friction on admins trying to quickly provide access for a user to their account on their first day.

Understand Customer Pain Points
We did several rounds of discovery and research calls before jumping into solutioning. We wanted to ensure that user states was what admins needed and not another solution.

03 Research

Our first round of research was centered around a prototype walk through created off of learnings from my PM’s initial discovery calls and learnings.

04 The States

Staged
Easily identify users who still need to be onboarded. Preassign all the resources and policies new users will need on their start dates without granting access. The user account will not be provisioned in most cases until the user state is changed to Active. You can activate, suspend, or delete a user from this user state. Staged users are billed as normal users.

Active
Immediately provision a user account and enable a user’s access to assigned resources and policies. You can suspend or delete the user from this user state. Active users are billed as normal users.

Suspended
Revoke a user’s access to assigned JumpCloud resources or prevent a user from accessing resources. You can activate or delete the user from this user state. Suspended users are billed as normal users.

05 User Validation

We made some refinements to the designs based off our learnings from the first round of research. Updates included clearer release messaging, definitions of the user states in product, and a more thorough test of our scheduling functionality.

"Normally I would just jump in because your new features usually have high impact...usually I would enable it and play around...why it can't be undone is my question. I'd like an example of how it's used, benefits, level of set up required..if there is a benefit I would apply it."

06 Design Refinements

The biggest pieces of feedback that we heard in our validation sessions is that the term “new” did not resonate with users as well so we switch back to “staged users” after these sessions.

We had also been discussing with product the idea of opting in and out of turning the new state on. This confused all of our participants and actually made them more hesitant to use the staged feature. Admins like to test and play with features before using it with the rest of the organization. For our later refinements we created a settings page where the creation state of a user could be changed from staged to active. Staged would always be available to every customer, however customers who had created their account before the release of user states would have to go into their settings and change their default creation state. We did this because many admins have probably created automated processes for provisioning/deprovisioning around the existing states in JumpCloud and we didn’t want to accidentally cause friction for them.

07 Continuous Enhancements

We are constantly working to improve the experience around user states. Latest improvements include updates the the individual user page design, UX improvements to user creation, and brainstorms around a user dashboard page.

08 Design Handoffs

To ensure clarity with engineers I worked closely with a feature lead and the PM on all of the designs so that I had a representative amongst the team to help find pages. Figma’s were laid out into user flows, sometimes even broken up into different epics when features called for multiple releases. This helped engineers understand how users got into different states and allowed us to catch any gaps in the experience more quickly.

09 Hackathon

Working with the PM and UI lead from this engineering team we spent a hackathon creating a POC of our proposed user dashboard designs. Below is our finished hack using real endpoints and data.