How DesignIQ decides

What goes in

Two screenshots of the same screen, A and B, or two ordered sets of screens for a whole flow such as a sign-up or a checkout. A task in plain words. A device, phone or desktop, picked from the screenshot size unless you change it. And which kinds of people to simulate. The same inputs always give the same result, because the random parts are seeded by the task.

1. Read

A vision model lists every element on the screen: its type, visible text, position and whether it can be clicked. It also returns the shortest sequence of actions an expert would take to finish the task, such as type here, type here, click this. That sequence is the path simulated people try to follow.

The model is asked for facts only. It never rates clarity or guesses how people feel. Readings are cached by image, so the same screenshot is never read twice. Frames sent from the Figma plugin skip this step: their layers already give exact positions and text.

Then both versions’ step lists are checked against each other. Two designs of the same screen must ask for the same inputs, so a name field counted on A is counted on B too. Without this, a model reading each screen on its own can hand one version a shorter task.

2. Measure

For each element, straight from the pixels:

• Size in CSS pixels, taking the screenshot as 390 px wide on a phone and 1280 px on desktop.
• Contrast as a WCAG ratio. Inside the element, the median pixel is the background and the darkest or lightest 2% is the text. The element’s fill is also compared with the page around it, and the higher of the two counts. WCAG AA asks for 4.5:1 on text and 3:1 on controls.
• How much it stands out, from 0 to 1: a mix of its size, how different its colour is from its surroundings, how saturated it is, and what kind of element it is. Buttons pull the eye more than body text.

People find a form field by its label. A field with a visible label just above or beside it takes the label’s contrast; a field with only placeholder text keeps its own, usually much fainter one. A checkbox is measured together with the text next to it.

3. Simulate

Each simulated person works through the task one step at a time. For every step:

1. They look, and they read. Their eyes jump to one element at a time, favouring what stands out, what sits near the top left (less so on phones), what fits the goal (fields when they need to type, clickable things when they need to press), and what is labelled with words from the task or the control they want: among thirty time slots they go to the ones that say 11:00. Each look costs the persona’s glance time, and an element looked at once is less likely to be looked at again.
2. They notice it, or miss it. When a look lands on the right element they notice it, unless its contrast is below what they need or it is smaller than they can pick out (half the persona’s tap size, at least 12 px). The further below the threshold, the likelier the miss, and missing sticks: a person who looked straight past a faint link mostly keeps looking past it. Faintness matters less on big elements: a pale 500 px field is still easy to spot, a pale 18 px checkbox is not.
3. They may click the wrong thing. A look at a clickable element of the same type as the target has a 20% chance of becoming a wrong click, 30% if it also carries the same label (the 11:00 slot on the wrong day). On phones, targets under 44 px can be mis-tapped.
4. They act. Choosing takes Hick’s law time, 0.15 s × log₂(clickable elements + 1). Pointing takes Fitts’ law time, 0.1 s + b × log₂(distance ÷ width + 1), with b set per persona. Typing takes characters ÷ typing speed.
5. They give up. Frustration grows by 0.25 for every look that isn’t the target, 1 for every time they look at the target and don’t register it, 1.5 for a wrong click and 1 for a mis-tap. Finishing a step halves it. Past the persona’s patience they leave, and the step, the element and the cause are recorded.

Returning customers remember where things are: 60% of the time they look straight at the target. Power users do so 20% of the time.

4. Compare

For each version and each persona: finish rate, average clicks, average time to finish, navigation efficiency (best possible clicks ÷ actual clicks) and speed (best possible time ÷ actual time, where the best possible is the same persona with no wasted looks). Efficiency and speed are measured on the people who finished, per persona, and count as zero for a persona where nobody finished. Otherwise a version would look fast just because only its fastest people got through.

Usability score = 100 × (0.5 × finish rate + 0.25 × efficiency + 0.25 × speed).

Confidence. There is no significance test: with simulated people, any difference becomes “significant” if you simulate enough of them. Instead the comparison runs 50 more times with every persona setting nudged by up to 20%. A version is named the winner only if it has the higher usability score, by more than a point, in at least 40 of the 50. Otherwise the verdict is “too close to call”. The score decides rather than the finish rate alone, because many flaws slow people down and cost clicks long before anyone gives up.

Flows. With several screens, each person walks them in order. Time and frustration carry over from one screen to the next, with 0.6 s for each screen change, and the result adds a funnel: the share of people who reach each screen and who finish.

5. Explain

Every failure is recorded as element, persona, cause and the measured value behind it. A language model turns that list into the written report: the verdict, the reasons, a line per persona, and fixes ordered by how many people they affect. It is given the numbers and nothing else. If no model answers, a template writes the same report in plainer words and the result says so.

What it can’t tell you

• Whether people want to do the task. Price, trust, wording and mood are not in the model. It predicts whether they can.
• Anything the vision model misreads. Every result shows exactly what was read, so you can check it.
• How your real audience differs from the four personas. The settings are published starting points until the validation study tunes them.
• What a live A/B test would show. Use DesignIQ to decide which versions are worth one.

Sources

• W3C, Web Content Accessibility Guidelines 2.2: contrast minimum (1.4.3), non-text contrast (1.4.11), target size (2.5.8).
• Fitts, P. M. (1954). The information capacity of the human motor system in controlling the amplitude of movement.
• Hick, W. E. (1952). On the rate of gain of information.
• Wolfe, J. M. (1994). Guided Search 2.0: a revised model of visual search.
• Nielsen, J. (2006). F-shaped pattern for reading web content.
• Apple Human Interface Guidelines: minimum 44 pt tap targets.