Part 2 – The agency side

In this second part of Can you just send us your content, I focus on the web studio perspective; what studios can do to support clients to have their content prepared in time for website design. If you didn’t read the first part of the story, why not have a look now so you get the balanced view.

Having recently been through the process on the client-side, as well as being an experienced agency-side web project manager, I know all too well that content development sits squarely at the client’s feet, the content is generally not ready in time and this causes a huge amount of grief for clients and their agencies.

The problem is that clients cannot always complete the content strategy, planning and production on their own. It’s complex; there’s many moving parts to consider and clients usually have a large number of stakeholders to engage and manage as well as dealing with content strategy, sourcing, review processes etc. Clients may also be looking for support and guidance from user experience designers and web developers to bring their content to life, so they hold back until the agency is engaged. Yet all too often, web agencies avoid getting involved, even though they really need the content produced in order to design and build the website. Why is that?

I think it’s because agencies have more than enough on their plate without also having to consider the content in detail (or the lack thereof). The client needs to be responsible for their own content right? To work around this, agencies are very clear with clients that ‘the content’ is outside their scope of work. They pop a sentence into the contract which says ‘content is the client’s responsibility’ and then ask the client repeatedly throughout the project “can you send us your content” until they get (all or some of) it. Generally the end result is that the timeline is blown out, the CMS does not cater for all the content requirements and the website sits in an incomplete state until the client can catchup. The agency loses momentum on the project and then wastes time (and money) ramping up again once the client content is ready. This is not optimal for either the agency or the client, so something needs to change.

Here’s 6 important content-related activities that web agencies should consider before scoping their next client website design and development project.

#1. Assess your client’s digital content maturity level

When you start engaging with a new client about their website requirements, you should get a pretty good sense of their web savviness and how much they have considered their content so far. As soon as you start to think that they may not have considered their content strategy or they have no plans in place yet to source, edit, review and publish the content, you should step in – for the clients benefit and yours. Help the client understand how important it is for their content strategy to be fully developed and for most of their content to be sourced before you start website design. Explain to the client that your UX designers and Information Architects are fantastic at what they do, but they’re not mind readers; they need something upon which to base their information and navigation design. Offer to scope in:

  • Helping your client to plan out their content requirements before you begin wireframes or start designing the CMS
  • Sending your UX/IA team in to support the client with content planning
  • Helping design content collection templates and tools that are simple for content providers to use, but robust enough to inform the UX/IA and CMS design
  • Completing an expert review of  the client content strategy, plans and production approach
  • Additional UX/IA design review points, so you can tweak the design iteratively as the content matures over time

#2. Don’t schedule UX design to start until content is produced

Agencies need as much content produced as possible to inform website design. Without the content, the design can suffer and the end result will be less than optimal for both the agency and the client. It’s a win-win outcome if clients can be encouraged to produce their content before design starts, but I know this is easier said than done. The project timeline will stretch out further than the client can bear, you run the risk of losing momentum and knowledge as you pick up then put down the project, your team members may change in the interim, etc.

So, I’m proposing that website design and development projects should not start until (most of, if not all) content is produced. What this means is that you’d need to take a two-phased approach to the project:

  1. Scope – conduct the usual scoping activities to give the client the solution, ballpark cost and timeline they need to get their budget approved and kickoff the project at their end. Then, you go away until they’ve produced their content. Hopefully you won’t completely go away, as your client will most likely need your advice and input during the content production process.
  2. Design & build – once the content is produced, you re-engage with the client, and kick start the design process, as you normally would.

I’m going to propose this approach on my next couple of website design and development projects. I really think it can work. It will look something like this…

Content-ready website development approach
High level website development approach, putting content production before website design and build.

#3. Don’t assume anything. Document everything.

Clients don’t always know the web like you do, so they won’t necessarily think (or know) of everything they want up front related to structuring and displaying content and they’ll need you to help them. In the early stages, you should tell them what’s possible, what the latest trends are, what’s so 2010 it needs to be forgotten about and what they could do to work around things like “we want a rotating slider” on a WCAG 2.0 AA compliant site. This helps set their expectations about how some of the content will be handled.

Then you need to document. Even on the smallest website design projects, you must always document the scope of the project – outlining what the client will and will not get for their $2. And if you’re building functionality to deliver content, then you should produce a functional specification. This doesn’t have to be a hard-core 500 page tome of use cases; it can be as simple as a feature checklist that you can use repeatedly – like a shopping list – so you can step through it with  clients and you don’t have to think about the same details every single time.

For example, if the client wants a shopping cart, there’s a range of bog standard functionality that your CMS should provide out of the box. List those things. Then sit down with the client’s requirements to work out what needs to be custom built. List those things. Then sit down with the client, go through the whole list, and show them examples of what each feature will do, making sure they understand the ins and outs of what you’re proposing to build. You should then develop a functional specification, walking the client through it using relevant scenarios that the client will relate to, then ask the client to sign it off. By doing this, you’ll have a baseline document you can point to when the client says “but I thought it was going to work like this?” as well as a reusable shopping cart feature list that you can add/change for each new project.

#4. Think about how editable the content needs to be

I’ve seen so many clients become disheartened (and some disgruntled) because their CMS did not allow them to edit as much content as they thought it would. Perhaps they had their own personal WordPress or Tumblr blog which lets them do all sorts, then you implement a web CMS for them which lets them edit headings, text, links and images only (because that’s all that was in scope). You can understand their frustration.

This is something you should address with the client from the outset, so the client is informed about exactly what they will and will not be able to edit themselves. Be open and honest about what will happen after go live, and how they may (or may not) need your support to add/change/delete certain content.

The level of editability you build in will depend on:

  • Does the client have a dedicated team of people who can be trained to maintain the content? If they do, you are more likely to allow them more flexibility when it comes to what they can and cannot edit using the CMS.
  • Who’s going to support the website ongoing? If it’s your agency, you may want to hold back some areas from being highly editable so you don’t risk the client inadvertently breaking something and calling you at 3am to fix it.
  • Do you trust the client to maintain the integrity of the content post go-live. This is a bit cheeky, given it really is the client’s website so they can in fact do whatever they like to it, but web agencies have pride in their work, and want to see their website continue to look as beautiful as it did on day 1. If you’re not sure the client can maintain the quality, you could either make it less editable or complete periodic reviews, providing feedback about things they need to address.

#5. Use lorem ipsum sparingly

I initially called this point ‘Ban lorem ipsum’. But in doing some further research, I found online discussions about whether the use of placeholder text like ‘lorem ipsum’ should be banned altogether because of the issues it creates downstream. Both sides of the argument present plausible reasons why you should/shouldn’t use placeholder text during the design process. See the good article links below for more information.

How many times have you used lorem ipsum placeholder text throughout wireframe and UI design, only to find that the copy sits there for months, goes through each signoff point unchallenged, and then once the actual content goes in, the client realises the content object is not suitable and asks for it to be drastically changed? You would like to call this a change request (“it’s what they asked for, and its been in the design for months!”), but in fairness you make the change to accommodate the client’s needs and keep them happy.  And you probably die inside just a little bit and lose some of your profit margin as a result?

I prefer to think about lorem ipsum as a tool, and as such should be used sparingly and with care, as you do with any other tool of the trade. If you try not to overuse  placeholder text, instead asking the client to provide actual content at every possible point in the process or only using it for things like captions, you’ll avoid needing to do rework at your own expense. And the client may begin to learn what you need (hopefully before you need it) and will start considering things like microcopy (404 page messages, error messages) in advance before you have to ask “can you send us your content”.

There’s no right or wrong answer here, but the moral of the story is to prioritise content up front (as much as you do the user’s needs) as you design the website, and continue thinking about the content as you move through the process. Use lorem ipsum sparingly and only to present lines of copy which aren’t (and don’t need to be) written yet.

“The information architect hasn’t seen this copy since it was “lorem ipsum” in the wireframes, and if she’d known it was going to say THAT, she would have taken a totally different approach.” Content Strategy for the Web, 2nd Edition, Kristina Halvorson and Melissa Rach

Good articles to read

 #6. Don’t ask clients to “send us your content”

Easier said than done, I know. But the perennial problem of client content not being ready or fully considered before website design commences needs to be solved. And asking  clients to “send us your content” doesn’t solve anything.

On my recent project, the client was more organised than most when it came to the content. We had teams of people producing content for each section of the site, all working towards the vision articulated by the project owner. This vision had been documented and distributed, so everyone involved knew the outcome we were trying to achieve. There was some devil in the detail that slipped us up along the way, but in general, the content development and subsequent entry into the CMS worked quite well. Some people still had difficulty visualising how their content was going to be displayed on the website though. I tried to bridge this gap by doing the following:

  • Before design started, we developed Word templates to collect the content in a standard format, matching the fields in the CMS. This made content entry much easier. We got some rubbish keywords and not many images supplied, but in general the quality of the content was good enough to work with. And the site templates and CMS were able to be designed to suit the content requirements.
  • After design was complete, we produced simple mockups of all the pages in some key website sections, so the client stakeholders could see how their content would hang together. It was then easier for them to go away and write copy, source images, videos and links to other websites, knowing what the whole section would look like and how the different pieces of content would work together.
  • Later in the project, we created some example pages on the staging environment, made them look as complete and perfect as possible, then PDf’d the pages and showed the people producing content so they could see how the end product would look. They tweaked their content to suit.

I was able to co-ordinate these activities because I have years of agency-side web project management experience. I daresay most clients wouldn’t have this experience, so that means agencies should step in to bridge the gaps if they can see the client is struggling with the content. I think its a win-win situation – clients get the support they need to produce appropriate content, whilst the agency is able to design and build the website and its CMS to match the content, resulting in a far better quality outcome that you can be proud to put your name to. Not to mention additional consulting revenue for the agency.


There’s many things agencies can do to solve the ‘content’ problem. Here’s a recap of the 6 lessons I learned:

  • Work closely with the client and help them to develop their content strategy, planning and production approach.
  • Try to schedule the start of UX design after most of the content has been produced. This won’t always be practical, but its really worth a crack!
  • Be careful about using placeholder text in wireframes and prototypes. Ask the client to try to fill gaps with actual content to force them to really think about it.
  • Support the client as they source, edit, review and publish their content. In any way you can.
  • Don’t just ask the client to “send us your content”. Help them get it ready for you.

By addressing these points, there should be minimal surprises and the job is more likely to be done on time and to budget, with far less pain and suffering.

In my next post, I’ll discuss how the content strategy, planning and production could be done before web design commences.