A space tells its secrets through its shortcuts.

On a college campus, it’s the dirt trail cutting diagonally across the lawn, a “desire path” worn in by thousands of students ignoring the official sidewalk.

I’ve written about desire paths in technology before. In a conference room, they look like handheld remotes pulled out of a clandestine drawer to bypass the pristine, untouched touch panel on the table.

Both tell the same story: people will ignore the elegant solution you built if it doesn’t feel natural to them. And when that happens in AV, we tend to call it “user error.”

But as Don Norman wrote in “The Design of Everyday Things,” there’s really no such thing as user error, only bad design. Most people don’t think like engineers. They think like … well, people. If our systems don’t match the way people actually think and behave, no amount of technical perfection will make them stick.

Programming

In AV, programming is one of the last phases of our projects. It is our code. It’s the logic we use to determine the order of operations a system needs to go through to perform a specific task. Its baud rates, code languages and batching files. It can also be the GUI design. The colors we use, the touch panel wireframes and the language or words we put on the buttons to help a user know what to do to get the intended result in the room.

But here’s where the language betrays us. In AV, “programming” means something entirely different than it does in architecture.

The programming phase in architecture is the pre‑design stage where project goals, functional requirements and performance criteria are defined. It involves interviewing stakeholders, observing workflows and gathering data to understand how the space will be used and what outcomes it must support. This process sets the guardrails for design, aligning spatial needs, budget and purpose before a single line is drawn. In short, it’s about defining what the project must achieve before deciding how to achieve it.

There’s a glaring contrast here. Programming in AV is the last phase of our workflow, but it is also often the first thing a customer encounters when they interact with our systems. However, the AV programmer often has no visibility into the initial conversations, needs, wants and goals of the customer. They’re programming in a black box, illuminated only by a screen showing a BOM and a line drawing done by a design engineer, who likely had little access to the users as well.

The result? Systems that are technically elegant and practically useless.

The Desire Path Problem

As I said, I’ve talked about the desire path problem before. You walk in a room and the remotes are on the table next to the touch panel. Why? Likely because they are intuitive and familiar. They are tactile. People have muscle memory for them.

I remember talking to a programmer once who was charged with training users on a new system that was recently commissioned. He walked in and handed the user a Crestron TP series touch panel. Industrial grade. Tried and true. a solid piece of hardware. He then asked them to do a few operations, to which they replied, “I don’t know how to use this.”

He explained the button layouts and operations, but they struggled to make sense of the device they held in their hands.

A bit frustrated but more curious, the programmer left the room. He returned with an iPad running an EXACT copy of the layout and buttons that were on the industrial touch screen. He handed it to the user and said, “Try this one.” The user had things running in a few seconds. Why? Because in their mind, they knew how to use an iPad.

The technology hadn’t changed at all, only the familiarity had. And familiarity is the fastest on‑ramp to adoption.

So yes, many times it may be the interface itself and sometimes it’s the hardware that holds the interface in question. In either case, the symptom is the remotes on the table, or the low adoption, or the poor feedback, but it takes digging into the people in the room first to understand exactly why.

Don Norman’s Truth

User “error” is usually just bad design. This may be initially hard to hear or accept, because as integrators, we take pride in our work, as we should. However, we can’t judge our work only by our successes. Sure, our IT contact may love the design and commiserate with us that their users just don’t understand technology. But we shouldn’t accept that!

Most AV systems are designed by engineers for engineers, but most end users don’t think like engineers.

We can’t just design for functional requirements. We have to design for mental models. How do people think, behave and speak? What do they expect? What is a common experience that they can all identify with?

If we do this, we can get true adoption, because the actions we’re asking them to take to get their meeting up and running are already baked into their workflows and behaviors.

Adoption is a metric that is just as important as system uptime.

True Programming

Page flips, access to advanced features, and recreating a way to tap into every feature of the system from the control platform can be very useful, and even done in a way that is elegant, but if those features add friction, cause confusion, and reduce adoption, they are a problem.

The functions need to be highly intuitive, the actions simple and obvious, and the language natural and familiar. Approaching the programming phase early, adopting the architecture model, would yield information about the outcomes desired, the stakeholder groups, the end users, and their natural workflows, shared history, and common language. That information is gathered before a single line of code is written, and even before a single line diagram is created.

This allows for system design that approaches the system from the users first point of contact, the user interface, and creating an ideal that then informs system design and equipment selection. Then the user face is wireframed and play tested, feedback collected, and then the final code put into play. It connects the programmer to the outcome, instead of asking them to design in the dark and then make changes until it’s “good enough”.

So let’s move programming in AV upstream.

We should be thinking about the customer/end user journey. Their first touch is typically a user interface on a control panel. As such, the people we task to deliver that first touch, our talented and creative programmers, should have access to those beginning conversations.

Doing so will increase adoption, provide better end user experiences, and give our most talented resources the ability to design and be creative, not just create functional streams of characters and semicolons.

Code can make a system run, but only people can make it work.