Buying a Bus Stop Information Display: Define the Data Before the Screen

A bus stop display becomes useful when passengers can understand the information and trust how it is presented. Screen size and enclosure design matter, but the purchasing brief should also explain where each message comes from, how it reaches the display and what happens when an update is unavailable.

Separate the information types

List route maps, timetables, predicted arrivals, disruptions and general public notices as distinct content requirements. Scheduled information and live predictions should be clearly identified. GTFS Realtime provides structures for trip updates, vehicle positions and service alerts, but the project must establish which feeds are actually available from the operator.

Name the data owner

Identify the transport authority, operator or integration partner responsible for the feed. Obtain the relevant documentation and a sample before promising a live service. Confirm stop identifiers, route naming, language requirements and the way changes will be communicated. A procurement schedule should allow time for the data provider and display supplier to work together.

Specify failure and fallback behavior

Ask what passengers see when the network is unavailable or the feed has not updated. A scheduled departure should not silently appear as a live prediction. GTFS guidance notes that missing realtime trip updates do not mean a trip is running on time. Define a clear fallback message, an update-status indication where appropriate and an escalation contact.

Review the passenger view

Use representative content to assess route identification, text size, contrast and the priority of service messages. Keep commercial content within an agreed information hierarchy. Review the display from the intended waiting area and consider whether people approaching the stop can find the right service without interacting with the screen.

Agree responsibilities at handover

The handover should name the teams responsible for transport data, message approval, CMS access, network service and hardware maintenance. Include a process for changed routes and relocated stops. Agree acceptance scenarios that cover normal operation, a disruption and loss of live data.

Before requesting a quotation, prepare the stop list, site layouts, proposed content, feed documentation and operating schedule. This shared brief helps the supplier assess the complete passenger information requirement and makes integration work visible before hardware is ordered.