For my first post, I wanted to tackle a subject that I’ve been thinking about for some time now: writing skills as a job requirement for UX professionals.
There has been a lot of discussion about the UX skillset—what it is, what it should be, and what it doesn’t necessarily need to be but might be nice to include. However, these discussions tend to revolve whether UX folks need to be able to code or create comp-level visual mockups. While worth debating, these issues won’t really affect most people’s day-to-day lives. If you’re an employed UX designer who can’t code, you’re fine; just don’t apply for jobs whose requirements include creating interactive prototypes (duh).
However, you’ll be very hard-pressed to find a UX gig that doesn’t require you to create documentation of some sort, most likely with fairly extensive written specifications.1 So what does this all mean? Basically, if you’re the business of creating these specification documents, you have to ensure that they’ll be understood by those tasked with taking your specs and transforming them into live products.
Don’t get it twisted: I’m not saying that every UX designer should be able to double as an adjunct writing professor, but a certain level of proficiency is an absolute must, for a few reasons.2
Don’t make em think3
First and foremost, as UX professionals, one of our main goals is to help create products that are enjoyable, efficient, and easy to use. One of the ways we do this is by eliminating cognitive strain from the experiences we design. No UX designer’s goal is to develop something that elicits a lot of head-scratching and questions.4 Given that we are often tasked with designing complex websites/applications/etc., and stripping the perceived complexity down to the absolute minimum, we need to be able to describe our product in a simple manner. Or, to put it another way, if you can’t describe a feature or an interaction pattern that you designed in language simple enough that a developer—who presumably has some expertise in bringing to life such features and interaction patterns—then you’re facing at least one of two problems:
- The item in question is too complicated to explain BECAUSE it’s too complicated for the user (sorry!)
- Your written communication skills need some honing (that’s ok, though, nobody’s perfect)
Be extra good to your colleagues
The second problem above leads into another point: It’s the developers who really rely on our specs. The developers are also the folks who tend to get stuck working the most grueling hours, racing against a looming deadline not just the day before a review, but almost every bloody day (in my experience, at least). Every time a developer asks you to clarify something from your document, that’s time taken away from actually developing. The more this happens the more time is lost; the more time is lost the more annoyance and resentment can build up. Such resentment can cascade and the overall team dynamic can suffer as a result. Some say that we should be most concerned with the users, and this is true, but I like to think that we can try to make life a bit easier for everyone involved, not just for the end-user.5
Be clear like visine
Potentially worse than requiring a developer to constantly ask you what you meant by X is the scenario where they misinterpret your specifications and build a feature to work differently than it’s supposed to. Sure, it might be caught in testing, assuming you or another person who knows how it’s supposed to work is doing QA. But what if QA is outsourced to another firm—one whose testers had the same interpretation of your spec? Bad news all round…
Beyond the spec
Writing doesn’t just apply to functional specs and wireframe annotations, by the way. UX folk often have to create, or assist in the creation of, conceptual decks to sell ideas to clients (or higher ups). If a copywriter isn’t available to assist, then it may be up to you to create the majority of the content. Presenting a conceptual deck riddled with errors, incomplete sentences, and weird syntax is NOT a good look.
Even on a day-to-day level, we write all the time. Skype chat, IM, and other tools are used across many organizations for quick communication. That’s not even mentioning the most obvious example of everyday writing: E-mail. Like it or not, emails that read like tweets from the not-so-bright foreign exchange student reflect poorly on the author. Clients don’t like it, nor does management.
So, if you aren’t the best writer, take some time to try and get better. You’ll be helping your coworkers, yourself, and potentially your users! Below are a few resources with tips, tools, and rules that can help improve your writing chops:
Pro Writing Aid – Pretty awesome tool that will scan your text and check for errors and even repeated words!
Grammar Girl’s Tips – This great tool for the layperson is full of good general writing tips and help with complex grammar rules.
Writing Tips for Non-Writers Who Don’t Want to Work at Writing – Pretty self-explanatory, no?
Elements of Style Online – This Strunk & White classic might be a bit dense for most purposes, but it’s been an invaluable reference for writers and editors since first published in 1918
- The ‘Lean UX’ movement/process seems to be an exception to this, but I’ve never experienced a process like this, so I can’t really comment on its prevalence—or efficacy. Check out Jeff Gothelf’s article on the subject here: http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/ [↩]
- Besides, adjuncts don’t get paid anywhere near enough money for that particular moonlighting effort to be worth the time involved. [↩]
- Sorry, Mr. Krug [↩]
- “What happens if the user does X before Y?” “What if there’s no content for this module?” and so on, and so on x 1000000 [↩]
- Call me an idealist, but wouldn’t it be nice if everyone thought this way? [↩]