Scope
Journey mapping, information architecture, UX writing
My Role
UX Writer / Content Designer responsible for:
Rewriting flows to improve clarity and usability
Applying the JobPay style guide across flows
Writing CTAs, helper text, labels, and transactional messaging
Identifying usability risks and advocating for content improvements
Problem
For the fictional app JobPay app (UXCC Fundamentals Course), these 3 sets of product flows were mapped out, but copy was grammatically incorrect and the voice was inconsistent. The ‘design team’ flagged that the experience was confusing, and I needed to get the product user-ready without redesigning the flows.
Solution
Create a new style guide with UX principles for the JobPay app
Apply the style guide to the flows in preparation for a design review with the Head of UX and VP of Product
Constraints
UI layout and flows were already set. I could make copy changes only
No access to users or live usability testing
Fixed business terminology (“Freelancers” and “Business Owners”)
No opportunity to validate changes with real product metrics
The flows to review were:
Onboarding for both users
Flows for freelancers
Flows for business owners
Challenge - tone that didn’t match the context
Onboarding screens used overly promotional language, which didn’t match user intent.
I referred to the style guide. Using a verb-first content pattern, I focussed on selling JobPay’s benefits, removing excessive adjectives, and focussing on clarity over brand voice.
Challenge - Contextualising guidelines in the UI content
A business constraint was that primary users were called Freelancers and secondary users were Business Owners. During onboarding, I identified a potential pain point when users select their profile type.
Freelancers are also business owners, technically - how could we avoid ambiguity / confusion during onboarding?
How could we confirm that Business Owners were in fact, clients of Freelancers?
I thought primary users “Freelancers” were more likely to call their clients, “Clients”. In real life, we’d have been able to test a few different terms (Business Owners vs Clients, Invoices vs Timesheets etc). But in lieu of testing, I had to work with the constraints I was given.
Solution
I considered introducing Clients to the platform as Clients, who would become Business Owners once they accepted a project from a Freelancer. I asked the “Product Owner” about this change of term mid-way through onboarding and received pushback. She confirmed that a sudden change in terms would ignore the business constraint and increase cognitive load on the user. I could have made a strong justification for it in the style guide, but it would have conflicted with my own ‘consistency’ rules.
Solution:
I maintained consistency with Business Owners and Freelancers throughout
Introduced supporting microcopy (tooltips, helper text) to help clarify what each role means to the user during onboarding.
I left comments for the product team as my job wasn’t just to edit, it was to advocate for usability.
Flows for Freelancers
I added form labels to all fields and helper text to provide guidance, context and constraints. I used sentence case for scannability.
Challenge - Clarifying how payments work
There was a confusing explanation of the 1% service fee. I re-wrote these flows so Business Owners understood that they pay the invoice total, while Freelancers cover the 1% fee. That distinction needed to feel transparent and upfront.
Solution
Where necessary, I:
Rewrote vague CTAs like “Continue” to be more specific (e.g. “Review and Pay”)
Simplified headings so each screen had one clear purpose
Added verb-led buttons
Flagged confusing flows in comments rather than redesigning them
Challenge - Working through ambiguity
Because this was a fictional scenario I couldn’t attend real stakeholder meetings or carry out . In a real-world setting, comments might become larger conversations in a Product team, and we’d be able to test multiple iterations.
My internal testing
With user profiles but no access to users, I pressure-tested flows myself:
Reading screens aloud for awkward phrasing
Scanning for hierarchy — what draws the eye first?
Checking consistency of terminology
Ensuring each screen has one primary action
Checking formatting against the style guide
It’s not formal usability testing, but it’s a strong sense-check before the ‘stakeholder review’.
Results
This was a pre-review iteration, so no live metrics yet. But the updated UI was much improved. It:
Reads consistently across all three user flows
Reduces ambiguity in financial flows
Removes friction in onboarding
Keeps voice consistent, trustworthy and professional
What would validate these iterations:
Direct user research
Validation beyond internal teams
If implemented and validated, I would expect improvements in:
Onboarding completion
Invoice payment completion rates
Reduced support queries about fees or overdue invoices
Increased user trust in financial interactions
What I learned
This project reinforced that:
A style guide is more than documentation. It’s a decision-making tool that should be updated as business needs change
Clarity is more important than personality in high-stakes flows such as payments
Small copy changes can significantly improve perceived usability
It is possible to improve UI without redesigning it
Good UX writing is collaborative, it’s asking questions as well as writing text