Web. Text. UX. App.

UX Writing Case Study (EN):
Project Management and Payment App

The Context

Handshake is a – fictional – project management and payment app for freelancers and their clients to manage projects, track hours and make/receive payments.

I was responsible for editing the in-app text in Figma and communicating possible design and functionality improvements within the user interface to the others on the team. My edits based on brand voice materials I produced throughout the course; the most relevant ones are included in this case study. On top, I implemented the suggested functionality changes in the mockups.

This case study illustrates my final project for the UX writing certification I earned through the UX Content Collective.

Project 

App design 

My role 

UX Writer, Content Designer 

Scope 

Review and rewrite the UI content for two types of users – freelancers and their clients – for an app built for iOS and Android operating systems 

Timeline 

Eight weeks 

Tools 

Figma, MS Word, pen and paper 

Bild: Übersicht der App, Design, Tech, Informationsarchitektur, Brand Voice, UX Writing

The Objective

My goals for the UX case study

My main goal was to show the process involved in shaping the language within the app to best meet the needs. The UX writer’s role is all about how to name things within a design system in a logical and strategic way. Though I’ve included several edited Figma mockups at the end of this page, a large part of my case study focuses on how I created style guidelines that – together with other product’s assets – can ideally serve as a single source of truth across the product team (and beyond). To achieve this, I aimed to:

  1. Critically survey the screens and assess how they might be easier for users to understand (from both a language and usability perspective)
  2. Communicate my thinking and design process
  3. Show (not tell) my ability to implement the above

Getting Started

The product design team I was collaborating with was working on revamping the prototype of the app, and rewriting the copy was part of this process. Here are the Figma mockups they shared with me (click the image to make it bigger):

Mockups

User flow overview

It’s important to figure out how the people we are designing for will make the best use of the mobile app. User flows provide a bird’s-eye view of the product – they help us walk in the shoes of our users and identify pain points and challenges. The designer’s draft was formatted in three basic sections – setup, onboarding, and ongoing use, with altogether five user flows:

  1. Login and first-time setup
  2. Onboarding (client)
  3. Onboarding (freelancer)
  4. Ongoing use and message centre (client)
  5. Ongoing use and message centre (freelancer)

Evaluating the given prototype

The evaluation of screens and interactions unveiled that the prototype lacked refinement both in terms of language and design. To fix language pain points, I did competitive research, analyzed the two user personas (section A below) and used brand materials I created throughout the course, including a glossary and style guide (section C below). To fix design flaws and add helpful functionality, I made suggestions on how to fix them, added screens and wrote on-screen notes to the product design team to share my reasoning.

A: Exploration

Understanding the app and the people who use it

Features

With this mobile app, people can:

  • Create and manage projects
  • Suggest budgets
  • Accept budgets
  • Send messages
  • Track hours
  • Send bills
  • Send payments

User personas

Everyone, say hi to Kelly and Tom. They are the user personas that will be helping with the rest of our journey. The UX research team provided persona worksheets (click the images to read all the details).

Primary persona: freelancer

Kelly is 24, a digital native web developer and new to the field of freelancing.

Goals: She’s learning how to run a business and would like to earn enough money to live well, pay off student loans and put money aside. She’s looking to use a modern platform to track the hours she works and bill clients.

Frustrations: Legal paperwork and tax forms scare her. Though she gets excellent feedback for her work, she worries her clients might not like what she creates yet also about not charging enough.

Secondary persona: client

Tom is a 52-year-old business owner, with years of experience under his belt. Tom has hired Kelly to redesign his website.

Goals: He needs an updated website so clients can find his business online and would like to engage with a platform that has robust options for keeping track of work progress without being technically overwhelming.

Frustrations: He’s a pro with everyday business procedures, but doesn’t enjoy bureaucratic tasks, let alone anything too technical.

B: Crafting Voice & Tone

“How do we sound?”

To connect with an audience, we need to first understand who they are. What do they like? What’s important to them? What kind of conversations are they having? What type of words are they using? What are they good at? What do they enjoy?

To develop a meaningful style, the first step was to accurately pick out the significant information from the data sheets provided by the UX research team and use this to tap into how our users Kelly and Tom might feel using the app. The emotional context helps make informed writing choices further along. Based on the given persona worksheets, here’s a range of emotions they may experience.

Kelly – the freelancer – may feel:

  • Excited about getting hired
  • Anxious to get a reply to the bid
  • Happy to be paid, to have the project appropriately tracked with software
  • Impatient because every moment spent on admin is time away from the creative work she enjoys
  • Empowered because the app makes tracking, invoicing and billing straight-forward

Tom – the client – may feel:

  • Uncertain this app will really solve business problems
  • Appreciative of it being easy to track status and communicate with freelancer
  • Appreciative of it being easy to pay when the job is done or at agreed-upon instalments
  • Intimidated by new technology
  • Empowered by the easy way to work together with freelancers

Next was to create voice attributes that answer the call to the user’s needs. The more specific the words, the easier it is to write consistent content. When we write copy:

  • We are cheerful, but not excitable. We are a welcoming place for all users, but never hyper.
  • We are smart, but not cocky. We know what we’re talking about, but we don’t use jargon to show off our smarts. 
  • We are trustworthy, but not boring. We are 100% transparent at all stages.
  • We are straightforward, but not brazen. We listen, empathise and say what needs to be said. No more, no less.
  • We are professional, but not stuffy. We allow the accurate and efficient completion of administrative tasks and payments.

C: Content Style Guide

Defining words and writing style

Bild: Brand Voice macht ein Produkt einzigartig

Good UX copy requires accurate use of terminology and is consistent. Decisions need to be made at the beginning of the design process about the voice, perspective, style, and strategy. That makes creating and maintaining writing guidelines that are in line with the brand a necessary evil.

  • “Is it contractor or freelancer?”
  • “Should the date be 23 June or June 23?”
  • “Do we write email or e‑mail?”

The voice brings content to life. Using a consistent voice reinforces the brand and simplifies a person’s interaction with the product. This in turn inspires loyalty and leads to trust.

Which terms should my team consistently use in the app and why? As a starting point, I brainstormed all the words that both freelancers and clients would use in order to find the common language from which to build the voice, tone and style guidelines.

  • Freelancer
    (not entrepreneur)
  • Client
    (not business owner, entrepreneur)

List of terms to use for the app (in alphabetical order)

  • Add. Enter. Use.
    We use simple, unambiguous, everyday verbs. This is to make usage of the app as frictionless as possible.
  • Automatic
    We are here to support the users and that means automating processes in the background, so they can focus on the work they enjoy. This is a selling point.
  • Budget
    Regular use will remind both the freelancer and the client that management and payment of money is a vital part of the project and partnership.
  • Effortless. Simple.
    The more matters that can be made into simple or effortless steps, the better. This is worth highlighting.
  • Flexible
    The appeal for both audiences is how much easier it makes their work. Flexibility is key.
  • Invoice
    More professional than “send me a bill”.
  • Payment
    Clients will see this in situations like “payment is due” and freelancers will see it in situations like “you have received payment…” This term clearly indicates what is required on both ends and is more specific than “cash sent” or “money sent”.
  • Project
    For either audience, jobs will be referred to as projects and tasks are a sub-category. The word project has creative connotations for the freelancer.
  • Track (time, project)
    Use this in reference to how a freelancer will document his or her work and how a client will be kept up to date. It’s a straightforward term everyone understands and is more specific than “logging”.
  • Work
    When we talk about what’s being produced by the freelancer, if specifics are unavailable, refer to it as their “work” and not “deliverables” or similar.

Which terms should not be used and why?

List of terms NOT to use for the app (in alphabetical order)

  • Deliverable.
    Avoid this kind of business jargon. If we can be specific, we are specific. Otherwise, just use the word “work”.
  • Monitor. Keep tabs.
    Specifically when talking to the client, our intention is not to help them micromanage, but simply to see how a project timeline is tracking.
  • Optimise productivity. Maximise productivity.
    It is up to the freelancer how productive or optimised they are. We are not here to push maximum efficiency. Our job is to facilitate their working style.
  • 1099, net 15, net 30, and other tax-specific terminology.
    We avoid (tax) jargon at all times.

We aim to maintain verbal and brand consistency between all products and outlets. When writing for the app, remember to keep language conversational. Keep things clear and simple, be direct but friendly. Some general tips (excerpt from style guide):

  • Stick to informal styles

  • Cut the fluff – be straightforward and natural

  • Speak directly to the user (use the second person “you”)

  • Use the present tense

  • Use the active voice

  • Use contractions (use common ones like “you’ll” and “you’re” but avoid rarer contractions such as “this’ll”)

  • Use gender-neutral language; use the singular “they”

  • Use terminology consistently (see glossary)

  • Prioritise clarity (brevity and grammar are important, but clarity is crucial)

  • Some interjections are nice, but don’t overdo it (!!!!)

At the core of the new brand voice here is human-centric language. My main goals were to use clear writing that would make it easy to use the app and to communicate my rationale to my team with sound reasoning and in a diplomatic way.

An important aspect in developing the brand voice was to shape it in such a way that it would speak to – and resonate with – both audiences. I also focused on easing the cognitive load that comes with payment and banking software, as this type of app often has a steep learning curve, which can be off-putting. It was critical to position the app as a simpler alternative for freelancers and their clients. Besides applying the brand voice, adding microcopy and tooltips came in handy for this.

Understanding the difference between voice and tone

We have one brand voice, but our tone changes, depending on to whom and what we’re communicating. For example, we use one tone when celebrating an accomplishment, and a different one when warning about a violation.

Bild: Ton variert, je nach Kontext
Tone spectrum – from fun to serious and everything in between

D: Bringing to Life

Applying brand voice to product materials

To get familiar with the voice attributes, I created a series of sample headlines and body sentence pairs for the onboarding screens. They needed to be of a certain length*, speak to both audiences and describe shared benefits.

  • Easy as a handshake
    We handle billing, so you can handle your business.
  • Save time and money
    Spend it doing what you love.
  • Convenient payments
    Online billing at your fingertips.
  • App-managed projects
    A modern solution for modern business owners.
  • Avoid the hassle
    Handshake means peace of mind payments.

* Headlines: 20 characters max., no period; body text: 40 characters max., with period

To get familiar with flexing the tone of the voice, I wrote two emails. One for people who just signed up, and one for users who just cancelled their account.

Headline: Thanks for choosing Handshake!

Body text: Hi [first_name],

You’re one click away from effortless project management, time tracking and invoicing.

Handshake is all about the personal touch. That means real support, always. Visit support.handshake.com for FAQs and to lodge a help request.

CTA: Get started

Headline: You’re moving on

Body text: Hi [first_name],

This is to let you know we’ve cancelled your Handshake account.

Thanks for working with us – we loved getting you paid faster. If you need us again, we’re one click away.

CTA: Reactivate Handshake

The Solution: Rewrites

Applying brand voice to UX copy in mockups

For the sake of brevity, I’m showcasing the Figma prototype series for the login and first-time setup screens only, without the notes to the team. I chose this user flow because it’s an important – if not the most critical – phase in any app user’s journey. The more pleasant the onboarding experience is, the more likely a person is to come back and use the app. To achieve this, I focussed on three objectives:

  • Help the user to register
  • Educate the user about the benefits and functions of the app
  • Gather profile information that can be used to present customised content and notifications

Login and first-time setup (before)

(click the image to make it bigger)

Login and first-time setup (after)

(click the image to make it bigger)

10 UX issues that called for improvement

Rewriting the login and first-time setup screens, there were many issues that needed attention. Here are the ten most important areas I focussed on:

  1. Declutter, get rid of all text that is too wordy and use visual weight to convey importance – simplify without losing significance
  2. Create new text to welcome the user with a brief explanation of the product and its uses
  3. Employ all caps for buttons (max. three words, always), remove drop shadow and use clear action verbs
  4. Add buttons, especially “back” buttons, as these put users in control
  5. Improve usability by separating login (returning users) and first-time setup (new users)
  6. Add labels and field text to all empty states of fields to take the guesswork out of filling them in
  7. Improve readability of text for password choice – easier to read and to the point
  8. Add “take tour” to help first-time users (with link to onboarding materials such as videos or documentation)
  9. Add legal text and check box (this text needs a heads-up from legal experts before deployment)
  10. Add dynamic text (customised to each user’s name) to add a personal touch that fosters trust with the user

The new welcome screen now explains the value of using the mobile app and how it will positively impact users’ lives. Separate sections for new and returning users are more clearly laid out with consistent CTAs. Upon successfully completing account setup, newcomers are now directed towards onboarding materials. This bit of extra guidance goes a long way towards reducing churn, ensuring that users actually complete the process of creating their first project. And finally, adding dynamic text – customised to each user’s name and their project overview – adds a personal touch, fosters trust with the user and serves as a home base that makes the app easier to use.

Wrap Up

Lessons learned

  1. Effective UX copy is human-centric and requires an understanding of the brand, its users, and their needs, goals, and motivations. 
  2. Writing for user experience is a collaborative process involving multiple stakeholders. Researchers, designers, and writers all stand to gain from sharing their insights and expertise.
  3. UX writing is a fundamental part of the design process. When evaluating the efficacy of a particular design, product, or service, proper UI text is critical to things like usability testing. Placeholder text only leads to confusion and frustration on the part of those using the product.
  4. The importance of workplace communication. Since this was for a certification course and not a real company, resources for user research and testing were limited. The project was conducted independently, leaving scope for team collaboration.

Celebrating Accomplishments​

Discovering Figma was a game-changer for me. What distinguishes Figma from other design tools is its collaboration feature that makes it simple to bring content designers like me and other stakeholders together onto the same page. Mastering the new technology forced me to look at every item on every screen and see what needed fixing and learn how to get it done. It was my first project using Figma and digging into the tech made me aware of just how powerful it is and that it’s a ton of fun to use.

The UX Content Collective deemed my high-fidelity mockups “ready to launch” and “outstanding”. I achieved a grade of 115% on the final project and earned specific shout-outs for my attention to detail, thought-process communication and usability improvements.

What’s Next?

With the positive feedback, the next step is to make the app really pop visually and then do usability testing. We need to get our app in front of users to uncover pain points that may still remain hidden. Then, following mood board inspiration, an interactive hi-fidelity prototype could be built that takes the results of usability testing into account and strengthens the design.