Domain verification helps to ensure that only verified website owners claim ownership of their public company profile on Trustpilot.
If a business user opens an account with an email address that does not match their business website’s domain, they are required to verify their domain. After signing up, they will be redirected to the domain verification workflow to complete the setup.
The options available to users wanting to verify their domain were becoming problematic to our colleagues in the Support department as the lack of automation in the workflow resulted in a great number of support tickets that were becoming more and more time-consuming to take care of.
60% of users entering the verification flow needed help from support resulting in a sum of around 150 tickets being created every day.
We needed a solution that would enable users to get through the verification process in a better and quicker way.
On the other hand we wanted to reduce the number of support tickets generated in the flow and get agents back to spend time on other tasks to allow the company to put their focus in the areas where we wanted scale.
Our focus has been improving and measuring the experience for all new users who opened a business account wanting to verify their domain and enter the domain verification workflow.
Considering the seriousness of the problem we have limited the scope to 5 weeks.
As a member of the core team, I was the Product Designer during the project and worked alongside a Product Manager, Engineers, members of the Support team, and UX Copywriters.
I was responsible for defining the overall experience through mapping out the current journey, design ideation, user validation, iteration, prototyping, and crafting high fidelity mockups throughout all stages of the project.
At the outset of the project, I have analyzed the domain verification experience to understand which aspects could be improved. I started by noting the starting position and the user goal and attached screenshots to each step of the journey to visualize what is happening at each stage.
The mapped-out journey has been used to align stakeholders and the delivery team around the project plan and vision. My goal was to avoid jumping to solutions, instead, I was focusing on the underlying problems and insights that can give the team foundational knowledge to base the future solution on.
An excerpt from the slide deck used at stakeholder meetings and presentations
The Product Manager and I have partnered with leaders in Support and a Tech lead to understand the different use cases and their priority and to acquire knowledge as they keenly knew the most common problem areas.
To understand how users use the current solution we conducted interviews with businesses who in the past month signed up for a free Trustpilot business account with an email that did not match their business domain and either:
The mapped out user journey after some of the first interviews being enriched with insights and learnings in a form of post-its
We ask users to sign up with an email that matches their business domain by saying it's going to speed up the process but we don't communicate to them why this is necessary
There is not enough context and guidance provided to users about why they landed on this page, what is the task ahead and what is going to happen
A support article exists in the Support Center but a link is missing from this page
The personas can be split up into two groups defined by the different level of expertise:
Non-tech-savvy: Users who are non-tech savvy would try to verify their domain by the most user-friendly method - Matching email.
Tech-savvy: Users who are tech-savvy would try to verify their domain by the more advanced methods - Google Webmaster Tools or Meta tag.
User doesn't receive a call but an email instead which creates a support ticket
The design was extremely outdated and didn't match the new Trustpilot brand identity that was present on the Signup page
The solution was not fully responsive
Through technical research and evaluation done by the engineering team, we have discovered that there are other possibly simpler methods to verify a domain like DNS and a File upload which we should be part of the future solution
Equipped with an in-depth understanding of the problem, I have invited my team and colleagues from support for a hypothesis creation and ideation workshop which helped us reach a common consensus through:
After gaining a deep understanding of the complexity of the domain verification flow the next step was to begin the redesign stage. I turned the learnings from the previous stage into goals that the solution needed to hit to build a successful product.
Handhold the user throughout the process
Give a sense of progress and provide necessary system feedback
Apply the look and feel of the new brand
Design for desktop with mobile in mind
By now it was clear that copy will be playing a crucial role in creating a successful solution therefore I collaborated with the copy team and created two variations of the design each of them using different labeling and copy.
Better context framing for the user was necessary so they can understand why they have to take action and what options are there to support them on their journey.
Upon landing on this page I wanted users to immediately understand why they have arrived here and what is the task ahead hence the big bold opening title with the supporting description underneath.
Furthermore, I created a guide-like layout where I have split up each method into a separate element, an accordion which upon opening users can get necessary information about what it takes to verify their domain through the different methods available before committing to a preferred way of completing the task.
In order to make it clear to users how far they are on their journey, I have created a stepper component that was placed onto the top of the page providing users with more context about how much of the task is completed and a sense of progress.
If an issue occurs I wanted to tell users what went wrong in a language they will understand and which will be presented with visual treatments that will help users notice and recognize them.
If the user got stuck we opted in to provide help in two ways. Making the Support article available on the page in form of a redirect link and an additional option of filling out a form using a third-party popup solution.
The designs with the two copy variations have been converted into clickable prototypes in order to further test them with businesses who recently signed up for a Trustpilot business account with a non-matching domain email.
I have collaborated with a UX researcher to plan the usability testing by setting up the test goals, defining testing scenarios, and creating a recruitment email.
As I’m figuring these things out I am also leaning on other groups of designers, my team, and our colleagues from the support department for input and validation.
Users understood why they landed on this page and what is the task ahead. The second variation was preferred as there was less text present and the task was clearly stated
The new design was perceived as a solution that would get the user through the process faster than the current and as more aesthetically pleasing and modern
The progress bar on the top of the page was perceived well and users thought it reduces the “sense of complexity”
The split between "Easy" and "More difficult" was not perceived well. Users thought it's adding unnecessary complexity to the task ahead and voiced that having all options on one page would make their job easier
The different verification methods were perceived as individual steps
The third-party pop-up form was confused with a live chat function
Based on the insights at hand we have moved all the methods to the same page.
We put more emphasis on the email method as being the easiest and quickest method for users to get the job done.
We have iterated on the copy of the page by making it shorter and to the point allowing users to understand quickly why they have to perform this task and how to proceed. Tackling the issue of each method being perceived as an individual step we have tweaked the copy for each method by starting with "Verify with"
Based on the user feedback we decided to move away from using the third-party pop-up solution as a way of contacting our support team if the user was stuck. Instead, we have opted for a modal that clearly communicated to users that they need to specify the reason why they were not able to use any of the methods available.
Based on the data we knew that the majority of our users are visiting the app through desktop devices but improving the user interface to provide a better user experience for mobile was an important factor of the design and support for mobile devices had to be part of the solution.
Arriving at the delivery stage I have given a walkthrough of the final design and emphasized all interaction details to the PM and the engineering team. We have also finalized the launch plan including a plan for collecting metrics, getting tracking into place, and setting up screen recording through HotJar to observe any potential UX bugs.
The whole team actively performed QA through the process of implementation and we collectively found solutions for any blockers.
We have planned for a staged rollout launching the new solution for a limited set of users at first. This allowed us to monitor the stability and performance while uncovering certain bugs and iterating to fix broken things as the days advanced putting the new solution under test.
After the new solution was launched, hence introducing a way of contacting support through a form the number of support tickets was drastically reduced.
A month before the release around 60% of people entering the verification flow needed help from support resulting in a sum of around 150 tickets being created every day.
A month after the release around 8% of people needed help from support resulting in a sum of around 10 tickets being created every day while the number of claimed domains remained steady and stable.
