Improving Workfront's  enrollment experience

Overview

Workfront is in the process of redesigning its entire platform for the first time in 17 years. This redesign is called the New Workfront Experience. As part of this transition, all existing customers must enroll themselves in order to use the New Experience. This is a 6-month journey of how our team took the existing enrollment experience and redesigned it for the New Experience.

Business objectives

Create a way for Workfront Administrators to enroll their users into the New Workfront Experience. Migrate all 350,000+ customers over to the New Experience in the next two years and sunset the classic experience.

Goal

1. Give Administrators the ability to enroll end-users into the New Experience.

2. Give Admins the ability to search by User, Group, or Team.

3. Develop safeguards so enterprise customers aren't able to max out our processing capabilities.

 Our team

My role

As the sole designer on this project, I was responsible for the entire design process from initial discovery all the way to the current release. I assisted our Product Manager in writing the requirements, running discovery and usability research, as well as creating and tracking metrics. I also worked closely with the Engineering team to develop feasible solutions to the problems we had with our processing capabilities.

Outcome

As of today, 15,000+ customers have successfully enrolled in the New Experience during our Alpha and Beta release. As we move into General Availability we expect to see our remaining customers enroll over the next two years.

The enrollment experience that was the result of this project.

Where we started

The process was unique for this project because we had an existing enrollment experience that another designer had done for our Alpha customers to use. This meant that when our team took on the redesign we already had feedback coming in that could help inform the new designs.

The pre-existing design

Discovery research

Before we put anything down on paper our team dove into the current feedback that was left from our customers and set up calls to talk more in-depth about their experiences. This initial set of research wasn’t to test the usability, or any new designs, but to focus on our customer's current problems. 

Findings

After reviewing the results from the research we found that there were major bugs that were making the enrollment process extremely difficult for admins. This, along with unclear buttons and navigation, left users feeling like there was insider knowledge required. These are the key takeaways we used to improve the designs moving forward.

 

1. The "Enrolled" column was not storing the enrolled users, instead, it was clearing all the names every time a new user was enrolled.

​2. Users were having to search for each user to see whether they were enrolled or not.

​3. It was not clear how to get users enrolled once they had been selected.

4. Users did not know if the "Select All" toggle would select all the users in their company, or just the users showing in the filtered list.

5. The search bar looked like it will filter both columns, but it only filters the column that shows all users. 

"I had difficulty enrolling. I felt like there's some insider knowledge required."

The biggest pain-points of the original design

Our first pass

Once we had enough feedback from our customers we made clear goals for the next enrollment experience. What we aimed to do was remove the bugs that were causing confusion, while also making design changes to help improve navigating and understanding the enrollment screen.

The areas that we focused on improving in the first design.

Changes to the initial design

There were 6 main changes that we made to improve the enrollment experience in the first release. These changes were aimed to improve the speed and clarity for Admins since this is one of many things they have to do on a given day.

1. New labels: We re-labeled both columns to better explain what they meant. After testing we found that “All Users” and “Enrolled Users” were clear titles. This also gave admins the ability to search and find the status of any user or filter down the enrolled users to see whom they had already enrolled.

2. Viewing user count: This gave Admins the ability to see how many users were showing in the list so they knew how many users would be selected if they selected all.

3. Search bars: We added a search bar to each column so Admins could easily filter down to find the Users, Teams, or Groups they were looking for.

4. Select all: We brought the select all option into the list so Admins had context to which users they were selecting.

5. Users selected: We added a selected count so Admins would always know how many users they were about to Enroll or Unenroll.

6. Enroll/Unenroll buttton: We brought the Enroll and Unenroll button in context with the selected user so it was easier for them to see how to proceed after selecting someone.

Limitations

Along with the UI changes we made, we also had to make states for the constraints our backend had. Workfront has customers with anywhere from 10–15,000 users so we needed to make sure that the designs could handle even the biggest requests. 

After the Engineers on the team did more research and tests they found 3 limitations that we had to include in the designs.

1. We could not process more than 2,000 requests at a single time. An admin could enroll an entire company (no matter how large), but if they removed even a single user our backend could not process it.

2. We weren’t able to process requests if Admins selected a user, searched for a team or group, then selected more users. They had to select from a single list, enroll the selected users, then search again.

3. Since Teams and Groups come in a range of sizes we had to make it so admins could only select all users for a single group or team at a time. 

Example of what happens when you select the maximum number of users.

Feedback

Workfront was in a Beta for its entire software, so we had a large blue feedback button on the bottom right of all the screens. Our team had a dedicated section so feedback would go directly to the Enrollment team. This allowed us to get feedback directly from the Admins trying to enroll users and allowed us to reach out to those Beta users for follow up conversations. 

The feedback button we used to collect feedback from Admins.

Results

After releasing this design we got a very small amount of feedback compared to what we were getting with the previous experience. In this case, we learned that no feedback was good feedback.

 

After reading through that feedback and following up with System Admins there were some usability improvements that needed to be done but their main pain-point was handling all the requests their team sent to enroll or unenroll users from the New Experience. Some wanted their Group Admins to also have the ability to enroll/unenroll users, while others wanted each user to be able to enroll/unenroll themselves.

"The main pain-point was handling all the requests their teams sent to enroll/unenroll users from the New Experience."

Usability changes discovered during research sessions.

Current designs

After presenting our findings to the Executive team, they decided that they would give Group Admins enrollment access but would hold off on letting all users enroll themselves. This was decided because they wanted to reduce the complexity of the changes to reduce the risk of issues during our General Availability release. 

What we improved with the final designs

What we changed, and why

1. Restyled the header: We redesigned the header to reduce the amount of copy and clarify what this page was for.

2. Enrollment settings: We made a section for enrollment settings so admins are able to control whether they want users to be able to enroll themselves. (This was recently pushed to a later release)

3. Updated search placeholder copy: We updated the placeholder text inside the search bar to make it more clear that Admins could search for Users, Groups, or Teams.

4. Viewing and selected count: We combined the number of users in a list with the number of users selected so Admins didn’t have to look in two places to get all the context needed to use the list.

5. Enroll/Unenroll button: We made adjustments to the button design to make it better align to the grid. We also adjusted the code so that the enrollment buttons were always visible above the fold.

What I learned

The most valuable thing I have taken from this project is to bring in Engineers as soon as possible. While I knew their input was important, this project had technical limitations that I needed tested before I could start designing. If I would have waited to talk to them until the designs were done I would have wasted my time and done double the work for no reason. This also made me appreciate writing in-depth requirements before designing so I know the constraints and limitations of the project.

Next steps

We will continue to track the feedback we get during our General Availability release and improve the experience using that feedback. We will also look to validate self-enrollment by end-users and implement the designs if we see the need.

Final outcome

With the current design, we have successfully enrolled over 15,000 users into the New Experience and expect the rest of our customers to migrate over during the next two years. We have received direct feedback from customers that the changes we have made make it easier for them to get new users into the New Experience, which assists in driving Workfront’s goal of getting all existing customers migrated into the New Experience.

Simplifying Search

A case study about our team's journey of simplifying a search filter with over 120,000 options.

  • LinkedIn - Black Circle
  • Medium icon
  • Twitter - Black Circle

© 2019 by Alex Barker