Plain language is a product design decision

Complexity does not disappear when a sentence becomes shorter. A person can read every word on a screen and still have no useful understanding of what it means for them. That is why I treat plain language as part of product design, connected to structure, sequence, and the decisions the interface asks someone to make.

The goal is not to make a specialist subject sound casual. The goal is to help someone build an accurate understanding without first acquiring the team's vocabulary. Sometimes that requires a short definition. Sometimes it requires an example, a visual relationship, or a clearer separation between what is known and what remains uncertain.

AI can produce fluent explanations quickly. The design responsibility is deciding whether those explanations preserve the meaning that matters.

Find the decision inside the explanation

Before rewriting a page, I want to know what the reader needs to understand or do. A broad request to make content simpler can lead to shorter copy without improving the experience. A specific question gives the team a better standard.

Imagine a product that shows a customer several account states. The customer may not need a full explanation of the internal processing system. They do need to know whether their action succeeded, whether they need to do anything else, and where to look if the state changes. The content should support those decisions in a sensible order.

This is where design and writing become difficult to separate. If the explanation requires several unrelated ideas, the page structure may be wrong. If a term needs repeated clarification, the label may be wrong. Editing the paragraph can help, but the stronger change might be to reorganize the interaction.

Keep the meaning intact

My Genographic project involved turning scientific information into an interactive ancestry experience for a general audience. I coordinated experience work with scientists, stakeholders, designers, and engineers. Understanding the underlying information was necessary before deciding how to present it.

The challenge was not simply to remove scientific terms. We needed to understand what the information represented and where simplification was appropriate. A clear story still had to respect the science. That required conversation with the people who understood the subject in depth, followed by careful design decisions about how much context to show at each stage.

That experience informs how I would use AI to assist with explanations today. I would provide approved source material, ask for a defined audience and purpose, and review the result against the source. A smooth sentence is a candidate for review. It is not evidence that an important distinction survived the rewrite.

Explain relationships before adding detail

People often struggle because they cannot see how the parts connect. A glossary can define every term and still leave that relationship unclear. A diagram, a short sequence, or a carefully chosen comparison may provide a better starting point.

Hoopes Vision Atlas explored a visual approach to eye education. I helped shape the concept and used AI-assisted coding to implement the demo. The experience lets people explore anatomy and conditions in smaller steps rather than encountering all the information as a dense block of text.

The project is an educational demo, not a substitute for an individual clinical conversation. That boundary is part of the content design. A useful explanation can help someone form better questions while remaining clear about what the experience can and cannot determine.

For other complex products, I would look for the equivalent relationship. In an invoice tool, it might be how a project, a billable item, and a payment connect. In a university directory, it might be how a program relates to a department. Once that relationship is clear, additional detail has somewhere to fit.

Let people choose the depth they need

A product does not have to choose between a tiny summary and a complete technical document. It can provide layers, with each one helping the reader decide whether to continue.

I would start with a direct answer to the immediate question, then provide the explanation needed to use that answer responsibly. Supporting definitions and deeper references can remain available without interrupting everyone. The important requirement is that the shorter layer must still be accurate on its own.

Expandable content deserves particular care. It can reduce visual density, but it should not hide information required to understand a consequential action. If someone needs a condition or limitation before confirming a decision, that information belongs in the main path. The interaction should support attention rather than depend on the person opening every panel.

This is also useful for AI answers. A brief response can link to the exact resource that supports it. The reader gets a usable starting point and a route to inspect the context.

Review generated language for changes in meaning

When using AI to help rewrite technical content, I would compare claims, not just tone. Did a possibility become a guarantee? Did a general statement become personalized advice? Did the rewrite remove the condition that made the original statement true?

Those changes can be small at the sentence level and large at the product level. Consider a hypothetical sentence saying a feature may help someone prepare information for a review. A rewrite that says the feature ensures approval has changed the promise. The result may sound clearer because it removed uncertainty, but the uncertainty was meaningful.

I would keep a short review record for sensitive explanations: the source, the audience, the intended takeaway, and any qualifications that must remain. A specialist can then review the right questions instead of being asked whether the paragraph sounds good. Designers can check whether the interface preserves the same qualifications around actions and summaries.

Test understanding in the person's own words

A content review should go beyond whether participants like the writing. I would ask them to explain what they think the product means and describe what they would do next. Their explanation can expose a gap that a readability score misses.

For an educational interface, someone might repeat a label correctly but misunderstand the relationship between two concepts. For an operational tool, they might believe a saved draft has already been sent. Both problems require attention even if the language looks simple.

The test should match the task. I would avoid turning it into a vocabulary quiz. The useful question is whether the person has enough understanding to proceed appropriately, and whether the product gives them a path when they need more help.

Make clarity maintainable

Plain language can erode as a product grows. Different teams introduce different names, a new policy changes an explanation, or a generated summary repeats old wording. A shared vocabulary and a clear source of truth make that easier to manage.

I would document important terms beside the product's content and design patterns. A label should have an intended meaning, a context where it belongs, and an owner who can resolve uncertainty. That gives future contributors something stronger than a preference to follow.

Clear language is a practical form of respect for the reader's time and judgment. It helps someone understand what the product is saying without asking them to guess what the team meant. When AI becomes part of the workflow, that standard still applies to every generated sentence we choose to put in front of a person.