Feature Registry Redesign

Leading the redesign of Capital One’s feature management portal.

Please note that an unredacted version of this presentation is available to be shown live to Capital One associates only

Feature Registry is an application used by Capital One associates to create and maintain customer features for the app and website

Project Profile

Position: Content Strategist, then Design Lead

Design team size: 5

Users: More than 250 potential engineers and product managers

Value: Millions in revenue generation, customer satisfaction, NPS/brand association, sev incident response times

KPI: Number of registered features, number of registered users, sev incident response time

Stakeholders: SVPs in Enterprise Product and Tech

Time: 10 months

Feature Registry’s problems were holding the company back in NPS and revenue

Lost Revenue

Slow Response Times

+

=

Production Bottlenecks

Product team presented the problem as a matter of rewriting the current content 

The original Feature Registry application was just a form. Users found it very difficult to understand.

The research showed that users avoided Feature Registry because they feared it

User Challenges

Found the system hard to understand

Did not know how features worked in general

Feared making a mistake on Feature Registry and causing sev incident

Design Challenges

No one knew how the whole system worked

Small number of users who knew how to use the Feature Registry application

Language rewrite wouldn’t fix the larger problems of knowing how the system worked

The design lead left the company; I served as interim design lead until a new one was found months later.

I reframed the problem and proposed new solutions to the product team

We moved forward based on my new vision and strategy and engaged a full design team of five plus PM and tech partners.

Updated UI: Eliminating forms in favor of a a guided user experience

Onboarding: Embedding instructional content on how to manage features

Migration Feature: A bridge to bring in users reluctant to copy over their feature data

Concept Mapping: Documentation of the system architecture and concepts for reference and review

My Teamwork Processes

I designed and facilitated four stakeholder workshops to define the destination state vision

Strategy

Design

Content

Technology

I built an ontology to visually document how the new system worked and get stakeholder agreement

This “ontology of wine” slide is from a deck I presented on how to build ontologies. We used the same framework to map out the concepts, their definitions, and their relationships to each other in Feature Registry.

I guided my team to use a content-first design process to build out the user interface

Ontology (IA)

The first step in breaking down the complexity into the key concepts

Language

Turning the terminology into easily understandable on-page language

UI Design

Using the terminology as content building blocks for the UI

The Results

We now had a prototype for further refining and testing. Initial usability measures via UMUX Lite were trending positive. Select screens from the initial prototype are below.

Initial testing showed that usability scores increased

2.3

5.1

Onboarding Interface

The following screens are protected by NDA; portions of the content are reproduced below:

The onboarding pages were written to accomodate first-time users. Large blocks of text were replaced with easy to understand diagrams, and were rated higher by users in usability testing.

Defining basic terms and providing instruction was the most important part of the content, per user feedback 

Content selection: “Feature Registry is used to build features for applications, or apps. But features aren’t yet an entity in Feature Registry, so we’re going to create them. In the next few pages, we’ll talk about how to do that.”

I wrote, tested, and refined all of the user-facing content below.

Content selection: “We provide services for app versions with components called feature flags, or just flags, formerly known as toggles.”

Users now had a guided process to create and import features in Feature Registry

Showing people what they needed to do before they did it helped them to trust the process. Users reported reduced anxiety because of the progress indicator in the right sidebar.

Content selection: “In this form you will create features by grouping flags together. No changes will be made to the customer experience. At the end, your results would look like the blue column to the right.”

The feature intake form provided descriptions, defined terms, and showed users’ real-time progress in the blue sidebar.

The onboarding documentation was made available in the expandable green box so users wouldn’t have to hunt around for documentation, one of their biggest pain points.

The final screens let users review before submitting, increasing confidence and trust

The feature confirmation modal guided users to other relevant content based on the content map

Epilogue:

I took on a new design lead role before the deployment of the Feature Registry MVP, but I would have tracked the following metrics to measure success:

-NPS scores

-UMUX ratings

-Time to onboard

-Attrition among users

-Sev incident response speeds

-Feature development speed (averages)