Most AI products treat speed as the virtue: faster, more, more immediate. Beff starts from the opposite hypothesis. If waiting is what makes a relationship, then latency is not a defect — it is a feature.
So I deliberately constrained two things. Space: the map is bounded to a walkable neighbourhood rather than a whole city. Time: replies do not arrive instantly, but after the sort of interval a person might take.
Method
I observed and questioned people in the moment of use — recording reactions while they were looking at the screen, rather than surveying them afterwards.
- 01Contextual inquiry
Observing and questioning participants as they used the app
- 02LLM prompt engineering
Conversational persona and reply rules composed as prompt layers
- 03Delayed-reply experiment
Treating reply latency as a design variable
The screens
The decision that the AI would not reply instantly had to be earned on screen. The core problem: make the wait read as anticipation rather than as failure, by showing the state honestly.
* Screens designed and built by me.
Try waiting for it
Read as a description, this just sounds like an odd decision. So here it actually makes you wait — the reply below genuinely has not arrived yet, and will not until the stated time passes.
I’m a bit worn out today
If you read another paragraph while waiting, that is exactly the state this was designed for: an instant answer gets consumed, a delayed one stays with you. (Skippable, and shown immediately if you prefer reduced motion.)
What I found
An unintended user population appeared
A cluster of women in their thirties — not the population I designed for — showed up. Nothing in my data explained why.
Rather than attaching a plausible post-hoc story, I recorded the fact that it was unexplained. It is not a conclusion yet — it is the next research question.
The moment you invent a reason you did not observe, every later design decision is stacked on that fiction. Writing down “I don’t know yet” is more accurate — for the product and for the research.