Exhibit A·2//Syntheia (opens Syntheia in a new tab)
Matrix Comparison View
Two readers, one table. A density switch instead of a second product.
- Matter
- Syntheia (opens Syntheia in a new tab) — Legal-tech SaaS · enterprise → self-serve B2B/B2C
- Role
- Interaction design · IA · data visualisation · mobile
- Domain
- High-volume legal comparison
- Term
- 2025
High-volume legal comparison has two readers. One is scanning for a single answer and wants the noise gone. The other is auditing everything and wants every column visible at once. The obvious response is to build each of them their own view, which is how a product ends up maintaining two of everything.
Simple and Super are the same table at two densities. Columns are added in Super, never reordered — so a row you learned to read in Simple is still the same row, in the same order, when the other six columns appear. The switch is a lens over one object, not a fork in the product.
The mobile portal carries the full feature set rather than a reduced one. The density switch is what makes that possible: on a phone you are simply always in Simple.
Build a second view for power users.One view. A density switch.
Two views means two mental models, two bug surfaces, two QA passes, and a decision the user is forced to make before they have seen any data.
- Select-all, search and checkboxes on one surface. The picker is a panel over the page, so the documents you are choosing from stay where you last saw them.
- The anchor is a control on the row, not a dropdown above it. One click sets the base, and the row that is the base looks different from the rows that are not.
- Compare is a split action: the left half runs it, the chevron picks the mode. Four modes behind one button beats four buttons, and the default is the right answer often enough that most people never open the menu.
Comparison needs a base document, and picking one is the only real decision in the setup. It gets a dedicated control on the row rather than a field above the list — you anchor the thing, not a copy of its name. Everything optional stays folded away until asked for.
Simple · 3 columns
Super · 9 columns
- Selected state carries a fill, not just a weight change — weight alone failed at 3:1 against the track.
- The divider is the affordance. Without it the control reads as two buttons, and people click both.
- Persisted per user, not per session. Switching view should not be a thing you redo every morning.
- Modes
- 2 — never 3
- Target
- ≥44 × 44 px
- Column delta
- +6, appended
- Row order
- identical across modes
- Mobile default
- Simple, locked
- Persistence
- per user
A two-state control is a small thing to specify and an easy thing to get wrong. The rule that mattered was the last one on the list: columns are appended in Super, never reordered, so learning the table once is enough.
- Three columns, the same three as Simple on desktop, in the same order. Nothing is reordered between breakpoints.
- The columns that will not fit become rows in the sheet rather than disappearing. Parity is a promise about information, not about layout.
- A column manager instead of a third preset. Every stakeholder wanted a different column promoted, and a preset for each of them is how you end up maintaining six.
Feature parity, not a cut-down companion. The density switch is what makes it possible: on a phone you are simply always in Simple, and the six columns Super would have shown come back as rows in the sheet. Nothing is dropped.
2 modes
One mental model
100%
Mobile feature parity
On reflection — The hard part was resisting a third mode. Every stakeholder had one column they wanted promoted; the answer was a column manager, not another preset.
Syntheia is under NDA. Every interface on this page is a redrawn abstraction — real structure and real decisions, no real screens and no client data.