We wanted to showcase a handful of the WordPress projects our team has worked on across the last couple of years. These projects range from full redesigns to sites where we’ve implemented more streamlined and lightweight processes for managing content and building new landing pages.
Before we show off our portfolio, we wanted to explain quickly why a lot of WordPress sites suck, and what our approach is for fixing them.
Why do lots of WordPress sites suck?
WordPress is still the king over the internet. Everyone uses it, there are millions of plugins, and most of its common pain points have solutions.
If you think your website is built with WordPress but you're not 100% sure, you can check out our article on how to tell what platform a website is built on.
Since its inception 19 years ago, WordPress has been used in every conceivable way to create applications, different forms of websites, membership sites, subscription centres, and things it was never intended to do. Even when it’s being used to create a standard website, there are hundreds of different themes and approaches to configuring WordPress.
A lot of these approaches aim to simplify the content management process for users, leaning on drag and drop elements, all-in-one plugins, and changes to WordPress’ native functionality. Simplicity usually comes at a cost, and this is the beginning of why a lot of WordPress sites suck.
You’ll notice in the picture that WordPress, Squarespace and Wix all seem to have similar rates of passing CWV. Squarespace and Wix both leverage drag-and-drop builders and are known to carry bloat in their payloads which increases the amount of data a browser needs to load before the site is interactive.
A blank WordPress site will pass the Core Web Vitals assessment with flying colours by default. However, when a clunky theme and many plugins are added to the site, those numbers go out the window.
Installing poorly optimised themes and mixing in too many plugins is the biggest reason many WordPress sites suck. The site performance slows down, and the combination of different plugin codebases creates design inconsistency, and the whole experience becomes Frankenstein-like.
We could go way deeper into these issues, but the point of this article is to focus on solutions rather than problems!
What does a great WordPress site look like?
Our team have built dozens of WordPress sites and made tons of mistakes a long the way. That experience has helped us figure out what a great WordPress site looks like to visitors and administrators.
To visitors, the design needs to tick a handful of boxes;
- Clean design
- Consistent spacing
- Strong and easily recognisable branding
- Easily understandable directives
A clean design avoids clutter and makes for an easy reading experience. Consistent spacing is kind of like looking at a neatly organised house, there is no chaos and the experience feels “right”. Strong and recognisable branding lets the visitor know they’re in the right place, battling that consistent sense of scepticism most internet users have developed. And finally, easily understandable directives help the user interact with the site and get what they need.
On top of all of this, the design should be creative and look good, but that goes without saying.
From the administrative perspective, the ideal situation would be a drag and drop builder that doesn’t have a million configuration options.
Even when administrators create new landing pages, they rarely think through every design possibility. They want the freedom to rearrange sections up and down the page, change content and add new images. They don’t want to pick fonts, font sizes, image spacing, or branding colours every time they create a new page.
This situation is where a block-based page builder comes in handy.
The blocks in this library (black dropdown on the right) have been pre-styled. They use brand colours, fonts and sizes. The code that generates the sections is lightweight and optimised. Most importantly, the administrator can change the content, images, link destinations and some basic styling options within each section.
This approach brings a lot of freedom for administrators. They can re-order parts of the page, create new landing pages, make content updates and remove unnecessary or outdated sections of any page. Best of all, they don’t need a developer to help out.
Now that we’ve reviewed our approach to creating WordPress websites, let’s check out a few case studies.
WordPress Case Study #1 - A Rich Life
A Rich Life is a financial and lifestyle news site that was due for a serious facelift and re-architecture. Previously running on a custom set of technology, managing content was difficult and required developer intervention for even the smallest change.
As a membership site, all payment and permission granting activities were being run manually.
It’s kind of bonkers to think that a site that had achieved decent success was such a manual mission.
Our mission was to reframe the huge content pool in a way that let non-paying members access just enough fresh content to wet their whistle, while also giving them a way to upgrade to a paying member. On the member side, we needed to ensure that members could easily log in, change their details, and access the wealth of gated content on the member side.
We ended up implementing Memberpress to bridge this gap. While it does the trick, we’ve become a bit frustrated with the quirks that come with running this plugin.
The next mission will be to help the A Rich Life team migrate to a new member plugin or platform that offers more flexibility and less clunkiness.
One thing we’re proud of with the A Rich Life site is its performance. They publish several articles a week and boast a massive library of content, thousands of hits a month and huge volumes of in-article images. Despite all of this, the site passes the core web vitals assessment on both desktop and mobile.
WordPress Case Study #2 - Bitmax
Bitmax knew their website was due for an update. Their old site design didn’t do their incredible brand justice. They had also struggled with being able to easily create new landing pages, changing the content of their existing pages, and with general responsiveness.
We set their new site up with the block-based page builder architecture. Bitmax took to this approach quickly, since their team have a decent amount of experience using WordPress.
Typically, we’ll need to hand-hold our clients as they rewrite content, swap images, and modify pages to fit their needs. However, the Bitmax team were way ahead of us and had everything sorted in the first couple of days of playing around with the test website.
We’re particularly proud of the small animations that were built into the Bitmax design to bring their content to life. Combining animations and a re-orderable block-based system can be tricky, but we managed to isolate the animations in this case.
The last stop before releasing Bitmax publicly was to tune up the site’s performance. The site easily passes Google’s CWV assessment, scoring a 95 on desktop and 90 on mobile.
WordPress Case Study #3 - National Aboriginal Community Controlled Health Organisations (NACCHO)
NACCHO are a unique client because they were happy with their design but they wanted to fix some of the annoying layout issues that plagued their site. They were also struggling to implement new functionality and found that their site was costing a lot of money to maintain.
These problems boiled down to running the site on Hubspot. While it’s an excellent marketing platform, Hubspot is a poor framework for website development. It’s not open source and carries a lot of bloat.
Check out these Google Pagespeed Insight numbers of the NACCHO site before we rebuilt it using WordPress:
31 from 100 is a poor score for any website. It’s especially troublesome for a government website that receives thousands of views each month and serves an essential purpose.
Before we jumped into rebuilding the NACCHO site, we needed to analyse the existing website. We started this process using FlowMapp, an excellent tool for visualising the sitemap of a website and creating a checklist of which pages need to be rebuilt.
Once we had a complete list of the pages to be redesigned, we needed to figure out how to standardise the design into a block-based library. This exercise aims to use as few blocks as possible to engineer their entire site design.
A big part of this process was making all the H1s, H2s, H3s, H4s and paragraph text blocks the same font type and size. Additionally, any element that is used across the site (cards, buttons, call to action sections) needed to be tweaked to be exactly the same.
There was a surprisingly large amount of variation across the site in these global components.
The final step was rebuilding the site and connecting an RSS feed with Hubspot to send out frequent emails summarising content updates.
At the time of writing, the new site is not live. We’ll report back with a Pagespeed Insights update when the new site is up and running to highlight the difference between a poorly optimised Hubspot site and a performance-focused WordPress site.
There are plenty of other WordPress sites we could showcase, such as Kynd, Angelsteach, Humanforce, and Julie Josephine. But we’re not in the game of repeating ourselves, and most of these projects follow similar courses.
We wanted to give you a quick showcase of some great case studies built with WordPress and talk about our approach for designing and developing these sites.
If you’ve still got questions or want to know if we’ve created a site that matches up with an idea you have, please add a comment below this article or write to us on our contact page.
Tim is the face of the company. When you want to kick off a new project, or an update on your existing project, Tim is your man!