▶I'm Looking Through You

A new project is underway and momentum is building. Regardless of whether this is taking place via waterfall, agile, AI-powered pods or some sort of intergalactic rocket mission, conditions are set for something impactful.

The first presentation occurs: a mock is included in the latter stages of the deck, rapidly generated by a designer or by AI, and thus the trouble begins. Several questions or objections are raised upon viewing the mock; 'please don't put too much stock into this, it's purely for illustrative purposes' you cry as you fend off the vultures, but the damage has been done. Someone has taken a screenshot and sent it to a stakeholder who was unable to make the meeting.

Over the course of the following weeks the problem deepens. As you discuss possibilities and ideate with other practitioners, different variants are shared between different individuals. These are all taking place with the best of intentions — you're having a constructive conversation about the information architecture of a certain complex component and you need to have a healthy back and forth. But invariably, at some stage, one of these variants will fall into the wrong hands. Now there are multiple PMs with different static mocks — one has already vibecoded their interpretation of it and a developer has been proactively speccing from a JIRA board. You have a stakeholder messaging you, commenting on elements disappearing below the fold, whilst another stakeholder asks if you've considered moving an icon from one side to the other. Perhaps worst of all, some are simply badmouthing the work for its apparent lack of quality.

This is the very specific horror of a static mock being treated as if it were fact. Evidently, all of these individuals have started to form their own opinions, but the mock has lost all semblance of its original intent and has at no point been accompanied by the further context it not only deserves but needs. The static mock hasn't just travelled — it has metastasised.

In our design world, an interface is not an image, it is a visual or auditory space of human interaction. The moment we represent it as an image, we have made a category error, and everything that follows — the misaligned or confused stakeholders, the vague tickets, the developer filling in gaps — is a direct consequence of that error.

Marshall McLuhan, the Canadian media theorist, argued that 'the medium is the message' — that the form of communication shapes its meaning more profoundly than the content it carries. His point was that television didn't just deliver content differently to radio; it changed how people thought. I wonder if perhaps the same principle applies here: designing in a static tool doesn't just produce static artefacts, it also produces static thinking. Organisations think in screens rather than flows, in presentation moments rather than lived experiences. Anyone that has a direct influence on the outcome of the interface falls into this trap.

I acknowledge that this problem is not equally distributed. In a small, empowered team — designer, engineer, PM in close proximity, shipping fast and talking constantly — the issue is largely self-correcting because misalignment surfaces before it calcifies; nobody is screenshotting a mock and sending it to another department head because there probably isn't one.

In a large organisation, the hierarchy often means design has to travel upwards for approval before it travels to engineering. Distance between functions means a static mock is often the primary communication tool between people who don't share context (and don't understand how to). Politics means presentations become performances, and polished static mocks are — in a sense — a costume. These are structural features of how large organisations work, which is precisely what makes the discipline around static mocks so important in those environments. A startup can potentially be sloppy about this and no one bats an eyelid. A large organisation being sloppy creates misalignment at a scale that snowballs over months and across hundreds of people.

The additional farce of a static mock is how authoritative it can look. A beautifully rendered image communicates: this has been thought through, this is close to done, this is what we are building. It's possible (perhaps even likely) that none of those statements are true. The polish conceals the incompleteness of the thinking behind it, and in an organisation where most stakeholders lack design literacy, that is a potential nightmare. Decisions get made, resources get allocated, expectations get set.

A brief nod to the knock on effect from a technical perspective:

When a developer receives a static mock, they receive a picture of a moment, but no guidance on the hundred adjacent questions that writing code requires answers to. What happens in the loading state? What happens when the text is twice as long? What happens when the API is slow, or the user's session has expired, or there are no results to show? What happens when the user drops their phone because their dog has snuck up on them? Some may fill those gaps with assumptions, and every assumption is a potential divergence from what the designer intended, assuming the designer had even considered it at all.

Historically, we see this produce tight coupling: components built so specifically to one context shown in a mock that they resist change and resist the kind of variation that a real product encounters constantly. It also produces hardcoded values which accumulate into a codebase that becomes progressively harder to maintain.

At this point, you may have what is perhaps the obvious objection: what if we don't have time?

It is hard to dismiss this question, because I can't claim that it's 'wrong' per se — depending on your workflow (and every company seems to be wildly different in these changing times) you may think what I'm suggesting is wholly impractical. However, I do believe if we are measuring time, we are measuring the wrong thing. The time argument compares the speed of producing a static mock with the speed of producing a working prototype and concludes that the former is faster. However, it fails to account for where saved time could go.

Every hour not spent on forming a working prototype is borrowed. It gets repaid — with interest — in back-and-forth, in rework when built reality diverges from design intent, in stakeholder management, in edge cases that weren't considered. Effectively, the static mock doesn't really save time, it just relocates it.

And so to my original statement — what about the tools available now that weren't available two years ago? The gap in effort between producing a polished static mock and producing a working prototype has significantly reduced thanks to AI-powered tools. A designer without coding knowledge can produce a working, interactive prototype in only marginally more time than it previously took to design the static mock. The faster option and the better option have (somewhat) converged.

Here are three things which I have actively incorporated (or am actively incorporating) into my day to day:

1. Being more deliberate about what I share and when. The group chat screenshot is where significant damage originates, and it is a cultural behaviour, which I would strongly argue means it is changeable. The adaptation takes time and is inherently political (someone will ask for a 'screen' at some point), but it's worth it. Please be aware: I'm not dying on this hill — I can't reasonably proclaim: 'from this day forward, I will never send another static mock again.' But I can be far more careful.
2. Start with prototypes to convince, not static mocks. A working prototype shown early creates alignment around behaviour. It is also harder to misrepresent; people are less likely to screenshot an interaction and pass it off as finished. The prototype forces the conversation to be about the right things earlier, when changing them is easy. Experience starts to become the currency — not images.
3. Using AI to make this viable. The tools are endless (sometimes overwhelmingly so, admittedly): Figma Make, Framer AI, UX Pilot, Lovable, Bolt etc. — whatever works best logistically, organisationally or financially. With simple prompting, the ability to describe an interaction in plain language and have a working prototype emerge rapidly is now becoming normalised.

A forewarning on this: I am very conscious that my argument throughout this article is something akin to 'static mocks are sloppy'. The irony does not escape me that AI generated work is often — in and of itself — labelled as 'slop'; if executed badly, prototypes can also be detrimental to productive discussion — glitchy transitions, incorrect content, poorly thought through journeys can all be damaging.

I suppose my advice is that as long as designers are maintaining rigorous control over the actual interfaces and are being as deliberate as possible with their prototyping decisions, we begin to communicate via a medium that is so much closer to reality. Let's leave less to the imagination.