Design or content first?

Along with building a new Content Management System (CMS); the team at the National Gallery of Australia (NGA) wanted to re-organise all of their content. The original website had a few thousands pages, some duplicated content and inconsistencies (in both form and content). It was decided that new content would be written for the new website and the existing pages were not to be imported in the new website. Some of its content would live under “general web pages” while other pages would need a bit more structure. For example, each on-demand video page contains a video and related meta-data (e.g. title, description, genre, etc.). The new design had to cater for the new (not yet existing) content, and the new content had to fit nicely into the new design.

This article is about that classic chicken-and-egg problem (design or content first) and how we’ve approached it with the team at NGA.

1.Content first VS Design first

While content-first is often recommended, both approaches have pros and cons.

With content-first, the text, images and videos are prepared before any design and any programming happens. That way, the client can focus on the raw content and not on its layout. Once the content is ready; designers and developers can prepare the best possible website for it. There is no surprising content which would “break” the design and no unnecessary features are added to the CMS. Developers can import content and the designers can work with hundreds of real pages and images. They can tune everything. The UX is perfect.

Well, it’s perfect until the NGA editors can finally get their hands on the CMS. As they start editing the content and seeing the result within the live design; changes would inevitably be requested. The client will potentially have to enter a lot of new content in a system they are completely unfamiliar with. They might then ask for fundamental changes which would have been better discovered earlier in the process.

With the design and CMS built first, the designers and developers don’t need to wait for the content to be ready. The client can see how their content actually looks when editing a page. They can pick images that work well with the theme colours and, more importantly, with the cropping (if any) imposed by the design. Having defined the fields and their look helps editors entering content. A good CMS also helps larger teams of editors (with a variety of domain knowledge and writing skills) by providing tools for publishing workflow (draft, revisions, pages publications for certain users only, etc.).

Design first sounds great. It makes the life of developers and editors easier. However, designing in the abstract is really hard.

2.Impossible choice

As outlined above, trying to enforce design first or content first leads to timing issues in both cases. It’s time consuming to prepare hundreds of pages and designing a website without content correctly is hard impossible.

The solution is to integrate design and content input together, doing so gradually and piece by piece... We would typically receive content and requirements for the homepage; design it; build it in the CMS and let the client edit it before moving on to the next type of pages. These small iterations of design and content entry allows everyone to work at the same time on the project without interruptions.

3.Making it work

Project management

Working in small iterations is a usual agile approach. Because the NGA website is content heavy, the content editors lead the priorities with their needs. We’ve designed and built page types and features that the editors needed. That way, they would test it straight away by entering real content.

To ensure the whole team cohesion (NGA editors and developers at the IC), we had weekly Work in Progress (WIP) meetings.

Occasionally, some content would be prepared out of the CMS first if that would save the client time. That was the case for on-demand videos and audios where a separate team organised the content in a spreadsheet, which we then imported into the CMS as pages. 

Technical implications

Having the NGA editors using the CMS while the website was being edited leads to many iterations; often several times a week. Most importantly, changes could not break the site. To avoid any issues, we used our two usual tricks: a demo site (referred to as our staging site) and lots of automated tests. 

Every single feature (page-types, blocks, design changes, imports, new fields, etc.) goes to staging first. We only release features to production (the live website) that have been approved on staging. Some features never make it to production.

Automated tests are basically code that checks that the website does what we expect it to do. For example, the first test is as simple as “When a user goes to the homepage for the first time, they see the First Peoples acknowledgement”. With that test in place; before every single production release, the presence of this acknowledgement message is automatically checked. Without it, someone would have to open a new browser in anonymous mode and check it manually. That’s the first test. With all of NGA's various pages and features, there are now a thousand of these automated tests.

Conclusion

We often have the luxury of working with pre-prepared content, which we just have to import. For NGA, we had to build the site while they entered the data. In other words, they had to enter the data while we built the site and its features. It took a great deal of coordination and was only possible through consistent collaboration between our team and NGA. This work paid off though with every single feature we’ve built being used (and therefore tested) straight away.