Case Study
Employer hubs - Building team trust through strategic compromise and beta testing
Quick Stats
1,000+
7% to 18%
Job application rate improvement
55
Clients actively using the product
9 days
of development work saved per hub
Project summary
In this project I…
01-02
Translated user insights and competitor analysis into a defined product concept through diagramming, prioritisation and stakeholder reviews
03
Inherited the successor to a failed project, requiring additional stakeholder management and advocacy to build trust and push the design in the right direction
04
05
Ran a beta test to advocate for my design direction with evidence
06
Scaled the design direction across the product to successful user tests
07
Organised user testing, getting the whole team involved to build engagement and morale
08
Shipped a product that more than doubled response rates
01 - The product problem
Jobseekers wanted employer culture, values and qualitative insight
Branded employer pages for job seekers
Branded employer hubs embedded within career centre sites showcasing company culture, values, and career opportunities
A self-service page builder for clients
A self-service page builder. Clients assemble hubs from content sections and publish to their career centre. No developer or design resource required.
02 - Discovery artefacts
Early exploration through flows, diagrams and analysis
Problem mapping
Initial framing: purpose, user groups, early project directions and the questions the work had to answer.
Competitor strategy canvas
Plotting the product against competitors to fix which factors to lead on and which to ignore.
Service blueprint
Front-stage, back-stage and support processes across the five stages of building a hub.
Site map options
Three CMS structures, tested against how owners actually manage employers versus hubs.
Wireframes
Initial concepts, then the revised journey after team review.
Integration & CTAs
Where hubs surface on the jobseeker site without disrupting the apply flow.
The design direction was clear,
stakeholder management was the Challenge
03 - The organizational problem
A failed product impacted the teams judgement
The same team had shipped a similar product before, that failed due to a misunderstanding of the market need.
Increased team scrutiny
The project team had lost confidence and heavily scrutinised anything that diverged from the previous failed project. Leading to an increased need for stakeholder management
PM Cost savings
The PM wanted to reuse old designs from the previous project as this was cost efficient for development. Any extra work requested was a direct extra cost requiring more advocacy than usual.
I was the sole designer, new to this project, with no involvement in the predecessor.
I owned the strategy, research, IA, user flows, and UI. Before I could push the work forward, I had to prove my judgment was worth trusting.
04 - The Research insight
Clients wanted design freedom they weren't trained for
Through research with clients, marketing teams, CSMs and site owners, I found the tension that defined the project. Clients wanted full creative control of the employer hubs they were building, but lacked the expertise to use it well.
Only 1 in 6 clients interviewed understood basic accessibility.
What clients wanted
Unlimited structural control
Freeform colour options
Pixel-perfect customisation.
Designs that match employer's career site exactly
What clients needed
Smart constraints
Accessibility guardrails
Design-vetted templates
Forgiving, responsive layouts
Research evidence
Design tools give users complete creative freedom
but our users were not designers.
05 - The Beta compromise
Using beta testing to support my approach
The PM wanted full colour customisation across the product and the developers had reusable code ready to go. I was new to this team, and pushing against more user control sounded like repeating the mistake that killed the last project.
My compromise: Limit colour customisation to one section, test with beta users, and measure the outcome. Across six users over one month, 5/6 created inaccessible sites with the tool we offered.
The evidence proved our users needed controlled guidance.
Beta results (Before)
Final design (After)
My alternative: Section Styles. Three preset text and background combinations built from design system brand tokens, all WCAG 4.5:1 compliant.
Users still got visual variety across their hub, but every option was accessible by default. Simple choices, professional outcomes.
The outcome
Rolling back the beta required a late-night maintenance session to republish all sites with defaults. This would be very difficult now at 1,000+ live hubs. But it built lasting trust in my design judgment, and Section Styles became the standard across the platform.
Our Users needed constraints and guidance
for consistent, high quality results
06 - Design Approach
Scaling the controlled design approach across the product
Smart constraints over unlimited control
Pre-built components with limited customisation
Responsive by default
Layouts adapt automatically across devices
Accessibility guardrails
Brand colour presets, readable contrast, image ALT text, guaranteed compliance
No design knowledge required
Marketing teams and CSMs can build professional sites with ease
Scalable and adaptable CMS
A design system of menus and components that scale, across a variety of clients, whilst maintaining usability
E.g. 1 - Fixed frames instead of native
I advocated for fixed image frames with transparent backgrounds and fill/zoom controls.
Accepting occasional grainy images for consistent and responsive layouts.
Native resolution (Before)
Fixed frame (After)
E.g. 2- Page dividers over padding control
The client was having difficulty organising long text content. They wanted pixel level padding control. Instead I provided drop in page dividers.
Choosing consistency over freedom
Padding controls (Before)
Page dividers (After)
07 - More User Testing
Building team engagement with team-wide user testing
I invited the entire sprint team to observe user-testing and take part in an insights and solutions workshop.
The team found it highly rewarding to see their hard work performing well with users and had plenty of great insights, and ideas to improve the product.
We tested with 6 users of varying design experience
Research evidence
Positives
Improvements made
08 - The Outcome
Positive results and a scalable product
1,000+ live hubs
Employer hubs built across 55 clients. Significantly better adoption than its predecessor
From 7% to 18% response rate
More than double the application response rates for jobs advertised on employer hubs
80+ hubs created by individuals
Showing a strong product-market fit, and ease of use at scale
9 work days saved per hub
When compared to the manual sites requirement, built internally. A huge operational saving
"It's all easy enough to use. It makes sense and it's very user-friendly."
Abbie Boyd, Operations Specialist, Pharmiweb
"The difference between the two is night and day. It's a lot easier on employer hub."
Kevin Kirchmyer, Sales Operations, Science Careers
The final product
Manage hubs on a dashboard, edit pages, design content in an editor, preview in browser, publish directly to the live site.
The employer hubs
Employer branded mini sites, published across a range of job boards
On Reflection
What I learned
Testing builds credibility
If I had the confidence I had today, I may have pushed harder against colour customisation. But the beta approach built my credibility through shared evidence and my own confidence in the design process. The team saw the problems themselves, not just heard me predict them. This created lasting trust that served the entire project.
Beta feedback is noisy
Opening up a beta generates a lot of input, but users' prescribed solutions aren't always the real need. Two beta users asked us to extend colour control further, which would have made the problem worse. I'll always question whether feedback fits the design ethos before acting on it. Our job is to solve the underlying need, not implement the suggested fix.
What's next?
The biggest barrier that remains is the workload required of small teams to set up many of these sites themselves. The next step is to examine how we can assist our users in creating employer hubs at pace.
I am currenlt exploring AI employer profiles. Using an LLM to scrape data from verified sources (such as the employers career site) and use it to produce a standardised employer profile. This has been successful in text-only documentation. The next step is to collaborate with developers to intergrate this process with the employer hubs tooling.
