Latest posts

Questioning the quality of our work

We took a break from client work last week to hold our second Erskine Breakfast event in our Nottingham office. It was a packed house and the topic of discussion was the creative process. This is a summary of my talk on improving the quality of our work throughout the project lifecycle.

Our design and development team is constantly improving the way we work together across different “departments” as well as with our clients. Questioning the quality of our work, the communication with our clients and how we can make that better.

Over the years we’ve naturally transitioned our approach to creating web projects from a siloed waterfall approach to working more collaboratively. Most of the changes we’ve made spawned from the following areas.

Design implementation

Design implementation breakdowns are a classic example of working separately on a project rather than together. The designer makes their masterpiece, emails it to the developer and the final implementation isn’t quite as it should be. LOL.

This is an easy one, and we can avoid it by putting more thought into our design deliverables and, as a designer, thinking more like a front-ender in terms of deliverables.

Thou shall not leave guesswork to the front-end developer.

Albert Einstein

Here are a few examples of design deliverables we’ve introduced over the last few years. Hint: lives have been changed.

Living, master colour guide
Detailed typographic styleguide and how the elements of the page fit together
Fully exported, optimized and organised imagery

Breakdowns in communication

This can be both an internal issue with our teams and an external issue with our clients.

Clients first. At the start of a web project we shouldn’t assume the client knows what we’re talking about. Don’t roll into a kickoff meeting beatboxing buzz words. Guide and teach your clients in plain, simple language all the way through. They’ll love you for that new found small talk they can bust out at next year’s holiday bash.

Internally we need to talk more cross department. It should be fair game, and encouraged, for designers to have development feedback and vice versa. Also, daily stand-up meetings. Knowing what everyone on your team worked on yesterday, is working on today and is having trouble with is a life saver for productivity and openness.


The key to maintainability is realising early on that a web project is never over and that shortcut you took last week will haunt you next year. It doesn’t matter what your project conventions are as long as your project has conventions and your team is sticking to them. Build for maintainability and build for the future.

Garrett Winder
Published in: