Rethinking how we build sites

A Typical Process

It goes like this: Company decides they need a website. They hire a branding/design agency, which produces static Photoshop comps filled with placeholder content, to do the design work. Those are handed off to a development team, who interprets this static design into a dynamic site, fills design gaps, and makes educated guesses about functionality where none have been specified.

Near the end of the process, the mostly complete site is handed back to the company/client, who then has to fill the site with content. Often, the content they write doesn’t fit in the design (that header was meant to be 5 words, not 10), so the designer has to go back in and make some tweaks, which then gets passed back to the developer. And this cycle continues numerous times, putting bandaids where missing functionality is discovered and squeezing in new image carousels and feature boxes where marketing requirements were overlooked.

Problems

Clearly, there are problems with this approach. First of all, the design team is creating the site map and content areas with no content and very little direction. They are often tasked with developing the content strategy and hierarchy of the site without being armed with the necessary tools for the job—the specific goals, requirements, and high-level strategy for the site. The client often doesn’t have a firm grasp on the goals of the site either (other then producing a site), making the design team’s job problematic.

Without having the real content, even if they are given a goal of some sort (drive traffic to a landing page to get users to fill out a form for lead generation, for instance), they have to figure out the length of headlines, copy blocks, and even bullet points for a product description. And as anyone can attest, even the best educated guesses are still just guesses. The writer often ends up either not writing to spec, in which case everything has to cycle back through the design and development teams, or the writer is constrained by the design and can’t speak to the subject as well as she might have, given the opportunity.

Another problem with this process, as is probably evident by now, is its price. The developers are also making guesses and filling in design gaps, and typically much of this improvisation ends up back in the hands of the designers. Every time there has to be a design revision or a functionality add-on, the developers are re-doing work.

A New Way

“Content first” is a phrase that’s been thrown around recently as an alternative approach. The name says it all—bake your content strategy before heading into design. A website is the content—everything else is there to support it.

Content Strategy

In the Content First process, content strategy is king. What are the clear, measurable goals of this site? How can the structure, hierarchy, copy, imagery, and/or video help meet these goals? The actual team that develops the content strategy will depend on the organization; ideally there is a content strategist, people from marketing, people from sales, and anyone else involved the branding and identity of the company. The design/UX team can be involved in strategy, but should be brought in for the wireframing process to interpret the plan into action. Once there is a consensus of strategy, actual content can start being created in tandem with wireframes.

Prototyping

From wireframing, we move into prototyping, where the development team enters the process. Having the development team review the wireframes and make early recommendations for functionality and organization is absolutely critical for success. Not only can the developers make suggestions for site flow and organization, they can point out any potential development problems or even small changes that can result in huge time savings, which is key for keeping the project on target, both in terms of timeline as well as budget.

Design

At this point in the process, the design team is brought in and given clear direction on the site goals, the strategy to reach those goals, and actual content (which isn’t necessarily 100% complete at this point). I cannot stress how much time can be wasted by designers trying to invent content when they aren’t given enough to work with from the start. With the real meat of the site in their hands, not only will the design come easier, but the design will be much stronger since the strategy will be informing every design decision.

They will also have the valuable addition of working prototypes, which they can use as a road map to see all of the bits and pieces that need to be designed but are often forgotten in a static design—like hover and active states, animations, forms, error messages, and so on.

The development team can also start building out the content management system at the same time. With a clear working prototype, the buckets of content will already be established, so the developer has clear content types to implement. Clarity from the get-go will mean less back and forth on the back end.

Integration

Once design templates are approved, they can be implemented with the existing CMS. The copywriter can tweak his work directly in the CMS, potentially reworking parts that read differently once in a design. There will always be back and forth between design and content, as the design can change the meaning of the content. How the content team and the design team work together will depend on the make up of your team; in an ideal world they would be in constant contact, as they both feed off each other. But just as the designer needs to make small tweaks once the design is interpreted by the development team, the writer will need to do the same once content is interpreted by the designer.

The real point to all this is that everyone is involved in the entire process, especially if the teams are all separate contractors. Every step of the process supports the purpose and goals of the website, and every team has crystal clear direction. While it can seem like a time waster to bring everyone into the room at the beginning, this process can minimize re-work, guesswork, and forcing square pegs into round holes.