Hyper-situational interfaces
Thoughts about interfaces created on the fly. For friends, not users.
Think about the last time an interface was user-friendly. Now think about the last time you designed something for a friend. Feel the difference?
We use “user-friendly” to mean easy and accommodating. But strip away the “user” part and you’re left with “friendly”. Which contains “friend”. And friendship isn’t about ease or accommodation. It’s about showing up, being specific, sometimes being difficult, and knowing when to leave.
User-friendly
Most UX design is in the business of accommodation. Make things simple. Hide complexity. Personas and other tools for generalization are created to design for everyone and no one. The result is a generic friendliness: interfaces that smile the same smile at millions of people, smoothing over every rough edge.
Consider organizing a small unconference. Maybe 20 people, two days, a community that knows itself. The “user-friendly” approach offers you Eventbrite or similar tools. Everyone gets a profile page they’ll never update. The platform collects emails, wants to keep you engaged. After the event is over, you receive automated messages and invitations to “stay connected” in a community forum nobody will use.
Designing for friends
Friends don’t need everything explained. They can handle messiness, appreciate specificity, value honesty over convenience. You don’t hide complexity from friends or pretend rough edges don’t exist.
Return to that unconference. What if it was organized by and for people who actually know each other, or are friends-of-friends? Maybe the schedule emerges through a sprawling Google Doc where people argue in the comments. Someone makes a Miro board for session proposals because that’s how they think. Another person spins up a quick Airtable because they like Airtable. It’s chaotic, specific to this group’s culture.
Or imagine something more ephemeral: someone in the community builds a simple tool for this gathering — perhaps for session proposals that reflect how this specific group discusses things, or a way to match people for conversations using the community’s own language and categories. It exists for this moment, serves this need, then dissolves when the event ends. No “account created.” No “come back soon!” No permanent infrastructure for a temporary need.
This is hyper-situational software: tools designed for very specific communities — small groups or even single people. Software that emerges from a particular need in a particular situation. Not a restaurant trying to serve everyone, but a dinner party for the people actually in the room.
But if we’re building temporary tools for temporary needs, we face a challenge: software needs to know how to leave. An event organization app, a workshop voting tool, a family vacation planner. Each harmless alone, but multiply by millions and we risk creating microplastics for the digital ocean. So hyper-situational software either ritualizes if it earns its place, or gracefully dissolves without a trace when the task is done.
If you’re more profoundly interested in this topic, I highly recommend reading Situated software, written in 2004 by Clay Shirky in the Networks, Economics, and Culture mailing list.
Questions
- What gets lost if we stop trying to scale? Access, reach, the efficiency of serving millions with one solution?
- What gets found? Intimacy, appropriateness, software that fits like it was made for you (because it was)?
- Who gets to make hyper-situational software? Does it require technical skills most people don’t have, or could these tools be as easy to spin up as organizing a dinner party?
- What’s the relationship between permanence and value? If software can dissolve, does that make it less serious, or more honest? What about trust?
- What does it mean for software to leave gracefully? To know when it’s no longer needed and not leave a mess behind?
By the way, have you seen Imagine with Claude? It let’s you “create interfaces on the fly” and I think it has that hyper-situational vibe.
