Recently worked on a project where the everyone kept saying, "the client will write the content" or "we'll get to content when the site is done". I suspected this was a recipe for disaster and it was. If you depend on the client to write content to essentially "finish" the site it will never be completed.
So, I want to avoid this pain in the future. How do some of you inspire your clients to provide enough information to create a website? We aren't talking about reams of material - enough to create the front page, about, contact, a brief company FAQ, product specs - the bare bones of information to design a site around. The use case would be small shops where the client doesn't have a dedicated content person to turn to so you have to bug them directly or try to write it yourself.
How do you inspire clients to write content for their websites? This group is "Web Managers / Content Editors" so I know our group does write some material that will go on the web. However, no Content Editor is going to be the master of all subjects so you'll need to gather information from your client at some point. For All-In-One shops where one person does everything (development, administration, theme, ect), how do you address the content problem from a client that is eager to have their website finished but can't find the time to write anything about said business/product/service/ect. They want it yesterday but don't know what to write.
I thought about different strategies, like using forms that gather information about product specs, company focus, vision, company ethic, ect and then using that to write the pages. Mainly looking for experience from some of you who have had to work with this issue. Do any of you have advice to give?
Many thanks,
Kevin
p.s. cross posting in Curriculum and Training because I think this may be relevant to them as well.
Comments
Hi Kevin, Are you talking
Hi Kevin,
Are you talking about small business brochure sites? That's where I've had most of the same situations you describe.
If there's an RFP, you should have a little to go on. If not, give them a set of questions to answer (in a design brief or something similar).
When all else fails here's one approach I've used successfully with small clients. Ask for their promotional materials, brochures, flyers, coupons, ads. Repurpose as much of that material as possible, at first in the sitemap, then instead of lorum ipsum. Show it to them and ask for revisions, additions.
On the other hand, I find more issues with overgrown websites that need reorganization and pruning. How about you?
Best, Marilyn
Ask for examples
I think we've all been to design discussions where a client whose business is not any kind of content generation says it "needs" five news channels, three-level navigation, and a Facebook like button on every block. I simply ask for examples of each to "flesh out the mockup with real data" — not "we'll re-use the text from the tri-fold and copy the rate card," but the actual text to put in an actual prototype. And that is when they realize that they need to choose banners and find quicklinks and write and write. And then my suggestion to use shorter paragraphs and bulleted lists instead of 6th-grade 5-paragraph essays doesn't seem so terrible after all.
I guess the site I was
I guess the site I was working on could be considered a "brochure" site. How do you typically define a Brochure site? I'm thinking a Brochure site is something a site which is meant to: Inform about a product or service, is aesthetically pleasing (it's perdy), persuade users to purchase the product or service. The site I'm referring to definitely intended to do all those things.
I haven't used a Design Brief but I am going to start. I found this link which has the following suggestions for Design Briefs:
There was a better one than this that I found a while back but I've since lost. That one got really granular with the questions and asked things like "company vibe" and "product mission". To this point I've done a rough design brief via questions over the phone but that is obviously not enough.
choster: I like your style. "flesh out the mockup with real data" is a good unoffensive way to inform the client about what they need to be thinking about regarding content.
http://www.webbfx.net/
I'd say that a "brochure"
I'd say that a "brochure" site is a site that doesn't have a two way interaction with the visitor.
Just like a brochure you have some text and images that are presented to the user and that's it.
Monetize/schedule client participation
I was frustrated by this very issue recently. Was building a 10-site network of library websites -- brand new Drupal sites. I created a 'template' site with real content that I migrated from one of the libraries -- the one with the most content, and used a stock (colorizable) theme. Made it easy for the other branches to simply start by revising that content as their own, then adding/subtracting content from there, and reorganizing the navigation as desired. Produced lots of Views blocks, and user-editable blocks.
I couldn't have made it any easier for them, yet they still failed to migrate over their content sufficient for launch. I had built out all the mechanics of the site, but I needed them to migrate over their content so that I could finishing out the theming, improve the layout (suggesting block visibilities, etc.), and tweak the site based on their use of it. Day before scheduled launch (which was tied to a grant deadline), they still had inappropriate template content on their own site (with references to another library branch), blocks with headings "**** Customize Me *****", and some Lorem ipsum content.
In my case, I asked to be released from the contract (and paid fully for my work), as I could see they would drag it on forever.
From that experience, I think that the best way to deal with it is through contract requirements and monetization. Whereas I normally think of the contract stating what is required of me as developer, I realize the important of it also stating what is required of the client. That compliance should be built into the schedule as well. I'd add a breach of contract clause, so you don't lose money, and your allocated time for the project, if the client creates impediments to completion (as mine did).
Then, you can either build out enough of their content or use Lorem Ipsum (e.g., through Devel Module) to complete the mechanical requirements. Once your development is complete, the rest is up to them.
Schedule the project with completion stages, wherein you get paid after each stage.
STAGE 1:
Developer: Drupal install of core and contributed modules necessary for content creation/migration.
STAGE 2:
Client: Create/migrate content to ____% (be specific about how much that is, and of what type).
STAGE 3:
Developer: Install and configure advanced functionality.
STAGE 4:
Client: Use/test stage 3 work.
STAGE 5:
Developer: Theming.
and so on.
I actually did this. Problem for me was that the client was so difficult to work with (indecisive/disorganized/ill-prepared/apathetic/uncooperative) that I had to constantly re-adjust my project approaches. And, I was wayyyyy too accommodating of them. I had to be a real b*tch at the end just to try to get the project completed so that they didn't lose their grant money. Not fun.
So, try to build in enough incentive ($ penalties) for them to comply, and structure it so that if they don't, you don't lose money because of it.
That sounds like a good
That sounds like a good strategy. Break it up into manageable chunks. Some of this is a communication problem on my part, I need to set solid terms up front so we both know what is expected. I have also have a tendency to be too accommodating as well. :)
You leave off theming until Stage 5, and using a core template until that point? If so, the problem I have run into trying to do it that way is that the client has no vision so you get a lot of, "but I want that navbar blue" or, "can you skoot that over 5 pixils?" rather than the content you are seeking. They simply can't comprehend that the template stage isn't what the final product will look like.
It sounds like your client was apathetic because it wasn't their money, it was the Library's money. People get really interested when it's their dime but when it's someone else's that urgency fades.
http://www.webbfx.net/
Normally, for small project,
Normally, for small project, I build out and theme the site, and then leave it up to the client to migrate content. And, tweak after that. But, for a project with a hard deadline, or if the client's delay will hold up payment to you, it can be a disaster. Problem with doing the theme first is that clients get fixated on the look. I started that way on the referenced library project, and that is what happened.
If the project is a high-volume content site, with lots of moving parts, the organization of that content is important. Harder to theme for that without seeing what it is going to be, and how client intends to present it (what to feature, navigation, etc.)
Thanks
Cool to get perspective on small project versus high volume content sites. I can't say that I've had much luck with the client actually migrating content to their site no matter the size. However, if I structure the contract in stages as you suggest or agree upon terms and get it in writing it wont matter. Setting solid boundaries and expectations on both sides early on is essential.
Thank you everyone for your perspectives. If anyone is looking for a Creative Brief template I found this one http://gettingattention.org/articles/197/planning-budgets/nonprofit-creative-brief-template.html. It's for Nonprofits but I think a lot of this is applicable in most projects.
Many thanks,
Kevin
http://www.webbfx.net/