Content is "King". Making the king affable requires careful
selection, cohesion and showcase them in the best stage. Platforms,
technologies, features, all service the content in the way a king would
like to be served. The most important aspect of any content based
project - be it websites, collaboration mediums, knowledge management
tools is to share the content in the most usable and likeable fashion
for the users, it is meant to enable and assist.
Invariably
across multiple projects within , the following 5 pitfalls are common
and give a "Oh! yet again" feeling. These are so obvious that they skip
the logic, analytical and focused and otherwise bright business minds
from delivering a best in class experience.
1. Content consumption vs User Engagement
A
content dissemination project is an experience. It needs to enhance or
at the minimum sustain the expectations in every page and at every
visit. Putting in processes and workflow to contain content, validate
contributions, and determine a "Who s who" chart in a content rich
environment is so common sense in the first round, but is very counter
intuitive. Even a captive content dissemination requires users
engagement, not consumption.
Consumption depletes and wears
the content with age. A contributed and user engaged content shapes up
to the needs of the audience and reaches far and wide, fresh every time.
Make it easy to share, allow users to bookmark within your site and in
the browser, make visible the stats, ask for feedback and importantly
scan for usage pattern to bundle the content with likelihood siblings
that users choose before and after the site visit.
Workflows
can focus on moderation, add specialized services like taxonomy
generation, proof reading and editing, ensuring content adequacy across
multiple interaction points and pages, but must be very less towards
routing for approvals and publishing.
Have at any time, your
project has gone down because users were reckless in their contributions
or have written nasty about the topics they care ? How many times after
rejecting a first posting, the same users felt motivated to contribute
more ?
Isn't this the reason why public facing sites become jaded after a couple of visits.
2. Research the audience before "context":
A
user research typically classifies and categorizes the audience by age,
ethnicity, race, region, religion, intelligence, etc, which is good for
presentations but not much useful in final product success. When the
final product isn't a success, will we blame that the audience types who
accessed the site changed from what came out of research ?
A
user research is to sample the intuition for the interactions a general
user base can do at the minimum without an aid. Are instructions
suitable ? Are the colors for a meaning or for differentiation ? Does
the site behave well with custom style sheets ? Can the user be
permitted to move across, up and down the site in a consistent way that
can be explained by word of mouth to another user over a phone ? With a
tool bar, when the site is translated, does it render well within the
layout grids ?
A user research is to ensure the audience
experiences based on their location and need in the site, just like in
an audition. There is a general sensitivity required about the audience
tastes and preferences and a better clue since in the content and web
medium there is a direct interaction on the "stage" with the users.
The
"context" is actually "open" in the web world and only the content
requires definition of a context to drive its meaning and establish its
brand in the web cacaphony.
3. Pitching wireframes and sequencing them as "Site Map":
Wire framing is a good concept. Site map is an essential first step. Both are different, though. Many
a times, we do individual wireframes, thread them together to call as
site map. Not a bad idea and an easy way to visualize.
It has just one flaw:
We are enforcing conformity of page layout and page types (page design)
to decide the site structure. Not creating a site structure to
visualize the flow of "content" is a common mistake and will be a
discussion point at some time in the content strategy meetings.
4. Adopting a "Template X" approach
This
template suited a similar need in project x. Let us fast track it by
fitting the content in the template. This is the main "break" factor. A
new project or a client with similar needs exist because the earlier
solution is not 100% compatible. Else in the age of Google, why take the
pains to execute a content dissemination project ? Template X is for
Project X. While in Project Y, leverage template X is acceptable, but
ensure it suits the needs and never hesitate to go back to blank canvas.
This isn't a "product" which can be configured for multiple
variants by choosing to mix n match or rip-off features to match lower
price points. This is content and a site structure, wireframe, design
and development needs to match "content" and its relevance in "context"
and never the other way around.
5. Missing the link between "copy writing" and "SME" collection
Never
miss to create and follow a style guide. For the project team, it is
boring and looks uniform. For the users it is consistent and sets the
expectations.
6. It is "about" the users and "for" the users, not about and for content:
This is the anti-climax. While all we do is to present content in a
nice and great way, it is one and only about the users and User
Experience. How many times in a content strategy discussion, is there a
serious concern and involvement for users ?
