top of page

THE HANDSHAKE APP

Course: UX Writers Collective

UXWC Handshake App: Text

The Situation

The UX Writers Collective course focused on the product launch of the (fictional) Handshake app. As a part of its launch, I created voice and tone guidance along with language specific to the two unique personas. The final project in the certification included editing the copy within the mockups of the mobile app.

UXWC Handshake App: Text

The Task

The Handshake app is intended to help employers and contractors work together to complete projects. The flow I was given included sign-up, onboarding, ongoing use, and messaging screens for both audiences.

UXWC Handshake App: Text

The Activity

I reviewed the mockups and updated the UI text for the Handshake app. I did end up bringing a product designer on board to help improve the small layout changes I had made in Figma. Lastly, I added questions and comments where I thought further context or discussion was needed.

UXWC Handshake App: Text

The Results

After completing this assignment and the final exam, I received a certificate in UX writing from the UX Writers Collective.


Please review my mockups below.

UXWC Handshake App: Text

BEFORE & AFTER MOCKUPS

UXWC Handshake App: Text

SIGN-UP SCREEN

Before

UXWC Handshake App: Text
Screen%20Shot%202020-09-20%20at%201.19_edited.jpg
UXWC Handshake App: Welcome


After

UXWC Handshake App: Text
After – Sign Up
UXWC Handshake App: Welcome

I cleaned up the copy and refined the help text. I replaced the original terminology with the terms I had added to the style guide (which I completed earlier in the course). Originally, I had included a bit more help text within this flow, but after collaborating with the product designer we decided less would be more—and future user research would help us decide if it should be added back in.

UXWC Handshake App: Text

OWNER SETUP

Before

UXWC Handshake App: Text
Before – Project Owner Onboarding
UXWC Handshake App: Welcome


After

UXWC Handshake App: Text
After – Project Owner Onboarding
UXWC Handshake App: Welcome

In addition to copy changes, I recommended adding “skip this step for now” as the user may not have all of the details necessary to complete the flow. For example, the user may need to verify their collaborator’s email address before adding it to the system. Forcing users to complete these steps solely on our timetable may cause undue stress.

UXWC Handshake App: Text

CONTRACTOR SETUP

Before

UXWC Handshake App: Text
Before – Contractor Onboarding
UXWC Handshake App: Welcome


After

UXWC Handshake App: Text
After – Contractor Onboarding
UXWC Handshake App: Welcome

I duplicated many of the changes I made to the project owner's flow. In doing so, it became pretty obvious that having the two flows be so similar is likely going to create a problem. What happens if a project owner and a contractor want to use different payment methods? In a future iteration, we'll need to address this scenario or dramatically change one flow.

UXWC Handshake App: Text

SETUP CONFIRMATION

Before

UXWC Handshake App: Text
Before – Setup Confirmation
UXWC Handshake App: Welcome


After

UXWC Handshake App: Text
After – Setup Confirmation
UXWC Handshake App: Welcome

It's important to note that if we follow my recommendation and don't make the invitation and payment setup mandatory, this header should instead read “Project details saved” or something similar. We don't want to confirm an action the user didn’t actually take.

UXWC Handshake App: Text

OWNER ONGOING USE

Before

UXWC Handshake App: Text
Before – Project Owner Ongoing Use
UXWC Handshake App: Welcome


After

UXWC Handshake App: Text
After – Project Owner Ongoing Use (1)
UXWC Handshake App: Welcome
After – Project Owner Ongoing Use (2)
UXWC Handshake App: Welcome

I moved around the content so that overview content goes on the overview page, time content goes on the tracking page, and payment content goes on the payments page. To do so, I had to reorganize the fields and proposed a new layout.

I also recommend we do not pre-select “project approved” until the user has selected it themselves. It should remain unchecked until that time.

Moving forward, we'll need to determine which fields are editable and which are not. For example, the project description should likely not be editable by the freelancer. If both personas can edit all of the copy, they'll likely miscommunicate. On that note, if the contractor wants to dispute information the project owner has entered, how should that happen? Within this screen or within the messaging platform? Further context will be required for the next iteration of these screens.

Lastly, I need more context on whether or not the project owner will want to approve the recorded hours as well as the invoice amounts. In that case, we'll need to add that functionality and work on the language. Further user research is required.

UXWC Handshake App: Text

CONTRACTOR ONGOING USER

Before

UXWC Handshake App: Text
Before – Contractor Ongoing Use
UXWC Handshake App: Welcome


After

UXWC Handshake App: Text
After – Contractor Ongoing Use (1)
UXWC Handshake App: Welcome
After – Contractor Ongoing Use (2)
UXWC Handshake App: Welcome

I duplicated many of the same changes here that I had made to the project owner's screens. Here again, it is highlighted that the project owner and contractor should likely not have edit access to all the same fields.


Moving forward, I need more information on the tracking functionality. For example: can we add a drop-down for the manual tracking? In the next iteration of this flow, I'd like to test different methods for time tracking.

UXWC Handshake App: Text

MESSAGING

Before

UXWC Handshake App: Text
Before - Messaging
UXWC Handshake App: Welcome


After

UXWC Handshake App: Text
After - Messaging
UXWC Handshake App: Welcome

The original layout was unclear and I was not able to get clarity from its designer. That said, it seemed like we were trying to recreate how messaging is typically done. I’d instead recommend we keep the layout more similar to other platforms—to avoid increasing a user's cognitive load. To do so, I created content that is closer to what is used on other popular messaging platforms. 


I'd also recommend we use visual elements (like bolding the text) to make it clear which messages are unread. In the same way, I think we can trust our users to know clicking on the message will open it—instead of needing specific “open message” buttons. If users do have trouble, we can add help text. Testing the prototype with our users should help us determine which direction we move.


Moving forward, I have several questions including: Can the same contractor and project owner have more than one message thread open between them? Should users be able to close messages permanently? The answers to these questions should have a major impact on the next design iteration.

UXWC Handshake App: Text
UXWC Handshake App: Text
bottom of page