KALEIDOSCOPE

PLAY

Play was an Apple Design Award winning mobile & desktop tool for designing iOS apps. Within Play, everything dragged onto the canvas is native—a real Apple map or tab bar, for example. When you're able to work with the same materials as a finished product, your prototypes are smarter, smoother, and more executable.

Years
2021-2024
Role
Product Designer
Platforms
iOS, macOS, Web

As a product designer, I was responsible for tapping into Apple's extensive developer offerings, surfacing them to designers in clear, concise, powerful interfaces—managing them from concept through release.

Play menu editor on macOS

Many seemingly simple UI components provided by Apple, like Menu, have a long list of contextual behaviors and configuration settings that I translated into a simple editor.

The first iteration of Play was iOS-only. Developing full interfaces on a small screen required maximizing the real estate of every feature. Is there a way to abstract the complexity from something until a user has signalled they wanted the fine-tune controls?

Educational projects in Play

To counter-act Play's notorious learning curve, we invested in top notch educational content, led by Dan LaCivita, Fede Sanchez and Harcourt Allen. It was important for us to make sure that new users were aware of these resources and that they were easily accessible when trying new, especially complicated, features.

Working closely with engineers Codin Pangell and David James, I product-managed and documented our Code Export product, which translated any screen in Play to native SwiftUI code.

After a certain point, we were able to start using Play to design Play. Here's a prototype from when we designed the Explore tab, demonstrating Scroll Effects.

Play's claim to fame was the playground we built off of Apple's rich set of native elements. For each element we surfaced, I carefully considered how to make the controls as impactful and simple to use as possible.

Play data configuration panel

Play was ripe with novel interfaces and controls, but as a design team (Joon Park, Kyle Helmstetter) we prioritized consistency to build a design language that made complex interfaces feel more familiar than novel. In the screens above, the card styling was used anytime the user was configuring their own data for a component. Throughout the app, any values with a slightly lighter, rounded background indicated their editability.

Everything our team worked on had an incredible amount of thought put into it. The expectation was that anything we pushed forward was battle tested as much as it could be. As a designer, that meant thinking through countless scenarios for any given feature. Above, see a small set of the right-click menus I mapped out for the desktop experience.

SELECTED WORK

EXPLORE TAB

How could we help new users understand what Play was capable of before asking them to begin with a blank canvas?

When I joined Play, I shared feedback about the confusing parts of starting a new project. It often took time for someone to understand how Play worked and what it could make, yet a new project opened to a blank page with no clear next step. An earlier approach placed content in every new project, but did not explain why it was there.

I worked on a clearer project-creation experience with several deliberate starting points: a blank page, an import from Figma, or a template. Making import visible also helped surface a feature many users were not aware of. For templates, I proposed both finished examples for familiar product types and simpler, lower-fidelity building blocks such as tab bars, navigation, and list-to-detail structures. The goal was to provide useful direction without deciding the project for the user.

That work eventually expanded into an Explore tab. I treated its categories as ways of thinking about what someone could make in Play, rather than as isolated labels. Search and categories needed to stay easy to reach while leaving as much of the screen as possible for projects. We also moved Learn Play starter projects into a dedicated category instead of installing more projects by default.

Explore brought educational projects, inspiring examples, and reusable templates into one place. The default category could remain curated, while Learn Play and categories such as Navigation gave people more directed paths. I prototyped the interaction in Play itself, which helped me identify bugs, performance issues, and UX improvements before the design was finalized.

PROTOTYPE

Using Play to prototype experiences for Play helped me identify bugs, performance issues, and UX improvements. Shown above is an early prototype of the scroll effects on our Explore tab.

PRODUCTION

The scroll effects and search functionality helped keep this tab to a single list, without having to develop detail/collection views.

The motion and scrolling effects were useful because they made the interface more efficient, not simply more expressive. Synchronizing the horizontal movement of the category list let two rows remain available without taking space away from the projects.

When someone scrolled vertically, I treated that as an intent to browse and reduced the category list. A tap could bring the categories back whenever they wanted to switch. Using Play to prototype the behavior kept the concept grounded in what the product could actually support.

SELECTED WORK

MONETIZATION

How could we introduce paid plans and new limits across three platforms without surprising or disrupting existing users?

With the release of Play for macOS, I led the monetization project and coordinated it with an upgraded login experience and the introduction of Drafts. I designed the relevant payment screens and user flows across three platforms, managed the development work, collaborated with QA, and researched Apple's payment guidelines. Because the user model and platform rules were interconnected, monetization remained an ongoing project after the initial release.

The scope included mapping how plans affected existing features and usage, designing plan comparisons across all three platforms, accounting for empty seats, updating SSO and login, overhauling Play’s web dashboard, introducing View Only mode, and preparing support documentation.

MOBILE

I designed the mobile upgrade experience around Apple's in-app purchase requirements and the constraints of Play's existing user model.

DESKTOP
Play desktop monetization dashboard

The desktop flow had to work alongside web billing, plan comparisons, and the logic for upgrades, downgrades, and seats.

The work extended beyond payment screens. It included the web dashboard, upgrade and downgrade flows, plan comparisons, email logic, and the rules connecting those experiences.

I started by identifying the technical questions that could block the rest of the work. I reviewed baseline behavior with Codin so he could check constraints in Stripe’s API, then brought options to Dan and Joon for confirmation. I documented the logic so engineering and QA could question it, separated decisions that blocked progress from work that could continue in parallel, and drafted staged milestones across the team. I revisited dates with collaborators, checked progress frequently, and completed design QA as the work came in.

The rollout went smoothly and, just as importantly, gave us information for later experiments. Subscriptions remained an evolving system: we adjusted their presentation and ultimately moved away from App Store subscriptions toward DMG and direct distribution, a path I had researched in advance. We also explored trials, requests for information, and early Apple review submissions before committing to a complete build.

The hardest constraints came from Apple review, upgrade and downgrade states, SSO differences between iOS and macOS, and payment proration. Looking back, I would simplify the plans so their differences were immediately legible, define limits for advanced features earlier, avoid referencing external plans in the in-app purchase experience, make every additional charge more explicit, and sell seats directly rather than basing billing on editors who accepted invitations.

I worked with Bruna in QA; Dan, our CEO; and Andrew, Adam, Codin, and Diogo in engineering. My role was to keep the product logic, design, sequencing, and review work connected so the team could move forward with a shared understanding.