UX Content Designer · 8 Years
Jargon in. Clarity out.
I take dense legal, clinical, and technical language and turn it into something a person can act on in five seconds instead of re-reading three times.
I'm Tyler. Eight years doing this for hospitals, a federal contractor, and a public university. Most recently: rewriting error messages and account flows so people stop calling support to ask what a sentence meant.
Before: Legal Draft
"Failure to submit required documentation within the specified timeframe may result in delay or denial of the requested action."
After: What Shipped
"Submit your documents by March 3, or we can't process your request."
Across three engagements, in federal, healthcare, and higher-ed products.
Initiatives delivered
Stakeholder satisfaction
Pages shipped weekly
Engagement increase
Three engagements, and the plain-language problem each one actually was.
Federal
Federal content has to satisfy accessibility law, legal review, and an actual human reading it, usually in that order of who complains loudest. I built the content audits, voice and tone standards, and style guide that got all three to agree.
Result: 40+ initiatives delivered on time, 90% stakeholder satisfaction.
Read the case study →Healthcare
Patients hit a scheduling flow that technically worked, the way a filing cabinet works if you already know which drawer. I rewrote the patient-facing content into new templates and design-system components across the system-wide redesign.
Result: 50+ content pages shipped weekly, revision cycles cut to under 10 minutes a page.
Read the case study →Higher Ed
A public university site grows one department at a time, for twenty years, and nobody's responsible for the whole thing. Mine had 20-plus navigation menus. I decided what stayed, what merged, and what finally got cut.
Result: 35% increase in engagement across a 5,000+ page site.
Read the case study →Three steps, repeated on every engagement regardless of industry.
01
Read what's already live and flag what's unclear, redundant, or failing an accessibility check before writing anything new.
02
Write the plain-language version first. Then fold back in the legal, brand, or technical requirements without losing the clarity.
03
Test it with the people who'll actually push back (legal, dev, a real user) and hold the line through revisions.