ThinkData Works

How can we empower users to explore a wide range of features with more confidence?


ThinkData Platform is a data catalog and has numerous sets of features that users often find overwhelming. The purpose of the feature gating project is to design a smooth upselling experience by introducing features incrementally and encouraging users to upgrade to the next payment model.

✓ How does this project help the business and users?

– Guide users to know where to start without being overwhelmed

– Allow the sales team to tailor the platform and the cost to the customer's particular needs

– Support users to learn the platform incrementally and clearly understand ROI on upselling at all times

✓ What was my contribution?

I gathered background information and contexts from stakeholders, analyzed the industry best practices and suggested how to apply them to this project, created prototypes with different levels of fidelity, and pitched my final design to stakeholders.

✓ What was the business impact?

This project will be implemented in Q3 2023 and the company will be able to gauge its business impact starting from Q4 2023. Potential business metrics include how many users complete the flow of this feature and what percentage of them decide to upgrade to the next tier model.

Design Process

Design Process

Design Outcomes

Onboarding process made easy and collaborative

Onboarding tasks function as a foundation for users to start using the platform without overwhelming them. While completing the tasks with their team, users come to explore different features across the platform in the way it is intended.

Flexible solutions for both sales and engineering

Gating the ability to assign different roles allows the sales team to meet the customer's particular needs while supporting the developers to easily turn on or off certain roles.

Pitch the merit in a context-sensitive manner

Feature gating tackles relevant user flow to remind users of the benefit of unlocking more features. The design nudges users through multiple touchpoints, increasing the chance of successful upselling.

Define problem

Define Problem

While talking to the product director, customer success manager, and sales specialist, I was able to discover that the problem was twofold — the problem for users and the problem for business. Users didn't know how to start using the platform since they get overwhelmed with all the features. At the same time, without tiered pricing models, the company couldn't charge customers differently depending on the type of features they were using. Following is how I turned the problems into HMW questions.

HMW questions


Design References

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.

  • Research overview

    Comments I left while analyzing design references

    Research overview

    Slide deck I created to share my learnings from research

  • ✓ Alignment with the project

    Best example

    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.


01 Job Stories
Job stories

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.

02 Journey Map

  • ✓ From user's perspective

    Journey map

    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

    Journey map

    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

    Simplified journey map

    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.

  • Journey map & research alignment

    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.

03 Defining variations

  • ✓ 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.

    List of use cases

    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.

Prototype & Iterate

01 Designing for Edge Cases
Chart for edge cases

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.

02 Improving Consistency

  • ✓ 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.

03 Developer Handoff

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

    Developer note - 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

    Developer note - components

    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.

04 Business Impact & Performance

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?


01 What Would I Do Differently?

1. Enable in-app flow to unlock the next payment model

Due to technical limitations, I had to make users contact the sales team to upgrade to the next payment model. While I value giving consideration to engineering constraints, I still would like to make this flow more self-sufficient — allowing users to unlock the next payment model by themselves within the platform.

2. Test my design with end users

One of the natures of working for startups is that I have to learn to handle the lack of resources. User engagement was the company's higher priority than user retention, hence I didn't have a chance to conduct any usability testing. If given more budget, I would like to build solid UX research plans and test the designs using different research methods.

02 Key Takeaways

1. Build low-effort design rather than designing the ideal

As much as I value advocating for users' perspectives, there were many occasions when I had to compromise with engineering constraints. I had to build design solutions that are low-effort for the engineering side but high-impact for the business side.

2. Understand different needs of users and customers

The unique thing about working for a B2B company is to understand that what customers want can be very different from what users want. In the business model of ThinkData Works, customers decided to buy licenses but didn't use the platform. So I learned how to make my designs show promising ROI to customers while making end users' life easier.

3. Make design flexible and adaptable

The nature of feature gating was that it should be flexible enough for the sales team to explore while being adaptable enough to be applied to different feature sets. As I worked on feature gating, I developed my skills in building flexible design solutions rather than keeping them rigid or fixed.