Content Validation Tool
Technical writers found out a page was hard to find, missing context or too wordy only after review. I designed a tool that shows them where, before it’s published.
Role
UX designer: research, AI prototype, interaction design
Team
Timeline
Outcome
Names, data and screens are modified for confidentiality. The process and my contribution are accurate.
Every score breaks down into checks, and every failing check points to the passage behind it. Open Contextuality or Conciseness and select a check, add a keyword and re-analyze, or start a new evaluation.
Searchability
Can people find this page?
- Google rank#4
- Keyword in title“click”
- Keyword in meta description“click”
- Keyword in headings“click”
- Keyword density2.8%
Contextuality
Does the page give readers enough context to act?
- User’s background0/30
- Purpose25/25
- Environment25/25
- Contextual anchors10/20
Conciseness
Is the page quick to read and scan?
- Lengthy sentences3/10
- Wordy paragraphs1/5
- Redundancy2
- Abbreviations not explained2
- Characters in words8
Three questions a reader asks, each with its own score and checks. Every card opens the same issue in the workspace above, outlined on the page.
Quality depended on who reviewed the page
Writers checked their own pages by hand, then waited on subject-matter experts whose feedback varied from reviewer to reviewer.
Across hundreds of documentation pages, that made quality hard to keep consistent. Problems that decide whether a reader succeeds, such as a page nobody can find, missing context or dense writing, were the hardest to spot by eye. They surfaced late, in repeated revision cycles
- CuriousDefineCuriousScopes the topic
- FocusedDraftFocusedWrites the page
- UncertainSelf-reviewUncertainChecks by hand, no shared standard
- AnxiousSME reviewAnxiousFeedback depends on the reviewer
- FrustratedReviseFrustratedRepeats the cycle
- UnsurePublishUnsureShips without a quality signal
Confidence drops at the three review steps, exactly where a shared quality signal was missing.
Writers started confident and lost it in review. The journey map from interviews: every dip sits in a manual, reviewer-dependent step.
I took the framework from interviews to interface
I ran semi-structured interviews and workflow analysis with technical writers, built the custom GPT prototype that tested the scoring framework, and designed the evaluation experience with one other UX designer and three writers over 2 months.
Help had to arrive before publishing
I ran semi-structured interviews and workflow analysis with technical writers, built the custom GPT prototype that tested the scoring framework, and designed the evaluation experience with one other UX designer and three writers over 2 months.
Drafts have no search data
Writers needed help before a page went live, but the first scoring model judged Searchability by search position and existing search behaviour, which only exist after publishing. So the Searchability matrix was rebuilt around static signals a draft already has: user-style titles, synonym and exact-term coverage, common-question coverage, upfront summaries and scan-friendly headings
A score can’t replace a reader’s judgement
Research on technical communication warns that readability formulas capture surface features, not how readers understand a page. So no dimension ends at a number: each score is the sum of weighted, named checks, each with a status, a reason and a suggestion, and the writer decides what to change.
The first matrix only worked once it was too late to help. Switch to “Published page” to see why it looked fine in testing.
A score is only useful if a writer can take it apart. Contextuality’s 60% is four weighted checks; the missing 30 points are one absent “who this is for” line.
I moved the feedback from a text report onto the page
My first prototype found the right problems but left writers to work out where they were.
Scan-first workflow over a generate-on-request GPT
I built a custom GPT that scored pages against the matrix and suggested fixes. The scores were measurable and the issues were real, but they arrived as text, so writers had to hunt for the sentence each comment meant. A Chrome plugin then put the breakdown beside the page, and the final workspace went further: it shows the analyzed page beside the checks, and selecting a failing check outlines the exact passage. What I gave up: the speed of a single generated report.
Rejected - Custom GPT: right issue, no location
• The intended audience is not stated. • Contextual anchors are weak in the steps.
Every answer sends the writer back to search the page.
Chosen - The check points at the passage
This documentation describes how to capture screenshots using your web browser’s built-in tools and keyboard shortcuts. Follow the steps in this guide to save images from any webpage…
A comment that points at the sentence gets fixed; a comment in a report gets searched for. The final tool outlines the passage the moment a writer selects the failing check.
Writers can check a page before review, not after it
Status: Internal review platform
The review loop changed shape. Instead of finding problems through rounds of self-review and SME comments, writers analyze a draft, see each issue in place, fix it and re-analyze before anyone else reads it.
Before: reviewer-led
- Draft the page
- Self-review by eye
- Wait for SME comments
- Revise
Repeat until reviewers agree
After: writer-led
- Draft the page
- Analyze the draft
- See each issue in place
- Fix and re-analyze
Repeat until the checks pass, then send for review
Outcome
Content Validation became the internal review platform for help content. A writer pastes a URL and gets Searchability, Contextuality and Conciseness scores, each broken into named checks, with every failing check outlined on the page itself.
That changed who finds the problems. Before, a page reached subject-matter experts with its gaps still in it, and quality depended on who happened to review it. Now writers fix a missing audience line, an over-long sentence or a keyword missing from the title themselves, and re-analyze until the checks pass. SME review can then focus on technical accuracy instead of catching problems a tool can spot.