Sometimes, in our industry, the work is done backwards. More often than not, an AV system is specified, designed and sold without a clear understanding of its range of use or a specific definition of its functionality requirements. Important services are often left off the bid package. In fact, low project bidders often win jobs by shaving programming costs off the budget. In such cases, the old saying rings true: you get what you pay for.
Control programming is the biggest variable in a system though it typically gets the least amount of attention upfront. For example, understanding who is going to use the system will help shape the programming. The ability to identify users and the fundamental difficulty of defining such intangible elements of a project add to these constraints.
All of this amounts to unpredictable results after installation, and a lack of planning and definition of the user experience can derail a project.
This is a case of the tail wagging the dog so why don’t we look at projects differently?
Typically, a project or system is defined by a set of user needs:
The next step is to design a system and select devices that meet these parameters and fit the budget.
These details provide the architecture of a system that represents and responds to your needs. However, if we stop here (as is too often the case), we miss the critical part of defining the user experience.
Alternatively, an approach that I have found valuable with my clients is to assess the functionality requirements and articulate the user interface experience before designing the