Mukoko Studio · Digital experience review
Air Zimbabwe digital passenger experience: a working redesign concept by Mukoko.Studio
A review of airzimbabwe.aero and a proposal for a modern customer-facing shell that sits in front of, and hands off cleanly to, the airline's existing Hitit Crane reservation system.
Executive diagnosis
The issue is not simply how the site looks. It is task completion, trust and continuity
Air Zimbabwe already runs a capable passenger service system. The problem sits in the layer passengers actually meet: a marketing website and a reservation engine that behave like two separate products, joined by links that sometimes point at a staging environment.
Alongside that structural issue, the site carries content that should never have reached production: placeholder narrative copy on the contact page, an unrelated consultation offer and third-party privacy wording inside the baggage page, a spelling error in a statistics block, and seasonal promotions long past their date.
None of this requires replacing the PSS. It requires one shell, one information architecture, honest content with owners and expiry dates, and a properly specified production integration with Crane.
Findings
Severity-ranked findings, with evidence
Severity reflects the risk to a passenger completing a task, and to the airline's credibility. Evidence is drawn from the public site as observed.
01Public calls to action point at a staging booking environment
Critical- Evidence
- Several booking and servicing links on the public site resolve to azw-stage.crane.aero rather than a production address.
- Impact
- Passengers can land in a non-production environment. It damages trust, breaks measurement, and creates a support burden when a booking cannot be completed or found again.
- Recommendation
- Audit every outbound link, replace staging hosts with the production Crane endpoints supplied by the airline or Hitit, and add a build-time check that fails if a non-production host appears in published markup.
02The marketing site and the booking engine feel like two different products
Critical- Evidence
- Typography, layout, tone and navigation change the moment a passenger moves from the website into the reservation flow, and there is no route back into site content.
- Impact
- Passengers lose confidence at exactly the point where they are entering personal and payment details. Drop-off concentrates at the handoff.
- Recommendation
- One shell, one design language, one navigation model. Where Crane owns the screen, apply the airline's theme, carry the passenger's context across, and provide a consistent way back.
03Ambiguous and repeated booking labels
High- Evidence
- Check-in and manage-booking entry points are presented with a Search Flights style label, so three different tasks appear to do the same thing.
- Impact
- Passengers pick the wrong entry point, fail the task, and either abandon or call the contact centre.
- Recommendation
- Name each task in the passenger's words: Book a flight, Manage booking, Check in, Flight status. One panel, four tabs, four distinct submit labels.
04Duplicated navigation and information architecture
High- Evidence
- The same destinations appear in more than one menu structure, and contact and information pages repeat with different content in each place.
- Impact
- Nobody can be sure which page is authoritative. Content drifts apart over time, and search engines split ranking between duplicates.
- Recommendation
- A single IA with one canonical page per subject, redirects from retired duplicates, and a navigation model derived from the top passenger tasks.
05Unrelated commercial content inside the baggage page
High- Evidence
- The baggage page carries a Book Your Expert Session block, a consultation form and privacy copy referring to an unrelated organisation named Optimum.
- Impact
- It reads as an unfinished template. On a page about rules and allowances, foreign privacy wording is also a data-protection risk.
- Recommendation
- Strip the page back to baggage only, with allowances by fare, extras, restricted items and a single route to help. Remove third-party privacy text entirely.
06Placeholder and unrelated content on the contact page
High- Evidence
- The contact page carries placeholder narrative copy beginning “Far far away, behind the word mountains…”, and an FAQ entry reading “Will Altivion help with career placement?”, which belongs to a different organisation entirely.
- Impact
- The contact page is where anxious passengers arrive. Filler text there does more reputational damage than anywhere else on the site.
- Recommendation
- Rewrite as a single enquiry route with named channels, opening hours, an accessible form and a plain statement of how details are used.
07Typographical error and unsubstantiated statistics
Medium- Evidence
- A homepage statistics block reads Routes fullied Per Month, alongside figures with no source, date or definition.
- Impact
- A visible spelling error next to unverifiable numbers undermines confidence in everything else the airline publishes.
- Recommendation
- Remove the block. If performance figures are wanted, publish only measured numbers with a definition, a period and a named owner.
08Stale seasonal content
Medium- Evidence
- Seasonal promotional content, including Easter holiday messaging, remains published well outside its period.
- Impact
- Passengers cannot tell what is current, so they stop trusting notices, including the operational ones that matter.
- Recommendation
- Every promotional and notice item gets a publish date, an expiry date and an owner. Expired items unpublish automatically.
09No dependable flight status or disruption channel
Medium- Evidence
- Status and disruption information is not surfaced in a consistent, dated place in the passenger journey.
- Impact
- During disruption the contact centre absorbs demand that self-service should handle.
- Recommendation
- A permanent flight status page fed by the operational source, plus a compact notice component on the homepage that carries a timestamp.
10Mobile layout and tap-target quality
Low- Evidence
- Several interactive elements sit below comfortable touch size, and content reflows awkwardly at narrow widths.
- Impact
- Most Zimbabwean passengers arrive on a phone, often on a constrained connection.
- Recommendation
- Mobile-first layout, a minimum 44 by 44 pixel target for every control, and testing down to 320 pixels.
Passengers
What passengers are actually trying to do
Book a flight for a date I already know
Search in under a minute, with fares I can compare.
Change something about a booking I hold
Find the booking, see it in full, act on it without calling.
Check in and get a boarding pass
A short, guided flow that works on a phone.
Find out whether my flight is running
A dated answer, in words, not just a colour.
Know what I can take with me
Allowances tied to the fare I actually bought.
Ask for assistance
One request that follows me across every flight.
Before and after
What changes, in practice
| Area | Now | Proposed |
|---|---|---|
| Hero | Rotating imagery with a small booking widget competing with promotional messages. | One dominant booking panel with four clearly named tasks, above the fold on a phone. |
| Booking entry | Three tasks sharing near-identical Search Flights labels. | Book, Manage, Check in and Flight status, each with its own form and submit wording. |
| Handoff | A jump into a differently branded, sometimes staging, environment. | A themed, contextual handoff into production Crane, with the passenger's search carried across. |
| Baggage | Allowances mixed with an unrelated consultation offer and third-party privacy copy. | Allowance by fare family, extras, restricted items and one route to help. |
| Contact | Placeholder narrative text and questions belonging to another organisation. | One enquiry route with channels, hours, an accessible form and a plain data statement. |
| Notices | Out-of-season promotions with no dates. | A compact notice component with publish and expiry dates, and an owner. |
Principles
Six rules the redesign is held to
Task first
Every screen opens with the thing the passenger came to do, not with marketing.
Mobile first
Designed at 320 pixels upward, with 44 pixel targets and thumb-reachable actions.
One airline experience
Content and booking share a shell, a language and a way back.
Trustworthy content
Dated, owned, sourced. No unverifiable figures, no filler, no stale seasons.
Accessible by default
WCAG 2.2 AA as the working standard, tested with keyboard and screen reader.
Resilient under low bandwidth
Light pages, progressive rendering, no dependence on heavy scripts to complete a task.
Information architecture
One page per subject, named the way passengers name it
Home
├── Book (booking panel: book · manage · check in · flight status)
│ └── Results → fare selection → handoff to Crane (production)
├── Destinations
│ ├── Zimbabwe: Harare · Bulawayo · Victoria Falls · Mutare
│ └── Regional and long haul: Johannesburg · Dar es Salaam · London Gatwick
├── Travel info
│ ├── Check-in and airport timings
│ ├── Documents and entry requirements
│ └── On board
├── Baggage
├── Special assistance
├── Flight status
├── Manage booking
├── Check in
└── Help
├── Contact
└── Feedback and complaintsIntegration strategy
Hitit Crane stays. The seams around it go
Crane stays the system of record
Hitit Crane remains the PSS. Nothing in this proposal reimplements inventory, pricing, ticketing or departure control. The shell is a front door and an orchestration layer, not a replacement.
Replace staging links with production endpoints
Every azw-stage.crane.aero reference is removed. Production endpoints and any theming or deep-link parameters are supplied by the airline and Hitit under change control.
Carry context across the handoff
Origin, destination, dates, passenger mix and cabin travel with the passenger into Crane IBE, so nothing is retyped. On return, the passenger lands back in site context, not on a dead end.
Keep the PCI boundary inside booking and payment
Card data never touches the marketing shell. Payment and ticketing stay entirely within the Crane environment and its existing compliance scope.
Theme rather than rebuild
Where Crane supports branding, the airline's palette, typography and language are applied so the visual break at the handoff largely disappears.
Instrument both sides
Events on the shell and confirmed handoffs into Crane are measured together, so drop-off at the boundary is finally visible.
Accessibility
WCAG 2.2 AA as the working standard
- Status and error states carry text and icons, never colour alone.
- Every control reaches 44 by 44 pixels, with visible focus styling.
- Forms use real labels, described errors and live regions for results.
- Keyboard-only and screen reader passes on every core journey.
- Motion respects the reduced-motion preference.
- Conformance tested and recorded, not assumed.
Content governance
Nothing is published without an owner
- Every page and notice carries an owner, a publish date and a review date.
- Promotional and seasonal items carry an expiry and unpublish automatically.
- Statistics need a definition, a source, a period and an approver.
- A quarterly review sweep covers fares, allowances and destination content.
- One canonical page per subject, with redirects from anything retired.
Measurement
What we would hold ourselves to
| Indicator | How it is measured |
|---|---|
| Booking search completion | Share of started searches reaching a results page |
| Handoff success | Share of fare selections that arrive intact in Crane |
| Manage booking success | Share of retrieval attempts that surface an itinerary |
| Check-in completion | Share of started check-ins that finish online |
| Error rate | Form and journey errors per thousand sessions, trending down |
| Contact deflection | Calls and emails per thousand sessions on self-service topics |
| Mobile conversion | Mobile completion measured against desktop as a ratio |
| Core Web Vitals | LCP, INP and CLS within the good threshold on 3G-class connections |
Baselines are set in Phase 0, before anything changes, so improvement can be attributed honestly.
Roadmap
Live in two weeks, in four phases that each ship something usable
Phases 0 to 2 are delivered inside a fourteen day window, with Crane integration dependent on production endpoints and credentials being available from day one. Phase 3 continues after launch.
Phase 0
Baseline and content cleanup
Days 1 to 3
- Full link audit, staging references removed
- Placeholder, duplicated and third-party copy stripped
- Stale seasonal content unpublished
- Analytics baseline and accessibility audit recorded
Phase 1
New shell and content migration
Days 4 to 8
- Design system, component library and accessible patterns
- New IA, navigation and homepage booking panel
- Destinations, travel info, baggage, assistance and contact rebuilt
- Content governance model in place with owners and expiry dates
Phase 2
Production Crane integration and end-to-end journeys
Days 9 to 14
- Production endpoints, themed handoff, context carried across
- Manage booking, check in and flight status wired to live sources
- Journey instrumentation across the boundary
- Load and low-bandwidth testing before launch
Phase 3
Personalisation, loyalty and disruption comms
Post-launch, ongoing
- Returning passenger recognition and saved travellers
- Loyalty surface if and when the programme is ready
- Proactive disruption messaging by email and SMS
- Continuous measurement against the KPI set
Timings are indicative and depend on content availability and the airline's and Hitit's change-control windows.
Mukoko Studio deliverables
What you would receive
- Experience audit with severity ranking and evidence
- Passenger research synthesis and jobs-to-be-done map
- Information architecture and content model
- Design system: tokens, components, accessible patterns
- High-fidelity design for every core journey, mobile first
- Front-end build with the Crane handoff specification
- Content governance model, owners, review cycles and expiry rules
- Accessibility conformance testing against WCAG 2.2 AA
- Analytics implementation and a KPI dashboard
- Handover documentation and team training
Give passengers one journey, not a website and a booking engine
The prototype attached to this proposal is a working demonstration of the first two phases. We would be glad to walk the team through it and agree a Phase 0 scope.
Disclaimer
This is an independent, unsolicited concept study produced by Mukoko Studio. It is not affiliated with, endorsed by or commissioned by Air Zimbabwe or Hitit. Observations describe the public website as viewed at the time of writing and may change. All fares, schedules, statuses and bookings in the prototype are illustrative sample data. No live systems are connected, no personal data is collected and no payment can be taken. Brand elements are approximations used to show how a redesign could respect the airline's existing identity.