Employee benefits · UX research & design
A self-service help center where families answer their own benefit questions, from Back-Up Care days to EdAssist reimbursements, before they ever call support.
Role
Research, copywriting, UI design, user testing
Stakeholders
Engineering, 5 product managers, support team
Testing
Card sort, usability test with 10 users
Result
Reduction in support calls, data identifying gaps in products
Bright Horizons provides employer-sponsored family benefits: center child care, back-up care, nannies, elder care, tuition assistance and college coaching. Members needed a fast way to resolve product issues and get answers to the questions they kept asking about their benefits.
MVP goals
Reduce the support team’s workload
Help users find answers on their own
Show where product knowledge is missing
This project started with a different request. The support team asked me to make their intake form harder to fill out, hoping fewer customers would submit tickets for small questions.
I pushed back. Adding friction would frustrate members without answering their questions, and the calls and tickets would keep coming. The real problem was that nothing in the product answered common benefit questions, so every one became a call or a ticket. Members needed somewhere to help themselves first, and that became the help center.
I grouped incoming support contacts by topic. Benefit questions, across every product, were the largest share. The rest were spread across client set-up, Center Finder, account, payment and technical issues.
Benefit questions were the largest share of support contacts
Led to benefit shortcuts on the home page
Each product had its own manager and its own idea of how help should be organized
Led to a card sort and one shared structure
Members had nowhere in the product to look up an answer
Led to search-first help with a clear way to reach support
1
Align
Set three MVP goals with engineering, five product managers and the support team.
2
Card sort
The teams could not agree on a structure, so I ran a card sort with every team and with new Bright Horizons customers.
3
Structure
Turned the pattern from the card sort into an architecture diagram that won stakeholder buy-in.
4
Wireframe
Wireframed the home, product and article pages in the product’s visual direction.
5
Test
Usability-tested with 10 users. 9 of 10 navigated the help center without help.
6
Refine
Closed the remaining dead ends and designed the help center for desktop, tablet and mobile.
With five product managers, engineering and support all involved, we could not reach consensus on how to structure the help center. I suggested a card sort with input from every team and from new Bright Horizons customers. Giving each team a say, alongside real customer data, surfaced a shared pattern: people look for help by product first. I turned that pattern into this diagram to win buy-in on the first architecture.
The architecture stakeholders signed off on: three ways in from the home page
Search
Search results lead straight to an article. A search with no results shows popular articles and lets people search again.
Help by product
Account issues plus four products, each with its own sub-sections and lists of articles.
Popular articles
The 10 to 15 most visited articles, one click from the home page.
Once stakeholders agreed on the structure, I wireframed the three core pages using the product’s visual direction and patterns from modern help centers.
Home: search, help by product, popular articles
Product page: sub-sections and their articles
Article: content, feedback and suggested articles
Decision 1
Let customers settle the debate
A card sort with every team and new customers replaced opinions with a pattern everyone could see.
Decision 2
Organize by product, not by team
Members know which benefit they have, not which team owns it. Each product kept one color from home page to article.
Decision 3
Lead with benefit tasks
Benefit questions drove the most support contacts, so the home page puts those tasks before anything else.
Decision 4
No dead ends
Every search, article and “no” answer ends with a next step: a related article or the right support team.
The final flow keeps the three ways in from the original architecture and adds a next step everywhere a member used to get stuck.
Search suggestions
Matching articles appear while members type, so many never need the results page.
No results
Suggests a spelling, products and popular articles instead of an empty page.
“Not helpful” follow-up
Asks what went wrong, then offers related articles and the right team.
Contact us
Routes members to the support team for their product.
Six screens, each annotated with what changed from the wireframes and why. No results and Contact us were added to close the flow’s dead ends.
Select a small marker to open its note. Use Markers off for a clear view, or compare the screens side by side.
Screen 1 of 6
Home
Members can search, start a common benefit task, or browse by product without scrolling past the first screen.
Final design
Screen 2 of 6
Search results
Suggestions appear while members type, and the results page answers the most common questions before they click.
Results page
Screen 3 of 6 · New
No results
The original architecture called for popular articles when a search came back empty. This page turns that dead end into four ways forward.
Screen 4 of 6
Product page
Every topic for a product on one page, so members scan instead of opening sub-sections one at a time.
Final design
Screen 5 of 6
Article
Answers are written as short steps members can follow, with a clear next step whether the article helped or not.
Final design
Screen 6 of 6 · New
Contact us
When self-service runs out, members reach the right team the first time, with one last chance to find the answer themselves.
Contact us
Responsive
Every screen was also designed at 834px and 390px, so members get the same help on any device.
Tablet, 834px
Home
Product page
Article
Mobile, 390px
Home
Search results
Article
Grids step down
Product cards go from three columns to two on tablet, then to a single list on mobile.
Sidebars become chips
The product page’s topic list turns into a row of chips above the topic cards.
Help stays in reach
On mobile articles, a Contact us bar sits at the bottom of the screen.
What we tested
After stakeholders approved the visual direction, 10 users tried to find answers in the help center
What we learned
9 of 10 navigated it clearly. The final design closes the dead ends that remained.
users navigated the help center without help
shared structure agreed by engineering, 5 product managers and support
breakpoints designed: desktop, tablet and mobile
What worked
The card sort. Giving every team a say, next to real customer input, turned a stalled debate into a structure everyone owned.
What was hard
Getting consensus across five product managers, engineering and support, each with their own view of how help should be organized.
What I would change
Track empty searches and “not helpful” answers from launch day, so the help center shows exactly where content is missing.