I collected some references to analyze how other products designed their upselling experiences and understand how the best practices can be applied to the feature gating project. I dissected each user flow and compared good examples and bad examples with the reasonings behind them. Then I shared these with the team to check if everyone was on the same page and define what we could learn from the references.

• 

  Comments I left while analyzing design references

  
  
  

  Slide deck I created to share my learnings from research

• ✓ Alignment with the project

  

  After discussions with the team, I chose Slack as the best example for our project. Then I shared this example with the team to walk them through how it closely aligns with our project goal and how we can leverage the learnings from Slack.

  
  

  Later in the design process, I created a user journey map of feature gating and tied the journey back to the insights from Slack. By doing so, I was able to make the project truly benefit from the research and support the rationale behind the user journey.

  See how I leveraged the research

I wrote up a list of job stories to have a deeper understanding of the user's focus and motivation. Elaborating on the user's situation, motivation, and expected outcome allowed me to focus on context and causality instead of jumping onto implementation or relying on assumptions.

Additionally, I scheduled meetings with the product director and walked them through the job stories I defined. I used this as a checkpoint to see if I understood their priorities and if I was moving forward in the right direction. We as a team edited some details of the job stories together and I was able to move on to the next phase of the design process with more confidence.

• ✓ From user's perspective

  

  Based on the job stories, I mapped out the details of the journey users will go through while using feature gating. First I defined users' actions, thoughts, needs, and unmet needs. While doing so, I was able to discover exactly when and where users experience frustrations then translated these findings into suggestions, focusing on how I could turn these pain points into opportunities for improvement.

• ✓ From business perspective

  

  Since the first journey map was to be fully immersed in the user's perspective, I created this business version of the journey map to point out how this user journey aligns with the company's roadmap. One benefit of having two different versions of the journey map was that I was able to bridge the gap between the perspective of users and business. Another benefit was that it made it easier for me to pitch my idea and solution to stakeholders.

• ✓ Communicating with product director and stakeholders

  
  

  Snapshots of the simplified journey map

  When sharing the journey map (user version) with the product director, one of my goals was to share the gist without overwhelming them. Hence I decided to simplify it as much as possible. My rationale was that the product director may not used to the format of the user journey map, and sharing all the details could distract or confuse them.

  
  

  So I trimmed it down to high-level steps in the user journey and translation of challenges into opportunity spaces. The product director found my approach very easy to understand and appreciated that I clarified the opportunities for improvement.

• 

  Slide deck I created to emphasize the value of this user journey

  In addition to this, I reiterated how the user journey (business version) aligned with the good example from Slack. It was my strategic approach to pitch my idea to stakeholders — making them associate this new journey with a successful example.

  See my process of creating the user journey

• ✓ Use cases

  Based on the journey map, I wrote up a list of use cases with the product director and senior UX designer. Here we documented when and where in the platform the feature gating would be needed. This list of use cases was used to define the number of different gate types and their characteristics.

  
  

  Use case list of feature gating

• ✓ Feature variations

  

  We concluded that the platform needs three different gate types: Quantity, Temporal, and Binary. Each type would gate users in unique manner in terms of how we are limiting users — if users need more quantity, a longer time span, or an ability to access the feature. In addition to this, we discovered the needs of an onboarding experience as a way to encourage users to try each type of feature gate.

Types of chart design for quantity gate

First, I focused on making the initial design suitable for the major use case. Then I started building more variations to cover different edge cases based on the inputs from the product director and developers.

While talking to the product director, I asked questions such as "Will there be any occasions the data for this chart is not applicable?" to learn more about the chances and conditions of edge cases. I also asked the developers' thoughts on edge cases to check if my design was covering all the scenarios. By doing so, I was able to facilitate the discussions within the team about what we would like to prioritize for each edge case.

• ✓ Iterations of hover state

  

  One of the considerations while iterating some design ideas was to maintain the consistency of the design system and to match repeated patterns that have been established within the platform. Above is one example, initial explorations of the hover state. There were two major goals in this flow: to communicate that the "organization manager" role is disabled and to provide a brief explanation of this role.

• ✓ Final design of hover interaction

  

  This is the final design I came up with to keep the hover and select experience consistent. I decided to only change colors for the hover state since that was the commonly used pattern in other areas of the platform. To communicate that the role is disabled, I used a lock icon instead of role-specific icons.

Along the design process, I frequently communicated with developers and this is how I finalized the details and documented the notes for handoff. For a smooth handoff, I create three different files: the first one to provide the details of components and their use cases, the second one to share individual screens and how the components are implemented, and the third one to show a clickable prototype.

• ✓ Sharing details of components

  

  In the first handoff file, I focused on elaborating on how to use each state of components and what affects the switch between different states. I started by explaining the granular components and then the aggregate-level examples to show how each component could be combined together. Also, I left some notes to mention what needs further clarification. In the example above, I left a yellow-colored note about "when to show progress bar" since the sales team hadn't reached a consensus on this yet.

• ✓ Clarifying user flow

  

  In the second handoff file, I explained the whole user flow and how the screens would look in different edge cases and scenarios. The goal of this document was to help developers visualize the user flow based on their understanding of the components from the first handoff file.

Feature gating project will be implemented in Q3 2023, hence the company cannot gauge the business impact of this project yet. However, here are some metrics and approaches I would like to take to measure its performance.

• 1. Sales team using the feature gating to explore tiered pricing models

  Since ThinkData Platform did not have different payment plans, the problem on the sales side was that customers either buy the license of the platform and get everything or do not buy the license and get nothing. Once this project gets implemented, the sales team will be able to explore tiered pricing models, leveraging its flexibility. For example, they can measure how many datasets they should allow users to create on the cheapest payment plan or which roles users are the most willing to pay more for.

  
  

  A mockup of tiered pricing models I created to help stakeholders' understanding

  How is the sales team benefiting from the flexibility of feature gating?

• 2. Users completing onboarding tasks

  Another goal of feature gating was to help users learn the platform and onboard successfully. Using the event metrics questions I created, measuring the number of users completing onboarding tasks and its correlation with the rate of users moving onto the next payment plan will shed light on the business impact of feature gating.

  Do users participate in onboarding tasks? Does it lead to upselling?