UNBRANDED MANCHESTER_

Empower clients.
Increase average project revenue.
Reduce website development overheads.

We set ourselves the task of scaling our agency output, with an increase in margins, without the additional expense of new staff or other overheads. We identified that like many other agencies, our website creation process included a large number of tasks that were repeated on each project that required a lot of hands-on, skilled developer time and put us in a position where we were required to maintain client sites with small updates and low-value mini projects.

We identified that the largest overhead was the development team. It turned out developers were spending laborious amounts of time solving problems that really could be solved at the design or planning stage.

The web has changed drastically due to the ubiquity of mobile devices, the size of screen your website will be viewed on can never be assumed. This has been widespread industry knowledge for years but many developers and design teams are still catching up…

"What pixel width should I use?"

Before the web, most design work was done for print. One of the first questions a sensible designer asks is for the exact dimensions of the medium they’re designing for. The difficulty with the modern web is that there are no such dimensions! Truly responsive design is a major headache for this reason.

A typical approach we’ve seen widely adopted is the following: arbitrary sizes are given as guidelines to a designer for e.g. the most common ‘Desktop’, ‘Laptop’, ‘Tablet’ and ‘Mobile’ sizes. That should cover all of your bases right? Sadly not! We can look at usage stats for common screen sizes, and optimise for those, but it’s misleading to think this way and neglect thinking about how we get from A to B. How does the design gradually transform with the size of the screen? We found this is where a lot of that extra development time was being spent! Fixing bugs thrown up in device testing or even having to re-work entire sections of designs.

In order to scale up in a world where good developers are in high demand, we needed to reduce developer workload. Counter-intuitively, this began with giving our dev team more time to spend on each project. We changed our approach. Instead of just solving what was in front of us on a per-project, client-specific basis, we devised more general solutions and ways to educate our designers to think responsively.

DRY not WET.

'Don't Repeat Yourself' vs. 'Write Everything Twice'

Taking inspiration from a concept in The Pragmatic Programmer, and making use of tools from the Roots Team we started approaching projects totally differently.

We looked at our 30 latest web projects, breaking down every task involved, to find repetitive patterns and to take a more intelligent approach to solving issues in a consistent, repeatable way. We identified that over 90% of the components and layouts we custom coded on each project were very similar, and those components themselves were made up of smaller elements that were being re-built each time.

Atomic Design

"We’re not designing pages, we’re designing systems of components."

— Stephen Hay

All digital agencies recognise that repeatedly building similar things is a bottleneck, the problem they encounter is that to work any differently: the rest of the team has to understand the development team’s approach. Building a site the way developers would like to build means there will certainly be less to ‘see’ (from a non-developer point of view) until much later in the project.

We needed a way to relay our ideas to our whole team, and to our clients, so we took inspiration from Brad Frost’s Atomic Design (which we encourage prospective clients to read up on). We began breaking down each website design into its basic elements and components. We sat developers down with designers and came up with a design system – a flexible set of layouts and components that work in a variety of contexts.

Ruined Design.

How could we ensure the site design consistency wouldn't be ruined when we handed it to our support team and clients?

We also needed to ensure that clients and our support team alike wouldn’t break the site when they took over the management. We began building a style guide for each website to provide reference for its look and feel. Building this first allows us to prototype and test potential responsive issues, styling issues, custom components, components in different layouts and site scalability.

The solution: Our custom layout builder, was born. It made it next to impossible for a design to be spoilt – impossible to deviate from brand guidelines and difficult to break. At the same time it empowers clients and support staff to begin rapid prototyping of new pages, built to brand and fully functional without requiring constant developer input.

The results: Designers were happier, as they now had a framework through which to understand responsive development, letting them make designs that pleased developers as well as clients. Developers were more productive, since they were taking advantage of good coding practices, repeating themselves less and able to focus on other areas. We simplified so much of the process that we were able to hire support staff from less technical backgrounds to help us build site content.

83%

Increased Productivity

By releasing our developers of repetitive tasks we were able to increase our productivity on new sites.

94%

Less Amends

Clients were no longer calling us to carry out low value work on their sites, we’d empowered them to take control.

27%

Profit Increase

By using support staff to build pages, we were able to reduce typical website build overhead.

2

Support Staff

We hired two new support staff to support the development process using the layout builder.

Contact Us




This website uses cookies for functionality and allow us to analyse the use of the site. To opt out please view our Cookie Policy. If you continue to browse the site, we'll assume you agree to the use of cookies. [ Hide Notice ]