Handshake App – Content strategy & UX writing
A complete UX writing project for the UX Content Collective certification
Overview
Handshake is a fictional app for freelancers and business owners. It has some essential features of invoicing and project management tools like Wave, Indy, or Hiveage: freelancers can track their hours and send invoices, and business owners can send them payments and check progress.
I got involved with the project after the design team had already drafted some mockups. The app needed to get ready for a design review with the Head of User Experience and the VP of Product, so my task was to review and edit all the UI text.
My role: Content strategist, UX writer
Duration: 8 weeks
Tools: Google Workspace, Miro, and Figma
Laying the groundwork for (re)designing
Digging deeper into the user personas & mapping the user journey
Researching competitors, interviewing stakeholders & finding our own TOV
Keeping an eye on localization
Writing CX content: onboarding screens and transactional emails
UI text redesign & suggestions
On-going use for business owners: making payments
On-going use for both users: messaging
Writing with limited resources
The importance of getting feedback – from users, and mentors
Challenges & constraints
Avoiding big design changes
The mockups presented massive design flaws – still, my job was not to redesign the whole experience but to develop solutions that would get the product ready for users. I could make minor design changes, but I had to keep the basic screens and flows intact.
Working solo, as a team
I didn't have access to other stakeholders who could have clarified the app's business goals, design choices, or technical specs. Most were unclear or just drafted. I had to make some suppositions, and prepare questions for the design team and the product manager so that I could fix the copy for the following hypothetical iteration.
Finding a common voice
As mentioned, the app users are two (freelancers and business owners). I had to find the right tone of voice (TOV) that could simultaneously speak to both, not alienating either user during shared screens and flows.
Laying the groundwork for (re)designing
Before getting my hands dirty with the mockups, I had to lay the foundations of my redesign.
The product was born without a content strategy, so I had to define the tone of voice from scratch and prepare an essential style guide.
Digging deeper into the user personas & mapping the user journey
One of the most fun moments was mapping the user journeys – I dissected the entire service period for both users and looked at how they might feel in each phase to draft with Miro an empathy map. Besides the interviews, industry reports and benchmarks (like Mailchimp&co's) offered many valuable insights.
One interesting datum that emerged was that the generational gap between freelancers and business owners was actually not so steep as the user personas created by the Research team seemed to suggest: the average age for freelancers is 40 years old (slide 70), while for business owners, is 50 years old (p.6).
Researching competitors, interviewing stakeholders & finding our own TOV
While researching, I familiarized myself with the industry and the competitors' apps. This allowed me to better empathize with our users, see how we could potentially stand out from competitors, and track the jargon used in the field. We could not afford to run more testing with users, but many words and idioms related to invoices seemed potentially obscure (1099 worker) or overly technical/verbose. I also brainstormed with a few colleagues and managers from other departments: How would we describe our brand at present? What's our mission, how do we want people to remember us?
Our voice influenced (and was influenced by) a few preferred words that I listed in our style guide to promote consistency.
I then noted down a few style rules to follow throughout the app interface. This would help us not only with consistency and usability but also to speed up the creation process for future copy.
Keeping an eye out for localization
Handshake's market geographics seemed to be limited to the USA. Still, as a non-native English speaker that worked for years in localization, I always look at the potential outside the original market/language. For this reason, I preferred a currency and date format that could ease localization in the future.
Writing CX content: onboarding screens and transactional emails
For onboarding screens, I selected the main features that appeared in both users' flows and highlighted the common benefits:
Now for one of my pet peeves: sorely neglected transactional emails. The company had already set up its automation using pre-designed templates, but since transactional emails are by far the most opened by users, I suggested some alternatives:
Sign-up: I gave users a short tour to keep them engaged and showcase how easy it is to create a project.
Cancellation: I wanted to assure users they completed the cancellation, keep positive, gather feedback and let them know they could always be back.
UI text redesign & suggestions
Now, back to the mockups.
Below are some of the screens with the main changes I made (besides the general work on spellcheck, consistency, and style), and why.
Sign-in & sign-up
Main changes:
-
Pointed out the benefits for users to log in and sign up to increase user retention.
-
Placed the labels above the fields for accessibility and to make them visible even when users clicks in.
-
Added hints as placeholder texts. With the current user flow, it's essential to specify that new users need to create a password – otherwise, they might be confused about which password they should type in that field.
-
Edited the confirmation message to guide new users to create a project, to prevent First-Time Use (FTU) friction.
Additional suggestions:
-
Separating the sign-in and sign-up screens. This way, we could add some missing information to the sign-up screen without overloading (like name and surname, double password check, terms, privacy links, etc.).
Project set-up
Main changes:
-
Divided the set-up into five steps and clearly marked progression to reduce FTU friction (ex: 1 of 5).
-
Used headings and subheadings to clarify what users need to do at each stage.
-
Included examples as hint text to guide users without adding explicit instructions.
-
Mentioned that the user can update the description later, to reduce the potential friction point of fully describing the project during the initial set-up (and analysis paralysis).
-
Picked one word to identify both users in the relationship with each other (partner) to emphasize the collaborative nature of the app. This will require further testing.
Additional suggestions:
-
Adding icons/logos for each payment method to make them recognizable at a glance.
-
Since adding payment details might require extra time and effort for the user, I suggest giving the option of skipping this step during project set-up (Skip for now).
-
Using a radio button instead of a standard checkbox when selecting a payment method.
-
In the Invite a partner screen, including a message field so users can add a message to the invitation if needed: Add a message (optional). We could also have the additional option for the users to invite themselves a partner: Get a sharable link instead
On-going use for business owners: making payments
Main changes:
-
Changed the color of the Pay buttons for consistency with their function.
-
Rewrote the confirmation message as a question to catch users' attention and added helpful information (the payment recipient and amount).
Additional suggestions:
-
Adding due date information, ex: Week 1 (due Oct 20, 2019)
-
Adding a reminder on the payment method: We'll send 1200,00 USD to Kelly Stephanie Chan. Your PayPal account will be charged. Change payment method.
On-going use for both users: messaging
Main changes:
-
On these two screens, more than adding/editing text, I deleted some unnecessary microcopy and relied on graphic elements that conventionally convey meaning.
Additional suggestions:
-
Having a separate section in the menu just for the messages, instead of a button placed under Project or Payments. Also, to mimic a conversation, we could have all messages to/from the same user group under the user name. Ideally, in the same conversation, we could also show notifications of actions such as Tom approved your proposal or Kelly sent you a payment request of 1200,00 USD for Week 3.
Takeaways
Here is where I would collect results, lay out data on conversion and drop-off rates, and give a preview of the next steps – but since it was a fictional project, just some personal takeaways.
Nice meeting you, Figma
This was my first close encounter with Figma – which, in recent years, became the industry standard for UX/UI design. I'm happy I had the chance to get the hang of it, and not just because I could add another software to my toolkit. Shifting from an online word processor to a design tool came with the full realization that UX writing is not just writing microcopy, but it's a way of using words (or the lack thereof) to design a better user experience. On many occasions during this project, I didn't have to write new copy but to delete, move, and cut what was already there. To ease friction, adding copy might work well at times, but it can also be a cheap, ineffective way out if content and design don't work in synergy.
Writing with limited resources
It would be great always to have every user data we need to write the best (micro)copy. It would be great to always sit at the table with designers from the beginning, have unlimited time, and be surrounded by a vast, supportive team. But it's not always the case – maybe it's rarely the case. Working with tight constraints and resources might not have been ideal for crafting a complete, great-looking study case, but it was a healthy exercise to make the best of what I had and work efficiently.
The importance of getting feedback – from users, and mentors
Testing is one of the best tools to ensure that our copy doesn't just sound nice but performs well. I can list at least a dozen choices I took during this project that I strongly feel I would need to test with users, pre or post-launch – and it's a very conservative estimate. The lack of testing, though, was made up by weekly feedback on my work from the UXCC mentors. It was great to have an expert opinion on my choices. I got a 20 out of 20 on this project, but what stood out the most for me was the encouragement of my reviewer to don't be afraid to have more fun with messaging. It's not easy to play with words with confidence in a language that is not your mother tongue, but since then, I've been practicing to master adding personality to my microcopy – in whatever language I write.