Brenna, Houston

Marifer, Dubai

Alejandra, Mexico

Devin, Dallas

Discovery Phase

When our design lead delivered the first round of prototypes, I was responsible for leading 1:1 interviews with fashion models across a wide range of career stages—from New Face models just entering the industry to experienced Main Board talent. To make sure we weren’t designing from a single perspective, we partnered with seven modeling agencies worldwide, which helped us recruit models from different markets and working styles.

In these interviews, I focused on understanding how models currently manage their professional materials, communicate with agencies/clients, and what they need most when presenting themselves for opportunities. I walked participants through early flows, asked them to narrate expectations and pain points in real time, and noted where the prototypes created confusion or friction. The insights from these sessions helped us validate key assumptions, identify usability gaps, and prioritize improvements that shaped the next iteration of the product experience.

Early Sketch, Business Profiles

Early Sketch, Browse View

Early Sketch, My Castings

Building the App

With our discovery insights in place, we shifted into building an initial prototype of the app using UIKit and Storyboards. This approach let us move quickly—validating fixed layouts, screen hierarchy, and navigation patterns before investing in extensive business logic. I built the first pass of core screens for browsing, profile views, and onboarding, along with reusable UI components to keep the experience consistent across the flow. We also set up a lightweight data layer with mocked content so we could iterate on interactions, loading states, and edge cases without waiting on final integrations.

After a two-week sprint, we visited our Mexico-based agency partner for a two-day testing session and ran a series of real user tests focused on the browsing and onboarding flows. We observed how agents and talent navigated the experience, where they hesitated, and what they expected to find at each step. After gathering much-needed feedback on day one, I quickly resolved the most pressing issues—tightening the navigation, clarifying labels and CTAs, improving validation and error states, and smoothing out key interactions. On day two, we reran the same tests to see whether the updates improved comprehension and completion rates.

Once the initial prototyping phase was complete, we began building the initial MVP with a three-month launch window. At that stage, we started replacing mock data with real integrations, refining the architecture, and hardening the app for production—improving performance, reducing technical debt, and adding analytics to measure onboarding and browsing behavior. We worked closely with our partners throughout to ensure we didn’t deviate from the core feature set and that the product aligned with real agency workflows. We launched the first version of Talent Book on June 17, 2021, with an app size of 20 MB.

Back to the Drawing Board

While the initial version of Talent Book was a success for the entire team, we still had several known issues—primarily around app size and the way different agencies managed their models. We learned that agency workflows varied more than expected, which created friction in the end-to-end flow and increased the complexity of keeping the experience flexible without bloating the app. During this time, the executive team decided to move the app to a more modern stack, including a migration to SwiftUI.

I was given a five-month timeline to rebuild the app with a new design created by the design team, built entirely in SwiftUI. The goal was to modernize the UI, streamline the navigation, and improve maintainability while preserving the core functionality that partners relied on.

Lessons Learned

This phase reinforced how valuable it is to validate the experience early with real users. Building a fast prototype in UIKit and Storyboards helped us confirm layout, navigation, and overall flow before committing to heavier engineering work—and the in-person testing with our agency partner surfaced issues we wouldn’t have caught internally.

From a Swift and iOS engineering perspective, a few lessons stood out. First, UI decisions and architecture are tightly connected: rapid Storyboard iteration was great for speed, but it also highlighted the importance of keeping view controllers thin and pushing logic into testable, reusable layers (models, services, and view models). Second, defining a clean networking and caching strategy early prevents duplication and makes it easier to swap mocked data for live endpoints without rewriting large portions of the app. Third, performance and app size need to be treated as first-class constraints—optimizing assets, reducing dependencies, and being intentional about packaging paid off immediately when we started preparing for launch.

We also learned the value of building a small internal component system (buttons, cells, empty states, and loading states) rather than recreating UI patterns screen by screen. That approach reduced bugs, improved consistency, and made changes faster during the sprint. Finally, the rebuild decision made it clear that the long-term benefits of SwiftUI—shared design tokens, more declarative UI, easier state-driven screens, and improved maintainability—would outweigh the initial migration cost, especially as the product and partner requirements continued to expand.