Before choosing a device or drawing a screen, describe the customer’s task from beginning to end. Use ordinary language and include what happens immediately before and after the kiosk interaction.

A simple journey map might record:

• why the customer has arrived and what they are trying to complete;
• what reference, booking or other information they may already have;
• the choices they need to understand;
• any details the organisation needs to collect or confirm;
• the exceptions that should involve a member of staff;
• the record, instruction or next step created when the task is complete; and
• what the customer sees or receives as confirmation.

This prevents the kiosk from becoming an isolated form. It also reveals work that a screen alone cannot solve. If staff must still re-enter the same details, search another system or decide what happened after a customer leaves, the user-facing journey may look tidy while the operational process remains fragmented.

Talk to the people who currently perform the work as well as the customers who use the service. Staff often know which missing detail causes a delay, which wording prompts questions and which apparently simple case actually needs judgement. Customers can show where instructions are unclear or where the expected next step is not obvious.

A kiosk is used in a shared place, often by somebody who wants to complete a task and move on. Each screen should make the current decision clear without expecting the person to study a dense page.

Use a short heading that says what is needed. Keep the main action easy to identify. Put supporting detail beside the choice it explains, rather than in a long introduction. When several options are genuinely required, use familiar descriptions and show the practical difference between them.

The journey should also make movement predictable. People need to know whether they can go back, review information or correct a mistake. A clear progress cue can help on a longer task, but it should reflect meaningful stages rather than decorate every screen with an arbitrary step number.

Avoid asking for information simply because a field exists in another system. Every question adds effort and another opportunity for uncertainty. If a detail is not needed to complete the task or the connected workflow, challenge why it appears at the kiosk.

The screen is only one part of the experience. Its position, surroundings and the time available all affect whether the interface is comfortable to use.

Check whether instructions remain readable in the actual lighting. Consider whether somebody can approach, understand and operate the kiosk without blocking the route for others. Think about privacy when information appears on a screen in a public area. If a customer needs to consult a reference or speak to a colleague, the journey should not punish a brief pause.

Buttons, text and choices need to suit the display and the expected viewing distance. Important controls should not depend on fine pointer movement or tiny targets. Colour can support meaning, but it should not carry the whole message by itself. Plain wording, a consistent layout and a forgiving route to correct errors matter more than visual novelty.

These decisions should be tested on the intended equipment and in the intended setting. A design that feels clear on a designer’s laptop may feel very different when the customer is standing, carrying something, working around glare or aware that other people are waiting.

Self-service should be a choice that makes a task easier, not a barrier between the customer and the organisation. Some people will need help because the task is unfamiliar, confidence is low, information is missing or the standard route does not match their situation.

The kiosk should explain what to do when that happens. Depending on the service, that may mean speaking to nearby staff, using a clearly signposted contact route or leaving the kiosk without losing information already confirmed. The right approach depends on the setting and the organisation’s support model.

GOV.UK guidance on assisted digital support recommends researching what help users need and planning appropriate support. Although that guidance is written for government services, the practical principle is wider: do not assume every customer can or will complete a digital journey in the same way.

Make the help route easy to find before frustration builds. Staff should also know what the customer has already done and what they need next, where the organisation’s permissions and process allow it. A handover that begins with the customer repeating every detail is not a connected service.

A kiosk is most useful when it is designed as part of the wider process rather than as an isolated screen. The completion action should create a clear business event: a request is recorded, an arrival is recognised, a collection is ready for the next stage or a staff task is created for review.

That connection should be planned from the start. Agree which system holds the trusted record, which information can be shown or changed, what validation is needed and who owns an exception. If the kiosk cannot reach a connected service, decide how the customer and staff will be informed and how the work can continue safely.

Axisware’s public self-service kiosk example illustrates the broad principle of joining the user interaction to an underlying operational workflow. It does not mean every kiosk needs the same process or equipment. Axisware can design bespoke kiosk applications that connect the user interaction to the underlying business workflow, shaped around the organisation’s actual task.

This is where workflow automation can add practical value. The kiosk can be one point in a sequence that includes staff checks, records, documents and follow-up. The design should keep responsibility visible rather than hiding the next decision behind an automatic action.

Real services contain ordinary exceptions. A reference may not be recognised. A customer may choose the wrong route. Required information may be unavailable. The connected system may return a result that needs staff judgement.

Do not leave these situations until the end of the project. List them beside the standard journey and agree a useful response for each one. A good response explains what has happened in calm language, preserves anything that can safely be retained and offers a clear next step.

Avoid messages such as “invalid input” or “operation failed” without explanation. Say which detail needs attention and how the customer can correct it. If staff help is required, say so directly. Never encourage somebody to keep repeating an action when the underlying issue needs a different route.

Also plan for interruption. The customer may walk away, the session may take too long or the service may become unavailable. The kiosk should protect the next person’s privacy and return to a safe starting point. The precise behaviour depends on the information involved and must be agreed as part of the wider process.

Technical testing confirms that the software behaves as designed. Usability testing asks whether people can understand that design well enough to complete the task.

Give representative users realistic scenarios and observe where they pause, choose an unexpected route or ask for help. Do not guide them through the interface unless that support is part of the planned service. Include people with different levels of familiarity and confidence, and test the exceptions as well as the straightforward path.

Useful questions include:

• Can the person explain what the kiosk is for before they begin?
• Do they know what information they need?
• Can they recognise the right choice without guessing?
• Can they correct a mistake without starting again?
• Do they understand when the task is complete?
• Can they find help when the standard route does not fit?
• Does the connected staff process receive what it needs?

Record the points that cause confusion and change the design before adding more features. Completion, corrections, requests for help and abandoned journeys can all provide useful evidence once the service is live, provided those measures are interpreted with staff and customer feedback.

A practical first release does not need to cover every customer request. Choose one valuable, repeatable journey with a clear beginning and end. Keep the scope narrow enough to test in the real setting and include the wider operational hand-offs from the outset.

A sensible sequence is:

1. map the customer task and the current staff process;
2. identify the minimum information and choices needed;
3. agree the trusted records and connected workflow;
4. design the standard journey and its common exceptions;
5. define the route to staff help;
6. prototype the screens on the intended equipment;
7. test realistic tasks with representative users; and
8. review completion evidence and feedback before expanding the service.

This approach makes it easier to discover whether the kiosk genuinely helps. It also gives staff time to understand the new hand-offs and refine how support works around the self-service route.

The best kiosk is not the one with the most impressive opening screen. It is the one that helps a customer understand the task, make the right choices, recover from a problem and reach a clear finish while the organisation receives the information needed for the next step.

That requires more than interface design. It brings together the physical setting, plain language, user support, connected records, staff decisions and operational follow-up. Bespoke software development gives an organisation the opportunity to shape those parts around its real service rather than force the journey into an unrelated template.

If you would like to explore a practical kiosk service journey, contact the Axisware team. We can map one customer task, its exceptions and its wider workflow before discussing the right interface or equipment.