Simon Data
2021-2023: Product design • User research • UX • UI • User testing
Simon Data is a customer data platform (CDP) that allows clients to unify customer identity, create audience segments, and set up marketing campaigns to target customers across multiple channels.
Simon Data website
Product images
• • •
Introduction
I was hired as a Senior Product Designer for Simon Data in 2021 and worked there for two years. Simon Data is a B2B start-up in the ad tech space. It is a highly technical product mainly used by data analysts and CRM managers working for companies from a broad range of industries and sizes. At Simon, I completed the full product lifecycle for every project that I worked on, from ideation and research to user testing and final execution. While my other case studies are more granular, this case study is an amalgamation of the different projects I worked on to give a holistic sense of our product design process and the breadth of the work I did at Simon Data.
Sample of the companies that use Simon Data.
• • •
Identifying problems
Most problems came to us directly from users. Because Simon has such a technical product with a steep learning curve, most users had close relationships with our Client Solutions team. Many users would communicate their desires and frustrations with our product to Client Solutions, who would then hand them down to the product team. User issues were also often aggregated and tracked, so we knew which came up most frequently. Additionally, a lot of product focus was on how to reduce client reliance on the Client Solutions team, so many internal product ideas would come from the team members themselves. Once a decision had been made about which issue(s) we were addressing, I would work with a product manager to talk through and broadly define our problem, knowing that it was subject to change in scope and specificity during the research process.
Research problem statements I wrote for some projects I worked on.
• • •
Research
Research at Simon was usually the longest, most extensive part of the product design process. I’d start by writing a research plan, collaborating with a product manager to define objectives, write a list of questions, and identify the best participants. Because Simon has a B2B product with a limited number of users, client participants were usually specifically targeted based on issues they were experiencing relating to their company or current phase of product usage. For example, when we were researching how to improve our onboarding process, we interviewed clients who were currently onboarding and those who had just completed onboarding. Almost all projects I worked on also involved interviewing engineers and Client Solutions team members as well.
A research plan I wrote for the Onboarding Discovery project.
• • •
Participant interviews
The majority of the research I conducted at Simon took the form of interviews. I would record my interviews with participants and then transcribe them, summarizing and highlighting important information.
Engineers
Talking to engineers was important because, at Simon, engineering work was often completed before design work. There was product functionality managed solely by engineers, and design would then be brought in to create an interface that would represent that functionality to clients. For example, when we were looking to make our Identity Sandbox to help clients understand their chosen identity rules before they were implemented, I needed to know exactly how our Identity product worked and why certain choices were made. The identifiers all had relationships to each other and choices made by the client would restrict other options. These kinds of details were ironed out in engineering interviews. Also, engineers were often roped into fixing problems and hacking together solutions for things that the Client Solutions team couldn’t manage. Interviews with them also helped surface their own pain points that the new product could hopefully account for.
Notes from an engineering interview I conducted for our Identity product.
Client Solutions
Because they served multiple clients, Client Solutions analysts could usually give a good overview of the most pressing issues. These conversations would also often help us reframe the problem we were solving. For example, when we were working on how to shorten onboarding time for clients, the focus initially was on what we could build or what internal workflows we could change to help speed things along. The Client Solutions analysts made it clear that most onboarding delays were due to clients’ own technical infrastructure and readiness to onboard. It helped us pivot the discussion to how we could help clients be ready before they start onboarding.
Notes from a Client Solutions interview I conducted for our onboarding research.
Clients
Client interviews were most useful for discovering specific pain points. Since we’d already have the context of the larger issue we were working on from Client Solutions, these conversations helped me understand more granular issues relating to their specific company and workflows.
Notes from a client interview I conducted for our Identity onboarding project.
Sometimes the research I did would also lead to artifacts to help to document institutional knowledge across different teams or establish the starting place for further product inquiry. For example, when conducting our onboarding research, my conversations with clients, product managers, engineers, and Client Solutions analysts led me to create a current map of every single required to onboard. This helped clarify and expose the bottlenecks in our current process.
Map of our current onboarding process I created from my research.
After completing all of the interviews, I would aggregate and summarize the most frequent and significant responses and offer solutions. I would then bring this to my product manager and team of engineers to discuss how best to move forward.
Research conclusions I wrote for our Identity Onboarding project.
• • •
Advocation
Because Simon had limited engineering resources for all of the proposed projects, it was often necessary to advocate the necessity of your project to get engineering resources allocated. Simon had a voting process, whereby members from every team in the company would vote on the most urgent and important projects. Part of advocating for your project was communicating how it would help move the needle for the company’s OKRs that quarter. Below is a canvas I worked on to advocate for our design system project:
Design system project canvas for Q1.
• • •
The MVP
At Simon, we always strove to produce the minimum viable product (MVP). The extensive research we did would inform what that was. In some cases, it wasn’t actually a product at all. For example, when working on improving onboarding to our identity product, we realized we could resolve our pain points by creating a survey in Qualtrics, and in fact, we didn’t need to build anything.
In cases where we did move forward with building a product, I would work with a product manager to define the minimum requirements to test our feature, considering everything we’d learned from the research. Then, I’d design the feature, working with our design system. When the design was completed, I’d collaborate with an engineer to have a prototype built. Below is a walk-through of our Identity Rules Sandox, which I designed:
Product Overview:
The Identity Rules Sandbox is a tool that allows clients to test out identity rules for their organization before committing to them in their account. Identity rules dictate what user data exists in a profile (like a phone number or email address; these are called “identifiers”) and how new incoming data affects those profiles. Depending on the rules set, incoming data can either create a new profile or cause existing profiles to be updated or merged with other profiles.
1. Set profile rules
First, the user sets the rules that apply within a profile. The user must choose the stable identifier. The stable identifier has unique, one-to-one relationship with each customer profile. This creates a source of truth, whereby no two profiles can have the same stable identifier (i.e. if Customer ID is chosen as the stable identifier, no two profiles can have the same Customer ID).
Then, the user chooses which of the other identifiers are enabled for use (either: all, first added, or last updated). If they’re enabled, this means that these identifiers can be used for messaging customers and updating and merging profiles. If all are enabled for use, they must choose which is preferred for messaging (either first added or last updated).
The design is set up vertically with distinct steps to encourage the user to progress in the order that makes most sense.
The Profile Rules section takes inspiration from an ID card, with a user icon in the left corner, to communicate that these identifiers all represent data belonging to a single person.
The stable identifier is on top, as its choice influences the information below it. Once a stable identifier is chosen, it moves to the bottom, and only the first added identifier can be enabled or preferred for messaging.
2. Set sharing rules
The user can then choose if they’d like an identifier type to be shared across profiles. This is optional, as a user can choose to have no identifiers shared between profiles. A common example of a good shared identifier is Device ID, since it’s likely that more than one person will share a device, such as a family desktop computer. The user can then choose if they’d like the first added or last updated identifier enabled for use.
All sharing rules should be made very deliberately because sharing could allow for multiple profiles to exist for the same person. To force the user into making a deliberate choice about sharing, no drop-downs are readily available. In addition, the button to add an identifier is greyed out and uses the text “optional.”
3. Configure profiles
Configuring profiles enables the user to recreate a situation that happens often within their own business to test what would happen in Simon. For example, if a customer changes their email address, will they have two separate profiles or will those profiles merge? The user can add up to 4 profiles and multiple identifiers of the same type within a profile, which allows them to represent almost any situation they are trying to test for.
The profiles are filled with dummy data. We decided on this because depending on the customer’s phase of onboarding, we might not have access to their actual customer data to use as an example in the tool. The dummy data gets around this issue while still giving an accurate representation of what that data could look like.
When the user adds a second or more profiles, they can choose for the identifiers to either match the previous profile or get new dummy data. This is helpful for determining if these two profiles would merge based on the identity rules set.
4. Add event
Identity events always contain two identifiers because they create associations between identifiers. A common example of an identity event is a user creating an account on a website with their email address and phone number.
This section follows the same pattern as the previous section, where users can either match the identifier data from the profiles they set up or get new dummy data.
5. Result
After clicking “Run", the user can view the result. One of the following results can happen: 1. Profiles merge, 2. A profile is updated, 3. A new profile is created, or 4. Nothing happens.
The green highlight denotes data that has been added to a profile and the gray highlight denotes data that has been removed. The icons denote which data is enabled and preferred for messaging.
• • •
User testing and launch
For user testing, I would write a script and a list of questions to ask all of the participants. In most cases, we’d ask them to use the feature as they saw fit for the needs of their company. This allowed us to cover different business use cases across multiple participants. I would record all of my interviews and then transcribe and summarize important conclusions.
User testing script I wrote for our Event Triggers product.
User testing would often give us jumping-off points for where to go in further iterations of the product. For example, for our Events Triggers feature, all of the participants indicated that they wanted A/B testing for events, which we later explored. In other cases, user testing results helped us redefine the best users of a feature. For example, for our Identity Sandbox product, we ended up deciding that it was better suited as an internal tool used by Client Solutions analysts to help clients understand the best business rules to choose, rather than the clients using it themselves.
User testing notes and conclusions I wrote for our Event Triggers product.
Upon completion of testing and any changes it led us to, the product would be shipped. Depending on the feature, my product manager and I might have calls with sales personnel to go through the ins and outs and talk about how it could be pitched to prospective clients.