Carbon Design System was often referred to as exemplary
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
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
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.
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
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
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
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
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
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"
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
Content Strategists, XAs, UXDs and researchers observed the interviews and then came together to build the affinity map
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!
We call out three high level findings that we felt would bring immediate ROI
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!