Happy campers: 5 lessons learned from content camps
From sandbox to camp — find out how to get your clients up and running on their brand new CMS, while giving them a great customer experience.
Picture this: Your several-month project is winding down. QA has had a full sprint to dig around and come up with bugs. Your client has had demos and walkthroughs all along, but they’re understandably eager to get cracking on content entry.
You could easily hand over the product at this point and technically be finished with the build. Maybe you toss in a content entry manual of copy-and-pasted snippets from other manuals over the years and links to online documentation. Maybe you have a couple of quick phone sessions for troubleshooting basic settings and configuration.
Sure, you could do that. Or…
You could actually help your clients make use of the full potential available in the product you’ve both pored over for months.
That sounds like a much better experience for everyone involved!
This is why we love content camps: a 1–3 day series of back-to-back full day sessions where we simultaneously train and support the content entry team. Content is entered, settings are configured, lunch is delivered, and trouble spots are identified prior to release. After years of testing every method for releasing a project, we’ve really come to love this approach.
A pretty typical ecentricarts content camp in progress. Actual experience may vary.*
Here are five helpful lessons we’ve picked up from our campers:
1. You’re in a long-term relationship
No matter the size of the project, you have formed a bond between your team and the client’s. Weeks, months, or even years of phone calls, emails, Basecamp threads, and any manner of back and forth has garnered a (hopefully fruitful) relationship. Together, you’ve built a short-hand language of features and functionality that no other team or project will share. You have formed a well-oiled machine, ready to unleash a beautiful product on the unsuspecting world.
With all that having passed, why would the relationship need to come to an abrupt end just because of a delivery timeline? You and the client have spent all this time learning to work with one another. After all the tough decisions and straight talk, it feels like time off when the whole team spends a few days together to run through the project.
Enjoy yourself. Have some fun while breathing life into the product. Why flee from a rough sketch when you can triumphantly hand off a fully fledged masterpiece?
2. Is it really a product if no one can use it?
You have built a fully functional, dynamic, masterful project from the scattered thoughts of a concept. This is no small feat. Congratulations.
The high fives and champagne toasts die down after a day, and your team starts planning on the next project. Out of nowhere, days later, you get an email…
The client needs to update a banner or post a press release with some vital information for their organization. You know your system can handle it, so you question why they need your help. The process is just so simple: adjust this page type, clone an existing template, edit that custom field set, extend this nested taxonomy layer.
Except that you never got around to passing on this simple process.
That’s where the key difference lives between an off-the-shelf product and a fully fleshed-out custom solution. Presumably, your masterwork didn’t come directly from an online retailer, plugin library, or open source design pattern. How would the client know how to work with it if you haven’t provided custom guidance?
Over the course of a project, both your team and the client’s will be able to look at user stories, acceptance criteria, feature documentation, and release notes to see what’s included — but this is no substitute for teaching them how to work with your work. Every party involved will have a different idea of how the product should work, and it is your duty to communicate how it does.
3.You know what they say about assumptions?
Every stage of a project will build a series of assumptions. The longer the project, the more those assumptions will build and build. Effective planning is all about reducing those assumptions (by establishing them as requirements or core definitions), but even the most detailed plans will still lug around a few. These can bubble up from differing thoughts about a feature’s functionality, a template’s flexibility, the content tree structure — anything, really.
The trouble comes when your (build) assumptions collide with the client’s (usage) assumptions. For instance, the development side could easily assume that a standard file upload control would cover all basic usage on a site’s custom forms (that is, after all, the semantically correct default HTML field). Meanwhile, the content entry and business requirements side could have a perfectly valid case for needing multiple files loaded into a form, using a user-friendly drag-and-drop interface (that is, after all, the way it works on just about every larger site with file uploads — Google Drive, DropBox, WordPress admin, etc.). In the scope of planning a great, big project, it’s pretty easy for something like this to fall through the cracks — but if your deployment plan consists of casually whistling while you stroll away with your hands in your pockets, this will become an issue.
Google Drive’s bells-and-whistles uploader interface is a monumental leap above the standard file upload control — and considerably more complex to put together.*
This is where content camps come in. You guide the client team through your assumptions, and they jump in, testing against their own set. The goal is to have little variance between the two, but a robust training session will let both sides fully test and adjust their assumptions.
4. Your product will get “broken”
You’ve built something beautiful. QA has been through, testing every user story, and your masterful creation stands triumphant. Your team feels great and the client team is ready to rock and roll.
Does that look right to you?
Is it supposed to do that?
Why isn’t that showing up?
The questions start rolling in, and you need to think on your feet. Many notes can be solved with an improvised workaround or a better demonstration, but there will be genuine issues. Don’t get upset. Remember that it is not humanly possible for the client to have communicated every possible intention their team would have with every single component. Just as it’s not possible, as much as you try, to predict every possible iteration of content they would want or need to enter.
Watching anyone interact with a product you built is a humbling and inspiring experience. Use it to strengthen your understanding of user interaction and modify your future work with that in mind. Look for the trouble spots, any minor point of confusion or conflict, and take it upon yourself to trim that away. Your work will be cleaner and your client happier when you figure out how to transform issues into a superior product.
There’s also a bit of pride to be had in finding a bug. Trust that your client is learning the environment when they have the confidence to tell you what you’ve done wrong. If you’ve built a confusing or unusable product, no one will know a bug from a feature.
5. Even experts start as novices
When you spend your working hours nose-deep in the administrator interface for one particular CMS, it’s pretty tough to remember a time when you didn’t know how to find everything. It is entirely possible, however, that your client has never used that particular CMS. Or any CMS.
That is completely fine. Expected, even. We all start somewhere.
This can become an issue when you hand over a product, expecting the client to fully absorb every custom feature and magnificent complexity by skimming your rapidly-drafted 10-page manual. After all, could your team realistically be expected to understand your client’s entire business structure, product offerings, and accounting process in a quick 30-minute meet-and-greet?
Hint: If your answer is “yes,” you probably aren’t doing your job.
An effective content camp will help your client become experts in using the product your team has built. They will not only learn the system, but grow to own features and components. One person will take a shining to widgets and specialty CTAs, another member will play around with image resizing, while someone else will start to push the capabilities of the navigation structure. This is expertise in the making. Have fun with it and encourage everyone to keep learning by leveraging whatever element draws them in.
Packing Up
The single biggest value of content camp is to reduce the pressure for everyone involved. Your team is there to help out. The client team is there to focus on breathing life into the product. Anyone can bring up questions, offer workarounds, or raise concerns. Learning comes naturally and painlessly while you’re all working together to launch.
Learning isn’t exclusive to the client team, either. Take a step back to collect what your team has learned from the cooperative experience. Your next project will be that much better as a result.
*Since Medium doesn’t appear to allow alt text on images, I’ve opted to use the caption space for that purpose and include would-be captions as an italicized block, below the image.
Update: They definitely don’t:
