UX

 

UX

Good UX writing presents the main ideas first, then breaks down the rest into easily digestible user-friendly pieces, always respectful of the user. It tells people what they need to know, paying attention to context, intent and emotion. It is clear, concise, empathetic, useful and organised. It should delight the user.

As a UX writer, every word you write needs to mean something. The ultimate goal with the Asana Help Guide articles was to:

 
 
 

Navigate through my work

 
 

Style guide

I wrote a style specifically for the Help Guide at Asana - Branding style guides don’t typically encompass design standards for content that's instructional in nature so I was contracted to create one - I wrote a set of standards for the writing and formatting combined with the design elements that all writers could refer to - a living breathing ever evolving doc and one source of truth for onboarding writers.

 
 
 

Excerpt from the style guide:

How to give instructions:

Provide step by step sequences in the correct order

  • Follow the timing and sequencing of the actual operation. Walk in users shoes

  • Provide visual stepping stones with screenshots and gifs or screengrabs

  • Use short snappy paragraphs with headlines - break down complicated concepts and make them relatable and easy to follow. Use a sequential flow

  • Explain what the function or feature is - how this impacts Asana users and operational context

  • Check that the instructions match the actual product. Keep the user at the core of everything

  • Test the instructions alongside the product - go into the test site and match. Cross-check

  • Write in the present tense but not the active voice *(see below)

  • Add tips - if you have some nugget of knowledge that might help the user please add (ensure it is 100 % accurate by reaching out to the PM to cross-check)

  • Promote the next steps, think what the user wants before even he/she knows he/she wants it. Use microcopy to gain trust. Signpost the user to better product adoption. Every piece of content matters!

  • Write the steps to end-to-end task completion, while using Asana. Refine and polish.

  • End with a call to action to read a related article to help customers get more from your article

  • Peer review

  • Publish

    Screenshots:

    • Add callouts in screenshots to highlight important information

    • Numbered step-by-step to match corresponding copy - see https://asana.com/guide/help/premium/billing

    • Only include people in screenshots who have @apolloenterprises.org email addresses (use test site)

    Complete the follow checks:

    1. Is it easy to work through the task from start to finish     

    2. Has the PM told you where in the Guide he/she would like it to be added? If not reach out. We encourage collaboration at Asana

    3. Can you randomly jump into a guide and just as easily understand the process?

    4. Has it been peer reviewed? -  new guide articles (particularly critical launches for new features)  need to be evaluated by another content writer for discrepancies, typos, grammatical errors and flow.

    *  Technical user documentation, unlike some other forms of writing, speaks to the reader in the present tense -  he/she has a problem to solve and he/she consults the Help Guide to find out what to do. Help content  is usually imperative ("do this"), and trying to combine the imperative mode with past tense can get confusing. You will still use "past-tense" phrases like "after you have done X", or "if you have previously done Y", but the main thread of your content will make the most sense to readers in an imperative/present style. 

How we write the Guide

Section 3: Style and Tone

Our voice speaks to our audience in a friendly but direct way.  Do not assume the user has extensive product knowledge. Our users are pressed for time and refer to the guide to unblock problems so our tone is concise -  no verbose, it is writing with intent, purposeful and clear. Brevity is clarity.

A persona, and how that informs tone and writing style, should always be included when kicking off a new content writer position in UO. 

Customer Needs & Pain Points

  • As a team lead in the process of creating my organization’s Asana, I want clear guidance on how to move my workflow into Asana, so that I can quickly get set up and onboard my team

  • As an individual contributor who just got invited to my team’s Asana, I want to quickly learn how to do [work out a feature] so that I can fulfill my team lead’s request and get on with my work.

  • As an individual contributor who went through onboarding and knows a particular feature exists but can’t remember how to do it, I want to quickly jog my memory so that I can get on with my work.

  • As a returning user who visits Asana infrequently, I want to learn what new features or improvements have been released since I last visited.

  • As a premium user who has a question, I expect to get customer support quickly.

  • As a developer/engineer the ease at which I can configure the API Asana integration is important so I can manage workflow more efficiently to amplify my business insights.

For the purposes of accessing the Asana Help Guide customer pain points are diverse and varied. The objective - solve the issue, address the steps and unblock quickly.

One goal - solve my problem and make it easy for me to get to the answer.


 

 Personas