iTest / Try Galaxy

Read the campaign story

Samsung's iTest invited iPhone users to explore a simulated Samsung interface on the device they already owned. Contemporary reporting in April 2021 describes the web experience being promoted in New Zealand, while DDB Group's project account traces the initiative from that market into the later Try Galaxy product. The experience did not install Android or turn an iPhone into Samsung hardware. It offered a selective simulation of another interface.

The demonstration included recognizable app screens, customization options and guided explanations. Some functions were deliberately limited, and the interface used messages and humor to explain parts of the experience. This gave a potential switcher something to explore before visiting a store or committing to a purchase. The later global development belongs to the same campaign family rather than a separate case created solely because the name changed.

The strategic insight was that a trial can be placed inside the customer's existing routine. Someone reluctant to leave a familiar device may not seek out an unfamiliar one. By bringing the demonstration to that familiar environment, the campaign reduced an early friction in consideration. It also changed the role of the advertisement: instead of describing customization from a distance, it let the audience perform a simplified version of it.

For a small software business, the useful adaptation is a clearly labelled interactive sample that requires no account or migration. A prospective user might try one workflow with fictional data and see how it differs from their current method. The demonstration must disclose what is simulated, what is unavailable and which results depend on the real product. Smooth animation should not be allowed to imply performance that has not been tested.

The opened sources establish the campaign's origin and interface, not a measured conversion from iPhone to Samsung purchases. Exploration is an intermediate behavior, not proof of a completed switch. A responsible test would assess whether users understand a specific feature and can distinguish the demo from a full operating environment. The most useful outcome is informed consideration, including the possibility that a person decides the alternative is not suitable for their needs.

Move the trial closer

Reduce the effort required to experience one meaningful feature.

Disclose simulation limits

A demo should not imply full hardware or operating-system equivalence.

Measure informed understanding

Interaction counts do not establish a completed switch.

A small test for another brief

Create an account-free demonstration of one software workflow.

Measure feature comprehension and recognition of demo limits.

Stop if the prototype implies performance or permissions it does not provide.

• Use fictional sample data and no external account access.
• Label simulated and unavailable functions clearly.
• Ask adults to compare the demonstrated workflow with their needs.