Sarah Romoslawski
Mixed Methods UX Research and Leadership

Developer Needs for the Interfaces Portal

Using Jobs to be Done to understand developer needs across teams at U.S. Bank

Objective

Inform feature direction and content direction of the Interfaces Portal, an internal developer portal aimed to support consumption and contribution of a unified design system's reusable interfaces (e.g. elements, components, micro-flows) across the bank. 

Do so by uncovering:

  • latent needs of developers who are working to both incorporate reusable elements and contribute elements back for others to use

  • where developers struggle the most along the consumption journey

So to inform:

  • feature direction across the portal

  • feature direction of a live demo

  • component page layout

  • information architecture across the portal

  • and more!

Methods

  • Jobs to be Done strategy

  • Job Maps

  • Journey Mapping

  • Cognitive Empathy

  • User Interviews

  • Deep Listening

  • Concept Testing

Interfaces Portal Team

The Interfaces Portal team worked in agile two-week sprints. This was the first time I had ever worked in this context as a user researcher. The team consisted of:

  • Myself (User Researcher)

  • User Research Manager

  • Experience Architects

  • Visual Designers

  • Content Strategists

  • Product Managers

  • Scrum Master

  • Front End Developers

JTBD Case Study

Carbon Design System was often referred to as exemplary

JTBD Case Study

A few of the available components on the very early site (note broken CTAs)

About the Interfaces Portal

U.S. Bank has its own internal design system, called Shield, that is intended to be used by designers and developers alike. Unfortunately, the system's components are not always compatible with the different business lines. Prior research found that developers struggled with the following:

  • Lack of awareness of what reusable elements are available to them

  • Lack of governance and standards for building reusable element libraries

  • Poor communication on component updates or changes

  • Unclear process of how to contribute back of a team needed to make a change to a component that was faulty or lacking features

These high level needs sparked a massive multi-million dollar project - The Interfaces Portal

Reframing Prior Research with Jobs to be Done
JTBD Case Study

We looked back at findings from prior research to find patterns using JTBD as the lens

Understand Prior Research

The first step of our journey into the developer's process was to dig into some work that had been done prior to our own. Leading up to the Interfaces Portal initiative there were three sets of work that provided insights for us to build the consumption job map and generate a set of personas as foundational research

  • Interfaces Framework "3-6-9"

  • Shield Design System developer user interviews

  • Portal Vision Proof of Concept interviews

Challenge: Insights everywhere, unclear on the overlap or key repeated themes

Solution: From these past projects, we extracted needs, jobs and solutions/opportunities. We also revisited user interviews and talked to teammates about the process so that we could create a job map.

JTBD Case Study

Job Map for Consumption Jobs

Why JTBD?

The top-down understanding of developer struggles with the current design systems was the spark for the portal project.  While these struggles were generally understood by stakeholders, a deep understanding of the problem space was not yet formed by the team.  We proposed to use Jobs to be Done to reframe the prior research and kick off further investigations

Jobs to be Done felt right for us because of these reasons:

  • Helped put some order to the chaos

  • Provides a system of atomic parts that can be grouped together

  • Affords building stories from these atomic parts that can be used in conjunction with agile user stories

  • Allowed us to categorize the prior insights into the tasks (jobs), needs and solutions

Our first Job Map

Incorporate Reusable Elements into bank experiences when crunched for time

JTBD Case Study

Connecting main jobs to the OKRs

Identifying Main Jobs to Create Vision of the Portal

As a developer builder, I want to

  • Consume Elements

  • Find New Elements

  • Contribute Back

  • Learn How to Build Reusably

  • Help Others

  • Get Help

I will do that by using

  • unified library

  • contribution process

  • curated content

We will measure success by

  • adoption of new components

  • page visits

  • number of platform teams using the service across the bank

JTBD Case Study

How might we spread communication across the consumption journey to avoid blockers?

Consumption Job Map Shows Struggle at the ASK stage

We identified a job stage called ASK where developers hit the biggest roadblocks. This stage involves having to communicate across many different channels such as teams, e-mails, or large group meetings. In some cases, developers were unsure of who or where to make contact. Further interviews revealed that many of these roadblocks are related to the misalignment of a11y standards.

Developer Personas and Thinking Styles
JTBD Case Study

Reframing the four developer personas using elements from JTBD

Developer Personas: Who are our developers and what do they need?

What we did:

When I came on to the team, there was not yet a set of personas. We created a set of goal-oriented personas based on prior research.

In order to continue to flesh out these personas, we kicked off user-listening “sprintly” so to create a regular stream of new insights to either validate those four personas or add to them.

What we learned:

The prior research yielded 4 distinct personas. Categorizing the different needs across the personas shows that although the needs show that needs relate to collaboration and communication.

  • World-Class Mobile

  • Efficiency is a Virtue

  • Conflict Averse

  • Fast Impact

JTBD Case Study

Summaries of our developers New Universe of Possibilities and Trapeze Without a Net

Validating and Adding to our Personas with User Listening Sprintly

Because the previous set of personas came from prior research, we needed to kick off a regular cadence of additional insights. Every sprint, our goal was to talk to developers during listening sessions. These sessions were easy to plan because they require only a strong initial question and then listening deeply to understand:

  • more main jobs to consider

  • guiding principles

  • inner reasoning

  • reactions

  • motivations / other purposes

We kick off most of our user listening with:

What goes through your mind when you think about building reusably at the bank?

Here are some of the individuals we spoke with, named by their mindset:

  • A New Universe of Possibilities

  • Trapeze Without a Net

  • This Isn't Magic

  • Manual Balancing Act

Developer Journey to Component Pages
JTBD Case Study

We had the wireframe for the component page but we really didn't yet understand how or why a developer was going to use it

Developer Journey to a Component Page

As the team began to iterate on the various pages of the portal, we realized it was time to start thinking about the solution space in addition to the problem space.

  • Zoom in on the stages of the job map from investigate to ask

  • Learn about tools used along the way (the things the developer hires to do the main job or micro-jobs along the way)

  • Understand when developers use GitLab vs Storybook vs looking at code on "their local"

JTBD Case Study

Places and Tools

One of our goals was to capture what it might look like for a developer to work through the process of consuming a component. We found:

  • that developers use different tools

  • developers will use the design system site to demo components in other repositories (unknowingly!)

  • developers can't find overarching a11y guidance

JTBD Case Study

Content Strategists, XAs, UXDs and researchers observed the interviews and then came together to build the affinity map

JTBD Case Study

The journey to consumption involves jumping around to many different places

What we learned:

  • There will be different needs for the circumstances of first getting to know a component vs using a component again

  • Hitting a11y defects very late in the game because the standards were not documented and there are multiple a11y teams

  • Not getting clear direction from UX on what components to use

  • No clear way to document when new issues are encountered

  • Not knowing which repository the component is associated with

  • Components living in different repositories with the same name

  • No clear way to contribute back (redundant work)

  • Lack of parity between components on the design system site and in the repositories

  • Browsing through components that are not “how we do things” (we learned how teams describe themselves: "We are form heavy, we are technical, we are theme heavy")

  • and more!

JTBD Case Study

We call out three high level findings that we felt would bring immediate ROI

JTBD Case Study

Live Demo wireframe shows ability to link directly to the component in GitLab

Findings we brought to the team

  • Priorities, content requirements, and feature recommendations for the README files, component documentation and Live Demo

  • Recommendations and best practices that might mitigate calling giant meetings

  • Prioritize access to a11y guidance and what is considered acceptable

  • Create parity between references and repositories

  • Consider ways for business line needs to more easily navigate to the "we are..."

  • Remove Download Packages call to action from component page

  • Consider bringing in a11y resources to the MVP version of the portal

  • Begin design innovation on ways for business lines to more easily filter for or navigate to components relevant to them (e.g. personalize for what theme or styles are used at the page level rather than at the component level)

  • and more!