When local governments talk about AI implementation, the conversation usually starts in the same place: tools, vendors, pilots, and budgets. What it rarely starts with is language.

That’s a problem. Because before AI can improve civic services, it needs something to work with — and in most local governments, that something is a sprawling, inconsistent body of documents, policies, forms, and workflows written in language that’s unclear even to the humans who use it every day.

Plain language isn’t a communications nicety. For local governments investing in AI, it’s the foundation everything else depends on.

What AI Actually Does With Your Content

AI tools — whether they’re summarizing reports, drafting resident communications, answering service questions, or routing requests — are only as good as the content they’re trained on or working with.

Feed an AI system vague policy language, inconsistently formatted procedures, or jargon-heavy forms, and you get vague, inconsistent, jargon-heavy outputs. Garbage in, garbage out is a cliché because it’s true — and in local government, where the stakes include resident trust, legal compliance, and equitable service delivery, bad outputs aren’t just inconvenient. They’re costly.

Plain language implementation solves this at the source. When your documents are clear, consistent, and structured for comprehension, AI tools have something solid to work with. The outputs improve. The errors decrease. The staff time spent correcting AI-generated content drops significantly.

 The Communication Gap Nobody Is Talking About

Most AI readiness frameworks focus on technical infrastructure: data systems, security protocols, integration capacity. These matter. But they don’t address the communication layer — the actual language your organization uses to document processes, instruct staff, inform residents, and record decisions.

In most local governments, that communication layer has never been audited. Policies written a decade ago sit alongside newer procedures in different formats, different reading levels, and different terminology for the same concepts. Nobody planned it that way. It just accumulated.

When AI enters that environment, it doesn’t fix the inconsistency. It inherits it — and then scales it.

Plain language audits surface these gaps before they become AI problems. They identify where terminology is inconsistent, where instructions are ambiguous, where documents assume knowledge that staff or residents may not have. That work, done before AI implementation, dramatically reduces the risk of AI implementation going wrong.

 Plain Language and AI Readiness Are the Same Work

Here’s what local government leaders often don’t realize until they’re deep into an AI project: the work of plain language and the work of AI readiness overlap almost entirely.

Both require you to inventory and assess your existing content. Both require clear, consistent terminology across departments. Both require documented workflows — not just the ones that live in people’s heads. Both require staff who understand what good communication looks like and why it matters.

Organizations that have invested in plain language are, almost by definition, better prepared for AI adoption. Their content is cleaner. Their processes are documented. Their staff are trained to think about how information is structured and received.

Organizations that haven’t done that work will do it eventually — either proactively, before AI implementation, or reactively, after AI implementation surfaces every gap at scale.

What This Looks Like in Practice

Consider resident-facing services: permit applications, benefits enrollment, complaint submission. These are high-volume, high-stakes interactions where AI tools are increasingly being deployed to streamline processing and improve response times.

If the underlying forms and instructions are written in complex bureaucratic language, AI doesn’t simplify them — it processes them as-is and returns outputs residents still can’t understand. The bottleneck moves but doesn’t disappear.

Now consider the same services after a plain language review. Forms use common words. Instructions are step-by-step. Terminology is consistent across channels. When AI enters that environment, it has clear inputs to work with and produces clear outputs. Staff spend less time fielding confused calls. Residents complete transactions successfully on the first attempt. The efficiency gains AI promised actually materialize.

Plain language isn’t preparation for AI. It’s what makes AI work.

Where ACLARA Comes In

ACLARA is an AI readiness scoring platform built specifically for local government — and plain language readiness is central to how it works.

An ACLARA audit doesn’t just assess your technical infrastructure. It evaluates the communication layer: the quality and consistency of your content, the clarity of your documented workflows, the capacity of your staff to communicate effectively in an AI-assisted environment.

The result is a concrete readiness score with a prioritized roadmap — so your leadership team knows exactly where to focus before committing to new tools or new vendors.

If your city or county is making AI decisions right now, the most useful thing you can do is understand where you actually stand. Not where you hope you stand. Not where a vendor’s demo suggested you stand. Where you actually stand.

That’s what ACLARA is built to tell you.

Request early access at aclara.ai— and visit plainlii.com to learn how Plain Language International helps local governments build the communication foundation that makes everything else work.

This week, a major cryptocurrency exchange announced it had received a Federal Reserve master account — the first digital asset company in U.S. history to get one.

The announcement was full of phrases like “sovereign financial rails,” “atomic settlement,” and “full-reserve model.” If your eyes glazed over, you’re not alone.

Here’s what it actually means: a crypto company can now move money directly through the U.S. government’s payment system — the same infrastructure banks use — without going through a middleman bank. That’s a big deal, because those middlemen have been a weak link for crypto companies for years.

Inside the Crypto Kraken Case

A Crypto firm gaining direct access to transacting with the Federal Reserve is, to say the least, a significant development. Here’s what it means across a few dimensions:

For Kraken specifically

The practical upshot is that Kraken can now move dollars directly on Fedwire — the backbone of large-value U.S. payments — without routing through a correspondent bank like JPMorgan or Silvergate (which collapsed in 2023). That removes a key dependency and a layer of cost and counterparty risk. It also means they’re no longer subject to a correspondent bank deciding to terminate their relationship, which has been an existential threat for crypto firms in the past.

For the crypto industry broadly

This is the most important implication. For years, one of crypto’s structural vulnerabilities has been its fragile connection to the traditional banking system — crypto firms depended on a small number of willing banks, and when those banks failed or exited (Silvergate, Signature), the whole sector felt it. A direct Fed master account changes that calculus. If this model becomes replicable, crypto infrastructure firms could become first-class participants in the U.S. payment system rather than tolerated guests.

For regulators and policy

The Fed has historically been extremely reluctant to grant master accounts to non-traditional institutions; there’s ongoing litigation from other crypto banks (Custodia Bank fought a similar application for years and lost). So, the fact that Kraken got one signals a substantial shift in regulatory posture, likely reflecting the broader policy environment shift toward crypto under the current administration. It may open the door for other Wyoming SPDIs, but the Fed will probably move slowly.

The “atomic settlement” vision and what to watch for

The most forward-looking implication in the announcement is the mention of atomic settlement (dollars and the crypto swap hands at exactly the same moment so no one has the risk of leaving empty-handed). Right now, even in regulated markets, there’s a timing gap between the crypto and the dollar side of the trade. If Kraken can eventually connect on-chain settlement with  direct Fedwire access, that closes the loop in a way that’s genuinely new. (The settlement means completing the blockchain transaction–remember that blockchain is the underlying technology, akin to a digital ledger, that creates and records transactions across many computers, making it impossible to change past entries because each new “block” of data is securely chained to the last one.) That’s still aspirational, but it’s architecturally plausible now in a way it wasn’t before.

The key caveats are that this starts with a narrow, phased rollout for institutional clients, and the Fed will watch closely before allowing expansion. The real test is whether this remains a one-off or becomes a template — and whether Custodia and similar institutions can now point to this approval to reopen their own cases.

But the reality is that it’s no longer hyperbole to call this structural. It legitimizes a new kind of financial institution that sits at the intersection of crypto custody and sovereign payment rails, and it reduces the sector’s chronic vulnerability to banking access being cut off.

Why does the language matter?

Financial institutions often communicate in ways that are technically accurate but practically useless to most readers. The people most affected — customers, investors, policymakers, the general public — are left guessing.

Plain language isn’t about dumbing things down. It’s about respecting your reader’s time and making sure your message actually lands. Complex ideas can be explained clearly. “Direct access to Federal Reserve payment infrastructure” can become “they can now move money through the government’s banking system without a middleman.” Same fact. Completely different level of understanding.

The stakes are real. When financial news is hard to understand, people make worse decisions. They misread risk. They tune out policy conversations that directly affect them. They trust institutions less — often for good reason.

The crypto industry is at a turning point. It’s moving from the fringes of finance toward the center. That transition will go more smoothly — for companies, regulators, and the public — if the communication keeps pace with the complexity.

Clear writing isn’t a nice-to-have. It’s infrastructure too!

The Language Industry Is Not Evolving — It’s Being Rewritten

For decades, the language industry has described itself as “resilient,” “people-driven,” and “quality-focused.” Those words describe strengths. But today, they are insufficient.

What is happening now is not gradual modernization. It is identity disruption. The language industry is not simply adopting Artificial Intelligence (AI) — it is being redefined by it.

And many players are still acting as if this is just another technology upgrade. It is not.

The Comfort Illusion

For years, the industry operated within a predictable model:

• Per-word pricing
• Human translation as the primary production engine
• Agencies managing distributed freelancers and adding value in orchestration
• Technology as productivity support

Margins were tight but stable. Demand was steady. Growth meant more linguists.  Then the content explosion happened. Software ate the world. Global expansion accelerated. And AI reached linguistic competence at scale.

The old operating model cannot support the new content economy. Yet parts of the industry are clinging to incremental adjustments — adding machine translation as a line item, relabeling post-editing services, or rebranding as “AI-powered” without fundamentally restructuring their workflows.

AI Is Not a Tool. It Is Infrastructure.

Neural machine translation was the first signal. Large language models are the second wave — and far more disruptive. AI can now generates multilingual content “natively”—yes, it is still predicting next token. But.. with million-token context windows, AI models can process vast amounts of information in a single prompt. This is equivalent to approximately 750,000 words, thousands of files, or 90 minutes of video. Sure, it is not a lifetime of experiences, but this helps AI now:

• Adapt tone and brand voice across markets
• Perform terminology enforcement at scale
• Operate in real-time within software systems

This shifts language from a downstream service to an embedded system capability. Companies are no longer asking, “How do we translate this content?” They are asking, “How do we design content to scale globally from day one?” That question changes everything.

The Human Role Is Changing — Not Disappearing

The End of Per-Word Thinking

Per-word pricing made sense in a human-only production model. It becomes misaligned in an AI-augmented one. When marginal production cost approaches zero for first-pass output, value moves elsewhere:

• Risk management (this is HUGE!)
• Domain expertise
• Brand protection
• Compliance assurance
• Data governance
• Accessibility
• Engagement

The industry must confront a difficult truth: translation as a commodity is collapsing. What remains valuable is judgment.

The Rise of Language Operations (LangOps)

The companies that will lead the next decade are not “translation providers.” They are architects of language infrastructure.

Language Operations means:

• API-driven pipelines integrated into product development
• Continuous localization within CI/CD environments
• AI-assisted generation and adaptation
• Real-time analytics and performance tracking
• Human oversight applied strategically, not universally

Organizations that understand this shift from service to architecture layer are building scalable multilingual ecosystems. Those who don’t are optimizing workflows that may soon be obsolete.

The Human Role

The narrative of “AI replacing translators” is simplistic. What is happening is more nuanced — and more demanding. The linguist of the future is:

• A domain specialist
• A cultural strategist
• An AI output evaluator
• A quality architect

Routine translation will be automated. High-context judgment will not.  The uncomfortable reality is that generalist production work will shrink. Specialized expertise will grow in value. This bifurcation is already underway.

The Strategic Shift: Language as Growth Engine

Forward-thinking enterprises treat localization as market acceleration infrastructure. Multilingual capability now directly influences:

• Revenue expansion
• Customer acquisition
• Product adoption
• Brand perception

In global digital markets, language agility equals competitive advantage. Speed matters. Scalability matters. Consistency matters. Risk management matters.

The providers who enable those outcomes — not just translated words — will define the next era.

The Industry’s Choice

The language industry stands at a crossroads:

1. Protect legacy structures and compete on shrinking margins
2. Redesign itself around AI-native operations

One path leads to commoditization. The other leads to strategic relevance.

This transformation is not theoretical. It is already visible in procurement behavior, startup innovation, enterprise localization strategies, and venture investment patterns.

The real risk is not disruption but underestimating how deep this shift goes. Because this is not about better translation technology. It is about a new operating model for global communication.

And operating models, once broken, do not quietly return.

The Missing Conversation: Plain Language as Power

As the industry races toward AI-native workflows and scalable multilingual systems, one principle risks being overlooked: clarity.

Plain language is not cosmetic. It is structural.

In civic contexts, language determines access. Policies, voting materials, public health guidance, and legal notices are only as effective as they are understandable. When language is opaque, participation declines. When it is clear, engagement rises.

In consumer markets, complexity erodes trust. Contracts buried in jargon, unclear return policies, ambiguous terms of service — these are not neutral communication choices. They shape power dynamics between institutions and individuals.

AI now gives organizations the ability to produce content at unprecedented scale. But scale amplifies whatever philosophy guides it. If complexity is automated, confusion scales. If clarity is engineered, trust scales.

Plain language, therefore, becomes a strategic decision.

For enterprises, it improves customer satisfaction, reduces support volume, strengthens brand credibility, and lowers legal risk. For governments and regulated industries, it reinforces transparency and democratic participation.

In a world where machines can generate infinite words, the competitive advantage may belong to those who choose fewer — and clearer — ones.

The future of the language industry is not just multilingual.

It must also be intelligible.

When do Translation Quality Scores Signal “Fitness for Purpose”?

Translation quality scores are supposed to predict success. But what happens when translations pass every quality check—and still fail in the market? The gap between measured quality and actual fitness reveals a fundamental flaw in how most organizations validate their translation workflows.

The stakes for translation quality validation have escalated significantly. Regulatory frameworks in medical devices and pharmaceuticals now require documented evidence that translations enable safe use—not just linguistic accuracy. AI and machine translation have compressed production timelines while introducing new uncertainty about output quality. Global brands face amplified reputational risk in markets where a single mistranslation can trigger viral social media backlash. Meanwhile, distributed teams and external vendors make specification alignment harder to maintain. Organizations can no longer afford to discover validation failures only after deployment, when correction costs multiply exponentially.

This article argues for a clear conceptual separation between verification and validation, and for applying that separation consistently at two different logical levels: the translation product and the translation quality evaluation (TQE) system that evaluates it. Without this separation, procedural compliance can be easily mistaken for effectiveness, and confidence in quality decisions is weakened.

Verification and Validation: The Core Distinction

In essence, verification is about checking compliance with specifications (stated and operationalized requirements) and validation is about checking fulfillment of actual requirements (stakeholder needs and expectations). Verification operates within the requirements space, while validation requires contextual evidence.

The distinction between meeting specifications and meeting requirements is well established in ISO quality management standards, yet its implications for translation quality evaluation are often underappreciated. A product can fully comply with its specifications and still fail to meet user needs.

This failure can arise from an array of causes, such as specifications that were incomplete or misaligned with requirements, or the use of a system that was not a reliable predictor of success.

When a metric is implemented incorrectly, scoring rules are applied inconsistently, or translators, evaluators, and validators rely on mismatched specifications, the issue is one of verification failure.

By contrast, when a metric is correctly implemented but is based on specifications that do not or no longer reflect current user requirements, the resulting scores may not support fitness for intended use.

Reliability issues are particularly important in this context: even a well-designed and correctly implemented TQE system cannot support valid decisions if its results are unstable. For example, inadequate evaluator training may lead to poor inter-rater or intra-rater agreement, undermining confidence in quality scores.

The following example illustrates product-level validation failure despite both product and system verification success. A healthcare organization consistently achieved 95% quality scores on patient-facing medication instructions using a rigorously implemented TQE system. Post-deployment analysis revealed critical comprehension failures: patients misunderstood dosing schedules and contraindication warnings. The specifications were being met—terminology was consistent, style guides were followed, error counts were low. But the specifications didn’t reflect how patients actually needed to process safety-critical information under cognitive load, time pressure, or health literacy constraints. The failure wasn’t procedural. It was a validation gap that specification compliance couldn’t detect.

Two Objects, Two Levels of Assurance: Product vs. System

To complicate matters, another source of confusion in translation quality discussions is the failure to distinguish between two different objects: 1) the translation product (the translated content) and 2) the TQE system (the metric, dimensions, weights, thresholds, sampling, and evaluators used to assess that content).

Verification and validation apply to both—but they do so at different logical levels. Activities at one level cannot substitute for activities at the other.

Product-Level Verification and Validation

Product Verification: Conformance to Specifications

At the product level, verification addresses the question of whether a translation conforms to its project specifications. Project specifications typically include terminology requirements, style guide adherence, and process constraints, such as revision requirements or use or non-use of MT.

Product verification checks whether such specifications have been implemented correctly. This is the domain of linguistic checks, QA tools, and analytic quality evaluation using metrics such as MQM.

For further detail on MQM dimensions, error taxonomies, and metric design, see resources published by the MQM Council.

It is critical to note that verification operates entirely within the space of specifications. It does not directly assess stakeholder needs, as it assumes that the specifications adequately represent those needs.

Product Validation: Fitness for Purpose

Product validation addresses a different question, namely, whether a translation is fit for its intended communicative purpose and usable by its target audience. This question cannot be answered by specification compliance alone. Product validation requires evidence from outside the verification process, such as:

• Task success rates,
• Stakeholder acceptance,
• Real-world deployment outcomes.

Product validation may occur occasionally rather than systematically, and when it fails, it should trigger an investigation on the root causes: Were the specifications implemented correctly? Are the specifications still appropriate? Have requirements changed?

System-Level Verification and Validation

TQE System Verification: Correct Implementation

At the system level, verification addresses whether a TQE system has been implemented and applied as defined. This includes confirming that processes are consistent and repeatable with:

• Metrics are applied as designed.
• Scoring rules are followed.
• Evaluators are trained to apply the metric consistently.

System verification ensures procedural correctness. It does not answer whether the system measures what actually matters.

TQE System Validation: Confidence for Decision-Making

System validation addresses a hard question: whether the TQE system reliably supports correct quality-related decisions for a given context. In practice, this means addressing whether:

• High scores reliably correspond to translations that meet stakeholder requirements.
• Low scores reliably flag translations that do not.
• Decision thresholds (publish, revise, reject) lead to appropriate outcomes.

Answering these questions requires meta-evidence, which emerges from outside the specifications space:

• Expert review of quality decisions,
• Alignment between evaluation outcomes and user acceptance,
• Correlation between scores and downstream outcomes (such as task success, user complaints, support tickets)

A TQE system can be fully verified and still be ineffective if it has never been validated for the decisions that it informs.

Risk, Uncertainty, and the Limits of Scores

When a Passing Score Fails to Meet Users Needs and Expectations (The Disney Problem)

Consider a scenario where a translation complies with all specifications. It is evaluated by a correctly implemented TQE system. It passes all thresholds. And yet… users reject it. Nothing has gone wrong at the level of verification. The failure occurs at the level of validation. This can happen when:

• Specifications no longer reflect user needs, leading to costly post-launch revisions or brand reputation damage in key markets.
• Error weights do not reflect real risk.
• Sampling introduces excessive uncertainty, potentially exposing entire product lines to undetected risk in user-critical segments.
• Evaluators lack access to relevant specifications.

The lesson is simple but uncomfortable: procedural correctness does not guarantee effectiveness.

Risk Management as Validation Variable

Quality scores are often treated as deterministic signals. But, in reality, they are inferences made under uncertainty. As such, their interpretation requires implementers to consider additional questions, including:

• How close is the score to the decision threshold?
• What is the level of evaluator agreement?
• How much uncertainty is introduced by sampling?
• Do different quality dimensions tell a consistent story?

Confidence intervals, inter-rater agreement, and internal consistency are not “nice to have” analytics; they are potential sources of validation evidence. They help determine whether a score is a reliable basis for decision-making or whether additional validation (such as user testing) is warranted.

Validation failures announce themselves late and expensively. Organizations discover that “compliant” translations don’t work only after launch, when typical correction costs run 10-30x higher than proactive validation. Emergency re-translations compress timelines and strain vendor relationships. Support tickets from confused users accumulate faster than quality scores predicted. Product launches delay while teams troubleshoot translations that technically passed all checks. In regulated industries, inadequate validation creates audit exposure that procedural compliance alone cannot address. These costs don’t appear in quality reports because unvalidated systems measure activity, not outcomes.

Seven Tips to Validate Without Overcomplicating Quality Management

Validation does not require continuous user testing or exhaustive experimentation. It requires targeted evidence that reduces the most relevant uncertainties. The following practices provide practical entry points for validation at both product and system level.

The following tips can guide validation for implementation in high-volume and risk-sensitive translation workflows.

1. Validate at Decision Boundaries, Not Everywhere

Validation efforts should concentrate where decisions carry risk, so validation should be prioritized when:

• Scores cluster near publish/reject thresholds,
• Quality dimensions conflict (e.g., fluency high, borderline accuracy),
• Content is user-facing, safety-critical, or brand-sensitive.

Rather than applying validation efforts uniformly, targeting boundary areas focuses efforts on high impact areas.

2. Use Targeted User Evidence, Not General Feedback

Validation evidence should be purpose-specific. Fitness for purpose is not a matter of whether users like a translation. Instead, concrete evidence can come from:

• Completing intended tasks,
• Understanding key messages without the need for clarification,
• Avoiding risk points (legal, medical, safety) based on content.

Task success is often more informative than subjective preference—and Likert scale preferences have been shown to be ill-aligned with task success metrics.

3. Exploit Disagreement as a Validation Signal

Evaluator disagreement is often treated as noise. In validation, it should be treated as data. Track inter-rater disagreement on high-impact dimensions and recurrent disputes on the same error types. Persistent disagreement may indicate that:

• Specifications are underspecified, or
• The TQE system is not aligned with real decision criteria, undermining confidence in every quality decision it informs.

4. Test the TQE System Against Known Outcomes

System validation requires ground truth, even if imperfect. Periodically compare TQE outcomes against content that previously triggered user complaints and content that performed well in real-world use.

Analyze false positives (“passed but failed in use”) and false negatives (“failed but worked fine”). Both outcomes become validation findings.

5. Treat Sampling as a Validation Risk

Sampling decisions introduce uncertainty that verification cannot remove. Unlike sampling ideally identical outputs of tangible manufacturing, translation sampling for quality evaluation is sampling across heterogeneous content with uneven user impact, where defects are not randomly distributed and consequences vary by context.

For sampled evaluations, explicitly ask:

• What failure modes could this sample miss?
• Is the sample representative of user-critical content?
• Would a different sample plausibly change the decision?

If the answer is “yes,” additional validation may be warranted.

6. Revalidate When Context Changes

Validation is not a one-time activity. Changes in context invalidate old assumptions faster than they invalidate procedures. Trigger revalidation when:

• Target audiences change
• Content type or risk profile shifts
• New MT or post-editing processes are introduced
• Quality scores drift without corresponding outcome evidence

7. Document Validation as a Rationale, Not a Score

Validation should support decision confidence rather than produce another metric. To keep validation lightweight while making uncertainty explicit, capture validation outcomes as:

• Short decision rationales.
• Assumptions tested and confirmed (or rejected).
• Residual risks accepted.

A Layered View of Translation Quality Assurance

Maintaining a clear separation between verification and validation ensures that 1) compliance is not mistaken for effectiveness; 2) confidence in quality decisions is justified; 3) risk is managed transparently; and 4) standards remain clear.

A robust translation quality framework respects the following chain:

1. Requirements are about stakeholder needs and expectations
2. Specifications are operationalized requirements
3. Verification (TQE) is the analytic evaluation of compliance
4. Scores & Decisions indicate inferred fitness
5. Validation is evidence that inference is reliable
6. Recalibration adjusts specifications and system to obtain valid and reliable scores.

Confusing the two may be operationally convenient, but it is conceptually unsound and increasingly risky in complex, high-stakes translation contexts.

Verification tells us whether we did what we said we would do. Validation tells us whether doing so actually works. Validation closes the quality evaluation loop. Without it, quality management becomes self-referential.

Building Justified Confidence in Quality Decisions

The separation between verification and validation isn’t academic—it’s the difference between measuring activity and measuring outcomes. Organizations that build validation into their quality frameworks gain not just better translations, but justified confidence in their quality decisions under uncertainty.

If your quality scores aren’t reliably predicting fitness for purpose, the problem isn’t the translators—it’s the system. And unlike verification failures, validation failures don’t announce themselves until correction becomes expensive. The question isn’t whether your translations comply with specifications. The question is whether your specifications—and the system that measures them—reliably predict what actually matters.

Validation closes the quality evaluation loop. Without it, quality management becomes self-referential, measuring its own compliance rather than stakeholder success.

Figure 1: Table comparing verification and validation at two levels. Rows distinguish the translation product and the TQE system. Columns distinguish verification and validation. Product-level verification concerns conformance to specifications such as terminology and style, while product-level validation concerns fitness for intended use based on user outcomes. TQE system verification concerns correct metric implementation and evaluator consistency, while system validation concerns whether quality scores reliably support correct decisions.

At the start of every new year, we talk about resolutions, new initiatives, new tools, new ways of working. But after years of working with writers, leaders, and public-facing organizations, I’ve learned that progress rarely comes from adding more.

It comes from making things clearer.

So my New Year wish—for our readers, our clients, and our teams—is simple: Clarity. Clarity in how we write. Clarity in how we lead. Clarity in how people experience the systems we design.

I’ve seen firsthand how unclear communication slows down good work. Policies that are technically correct but difficult to use. Forms that ask too much, too fast. Guidance built on assumptions instead of meeting people where they are. None of this comes from carelessness. It usually comes from expertise that hasn’t yet been translated into something usable. That’s where clarity matters most.

Clarity isn’t about compromising meaning. It’s about making relevant meaning visible. It’s about anticipating questions, removing friction, and recognizing that people are often reading for action under pressure—while applying for services, meeting deadlines, or trying to make the right decision under duress.

When communication is clear:

• People act with confidence instead of hesitation.
• Errors and follow-up questions decrease.
• Staff spend less time explaining and more time serving.
• Trust builds—not through slogans, but through shared experience.

This is why I believe clarity is both a strategic and a human choice. For writers, clarity is an act of craft and care. For leaders, it’s an investment in alignment and efficiency. For clients and communities, it’s the difference between moving forward and getting stuck.

Plain language is often misunderstood as a writing style or a final editorial pass. In reality, it is a strategic tool that shapes how effectively an organization functions.

When plain language is applied early, it clarifies priorities, exposes gaps in thinking, and fosters alignment across teams. If a process can’t be explained clearly, it’s often because roles, decisions, or expectations aren’t clear themselves. Plain language makes those issues visible and can help correct them before they show up as errors, delays, or confusion for the people we serve.

A lightbulb and pencil emerging from a gear represent clarity of thought, intentional design, and clear writing working together.

Used strategically, plain language:

• Reduces risk by minimizing misinterpretation and rework
• Supports consistency across departments and channels
• Strengthens trust by making systems more transparent and navigable
• Speeds decision-making by clarifying actions, roles, and expectations
• Improves operational efficiency by reducing reliance on workarounds and supporting process documentation

This is why plain language belongs at the planning table, not just in editing cycles. It helps organizations design communication and processes that work together, instead of asking writing to compensate for unclear systems.

When leaders treat plain language as strategy, clarity becomes scalable. It’s no longer dependent on individual writers or one-off revisions—it becomes part of how work gets done.

As we move into this new year, I invite us to pause before publishing, launching, or rolling out the next “update” and ask:

• What does someone need to do after reading this?
• What might confuse or overwhelm them from the text?
• What might confuse or overwhelm them from the process or system behind the text?
• How can we make the text, process, and system easier to understand and use?

Considering the alignment between communication and processes has a compounding effect.

My hope for the year ahead is that we choose clarity not as a final polish, but as a starting point. Clarity starts with how we think and design processes, not how we edit sentences at the end. When processes are designed for the people who use them and writing about the processes is clear, everyone benefits.

Here’s to a year of fewer assumptions, better understanding, and work that moves us forward—clearly.

Clear Communication Can Formalize Operational Intelligence—Especially in Today’s Distributed Teams

“The path forward requires acknowledging a hard truth: you cannot manage what you do not understand, and you cannot understand what you have not bothered to document and internalize in knowledge management systems.” 

Jessica Talisman

Plain language is often described as communications refinement: shorter sentences, simpler words, fewer acronyms. That framing undersells its strategic value. When applied to process documentation, plain language functions as knowledge infrastructure—a way to surface, formalize, and transfer operational intelligence that would otherwise remain implicit, obscured, fragmented, or lost.

This is particularly true in offshore and distributed operations, where undocumented assumptions and “tribal knowledge”—unwritten know-how—quietly become sources of risk and inefficiency.

The Real Problem: Unclear Knowledge, Not Just Unclear Writing

Most organizations treat process documentation as a compliance artifact—something produced to satisfy ISO requirements or formulaic auditing steps. As a result, procedures often under-describe what to do and evade explaining why, when, or how decisions are actually made.

In offshore and distributed contexts, this gap is amplified. Onshore and in person teams rely on context built through proximity, informal conversations, and shared history. Offshore and remote teams inherit the tasks, but not the tacit knowledge and hallway troubleshooting that makes those tasks successful. The result is predictable:

• Repeated clarification requests across time zones
• Over-reliance on senior staff to interpret intent
• Inconsistent outcomes masked as “execution issues”
• Slow onboarding and fragile continuity when people leave

These are not communication failures. They are failures of knowledge capture.

Plain Language as a Tool for Making the Implicit Visible

Applied rigorously, plain language forces an organization to articulate what it actually knows—not what it assumes people will infer. The act of writing clearly exposes gaps between documented processes and lived reality.

Specifically, plain language accelerates procedural knowledge formalization by requiring teams to:

• Break work into discrete, observable steps
• Identify decision points, conditions, and exceptions
• Make assumptions explicit rather than implied
• Distinguish between rules, guidance, and judgment calls
• Use consistent structures and terminology across procedures

In other words, plain language reverse-engineers expertise. It extracts what experienced staff “just know” and makes it transferable.

A quick story: The Secretary Who Took the System With Her

A common knowledge-management anecdote tells of an office where a long-serving secretary maintained a flawless filing system. Documents were always easy to get—until she left. Overnight, retrieval became nearly impossible. The files were still there, but the holder of the logic behind them was not.

This story endures because it captures a universal organizational risk: processes can appear stable while being fundamentally non-transferable. When expertise remains implicit, the system walks out the door with the expert.

Plain language addresses this failure mode by forcing organizations to make their reasoning explicit—so processes remain usable even when people move on.

Operational Benefits for Teams

For all teams, and especially for distributed teams, clear, plain-language process documentation delivers concrete operational advantages:

• Reduced dependency on synchronous communication. Teams can execute independently without waiting for clarification calls or Slack threads.
• Faster, more reliable onboarding. New hires learn the process as it actually works, not as it is informally explained.
• Clearer accountability. Documentation defines what “done” means, reducing ambiguity and rework.
• Continuous improvement from the front line. When processes are intelligible, teams can identify inefficiencies themselves rather than simply executing flawed workflows.

The shift is subtle but significant: hollow, modular, and virtual organizations can rebuild the link to core processes.

Where the RAISE™ Framework Becomes Operational

This is where a structured framework such as RAISE™ moves plain language beyond generic training and into operational design:

• Relevance
  Does the process capture what people actually need to know to do the work, or just
  That the organization thinks should be documented?
• Access
  Can someone in Manila or Bangalore execute the process without relying on informal escalation to a head office?
• Intelligibility
  Are decision points defined clearly enough that two people would reach the same conclusion?
• Suitability
  Does the documentation reflect how the work truly flows for users, rather than how it was imagined during design?
• Efficacy
  Can the organization measure whether clearer processes reduced errors, questions, or rework?

Using plain language within this framework turns documentation into a testable operational asset rather than static text.

Complaints and Feedback as Diagnostic Signals

One underused input into this work is complaint and feedback language. Complaints are rarely just emotional reactions; they often point directly to where documented processes diverge from reality. When people say, “This step doesn’t make sense,” or “We always have to ask for clarification,” they are identifying knowledge gaps.

Analyzed systematically, this type of language becomes a diagnostic tool for process improvement—highlighting where assumptions are unstated, decision logic is missing, or responsibilities are unclear.

A Different Kind of Deliverable

Positioned as a bridge towards procedural knowledge, the outcome of plain language work is not simply “clearer documents,” but deliverables that leverage clarity towards a stronger culture:

• Decision maps showing where expertise is actually applied
• Knowledge-gap analyses that identify undocumented assumptions
• Standardized procedures that function across geographies and experience levels
• Measurable reductions in clarification requests, escalations, and rework

This reframes plain language as organizational infrastructure—a way to preserve institutional knowledge, enable scale, and reduce operational risk.

From Communication Polish to Operational Intelligence

When plain language is treated as a strategic capability, it becomes a lever for knowledge management, helping organizations capture what they know, make it usable across boundaries, and ensure that expertise does not remain locked in individual heads or local contexts.

In distributed operations, that shift is not optional. It is foundational.

Where Does Plain Language End and Editorial Style Begin? And Why Your Organization Needs Two Separate Guides

A recent fabulous Plain Canada Clair webinar about style guides sparked conversation about the confusion many organizations face:
How much should a plain language guide cover, and when should editorial guidance take over?

The short answer is that a plain language guide should help people make writing understandable, while a style guide should help people make writing consistent.
Trying to combine the two usually dilutes both.

What a Plain Language Guide Is—and Is Not

A plain language guide exists to help writers and reviewers answer one core question: Will the intended audience understand this? It should cover the decision-making aspects that affect clarity and usability.

What belongs in a Plain Language Guide

• How to identify your audience and their information needs,
• How to structure information logically and support cognitive processing (see this comma story),
• When and how to define terms,
• Where and how to support content with visuals, tables, and alternative formats,
• What techniques to use for evaluating clarity and actionability (testing, peer review, heuristics),
• What accessibility considerations matter for the organization, including multilingual writing and localization for cross-cultural audiences.

These are decisions that affect meaning, comprehension, and user success.

What does not belong in a Plain Language Guide

• Whether you capitalize job titles,
• Whether you use % or “percent,”
• Whether you use serial commas,
• Whether you spell out numbers one through nine,
• How you write date formats (ok, if you localize you may need to remind people in your plain language guide that formats vary—and refer them to the appropriate style rule!).

These issues matter—but they don’t affect comprehension in the same way. They affect uniformity and brand identity. And that’s the job of an editorial style guide.

The Purpose of an Editorial Style Guide

An editorial style guide is your organization’s “house rules.” Its job is to ensure consistency to:

• Reduce cognitive friction,
• Build trust,
• Support efficiency for writers and editors,
• Protect brand identity,
• Reduce ambiguity in legal and policy documents through predictable use of grammar (see this comma story).

What belongs in an Editorial Style Guide

• Capitalization and punctuation rules
• Spelling preferences
• Number formatting
• Abbreviations and acronyms
• Tone and voice
• Formatting conventions
• Citations and references
• Templates, boilerplate, and standard language (which should be done in plain language!)

These decisions don’t require audience testing or cognitive heuristics—they require specifications.

What about glossaries? OK, yes, terminology can be tricky: preferred terms and banned terms go in the style guide. Definitions of brand terms go in the style guide. Guidelines for defining terms go in the plain language guide.

Why Combining Them Causes Problems

When organizations blend the two, they typically end up with a document that:

• is too long for writers to use,
• buries high-impact clarity guidance under technical guidance,
• forces plain language reviewers to argue about punctuation instead of reader needs,
• makes training more confusing, not less.

Worse, it sends the message that “plain language = grammar rules,” which is… exactly the opposite of plain language’s purpose. For a style guide, grammar is the goal. For plain language, grammar is the means.

Plain language is about helping people understand information so they can act on it. Editorial style is about helping organizations communicate consistently so readers can move past decoding to interpreting messages. Those goals are not the same.

The Sweet Spot: Two Guides That Work Together

A modern communication ecosystem works best when you have:

1) A Plain Language Guide

A practical document that teaches writers how to think clearly and express thoughts . It should be short, actionable, and focused on communication goals and user-centered decision-making.

2) An Editorial Style Guide

A reference document for editorial decisions—for look-up rather than instruction.

3) Cross-references between them

For example:

“For rules on capitalization, see the Editorial Style Guide.”
“If a technical term must be used, follow the Plain Language Guide’s approach for defining terms.”

This keeps each guide focused and functional, while making the relationship between them clear.

What Should Go Where? A Quick Heuristic

Ask this: Is this about whether readers will understand the content?

If yes → Plain Language Guide

Or: Is this about whether writers will produce predictable-looking content?

If yes → Editorial Style Guide

It’s that simple—and that powerful.

Here’s a comparison with coding. (If you never tried, here’s a very short Hello World hands-on–technically markup and not programming, but it illustrates function versus convention: change red to GREEN as background color and run it.)

• Plain language = the logic and architecture of your communication, like a programming language.

• Style guide = the conventions and formatting used to express it, like case choices for code.

Honor the Purpose of Each Tool

Plain language and editorial style are partners, not competitors. One helps you make sense. The other helps you look like you belong to the same organization. When each guide does its own job, writers spend less time debating commas and more time ensuring readers understand the information they need to navigate systems, make decisions, and participate fully.

Plain language opens doors. Editorial style keeps the hallway tidy. You need both.

—-

P.S.: A Quick Comma+ Story

Remember the “5-Million Dollar Comma” case? It was a dispute in the State of Maine involving overtime pay exemptions and the tiny punctuation mark—or, more accurately, the lack thereof in: “marketing, storing, packing for shipment or distribution.” The missing comma AND the missing parallel structure between “distribution” as a noun and the gerunds on the list (-ing forms) convinced the court that the language was sufficiently ambiguous to grant drivers (who did the distribution) 5 years of overtime pay. The truck drivers argued they “distributed” goods but did no “packaging for shipment or distribution” (interpreted as a single activity), so the exemption should not apply to them!

Both editorial style and plain language choices matter.
Back to Plain Language Guide Section. Back to Style Guide Section.

Today marks an exciting moment in the trajectory of plain language: the European Parliament has officially renamed its translation service the Directorate-General for Translation and Clear Language.

Beyond the institutional news, this change reflects something Plainlii has championed from the start: plain language is not a political stance — it’s a democratic essential.

A Growing Movement Toward Clarity

Across governments and organizations, plain language is no longer seen as an optional communication style or a kindness reserved for newcomers or vulnerable groups. It is becoming a pillar of democratic participation, an essential part of public trust, and a practical tool for good governance and effective business.

The European Parliament’s decision to explicitly include Clear Language in its official name marks a milestone in this trajectory — a sign that clarity, accessibility, and transparency are not afterthoughts but core responsibilities.

Plain Language Has No Political Color

Plain Language has no political color. It’s a tool that serves everyone — regardless of party affiliation or ideology.

When government agencies, organizations, and businesses communicate clearly, they build trust across the political spectrum. Plain language removes barriers that prevent people from understanding their rights, fulfilling obligations, and taking part in civic life.

In the private sector, clear communication:

• builds customer loyalty
• prevents disputes
• reduces operational complexity
• and saves time and money

Clarity benefits:

• Conservatives who want efficient, accountable institutions
• Progressives advocating for accessible services
• Independents seeking transparency in decision-making
• All people who deserve to understand information that affects their lives

Plain language works because it belongs to no one — and everyone.

Why the European Parliament’s Move Matters

The Parliament’s new name signals that plain language is becoming embedded in the very structure of European democracy.

It acknowledges that:

• translation and comprehension must go hand in hand
• multilingual democracy depends on accessibility
• citizens deserve information they can understand immediately
• clarity is essential for trust, equity, and democratic legitimacy

This isn’t branding. It’s an institutional shift — and a powerful example for governments worldwide.

Pomp and Gobbledygook Close Doors. Plain Language Opens Them.

Pompous and dense writing exclude rather than informs, and at best gives “the illusion of having learned” (see a Dr. Fox Experiment, paper and video) . Bad writing allows bad actors to hide harmful terms and gives pedants a

space to mask their ignorance. This happens both in public-facing communication and in technical documents in which writing becomes unnecessarily complicated.

Technical complexity is not the enemy. Unnecessary opacity is.

Subject-matter experts need precision, and focused fields genuinely require specialized terminology. But too often, technical communication becomes dense by habit, not necessity — written to impress peers rather than communicate. Internally, this breeds confusion, slows decision-making, and creates silos where only a few people truly understand what’s going on.

Meanwhile, outside of expert circles, people sometimes use jargon-laden lay language — not because it’s clearer, but because it sounds authoritative. The effect is the same: it shuts people out.

Plain language does the opposite:

• it fosters trust
• it promotes accountability
• it strengthens civic participation
• it empowers both majority and minority voices
• it supports informed decision-making inside organizations and industries
• it helps experts communicate accurately and accessibly without sacrificing precision

Good governance and good business both require informed participants — whether those participants are citizens, customers, colleagues, or technical stakeholders.

Plain language is how we get there — together.

Clarity Is the Future

At Plainlii, we see the European Parliament’s decision as a sign of what’s ahead: a world where clarity is expected, not exceptional — where people are treated with respect through communication they can understand.

Whether someone is a newcomer or a lifelong resident, multilingual or monolingual, highly educated or learning as they go — everyone deserves clarity.

Plain language isn’t political. It isn’t ideological. It’s fundamental.

Good communication doesn’t divide; it connects.

Plain language is about thinking clearly and expressing ideas in a fitting style for the audience. Above all, it’s a commitment to respect and shared understanding in business and civic life.

Different frameworks inevitably reflect the emphasis placed on different aspects of communication. ISO 24495-1:2023 organizes its guidance around four governing principles—relevant, findable, understandable, and usable—with “understandable” encompassing a wide range of linguistic and structural considerations, from wording to tone to cohesion. This structure serves the purpose of the standard, which is to provide a broad, outcome-based framework for authors across contexts. My plain language framework differs from  ISO 24495-1:2023 because it expands the four principles into five, grouped in my trademarked RAISE™ framework, which includes Relevance, Access, Intelligibility, Suitability, and Efficacy.

Unpacking “Understandable” in a Plain Language Framework

In my own practice, I have found it helpful to unpack “understandable” into the two distinct dimensions of Intelligibility and Suitability. I separate these not to diverge from the standard but to make explicit two linguistic aspects that require different kinds of decisions from authors—and which, while not discrete or sequential, can build on each other. So, RAISE™ offers a practical way to operationalize two linguistic dimensions at the heart of clear communication: how meaning is structured and how expression fits the audience, making them more visible and actionable for writers.

Intelligibility refers to what linguists call textuality: the construction of meaning through grammaticality, cohesion, and coherence. While ISO includes cohesion as a guideline under the Understandable principle (5.3.8), coherence—how ideas hang together logically and conceptually—deserves equal visibility, if not more! Cohesion and coherence interact to create clarity of thought, and the challenges involved in maintaining them differ markedly from those involved in shaping tone or choosing vocabulary. Treating intelligibility as its own principle highlights the cognitive work of structuring ideas so readers can follow the logic without undue inference.

Suitability, by contrast, involves adequacy: aligning tone, register, and stylistic choices with the needs, expectations, and cultural context of the intended audience, and the media and channels of communication. ISO situates tone within Understandable (5.3.7) as part of projecting respect and inclusiveness, but, in practice, style involves a broader set of interpersonal and contextual decisions. These choices carry substantial weight in whether readers feel seen, respected, and invited into the text as valid interlocutors.

Separating intelligibility and suitability is thus a practical decision rooted in how writers think and work. Authors routinely struggle with structure and idea-flow on the one hand, and with tone, voice, and audience fit on the other. When these are treated as one principle, the risk is that one dimension, often coherence, receives less attention than it needs for the text to succeed—especially in longer texts required for explanations and learning.

How Quadrants Support a Plain Language Framework

In the Visual Plain Language Guide (find the Guide here), I map written communication onto four quadrants defined by two intersecting dimensions: clarity of thought (cohesion + coherence) and adequacy of expression (tone, register, vocabulary). These dimensions generate four distinct types of text: clear technical communication, clear lay communication, poor technical writing, and poor non-technical or lay writing—what we often call gobbledygook.

This quadrant view makes one point especially visible: clear thinking is transferable. When the underlying ideas are coherent and well-sequenced, it becomes possible to create both a clear technical version and a clear lay version from the same conceptual core. Structure and logic remain stable; only the expression layer changes, as it were.

By contrast, when a document lands in the “poor” half of the chart—whether technical or lay—it usually signals problems in the idea layer, not just the wording. No amount of de-jargoning will fix incoherent content because the problem isn’t in the lexicon; it’s the absence of a rationale.

This quadrant model therefore underscores why I separate intelligibility from suitability in my five-principle framework. Cohesion and coherence give you the internal architecture that supports multiple versions for multiple audiences. Tone and register then allow you to adapt that architecture for readers with different backgrounds, needs, or levels of expertise. Clear thinking first; clear expression follows.

Why Clear Thinking Matters in a Plain Language Framework

In this framework, clarity of thought is essential for reader understanding and it also becomes a powerful tool when creating different versions of the same content for multiple audiences. When the underlying ideas are coherent (logically sequenced and structurally sound), it becomes much easier to adapt the message for audiences with different levels of expertise, cultural backgrounds, or communication needs. A well-formed conceptual architecture allows you to adjust vocabulary, tone, and examples without having to rebuild the message each time. In other words, textuality provides the stable “skeleton” of meaning, and adequacy lets you tailor the “surface” for each group. This separation of layers is particularly useful in multilingual contexts, regulated environments, and collaborative projects where stakeholders require variations of the same content. Starting with a clear, coherent core reduces duplication of effort and results in versions that remain aligned in purpose and substance while meeting readers where they are.

A Clearer Tool for Writers

Ultimately, I use five principles not to complicate the ISO model but to give authors a clearer diagnostic tool. Distinguishing clarity of thought (intelligibility) from kindness of expression (suitability) helps writers recognize which choices affect the logic of the message and which affect its relationship with readers. Both contribute to understanding, but they do so through different mechanisms. Making that distinction explicit supports better planning, drafting, and revising—while remaining fully compatible with the intent and scope of ISO 24495.

Note: Access in the RAISE™ Framework includes organization of the message, structure of the document, multimedia supports, and digital accessibility as defined by WCAG Standards.

This post walks through how the guide came to life: the problems it aimed to solve, the research behind it, and the design decisions that shaped the final framework.

Why I Created the Visual Plain Language Guide

The guide began from a simple question I kept getting in workshops, client projects, and conversations with other communicators:

“Plain language makes sense in theory — but how do I see it?”

Plain language is often taught as a set of writing rules, but what I witnessed repeatedly were moments of visual confusion:

• text structured in ways readers couldn’t navigate

• ideas buried because the hierarchy didn’t guide the eye

• information mapped in the writer’s mind, but not for the reader’s brain

Those who know me a little know I am BIG on cohesion and coherence–the visible links and the underlying clarity of thought that go into good writing. So I set out to show, even if a little, how these come to life. And I started sketching. I started with my existing RAISE™ wheel and it all evolved from there.

Those sketches became motifs: the target for goals (page 9), the puzzle pieces for flow (page 22), the hand and heart for empathy (page 23). Eventually, they evolved into a unified visual language to communicate the concepts of plain language — not within design, but through design.

A Visual Guide — Not a Design Guide

One thing I want readers to understand is: This isn’t a guide about visual design. It’s a guide that uses visual design to teach plain language.

Every icon and layout choice serves a conceptual purpose:

• The RAISE™ principles wheel (page 6) represents balance and interplay.

• The quadrants of clarity (page 7) visualize the differences in clarity and gobbledygook for lay and specialized communication.

• The 10-step circular diagram (page 8) positions clarity as an iterative, non-linear process.

I didn’t set out to create a “pretty PDF.” I set out to make abstract principles visible and memorable. In the Visual Plain Language Guide, each visual is tied to a principle or technique for making communication easier to find, understand, and use.

How the Guide Took Shape

Here’s the development journey behind the scenes:

1. Grounding the guide in international standards

Years before the ISO 24495-1 Plain Language Standard existed, I developed the RAISE™ model—Relevance, Access, Intelligibility, Suitability, and Efficacy—as a practical way to explain what makes communication clear. It grew out of years of observing where communication breaks down and noticing that “understanding” isn’t one thing; it’s a combination of how clearly something is expressed (intelligibility) and how well it fits the reader’s needs and context (suitability).

When ISO began drafting what would become the first international plain language standard, I was invited to join the technical committee responsible for shaping it. It was remarkable to see how closely the developing ISO principles aligned with the structure I had already been using in RAISE™—even though the model predated the standard.

The only real difference is conceptual emphasis. ISO includes “Understandable” as one of its five principles, while in RAISE™ that idea unfolds into its two essential dimensions:

• Intelligibility — the clarity and precision of the expression

• Suitability — the appropriateness and resonance of the style for the intended readers

Together, they capture what understanding actually requires in real-world communication: clarity expressed in a style that meets readers where they are.

Because of this natural alignment, RAISE™ maps cleanly to the ISO standard, allowing the guide to stand on an internationally recognized foundation while preserving the nuance, depth, and reader-centered structure that originally inspired RAISE™.

2. Turning research into approachable visuals

Once I knew the guide needed to show plain language, not just explain it, I returned to the research. Studies on cognitive load, reading behavior, and visual processing all point to the same truth: people understand faster when information is paired with clear, meaningful visuals. Not decorative visuals — but visuals that orient, anchor, and reinforce meaning.

So I began developing a visual vocabulary for the guide: a system of icons, metaphors, colors, and spatial patterns that help readers grasp concepts at a glance. Every visual decision had a purpose:

• The magnifying glass + lightbulb + gear (page 4) conveys “find, understand, use.”

• The audience icons (page 12) show diversity without over-specificity.

• The color palette leans friendly and modern — bright but soft, not childish.

The visuals aren’t decoration; they’re cognitive scaffolding.

3. Building a structure readers can follow at a glance

The guide mirrors the very principles it teaches:

• Clear sections (Goals → Readers → Structure → Design → Words →…)

• Consistent iconography

• Headings that double as meaning cues

• Logical flow from “thinking” steps to “crafting” steps to “refining” steps

This scaffolding is visible on nearly every page, especially the 10-step cycle on page 8 of the Visual Plain Language Guide.

4. Iterating through testing and feedback

Just as step 10 of the guide emphasizes Get Feedback (page 27), I moved through several cycles of:

• testing concepts with writers and editors

• adjusting language

• simplifying visuals

• refining metaphors

• tweaking contrast and spacing

Each iteration made the guide more coherent, lighter, and more intuitively navigable.

Why the Guide Looks Playful

Plain language can feel rigid or even simplistic. I wanted to challenge that perception.

That’s why the guide uses:

• rounded icons, not rigid lines
• asymmetric silhouettes, giving movement and energy
• vivid colors that signal friendliness
• visual metaphors that feel human, like the helping hand or warm lightbulb

This visual tone embodies the empathy at the heart of plain language (step 8, page 23).

Icon System Inside Visual Plain Language Guide

Here are the icons for each of the ten steps of the Visual Plain Language Guide.

What the Visual Plain Language Guide Aims to Do

Ultimately, the guide is meant to:

• make plain language principles more teachable

• help teams create better documents, services, and policies

• support trust, clarity, and usability (page 29)

• show that communication can be both rigorous and inviting

In other words, the guide exists to turn the journey from ideas to results (page 33) into something clearer, lighter, and more human.