Incheq

Project Framing

Incheq is a comparison tool that sits in a space dominated by cluttered interfaces and aggressive conversion tactics. The brief asked us to design something that could present dense financial data without resorting to the visual noise that most comparison sites treat as inevitable. The users are people making real decisions about their money. They deserve interfaces that respect that.

The project scope covered UX research synthesis, interface design across responsive breakpoints, a component system, and front-end implementation of the comparison engine's presentation layer. We were not building the data pipeline or the scoring algorithms—those existed already. Our job was to make the output of those systems legible, navigable, and trustworthy at a glance.

Challenge and Design Context

Comparison tools have a specific UX problem that most other interfaces do not face at the same scale: the user needs to hold multiple data points in working memory while scanning across rows and columns. If the visual design adds cognitive load on top of the informational load, the tool fails its primary purpose.

The existing interface used a dense table layout with alternating row colours, inline icons for feature indicators, and a sticky header that consumed significant vertical space on smaller screens. It worked, technically, but user testing showed that people frequently lost their place in the comparison grid and struggled to isolate the factors most relevant to their decision.

We also faced a trust challenge. Financial tools need to feel authoritative without feeling sterile. There is a specific visual register—clean but not cold, structured but not rigid—that signals competence without triggering the scepticism that overly polished financial interfaces can create.

Structure and Layout Decisions

We restructured the comparison experience around a card-based model rather than a pure table grid. Each option in the comparison set receives its own vertical card, and the user can select which attributes to compare using a filter panel. This approach trades some information density for significantly improved scanability, particularly on mobile where table layouts become nearly unusable.

The card layout uses a consistent internal grid. Key figures sit at the top of each card in large, well-spaced type. Supporting details follow in a compact list format. Visual indicators—small progress bars and subtle colour coding—provide at-a-glance comparisons without requiring the user to read every number.

On desktop, the cards arrange horizontally with synchronised scrolling, so attribute rows stay aligned across options. On mobile, the experience shifts to a swipeable card stack where the user can flip between options while a persistent summary bar at the bottom tracks their shortlisted choices.

Typography and Visual Language

The type system prioritises legibility at small sizes, since much of the interface consists of data labels and numerical values. We selected a humanist sans-serif for the primary interface—something with enough character to feel considered but conventional enough that it disappears into the reading experience for data-heavy screens.

Numbers use tabular figures throughout. This is a small detail that makes a significant difference in comparison contexts: when numerical values are stacked vertically, tabular figures ensure that digits align by column, making it much easier to scan and compare values across rows.

Colour usage is deliberately restrained. The base palette is near-white and dark grey. A single muted blue serves as the primary interactive colour—links, buttons, selected states. A secondary warm tone appears only in comparison highlights, used sparingly to flag where one option outperforms another on a selected metric. There are no traffic-light colour systems or aggressive red and green indicators, which research suggests can trigger anxiety in financial decision contexts.

Interaction and Implementation Notes

The comparison engine's front-end is built as a client-side application that receives pre-processed data from the API. The initial page load delivers a lightweight shell with the most popular comparison categories, then hydrates the full filtering and comparison interface.

State management handles the user's filter selections, card ordering, and shortlist choices in the URL as query parameters. This means comparison states are shareable—a user can copy the URL and send their current comparison view to someone else. This is a small feature that has outsized value in financial decision-making, where people frequently consult partners or advisors before committing.

The filter panel uses an accordion pattern on mobile and a persistent sidebar on desktop. Filter changes trigger smooth layout transitions rather than hard re-renders, which keeps the experience feeling fluid even when the underlying data set changes substantially.

Accessibility was a primary constraint from the start. All interactive elements meet WCAG contrast requirements. The card-based layout supports keyboard navigation with clear focus indicators. Screen reader announcements update when comparison results change in response to filter adjustments.

Lessons and Observations

Incheq taught us that data density and usability are not inherently opposed. The key is giving the user control over which data they see, rather than presenting everything at once and hoping they find what matters.

The project also reinforced how much trust is communicated through visual restraint. When we presented the initial design concepts—stripped of the usual comparison-site visual noise—there was initial concern that the interface looked too simple. User testing reversed that concern quickly. Participants consistently described the cleaner interface as more trustworthy and more professional than alternatives they had used. Simplicity, in this context, communicated competence.

Working on Incheq also sharpened our thinking about responsive comparison patterns. Tables are the obvious choice for comparison data, but they are one of the hardest patterns to make work across breakpoints. The card-based approach was a compromise that required more front-end engineering but delivered a fundamentally better small-screen experience.