Will McLean is a designer and artist working in the Central Coast of NSW where he lives with his wife and 2 children.

Will is a meticulous developer and favours simplicity and clarity within his code. He can’t stand writing things twice so searches for any way to automate. His experiments can be found in the Exercises section of this site.

Will designs within systems. No project is too small for a design system. He favours the unusual, if not, how can he progress? You can read about his work in the Case Studies section of this site.

Updated: November 20, 2018

This is a Case Study post.

Pollen Press


As part of my role as Site Architect at Pollen I developed and maintain a framework we use for most site builds, Pollen Press. Pollen Press is the culmination of the studio’s design and development research in the form of a starter template for WordPress builds. It is something we can build on with every project, meaning that we are never starting from scratch, but instead refining our processes and building a valuable framework for ourselves and our clients. Pollen Press has all the common modules with which we start each project installed immediately. They can be reordered on any page to create unique and flexible layouts. It creates familiarity and predictability for producers which streamlines the workflow and allows us to explain our offering and process to clients with confidence. It holds our typography scale and is designed and built using Brad Frost’s Atomic Design approach.

Pollen, Cambell St, Surry Hills

Why did you need a framework?

We identified a need for a common language from project to project between departments. We wanted to encourage familiarity with the core structure and appropriate parts of our projects. We were finding problems with the way we scoped, wireframed and designed as page templates. It just wasn’t translating to the build and time estimates were rising quickly when we scoped the projects. We had experimented with a more modular approach and we wanted to formalise this. We were starting our builds from scratch each time, however, we found ourselves building the same, or very similar modules on every project. We were bug fixing the same bugs on every project. Not only was this a nightmare from a development point of view, there was a danger in it becoming unnecessarily expensive for our clients. Whilst this could have continued for small projects without major impact, on bigger projects it was in danger of becoming unsustainable. We needed a framework.


How did it feel when building it?

It felt like I was doing my last exam at school. I knew that I would never ever have to create these modules from scratch ever again. The highlight was building the menu. On every project we redesigned the menu and built it from scratch. We designed and built the Pollen Press navigation based on an amalgamation of some of the latest projects. This meant pooling the studio knowledge to create a ideal menu that could serve the initial needs of a majority of clients. This, like the rest of the site, was built with very minimal base styles so as not to dictate the look and feel. It was then tested on all the browsers and screen sizes. We were left with a navigation that had input from every department, that we knew worked and was already built. Now, on each project, we can decide if it is suitable for the client as is or it is something worth investing in to accommodate some unique needs.

A toy Fararri that has been hanging around the office. The ultimate inspiration for fast paced, modular design.

Does it stifle the design?

No, it is a response to what we were already designing. It is not like a framework picked off a shelf. It is representative of the design patterns we were already producing. It has actually led to a deeper understanding of our own design. We started very tentatively with our styles. We did not want to influence the direction of a project before it had already started. However, as time has gone on we have recognised things we are doing every single time. We have then added that as the default. It leads to real examination and automation of our design process. It has allowed us to spend time on unique parts of client projects, the things clients actually want and need to differentiate themselves from their competitors. We don’t waste time or money on things everyone needs. Client budgets are now stretching further and we are able to extend ourselves creatively on the right parts of the project.

Working hard or hardly working? #agilelyfe

Were there any teething issues?

There always are. The designers were worried it might stifle their creativity and besides, it wasn’t the right colour. The producers were worried that it wasn’t on fire or related to anything that was on fire so thought we didn’t need to put it out. The UXers were worried that it hadn’t gone though 3 rounds of workshops with multiple stakeholders so couldn’t see how it might address anyone’s needs. Anyway, the directors said let’s use it, so we did and since then it has been used on every build. The designers now have a full appreciation of the time it frees up to really refine the final product (and they can change the colour). The producers are happy because it isn’t on fire and seems to have actually helped them put out a few fires along the way. The UXers are happy that it has cleared the deck for a few extra workshops. And the developers are happy because everyone has a better understanding of what is involved in the build and we get more time to watch Star Trek.

Backlog grooming

What sites have been initiated with this framework?

GML Heritage
The Lane
Alpha H
Future Women
Future Women Academy
The Australian Center for Social Innovation
Family by Family