Pinecone Registration Flow (1)

Learning more about our users and what they’re building with the Pinecone Vector Database, while enabling personalized experiences on the Pinecone Console.

Updated October 2023

Role: Product Designer

Collaborators: This was 1 of 3 projects I designed solo during my Product Design Internship. I was supported by and collaborated with 1 Principal Product Designer, 5 Full-Stack Software Engineers, 1 Product Manager and 1 Growth Product Marketing Manager.

Project Overview

The Product and Design teams needed a way to gather information about users to learn who they are, what they do, and why they are signing up. Knowing this information would not only allow us to develop more tailored user experiences, but also would ripple throughout the entire company as executives would have data to present to investors and partners about who is using Pinecone and what they’re making with it, and internal teams could tailor their research and engineering for those users.

Problem Overview

In March 2023, Pinecone’s growth exploded, reaching 10,000+ new users a day. To add fuel to the fire, the Design and Product teams removed all friction from the sign-up process, pared down the onboarding, and made it faster for user’s to create their first database (called an “Index”). This worked, with ~80% of users that signed up going on to create an Index.

But when I began as a Product Design Intern in June, the user growth had stabilized and the team refocused on improving the experience for new users.

Reducing friction at all costs had created 3 problems:

1. New users received no onboarding or education. They’re just dropped into the console to get started, with little context or guidance, especially for a fairly technical app.
2. As a company, we didn’t know WHO was using Pinecone, or WHY they were using it, since we didn’t gather any user info. Data-enrichment had a terrible 30% match rate since we only had emails to use as inputs.
3. We couldn’t personalize the console. Since we didn’t know much about our users, we didn’t know what we should teach, or who to target.

Problem Statement How might we understand our new and existing users better in order to design more personalized onboarding and user experiences, and develop better internal data on our users?

Goals

• Personas: Learn what user personas are using Pinecone
• Projects: Lean what type of projects users are building with Pinecone
• User data: Improve our data-enrichment match rate from ~30% to at least 80%
• Personalization: Use our insights to immediately personalize the Pinecone Console for the users
• Low friction: Achieve these goals without significantly affecting the rate of users that complete their account creation and create an index (benchmark of ~80%)

User Personas and Internal Research

While I worked on this project, the design team interviewed the marketing, growth, and customer support teams to create a set of user persona’s for our customers, which we could then use to decide which question to ask users. As a developer-focused B2B product, different user-types use different features within the Pinecone Console, ranging from the hyper-technical engineer working on a software team, to hobbyist developers experimenting with AI, to buyers and administrators within companies trying to evaluate or manage Pinecone for their teams.

Formalizing these personas would help the company develop a shared understanding of our users to guide future features, marketing, and product strategies.

Wireframing/Prototypes

I was hoping to explore different ways of displaying the questions, prompting the users, and enticing them to complete it, while trying to reducing the visual weight and cognitive load for each one.

Modal with traditonal dropdown selectors and text fields

Modal with expanded radio groups

Modal with Radio Group List’s

Multi-step text input fields and expanded radio groups

Full-screen expanded radio groups

Full-screen marketing with expanded radio groups, and social proof

Full screen modal with expanded radio groups

Unbounded full-screen

Evaluating Wireframes

High Fidelity Exploration and Visual Design

I explored a structured column design with equal width buttons. The fixed width columns made it hard to scan and increased the clutter.

I tried making the selected options more distinct, but they looked too similar to the button.

The hierarchy felt off, so we made the subtitles larger and bolder which helped the whole form become more balanced, structured and glanceable.

With options that hugged their content, the height and overall size of the form could be decreased and the elements were more glanceable.

I also added icons to the option

Overall, the icons increased clutter without increasing the clarity that well so we removed them. We also removed the fill around the checks and increased the border width to counteract the decreased weight of the checks.

Later on, we’d make the text input fields the same height as the buttons to make it more cohesive.

Here I explored some full screen designs, that add social proof, features, and more to use the form as an opportunity to educate users and encourage them to complete the app.

We decided against these options since they were too similar to the initial sign up page, didn’t add new information, and unconsciously indicated that this form was part of the signup process rather than the setup process.

We briefly considered a multi-step form, but thought the number of clicks to complete it would lead to drop-off. This would’ve been interesting to split-test if we had the chance.

Copy

I tried to make the copy pithy, concise, and transparent, and convey that this is the last step before using the Console.

In the name of transparency, if we were asking the user for info, we needed to show our work and explain why, so I added a subheading that states we’ll use it to personalize their account.

Last Minute Changes

We decided to add an option for “other” to each radio group category, which would show a text field.

After prototyping the form, I saw that the checkmarks caused the width of each radio option to expand each time the selected option switched, which pushed each option to the right and led to a clunky UX. I had considered this early on, but it ended up feeling worse than expected so we experimented with ways to avoid it.

I tested adding padding to the right of each option to hold the check, but it looked odd to have the excess space.

Ultimately, even though the check added clarity for which item was selected, we chose to get rid of them and increase the width of the border on selected options to ensure accessibility.

Final Versions

Some Surprise Coding in React for Account Settings

To wrap this project up, we needed to allow users to edit their selections, and to help existing users fill it out if they wanted. Most importantly, we wanted user’s to be able to edit their email address and preferred coding language.

I mocked up a quick modal which would be accessible through the profile dropdown with quick editing.

Excitingly for me, I got to see this feature through from design to development, eventually coding it with React, TypeScript, and React Redux. I always love breaking out my programming skills when I get the chance.

Usability Testing

We tested prototypes of the expanded radio group modal and the dropdown modal with 25 people.

The expanded radio group modal was favored by 68% of people, which was statistically significant at alpha = 0.05 (z-score = 2.55).

Overall users, preferred that the expanded radio group modal guided them through the form, that all the options were all visible, and that it felt less cluttered despite having more information.

Launch and Results

To save engineering time, instead of traditional A/B test, the team opted to launch the expanded radio box version first and see if there was a decrease in completion/new index creation, and if there was to then develop the traditional dropdown and test that one.

After launching, there was no statistically significant decrease in sign up completions or new index creations, which was exactly what were hoping for, and the form was rolled out to all new users.

2 Wins

It feels like a physics problem because there’s (almost) no friction

Despite the fact that a form interrupting the sign-up process can feel annoying, I think I was able to successfully reduce the friction of this form to about as low as it could be. I did everything I could to keep things on one page, reduce extra clicks, present all the information in a glanceable way, and put it in a modal so you know you’re almost there. I also refined the copy over and over again to be pithy and indicate that this is the very last thing.

It’s live right now

This was both my first feature that launched at Pinecone, and also the first feature in a product I’ve worked on that has been used by thousands of people every day. It’s currently live for all new users, and is the first thing a new user sees after signing up for Pinecone. Being a small part of a users journey to build something cool with Pinecone feels really special. And I’m equally proud that my colleagues at Pinecone can benefit from the collected data to guide the development of personalized onboarding features.

2 Improvements

Build more excitement

I think this form could be a great opportunity to build more excitement in users. It’s a chance to tell them about the cool things they can make once they complete it and inspire in them that they can use Pinecone to build things. I tried to do some of this with the copy, but I think largely it’s still a form that they just want to quickly complete. A version where each use-case has a large and playful graphic associated with it would be a good place to start, but there’s lots of others way too. This was not the main purpose of the form, and I think this excitement and inspiration will most likely come from the onboarding experiences when they launch, but if I could go back, I would try to add a bit more of it here.

Create a better first impression

This form is the very first thing a new user sees when they sign up for an account, and while I think it is well-designed and solves the problem well, it’s still just a form. I’d love to have it be a bit more visually interesting, or show something more interesting behind the modal to leave a lasting first-impression.

2 Takeaways

Problems exist inside and out, but they all come back to the user eventually

At first I was disappointed that this project was not focused on the user, but rather solving an internal company problem. I’m someone that is always thinking about the user, and this form could be interpreted as an annoyance to users which is the last thing I want to be working on.

But as I worked on this project, I realized that if the people making the product are having problems, it will ultimately be reflected in a worse product which does in fact impact the user. In this case, we just didn’t know enough about our users to build personalized experiences for them. But now with this registration form, we do.

So is it annoyance for users? A bit. But will that (relatively) small annoyance ultimately lead to pretty big improvements in the user experience overall? Absolutely. It’s all about tradeoffs, and I feel pretty good about this one.

The more you talk to engineers, the better

I’m continually inspired to work with such talented and thoughtful engineers. My discussion with them almost always bring up interesting new approaches to a design problem, or raise edge-case and or factors I hadn’t considered that help wit the design process. On this project, I was chatting with Dan about the input validation, error handling, and how to mark items as required vs optional. Learning more about the engineering constraints, tradeoffs, and engineering time for each piece was incredibly insightful and helped me go into the design and iteration process with a more well-rounded and considerate perspective on what it would take to see this feature from beginning to end.