I’ve had an ongoing debate with my coworkers for some time now regarding the subject of content entry. We know the story behind content, he’s king. Cliché as it sounds, it’s still the case. In my experience, content is the most important piece of the puzzle that no one thinks about until the last second. Internally, we’ve tried to circumvent this phenomenon by including content population within our process.
Should the project include it, we’ll work with clients to finalize their content strategy from top to bottom and work with them to finalize copy, imagery, and other assets. The part that comes with some internal divide in my office, however, is that pesky population part. Who does it, and when?
We should do it, we provide a service
One side of the office argues that we should provide content entry as part of the development process. While final content shouldn’t hold up development in any way, this camp feels that once content has been finalized, it should be provided from the client in its native form and it’s our job as the service provider to enter it all. I see the positive, customer service aspect of that solution, but I also see a ton of red flags.
First and foremost, have you ever received photo gallery content (read: photos) in a Word doc? Yeah, I have too. Last week in fact. Although it’s labeled as final, much of the content is still missing and much of what’s there isn’t organized in such a way that makes much sense to the developer or production manager that actually has to input everything.
By far, though, the worst offense that I can see is that it’s delaying a completely necessary part of the project. The part where you hand over the keys to your client and they actually use the content management system you spent 3 months setting up for them.
We provide extensive documentation in conjunction with a site staging environment, and the tools in place exist for the client to use. Why would we delay that and take it upon ourselves to use the tools for them? We would do it because content entry is not fun, it’s very tedious. We’d also do it to make sure it’s done on time and in such a way where we can take advantage of the little tips and tricks we’ve come up with can be fully taken advantage of. But is it for naught?
While the initial content population might be top to bottom perfection if done in house, at some point you’re going to have to relinquish control to the client and they’re going to do everything in their power to make that text centered, bold, capitalized, and “a red that pops” once a new promotion begins. I guess what I’m saying is, why wait until the site is live to try and sway your client in the right direction as opposed to when it’s on the staging server, hidden from public view? If the client is populating all of the content, you can monitor how they are using the CMS and educate accordingly.
The client should do it, it’s their site
The other camp at the office feels that it’s the job of the client to populate their own content on their website once it’s to a stage where the CMS will facilitate the additions. This camp feels that in addition to the documentation we provide, the client needs working knowledge of the website, because chances are they didn’t read the documentation anyway, and won’t until an emergency edit needs to be made at a later date.
While we do work with clients on a consistent basis to finalize content, the only one to have it truly and absolutely organized is the client, and often times it’s very difficult to have a client transfer the assets in such a way where it makes as much sense on our end. Why cloud the waters? Why not just let the client enter the content in the exact way it’s organized in their head?
Many times when we’re entering content we’ll see that the wrong assets are incomplete or categorized improperly, which causes a certain amount of additional back and forth with the client to number one make it clear which page we’re talking about and number two explain what was wrong and what the client needs to do to make it right. This is often a very circular, frustrating process that we’d rather avoid altogether. If the client is entering their own content, it’s a moot point because they plainly see the exact problem at hand.
The major argument against the client entering their own content is customer service. Is content entry putting your client to work? I try to put myself in the shoes of the client, having just gone through this extensive process of working with a company to build my dream website. I might not be the most computer savvy person, but I went with this company because they showed me that managing my website isn’t as scary and impossible as I was once told. I want to get my hands dirty, I don’t want to be scared of making updates to the site in the future, once I’m on my own.
What’s my take?
I know I can’t help my bias of actually building these websites and thinking about how much a client willshould love working with the content management system the way I’m setting it up. I try to be objective with this situation, as I do with all client situations. I feel that it helps me do my job that much better, but I see both sides with this argument.
I do have a formulated an opinion on the subject, though. I’d prefer to hold off in saying it outright in an effort to hopefully spark some conversation in the comment thread, but at some point soon I’ll plead my case in line with one of the camps above.
Comments
As with everything, it is contextual, but my opinion is we should provide it as a service.
Hey Nate, I’d love to hear more behind your stance with this. Have you tried both angles and only found a positive outcome with populating on our end? Do you not think a client needs to be tossed into the deep end to learn how to swim right out of the gate? I’d love to know more!
For the sake of the sites integrity, I think that the person/company who created it should input the content for the initial launch. Reason being, content (voice & length) can really support or destroy a design. There are sometimes specific areas of content that are only intended to hold 2 or 3 word headlines, or 1 paragraph of body text. This specific intention of content length can really help drive home a message. If a client gets the keys without any “template” so-to-speak, they might flood these areas with way too much; rendering the site (or at least that section of the site) ineffective.
Besides that, it’s a good service. After all, you wouldn’t buy a car new car without the stereo installed, would you? I wouldn’t. So all in all, you can charge extra for the service, get a better outcome and make the client double happy.
Client/Consultant collaboration or find a third party company that can provide the services and who is willing to work with both you and the client.
This should help with best practices and stay true to the copy as it relates to the specific industry that the client competes in.
I’m a designer/dev’r though, I’m not a writer. Writing content that sounds intelligent about products and services my clients offer –typically that they are experts about– would be a waste of my clients resources because it would take much longer then it should, and the fact that I don’t understand subject would probably come through in some way.
If were talking about just copying an pasting text that the client emails to us in for them, well… then it’s not an issue of content. It’s an issue of the systems we’ve put in place to lower the barriers for the client to take control of this in the first place. And that’s our fault. Because I believe this can be made a simple enough process for the client.
Meaning, as a developer, we can make the content implementation (for the client) a bulletproof thing. I’m not saying it’s easy. But that should be the goal. And tools like Pods on WP, and custom content types In expression engine and WP 3, etc, are the tools we need to call on to do this..
I agree that it’s a good service, but (and I’m just playing snarky here) it’s the client’s site, right? We are paid to give them what they want and there are those times where explaining that something is bad just doesn’t hit home enough and that headline will indeed find itself spanning two lines. In an ideal world, the content would be finalized before the stage of population is reached, and hopefully those red flag situations are squashed before it’s too late!
I can definitely see it being a good, billable, service. Great analogy with buying a car stereo, but you do pay installation when you buy something aftermarket. “When you want something done right…” — right?
I think the debate on this subject is more-so behind why either side should populate content as opposed to a willingness to do so. I did mention that I feel it’s quite tedious but I also see the worth in a client taking the plunge and populating the content on their end. Do you feel that content population should be an equal responsibility for both parties?
Great points, I do feel that unless you have a copywriter on staff, taking content creation on yourself isn’t in the best interest of the project. To be super clear, yes, I was pretty much referring to an issue of copying and pasting client-provided content where if we handle the content population, the client provides it, we copy and paste into the CMS. Are we simply playing the middle man by copying and pasting? Why not have the client do that themselves and in doing so learn the CMS we’ve provided for them? What do you think?
I do feel that it should be equal responsibility for both parties. Ensuring accuracy of content and filling in content aside; there is certainly more to take away from this.
It gives the client an opportunity to experience and learn what ever publishing platform the consultant has put in place for them to use. To me this educates the client, builds confidence for the client, and eliminates some future “hand holding”.
On the consulting side of things it reaffirms your knowledge and skill as a consultant and helps get you better familiar with who your client is and what their business is about.
Yes, content entry is a service. The keyword here is service, and it’s a service that shouldn’t be free. Let the client decide: if they want to pay for it, then include a line item for it in the contract; if they prefer to save their money, let them know they will have to enter content on their own.
Yes, I agree with Chris. It’s a service. I try to give the client the option up front and give them the reasons why they may want you to do it and why it’d be good for them to do it as well. Then the expectation is there and the choice is theirs.
We’re in both camps, -but in a unique way. We created our product http://jumpchart.com so that part of our team could be working with the client on creating architecture and organizing content _before_ and if necessary, during the development process. We like to design websites around content rather than shoehorning it in later. Using our own API, we directly import our content wireframes straight into our CMS, -skipping the tedious content entry part…
The point of implementing a CMS is to allow for easy content entry, regardless of who actually performs the work. We’re either making it easy for the client or easy for ourselves. I agree with Chris, this should be a paid service and should typically be agreed upon before the site is created. In most circumstances, and especially in freelance, copy-writing is not a developers strongest attribute. In the end, leave content entry to the client unless you advertise (and excel at) the service and the client chooses to pay for it.
I honestly think that in almost every situation a hybrid approach works great. I have (an actively do) end up doing it both ways, one the site sits unlaunched for months because the client doesn’t bother working on it – the other they have no idea how to use the CMS because they never made an effort to try.
But to build out enough of the site to launch and then hand it over to them to finish up the last “non-critical” sections is a good balance of moving the site along and getting it mostly finished while providing the client some real-world hands on training.
It is hard to get the client to buy in to it, but when they do it seems to work better than one way or the other.
We should provide it as a service, a paid service.
I would charge an hourly rate that favors my wallet, which will benefit either party, in having me do it, I make a good rate from it, if they do it, they save money. Why such a high hourly rate? – to influence them to do it themselves.
I am a strong believer that we need to input content into the CMS before launch of the site (although this isn’t what is being asked of you, but worth mentioning) and that will allow them to learn from example of how the content is entered translate onto their webpage(s).
From there, they need to take ownership of their content, whether that is updating it themselves or paying for someone to do that for them.
Ah. Great Question and Conversation.
We put 95+% of the content in for clients. We’re talking 1000s of pages sometimes. We even did a spanish variation for a client once! About 300 pages. Whew.
I actually wish that we could get to a point that would allow for quicker handoff of the site once development is complete. This would allow for more specialized/complicated content to be added by us. More energy could be spent on ensuring that the most important pages (conversion pages and actionable pages) are created by us.
I really have to spend more time checking out jumpchart. I hope that in the next project our team can sink its collective teeth into the app.
We use Jumpchart and although not every client gets it first time, with a bit of chat through with them they see the benefits. It’s particularly useful as a sitemap tool.
On the issue of service vs deep end, it has to be a custom fit for the client. Each client offers up a different scenario based on time constraints, technical proficiency, availability of content and financial resources.
I’d prefer to be paid just for a content strategy based on the information architecture and discussions with their SEO consultant and then let them just get on with it in the CMS or shop, but you need a really enlightened, sophisticated, time rich, deep pocketed client for that. Let me know when you find one…
Usually, my preferred approach is that we should do the data entry, but paired with the client. So, during that time we are both doing data entry and staff training and at the end of that process we have:
1. Fixed some bugs
2. Changed some details to streamline data input for them
3. Transferred the required knowledge
Since the knowledge transfer is a required step of the process, it’s usually a win-win scenario doing that while making the data entry. Optimizes time and costs (well, to a certain extent).
Really great conversation going on in this thread because these issues are right at the forefront when building a CMS for clients. It certainly makes me think about how my concerns, during development and build-out, about delays in receiving all of the content from the client (not to mention what level of dis-organization it will be in when it arrives), abruptly switch to concerns about all the ways that the client might find to improperly style and display new content after we’ve launched and given them author/editor rights.
After reading this post I am inclined to say that Clients should be involved in the process, adding content to the beta site as an additional level of hands-on CMS training, because I think that it would help address the concerns that I inevitably start to feel. Now, that is not to say that they should be responsible for adding all the content by themselves, but it should be folded into the training. And it should be framed that way too. I think it’s a natural progression in the workflow of a CMS site.
Of course it might not work for every client either, and so I don’t think that we can remove ourselves from the process entirely. When you get down to it, the site map is really content too, albeit in outline form. And everything else grows from that. Even if the client knows exactly what they want their content to be in their head, it should exist on a page or a planning document, separate from a finished website before it ever goes live. Even a developer who doesn’t know much about writing can still help protect a client from themselves by being another set of eyeballs reading over the copy before it is approved.
I bet that given the right client, the right project, the right person client-side responsible for adding content, involving them early in the process could lead to a huge boost in efficiency.
This is a great article and conversation, and something I’d already been thinking about recently due to the challenges of short development timelines, clients who initially don’t know what they want, late changes of content and design, and overall efficiency.
We typically get a sitemap/IA outlining all the pages/sections of the site – why not enter this as categories and dummy pages into the CMS as soon as we have it? (Rather than waiting for final designs and content to start building the CMS.)
We typically get rough wireframes as part of the preliminary design process – why not just create a CMS site templates based on the wireframes (with only very rough styles initially), and create corresponding editable content areas in the CMS to match up with them, rather than waiting for the final designs to start building the site?
The designer typically works with some form of branding style guide to start with – fonts, colors, etc. Why not enter this into our CSS file right from the beginning, so at least the fonts and colors and relative heading sizes are right (and everyone can see early on how they work on the website)?
We typically ask our SEO team to populate a spreadsheet with url, page title, meta description, and h1 tag (as well as keywords to emphasize when writing content) – why not have them enter it straight into the CMS? (If the CMS is any good, that shouldn’t really be much harder than entering into a spreadsheet, right?)
We typically ask clients (or copywriters) to populate a content spreadsheet, with a tab per page of content, and each content chunk (ie, editable content area or field in the CMS) on a separate row (and labeled as corresponding to an area on the sitemap), along with information on links, images, and other associated files. Why not just have them enter it straight into the CMS? Even if it’s not styled yet, why not hold the content there, on the page it belongs on (and even in the correct editable area)? We (the developers) can clean it up into semantic HTML once it’s entered (or enforce only semantic HTML via the installed editor).
As the site designers/developers, we will do the work of creating the stylefile and template based on the final design, and maybe properly coding the content into HTML, but why do we have to ask everyone else to copy/paste stuff into other documents, then match those up with the actual pages in the CMS and copy / paste them back out? Why not just skip that whole middle step and have everyone throw their stuff straight into the CMS where it belongs? (With one caveat being that original Word docs might contain styling clues we’d want to refer to later.)
As a “content management system”, doesn’t a CMS seem like a better place to MANAGE CONTENT in a remotely-accessible, multi-user, version-controlled setting than, say, a spreadsheet or Word doc? Why should content management in the CMS only start after the site launches?
Not only does it seem like this could save a lot of redundant work, it could allow more processes to occur in parallel, allow all involved parties to see the site as it is developing (as a living prototype gradually evolving into their final site), and (as mentioned in the article) gets the clients more comfortable with the CMS during the build process, rather than after the handover.
After thinking about this possibility, I had already stumbled on Jumpchart, which looks fantastic, but then begs the question – what makes it different from the final CMS the site will be built in? I mean, it looks and sounds like a (crippled) CMS to me, and if the site is going to be published in Drupal or SilverStripe, why build it in Jumpchart, then re-build it in the other CMS? Why not just build it once? (Conversely, if Jumpchart is so much better for initial site building, maybe it should transition to being a full CMS, not just a prototyping tool for other CMS’s…)