Offline Jobs 2.0

Overview

Role

Product Design, User Research

Context

Offline Jobs is an Intuit Identity capability that allows services and applications to run behind the scenes without an “online” user. They act on a user’s or realm’s behalf without needing them to be signed in, enabling a smoother and more efficient experience for end users. Offline Jobs are set up and configured through a self-serve flow in Developer Portal.

Example use case: A user might want a report on their finances to be run every evening when they’re already logged off. Offline Jobs enables this to happen securely even when the user isn’t present.


In Q2 of FY23, Offline Jobs needed to migrate to Identity 2.0 as part of a broader tech stack migration that was slated to be complete by end of year. This resulted in changes to both the backend architecture and front-facing user experience.

Why is this important?

  • Offline Jobs assets make up 55% of all assets that need to be migrated to ID 2.0, making it highly impactful on the overall migration speed and ID 2.0 adoption rate

  • 17% of all Identity support tickets were related to Offline Jobs, sometimes taking users 3+ days to onboard to 2.0

  • Enabling smooth self-serve experiences allows developers to work more efficiently, and spend less time on waiting for answers. This also reduces the time the support team needs to spend on tickets

  • The smoother Identity capabilities like Offline Jobs work, the smoother regular BU operations can go, enabling developers to spend their time on other customer facing features

Problem to solve for

Offline Jobs 2.0 had not gone through any user testing, and was at risk of confusing users due to the addition of new terminology, new use cases, and a modified UI flow. How might we streamline the migration between 1.0 to 2.0 and ensure that we’re enabling self-serve as much as we can?

Solution

Among the many design changes made following user research, 3 of the most important ones were:

  1. Making purpose descriptions visible in the search table

  2. Providing typeahead dropdown validation for permissions

  3. Redesigning the review screen so that users can quickly jump back to edit sections.

These changes allowed users to discover purposes and permissions more easily, and validate their entries before submitting for review.

Constraints

  • Design: Offline Jobs is an Identity capability located within the Developer Portal framework, making the DevPortal design team a core stakeholder in this project. It was important that we aligned our experience with DevPortal’s standards, and received approval from their team before finalizing our changes.


Research

To ensure that developers would have a smooth experience using Offline Jobs 2.0, I worked with our research partner and PM to create a research plan. We tested the flow with 10 internal users, including both new users and individuals who had used Offline Jobs 1.0 in the past.

Research goals

  • Discover pain points on two fronts:

    • Any migration-related issues

    • Any gaps in the MVP experience and documentation

  • Come out with list of prioritized improvements for post-MVP roadmap planning

Research Findings

Disconnect between 1.0 and 2.0: 1.0 users didn’t understand how the old use cases mapped to the new ones in 2.0, and documentation wasn’t sufficient to answer their questions

  • Suggestion: OLT 2.0 needs a separate documentation page that can help both old and new users understand what use cases will match their needs.


Low discoverability for essential information: Users were being asked for highly technical information in the self-serve flow with little resources in helping them find this information, leading to blockage

  • Suggestion: provide a comprehensive list of permissions and guidance on how to find this info. In addition, show purpose descriptions in table form so users can quickly scan and retrieve info.


Users need input validation: Not having validation leads to low user confidence when submitting. When errors do occur, requests need to be revised and resubmitted manually, slowing down onboarding time.

  • Suggestion: Provide validation wherever input boxes are necessary. This helps to decrease user error, and lessen work for the security team checking submissions, leading to an overall faster job creation time.

Next steps

I shared the research findings with the Offline Jobs development and PM team, and organized a follow-up design workshop to go through the flow as a whole.

The workshop helped the team…

  • Breakdown user pain points screen by screen

  • Understand how to fix problems from both a design and engineering perspective

  • Prioritize post-MVP design and engineering tasks

Post-MVP Updates

Post-MVP Updates

Created a guided tour to help users get started on onboarding

Created a guided tour to help users get started on onboarding

This update was implemented to help users get familiar with the new layout, which had changed greatly since Offline Jobs 1.0.

Redesigned “Purposes” table so that descriptions are visible without any additional clicks.

Previously, users had to click “View” on each purpose to see its description in a new tab, taking them away from the self-serve experience and increasing the time spent on finding the right one. This was redesigned so descriptions are visible from the surface, while maintaining a “Details” link that users can click to see other information about the purpose.

Redesigned review screen

To edit anything before submitting, previously users would have needed to click “Back” until they reached the section they were looking for. Adding links to the review screen helps users get to the right section more quickly.

Added validation for the “permissions” screen

Permissions are needed in most use cases in order for the Offline Job to access the right APIs. Users don’t typically know the name of the permission, so a typeahead dropdown was needed in order to increase discoverability. In addition, all permissions are now validated and checked before submission to decrease the security team’s workload.

Additional post-MVP updates informed by research

  • Full audit of UI to ensure alignment with DevPortal standards

  • Audit of all content shown in self-serve flow. Worked with content design to ensure that content was easily understandable even for users with limited experience with Offline Jobs

  • Addition of new documentation informed by research, detailing how to onboard, what use cases are supported in 2.0, and explaining mapping between 1.0 and 2.0.

Impact and Learnings

We were able to successfully complete research and post-MVP roadmap planning within the 2 month time constraint we had before Offline Jobs 2.0 launched. The research provided us many valuable learnings that informed changes on a variety of fronts - design, content, documentation, and strategy. As of FY23, Offline Jobs assets are continuing to be migrated to ID 2.0 daily, with overall migration set to complete on track by end-of-year.

  • Reduced migration time from 2 weeks to 2 days (80% reduction)

  • Support volume reduced by 30%

  • Migration to 2.0 on schedule, with Offline Jobs 1.0 fully sunsetted

Learnings

  • The importance of keeping the dev team, design, and product on the same page. While working on post-MVP design tasks, occasional disconnect between development and design/product led to misaligned priorities and caused delays. Creating JIRA tickets for design ensured that everyone had visibility into upcoming work

  • Content design is especially important for self-serve flows, since the user has limited support when going through the experience on their own. Revising the content on certain pages decreased the likelihood of use case selection errors.