CoreHR / The Access Group
·
June 2016 - Mar 2017
Core HR
A coherent, brandable design direction for a large HR suite across desktop and mobile, handed over to a team without in-house designers.
Role
UI / UX Designer
Timeline
June 2016 - Mar 2017
Team
Head of Product, engineering and product teams
Platform
Web / Mobile
Overview
One design direction for a sprawling HR suite
CoreHR builds HR, payroll and workforce software for large organisations, and is now part of The Access Group. When I joined, its suite had grown to more than 200 products across Sencha-based and legacy Oracle systems: separate applications for tasks such as booking holidays, claiming expenses, recording overtime and running reviews, many of them designed in isolation, with screens and patterns that had evolved separately. I was brought in to review the existing interfaces and set a more coherent, brandable design direction across desktop and mobile. Working with the Head of Product, engineers and product teams, I defined how an established suite could look and behave as one product family. It marked my move from designing individual screens to product-wide design.
200+ products
Holidays, expenses, overtime, reviews and more, across Sencha-based and legacy Oracle systems
Representative screens
Key screens and patterns chosen to set direction for the whole suite
White-label direction
A dashboard structure designed to carry each client's brand
Challenge
Consistency at the scale of a whole product suite
The products had grown up across different technologies and teams, so the same tasks looked and behaved differently from one part of the suite to the next. The suite also had to be white-labelled for client organisations, and the team wanted a direction that felt distinct from a conventional SaaS dashboard. Redesigning every screen was neither possible within the engagement nor the point of it. In early conversations with the teams, I proposed a different approach: set a direction CoreHR's own teams could carry forward.
How do you set a coherent direction for a suite this large without redesigning every screen, and leave a team without in-house designers able to carry it forward?
Approach
Representative screens, repeatable patterns and a direction to hand over
Reviewing the suite
I started by reviewing existing designs across the suite and travelling to Ireland to meet CoreHR’s product leaders, engineers and wider team. Those conversations grounded the work in how the products were actually built and used, and showed which recurring layouts, navigation and dashboard patterns had diverged from one product to the next.
Choosing representative screens
With the teams agreed on setting a direction rather than redesigning screen by screen, I chose the screens to carry it: key examples of the layouts, navigation and dashboard patterns that recurred across the suite.
The redesigned employee dashboard: the direction in one screen.
Left Existing layouts beside proposed ones. Right More before-and-after pairs.
I redesigned representative desktop and mobile screens, setting existing layouts beside proposed ones so the reasoning behind each change was visible. Because every decision was made at the level of a pattern rather than a single screen, it could be applied well beyond the screen it was shown on.
Left The dashboard pattern repeated across modules. Right The same direction on mobile.
The direction moving across desktop, tablet and mobile (video).
Designing for many brands
CoreHR’s product was sold to client organisations who wanted it to carry their own brand. I explored how the dashboard could take on different identities, using well-known retail and sports brands as test cases, while keeping a coherent core experience. That meant separating what had to stay constant, such as structure, hierarchy and interaction patterns, from what each client could make their own.
The direction drew on the design thinking of the time: a flat, card-based language, influenced by Material Design, that could organise very different content into consistent tiles, scale from desktop to mobile and give each client a clear place for its brand. The same work answered the team’s wish for a dashboard that felt distinct from a conventional SaaS product, without trading clarity for novelty.
White-label explorations, using well-known retail and sports brands as test cases for the dashboard’s flexibility.
Handing over a direction
CoreHR didn’t have an in-house design team at the time, so the handover had to carry the work on its own. I delivered design files and annotated screens, presented the direction to the team, and walked them through it in detail, so product and engineering could extend it across the wider suite with confidence.
Outcome
A direction the suite could grow into
CoreHR came away with a coherent design direction for its product suite: redesigned representative screens across desktop and mobile, the recurring patterns behind them, a white-label dashboard structure, and annotated files and walkthroughs that equipped its product and engineering teams to continue the refresh across the wider suite.
A suite-wide direction
Redesigned representative screens that set the standard for the wider suite.
Repeatable patterns
Recurring layouts and components the team could apply product by product.
White-label dashboards
A stable structure that could take on each client's brand without losing coherence.
A handover that stands alone
Annotated files, a presentation and walkthroughs for a team without in-house designers.
Status
Design direction and handover delivered
Design direction and handover delivered
Reflection
Scope is a design decision
At the scale of a whole product suite, choosing what not to design matters as much as the screens you do. Picking representative screens and the patterns behind them turned an impossible redesign into a direction a team could own. I start large, messy briefs the same way: find the few decisions everything else can inherit. Looking back, the dashboard is where I'd push further. The team wanted something more desirable than a typical dashboard, and the exploration went some way there, but it needed more iterations, and a clearer case for departing from the conventional pattern, than the engagement allowed.
