Explanatory Images and Asset Specifications

Start With the Buyer’s Comparison Task

The first brief field should describe a decision visible on the page. “Create a pricing diagram” is too broad because it does not identify the information at risk.

Use a task statement that names the relevant plan column, feature row, add-on block, FAQ answer, or adjacent section. The statement should also identify the comparison unit, such as availability, quantity, billing period, dependency, exclusion, or scope.

• Compare which features appear in each plan.
• Identify the usage limit that changes between adjacent tiers.
• Determine whether an add-on requires a particular plan.
• Distinguish included capacity from separately purchased capacity.
• Understand whether an FAQ exception changes the table’s general rule.
• Recognize what a trust cue applies to without confusing it with a plan feature.

Do not begin with icons, arrows, or an annotated screenshot. Those choices describe the presentation, not the comparison the asset must preserve.

What Belongs in the Brief

A brief-ready specification connects the buyer task to production and review requirements. The following fields give another person enough context to produce or inspect the asset without guessing.

Page Context

Name the section where the asset will appear and the content directly before and after it. State whether the image supplements a pricing table, replaces part of one, expands an add-on rule, or illustrates an FAQ answer.

Nearby text may already provide part of the explanation. Record that relationship so the asset does not silently contradict the page or introduce a second terminology system.

Comparison Objective

Write one sentence explaining what a buyer should be able to compare after reviewing the asset. Keep the objective observable.

A buyer can identify which base plans support the audit-log add-on and whether another add-on is required first.

This is more useful than “make add-ons easier to understand.” The narrower statement gives reviewers a specific relationship to inspect in the table, asset, and surrounding copy.

Information Inventory

List every plan, feature, usage limit, add-on, dependency, exclusion, and subscription condition represented by the asset. Research on SaaS pricing models provides useful vocabulary for separating these objects, but it does not prescribe how they should be drawn.

A plan inclusion, a numeric usage limit, and an optional add-on are different pricing objects. Combining them under one generic checkmark can hide the distinction a buyer needs. For technical offers, quota, rate, periodicity, and capacity may also require separate labels when the offer exposes those differences.

Required Relationships

Record the relationships that must survive every version of the asset:

• Feature included in a plan.
• Feature unavailable in a plan.
• Add-on available only with specified plans.
• Add-on dependent on another add-on.
• Add-on excluded from a particular plan.
• Usage limit measured over a stated period.
• FAQ exception applying to one tier rather than the full offer.

A relationship should not depend only on position or color. If a red line means “incompatible,” the meaning also needs a label, legend, pattern, or nearby explanation.

Visual Hierarchy

State which information must be read first, second, and third. The hierarchy should follow the buyer’s comparison sequence rather than the internal structure of the product.

1. Identify the relevant plan.
2. Locate the feature or add-on.
3. Read the inclusion, limit, dependency, or exclusion.
4. Check the associated condition or exception.

This sequence can guide headings, labels, connectors, and grouping. It also gives the mobile pass a defined reading order.

Match the Specification to the Asset Type

Different pricing-page workstreams fail in different ways. The brief should focus on the information most likely to become ambiguous for each asset.

Comparison Table Visuals

A comparison table visual may include tier cues, feature icons, annotations, grouped feature families, or expanded explanations. Its purpose is to preserve distinctions across plan columns and feature rows.

Specify:

• Which plan columns are being compared.
• Which feature groups control the scan order.
• What each icon, pattern, or annotation means.
• How included features differ from limited features.
• Where quantities and measurement periods appear.
• How exceptions connect to the correct row.
• What happens when columns collapse on mobile.

Avoid using the same checkmark for “included,” “available with a limit,” and “available as an add-on.” The shortcut reduces visual variation but erases pricing distinctions.

During a mobile pricing-table review, inspect whether the plan name remains associated with every value. A stack of detached feature values is not enough. The buyer must still know which plan, feature, quantity, and condition belong together.

Add-On Blocks and Dependency Diagrams

An add-on block becomes difficult to scan when eligibility, dependency, exclusion, and price context appear as one paragraph. An add-on dependency diagram can separate these relationships, but only if the brief defines them first.

Brief a SaaS Pricing Page Add-On Dependency Diagram

Start with a bounded statement:

Show which base plans allow each add-on, which add-ons require another purchase, and which combinations are unavailable.

Inventory the objects:

• Base plans.
• Add-ons.
• Required add-ons.
• Excluded combinations.
• Applicable account or subscription conditions.
• Any usage limit relevant to the dependency.

Define a syntax before production. Solid connectors might indicate eligibility, while labeled connectors identify a dependency. Do not rely on connector style alone; record each relationship in text as well.

The specification should answer:

• Can an add-on be purchased without a base plan?
• Is the dependency mandatory or merely recommended?
• Does eligibility change by tier?
• Does one add-on exclude another?
• Is the rule account-wide or limited to certain users?
• Is the add-on included, available, or separately priced?
• Does an FAQ modify the rule shown in the diagram?

Keep the source wording aligned across the diagram, pricing table, and FAQ. “Requires Business” and “available on Business” can describe different conditions. The brief should not treat them as interchangeable.

Mobile Fallback for a Dependency Diagram

A desktop node-and-connector layout may become difficult to scan when reduced. Serving a smaller version of the same composition can preserve pixels while losing labels and relationships.

A mobile specification can instead require:

• One add-on per grouped section.
• Eligible plans listed directly below its name.
• Dependencies written as labeled statements.
• Exclusions separated from requirements.
• A stable reading order matching the desktop meaning.
• A nearby text explanation containing every essential relationship.

During the mobile pass, compare the fallback against the relationship inventory. Every required plan, dependency, and exclusion should remain present, even when the composition changes.

FAQ Assets

An FAQ asset should clarify an answer that benefits from a visual relationship, sequence, or boundary. It should not repeat a simple sentence as decoration.

Suitable tasks may include:

• Showing how an account-level limit is shared.
• Distinguishing base-plan access from add-on access.
• Explaining the order of a plan and add-on selection.
• Locating an exception within a broader pricing rule.

Record which sentence in the FAQ remains authoritative. If the image and answer are revised separately, the brief should identify who verifies that they still match before publishing.

On mobile, inspect whether the asset remains close enough to the relevant answer. An illustration separated from its heading or collapsed under another question can lose its context.

Trust Cues

Trust cues may include security marks, customer marks, review graphics, or short evidence-related annotations. Their specification should state what the cue refers to and where its supporting information comes from.

Do not let a cue visually attach itself to the wrong claim. A mark placed inside one plan column may appear to describe that plan alone, even when it applies to the product more broadly.

For each trust cue, record:

• The exact subject of the cue.
• Whether it applies to one plan, several plans, or the full offer.
• The approved label.
• The source asset and provenance.
• Required usage conditions.
• The nearby text that provides context.
• The mobile placement.

The review concerns visible scope and source records. A trust cue does not establish a business outcome or broader authority.

Specify Image Purpose and Text Alternatives

Image classification should reflect the asset’s function on the page, not its file type. Guidance from W3C WAI distinguishes informative, decorative, functional, and complex image purposes. That classification changes what the specification should request.

Decorative Images

A decorative image contributes no pricing information and performs no interface function. Its removal would not change the comparison task.

The brief can identify it as decorative and require that it not introduce unexplained labels, symbols, or product states. An image stops being purely decorative when buyers must inspect it to understand a plan difference.

Informative Images

An informative image communicates a concise fact or concept. Its text alternative can usually express the relevant information without reproducing every visual detail.

For an image alt text pricing page field, specify the intended meaning rather than only a filename or appearance description. “Three connected boxes” describes shapes. “Advanced reporting requires the Business plan and the Analytics add-on” conveys the pricing relationship.

Functional Images

A functional image acts as a control or command. Its accessible name should describe the action rather than the artwork. This matters when an icon opens plan detail, expands a feature group, or changes billing views.

The explanatory image brief need not absorb the full interaction specification. It should flag that the asset is functional and requires an interaction review.

Complex Explanatory Images

A complex asset contains several data points or relationships that cannot be captured in a short label. Examples include a pricing plan relationship diagram, a dense annotated comparison, or a multi-step add-on map.

For an accessible annotated diagram design, plan several layers:

• A concise identification of the diagram’s subject.
• A summary of its main comparison.
• A structured explanation of plans and relationships.
• Equivalent information in nearby text, a list, or an appropriate table.
• A reading order that does not depend on visual position.
• Labels that remain meaningful without color.
• A mobile treatment that preserves the same distinctions.

Research involving chart users can sharpen inspection questions about overall views, readable labels, legends, scalable content, underlying data, and tooltip placement. These observations concern charts and visualization access rather than SaaS pricing pages, so they should inform checks rather than serve as direct proof about a particular pricing asset.

Ask whether the diagram’s relationships remain available beyond its visual composition. Do not assume that one short label, one color system, or one automated description can carry every relationship in a complex asset.

Common Concept Mix-Ups

Responsive Image Versus Mobile Fallback

A responsive image is delivered according to display conditions. A mobile fallback is an editorial treatment that preserves meaning when the original composition no longer works.

The first is a delivery concern. The second is a comparison concern.

Alt Text Versus an Equivalent Explanation

Short alt text may identify an informative image. It may not be sufficient for a complex asset containing several plan relationships, limits, or dependencies.

The brief should state where the complete equivalent information appears. Do not force the entire diagram into one long image attribute without considering page structure and reading order.

Attribution Versus Permission

Attribution records who created an asset and how credit should appear under applicable terms. Permission depends on the actual source, license, restrictions, modifications, and intended use.

One does not replace the other.

Visual Consistency Versus Pricing Accuracy

Reusing one icon system can make rows appear consistent, but consistency does not justify merging different pricing states. Included, limited, optional, unavailable, and dependent should remain distinguishable.

Pricing accuracy comes first.

Planning Fields Versus Formal Assessment

Image classification, text alternatives, redundant encoding, responsive variants, and mobile checks are useful production requirements. Their presence in a brief does not by itself establish formal accessibility conformance.

Keep the planning claim narrow: the required information has been identified, represented, and checked in the specified page contexts.