A brand-new product that allowed the company to perform a fundamental strategic shift.
Equipped with a drag and drop interface, it enables non-technical users in creating a GDPR-compliant preference center.
- No similar products on the market. Privacy regulations were a new thing, and existing preference centers were not built with them in mind.
- Personas having divergent needs: the Data Protection Officer and the Head of CRM.
- The absence of a legal department. Researching the legal constraints posed by the privacy regulations was an additional effort along all the process.
A preference center is a web page brands provide to their customers to let them manage their options related to the communications they receive. More recently, they have also used to ask customers’ preferences over specific topics.
A customer’s preference center.
While these kinds of products are not new, the advent of privacy regulations is rapidly changing their legal requirements and increasing their importance for the company’s digital strategy.
Since they collect customer personal information, they now must comply with the European GDPR (General Data Protection Regulation). They need to collect, manage, and store the user’s consent.
In addition, because of the upcoming ban on third-party cookies, preference centers are becoming a primary tool to profile customers. Each company is interested in asking a different question to their customers, and while Decathlon.com would ask about your favorite sports, Booking.com would probably ask about your favorite city.
The fact that this product lies at the intersection of the legal requirements (it needs to comply) and the marketing needs (it needs to profile) makes it unique.
The Product vision board that I created during the research. It was also useful in aligning the internal stakeholders.
The company already created ad-hoc preference centers for some clients. They were built in the context of a consultancy project, meaning it didn’t approach it as a SaaS product.
Nevertheless, their users were a good starting point for our research. We interviewed them, built the journey maps, and mapped the pain points.
Journey Map based on one of the interviews. It allowed us to map their pain points.
In parallel with the interviews, I run a few workshops with the internal stakeholders to explore the different points of view and align the expectations. Workshops were run online on the Miro platform, since we were working full remote.
The output of one of the internal online workshop. Participants started converging on a general idea about what the product was about.
Through internal and external interviews, I found the two proto-personas I needed to keep an eye on:
- The Data Protection Officer (DPO)
- The Head of CRM (HoCRM).
The DPO’s mission is to make the company compliant with the privacy regulation. Thus, they are a significant stakeholder and a potential user. They want to validate how the personal information is collected from the customers and have constant visibility over it.
Proto persona of the DPO.
The HoCRM needs to profile the customers to increase the marketing campaigns’ efficacy. They want to be able to collect whatever preference they need from the customers without waiting for external validation.
Proto persona of the Head of CRM.
The conflict of interest of the two proto-personas highlighted the first problem we needed to tackle.
Our answer to this question, which came after more research and a lot of prototyping, was that the DPO should set some boundaries, and the HoM should be able to act within them.
Testing the Prototype.
I created the prototype in Figma, the result of several iterations over a few weeks.
I imported it into Maze since it allowed me to keep track of the testers’ behaviors and easily gather insights. In addition, Maze enables a better organization of the flows, and it allows adding comments and contextual instructions for the testers, making it possible to run asynchronous user tests.
The first batch of testers was composed of people from the product team, and I conducted the testing in a video call, with the user sharing their screen. After the tests, I reworked a few areas of the prototype.
The second and third batches were asynchronous: I shared the prototype link with a few people from different departments, analyzed the insights, and reworked some details.
Finally, the prototype was also exposed to a few prospects that gave their availability for an interview. The prototype was solid enough, so only small details were changed at this point, so I started onboarding the UI designers.
The report with the user tests insights, generated on Maze.
Video: the Maze report with the user tests insights.
The DPO can set the most critical legal boundaries of the tool by defining for which purposes personal information is collected from the customers. This is related to a very strong GDPR requirement that states that every time personal information is collected, the company must declare its purpose.
In other words, a company collecting customer information (preferences included) must explain how they will use it. Declaring the wrong purpose would represent a privacy breach, exposing the company to legal and financial risks.
The interface for the DPO is a “tree builder”, where they can add purposes in first places and then nest the preferences under them, creating a logic and visual relation between the two. This assures that each preference is linked to a purpose and allows clear visibility of the entity’s relations.
One of the prototypes, showing how the user can define relations between purposes and preferences by adding them to the Configuration Tree.
Video: Using the Configuration Tree on the final product.
This solution is also valuable from a technical perspective because it’s easily translated into a versioned JSON used to save the user’s consent, complying with the GDPR requirements.
The tree, which we call Configuration Tree, creates the boundaries that the HoCRM will use in the preference center creation.
Although the HoCRM can contribute to building the tree by adding new preferences, they operate mainly on another interface: the Preference Center creator.
Their primary need is to be able, through the preference center, to provide customers with specific questions so that they can express their preferences.
Their interface displays the tree created in the Configuration tree, and they can select which one must be displayed to the customers, customize both the wording and the style as much as needed, and finally publish the preference center online.
The prototype showing how the user can create and customize a preference center based on the defined Configuration Tree.
Video: Creating a preference center on the final product.
So, while the relations between purposes and preferences are defined with or by the DPO, they can freely configure the preference centers.
It is worth noting that they can create and publish several preference centers with different configurations, enabling customer segmentation or allowing another brand to have a different preference center. No matter how many preference centers they publish, the Configuration Tree will act as a single source of truth, making them compliant with GDPR.
All the work, from the discovery phase to the validation of the prototype, was conducted by me in partnership with a Product Manager.
We had daily discussions, and we challenged each other ideas in a very constructive process. We engaged the tech team for the feasibility, the product and customer support team to gather business insights, and interviewed prospects to collect user needs. We finally defined a synthesis of what we wanted, and I transformed it into an interactive prototype.
The prototype, built with Maze, was tested with 30+ people from all the departments and a few external prospects.
During the following phases, I onboarded the UI designers to refine the interface (the design system was still under definition) and supported the dev squad in starting to build the product.
Unfortunately, during the development phase, I was assigned a new product discovery and had to manage my time between the two projects. Nevertheless, I genuinely believe in the value provided by designers working shoulder-to-shoulder with developers. This is why I tried as much as possible to participate in the squad’s refinement meetings, supporting them with new design solutions every time an issue was detected.
Following the end-to-end process, from the product discovery to the release in production, is what I love doing. I enjoyed working on this product, and I was able to deliver critical contributions.
The product is now part of the Didomi suite and represents a milestone in the brand repositioning towards a post-cookies scenario.
In addition, the user experience and some interaction patterns I designed were quickly adopted as internal standards for other company’s products. Things like the header, the step-by-step flow, the left panel organized in tabs, the clickable preview, and the drag-and-drop interface are now consistently used across the Didomi product suite.