"A working notebook." —
Open something. Press 1–5, or click.
Section I
Essays, working notes, and marginalia. Most of these started as journal entries that wanted to be something more careful.
Writing — essay 01 of 03
Most software treats words as the last step. Layouts get drafted, components get built, flows get wired up — and then someone is asked to write the copy. By that point the structure is set: what the product is allowed to say has already been decided. The writer fills in the placeholder.
This is 's familiar problem. The deeper one is that words have a structure of their own that nobody is designing. A exists. A exists. Names cluster. Patterns accrete. They are usually invisible because they grew up unattended — the result of a hundred small decisions made by people who didn't think of themselves as making decisions.
is the work of naming what is already there and making it intentional. It is not writing. It is not voice. It is closer to information architecture, but where IA orders the boxes, content architecture orders what the boxes are allowed to say — the shape of the message, the rules of escalation, the dependencies between one screen's language and another's.
The test of a content system isn't whether the prose is good. It is whether the next writer can sit down and ship without you in the room. If the patterns hold, the system survives; if they don't, every screen becomes a one‑off, and the next person inherits a folder of decisions they cannot trace.
Most of what I do for a living is this — the structural editing of product language, before the language gets written. The work is invisible if it works and embarrassingly visible if it doesn't. Nobody notices the framework that keeps the alerts consistent across a vehicle OS; everyone notices the screen where the tone is wrong.
I keep coming back to this work because the systems that survive their author are the only ones that ever scale. Most software doesn't get this kind of attention until late, if at all — and by then there is no architecture to design, only the patterns that grew without one.
Writing — essay 03 of 03
"Care" is one of those words people use in design talks the way "elegant" gets used in code reviews. It usually means I approve of this. As a constraint it is harder to operationalize.
My working definition is this: care is the shape a piece of work takes when you are responsible for whoever uses it, especially the ones who didn't ask to. In a healthcare app, care means writing for a patient on her worst day, not her average one. The words have to hold up at 2am, scared, alone, in a language she may not speak natively, on a device whose screen is too bright. Most product writing isn't subjected to that test.
In safety‑critical environments — alerts, notifications, the sort of work I did at GM — care becomes more literal. The questions are about agency and attention. Who decides what reaches the driver? What is the cost of being wrong about that? , in that context, isn't a feeling. It is a discipline of restraint.
I think a lot of the "designing with care" rhetoric obscures what care actually requires of the people doing it. It requires saying less. It requires letting the system not speak when it could. It requires deciding which thousand things will not be added, because each of them would cost someone an ounce of attention they cannot afford. Care is mostly a no. The yeses sit in the margins around it.
The I have built that I am proudest of are the ones that disappeared into the work — where nothing about the architecture announced itself. The product just did the right thing and got out of the way. Care, in those cases, was the thing that allowed restraint: the discipline of putting the right amount of language in front of someone, and no more.
When I say I work with care, I do not mean I have warm feelings about your users. I mean I am willing to say no to the things that would crowd them. That is the only version of care I trust.
Writing — essay 02 of 03
I was hired at GM to figure out when the system should speak. I left with a different question.
The original brief was a content problem. The alerts and notifications across the vehicle, the mobile app, and the connected services were inconsistent. Teams were making per‑case decisions about what to say, when to interrupt a driver, what the AI assistant could initiate on its own. Most of those decisions were defensible in isolation. None of them held together as a system.
The intuitive move was to write a content style guide. Voice patterns. Tone modes. Severity buckets. What I started writing kept failing me. The problem wasn't how to say things. The problem was when the system was allowed to speak at all.
That's an agency question. Who decides what reaches the driver — the OS, the application layer, a third‑party developer, the AI? A driver who is interrupted while doing something safety‑critical is being told, implicitly, that their attention is owed to whoever pushed the interruption. That is a moral claim disguised as a content decision.
So the I ended up with isn't really about content. It's about who gets to take a driver's attention and on what terms. The five tiers describe a hierarchy of permission. The least urgent tiers belong to the driver — the system speaks only when invited. The most urgent belong to the system, and AI is silent there because driver agency at that moment is fragile and shouldn't be confused with anyone else's voice. The middle tiers are where most of the design work happens, because that is where the lines are not obvious.
What surprised me — what I came back from the work thinking — is that most product decisions are agency decisions in disguise. The button you make prominent. The default toggle. The screen the user sees first. Each one is a small wager about whose intentions matter more, in this moment, in this context. Calling these "design decisions" rather than "agency decisions" obscures what they are.
The five‑tier framework isn't the only way to think about it. But it's the way I think about it now, and it sits underneath everything else I'm working on.
Section II
Selected cases. The structure underneath is the discipline; the screens are the evidence.
More work — GoDaddy, Everly Health, Cmd, Odyssey — listed in About and on my CV.
Work — case 01 of 04
GM's vehicle OS needed one framework for alerts and notifications across in‑vehicle, mobile, and connected surfaces. Without it, every team was making per‑case decisions about when to interrupt a driver, how to escalate, and when AI was allowed to speak — slow, inconsistent, risky in a safety‑critical environment.
I designed a five‑tier severity framework grounded in driver safety and human agency. Each tier defines when and how the OS may interrupt, what the system is permitted to say, and what latitude AI is given.
Immediate threat to driver, vehicle, or others. The system speaks the way it must be heard. AI is silent here; only the system speaks.
Time‑sensitive, safety‑adjacent. The system may interrupt but does not demand. AI may amplify what the system has said — not initiate.
Should be known, not acted on now. The system surfaces; AI may explain when asked.
Useful, non‑urgent context. Queued, not interrupted. AI may converse here without surfacing safety concerns.
Background state, environmental, not directed at the driver. AI is allowed to be conversational here — as long as the driver chose the conversation.
Specific rules per tier are governed by GM's confidentiality. The structure shown — five tiers, descending severity, ascending conversational latitude for AI — is the framework the work produced.
Leadership endorsed the direction. The framework is being adopted across the OS, giving product and engineering teams reusable criteria for interruption decisions without case‑by‑case content review. Alongside it: naming and brand strategy for OnStar AI Assistant (OSAIA), and content standards for gmUI 3.0 across mobile, web, and in‑vehicle.
Work — case 02 of 04
Apple's Commerce platform supports developers selling subscriptions, in‑app purchases, and bundled products across global markets — each with its own tax, regulatory, and policy requirements. Bundling needed a content system that could ship anywhere, by any team, without case‑by‑case writer review.
I built the foundational content system covering the bundling experience: the screens any team would assemble, the flow patterns they would follow, and the language conventions for each market and policy context. I defined the patterns and the rules for combining them, so the system itself could be picked up by internal Apple teams or third‑party developers without me in the room.
The work sat alongside the broader UX writing standards I established for Apple's Commerce space — language conventions specific to commerce flows that future writers can extend.
Live in production across Apple's developer ecosystem. The patterns can be used by future writers and teams to assemble new bundles without requiring the original author. That is the test of a content system: whether it survives without you.
Work — case 03 of 04
Inception Health needed a complete content foundation for the Here Health app, brand, and patient‑facing website — built from scratch, in a regulated healthcare context, with legal and compliance review at every patient‑facing touchpoint.
I developed the voice and tone guide spanning the app, the digital product, and the patient‑facing site — giving the ecosystem one coherent voice. I wrote the product copy for the app itself. I led the content redesign of the Froedtert & MCW site, partnering closely with legal on patient‑facing language and disclosures.
I also built the FAQ infrastructure and help‑desk content library — patterns that let the product handle patient self‑service without escalation for the easy questions.
A unified voice across app, brand, and patient site. A voice and tone guide that the rest of the organization could pick up and use. A help‑content library that supports patients without requiring a writer in the loop for every question.
Work — case 04 of 04
I shipped a conversational AI experience on mobile and web using GPT‑4, defining the multi‑turn interaction model and the assistant's voice. The voice work mattered: a tutor that sounds wrong is a tutor people stop trusting.
Alongside it, I redesigned and systematized the multi‑factor authentication and identity verification flows across Chegg's product surface — balancing fraud prevention, regulatory requirements, and friction for legitimate users, partnered closely with security and legal.
I also led a voice and tone refresh across the platform, establishing updated language standards adopted by product teams.
Section III
A small number of outside projects each year, alongside my day work at GM. Selectively, slowly, on the right things.
engagements where there's a system that needs designing — not a one‑off copy review. Three shapes I get hired for most:
Embedded with your team for six to sixteen weeks. Scoped to a question, not a fixed deliverables list. I bring the discipline; you bring the context. I work best with teams who take their users seriously and aren't in a hurry to ship something forgettable.
Most of my work has been in regulated environments — healthcare, automotive, diagnostic — and I bring legal and compliance into the design process early. Patient‑facing or safety‑critical language ships clean the first time.
Considering one engagement starting in Q4 2026.
Advisory and short consultations available sooner.
Email me at tylerjlyman@gmail.com. Tell me briefly: what you're working on, what kind of help you're looking for, and roughly when. I reply to everything.
Section IV
Three projects I keep alongside the work. They share a maker, not a frame.
Practice — project 01 of 03
One entry per day, forty days, then bound. Less a product than a discipline — a daily commitment that produces something physical at the end. The book is small. It is real. It is the proof that I did what I said I would do.
Forty is long enough that the practice is no longer novelty and not yet drudgery — the place where most of the actual work gets done. Forty is also short enough that finishing is plausible from where I'm standing on day one.
Because most creative practices end in nothing — a folder, a feed, a tab. The bound book is the answer to "what did you make." You can hand it to someone. You can put it on a shelf. You can lose it.
Practice — project 02 of 03
We read, we write, we send each other things in the mail. The aim is craft, slowly, with people who can take it. The collective is small on purpose; the work it produces is the kind that benefits from a few good readers and no audience.
Writing alone is the work. Writing alongside is the practice. You bring drafts you would not otherwise finish, and someone else's drafts make you better at reading your own.
Practice — project 03 of 03
A working tool for keeping the line between input and output thin and intentional. What you read becomes what you make. Suprareader is the place I built to make that easier for myself, and now for a few other people.
Reading and writing are usually treated as separate practices. They aren't. The most generative writers I know read with a pen — and most pens go missing. Suprareader is what came out of getting tired of losing the pen.
Section VI
A short vocabulary for the discipline. Dotted terms throughout the site pull from here — tap one for a quick definition.
The structural design of what a product is allowed to say, before any words are written.
Content architecture is the work of designing the model, taxonomy, governance, and naming systems that hold a product's language together. Where information architecture orders the boxes, content architecture orders what the boxes can say. It is upstream of UX writing; it is what makes the writing scale beyond the original author.
The discipline of designing content as part of the interface, not as copy added afterward.
Content design treats the words on a screen as design material — shaped together with layout and flow, not handed off downstream. It overlaps with UX writing but is broader, including content models, microcopy patterns, and structural decisions about what a product communicates at all.
The craft of writing the words inside product interfaces — buttons, error messages, empty states, microcopy.
UX writing happens at the level of individual words and short strings. It is usually the most visible content discipline, because users read it directly. But it sits inside a larger architecture: voice, tone, patterns, and the system that gives the words their shape.
Voice is how a product always sounds. Tone is how it sounds in a particular moment.
Voice is the stable identity of a product's language — the qualities that should be consistent across every screen. Tone modulates within voice: an error message has a different tone than a success state, but both should still sound like the same product. The system that holds both — the patterns, the do/don'ts, the boundaries — is what scales.
A structured definition of what types of content exist in a product and how they relate.
A content model defines the fields, relationships, and rules that govern how content is structured behind the interface — what a "course" is composed of, what a "lesson" requires, which fields are optional, what content can reference what. It is the upstream constraint that shapes everything that gets written.
The rules for who decides what gets said, how, and when.
Content governance defines decision rights and workflows — who can write what, who approves, what reviews are required, what the escalation paths are. Governance is what keeps a content system intentional after the original team has moved on. Without it, every new screen becomes a one‑off decision.
A system of categories and labels that organize what a product talks about.
A taxonomy classifies content — categories, tags, types, statuses — so a product can find, filter, and relate things. It is upstream of UX, but its decisions shape how users see what exists in the product. Bad taxonomies hide what is there; good ones make the structure of the product visible.
A system for deciding when a product should act, speak, or interrupt.
A behavioral framework defines the rules for when an interface should reach for the user's attention, what severity tiers exist, what each tier is allowed to do, and what is escalation versus ambient. The five‑tier alerts framework at GM is a behavioral framework — it defines who gets to take the driver's attention and on what terms.
Section V
I'm a content designer and content architect. I design the systems beneath what a product says — models, frameworks, voice, governance.
I came up through writing — literary writing, specifically. The BA at Naropa was in writing and poetics; the apprenticeship since has been a long one in attention to the line. The product work I do now isn't separate from that. It's the same instinct turned toward systems.
Senior content designer at General Motors. I architected the alerts framework covered in Work, led naming for OnStar AI Assistant, and am extending the work into broader content standards across gmUI 3.0.
A decade across regulated environments — healthcare, automotive, edtech, fintech‑adjacent. The four most recent are in Work. Before them: Everly Health, Cmd (acquired by Elastic), GoDaddy, and Odyssey, where I led an editorial operation from one to ten million monthly page views.
I write outside of product — essays here, occasional notes, and a quieter writing practice that ends in a bound book every forty days. I keep a small writers' collective and a reading tool for writers, both small on purpose. They're related to the day work, but not in business with it.
For new project work, start with Available — it lays out what I take on, how I work, and what I'm currently considering.
For everything else: tylerjlyman@gmail.com. I reply to everything.