Your product doesn't need to leverage synergistic workflows.
It needs to make sense.

The Challenge

The core platform was built for full-time risk, compliance, and security professionals who used it daily and had been trained on it. A new product extension needed to serve a completely different audience: employees, vendors, and third parties who might log in once a quarter to complete a single task, with no time to spend learning the tool and no patience for complexity.

The content design challenge was making the product feel approachable and self-explanatory, without abandoning the professional tone the platform's enterprise customers expected.

My Approach

Plain language over industry jargon. Technical terms used elsewhere in the platform were replaced with everyday words non-expert users could act on immediately.

Warmer, but still professional. Contractions, shorter sentences, direct address, while staying appropriate for a workplace tool rather than a consumer app.

Guidance-forward. Since users were unfamiliar with the workflow, every screen had to answer "what is this?" before "what do I do?"

Documented and scalable. Voice and tone decisions were captured in a guide the product team could write against as the product expanded.

Where I Pushed Back

Product management proposed playful imagery, including illustrated animals in error states, to make the product feel friendlier. I pushed back: this was a workplace tool used for required compliance tasks, not a consumer app, and playful imagery in that context reads as undermining rather than charming. We landed on copy that was clear, reassuring, and focused on helping the user recover. Someone stuck on a required compliance task doesn't want to be charmed. They want to know what to do next.

Sample Copy

"You're all caught up. When someone sends you a request, it'll show up here."

"There are questions that still need answers before you can submit. Jump to incomplete questions."

"Request submitted. The team that sent this will be notified automatically — you're done."

Outcome

The product shipped and was adopted by enterprise clients, later expanding to additional use cases: a sign the content foundation held up under growth. Looking back, I'd push even harder for direct research with real end users rather than relying on internal assumptions about who they were. That's a good instinct to bring into any new project.

The Challenge

The product let risk managers replace subjective heatmaps with quantitative risk analysis, putting a dollar value on how often a risk event happens and what it costs when it does. The math underneath was complex: probability distributions, expected loss, conditional versus unconditional impact, built by a quant subject-matter expert with a math PhD.

The product's whole value proposition was making this approachable for risk managers who think in heatmaps, not statistics. If the UI read like an actuarial textbook, it would undermine that promise. The job was finding language that was technically defensible to the quant team and immediately usable to everyone else.

My Approach

Plain language first, precision preserved. Where the underlying concept was "expected number of risk occurrences based on all drivers in a certain time period," the UI asked: "How many times a year, on average, does this risk event occur?"

"Explain this" as a pressure release valve. Rather than over-explaining every field inline, ambiguous or technical fields got a contextual link, keeping the default experience clean for confident users, with support available for those who needed it.

One term, one meaning, across the product. Multiple terms were in circulation early on for the same concept (frequency vs. number of occurrences, economic vs. financial impact). I led a cross-functional terminology standardization effort with product, UX, and the quant SME to converge on single terms used consistently across the UI and documentation.

Working With a Technical Stakeholder

The quant SME's instinct was for precision: terms like "expected financial loss assuming risk occurs" are mathematically exact, but were a mouthful for a UI label and assumed statistical fluency most users didn't have. Rather than simply picking the friendlier option, I worked through each disputed term with the SME to confirm what the simplified version meant mathematically, asking directly: "Would you be thinking about expected loss if the risk didn't occur?" So plain-language labels and technical accuracy moved together instead of trading off against each other.

Sample Copy

"How many times a year, on average, does this risk event occur?"

"Actual Only / Inherent–Actual / Full Control Specification / Bowtie"

"Number of occurrences: 1.6 · Economic impact per occurrence: $49m · Annual economic impact: $78m"

Outcome

The terminology standardization work outlasted any single release, becoming the reference for how the team talked about the product across the UI and documentation, reducing the "which word do we use" debates that slow both content and development. Working closely with a subject-matter expert who thought in formulas reinforced a core principle: plain language and technical accuracy aren't in tension, they just require someone willing to sit in the gap between them and ask "what does this mean?" enough times.

Independent critique and rewrite for portfolio purposes, based on the publicly live sign-up flow at zoho.com/projects. Not affiliated with or commissioned by Zoho.

The Problem

Zoho Projects is a project management tool, part of Zoho's business software suite. Its sign-up form asks for a company name, a workspace URL, a business email, a password, and an optional phone number. Two of these fields create real friction: the workspace URL field has no visible label, just small gray text reading "https://projects.zoho.com/portal/" above an empty box, so it's unclear what belongs there. And the phone number is marked optional but comes with no stated reason for asking.

The rest of the form is standard and unremarkable, exactly what you'd expect from a sign-up form. The unlabeled URL field is the sharper problem of the two: a user who's never used Zoho has no way to know what they're supposed to type there, or what happens after they type it.

Current → Rewrite

Reasoning

The biggest issue here isn't tone or terminology, it's the missing label. Before proposing friendlier words, the more basic UX writing job is making sure a field is labeled at all. I don't know whether "portal" is Zoho's internal architecture term, whether the workspace name can be changed later, or why the phone number is requested. I've flagged each of those as open questions rather than assumptions. The work of UX writing isn't just finding the right words, it's knowing which questions need answers before those words can be right.