Responsive Design case study

Last month Mixd launched a website for the South Tees Hospitals NHS Foundation Trust. We believe it to be the first truly responsive (as opposed to adaptive) NHS Trust website in the UK. It should be recognised as a stride forward for NHS organisations, whose websites have certainly had their critics in the past.

This post aims to outline the entire project processes and act as an informal case-study for the construction of a large-scale responsive website. The South Tees site contains over 1,000 pages and while Responsive Design is not a new technique, documented examples of client sites on this scale are few and far between. The more we share our experiences, the better our techniques and processes will become as a result.

Planning and scoping

Although not totally related to Responsive Design, it’s good to talk about some of the processes earlier on in the project. These will differ agency to agency, project to project but here is some of what was undertaken:

Mobilized Header and Footer Prototype

Kick-off meeting

After we had talked through the client brief/briefing form and begun to establish things like objectives, success criteria and target audiences — it became immediately obvious that the site was going to be very information-heavy.

We made sure to outline the benefits of responsive design to the Trust from the very beginning. Given the subject matter and working with a public sector organisation; the concept of One Web couldn’t have been more pertinent.

I followed this up by creating a responsive prototype to demonstrate a typical navigation pattern. This proved a useful example and luckily the Trust & their Communications department are switched-on technically, so bought into the benefits fairly easily.

Content audit

This was crucial to the project’s success. For a site so vast, starting the content process rolling as early as possible was paramount. The Trust were tasked with analyising every page of their existing site and auditing content under certain headings. Each page was given a score, an action (e.g. keep, remove, move), a priority, a department/division and a content manager.

South Tees Content Audit

It was a laborious task with over 2,000 entries but it allowed them to take ownership of content, make assessments about quality and recognise any gaps that needed filling. As the Trust is split across a variety of departments and hospitals, it helped them focus their efforts on bringing those responsible for content to action as early as possible.

Above all it made the client recognise just how important a dedication to content is and prompted them to raise their budget and involvement with our proposed CMS training.

UX Principles

UX research

This took the shape of eight 30-minute telephone interviews. To ensure relevance, the participants must have used one of the South Tees hospitals in the past and also visited the existing website. The theory was that quality of research is better than quantity; if you pick the right people, user research/testing doesn’t have to be a long and drawn out process.

The research focused on user’s experiences of the existing site, effectiveness in finding information/completing tasks and their expectations as a whole. Alongside this research we also created a number of user personas which we could reference when making decisions.

Feature-based Quoting

Feature-based quoting

We held an ideas workshop and given all the information available (e.g. brief, aims, research) talked in relation to creative and technical requirements. Ideas from this meeting formed a list of features, each given a priority and a time estimate.

Each item was then written onto a card. Starting with the most important, we worked backwards to prioritise the cards and assemble a finalised set of features that lay within the project budget. This became the project’s specification.

Building the site responsively was a feature/card that had an associated time (and cost). It was deemed a high priority and was one of the first things to be included. To lie within budget, inevitably some features (of lower priority) were shelved to be revisited later.

I think whether Responsive Design should be included “as standard” and what it costs is totally subjective. Price ultimately is dictated by time — how much you put into the process and how quickly you work will differ for everyone.

Wireframing and design

Whilst the benefits of mobile-first are clear technically, I think the planning and design phases of a project are a little less set in stone. Responsive Design, its tools and processes are still at relative infancy and for the moment I think a variety of different methods can all lead to a successful outcome.

Design - Desktop to Mobile

We adopted a very traditional approach to wireframing and design during the project. That is, we created desktop wireframes that led into desktop visual comps. Naturally, direction was informed by the UX research & content audit, and any obvious tripping points relating to smaller screens were considered as we went.

Wireframes (Home)
Wireframes (Hospitals)

From there we worked backwards to see how the desktop design could be optimised for smaller screens. This part was done almost entirely at the build stage. As opposed to planning from mobile upwards or designing fully in-browser, this method of working (on a responsive site) may be a little less idealistic. But we found it was certainly workable.

Whilst the Trust had bought-in to concept of Responsive Design they were commissioning a primarily desktop website. Given the scoping stages had taken some time, they were keen to see design comps in desktop form as early as possible (and trusted us to take care of the rest). This is a client mindset we will have to work hard to change, I feel. In hindsight we could have presented more of an overall process, as opposed to focusing largely on the technology.

Design Visual

We identified and agreed 15 key pages which were wireframed and then produced into visual comps in Adobe Fireworks. It was these comps that the Trust signed-off against before we started building (with room for any slight changes necessary during the build).

Design Balance

Whilst users finding information was clearly important, some of the site’s other aims & objectives were in relation to launching the Trust’s new brand. During the design, a careful balance had to be struck between user experience and marketing the Trust & their services (as well as adhering to NHS brand guidelines).

Build and technical

It was my role to complete all of the project’s technical work. The initial build stage involved taking each designed page, then turning it into a static HTML/CSS template. I then integrated these into the site’s CMS — WordPress.

While the site was designed desktop down, the build was carried out mobile-first. The whole mobile/content-first concept encompasses more than just how you build, but from a technical point of view the benefits are clearly proven.

Build - Mobile to Desktop

Working with the design comps I knew which elements needed to appear on the page and what to aim for in desktop browsers. I started by coding the HTML alone without touching any CSS until I had established the core markup for each page. I find this helps to remind you just how fluid elements are before you’ve even added any CSS, and helps you plan re-ordering in the browser. From here I implemented the styling from the desktop designs with everything pretty much still linearised.

I then worked to re-structure the layout when content required, using 3 major breakpoints (set in ems for flexibility). These were helped by a peppering of max-widths to accommodate line length and image sizes. I used a combination of setting the desktop layout first then refactoring my CSS for smaller screens, or visa-versa.

Media Objects

Changing of the grid/column structure through the breakpoints led me to an early version of my recently-released proportional grids concept. This uses fixed gutters with proportional columns, and helps you avoid the need for re-defining lots of CSS as screen size increases.

Adopting a more object-orientated approach and creating re-useable elements such as the media object helped me out loads in bringing the build together quickly (that’s a really powerful bit of code!).

I used Sass to compile my CSS (via CodeKit) which was a first for me on a project of this size. It’s no substitute for logical & efficient CSS but I think it’s a great tool and working with mixins helps me code more quickly.

The @import function allows you to separate sections of a stylesheet into manageable chunks which helps when serving old IE. The site needed to be 99% identical in IE7, which the Trust use internally. IE7 and 8 are fully supported and receive a fixed-width, 960px wide layout. If you’re trying to polyfill these older browsers with media queries, you’re doing it wrong!

User context

Although it has been lauded that you should never assume a user’s intentions because they are on a certain device, the research and user personas made us realise that context can be important in some instances. For example, visitors to the site who are travelling to a hospital for an appointment or seeking information during a medical emergency.

These scenarios impacted how I prioritised content during the build. For example, pushing the “Finding a hospital” and “Getting here” (contact info) panels to the top of the page on smaller screens.

Home Page (Mobile)

Hospital Page Trust (Mobile)

Considering content hierarchy across the range of screen sizes inevitably happens on any responsive project, but it was good to have specific context to inform decisions made.

Being constrained by source order (or having to duplicate content) can be one of Responsive Design’s limitations, although developments like flexbox make things slightly easier. Fortunately I was able to accomplish what we wanted using float alone.


Much has been written about responsive navigation patterns; in summary, they all have their pros and cons. I opted to use the dropdown menu pattern in the header and footer on small screens.

South Tees Navigation Pattern

As per my prototype, I used slightly modified version of Samuel Cotterall’s touchdown.js script to group together the two sets of links in the header. There are four navigation layouts which all give the primary navigation and search equal prominance either stacked, or side-by-side.

Sub-navigation Pattern
Secondary navigation can be problematic on small screens especially if the nav is complex. I’ve not seen many solutions to this end discussed yet. As the site’s sub navigation was three levels deep and very long in places, rather than over-complicate things it was simply left to flow underneath the main content. Links had display: block added to make them more clickable.

I wouldn’t say it’s ideal having to scroll most of the way down the page to reach sub navigation, but I’m not sure we had a much better option.

Style guide

While the build went along each module created was extracted and placed into the site’s comprehensive style guide. This documented all available content styles and ensured every item could be re-used when placed in different contexts. An object orientated approach really came into its own here, simply adding classes to change layout or give a colour variation.

Style Guide
The style guide proved a vital reference point for the Trust, who were tasked with uploading all of the site’s content. When using the CMS (WordPress) it allowed them to make better decisions on the layout & styling of each page and ensured consistency. In my opinion having a base set of re-usable modules really is the cornerstone of modern web design, and especially important when integrating a responsive site with a CMS.

Style Guide

To make things easier I created WordPress shortcodes and provided HTML code snippets below each item. It is unreasonable to expect all clients to be able to use HTML to update content but often some HTML knowledge is required to do anything beyond basic WYSIWYG styles. The code snippets helped the Trust so they were comfortable using either the visual shortcodes or HTML view (and actually chose HTML view most of the time!)


WordPress Image Sizes
We chose to use images sparingly and avoid the challenge of responsive images rather than overcome it. Setting the WordPress medium image variation to be a maximum of 425px wide meant images (resized on upload) could easily be added to support content, without being overly large in file size when shrunk on smaller screens. The Trust were then advised to stick to this size and use images sparingly per page.

Hero Image

Problems did arise with the home page slider and the “hero” images however, which served to act as billboards for the Trust and their individual Services (promotion being one of the project’s objectives). Images here sat at > 1000px wide, with the slider weighing in at about 350kb.

Here I decided to evaluate what was most important and in referencing the user personas decided both items were of secondary importance to other content. Neither are loaded on mobiles, using the Mobile Detect script to test the browser’s User Agent string (from a list which looks to be updated fairly frequently).

Home Page Mobitest

Admittedly two rules were broken here; assuming user context and implementing UA sniffing which is not without its flaws. However I felt page loading time was paramount, and alongside the mobile-first build the homepage came in at less than 220kb.

As the content was text-heavy, there really weren’t many other large images across the site. I didn’t feel the need to implement a responsive image solution such as Adaptive Images or Responsive Enhance, though I may do so during a later release.

At least for the time being, I think we have to be more considerate to images at the design stage. Raster images & high resolution devices being the main challenges; but before a standard such as the <picture> element is defined (hopefully soon) things are less than perfect. Should we ease off on things like sliders and photography until we have a more solid solution? Perhaps.


Contact Panel
Naturally I was keen to adopt resolution independence and ensure all graphics displayed sharply across the board. For site’s unique graphics I coded top-down, adding an SVG logo and sprite, with PNG fallbacks for non-supporting browsers (using the .no-svg class via Modernizr.)

Social Media Icons

Icons were brought together using Fontello to compile a custom font containing only the iconography required (keeping file size to a minimum). To add each icon I used CSS pseudo elements with unicode characters in the content: property, meaning no extra markup was needed. I find icon fonts very effective, but worry that perhaps our reliance on them to overcome technicalities may lead to a lot of websites looking very similar.

Building the site mobile-first meant that the header, footer and background (branding) graphics only loaded when the screen size became appropriate. I opted to keep these as raster PNGs simply because they were too detailed to be usable as SVGs without a huge file size.


One slight hurdle during development was displaying tabular data; each Consultant profile page needed to display their weekly Timetable. Luckily as profile data is pulled via an XML feed it meant I could easily control the markup and formatting of the table.

This allowed me to hide the <thead> on smaller screens, then use HTML5 data-labels and a CSS pseudo-element with content: attr(data-label) property to prepend each table cell with an equivalent label. Kudos must go to Chris Garrett for this method.

Responsive Table

This responsive table solution is pretty well supported apart from older IE browsers, who receive a fixed-width desktop version anyway. The one drawback is that it relies on you being in total control of the HTML table structure and isn’t too practical to add data-labels when inserting a table via CMS.

As such I chose to leave alone all other content tables after initially looking at David Bushell‘s Responsive Tables. I decided it was slightly more intuitive for the user to drag the page (as opposed to the <tbody>) to view additional columns. The layout breaks slightly on some pages, but the result is far from drastic.

WordPress integration

WordPress Custom Post Types
The site is built around WordPress, Mixd’s CMS of choice. We knew it was more than capable and the Trust were very keen to work with an open source platform — there was little reason to look any further.

During the build I was able to create the IA required relatively easily, helped largely by a great plugin from Scribu called Posts 2 Posts. The plugin allows you to create many-to-many relationships between posts. For instance; letting sidebar panels be managed centrally, and then assigned to individual pages.

I worked up five custom post types; Hospitals, Wards, Services, Consultants and Panels. Hospitals and Services are effectively a replica of Pages (hierarchical) and function identically. The site’s sub-navigation tests for the current post type before listing the relevant child pages. Separating these three post types allowed me to simplify the admin interface and display specific post meta boxes (created using the Advanced Custom Fields Plugin) only where they were needed.

Posts 2 Posts Plugin

Using the Post 2 Posts plugin I created connections to easily assign Wards to Hospitals, link related Services, and add sidebar Panels to any Page, Hospital or Service. We also created a custom plugin for the Consultants section which parses an XML feed exported from a central NHS database, then imports the data into the Consultants custom post type (with Services cross-linked).

Whilst all this is fairly standard fare for a lot of CMS’ out there, it’s good to see you can push the capabilities of WordPress and create something more complex. I often wonder if (as a CMS) WordPress will end up being limited by its beginnings solely as a blogging platform though. One issue I find is in the flexibility and reliability of the Permalink structure which seems a bit hit-and-miss at times.

CMS training

WordPress Logo
The Trust’s dedication to training was great to see. They recognised the need to be fully comfortable with the site’s capabilities to ensure its continual success. We carried out numerous half-day training sessions on site with the Trust’s content leader and four content editors.

Thoroughly training the client for content upload meant we could focus efforts on other parts of the project. Let’s face it, no agency likes to spend time uploading content!

The training process worked really well. The Trust have now set up their own internal web team, with the content leader independently training numerous editors across different Service departments. Making use of the Revisionary plugin allowed any content added/edited to be held in a moderation queue for approval before going live, meaning administrators can retain overall ownership of content.

In summary

Hopefully I’ve provided an honest look at most stages of this particular project. Responsive Design workflow seems to be a big discussion point right now (here too), but I don’t think for a minute there’s ever a one-size-fits-all. What’s vital is to initiate the process and consider everything at the very beginning.

For responsive builds look not just at on-screen flexibility, layout and navigation — but in terms of an overall user experience. Consider things like data load, images and content hierarchy at all stages, then pick the option that feels most appropriate given everything that you know.

Our landscape is changing every day and what’s difficult is adapting quickly. This project began 9 months ago and yes, there are things we may look to do differently or more efficiently next time. Stop and assess each part of your workflow after every project and more importantly, write about it!

Google Statistics

A month since launch, in more than 26,000 visits the site is seeing almost 20% usage via mobile or tablet. Interestingly, 75% of that is via an Apple device. I’d like to think that all of those users are getting a great experience, helped by Responsive Design and the decisions made here.

Please let me know what you think of the South Tees site and what we did right or wrong. If you have any further questions about anything please get in touch or comment below!

Likewise, if you want a responsive website Mixd would love to hear from you!

Finished reading, formed an opinion?


  1. James Young

    James Young



    Thanks for this write up and for sharing so much detail. Like you said, there’s nowhere near enough sharing of the results of an actual client project and the real constraints and limitations that can sometimes crop up.

    Great work and writeup! Congrats to the Mixd team :)


  2. Primož Vidovič

    Primož Vidovič


    This is a very insightful post. As an inspiring designer, I find articles like this very useful to refer to when learning to design websites. It is also a great way to implement responsive design on the web. Great work.

  3. Robin Green


    Great write-up Matt – thanks for taking the time to explain the process. As someone who works independently on small-to-medium projects it’s interesting to read how a large site like this can be put together in WordPress.
    One quick question – did you use a theme or framework within WordPress for the site? Or was it a custom build from scratch?
    Many thanks,

  4. Bob


    Thank you for taking the time to explain how you tackled this HUGE project. I’ll be thoroughly robbing many of your practices, especially the content auditing, I hope you don’t mind!

    One thing I would love to know is how you tackled the permalink structure. I’ve attempted, and failed, to achieve such deep nesting in WordPress. Are you some kind of wizard?

  5. Brian



    This is an incredible write up, sir. I’m not one that usually reads an entire post but you had me from the beginning and provided a lot of great info and links that I will be considering during my next project. And I love that while your seed was RWD that the article was really less about RWD and more about your process and decisions, which is always the hard part anyway.

    I do believe your comment about WordPress being limited by its label as a blogging. I’m a firm believer in WP as a powerful tool but always get some gruff when I bring it up as an example as a CMS platform. And I’m going to try that P2P plugin you noted to see how I can use it…it sounds powerful!

    Thanks again. Cheers.

  6. Matt Berridge


    Thanks for the positive comments. Wasn’t sure if I’d written too much or lots of obvious points!

    @Robin – Some time ago I created a generic WordPress framework which we start all of our WordPress projects from at Mixd. It includes lots code snippets and functions we commonly use. I’m in the process of updating it then I’ll be sure to post it up again.

    @Bob – Do you have anything specific you’re trying to achieve? I’d be happy to help if you want to get in touch on twitter. This setup wasn’t too complicated — just hierarchical pages. I’ve had a few problems in the past with custom posts & custom taxonomies, getting the category into the URL for instance. I solved it in the end though!

    @Brian – Yup, it’s really not seen as an “enterprise” CMS and does meet with some skepticism. Hopefully this site shows it is more than capable.

  7. Leban Hyde

    Leban Hyde


    Nice write up. I’m sure it was as much for your own benefit as it was for the community at large (speaking from personal experience). I am glad to see that you were candid in sharing your process as well as honesty in the difficulties you faced at various screen sizes.

    RWD is a lot of work. No magic framework, no magic technique. And I’m speaking from limited experience. It was stellar of the client to be on board. I wish more businesses could look that far ahead.

    Keep up the writing. Cheers!

  8. Niall Rutter

    Niall Rutter


    Great case study report!
    I happen to be embarking on a responsive WP based site very soon. This gives me that much more confidence with the project. Congrats on deciding to publish your process and results. And it’s good to see the NHS opening up to a modern medium.

  9. Caleb


    Thanks for this great case study of how you built this site. It really helps fellow developer/designers to see exactly how other firms are working through a larger project.

    I plan on doing a similar case study for a website I’m working on right now for Sign-A-Rama.

  10. bob


    @matt – “problems in the past with custom posts & custom taxonomies, getting the category into the URL for instance” BINGO!

    The native permalink rules are very limiting. Any of my attempts to overcome them are burdened with caveats and frailties. Any wise words / links/ plugins would be very much appreciated…

  11. Tim


    It’s great that you could use WordPress for a project like this. Really nicely implemented. I have been getting more and more into customising WP and I do have a question:

    How did you manage, for the most part, to hide the existence of WP from the code i.e. there is no theme information in the stylesheets, no theme source links etc.? I mean other than wp-content for image uploads and the W3 cache plugin comment you wouldn’t really be able to tell.

  12. Stephanie



    Very big thanks for sharing the case study, particularly the WordPress part. I’m currently finishing a WordPress responsive site, and encountered the same problems. I’ve tested some responsive image plugin solutions, but so far none matched our needs. They either don’t work, or generate HTLM input that breaks the layout. So I think I’ll end up doing like you did, training users, explaining them they should use the medium size image, and also giving them some tools for PNG/JPG optimisation. I’m also wondering if we won’t too remove the slideshow for mobile sites. It’s pretty small, and does not add much value except nice images and teasing. WordPress embed a wp_is_mobile functionality that detects UA for this kind of things, but it’s UA sniffing, not 100% sure (you can see some tests I run here )
    The other point I agree is how you handle IE. I’ve tested some media queries polyfills, with the modernirz conditionnal load. It works pretty well, but there’s a little delay and of course loads extra ressources. I’m wondering if I won’t remove the polyfill, give IE8 and below a fixed container size instead of a max-width. The only problem will be non IE browser that don’t support media queries.

    Still work in progress :)

  13. Alex


    Very “real world” article. Love the fact that you used only a few js plugins. There is a strange fitvid bug: it inserts a div class “fit-vids-style” in the head right under the meta charset tag with the content “�” and a style. In safari mac it doesn’t show but in chrome the “�” it’s visible on top of the header and it also messes up the dom.

  14. Ben



    Thanks for this case study, interested in knowing why you didn’t start with something like Twitter Bootstrap or HTML 5 Boilerplate?


  15. Matt Berridge


    @Bob – I’m about to release a sample framework theme which should help you out, just writing the blog post for it. I’ll email you when it’s complete.

    @Tim – Hiding the existence wasn’t deliberate, it’s just the way the theme turned out. There’s certainly not much reason to! We didn’t use many plugins so no scripts / CSS get added to the wp_head really, which may be partly why.

    I always keep my folder at root level and not in the theme. Partly because of a carry-over from the templating, and also because it’s a bit neater with a shorter URL. Obviously if you’re shipping your theme publicly then your assets should be within the theme directory.

    Usually I amend the /wp-content/uploads folder to something more generic like /uploads, but forgot before the client had added uploaded lots of files! A bit of faux paux on my behalf. Again, because a shorter URL is a bit neater…not to hide anything specifically.

    @Stephanie – I had noticed the wp_is_mobile function but chose the Mobile Detect as it seemed a bit more thorough? It also looks to be updated fairly frequently, which is important when new devices/browsers come out. Great to see that you’ve done some tests, where do you get your devices from?! Unfortunately I fear browser sniffing is never going to be 100% reliable.

    Generally I would say if a slideshow can be hidden on mobile then it shouldn’t be there at all! In our case, the Trust were really sold on it so it really was a last resort because we wanted the site to load super quickly. Have you looked at the two responsive image scripts I mentioned above? I’ve had success using adaptive-images with WordPress which serves correctly sized image variants based on device width. Maybe try that and you may be able to keep the slider, without extra data to load?

    I would remove the polyfill personally. IE 7 and 8 are desktop browsers and it’s unlikely their window will ever be resized (only by you in testing!) And if it is, I’d say a fixed width and horizontal scrollbar is acceptable for a 3+ year old browser.

    @Alex – Thanks for noticing that, I tweeted you about it. I have updated the code now — it was to do with an error during the minification of the Javascript.

    @Ben – The site was designed from scratch so that obviously had a bearing on not using something off-the-shelf. Twitter Bootstrap is okay but I find it’s more suited to applications/back end systems rather than general websites.

    We have our own frameworks at Mixd — both CSS and WordPress — which we use as our starting block to get us off the ground quickly. I actually used some of HTML5 boilerplate (and others) within them, and then customised to build around the general methods we use when we create sites. I think this is how a framework should be; it’s great to create and customise your own given how you work, it saves a lot of time!

  16. Ethan Marcotte

    Ethan Marcotte


    Well now. This is a wonderful, exhaustive post; thanks so, so much for sharing it, Matt. And congratulations on the launch!

    I wonder if you’ve evaluated any viewport-driven conditional loading techniques, à la AjaxInclude (part of Filament Group’s SouthStreet project). If so, I’d be interested to hear why a UA-based approach won out in the end.

    Thanks again for the lovely site, and the thoughtful, engaging post.

  17. Avangelist



    I have spent the last hour enjoying – genuinely enjoying reading through this and as a total body of work, it is stunning. Is there any chance of you publishing total man hours?

  18. Carlos



    Wow! I got so much work to do! I work for a university and a lot of the context you’ve described on how you handled it for South Tees is a bit if not a lot of what I have to look forward to. This article is a great “cow path” type of reference that I appreciate being available. The desktop to mobile process sounds daunting but I hope we don’t have to use that approach. None the less great information you’ve provided. Thanks!

  19. Matt Berridge


    @Ethan – Thanks man, I’m humbled.

    The loading techniques were released around about the time I was on that part of the build, but sadly I missed them. I then thought about revisiting but couldn’t see immediately how I’d get it to work and unfortunately time was up.

    I’ll be sure to test them out and will bear them in mind for the future. Filament Group are doing some great work!

    @Avangelist – I’m not averse to posting man hours but I’ll have to do some digging. Honestly, some of what we did was over and above because really we could only estimate how long certain things would take on this scale. It was a good learning exercise!

  20. Toms Outlet


    I think were moving in the right direction.

  21. website


    Hi, Neat post. There’s a problem together with your web site in internet explorer, would test this… IE nonetheless is the marketplace leader and a large section of folks will omit your fantastic writing due to this problem.