Building a help centre.

Role & responsibility

Senior UX Designer
Page builder
End-to-end ownership

Timeframe

March – June 2025

TEAM

1x UX Designer
5x Copywriters
1x SEO specialist

SKILLS

UX research
Data analysis
UX / UI Design
Wireframing
Page building
A/B testing

TOOLS

Figma
Microsoft Clarity
Google Analytics
WordPress

Overview

From an FAQs page to a help centre hub.

Babbelforbusiness.com had a simple FAQs page covering common questions asked about the business and the products (you can see this old page design here).
This project was to see where the FAQs page could be improved from a user and business point of view.

I worked closely with a content team of five copywriters and an SEO specialist, and collaborated across product, marketing, sales, and development – navigating each team’s different priorities to get everyone pulling in the same direction.

Long story short, this resulted in a big transformation from a single page into 50+ page help centre ‘hub’.

Impact

73% increase in CTR

Users reaching high-conversion pages more than ever before

Bounce rate reduced by 38%

Users exiting the site reduced significantly

61% more organic traffic

28% reduction in support tickets

Cutting red tape and reducing time for users and the team

THE PROBLEM/S

1. Poor usability.

Looking into the original design of the FAQs page as shown here, there were several clear usability issues from the design alone:

The page presented only 14 questions (it’s very likely a user would have a question that isn’t covered)
There’s no search bar for specific topics (users were having to scroll or ‘Cmd F’ – which is not optimal for mobile)
Questions were grouped into only 3 categories with no visual hierarchy
There was no use of space above fold
All content was on one page displayed in accordions (not best for SEO practices)
Internal linking had much room for improvement (links to the home page, links to Babbel’s B2C website, etc.)

2. User and business goals not being met.

Due to the lack of content on the page, crucial UI elements missing, and the poor internal linking, it was clear that both user goals and business goals were not being met.

User goal: Getting answers to their questions (it is an FAQ page after all).

Business goal: To drive those users from that page to higher priority pages that might turn them into paying customers (product pages, demo page, etc).

USER RESEARCH

Data findings.

Data confirmed the UX wasn’t performing well & suggested the page wasn’t meeting the user goal of having questions answered or the business goal of conversions.

For example:

The page had a bounce rate of 55%
Heatmaps showed the most clicked on item on the page was the ‘‘what product options are there?” FAQ (this helped lead other projects to make our products much clearer from the get-go.)
46% of users were scrolling to the bottom of the page (you’d hope half of users wouldn’t need to scroll that far to find answers)
The 9th most clicked on element on the page was the ‘contact us’ CTA – suggested again that questions aren’t answered by the page alone.

This highlighted what we needed to do:
Increase questions and make them easier to find

COMPETITOR RESEARCH

Clear patterns emerging.

Another important step when it comes to page optimisations is seeing how competitors are doing it differently. I looked at several close competitors in the language learning space and also some B2B SaaS companies.

While this isn’t a one-size-fits-all approach, there was a clear pattern emerging that you can see in the screenshots. Instead of an FAQ page, they had a help centre. With a clear cut design, question categories and a search bar placed centre above the fold to ease navigation.

DESIGN DECISIONS

1 page FAQs → 50 page help centre hub.

Based on data findings and competitor research, it became pretty clear that a single FAQ page just wasn’t going to cut it. The idea of a three-stage ‘hub’ started to take shape.

Overview page

Featuring search bar and showing roughly 5 categories

Category page

Parent page showing roughly 10 questions per category

Question page

An individual page of copy for each question

The three-stage structure was a deliberate choice. From a user perspective, it gives people multiple ways to find what they’re looking for – whether they search, browse by category, or land directly via Google. From a business perspective, having each question on its own page is a much stronger setup for SEO, and more pages means more opportunities for internal linking to higher priority pages.

Deciding question categories.

Settling on the right five categories took a bit of lateral thinking. I pulled from three different sources:

The existing categories on the old page (the product FAQ being the most clicked was a useful signal)
Responses from the ‘Contact Us’ form (I collated the ‘how can we help you?’ field responses from the ‘Contact Us’ page and ran them through AI to find the most common themes)
A cross-check against competitor category structures.

Where all three pointed in the same direction, I felt confident. The result:
Getting started, The Babbel App, Babbel Live, Administration, Technicalities.
I brought these findings to the wider team for a final sense-check before committing, getting early buy-in here made the stakeholder pitch much smoother down the line.

WIREFRAMES

LoFi wireframes > prototypes.

The next step was wireframes. As usual with my process, I started with LoFi sketches to map out the three stages before committing to anything higher fidelity.

For the overview page, the structure was built around two types of user – those who know what they’re looking for (search bar, above the fold) and those who are browsing (categories directly below). A ‘Contact Us’ CTA and helpful resources section were added lower down as a safety net and to keep users engaged with the site, while other elements like a featured articles section were considered and ruled out for adding noise rather than clarity.

The category and question pages were deliberately stripped back to help users easily find what they’re looking for. Once the structure felt right, it was time to build a HiFi prototype across all three stages.

OVERVIEW PAGE

Category PAGE

Question PAGE

CHALLENGES

Pitching to stakeholders.

Once the visualisations were ready, the next step was to share this with the team working on it and pitch the new design to other stakeholders involved.

The main challenges here were:

Getting everyone on board – this was a project that involved many stakeholders with many different opinions (developer, content, marketing, product, sales)
Workload – 50 questions x 6 geos = 300 pages of content needed to write and upload (between 5 copywriters)
Timelines – we aimed to get this live by the end of Q2 (giving us just 2 months to work on it).

To get everyone on board, I framed the proposal around shared business goals rather than UX metrics alone – once the conversation shifted to Better UX → lower bounce rate → more conversions → higher ROI, it clicked for everyone. Getting that alignment made execution a lot smoother across such a large, cross-functional team.

ITERATIONS

A/B testing.

While building the pages in WordPress, I A/B tested certain elements of the hub including:

The order of the categories: chronological vs alphabetical – chronological had 16% lower engagement time on the main index page (meaning the user was navigating through faster).
Displaying the first line of the questions (as shown in image): This had an 8% higher bounce rate so we decided to only show the question.

This data suggested a simpler, chronological design was the best approach.

There were other elements that could have been tested here (for example CTA placement, where to display the categories, etc), however we were tight on time so had to limit tests. Decisions on what to prioritise were made collaboratively with the team based on what would have the biggest impact on our goals.

Final Design

Before.

After.

OUTCOME

The result.

Once built, the new design of the help centre hub showed a significant improvement in terms of user experience.

73% increase in CTR

More users reaching high-conversion pages like demos and pricing than ever before

28% reduction in support tickets

Users finding answers themselves – without needing to contact the team

Bounce rate reduced by 38%

From 55% down to 34% – users were actually staying and exploring

61% more organic traffic

300 individual pages meant 300 new opportunities to be found

LEARNINGS

Key takeaways.

Gain stakeholder alignment early

With a project this size, the timeline was always going to be the biggest risk. 50 questions across 6 geos means 300 pages of content, and we had two months. In hindsight, getting cross-functional sign-off earlier and aligning the whole team from the start would have given us a lot more breathing room and more time for A/B testing, which felt a bit rushed towards the end.

Qualitative research would have added a lot here

This project ran entirely on quantitative data, which served us well. But if I were to do it again, I’d push harder to speak to actual users. Whether that’s a quick usability study or a few informal chats, hearing people explain their frustrations in their own words would have added a layer of confidence to the decisions we were making from numbers alone.

Sometimes the best data source isn't the obvious one

Honestly, one of my favourite things about this project was realising that the ‘Contact Us’ form was a goldmine, giving us access to real users and real questions which we were lacking due to our quantitive methods. It’s a good reminder that useful data doesn’t always come from the tools you’d expect and to think outside the box here.

Work with me.

Get in touch to work together or just for a virtual coffee and a chat.