THE HANDSHAKE APP
Course: UX Writers Collective
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.
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.
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.
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.
BEFORE & AFTER MOCKUPS
SIGN-UP SCREEN
Before
After
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.
OWNER SETUP
Before
After
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.
CONTRACTOR SETUP
Before
After
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.
SETUP CONFIRMATION
Before
After
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.
OWNER ONGOING USE
Before
After
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.
CONTRACTOR ONGOING USER
Before
After
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.
MESSAGING
Before