Reframing the Subscription Process

Institution / client name: Red Hat
Project name: Reframing the Subscription Process
Date: Winter, spring 2011
Role(s): UX Design, Business Analysis

This diagram illustrates how a user's understanding of a concept is built through different channels
Sample page of early narrative document
Sample slide from presentation showing simplified concept of a subscription
Sample slide from presentation illustrating part of cognitive walkthrough

Problem

The project started with a simple question: Do our customers understand how subscriptions work? As with most good questions, this one unraveled into a very large problem. As an open source company, Red Hat sells subscriptions not licenses. When a customer purchases a subscription, she is purchasing the ability to use Red Hatís services, such as software downloads and updates, for a given period of time. Customers need to purchase renewals when their subscriptions expire.

Thereís a whole chain of business logic and processes behind Red Hatís subscriptions. The marketing teams develop product SKUs that the sales teams offer to customers. Because subscriptions are timed, the customer has to register when the subscription begins so the operations team can keep track of when they expire. The technical support team needs to know what level of support the customer paid for in their subscription, and various updating tools also need to know if the customer has paid for access to updates they request. And, each product needs to make sure thereís a valid subscription in place before it runs Ė and there are many different teams that build the products.

Each step in a customerís experience, from shopping, to purchase, to installation, to training, to up-and-running, yields explicit and implicit descriptions of the overall subscription process Ė and these descriptions come from a half-dozen different teams or more. Because the subscription process has evolved over many years, and continues to evolve today, different teams are building off of different visions of what the process really is, and are explicitly and implicitly encoding these different visions in their part of the overall process.

The userís job is to assimilate all of these messages into a single whole. But, taken together, the explanations do not make a coherent story Ė and that causes headaches for the user who is trying to understand.

My job as a UX designer is to eliminate those user headaches.

Approach

Why is it important for a user to be able to create a cohesive story? Because, when the user discovers an unanswered question, she will use her current knowledge to make inferences as to how the entire subscription process works Ė and her current knowledge is represented in the story sheís internally developing. The inferences she makes will feel like promises about how the systems will behave Ė and nothing causes frustration headaches for users more than broken promises.

My approach to solving this problem was to create a common user-centric reference narrative that defined a single process in diagrams, terms and relationships between terms that are used throughout the subscription process:

  • When a user has heard a part of a story, he will try to use new information to fill in gaps, attempting to making a complete story.
  • I wanted to design the complete story that Red Hat wanted users to understand about subscriptions, allowing users to draw valid and consistent inferences.
  • The story is a representation of the work model for a type of user interface that is spread across many individual products.
  • The narrative is designed as a reference to be drawn upon by those creating customer-facing communications; in and of itself, it isnít shown to the user.
  • By using the complete story as reference when they create their artifacts, different teams will be telling different parts of the same story.
  • The different parts of the story that users hear will be able to be assembled into a coherent whole, because they originated as part of a coherent whole.
  • New pieces of information will support and positively reinforce the mental story the user creates.

Actions

Here are some of the steps that I went through in creating this narrative:

Research:

  • Interviewed development, operations, product management, customer service, and other stakeholders to get their opinions of the process.
  • During each interview, I noted where the story I was currently hearing diverged from other stories, and I asked about it.
  • I noted whether divergences were due to terminology, or to different fundamental understanding of the systems.
  • I drew up system models conforming to the explanations I had at the time, and showed them around for comment.
  • I drew up a text version of the narrative that broke the overall system down into logical units. Each chapter of the narrative dealt with a single concept, and explained it with a series of bullets that form a story, and a series of definitions.
  • I submitted this for feedback to even more constituents for comment.

Development:

  • I began to work closely with MK, product manager for subscriptions, to show how the concepts would map into the products that were in the current development and release pipelines.
  • In our discussions, it became apparent that we needed to validate certain aspects of the narrative with Red Hatís contracts team.
  • We found a significant issue that caused us to go back and recast certain parts of the process to gain the approval of the contracts team.
  • I began to create a formal presentation illustrating what the userís experience would be in a specific scenario of purchasing and installing several different products.
  • MK and I refined the scenario, and iterated with more people.
  • After several revisions, we presented the narrative to senior engineering and marketing management as well as to technical field staff.
  • Everyone was extremely pleased with the outcome, and could tell that there significant value would accrue from my work.

Results

In the end:

  • We achieved consensus on the subscription process
  • We achieved consensus on the need for common terminology
  • We achieved consensus on the concepts that needed to be named
  • We achieved consensus on some concept names

Red Hat is now poised to put this plan into action. As new products, and new materials for those products, come out, users will be able to build a common picture of what the Red Hat subscription process is.


phone: 617-697-7527 — e-mail: ben@dubrovsky.name — ©2007, 2008, 2009 Ben Dubrovsky