Re-imagining the ABC iView experience

Re-imagining
the ABC iView experience

Re-imagining the ABC iView experience

Reimagining the ABC iView experience

Re-imagining the ABC iView experience

ABC

iView App

The iView experience needed a refresh, and I had the priviledge of leading the visual design on the project. Used by millions of Australians each day, the app and website need to offer an intuitive, engaging experience while allowing users to easily discover content. The project involved multiple user testing sessions to establish which models proved best suited to the user needs.

The iView experience needed a refresh, and I had the priviledge of leading the visual design on the project.

Used by millions of Australians each day, the app and website need to offer an intuitive, engaging experience while allowing users to easily discover content.

The project involved multiple user testing sessions to establish which models proved best suited to the user needs.

RESPONSIBILITIES

UI Design, UX, Interaction Design, User Testing

iView-hero

An established player

Humble beginnings

The iView app has over 3 million users across Australia. With a website refresh underway it was time to look at the existing iView experience and bring it in line with the wider ABC products.

The app was dated and users were experiencing difficulties finding content. In addition the player itself lacked the kind of functionality that modern video delivery products provide, such as the ability to continue playing an episode when returning to the app, or automatically playing the next episode in a series.

This meant that the app was struggling in a now very competetive market, with multiple alternative products providing a superior user experience.

iView-existing

Researching competitor products

When looking at redesigning a VOD service it is important to carry out a detailed analysis of current and emerging patterns and interactions across the space. I signed up for multiple competing VOD services, and began exploring how they solved similar problems to the ABC, and which of those solutions worked (or didn't). 

I also took screenshots in order to better analyse elements like type and icon sizing, and spacing across platforms and devices. This allowed me to be fully aware of the product space before embarking on the design journey.

ultimate-streaming-guide-au

Prototyping and validating the solutions

I came up with three main solutions that I wanted to validate with users, so I created protoypes in InVision using screens from Sketch. These were stitched together and a series of tasks was settled on which would adequetly test the prototypes.

I carried out guerilla testing in the ABC lobby, which at the time acted as a throughfare for pedestrians travelling between The goods Line and Harris Street in Ultimo, Sydney. There was plenty of room, with sofas and low tables to help facilitate testing sessions. There was no shortage of people to validate my designs with, presumably because they feel somewhat invested in the ABC.

I used these guerilla testing sessions frequently, as they required little planning and I could get feedback almost continuously on the varous solutions.

As well as these informal testing sessions, I also set up in-office testing sessions, where I would have a much more controlled environment and be able to record video of the sessions. In total I tested 5 users in this environment, and the resulting insights were invaluable in ironing out any last issues, and also provided more convincing evidence for senior stakeholders.

NSW-ABC-Foyer-700-Harris-6
postits
iview_wf-1

Understanding the programme lifecycle

One of the major challenges in designing the iView platform was understanding the complex relationship between the ABC, content licensing and the way these impact the user experience.

Each programme and feature has a lifecycle - when it first gets promoted, when it becomes live, when each episode becomes available and when each episode is no longer available. 

Additionally, some programmes move from being free to view to being purchasable on iTunes.

This creates user experience issues, for example when a programme ceases to be available before a user has finished watching the series. 

Program Lifecycle – Service Design – Confluence

The onboarding experience

Streaming platforms live or die by their first impression. When a user downloads iView, they arrive with intent—but that intent is fragile. A clunky onboarding experience, or one that feels like administrative box-ticking, squanders the narrow window between installation and abandonment.

This project explored how behavioural design principles could transform iView's onboarding from a data capture exercise into a genuine value exchange. The goal wasn't simply to collect preferences—it was to create psychological investment that would increase activation, retention, and long-term engagement.

I developed two distinct approaches, each grounded in different behavioural frameworks and optimised for different user motivations. Both share a common foundation: onboarding should feel like the product has already started, not like a gate standing in front of it.

Key functional questions

When do we ask people to sign up?
Should users create an account before or after they've picked their preferences? Asking later means they get to the good stuff faster. Asking first means their choices are saved from the start. 

Profile sharing/switching: If multiple people share a device (common in households), do we support profiles from day one, or introduce this later?

Implicit vs. explicit preference updates: How aggressively do we infer preferences from viewing behaviour vs. periodically asking users to update their profile?

Using behavioural hooks

Endowed progress
Progress bar starts at 20%, visually accelerates as you advance

Progressive disclosure
Sub-genre screen content changes based on mood selections

Variable reward preview
Content thumbnails appear after making sub-genre selections

IKEA effect
Profile card consolidates all choices into an "artefact" the user built

Identity reinforcement
Personalised label ("The Curious Explorer") gives them a name for their viewing self

Approach 1: The Profile Builder

Concept

Users answer a series of questions about their viewing preferences - starting with broad mood-based categories ("I want to escape", "I want to learn"), then drilling into sub-genres and content attributes. The journey culminates in a personalised "viewing profile" that reflects their choices back to them, complete with a generated label like "The Curious Explorer."

Behavioural Framework

This approach leans on identity reinforcement and the IKEA effect. By asking users to articulate who they are as viewers, we activate consistency bias; people act in accordance with their stated identity. The profile becomes a psychological anchor, and the effort invested in creating it raises switching costs.

Pros
  • Captures rich, explicit preference data that powers accurate recommendations from day one
  • Creates emotional resonance - users feel understood, not processed
  • The profile artefact provides a memorable moment and a reason to return ("my iView")
  • Works well for users who enjoy self-reflection and appreciate personalisation
  • Scales cleanly across content categories without needing extensive media assets
Cons
  • Relies on users accurately knowing and articulating their preferences (which research suggests is unreliable)
  • Longer flow with more steps - higher risk of abandonment
  • May feel effortful for casual viewers who just want to watch something
  • Abstract categories can be difficult to map to actual content decisions
1a
2a
3a
4a
5a
6a

Approach 2: The Taste Test

Concept

Users swipe through a curated sequence of content cards, saving what interests them and skipping what doesn't. There's no explicit preference capture - instead, the system infers taste from behaviour. Users leave onboarding with a functional watchlist ready to play.

Behavioural Framework

This approach leverages recognition over recall - people are far better at reacting to concrete options than articulating abstract preferences. The swipe mechanic introduces variable reward psychology (each card is a small surprise), while the growing watchlist creates visible progress and immediate utility.

Pros
  • Lower cognitive load - users react rather than reflect
  • Captures implicit preferences that may be more accurate than self-reported data
  • Delivers tangible value immediately (a watchlist they can use tonight)
  • Gamified interaction feels lighter and more engaging
  • Natural content discovery mechanism that doubles as marketing
Cons
  • Relies on users accurately knowing and articulating their preferences (which research suggests is unreliable)
  • Longer flow with more steps - higher risk of abandonment
  • May feel effortful for casual viewers who just want to watch something
  • Abstract categories can be difficult to map to actual content decisions
1b
2b
3b
4b

User testing

Method

I ran moderated remote sessions through UserTesting.com with 12 participants across two rounds. Participants were Australian adults aged 25–54 who had used at least one streaming service in the past month but were not current iView users. This ensured familiarity with streaming conventions without existing expectations of iView specifically

Each participant was randomly assigned to one of the two prototypes. Sessions lasted 15–20 minutes and included a think-aloud walkthrough followed by a short post-task interview.

Tasks
  • Open-ended start: "You've just downloaded the ABC iView app. Go ahead and set it up however feels natural to you."
  • Comprehension check: "In your own words, what was that experience trying to do?"
  • Preference articulation: "How confident are you that iView now understands what you like to watch?" (1–5 scale)
  • Immediate intent: "What would you do next - watch something now, or come back later?"
  • Comparative reflection (post-task): Participants were shown a brief walkthrough of the alternate approach and asked which they'd prefer if downloading the app today.
Insights
1. The Taste Test was faster, but the Profile Builder felt more personal

Participants who used the Profile Builder described the experience as "thoughtful" and "like it actually cared what I wanted." Taste Test users completed faster and with less friction, but several noted it felt "a bit random" or "like Tinder for TV." Speed didn't translate directly to satisfaction.

"I liked picking the categories because it felt like I was teaching it about me. The swiping thing—I wasn't sure if it was learning or just showing me stuff." — P4, Profile Builder


2. The swipe mechanic drove immediate action; the profile drove return intent

Taste Test users were significantly more likely to say they'd "watch something now" (83% vs 50%). However, Profile Builder users more often mentioned coming back—they felt they'd invested in something worth returning to. This suggests the approaches may optimise for different parts of the funnel.


3. Minimum save threshold caused hesitation

In the Taste Test, requiring 3 saves before unlocking the feed created a small but noticeable friction point. Two participants saved content they weren't genuinely interested in just to proceed. One described it as "forced liking." This risks polluting preference data.


4. Sub-genre fatigue appeared in multi-mood selections

Profile Builder participants who selected 3+ moods showed visible fatigue by the second or third sub-genre screen. Two participants began selecting randomly to "just get through it." The dynamic screen count—intended to capture richer data—backfired when it extended the flow.


5. The profile reveal was a moment of delight

The generated label ("The Curious Explorer", etc.) consistently prompted positive reactions - smiles, screenshots mentioned, one participant read it aloud. This was the most emotionally resonant moment across either flow.

"Oh that's fun! 'The Drama Devotee.' I'd actually share that." - P9, Profile Builder


6. Sliders were misunderstood

In the Taste Test's context screen, the binary sliders ("Short bursts ↔ Long binges") confused several participants. They expected a neutral midpoint to mean "no preference" but weren't sure if the system interpreted it that way. Two participants skipped the screen rather than guess.

Decision

Based on testing, I recommended proceeding with the Taste Test as the primary onboarding experience, with targeted refinements to address its weaker points.

The data made a compelling case: 100% completion rate, nearly a minute faster to complete, and significantly higher immediate activation intent (83% vs 50%). Users who watch something on day one are far more likely to return on day seven.

The Profile Builder's strengths were optimised for a user who's already committed. The Taste Test wins the users who aren't sure yet, and in a competitive landscape, that's the bigger win.

Refinements to the Taste Test based on insights:

  • Lower the save threshold to 2 and soften the framing: "Save a couple that catch your eye" rather than "Save at least 3 to unlock." This removes the forced-liking behaviour I observed.
  • Cut the context screen entirely. The sliders confused users and the skip rate was high. We can infer these preferences from viewing behaviour within the first few sessions - no need to ask upfront.
  • Add a single confidence-building moment after the swipe sequence: a brief screen that summarises what we learned ("You're into drama, true crime, and local stories"). This borrows the Profile Builder's "reflection" moment without the overhead of building an entire profile.
  • Retain the swipe mechanic for ongoing discovery. Multiple participants mentioned they'd use it again. I recommended surfacing "More to discover" swipe sessions in the home feed after the first week - turning the onboarding mechanic into a re-engagement feature.

The Profile Builder remains a viable future addition for power users who want more control—but it's a settings feature, not a gate. The Taste Test gets people watching, and that's the job.

Utilising the Design Language System

Utlising the Design Language

A major part of the ABC web refresh was the Design Language System (DLS). This was a work in progress, and I began looking at elements and patterns I could use across the iView app, and working on new patterns that could be fed back into the system.

A major part of the ABC web refresh was the Design Language System (DLS). This was a work in progress, and I began looking at elements and patterns I could use across the iView app, and working on new patterns that could be fed back into the system.

iView-DLS-01
iView-DLS-03
iView-DLS-02
iView-DLS-04

An improved iView player

Establishing a baseline

An important component the new iView app was working on an improved media player, and this required a fresh look at the visual language. As part of this project I designed a contemporary icon set that would be used across mobile, web and TV.

After observing several user testing sessions it became clear that the users were struggling with many aspects of the existing experience. Copy lacked clarity, the interface was cluttered and inconsistent, and established UI patterns were not being followed. To document these issues I decided to carry out a UX audit of each component screen, highlighting issues and providing suggested improvements. 

iView-icons

Users need control

Finessing the interface

I worked on several interaction models for the iView player, both for mobile and desktop. Key parts of the functionality were 'Up Next' and 'Suggested Videos', features that had been missing from the old player and that users had consistently requested in our early research sessions.

iView interaction exploration 

iView-universal-player-03

iView interaction exploration 

iView-universal-player-01

Testing the prototypes

Establishing a baseline

Based on the research and required functionality I came up with several variations of iView series and episode screens. These designs covered scenarios such as landing on a programme page, landing on an episode page and returning to a programme page with an unfinished episode.

To help validate these concepts I carried out guerrilla testing sessions with members of the public in the ABC foyer. These sessions helped inform the design and I finally arrived at two interaction models I wanted to test more thoroughly. 

Tasks that were tested included finding a particular programme, finding a particular episode, finding who the director is and watching an episode.

The simplest interaction model proved most successful. This solution presented a single page for a programme, with a latest episode thumbnail. This allowed the design to retain a consistent brand heading across various user scenarios and ensure the programme metadata was easily discoverable.

After observing several user testing sessions it became clear that the users were struggling with many aspects of the existing experience. Copy lacked clarity, the interface was cluttered and inconsistent, and established UI patterns were not being followed. To document these issues I decided to carry out a UX audit of each component screen, highlighting issues and providing suggested improvements. 

Final designs

Mobile: Programme

iView-mobile-program-expanded-01

Mobile: Episode

iView-mobile-program-extras-02

Mobile: Latest

iView-mobile-episode-03

Mobile: Film

iView-mobile-movie-04

Tablet: Film

iView-tablet-movie-01

Tablet: Programme

iView-tablet-programme-01

Selected Projects

AmaysimMobile app

ABC iViewMobile app

NickelcloudSaaS platform (start-up)

ShiftPlatform redesign

P&O CruisesCruise booking website

All of UsMobile app (start-up)

Trade Finance AppStandard Chartered

Advice IntelligenceSaaS platform (start-up)