AgentPresent Blog
The Table Is a Decision Surface, Not a Product Shelf
A live comparison on an iPad should be designed around what the client needs to decide, not around how many products or data fields an agent can fit on screen. A useful starting budget is one label column plus two or three alternatives. That is a presentation rule of thumb—not a universal device limit or a claim that e
The Table Is a Decision Surface, Not a Product Shelf
A live comparison on an iPad should be designed around what the client needs to decide, not around how many products or data fields an agent can fit on screen. A useful starting budget is one label column plus two or three alternatives. That is a presentation rule of thumb—not a universal device limit or a claim that every comparison should contain exactly the same number of options.
The reason is practical: each additional column competes for the width needed to read the information inside it. When the client must pinch to zoom, scroll away from the relevant row, or remember an earlier option that is no longer visible, the table makes the comparison harder to follow. Nielsen Norman Group advises preserving legibility without zooming and notes that wordy entries may limit a mobile table to two columns, while number-heavy tables can sometimes support more. Its guidance is to prioritize the attributes relevant to the comparison rather than force every possible detail into view. [1]
For licensed insurance agents and financial advisors, this distinction matters in a client meeting. A presentation table is a visual aid for explaining alternatives. A compact layout can help keep the discussion focused, but it does not establish suitability, replace professional judgment, or substitute for required product information and disclosures. The column budget governs what is visible at a particular moment; it does not determine what the client should choose.
Start with the question the client is answering
Before building or opening a comparison, state the decision in plain language. Is the client comparing two approaches, reviewing a current option against alternatives, or deciding which features merit further investigation? Then select the rows that help answer that question. If a detail does not help distinguish the options for this decision, it may belong in a supporting view rather than the first screen.
The leftmost column should identify the row meaning: for example, the feature, criterion, or question being compared. The remaining two or three columns can represent the alternatives. This gives the client a stable reference for interpreting each value. Without row labels, figures or short phrases can become difficult to interpret when the conversation moves between products.
A disciplined first view is not an incomplete analysis. It is an intentionally limited view of the analysis, organized for a particular moment in the conversation. Secondary details can be introduced when they become relevant, instead of requiring the client to navigate a crowded table before the primary distinction is clear.
From Decision Question to Visible Comparison
The column budget works best as a sequence of design decisions rather than a fixed template.
1. Name the decision, then choose the rows
Write down the question the table is meant to answer. Next, identify a short set of attributes that directly bear on it. For instance, in a protection review, the left column might name the coverage considerations under discussion, while the other columns show how three alternatives address those considerations. This is an example of a layout, not a recommendation about which products to present or select.
Rows should be specific enough that the client can understand what is being compared. If entries need long explanations, the table may require more horizontal space than a concise, number-based comparison. That is a reason to simplify the visible comparison or reduce the number of alternatives—not to compress the text until it becomes difficult to read. NN/g’s mobile-table guidance explicitly distinguishes between wordy content and number-heavy content when discussing how many columns can remain legible. [1]
2. Set a visible comparison boundary
Begin with the row-header column and two alternatives. Add a third only if the content remains easy to read at the size and orientation planned for the meeting. The test is not whether the table technically renders; it is whether the client can identify a row, read the relevant entries, and compare them without losing context.
If all three alternatives are genuinely needed, consider whether the table can be reorganized around the decision rather than expanded with more fields. If the third alternative makes the text cramped, a two-option view may be more useful for the initial explanation, with another option introduced in a follow-up view. The aim is to make the sequence of comparison understandable—not to hide relevant information or imply that the first screen contains the entire analysis.
3. Make any overflow deliberate
Sometimes a table has more useful information than can fit in the initial view. In that case, overflow should be visible and navigable rather than surprising. NN/g recommends visual cues such as a partially visible next column or arrows, and recommends keeping the first column fixed during horizontal scrolling so users retain row context. It also recommends sticky headers for tables that extend beyond the vertical screen. [1]
These choices affect the conversation. If a client swipes horizontally and can no longer see the row label, it may be unclear which feature the newly visible value belongs to. If a table scrolls vertically without its header remaining available, the client may have to reconstruct what each column represents. Fixed labels and clear navigation cues help preserve the comparison’s meaning as the view changes.
Two or Three Alternatives: Choosing the Layout in Practice
Two columns and three columns are not competing standards. They are starting layouts suited to different content and decisions. Two alternatives can give more room to longer descriptions and make a direct contrast easier to follow. Three alternatives can help when the client’s question requires a middle option or a broader side-by-side view, provided the entries remain legible.
Consider a client meeting in which the discussion centers on a few distinct alternatives. A two-option opening view can establish the main contrast. If a third option is important to the decision, the agent can add it after checking that the row labels and values remain readable. This staged approach lets the conversation determine when additional complexity is useful. It also avoids making the client inspect every available alternative before understanding the central choice.
AgentPresent provides a practical example of the product category: it is an active participant in B2B client-presentation tooling, and its website describes the product as a presentation tool rather than a quote engine. [4] In that context, the column-budget question concerns how an advisor structures a client-facing explanation—not how a system calculates a quote or determines a recommendation. A tool’s ability to display a wide table does not, by itself, make that table easy to use in a live meeting. The relevant test remains whether the chosen layout supports the specific discussion on the client’s screen.
The distinction between layout and analysis should remain explicit. A client-facing view may emphasize a small number of decision-relevant attributes, while supporting material contains additional context. The agent should be able to explain what the visible comparison includes and what it leaves for a later discussion. A narrower table should never be presented as proof that the omitted details do not matter.
Test the screen the client will actually see
Check the finished table on the iPad, in the orientation intended for the meeting. Apple’s device documentation distinguishes display dimensions expressed in UIKit points from physical pixel dimensions. Because those are different coordinate systems, pixel counts alone do not reliably describe the interface width available to a layout. [2] The practical implication is to judge the actual rendered presentation, not infer readability from a device’s pixel specification.
Test the full interaction, not just the initial screenshot. Read the longest entries, check the smallest text, and determine whether the client can keep the row labels in view. If the layout depends on horizontal movement, make that movement apparent. If the table extends below the visible screen, check that the client can retain or recover the column headings. The test should reflect the device, orientation, content, and viewing distance expected in the meeting.
For web-based tables that require horizontal scrolling, accessibility guidance also matters. W3C’s design-system guidance calls for a focusable scrolling wrapper with a region role and an accessible name linked to the table caption. [3] These recommendations do not make a crowded table preferable; they describe ways to make necessary overflow more understandable and accessible.
The Long-Term Value of a Column Budget
A column budget is a repeatable editorial decision: what does the client need to compare now, and what can be presented when it becomes relevant? That approach can make meeting materials easier to adapt across devices and client situations because it begins with the decision and the content, rather than assuming a fixed number of columns will always fit.
It also creates a useful review standard for teams. Instead of asking only whether a table contains every available field, reviewers can ask whether each visible column serves the stated purpose, whether labels remain available during navigation, and whether the client can read the entries without zooming. The standard does not dictate a universal table design. It gives the team a way to identify when a comparison has become too dense for its intended use.
The practical rule is straightforward: start with a label column and two alternatives; add a third when it remains readable and directly supports the decision in that meeting. If important content still cannot fit, simplify the first view or make overflow unmistakable. Keep the full analysis available through appropriate supporting material, and explain the role of the client-facing table accurately. The goal is not to fit the catalog on one screen. It is to keep the decision visible while the client is considering it.