top of page

Daltons Email Alerts

Auditing the User Flow

Project Summary

Overview

The email alerts feature was first launched to aid buyers in their search for businesses that matched their preferred business type and location criteria. It originally existed as a standalone page, which was accessed by a sub link on the primary navigation. 

Due to its obscurity and the fact that it was not intelligently integrated into our search results functionality, the facility was only used by around 30% of users searching for a business.

As the need arose to provide users with tools in aiding their searches, the feature was updated. Users could now perform a search and then have the option to save the search parameters as an email alert for any new businesses published to the site that match those criteria. Buttons to create alerts were added to the homepage advanced search section and on the business results pages. This resulted in a significant increase in users creating email alerts.

Conduct a usabiltiy audit and identify issues with the aim of improving the email alerts functionality and user flow for new and existing customers. 

search-box-email-alert-button.png

Problems with the Current Implementation

Due to a lack of resources at the time, and as the product seemed to have met it's original goal of increasing the volume of email alerts, testing after launch was minimal and mostly limited to checking the functionality (change criteria/change frequency/delete alert/add alert) and backend data capture.

Within a few weeks after launching, there were a few issues reported by users. The support team assisted users who were having difficulty setting alerts and the assumption was that they were user related issues and not platform issues. 

After a couple of months and many support tickets later, it became apparent that there was a problem with the functionality of the email alerts system which was causing friction with users.

User Research Methods

I read through the support tickets and tried to identify any commonalities in their content that would indicate where an issue could be lurking. I found a pattern emerging that hinted at what stage in the process the issues could be arising. Based on the user feedback, I summarised the problem into 3 main phrases:

"I can't find..."
"How do I find... "
"Where do I find..."

As part of this audit, I referred to an empathy map and x2 user personas that I had previously created to represent our business buyers. These were valuable in depicting the goals, aspirations and motivations of our business buying audience and helped guide me in developing a valuable and reliable email alerts feature.

Business buyer - Empathy map.png
Business buyer - Persona 2.png
Business buyer - Persona 1.png

Job Story:

When a business buyer creates an email alert, I want to ensure that the user is aware that the alert has been created, without interrupting their current task of searching for a business.

Business Buyer Statement:

As a business buyer, I want to easily set up email alerts, so that I can find out about new businesses that interest me.

I researched three of our competitors and other consumer sites to assess how easy and intuitive it was to set up email alerts on their platforms. I noted friction points I encountered and what I thought they were doing well. I then developed a new customer journey map.

Email alerts - User journey.png

Roles and Responsibilities

Being part of a small design and development team, I was able to take on multiple roles for this project, which included:

1. User research analysis
2. Competitor analysis
3. UX design
4. UI Design
5. Project management of bug fixes/improvement tickets
6. Testing and post deployment iterations

As the user feedback we already had was enough to make assumptions on where the issues were arising, and as the problem needed immediate attention, I did not require any further user testing at this stage. I decided best way to identify any potential issues would be start my own testing.

Scope and Constraints

The main goals of this audit were to:

- Identify and resolve any key usability issues
- Identify and resolve any key functionality issues
- Improve the task flow

Tertiary goals included:

- Make visual improvements if required
- Reduce the amount of related support tickets

I summarised the actions required into 4 steps:

1. Test frontend task flow/user flow
2. Test alerts functionality 
3. Test backend data capture
4. Check alert email generation and deliverability stats

The Auditing Process

My testing protocol:

1. Select a business type and/or location and Search
2. Click "Create an alert button"
3. Enter details to create an account / login to existing account
4. Check if alert has been created  - via dashboard/Navigation link
5. Check backend to see if alert parameters have been added to the user's profile
6. Check email alerts report to see if alert/user details have been added
7. Amend/Delete alert and re-check backend user profile and report for updated changes

Any testing would have to include the same scenario for each role. I created my test user accounts and documented the steps of the process for each user. I used Photoshop to arrange my screenshots sequentially so that I could create a visual representation for later comparison and presenting to stakeholders.

When creating an alert, the profile of the user can have 1 of 3 roles assigned:

1. New user
2. Existing user (logged out)
3. Existing user (logged in)

The issues became apparent within the first few minutes of testing, one of the flows had a critical error, whilst all 3 flows were also inconsistent.

1. New user

Post registration, the user is returned to the listings page from the registration page, but the email alert was not saved, and the users original business type and location selection was cleared from the search fields. The user was not immediately aware that the alert had not been created (the assumption is that the site has saved their preferences), and they now had to re-enter their original search parameters.

So in this scenario, if they user did not receive any alerts in the days/weeks following, they would assume that no new businesses were matching their criteria, and be unaware that an alert had not been set up. This was obviously a major issue which I flagged immediately with the development team. Further investigations from the developers revealed that this bug was related to a deployment of a non-related project and had occurred 12 days ago.

Email-Alerts-New-Users.jpg

2. Existing user (logged out)

Post login, the user is redirected to the email alerts page from the login lightbox, which is an abrupt interruption in their flow of searching for a business. To continue in their search, the user now has to navigate back to the homepage/listings page and re-enter their original search parameters as these had been cleared during login.

So although the alert had been created, the user was unnecessarily diverted from their main goal of searching for a business, just to be redirected to what was essentially a confirmation that the alert had been set up.

Email-Alerts-Existing-Users-Logged-Out.j

3. Existing User (logged in)

After creating an alert, the user is scrolled up to the top of the page and a success banner appears under the main navigation which confirms that an alert was created. This was an annoying interruption in the user flow just to see a confirmation message.

Email-Alerts-Existing-Users-Logged-In.jp

Actions Taken

I re-mapped the email alerts task flow so it would be a consistent experience for new and existing users, regardless if they were logged in or not. I alerted the development team to the fact that alerts for new users were not being created when the user created an account. 

I removed the redirection to the email alerts page and also the success banner at the top of the page. 

Searching for a business is the primary goal of the user, and setting and alert is a tertiary action. I designed an alert confirmation lightbox popup that would appear once the alert was created and saved in the database. This modal also had a link to the email alerts page and a button to dismiss the notice. This modal was the maximum interruption I would allow in the user flow.

I also made the business category and location fields "sticky", so that any values entered would be saved in their respective fields, thus eliminating the need for the user to re-enter these values.

Instead of only sending the email alerts, we also added a confirmation email that is sent when the user sets up their first alert, which links back to the email alerts page. The function of the email is twofold, a secondary confirmation and introduction to the email alerts page, where email alerts can be set up without the user having to perform searches.

Summary of Improvements:


- Consistent task flow
- Alert confirmation lightbox popup
- Removed re-direction to email alerts page
- Removed success banner at the top of the page
- Added functionality to check for duplicate alerts
- Added alerts confirmation email

New User Email Alert Task Flow.png
Existing User - Logged Out Email Alert T
Existing User - Logged In Email Alert Ta
User Flow Chart- Email alerts.png

Key Outcomes

The use of the email alerts feature increased substantially and is now a very popular tool which results in users returning to the site and enquiring to businesses. This has also had a positive effect on our relationship with business transfer agents, who are processing more enquiries as a result. More time resources have also been invested into improving the accuracy and relevancy of the feature. 

The most important lessons learned from this audit is that before and after launch testing must be vigorous and sufficient resources need to be allocated to the task. User issues need to be investigated thoroughly and we should not always assume that the user is at fault.

The tool will be reviewed regularly as part of the project life-cycle, with further enhancement such as increasing visibility on mobile and introducing more filters (price/profit/turnover) currently on the product backlog.

bottom of page