Designing UX for Invisible Technology: Lessons from Sustainability Platforms in High-Traffic Venues
There is a particular kind of design problem that nobody really prepares you for in school, and it is not really described in most design job requirements. It is the kind of problem where the technology you are designing for is, by its very nature, invisible; where the product is working in the background, tracking, measuring, or enabling something, and the only moment where the user really experiences it is through the little screen they are looking at while they are waiting in the concourse of a stadium, holding their reusable cup, and waiting for the match to start.
This is essentially the situation I found myself in when I joined a sustainability technology company in 2023 — one that helps organisations reduce single-use plastic waste by replacing it with tracked, reusable packaging systems.¹ The product I had to redesign is a consumer engagement tool accessed via a QR code printed on a reusable cup or product. No app download is required. The user scans, the interface loads in their browser, and within seconds they should be able to see their environmental impact, claim rewards, and engage with the brand they are interacting with.²
At the moment there were no established UX patterns for what we were trying to build. I had to invent the playbook while simultaneously building the product.
The Problem with Designing for a Product Nobody Sees
Before I even opened Figma, I had to understand why this current product wasn’t working. The problems were obvious: there was a lack of consistency in colour, placement issues, and formatting problems, as well as a general look and feel that just wasn’t quite right. But there was another, more interesting problem.
The product I was redesigning is what I would call invisible technology. It is made possible through sustainability infrastructure — cup tracking, data collection, and environmental calculations — but the user is only ever privy to a web-based application after scanning. For this interaction to occur, it is essential for the interface to do an enormous amount of heavy lifting within a very short span of time. It has to establish trust, convey value, and walk the user through an activity they have probably never performed before, all while competing with the noise of a packed stadium, a queue at the bar, and the general chaos of being at a live event.
The design at the time wasn’t built to handle any of this and new users found it hard to understand the flow. Important features were hard to notice, nothing about it said “this is real, this is legitimate, this is worth your time”. Because of this, it wasn’t real. And if it wasn’t real, users just wouldn’t use it.
This is one particular failure mode that I think is not well understood in UX writing, and it is “the credibility gap of invisible technology.” Users can’t see the system behind the product. There are no physical indicators, no patterns of an interface, and no pre-existing brand recognition. The design has to be enough to establish trust. If it is confusing and unpolished, it is not just unhelpful; it is actively untrustworthy. A confusing interface does not just frustrate users in environments like these. It makes them question whether the whole thing is legitimate.
Starting Without a Playbook
One of the things I had to get comfortable with right away was that there weren’t any established patterns in UX design that matched what we were creating. Creating design patterns for sustainability engagement in a high-traffic, real-time environment wasn’t a problem that had been solved yet. The most similar design patterns I could find were those of gamification interfaces and loyalty programs, but those are generally being used in a completely relaxed environment, like a person sitting in their house scrolling through their rewards programs.
Existing ESG and sustainability tools in the market were, almost without exception, designed for specialists: quarterly reporting dashboards built for sustainability managers who had time, context, and training.³ None of these factors are present for the football stadium fan, who has just been handed this cup and is wondering what this QR code does.
So, I began with what I always begin with, even if there’s no template: paper. I filled several pages with sketches (yes, sketching on paper might be considered very old school but that is what I am most comfortable with) – layout ideas, flow alternatives, navigation structures. I wasn’t trying to solve the whole problem at once. I was trying to understand the constraints well enough to know which problems needed solving.
The constraints, as I saw them, were:
· The user arrives with no prior knowledge of the product
· The user is in a distracting environment
· The user has scanned a QR code, so at least mildly interested, but not more than that
· There is no way to explain the product before they are presented with it
· The interface has to be usable by a first-time user, and by a tenth-time user
· There is no app installation – everything has to work in a mobile browser
These constraints drove all of my decisions from that point forward.
The Design Principles I Built Around
Through working within these constraints, I was forced into a set of principles that I have continued to use in other projects since. I would like to share them with you not as a framework but as the conclusions I came to through making it work.
Simplicity is not optional; it is the product. In a high-traffic, high-distraction world, every extra click, every unclear prompt, every bit of visual noise is another reason to leave. I made a conscious decision early on that the product would have to feel almost intuitive; not dumbing it down but making it clear. The way in which the user would navigate through the levels of information would have to be intuitive; if it was not clear to a first-time user what to do within the first few seconds of loading the screen, it was not working.
Trust has to be visible. Since the technology isn’t, the design had to ensure the product felt real. This meant ensuring colour branding, typography, and the overall visual language felt considered and not assembled. I created new brand guidelines for the interface, not just applying the existing brand of the venue operator, but creating a flexible one that would stand up to real-world use with different clients, such as a football club, food festival, or hospitality bar.
First-timers and repeat users are not the same person. This might seem like an obvious statement, but it has significant implications for the design. First-timers need orientation. They need the interface to explain what this is and why it’s important before asking them to do anything. Repeat users need efficiency. They know what it is, and they need to get to their rewards or their impact data quickly. I had to balance the two without frustrating either user type.
Collaboration with developers is not up for negotiation. This is one aspect of the process that I want to highlight because, in my opinion, designers sometimes don’t fully appreciate the impact of the context of development on what is feasible. Working closely with the development team from the start meant that my choices were informed by what was feasible to build and deploy in the browser, without the need for an app install, and across the variety of devices the user would be holding. Design that looks good in Figma but fails dismally in the browser isn’t finished design. I worked closely with the team, and the final product was genuinely better for it.
What the Iteration Actually Looked Like
I want to be honest about this process, too, because I think there’s a tendency within design writing to present this process of iteration as easier than it actually is. The reality is that feedback came in waves, from multiple directions, and not all of it was easy to reconcile. Early feedback from the development team flagged technical constraints I had not fully accounted for in my initial layouts.
There were user issues, too, according to the client-facing team, where some of the elements I had given prominence to were actually not being used, while some of the elements I had not given prominence to were actually the ones being requested.
And then, of course, there was the feedback that came afterwards, the kind of feedback you only get when people are actually using the product for the first time, in an actual stadium.
This last category of feedback is the most valuable and the most difficult to simulate. The reason is that I couldn’t conduct a formal usability test in this kind of environment prior to launch. What I could do was design conservatively for this “first-time user” scenario, make sure the most important actions were visually prominent, and then iterate based on what we learned after launch. This is not an ideal approach, but it is a realistic one given this kind of environment.
Each round of iteration informed the design system. Instead of just fixing isolated issues, we attempted to understand each piece of feedback as indicative of a larger trend: “this is a labelling issue,” “this is a hierarchy issue,” “this is a contrast issue,” and so on. This approach is part of what made this product more stable over time.
Where It Ended Up
The redesigned interface is currently used across a range of venues and events, including Derby County Football Club, Notts County Football Club, Sheffield Food and Drink Festival, Electric Daisy, and various hospitality venues. Every reusable cup used in these football clubs’ stadiums contains the QR code for the interface. This means that every day of a football match, thousands of people are using a product I designed. The redesign proved successful not just in terms of usage, but also in terms of organisational credibility — it was incorporated into pitch decks, marketing materials, and the company website in a way that had not been possible before. My view is that a product that does not look credible is not helpful in securing the trust of partners, clients, or investors. One that does can be.
One further validation of this approach came from a partner company, a sustainability organisation based in Portugal, whose product had been tested at sustainability fairs and is now being rolled out across their stores, with plans to move into Spain. The fact that the design had to accommodate different languages, brands, and cultures was something I thought about from the very beginning, and this is partly why I developed a flexible design system rather than a rigid template.
What I Would Tell Other Designers
If you are working on a product where the tech is not really visible to the end user – sustainability platforms, IoT interfaces, background data systems – then here are the things I wish someone had told me before I started.
Constraints are more important than flows. The context in which a user is using your product – the environment, the mental state of the user, time of day, device – is more important than thinking about the flow of your product only. The constraints are your brief.
Trust is a design material. When you don’t have physical design elements like a brand or a physical product to rely on, then the look and feel of your interface is doing a lot of trust-building work that you may not even realize.
Design for first-time users without punishing returning ones. These are not the same person and they need different things.
Get in the environment if you can. I designed this product for use in stadiums and at festivals. If you’re designing for a physical environment, try to be in the environment, even if it’s just to observe, not to test. It will change your assumptions in ways that no user persona document will.
Iteration is not failure, it’s the work. The product I shipped looks nothing like my first sketches, and that’s just the way it should be. The goal is to get to something that works.
Putting These Principles Into Practice
If you take nothing else from this piece, take these three questions and apply them to whatever you are currently working on. First: what does a first-time user see in the first five seconds, and is it enough to earn their trust? Not their engagement, not their enthusiasm — just their trust. If the answer is unclear, that is your first design problem. Second: have you mapped the real environment your user is in — not the idealised one — and have you designed for its actual constraints? Most interfaces are designed for calm, patient users on good Wi-Fi. Most real users are distracted, rushed, and sceptical. Design for who they actually are. Third: are your most important actions the most visually prominent ones? Not the ones you find most interesting, not the ones that are technically impressive — the ones your user needs most. These three questions will not solve every problem, but in my experience, if you can answer them honestly and design accordingly, you will have already solved the majority of them.
A Final Thought
There is something that I find interesting about designing for invisible technology. When it is successful, no one ever notices it. They look, it loads, they see how they’re making an impact, they collect their reward, and then they’re off with their evening. It is like it was never there at all.
For a designer, it is both the hardest thing to achieve and the most satisfying one. It means that it did its job; it got out of the way and let the thing that was really important, the sustainability behaviour, the impact on the environment, the relationship between people and the world around them, really come through.
We do not speak enough about designing for invisibility, but I think it is one of the most important skills we can build, particularly as our use of technology becomes further integrated into physical environments, such as smart venues, sustainable retail, or physical infrastructure. It is not just ‘how do I make this easy to use?’ but ‘how do I make this so good, so natural, so right, that the user never has to think about the design at all?’
This, of course, remains the question I am still working on. I suspect I shall still be working on this question for some time to come.
