Remodelling the blog header

Posted in: Front-end development

How we ended up with two different headers

In 2017 we commissioned an external agency to build us a theme for, our WordPress multisite. The header was based on the look and feel of our site at that time:

Screenshot showing the previous blog header.

Why we wanted to update the header

Since 2017 we've made a lot of changes to the design of so the header used on our blog site started to look outdated and out of step with our core brand.

If we adopt the same look and feel across our platforms, the user is not suddenly hit with content that looks completely different. They don't need to acclimatise to differing functionality and they are reassured that the pages are official, because they carry the same branding.

Something extra

In addition to achieving that same look and feel, we wanted to introduce a bit of animation and reduce the size of the header when the user scrolls on a larger tablet, laptop or desktop computer.

What the challenges were

Most of the pages on are created using our bespoke platforms; Typecase and Typecase for Courses. Our blog site uses WordPress, an open-source content management system. So not only do they use a different code basis for the build, but the component structure (how the different parts of the pages are split) is not the same.

Same same but different

The global page size was different on this site and without changing that, we'd end up with things sort of being the same, but not quite. If the design is not precise it could appear less trustworthy to the external user - think about those spam emails which use a company's logo, but it's a little bit pixelated.

WordPress sites use several templates for different scenarios, such as site landing pages, blog posts and blog pages, so when making a global change, you have to make sure it works on every type of page.

Scroll and swap functionality

We wanted to shrink the header on scroll, which meant adding some JavaScript to swap over the logo and reduce the height of some elements. This involved quite a bit of trial and error as there are multiple ways to approach this. You need to be careful about how your changes work in multiple scenarios; on different screen sizes, devices and pages/posts.

When you visit the site you are presented initially with the full-sized header:

Screenshot showing the new blog header.

Two downward directional arrows.

As you scroll down the page you see the reduced sized header and the smaller logo:

Two downward directional arrows.
Screenshot showing the new minimised blog header after the user has scrolled down the page.
We use a different logo and display for mobile devices and small tablets, so if you want to see this in action you will need to view it on a larger tablet, laptop or desktop device.

The process

There are multiple stages to our process to make sure we consider the wider context and check everything works before it goes live.

  1. Discovery: We review our options on how to tackle the story and agree on the next steps.
  2. Estimation: We decide how many points the story is worth. We give our scores individually, discuss and agree on our final score.
  3. Draft the changes on staging: We make a copy of the live site in our staging environment. We can then draft our changes somewhere that won't affect any of our live content.
  4. Review: Another member of the team, takes a look at the changes and will give feedback on anything they think could be improved. They look at coding conventions, functionality and design.
  5. Accept/reject: The product owner will take a look at the proposed changes and either accept or reject them. If the story is rejected, we'll make further changes and then ask our reviewer to re-review.
  6. Schedule downtime: Once the story has been accepted, we let our blog users know that there will be a period where they should not make any changes.
  7. Go live: During the scheduled downtime, we will copy the changes to our live site.


Moment of pride

Much of what we work on is not very visible. We are either fixing a bug or making a small improvement which improves the look and feel or improves usability or accessibility. The header is very visible to all users, so it's great to be able to see something you've done go live. And now we're looking into using it on the main site too.

Posted in: Front-end development


  • (we won't publish this)

Write a response