In an overloaded future there is a keyboard related to attention. What is it?
HACKSPEC_ARTMar 2026
Friction — prototyping a future keyboard
Different crew this time: Haley Potter, Miami Celentana and me, at Figma's FigBuild. The brief was open-ended, so we deleted the constraints and used the event to imagine what a keyboard could be if it wasn't just a dumb input device.
Most feedback from a computer comes back as more information, like a warning, a notification, a timer, or a number turning red. We tried making the feedback physical instead. A key could get harder to press. The wrist rest could change temperature. Instead of giving you another thing to look at, the thing you're already touching would change.
My part was mostly high-fidelity interaction work. I wanted to get really specific about what happens when the state changes: what moves, what becomes obvious, what the user can override, and what happens when the system is wrong.
Here's the prototype. It's a pretend Windows laptop with Friction running on it. The sliders on the left stand in for the sensors, and the three stories walk through what Friction does.
This is the deck we made for it. Arrow keys or swipe to move through it.
The broader research came out of some of the same cognitive-load questions behind Clay/Gyrus, but Friction took the interaction down into the keyboard and the operating system. We didn't build the final keyboard during the event, and we missed the submission.
| Friction sensing concept |
|---|
| Possible sensing inputs (eye movement / posture / other signals) |
| ↓ |
| Local state estimate |
| ↓ |
| Interaction logic |
| ↓ |
| UI response ‖ Magnetic key force ‖ Wrist-rest temperature |
| ↓ |
| Physical feedback |
| Friction event prototype |
|---|
| Manually supplied focus / fatigue state |
| ↓ |
| React / Vite simulated desktop OS |
| ↓ |
| UI + keyboard-response simulation |


The working artifact was a high-fidelity browser/simulated-desktop prototype built in React/Vite from the Figma Make work.
Focus and fatigue values were entered by hand in the event prototype. Those values drove the interface changes and stood in for the proposed keyboard response.
The physical concept used variable key resistance and wrist-rest heat as output channels. The broader concept looked at sensing through smooth-pursuit eye movement and RF/posture signals, with local processing and explicit calibration stages.
The event prototype didn't implement or validate a reliable way to infer focus or fatigue from those signals. So the software prototyped the response/interaction layer separately from the proposed sensing hardware.1