Unsuck-It.com: A Clear Content, Anti-Jargon Resource
I took a break from a new post to listen to Content Talks. Episode 9, with Mike Monteiro, to be precise.
The topic was the business of design. But along the way, they mentioned UnSuck-It.com.
I’d never heard of it before. (Which, given this blog, is outright bizarre!)
So of course I checked it out. The site is a database of witty common-sense alternatives for jargon terms. Rewritten – “unsucked” – so they make sense.
I am ecstatic to see this. Not only did we badly need this out there, but it means I don’t have to build it myself! (I did have a similar idea in my notes.)
Whoever wrote the ‘unsucked’ explanations deserves a medal. Lots of great sarcasm to quash any jargon-user’s (self-)righteous fury.
I’ll quote a few examples:
Gamification
-Unsucked: “A popular product strategy fantasy about turning every mundane task into Farmville.”
My Comment: While balancing work and play is healthy, the fact that ‘gamification’ exists worries me.
Red Flag
-Unsucked: “Concern.”
My Comment: If you’re in Texas, you can use this. (It’s in the state business code, I think.) Everywhere else? It’s just a concern.
Social Media Strategy
-Unsucked: “Typing into text areas.”
My Comment: Heehee! Hey, wait a second…
Solution
-Unsucked: “Software. Please, just call it software.”
My Comment: Yes! We even have extra add-ons to make it clearer! Software program, software application…a “solution” is what you reach after USING the software!
Take It to the Next Level
-Unsucked: “Improve it.”
My Comment: Hatred of this term has sustained me for years.
“Unsuck” Your Content Before Posting It
I happily recommend this site to everyone writing content. If you’re using a term that’s listed on UnSuck-It.com, reconsider.
Can you be clearer? Chances are you can. Then your content won’t suck.
Next time I’ll write on content development for startups. (Product’s not the only thing you’ll need to work out!) Watch for it soon.
While you wait, why not follow me on Twitter or add Blue Ferret’s Clear Content Writing to your RSS?
Confusing Content: The Opposite of Clear
If I’m going to blog about what I term, “Clear Content,” then I should define its opposite too. Telling the difference between two sides of a coin is much easier if you know what they look like.
Henceforth I will call the opposite – Confusing Content.
Under this label I include things like:
- Long copy that you get lost (and a headache from) reading.
- Webpages that don’t make sense.
- Websites without any conversion process in place.
- Buzzword-laden BS.
- Content which talks about 3 different subjects at once. Or 4. Or 10.
- Sales-heavy copy.
- Content that wasn’t properly targeted (or targeted at all!).
If Content Isn’t Clear, It’s Confusing
You’ve seen Confusing Content on websites, in white papers, in email newsletters. And you thought something like:
“What’s this about?”
“This doesn’t tell me what I need to know.”
“Gah! Back button!”
Clear Content VS. Confusing Content: DING!
The battle begins next post. More coming soon.
(If a website popped into your head reading this, please leave the URL in the comments. I’m always gathering more examples.)
When Should Content “Come In” in the Development Process?
I was watching Karen McGrane’s video on “The 11th Hour Sh*tstorm Problem” earlier today. (It’s a really good video. If you have anything to do with user experience or web development, go watch it. I’ll wait right here.)
Welcome back. So, while watching that, I had a few ideas.
The problem she’s discussing is VERY real. I’ve seen it too many times. But let’s look at it from my end – that of the content writer/producer.
Sometimes development teams focus on their work and think of content as “something that goes in later.” Resulting in content producers (like myself) have awkward last-minute conversations with them. Like this:
“Thank you for finally speaking to me about content. I’ve been trying to coordinate with you and the client for weeks now. What? You built the site already? Here you go then–half-baked content. Have fun figuring out how to fit it in!”
So I thought I’d blog about a question. A question that should help crystallize the “11th Hour” problem – and maybe help a few of us avoid it in future projects.
When should content “come in” in the development process?
Right now content is the red-headed stepchild in most dev processes. It’s the “black box” as Karen put it, that designers & developers block out in their minds. And to be fair, it’s not their primary job, so it makes sense.
Trouble is when they do this, one of two things happen:
The content producers are shoved to the side of the project cycle.
OR
The content itself is ignored.
Both result in – you guessed it. The 11th Hour Sh*tstorm. (Karen, that is a great metaphor. I may borrow it for future meetings.)
So how do we fix this? Well, first by answering the above question of when to bring in the content. I find that…
The best position for content “coming in” is right before the client sees the new site for the first time.
Why then? Because this position forces several changes in the overall development process. All of which help keep everyone content-aware.
Oh, and it helps create better content too.
- It reminds development that the site is not a “bucket” for content – it’s a podium for it.
- It compels use of a content strategy. If the dev team knows content is coming up, and there’s a content strategy involved in the project, then that strategy must work with the overall Web strategy. And vice-versa.
(This also gives a paper trail for everyone to refer to/save themselves with later.) - It compels early buy-in from the client. It’s easy to put content off in favor of development. But if a content writer is right there at initial planning, he’s much harder to ignore…
- It helps you organize the site around user needs. Karen made a big point of this in her presentation, and I agree 100%. The site isn’t there to astonish the client. It’s there to help their customers solve problems. Showing them content DURING development gives more time to sharpen the message.
Content Must Be a Constant Presence
When the client first sees the site, it should have content IN IT. Lorem ipsum filler is now a sign of poor development. (I have decreed it so.)
If content is to be delivered at first-version, then content R&D has to start at the same time as site development. Usability testing, audience research/interviews, UX, outlining…all done while the site goes from wireframe to HTML.
This way content providers stay in the loop. And the client receives reminders about content’s importance. Maybe this will help dev teams avoid last-minute scrambling.
Hey, we content producers don’t like it either. We’re all problem-solvers in one sense or another. So let’s fix this!
Thoughts? Anything to add? Think I’m radically oversimplifying things? Comment away.