large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

<a href="http://ift.tt/2qoXqt2">uxdesign.cc &ndash; User Experience Design &mdash; Medium</a> | andy healey 
The role of UX Writer is trending right now, with big organizations such as Google and Dropbox actively recruiting. A few weeks ago <a href="http://ift.tt/2q0rutG">Kristina Bjoran</a> wrote a great article on <a href="http://ift.tt/2oyp2KS">How to Break into UX Writing</a> where she identified that to land one of these roles you’re going to need to show that you’re more than just a pretty writer, and have UX design right at the top of your “Key Skills”.
UX writing is a still considered a relatively new role, a “<a href="http://ift.tt/2mVp7ac">unicorn skill</a>”, outside of California at least. I checked LinkedIn for UX Writer roles in the UK &#8211; there were exactly zero results.
<img alt="" src="http://ift.tt/2pxieL1">
So chances are that your organization (or ‘company’ if you’re in the UK) hasn’t yet thought about hiring a UX Writer. Sure, you may have a team of UX Designers or Experience Developers, but how many of them are really into honing and crafting words. <a href="http://ift.tt/1t6nyWy">John Maeda</a> says in his “<a href="http://ift.tt/2mUc8pS">2017 Design in Tech Report</a>” that:
“A lot of times designers don’t know that words are important”
Now that’s maybe a little bit harsh. Most designers are massively overstretched and have to prioritize, and words just don’t come that high up the priority list. And this is what provides you with a massive opportunity.
<h4>The six degrees of UX writing</h4>
Before you get started, it’s worth evaluating what degree of UX writing your organization currently has. On the scale below then chances are that it’ll be somewhere between one and three. When you get involved you should target three and four as to where you can make a short-term noticeable impact. Your longer-term goal should be to reach five, with six as the holy grail.
<img alt="" src="http://ift.tt/2q0g9cW">
<h4>1. Identify your opportunities</h4>
When I joined Alfresco over 4 years ago, there was a small design team, working on multiple products. Their focus was on delivering great new products and features. Of course this is just the same in most other places, and changing a few words is rarely seen as a value add.
One of Alfresco’s products alone contained over 40,000 individual words. A lot of the copy had been written on the fly by developers and there were things that could definitely be changed to improve the user experience:
· There was no consistency
· There were typos
· Some of it didn’t really make sense
But there was no process for making changes and every day more words were being coded that didn’t have any science behind them. There was an open goal for someone to take ownership of the product copy.
<h4>2. Start small</h4>
The best way to show you can make a difference and grab attention is to attach yourself to a new project for a standalone feature or small product. It’s all about taking baby-steps, you can’t change everything immediately.
Chat with the Product Manager and/or UX Designer and offer to take a look at the copy in your own time. Propose to them that you can help to make a nicer product that’s more likely to be adopted. Show them a couple of examples of what you could improve. Give them some figures to show how words affect user adoption (for example, 80% of people prefer sentences written in clear English, <a href="http://ift.tt/1dD1B6R">Clarity is King</a>). It’s all about making a better product. Plus less work for them.
No-one’s going to say no to an offer like that right?
<h4>3. Short-cuts to validating your words</h4>
Most of the time our gut instinct on what reads better is usually correct. If your team are happy with your gut instinct then great, but wouldn’t it be even better to back yourself up with some real data as well? Prove that the words you use are going to improve the user experience.
At this stage you don’t have writing guidelines and you probably don’t have access to a user research team. Remember that this is a stealth start-up project you’re running here. Fast and light.
Fortunately, there’s a lot of people out there who’ve already done the research for you.
Chances are that your test project has design parallels with other products. So look at those products and see what words they use. Take a look at a few writing guidelines such as <a href="http://ift.tt/2hGkdIU">Google’s</a> and <a href="http://ift.tt/2pxaCIj">Apple’s</a> to back up your ideas. For each word choice that you make you want to justify why it’s an improvement. That can often be as simple as “this is what Google do”. Check out the <a href="http://ift.tt/2gQUMno">John Saito</a> article on how data informs UX writing at Dropbox — <a href="http://ift.tt/2hDD9vr">Designing words with data</a> for more on this.
Focus on consistency, clarity and simplicity. You can think about a more formalized tone and voice later.
<h4>4. Record everything!</h4>
A key mistake I made when I first started reviewing and writing copy was not keeping a record of what I’d done. The team I was working with knew I was involved, but you really need some metrics to show the value you’ve added.
To begin with this doesn’t need to be anything too fancy. Just keep a record of the number of lines of existing content that you’ve reviewed, the number of these that you’ve optimized, and the number of lines of new content you’ve created. And get before and after examples. Ideally for everything you change, but certainly get some of your best work for future reference. This serves two purposes:
<ol>
<li>For your company — showcase your value-add</li>
<li>For yourself — you’re building a portfolio as a UX Writer</li>
</ol>
<img alt="" src="http://ift.tt/2pxp8Q4">
If your team is testing with users before you launch then your validation will done for you. If not, then you can run simple A/B tests yourself comparing the original to your optimized version, using online tools such as <a href="https://validately.com/">Validately</a> (which has a free month trial option). Let’s be honest though, that sounds time consuming. So why not just test out your copy with coworkers, or even your family or friends.
<h4>5. Double down — users as advocates for change</h4>
Having started from an ad-hoc approach, you’ll hopefully have had a visible impact on product development. The products or features you’ve worked on will have clearer, more consistent copy, with a degree of user validation and competitor analysis. Your UX team and developers can appreciate the positive impact your involvement has, and you’ve recorded evidence of the improvements your brought.
Wouldn’t it be great if you also had users on side to support your efforts?
I had some ideas about how to improve our legacy product copy, but felt that to get real support I needed to prove that users felt the same way. So I set up a survey on SurveyMonkey and asked the team at Alfresco to share it with customers, partners, and users. The result was over 200 respondents, giving us lots of insight. The most important response was to the following statement:
My experience could be improved by changing the tone / terminology
<img alt="" src="http://ift.tt/2q0eX9p">
There were also well over 100 specific comments such as:
“too technical”
and
“say it like it is, don’t assume you’re dealing with an Alfresco expert”
If you don’t have the means to conduct your own survey then just share these results with your Product Management team. A massive 49% of our users were telling us that by focussing on UX writing we could improve their experience. That’s a pretty compelling case.
<h4>6. Formalize processes</h4>
You now have solid evidence behind you, and a body of work that demonstrates the impact you can have. Congratulations! You’ve made real and tangible progress towards making UX writing a thing in your org. This is where the real works starts…
a) Create guidelines
Before you begin to formalize processes you need to set a benchmark. The simplest way to do this is to have defined writing guidelines in place. You can either reuse existing ones such as Google’s, or create your own as we did at Alfresco — http://ift.tt/2pwVESN.
In defining your tone and voice there’s a huge amount of info out there, but most of the time finding a style equates to keeping things simple, clear, and non-offensive. There’s plenty of research, for example Microsoft’s presentations on “No more robot speak” (Doug Kim, 2014), showing that a clear majority of people (including developers and other “techies”) want the product voice to be clear, non-technical, and not to look like it’s trying too hard. So just focus on these three things:
1. Consistency — Create a pattern of usage to avoid ambiguity
2. Empathy — Understand your users situation and help them
3. Simplicity — “Simplicity is the ultimate sophistication”
When you’re done, share this in a public space and advertise the fact that it’s now available. If possible, get someone senior to endorse it as the new standard to work to.
b) Integrate writing into the design process
This is nominally straightforward, but depending on the size of your org or any internal resistance, may take some time to for a new process to become the norm.
If you have a UX team or product designers then you need to align with their workflow. My experience is based on working in an Agile environment where UX prototypes and flows are created for developers to work from. There are two key factors to instil in your team:
1. The UX team work with you to create any new copy. To begin with this will likely be that they design protocopy, then you discuss the design and user flow with them and optimize the copy. This is the 5th degree of UX writing — if you make it to here then your company is doing UX writing.
2. The developers DO NOT code anything until they know that it has your approval. This will be a gradual process and is about developing their trust. I’ve found though that most developers would always prefer to defer to the “authority” (remember those writing guidelines) rather than making up some words themselves.
<h3>Summary</h3>
As far back as 1985 the Apple human interface group recognized the importance of UX writing with their motto “<a href="http://ift.tt/2q0mYLI">A word is worth a thousand pictures</a>”.
30+ years later we’re starting to see this being realized in the role of UX Writer.
If your org currently settles for the 1st or 2nd degree of UX writing then they’re accepting the associated costs in user unhappiness. In today’s highly competitive markets, with everyone looking to disrupt each other, you have to be better than the competition.
You have the opportunity to make a difference. Now’s the time to make UX writing a thing in your org.
<iframe src="http://ift.tt/2iFGGW9" width="800" height="400" frameborder="0"><a href="http://ift.tt/2h0f00F">http://ift.tt/2h0f00F</a></iframe><img src="http://ift.tt/2pxfRHO" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2q0j7hE">How to make UX writing a thing in your org</a> was originally published in <a href="https://uxdesign.cc">uxdesign.cc</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to make UX writing a thing in your org

How to make UX writing a thing in your org

Top Stories