Teaching a legacy input device to introduce itself

Abstract mark: force replacing displacement

01 / problem

A device that punishes you for already knowing how to use a computer

The client ships a pointing device that predates the trackpad and still appears on millions of laptops. Almost nobody who owns one uses it.

The failure is not preference. It is first contact. The sensor responds to force rather than displacement, which is the opposite of every other input device a person has ever touched. Users arrive with a trackpad mental model, swipe and tap, and nothing happens.

But that is only the second way adoption fails. Most people never try the device at all, because nothing in the setup flow, the marketing or the hardware itself tells them it is a pointing device. And the people who do get past first touch still put it down, because being able to use it is not the same as having a reason to. Three different failures, three different populations, one device.

02 / method

Two waves, four sample groups, 91 sessions on real hardware

Wave one was diagnostic and zero-context. Participants were handed a machine with no explanation and given micro-tasks that isolated cursor movement, clicking, dragging, scrolling and text editing. We recorded behavioral metrics, qualitative observations and the exact moment each person gave up. Zero context was the point: it captures genuine first-touch behavior rather than task knowledge, and in-person sessions catch abandonment, which a remote study records as a completed task.

That wave produced the three-stage journey rather than assuming it. We mapped the dominant failure mode at each stage and only then designed against them.

Wave two tested nine solutions, three per stage. Each participant received one randomized solution per stage, so no intervention could bleed into the next one's result. Alongside both waves, we interviewed IT buyers at universities to check whether the problem registered at the purchasing level. Not one of them raised input devices as a consideration, which became its own finding: this is not a procurement problem, so it cannot be solved by selling harder.

• workforce stage
• keyboard intensity

The three stages

Failures compound. Awareness fails, so first touch never happens, so nobody reaches regular use. Skipping a stage does not cost you a percentage, it costs you that stage's entire population. No single intervention carries all three.

03 / what the segments split on

The segments did not disagree about the device. They disagreed about the fix.

Every group failed at first touch the same way, which is genuinely useful news: it means the onboarding work generalizes and does not need per-segment variants.

The splits showed up in what people would accept afterward. Older, low-keyboard participants rejected guided practice as a concept rather than as an execution. Their objection was not that the flow was bad, it was that they did not want to practice an input device. No amount of polish on that flow was going to reach them, so we stopped trying and flagged them as out of scope for that stage.

The third-stage solution inverted this. A shortcut layer built on the device's omnidirectional movement landed unanimously with participants who do not use keyboard shortcuts at all, and not once with power users, who already had a faster path and no memorization problem. In aggregate it looked mediocre. Split by segment it was the only third-stage solution that worked, and it worked precisely for the people the existing solution had failed.

A feature that tests badly in aggregate can still be the right ship once you know whose problem it solves. That is the argument the segmentation bought us.

04 / the recommendation

Recommend against the highest-rated solution

At the first-touch stage, the static introduction rated highest on perceived usefulness and every participant read it start to finish. On the ratings, it was the winner.

Then we watched what people did with it. Many tried to click and drag on the introduction's own graphics. It was a static screen, so nothing happened. In the follow-up task they could describe how the device worked and still could not execute it.

That gap is what the project turns on. Reading taught the concept. It did not teach the hand. The introduction rated well because people liked it, not because it worked.

So the recommendation was not the winner. It was a merge: open with the introduction's strongest frames, then transition on the same screen into guided practice, so a user reads for a moment and immediately tries. One flow, no handoff between products, under a minute. Paired with a redesigned settings surface as the place to adjust later.

The option not taken: shipping the introduction alone on the strength of its ratings. It was the cheapest build and the easiest recommendation to defend with a chart.

The final deliverable was a stack, not a single fix: one solution per stage, argued from comparison rather than from taste, with a feasibility and risk assessment for each so the client could see what it would cost to build.

05 / outcome

The research did not stop at a readout

The merged recommendation went to the client as a software-only change with no hardware dependency, which was the constraint that made it shippable at all.

06 / reflection

The entry point is still unsolved

The redesigned settings surface won on coherence and lost on discoverability. Fewer than half of participants found it unaided. A better menu that nobody can find is not a better menu, and we flagged it as an open dependency rather than claiming the win.

If I ran this again I would test the entry point as its own variable instead of bundling it into the redesign. The research kept telling us discoverability was the real constraint, and we kept solving for quality once users had already arrived.