technologies and interfaces
the problem with impressive
there's a particular kind of tech demo that gets applause at conferences and goes viral on social media. a holographic interface. a gesture-controlled wall of data. a robot that does a backflip. everyone claps, shares it, calls it the future. and then nobody actually uses it for anything.
i've been thinking about this gap for a while now. the distance between what impresses people and what actually helps them. it's wide, and i think a lot of us in design and technology spend too much time on the wrong side of it.
invisible technology
the best interfaces disappear. you don't think about a good door handle. you don't admire the design of a light switch every time you flip it. it just works, and your mind stays on whatever you were actually trying to do. that's what good technology should feel like.
don norman wrote about this decades ago. the design of everyday things isn't about making them beautiful or impressive. it's about making them understandable. a kettle that you can use without reading instructions. a tap that makes it obvious which way is hot. the design serves the person, not the designer's portfolio.
i keep coming back to this idea: technology should be humble. it should do its job and get out of the way. the moment you notice the interface, something has gone wrong.
over-designed vs. simple
think about the difference between a flashy smart home dashboard with animated graphs and swipe gestures and custom widgets, versus a simple row of physical switches on the wall. the dashboard looks incredible in a demo video. the switches actually get used by everyone in the house, including your grandmother who doesn't own a smartphone.
or consider a restaurant menu. a paper menu works. you pick it up, you read it, you order. an ipad menu with animations and photos and categories and search is technically more "advanced," but i've watched people struggle with them in real restaurants. they tap the wrong thing, they can't find the section they want, they feel stupid. the technology added friction to something that was already solved.
i'm not against digital interfaces. i build them. but i think we need to be honest about when we're adding technology because it helps and when we're adding it because it looks good in our portfolio or impresses a client in a pitch meeting.
how this shaped my later work
this thinking has quietly influenced everything i've built since. when i worked on the furhat robot project, the temptation was to make the interaction as complex and futuristic as possible. multiple face expressions, elaborate conversational flows, gesture recognition. but the people who would actually interact with this robot didn't care about any of that. they wanted to ask a question and get an answer. the simpler the interaction, the more comfortable people felt.
the same thing applied to the balloon installations i worked on. the instinct was to make them technically complex, to show off what was possible with sensors and lighting and sound. but the moments that actually worked, that made people stop and engage, were the simple ones. a balloon that changed colour when you touched it. that's it. no app required, no explanation needed, no instruction manual. you touch it, it responds. a child understands it instantly.
the technical complexity should be hidden underneath, not displayed on the surface. the engineering can be sophisticated. the experience should be simple.
the pressure to impress
in design and tech education, there's an unspoken pressure to make portfolio pieces that look impressive. projects get evaluated partly on how "wow" they are. this creates a strange incentive: you build things that photograph well and demo well, rather than things that work well for real people in real situations.
i've felt this pressure myself. the urge to add one more feature, one more interaction, one more technical flourish, not because the project needs it but because it'll look better on a website or in a presentation. every time i've given in to that urge, the project got worse. every time i've resisted it and kept things simple, the project got better.
the best work i've done is the work that's hardest to show off. a server setup that just runs without needing attention. a website that loads fast and is easy to navigate. a circuit that does one thing reliably. none of these make for exciting demo videos, but they're the things that actually matter.
against spectacle, for service
i think there's a meaningful distinction between technology as spectacle and technology as service. spectacle is about the technology itself, about what it can do, about making people say "wow." service is about the person using it, about what they need, about making them not think about the technology at all.
this isn't a new idea. dieter rams said it better than i can: good design is as little design as possible. victor papanek argued that design should serve human needs, not create artificial ones. these ideas are decades old, but they're still radical in practice because the incentives in the tech industry still push toward spectacle.
i want to build things that serve. things that are useful in the quiet, unglamorous, everyday sense of the word. things that people rely on without thinking about. that's not as exciting as a holographic interface or a gesture-controlled wall, but i think it matters more.
technology should be humble
the word "humble" doesn't come up much in tech. we talk about "innovative" and "disruptive" and "cutting-edge." but i think humility is the most important quality technology can have. humble technology doesn't demand your attention. it doesn't require you to learn its language. it speaks yours.
this is the principle i want to carry forward into everything i build. not "is this impressive?" but "is this useful?" not "will this get attention?" but "will this get out of the way?" the answers to those questions lead to very different kinds of work, and i know which kind i'd rather do.