Interactive elements at an exhibition stand are worth testing before production. We offer a practical path from hypothesis and prototype to flow testing, rehearsal, and a launch decision.
Interactive elements at an exhibition stand are often first discussed starting with a list of equipment: a screen, a motion sensor, virtual reality, or an image generator. At Aventura, we start with a different question: which visitor action needs to be tested before production. That way, the idea goes through a cheap prototype, user testing, and a rehearsal before the team ties it to equipment and installation.
Why does an interactive mechanic need a separate technical specification?
In short: A separate technical specification links the interactive element to the product's objective and an observable visitor action. In it, we define the audience and the promise. Then we describe a short scenario and the next business step. Venue constraints and stop conditions complete the document, according to which all project participants test a single hypothesis.
The overall stand design is responsible for space, flow, and negotiations. A detailed analysis of this system is in the article "Exhibition Stand as a Funnel". Here we take one narrower layer: how to devise an interactive mechanic, test it without a finished build, and decide whether to put it into production.
Hypothesis before choosing technology
A good hypothesis describes a specific visitor, their work-related task, and the change after a short interaction. It does not start with the name of a device. First, we decide what the person should understand, compare, try, or discuss. Then we choose the medium that makes this action clear and feasible in an exhibition setting.
Fill in five lines:
- who approaches the interactive mechanic and with what task;
- what the person notices while passing by;
- what action they perform themselves;
- what result they get immediately;
- what business step the team offers after the result.
For example, a manufacturer of complex equipment can let a visitor choose operating conditions on a simple mock-up. The system shows a suitable configuration, and an expert discusses the limitations. The testable hypothesis here sounds like this: choosing conditions helps move faster from general interest to a substantive conversation. The statement does not promise a sale and does not replace future analytics.
A weak formulation sounds like "put up a bright screen for engagement." It does not explain who needs the screen and what counts as a useful action. A strong formulation allows making the first test on paper.
How to build a scenario on one page?
In short: A one-page scenario shows the path from the first signal to the continuation of the conversation. For each step, specify the visitor's action, the interface's response, the staff member's line, the expected time and a fallback in case of failure. If the team cannot walk this path without additional explanations, programming will only cement the ambiguity and make rework more expensive.
Put the scenario together in a table. One row per step is enough.
The table brings together the key points of the section: Step, Visitor, Mechanics. Use it as a quick reference when preparing your event.
| Step | Visitor | Mechanics | Staff | Check |
|---|---|---|---|---|
| Signal | notices the promise | shows one clear start | does not block the view | the meaning is clear without explanation |
| Start | chooses a task | accepts the action | helps only on request | the start takes few actions |
| Experience | tries or compares | gives a visible response | links the response to the product | no dead end and no unnecessary waiting |
| Debrief | asks a question | saves the result if needed | clarifies the context | the conversation changes depending on the guest's role |
| Follow-up | chooses the next step | shows a clear form | records the agreement | there is an owner and a deadline |
The scenario has two variants. The first is for a visitor who does not want to leave their details: they still get an honest, complete experience. The second is needed if the network, screen or sensor fails. The fallback can be simpler, but it must preserve the meaning of the product.
If you need to link the mechanics with the stand route and sales goals, request a quote from us. In your request, specify the exhibition, product, audience and the action you want to test.
Practical breakdowns of events and exhibition projects are published in Aventura's Telegram channel. There we break down programmes, participation mechanics and how the team works on site.
Prototype before programming and production
The first prototype should test the meaning and the sequence, not the quality of the graphics. Use paper cards or clickable screens without complex logic. Automation can be temporarily replaced by a physical mockup or a staff member. The visitor follows the scenario while the team observes the choice and the transition to conversation.
Choose the simplest medium that allows the key action to be performed. A touch interface can be replaced by printed screens: the tester touches an option, and the moderator manually shows the next card. In a simulation, the initial conditions and the result are played out on a table. On the first test, a staff member temporarily acting as a recommendation system guides the personal route.
On the first run, do not explain the logic to the participant in advance. Show the same signal that a guest will see in the general flow. Observe where the person looks, what they try to click, and at what point they ask a question. After completion, ask what they understood about the product and what next step they expected.
A prototype does not have to impress. Its job is to quickly break a weak assumption. If the meaning holds up only through the author's long explanation, the mechanics need to be simplified before production.
How to test the mechanics with people?
In short: A user test is conducted with people similar to future visitors in role and level of knowledge. Each participant goes through the scenario separately, and the team records the observed actions. Do not give hints about the solution or defend the idea during the test. After several runs, change one debatable element and test the new version again.
Conduct the test in the following order:
- state the exhibition context but do not explain the mechanics;
- show the first screen, object, or phrase;
- ask the person to act as they would at the booth;
- record stops, incorrect expectations, and questions;
- after completion, ask them to retell the meaning of the product;
- clarify what continuation of the conversation seems appropriate;
- repeat the test after one targeted edit.
Do not put a manager, a technical specialist, and a procurement person in the same group if they have different scenarios. The same mechanics may give each a different starting point, but these variants need to be tested separately. Otherwise, the team gets an averaged reaction that does not exist in the real flow.
Record observation, not the author's evaluation. 'Thought for a long time before the button' is more useful than 'didn't understand the modern design.' A short video recording of the test is possible only after clear consent from the participants and according to your company's rules.
Flow, accessibility and safety
Well-functioning mechanics should work in a real flow, not only in a quiet meeting room. Check the waiting area and sightlines. Measure the duration of the main option, assess the passage to neighboring zones and the employee's actions during a surge. For equipment, coordinate power and cable routes. Separately, determine a safe way to stop the interactive.
Guidance from the UK Health and Safety Executive (HSE) recommends keeping pedestrian routes clear and not creating bottlenecks at activity points. This is not a Russian standard, but a useful engineering reference. Take mandatory requirements from the rules of the specific venue, design documentation, and instructions from responsible specialists.
For digital screens, you can rely on the Web Content Accessibility Guidelines (WCAG) 2.2. The AA level criterion sets a minimum target for a pointer of 24 by 24 CSS pixels or sufficient spacing between targets with specified exceptions. The W3C also recommends providing a conventional control as an alternative to a required gesture or device motion.
Test the mechanics in three modes:
- a single visitor completes the main option without assistance;
- several people approach almost simultaneously;
- the main device or network is unavailable.
The queue should not occupy a shared passage. Cables are removed from the route or protected in a way agreed with the venue. A visitor needs a way to go through the meaningful scenario without a precise gesture or mandatory body movement. Key audio information is useful to duplicate visually.
What to Rehearse Before Setup?
In short: The rehearsal tests the handover of a person between the mechanics and the team. Run through the main scenario and the crowd surge. Then act out a technical failure, a staff change, and stopping an unsafe action. Every failure must have a responsible person and a visible signal. A backup plan and a return condition are also needed.
Assign roles: the greeter briefly explains the start, the expert leads the substantive review, the flow manager monitors the queue, and the technical specialist can restart the system. One person can combine roles only where the actual workload allows it.
During the rehearsal, deliberately create several problems. Disconnect the network. Let a participant choose an unexpected path. Create a small queue. Ask to replace the expert. Check whether the team can continue the conversation without a screen and who makes the decision to stop.
It is useful to cross-check this block with the event crisis plan. The venue's emergency procedures remain a separate track: when people are at risk, the team follows the instructions of the responsible services, not the interactive scenario.
Data and the Next Step
The form at the stand collects data only for a pre-stated follow-up: send material, schedule a demonstration, prepare a quote, or connect with an expert. Federal Law No. 152-FZ requires a specific purpose and a proportionate amount of data. If consent serves as the basis, it must be separate, specific, and unambiguous.
Article 9 of No. 152-FZ requires consent to personal data processing to be executed separately from other information and documents that a person confirms. The specific form design, legal basis, data transfer, and retention period are checked by your company's responsible officer.
A badge scan alone does not give the team the context of the conversation. The work record needs the topic of interest, the promised next step, the responsible person, and the deadline. The set of fields must correspond to the purpose and internal data processing rules.
Before the exhibition, test the form on the device and connection that will be used at the stand. Make sure the data goes into the agreed system, the record is not lost when the button is pressed again, and the staff member sees a confirmation. When collecting data of Russian citizens, separately check the requirements of Article 18 of No. 152-FZ for the use of databases.
How to evaluate the estimate and results?
In brief: The estimate is compared across the full lifecycle of the mechanic. First, the scenario, prototype, and content are taken into account. Then development and equipment are calculated. Integration, installation, and on-site support are assessed together with backup. Results are checked against the original hypothesis and the actions completed after the exhibition.
The table brings together the key points of the section: Level, What to measure, What decision it supports. Use it as a quick guide when preparing your event.
| Level | What to measure | What decision it supports |
|---|---|---|
| Entry | stops and started scenarios | whether the signal from the entrance is clear |
| Completion | completions, declines, and retries | whether the mechanic is easy to use |
| Conversation | questions about target objectives | whether the experience leads to the product |
| Follow-up | assigned actions and owners | whether a contact can be handed over without losing context |
| Operation | queue, failures, and backup operation | whether the solution withstands the flow |
| Budget | plan vs. actual for major blocks | what to change or reuse |
Do not attribute the impact on the exhibition's entire revenue to a single interactive. First, set a goal and an observation period. The metrics matrix can be supplemented by our analysis of corporate event KPIs.
In the estimate, show scenario creation, prototyping, and testing separately. These tasks are easy to lose within the "development" line item, even though they are what make it possible to stop a weak idea before expensive production. For a repeatable stand, calculate which modules, equipment, and content can be used again.
The Decision After the Test
After the test, the team has three honest options: launch the mechanic, simplify it and test again, or drop the idea. Launching is justified when the visitor understands the starting point, performs the action, connects the result with the product, and the team can manage both the flow and a failure. A beautiful prototype without these signs is not yet ready for production.
Record the decision in a single document. Note the confirmed observations and the open risks. Set out the next version, the people responsible and the date of the follow-up rehearsal. Meaning and safety come first. Then accessibility and data handling are checked, and only after that does visual polishing begin.
At Aventura, we can build this path together with your team: turn a product task into a scenario, prepare a prototype, run the test, connect the mechanic with the stand space and coordinate the on-site implementation.
Frequently asked questions
The overall stand project is responsible for the space, the flow and the negotiations. You will find a detailed look at that system in the article “An exhibition stand as a funnel”. Here we take one narrower layer: how to come up with a mechanic, test it without a finished build, and decide whether it is worth putting into production.
A good hypothesis describes a specific visitor, their work task and the change that follows a short interaction. It does not start with the name of a device. First we decide what the person should understand, compare, try or discuss. Then we choose the medium that makes this action clear and achievable in exhibition conditions.
Put the scenario into a table. One row per step is enough.
The first prototype should test the meaning and the sequence, not the quality of the graphics. Use paper cards or clickable screens without complex logic. Automation can temporarily be replaced by a physical mock-up or a staff member. The visitor follows the scenario while the team watches the choices made and the transition to conversation.
Run the test in this order:
A working mechanic must function in a real flow, not only in a quiet meeting room. Check the waiting area and sight lines. Measure the duration of the main option, assess access to neighbouring zones and what a staff member does during a rush. For the equipment, agree on power supply and cable routes. Separately, define a safe way to stop the interactive.
To discuss an interactive for your exhibition, request a quote from us. Tell us the product, the audience, the venue and the action the visitor should perform.
Sources
- Principles of personal data processing: Article 5 of Federal Law No. 152-FZ.
- Consent of the data subject: Article 9 of Federal Law No. 152-FZ.
- Operator's obligations when collecting data: Article 18 of Federal Law No. 152-FZ.
- W3C WAI: Interactive target size in WCAG 2.2.
- W3C WAI: Alternative to motion actuation.
- Managing flow inside the venue: HSE guidance.
- Temporary electrical supply and cable routes: HSE guidance.
Contents
Was this article helpful?
