Client Specific Presentation Ordering & Tracking System (C‑SPOTS)
I optimized a B2B’s client portal with clearer UX writing and more intuitive user flows.
The modifications resolved client pain points and saved valuable staff time.
COMPANY OVERVIEW
Research Director Inc. is a media consultancy, specializing in helping radio stations grow their ratings and revenue.
The company tracks client’s ROI from customized Client Specific Presentations (CSPs), which are data-driven slide decks for radio salespeople to pitch advertisers.
In 2018, the company launched a web-based client portal called the Client Specific Presentation Ordering & Tracking System (C‑SPOTS).
Clients use C-SPOTS to request and download presentations, as well as provide feedback and outcomes.
PROJECT SUMMARY
After working with the client portal for a few years, some problems began to emerge.
We fielded too many questions from clients due to suboptimal user flows.
Staff was wasting time reaching out to clients and reading irrelevant emails.
The back end design left too much room for human error.
ROLES & RESPONSIBILITIES
I worked with stakeholders to pinpoint the issues, and we partnered with a Web Developer to execute the changes we wanted to make.
TIMELINE & SCOPE
We wanted to complete the project in Q1, and we had a limited budget. There were 4 key areas that we wanted to address.
Suboptimal User Flows
1
Clarity of Labels and Help Text
2
Form Options and Defaults
3
Preventable Human Error
4
DISCOVERY
I started by meeting with our client-facing employees to learn about their experiences with the client portal.
I set up interviews with members of the Client Services team to determine:
Where are clients getting stuck or confused?
When are we reaching out to the client for additional information?
What would they change about the client portal and why?
I learned that small things were leading to wasted staff time and inconveniences for clients.
The result was a list of problems and pet peeves.
UX WRITING & REQUIREMENTS DOCUMENTATION
I translated what I learned from the stakeholder interviews into requirements to get estimated by the Web Developer.
Step #1:
Identify the root causes of problems that staff and clients were encountering.
Step #2:
Optimize the UX writing.
Step #3:
Create functional requirements.
CONSTRAINTS & FEATURE PRIORITIZATION
Our budget wouldn’t allow us to implement all the changes, so I determined what would give us the most bang for the buck.
Low-risk changes, like edits to static text, were straightforward.
Complex changes required evaluating cost, risk, and benefits to set priorities.
I presented my recommendations to the CEO for final budget approval. Once decisions were made, the Web Developer got started.
KEY AREA #1: SUBOPTIMAL USER FLOWS
We received phone calls from clients who were confused about how to reset their password.
Before: Native WordPress password reset functionality.
After: Custom password reset functionality with clearer messaging and optimal flow.
We also received phone calls from clients who were confused about where to find their materials.
Before: Market Materials/FAQs button brought links to top of screen – but users with large monitors wouldn’t see any change.
After: Market Materials/FAQs button brings user to a new page.
KEY AREA #2: CLARITY OF LABELS AND HELP TEXT
Staff sometimes needed to follow up with the client if there was a misunderstanding with the request form submission.
Before: Some help text was unclear, and color contrast didn’t pass the most basic WCAG guidelines.
After: Clearer help text and 7:1 contrast ratio.
Staff was wasting time reading irrelevant emails.
Before: Vague field label led to clients providing comments on the feedback screen that didn’t need our attention.
After: Explicit field label plus indication that comments are optional.
KEY AREA #3: FORM OPTIONS AND DEFAULTS
With over 7,000 presentations under our belt, we knew how often clients chose the various options in the drop-down menus.
Before: Defaults weren’t the most common selection, or there wasn’t a clear majority.
After: Defaults are the most common selection, or clients are forced to select an option.
Clients would occasionally request presentations for delivery the same day, which wasn’t always feasible.
Before: We asked for 2-4 days notice, but didn’t require it.
After: Clients could not submit requests for same-day delivery after 12:00 pm ET.
KEY AREA #4: PREVENTABLE HUMAN ERROR
When a presentation was ready, we would upload the file and change the status on the back end, which auto-generated an email to the client.
Before: If we forgot to upload the file, we could still change the status – but the link in the client email wouldn’t work.
After: We added a pop-up to warn us when we changed the status without uploading a file.
TESTING
After the changes were implemented on our staging site, I conducted functional and regression testing.
I had already created a comprehensive website test plan, so I just needed to isolate the areas that could be affected by these changes.
ONBOARDING
Before deploying the changes to our live website, I prepared both staff and clients.
Documentation
I updated internal procedural documentation and our client guide for portal usage.
Staff training
I met with staff to explain the changes and how they (and the client) would benefit.
Client announcements
I sent two client updates: one pre-deployment to address questions, and the second at the time of deployment, reminding clients what was changing and why.
OUTCOME
The implementation was a resounding success! We resolved key UX issues for clients, and saved valuable staff time.
Decrease in incoming calls from clients who were having trouble resetting their password.
Decrease in incoming calls from clients who were confused about where to find their materials.
Reduced need to call clients to clarify form selections or gather additional information.
60% fewer auto-generated emails with trivial comments from clients.
Eliminated errors of notifying a client that their presentation is ready when staff forgot to upload it.
LESSONS LEARNED: MANAGING STAKEHOLDER EXPECTATIONS
Just because something “seems simple,” doesn’t mean it’s simple to implement from a technical standpoint.
Stakeholders may fixate on something they think should be simple to change.
Bridging the gap between technical and non-technical teams requires clear and concise communication.
View other case studies: