Since the beginning of time (i.e. August 6, 1991), web designers and developers have been working to perfect the process of creating websites. It’s a process that’s never complete because things keep changing in digital communications. When it comes to nonprofits looking to deliver engaging digital experiences that involve large volumes of content, there are a lot of things we must take into consideration: planning, architecture, design, development, front-end coding, testing, and deployment. And the more content-heavy a nonprofit’s website, the more difficult this can be. The general process many web design firms have traditionally used goes something like this:
This approach may work well for certain kinds of projects, but when it comes to large, content-heavy websites with a large number of page types and content types, there is room for improvement. Over the years, a lot has been written about “Content First” approaches to site development (Luke Wroblewski, Jeffrey Zeldman, Georgy Cohen), especially in the age of responsive design. These ideas are all well and good, but in the real world, having content developed before initiating the site build isn’t usually realistic. However, we can (and should!) include content in the process sooner and more often than often is the case. This is exactly the kind of thinking that goes into developing content strategy for websites.
Content Development is Hard!
Let’s get this out of the way first: content development is always, always, always the hardest part of a website project. Yet how often do we underestimate the amount of effort it takes to collect, analyze, write and edit good site copy? Never mind getting good images, which are also content but somehow treated separately. Hours spent, from needle-in-the-haystack scrolling through stock photos to hiring photographers and illustrators to create custom imagery.
The main reason people visit our websites is to read our content. Yet, time and again, (especially in the world of nonprofit websites), content treated as a separate thing—handled by the client (often for budgeting reasons), divorced from the design and development. The problem with this approach is that once the visual design work is done, unless a design firm is handling content development as an integrated part of the process, clients are left to make the content to work within a content strategy and website designs that expect idealized content.
Now, this isn’t necessarily a bad thing; a little structure is good to help focus our content. Good wireframes and design comps can help give clients an idea of how a new site design will help them frame the discussion and focus their message. But unless a content team is integrated into the process, rarely do the results live up to the promise once designs have been approved and it’s time to get to writing.
The Discontents of Our Content
Over the years, we’ve continuously refined our design and development process to reflect the needs of delivering great content for the nonprofits we work with. And one thing is clear: approaching a website by designing lots of great-looking comps and/or prototypes, building them, and then populating with content can be problematic.
When it comes to designing content-rich nonprofit websites, we can run into serious trouble when real content is integrated into the idealized world of our design comps. Symptoms include content that doesn’t consistently fit the templates, content that exists but has no place to live, content that breaks the visual designs, and so on.
And this problem extends to the development side as well: when final content is delivered after a CMSs is architected, it rarely fits into the neat little boxes we create to support it—or unanticipated content creates problems, forcing the redevelopment of pages or features.
As a result, for many projects, after content is entered, there is a period of fixing where designers and developers spend countless hours working together to get the pages to “work”—tightening up all the loose ends and pushing ever closer to those idyllic design comps the client (and designers) fell in love with. This introduces a painful period of rework into the process that looks like this diagram, and points to a flaw in how we plan and design for the real content.
Process Adjustments
Given all of these issues, it seems clear that what’s needed are “content reality checks” along the way. Because, ultimately, the real content must meet the real designs and decisions need to be made when there are issues. So, as part of our ever-evolving digital process, we’ve added check-ins throughout the design and development process that make it easy for everyone to translate our content strategy into effective designs, saving a lot of time, money, and headaches. It looks something like this:
Two things are different here:
- There are periodic check-ins between the content developers, the designers, and the developers. The designers and developers should have access to some of the content plans and the content developers need to have some idea of what is going on with design and development. There is a lot of efficiency to be gained if visual designers, developers, and content developers can work together more.
- Deferring Theming (which includes front end coding and its integration with the CMS) until at least some representative content is entered into the CMS allows the front-end coders to make real-life decisions on how pages will render. This also prevents them from having to refactor their front-end code to handle last-minute changes to the site. Additionally, this is a major boon when working on projects with a responsive design component, as the front-end coder can test real-world content on a variety of devices and screen-sizes while they’re coding.
A More Integrated Approach
When greater effort is made to incorporate content strategy and content creation into the website design/development process, teams save significant time and effort—and their results will be brand experiences for audiences where content, design, and technology work together in harmony to engage audiences.
