Comparisons and decision criteria
Compare the options under the same conditions.
A useful comparison makes its criteria, evidence and limits visible. Give each option the same scope, then explain which reader conditions justify the recommendation.
Free learning from Semantec SEO.
Define the decision before choosing the columns.
A comparison helps when the reader must choose between options for a stated job. Begin with the job, the conditions that cannot change and the consequences of a poor choice. A table about “the best architecture” is underspecified until the audience, content, maintenance resources and required routes are known.
Write a decision sentence such as: “Choose a content structure for twelve established services, one editor and a need for both quick orientation and detailed service answers.” This fixes the object of the comparison. Do not compare an entire publishing strategy with a single navigation feature as if they were equivalent alternatives.
List conditions that rule an option out before applying preferences. A structure that cannot represent the required service distinctions is unsuitable even if its layout looks attractive. A structure requiring more ongoing review than the organization can supply may need to be simplified. These are constraints to investigate, not scores to invent.
Use comparable units and the same evidence boundary.
Give each option the same scope. Compare the same set of content, audience, language and operating period. A one-page orientation containing twelve short summaries cannot be presented as equivalent to twelve fully researched service explanations unless the missing depth is included in the comparison.
Use the same unit for every numerical claim. If a real project records editing time, define the task, editor experience, measurement period and included work. Distinguish one change to a shared component from manual edits across separate pages. Without observations, use a qualitative maintenance assessment and label it as an expectation.
Keep unknown values visible. “Not measured” differs from zero effort; “not supported by the current system” differs from impossible in every system. A blank cell should not invite readers to infer that an option performs badly. Explain missing evidence and how it affects the decision.
Choose criteria that can change the recommendation.
Use a criterion because it matters to the stated reader, not because it fills a row. Useful architecture criteria can include answer depth, direct access to a specific task, navigation effort, ownership clarity, duplication risk and the number of dependent records affected by an update.
Define what each criterion means before judging the options. “Easy to maintain” might mean one editor can find the owner of a fact and update all affected placements. “Clear navigation” might mean a visitor can distinguish services using meaningful labels. Neither phrase is a measured result until the relevant test has taken place.
Avoid adding closely related criteria simply to favor one option twice. For example, page count and number of separate page records can describe the same maintenance burden in this decision. Keep distinct concerns separate, and explain any weighting through the audience’s priorities rather than a concealed total.
Attach evidence to the cell it supports.
For a real comparison, record the source URL or file, date, version, exact observation and relevant qualification. A content inventory can support the number of distinct tasks. A system test can support a routing limitation. An interview can support a reader preference in its own sample. None automatically proves the other claims.
Use current product or technical documentation for supported features, then check the configuration in use. A feature available in one plan or version may be absent in another. If the evidence comes from a prototype, identify that prototype and preserve its limits. Do not call a proposed benefit an observed improvement.
Where a recommendation combines evidence with judgment, name both. “The inventory shows twelve distinct tasks; we recommend separate answer homes because one short orientation would omit their conditions” is inspectable. “This structure is better for SEO” hides the reason and promises more than the evidence establishes.
Worked comparison: two options under one set of constraints.
This fictional example compares editorial choices, not measured websites. The site explains twelve services with distinct eligibility conditions. One editor maintains it. Readers need an overview and a direct route to the relevant service. The existing content can support twelve different answers. No traffic, conversion or ranking improvement is asserted.
Option A uses one long service page with an overview and twelve full anchored passages. Option B uses a short overview linking to twelve dedicated service pages. Both must preserve the same twelve service answers and the same qualifications. A thin one-page summary is excluded because it would change the content scope.
| Criterion | One long page | Overview and separate pages |
|---|---|---|
| Orientation | One document exposes the complete set, but readers must distinguish a long sequence. | The overview can summarize the choices, with a separate visit for detail. |
| Direct task access | Anchor links can point to a service passage; the target and navigation need testing. | A service URL can own the detailed task and receive contextual links. |
| Fact ownership | All service text lives in one record; repeated shared statements still need an owner. | Each service has an owner; shared facts need a central source and update list. |
| Maintenance | One page record can simplify locating the content, but a small edit still affects that large document. | Changes can be limited to a service page, while navigation and shared facts may affect more records. |
| Reading conditions | Long-page orientation, headings and in-page navigation need review. | Repeated navigation and transitions between overview and detail need review. |
| Evidence state | Qualitative expectations only; no user test or time study. | Qualitative expectations only; no user test or time study. |
The recommendation in this scenario is Option B because the fictional brief requires distinct detailed tasks and direct destinations. It is conditional on keeping the overview useful, avoiding duplicate service introductions and assigning shared facts to an accountable source. Option A remains a plausible alternative if the answers are tightly connected and testing shows readers can reach the needed passage.
Show the tradeoff instead of hiding it in a winner badge.
A recommendation should say what the chosen option gains and what it makes harder. In the example, separate destinations improve the ability to assign one detailed answer home, but they add navigation and more page records. The page should explain who accepts that tradeoff and what must be maintained.
If the audience changes, rerun the decision. A site with two short related services, infrequent updates and a reader task requiring both answers may justify a single page. A large catalogue with different conditions may require a different model. The worked recommendation does not transfer unchanged just because the same labels appear.
Do not assign a universal numerical score to qualitative judgments without a defined method. If decision makers use weights, publish the criteria, scale, evidence and weighting rationale. Show how a different priority changes the result. A precise total cannot compensate for a false input or an omitted hard constraint.
Keep the comparison readable and accessible.
A table suits parallel criteria because each row asks the same question about each option. Use a meaningful caption, clear column and row headers and ordinary words in the cells. Keep qualifications beside the claim they limit. Do not rely on green and red alone to communicate a recommendation.
The W3C requirements for information and relationships address making conveyed structure available to users and software. On an implemented page, inspect how headers relate to values and how the comparison reads in a meaningful order. Styling alone does not establish accessibility.
On a narrow screen, keep the relation between criterion and option intact. Short parallel cells can wrap; a genuinely wide matrix may need an identified scroll region and keyboard testing. Do not turn necessary conditions into a tiny raster image. Decorative illustrations can accompany the decision while the evidence remains native text.
Set a review trigger and record the limits.
Keep a comparison record with the decision, options, common constraints, sources, unmeasured assumptions, recommendation, accepted tradeoffs, reviewer and review date. Revisit it when the audience, content scope, system or evidence changes. A dated source can become stale even when the comparison still looks polished.
Before release, ask a reader to explain what would make each option suitable. If they can only repeat the winner label, the comparison may be hiding its criteria. Check that a reasonable reader with different conditions can recognize the limits of the recommendation and choose a more relevant route.
Google’s content usefulness questions offer a broad editorial check on the useful contribution. They do not prescribe this comparison method or guarantee a search display. Continue with the content writing hub or topical mapping hub. The learning overview connects the wider process.