Qantas Rewards

Helping members discover one more thing

Qantas Frequent Flyer is one of Australia's most recognised loyalty programmes. Its scale is a considerable strength: members can earn and use points across flights, hotels, financial products, retail and a growing network of partners.

That breadth also creates a discovery problem. Recognition does not automatically translate into understanding, and even established members may only know the parts of the programme they already use. Every additional service increases the potential value of membership while making the whole ecosystem harder to hold in mind.

The engagement began with a simple ambition: help each member discover one more useful thing they did not know the programme could do, then give them a clearer reason to put their points to work sooner.

Working with ustwo on Qantas Loyalty's Digital Customer Experience programme, I moved between product discovery, technology and rapid prototyping. We were not handed a predetermined feature to deliver. Our job was to turn a broad opportunity into a smaller set of credible directions before Qantas committed to building them.

Turning breadth into relevance

The challenge went beyond navigation. Placing every available service in front of a member would show the scale of the programme without necessarily making any of it more useful.

The experience needed to reveal breadth selectively. A member should be able to encounter an opportunity that felt relevant to their circumstances, understand how it related to their points and decide what to do next without first learning the structure of the entire programme.

I found it more useful to ask “what is the next valuable thing for this person to understand?” than “how do we explain everything?” The first question tends towards catalogues and information architecture. The second opens up product directions around timing, context and progressive discovery.

The work was scoped as a mobile product experience rather than a redesign of the existing web estate. That boundary gave the team a clear environment in which to explore the idea, while still leaving a wide range of possible behaviours, data sources and partner services to evaluate.

Understanding the system before drawing the interface

Before I could trust a prototype, I needed to understand the landscape beneath it.

The technical journal — kept live through discovery

I ran a technical exploration across the existing customer touchpoints, the services that supported them and the core systems underneath. External capabilities were assessed alongside the internal platform where they could extend what was possible—for example, connecting transaction activity with relevant partner offers.

I kept the work in a living technical journal instead of waiting to write a report at the end. Questions, dependencies and changes in our understanding stayed visible throughout discovery. Designers, technologists and client stakeholders could use it as a shared reference while the concepts were still moving.

Two complementary views emerged from that journal. One mapped the wider ecosystem in layers, showing how customer experiences related to supporting services and foundational systems. The other followed individual concepts in more detail, tracing how information would need to move between Qantas and its partners for an experience to work.

These were working product tools, not architecture documentation for its own sake. They helped us ask which ideas could be supported now, which needed additional capability and which depended on assumptions the programme could not yet verify.

Designing across the present and the future

Large organisations carry both mature capabilities and promising ones that are not ready to support a customer proposition. Discovery can easily blur that distinction, especially when a future-state concept is persuasive in a presentation.

The technical landscape made readiness part of the creative process. Concepts using services already in operation could be treated differently from ideas that depended on new data, an unproven partner or a connection that had not yet been established. Future-facing opportunities remained visible, but they were labelled honestly rather than presented as if the difficult parts had already been solved.

That kept the prototypes from becoming polished fiction. It also gave Qantas more useful options than “build” or “discard”. A valuable direction could be sequenced: test the customer proposition, identify the capability it required and then decide whether enabling that capability justified the investment.

Feasibility did not narrow the creative space. It gave each idea a more honest place within it.

Giving ideas a shared scorecard

Discovery at this scale produces more ideas than any programme can responsibly pursue. The useful work lies in deciding which ones deserve the next round of attention.

We assessed each feature concept through a scorecard that brought potential member value and technical feasibility into the same decision. Design and engineering shaped the evaluation together from the beginning, instead of producing separate recommendations and negotiating the difference later.

An idea with a strong customer proposition but immature dependencies could remain strategically interesting without being mistaken for an immediate delivery candidate. A concept supported by existing services could move forward sooner, provided it offered enough value to justify doing so.

The scorecard turned a broad collection of possibilities into a sequence of decisions. It gave us a consistent basis for selecting what to prototype, showed leadership where the real trade-offs sat and connected near-term delivery options to the longer-term capabilities they might unlock.

Ideation — concepts scored on value and feasibility together

Prototyping to decide

Rapid prototypes made the strongest directions tangible enough to evaluate before the cost of changing them became significant.

The prototypes were not meant to imitate a finished Qantas product or suggest that implementation had already been solved. We used each one to make a decision: expose the intended member behaviour, test whether the value was understandable and reveal where the concept depended on data or services that were not yet available.

Because the technical investigation and experience design progressed together, the prototypes could stay ambitious without becoming detached from reality. Existing capabilities were used as anchors. Uncertain dependencies were made explicit. The team could then discuss an idea as a complete proposition—what it offered the member, what it asked of the organisation and what would have to be true for it to reach production.

That was the value of rapid prototyping in an enterprise setting. Moving quickly let us reach the difficult questions before they became expensive.

The outcome, and an early stop

The engagement ended earlier than planned as the COVID-19 pandemic began. We did not get to carry the work through the full validation and delivery sequence we had expected.

Before it stopped, we produced a technically grounded set of directions for the Qantas Frequent Flyer mobile experience, supported by a shared landscape map, detailed service views, a feasibility scorecard and rapid prototypes. Those artefacts gave the wider team a clearer basis for action. Qantas could distinguish ideas ready for further validation from those requiring additional platform or partner capability, and leadership could compare options with a fuller view of customer value and delivery reality.

The outcome was never intended to be a production application, but the early ending placed a firmer boundary around what we could claim. We reduced uncertainty and translated a broad ambition into testable propositions, visible dependencies and credible next steps. We did not get to see those directions through to production.

The experience left me with a practical lesson. In a product ecosystem this large, ideas are rarely the scarce resource. The bigger risk is letting an attractive idea travel too far before discovering that the organisation cannot support it, or that members do not need it. Bringing desirability and feasibility together early made the discovery useful to the people who would eventually have to decide what happened next.