UX Design · Product · AI · 8 Years
"Make the problem simple, then solve the simple problem."
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 a federal contractor and a public university. Most recently: rewriting error messages and account flows, shaping the product decisions behind them, and figuring out where AI actually earns its place in that work, and where it doesn't.
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 federal and higher-ed products, the work I lead with.
Federal concept dashboards designed
Employees reached through AI training
Pages redesigned at UNG
Engagement increase
Two engagements, and the plain-language problem each one actually was.
Federal
Federal agencies won't sign a contract on a promise. Agile Defense proves the idea first, building working concept prototypes clients can react to before a line of code gets written. I've designed four of those prototypes, run a design team, and now build the training teaching 1,500 employees to use AI the same deliberate way.
Result: 4 federal concept dashboards designed, AI training reaching 1,500 employees company-wide.
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.