Someone opens a metro guide on their phone. They are trying to understand where to change trains, but the page starts with a large video, a full-screen promotion, and a map that has not finished loading.
The information may be somewhere on the page. Right now, it is difficult to reach.
That is a useful design problem for web developers.
A travel guide needs to work when the reader has limited time, an unfamiliar place to navigate, and a connection that may be slow or unreliable. A beautiful desktop layout is only part of the job.
I run the independent BurJuman Metro Station guide. Using a station guide as an example, this article explores how to organise useful travel information and deliver it through a lightweight, readable website.
These are proposed design and testing practices, not a claim that every feature has already been implemented on my site.
Disclosure: I run the website linked in this article. It is independent of Dubai’s Roads and Transport Authority. This article was prepared with AI assistance.
Start With the Traveller’s Immediate Question
A station page can cover history, facilities, nearby places, tickets, and routes. Those subjects do not all deserve the same position.
A person checking the page during a journey may need one answer:
- Is this the station where I change lines?
- Which direction should I follow?
- Where can I check current service information?
- How do I continue to my destination?
Start with the station name and a short explanation of its role.
BurJuman is an interchange between Dubai Metro’s Red and Green Lines. RTA lists its station codes as R19 and G26.
That gives a reader useful orientation before they reach the longer content.
Historical background can come later. It should not stand between the visitor and the information needed for the next step of a journey.
A useful design question is:
If the reader only sees the first screen, will they understand what this page can help them do?
Separate General Information From Current Conditions
Some information changes less often than other information.
A station’s general role in a network is different from tonight’s last departure, a temporary closure, or a lift outage.
Treating these as one undated block makes the page harder to maintain and easier to misunderstand.
A practical content plan might look like this:
| Information | How to handle it |
|---|---|
| Station name and connecting lines | Verify against the operator’s network information |
| General explanation of changing lines | Write clearly and review when the network changes |
| Opening hours and last departures | Check current operator information and show the relevant date |
| Fare information | Explain applicable conditions and verify current rules |
| Temporary disruptions | Use a current authoritative source |
| Accessibility availability | Distinguish permanent facilities from temporary outages |
Do not label manually written information as “live.”
Also distinguish a page’s editing date from the date its travel details were checked. Fixing a spelling mistake does not mean the timetable has been verified again.
If a field has not been checked recently, make that limitation visible.
Give the Page a Useful HTML Foundation
A guide should not need a complex application just to show a station name and a few paragraphs.
Serve the essential content in HTML so the browser can display it without waiting for optional interactive features.
Use ordinary links for navigation. Keep headings meaningful. Make the main information available before loading extras such as an interactive map.
This is an application of progressive enhancement: begin with a useful basic experience, then add features where the browser and connection support them.
Habdul Hazeez’s introduction to progressive enhancement provides a useful explanation of this approach.
For a metro guide, the basic version might contain:
- A station overview.
- Connecting line names.
- Short travel explanations.
- Links to current operator information.
- A readable list of common questions.
A map can improve that experience, but it should not be the only way to understand the page.
Organise Sections Around Real Decisions
Headings should help someone find an answer quickly.
“Where Is the Station?” is clearer than “Discover an Amazing Transport Hub.”
“Changing Between Lines” is more useful than “Enjoy Seamless Connectivity.”
For a long station page, a short contents list can link to sections such as:
- Station overview.
- Location.
- Changing lines.
- Tickets and fares.
- Accessibility.
- Current service information.
Give each destination heading a stable section ID. Test every contents link after changing the layout.
If the site uses a fixed header, make sure jumping to a section does not hide the heading behind it.
The same approach could make the BurJuman station overview easier to navigate as its content develops. The goal is to help readers reach the relevant section without forcing them through the entire page.
Make the Text Comfortable on a Phone
A page that technically fits on a small screen can still be uncomfortable to read.
Watch for long lines, tight spacing, small controls, and wide tables.
Use short paragraphs, clear headings, and enough space between links to reduce accidental taps.
Keep important information as text rather than placing it inside a banner image. Text is easier to resize, translate, search, and read with assistive technology.
Transit line names should also appear in words. Red and green colours can support the design, but they should not carry the meaning alone.
Avoid placing essential information in a hover-only menu. Phone users need controls they can tap, and keyboard users need controls they can reach.
If a table is too wide, consider presenting the information as short labelled sections. Do not shrink the text until it becomes difficult to read.
Use Images With a Clear Purpose
An image should help explain the page or establish its context.
A verified entrance photograph can help someone recognise a location. A decorative skyline image serves a different purpose.
Neither should be mistaken for a route map.
Choose image dimensions that suit the layout. A phone does not always need the same image file as a large desktop display.
Compress photographs while checking that useful details remain visible. A small file is helpful, but unreadable signs or blurry route information defeat the purpose.
Reserve space for images before they load. Otherwise, a late-loading photograph can push text or links away just as someone tries to tap.
Images further down the page can usually wait until they are near the visible area. Avoid delaying an important image at the top of the page without checking the effect.
If an image is AI-generated, do not present it as a real station photograph. It should never be used to prove an entrance location, platform layout, or walking route.
Write Alt Text for the Image’s Actual Role
Alt text should explain the useful information an image contributes.
For a verified station entrance photo, describe the relevant entrance and any visible detail that helps the reader recognise it.
For a decorative image, an empty text alternative may be appropriate.
A complex route diagram needs more than a short label such as “metro map.” Provide the important route information in nearby text or another complete text alternative.
Avoid filling alt text with repeated keywords. Someone listening to the page needs a meaningful description, not a list of search phrases.
Also remember that alt text cannot make an inaccurate image reliable. The image itself must be suitable for the claim being made.
Load Maps When They Are Needed
An embedded map can bring extra scripts and network requests.
If the page’s main purpose is to explain a station, consider showing a short location description first and offering a clearly labelled option to open a map.
That lets the visitor decide whether they need the heavier feature.
If the map fails, keep the written location information available. Show a useful message rather than leaving a blank rectangle.
Do not promise an exact walking time without checking the route and its assumptions. Distance alone does not account for crossings, access restrictions, weather, or mobility needs.
Likewise, an exit number is only useful when it has been verified. Guessing a precise detail can create more confusion than leaving it out.
Be Careful With Saved and Offline Pages
Saving a guide can be useful before travelling.
However, saved content may become outdated.
If you add offline support, clearly distinguish saved general information from current service conditions. Show when the saved content was checked and explain that it cannot confirm present disruptions.
For a first version, a clean print layout may be enough. It can let readers save the guide as a PDF without building a more complex offline system.
Do not claim offline support until you test the intended behaviour. A page that happens to remain visible in one open tab is not proof that it will reopen reliably without a connection.
Timetable and disruption information deserve particular caution. Old operational details should not look like fresh updates.
Test the Reading Journey, Not Just the Homepage
Start with a concrete task:
Find which lines connect at the station, then find where to check current service information.
Try completing it under different conditions.
Use a narrow screen, a slower network setting, enlarged text, and keyboard navigation. Temporarily block optional scripts and check whether the important content remains available.
A useful test list includes:
| Test | What to look for |
|---|---|
| Slow connection | Important text appears before optional features |
| JavaScript unavailable | Core content and ordinary links remain usable |
| Images blocked | Essential travel information is still understandable |
| Narrow screen | Text fits without unnecessary horizontal scrolling |
| Enlarged text | Content remains visible and controls do not overlap |
| Keyboard navigation | Links and buttons have a logical order and visible focus |
| Map failure | Written location information remains available |
| Section navigation | Links reach the correct heading |
| Old saved page | Its date and limitations remain clear |
Automated checks can help identify problems, but they cannot tell you whether a travel instruction makes sense.
Ask someone unfamiliar with the page to complete the task. Watch where they hesitate.
Measure Changes Without Inventing Results
Before optimising a page, record a baseline.
Note the device or test environment, network setting, page version, and the task being tested.
Then change one meaningful thing, such as reducing the cover image size or delaying a map.
Repeat the test under comparable conditions.
Do not claim that a change made the site “twice as fast” unless your measurements support that statement. A desktop test on a strong connection does not describe every traveller’s experience.
Page speed also has several parts. The first text might appear quickly while a large layout shift later makes the page difficult to use.
For a guide, the practical question is whether someone can read and act on the important information without avoidable delays.
Keep the Independent Guide’s Role Clear
An independent travel website can explain concepts, organise information, and help visitors prepare questions.
It should not imply that it operates the railway or provides official live updates.
For the independent BurJuman Metro guide, the useful role is to help readers understand the station while directing time-sensitive decisions to current RTA information and station guidance.
The same principle applies to other local travel websites.
Clear ownership, sensible source attribution, and an easy way to report errors help readers understand who is responsible for the content.
A helpful guide earns trust through accurate explanations and honest limits.
Build Around the Reader’s Next Step
A successful metro guide does not need to keep someone on the page for as long as possible.
Sometimes the best result is that they find their answer quickly and continue their journey.
Put the main information first. Keep the page readable on a phone. Make optional features optional. Explain when information was checked, and avoid presenting saved content as live.
These decisions make a station guide a useful web-development project. They bring together content structure, accessibility, performance, and maintenance around a clear human need.
Before adding another visual feature, ask whether it helps the traveller take their next step.
Top comments (0)