Artists, Not Archivists

TL;DR

DreamWorks Animation had 20+ years of creative work locked in disconnected systems, inaccessible archives, and tribal knowledge. Artists were spending hours searching for assets instead of creating. I led product strategy across two workstreams—Rico (a digital asset platform) and Courier (a vendor delivery tool)—and helped transform how the product organization builds products: from reactive feature delivery to discovery-driven development grounded in artist workflows.

"Transformed the way they do engineering... designing for the needs of their creators instead of iterative guesswork." — VP of Engineering

Impact:

• Reduced asset discovery time from 15-30 minutes to under 60 seconds
• Shipped production workflows across 4 departments (Modeling, DigiMatte, Previz, Final Layout)
• Delivered a design system now used across all workflow UIs
• Established a North Star metrics framework the COO endorsed and requested studio-wide
• Identified a single architectural root cause behind 5 distinct Courier pain points

---

How Animated Films Get Made (And Why Asset Management Matters)

A feature animated film takes 3-5 years to produce and involves hundreds of specialists across dozens of overlapping departments. At DreamWorks, a single film might involve:

Pre-production: Story artists create thousands of storyboard panels. Concept artists and visual development teams produce character designs, environment paintings, and color scripts. Editorial cuts rough sequences together.

Production: Modeling builds 3D characters, props, and environments. Rigging creates the digital skeletons that let characters move. Look Development defines materials and textures. Layout blocks camera angles and staging. Animation brings characters to life. Lighting sets mood and atmosphere. Effects handles simulations—water, fire, cloth, hair. Rendering converts it all into final images.

Post-production: Compositing layers everything together. Color grading and final polish.

Each department generates and consumes thousands of digital assets[asset]: character models with dozens of costume variants, environment paintings that can be 20GB Photoshop files, animation clips, reference footage, storyboard panels with dialogue and revision history. Disney Animation's research library holds over 65 million assets from their 100-year history. DreamWorks has a comparable backlog from 30+ years and 50+ films.

The platform we were building needed to be nothing less than a system of record and knowledge base for every film going forward.

---

Context

When a partner studio worked on a DreamWorks sequel, they needed reference footage from the original film. DreamWorks had produced it years earlier. The internal archive should have been a gold mine.

Instead, the partner discovered everything from the original was gone. The pencil test database had been moved to an out-of-state warehouse, stored on zip drives in file formats that couldn't be read anymore. So animators manually digitized frames from the DVD of the studio's own film.

This was the environment I walked into in early 2025 as Product & Strategy Lead at Stellar Elements, a consulting partner. DreamWorks makes animated features with 300+ artists spread across the departments described above. Each department manages thousands of assets. None of their tools talked to each other.

My role: Discovery planning and synthesis, stakeholder alignment, workshop facilitation, and translating qualitative pain into scoped requirements engineering could ship. The engagement started in November 2024 and is ongoing. By mid-year, I was running two parallel tracks: strategy support for Rico[rico] (the new asset platform) and product coaching and development for the Product Owner managing Courier[courier] (the vendor coordination tool).

What we walked into: DreamWorks had worked with external design partners before. Those engagements hadn't gone well. Designers without product or engineering resources produced work that wasn't grounded in feasibility. When my team arrived talking about discovery methodology, some people heard: "Here come more outsiders who don't understand our culture." Trust had to be earned through shipped value before we could expand the scope of change.

The first research request I made got blocked. Screen recording for user sessions was framed as a privacy concern, even though it's standard methodology. I documented every constraint and looked for alternate routes. The Courier Product Owner had gotten executive approval for a discovery approach that aligned with what I'd been pushing: involve engineers earlier, talk to representative users, own the solution space rather than asking users to prescribe features. He had air cover. I helped him launch his approach, positioned it as their initiative, and worked to bring the broader team along.

What eventually worked: I stopped using framework language. When I showed lo-fi mockups instead of talking about "discovery methodology," the Rico Product Owner engaged. He needed to feel like he was shaping the process, not having it imposed. I could flex on how discovery happened, but I held firm on whether it happened at all.

---

Problem

The organization had no shared language

The root problem wasn't technical—it was ontological. DreamWorks had no shared concepts and language across departments, and this manifested everywhere: file-naming structures, processes, how people referred to files, what people called "assets," what people called workflows.

This happened every time a new show got started. Each show-development team developed its own idiosyncrasies, and within that, each department working on that show developed its own idiosyncrasies in naming stuff. This was both blessing and curse: it provided flexibility so each film could be purpose-built for its creative needs. But it also meant that leveraging past work, cross-pollinating good ideas, and getting advantages from the scale and volume of assets DreamWorks produced was near impossible.

The Story Department Head stopped me cold during a discovery session:

"Not even easier access, but just access AT ALL to the storyboards and screenings from all of our past projects. That is completely inaccessible to us right now."

Another Story lead put it plainly:

"There is no actual accessible archive for artists to look at other artists' work. If you are not on that show, you don't have access."

The Story team used Flix[flix], which had no search functionality. Modelers used Doris[doris], which limited access to one show at a time. Previz[previz] artists relied on file system navigation. Each tool solved one department's needs while creating walls between departments.

Artists were archivists instead of artists

Each department had broadly similar needs. They needed to find previous work and current work. They needed to find assets and files quickly. But artists and production staff were spending too much time looking for assets—or failing to find them entirely—and recreating work that already existed.

The framing I kept returning to: we want our artists to be artists, not archivists. They should focus on creativity, on leveraging inspiration from past and present work, not worrying about folder organization, tagging structures, or file names.

Production coordinators weren't immune. They spent significant time creating, managing, updating, and using ontologies (essentially file naming structures) and finding assets for their artists. Not the best use of their time.

The looming challenge: globalization

As the production environment changed, DreamWorks needed to preserve the strategic option to use different vendors or studios for different parts of the production process. Partner studios in Vancouver, London, or Bangalore might handle effects, animation, or lighting for a given film.

Take the internal confusion and introduce outsiders to it, and the impact multiplies. For Courier (the vendor delivery tool), partners had to learn DreamWorks' organization and naming structures. Those structures conflicted with the mental models partners brought from their own studios. There was no lingua franca for assets, files, or animation production workflows.

The incumbent had a 4-year head start on AI

Doris had spent 4 years building an AI-powered semantic search engine called Eureka[eureka]. Artists could search by visual similarity, natural language, and concept. Our platform had no AI search at launch.

This created a genuine adoption problem. For Modeling users specifically, we were asking them to migrate from a tool with AI search to one without it. The Product Owner called it a "sore spot." In training discussions, artists wanted to know when they'd get the capability they were losing.

File-by-file workflows burned hours

In DigiMatte[dgm], artists work with 20GB Photoshop files. Opening one takes 2-5 minutes. A DigiMatte artist described the workflow: open a file, wait three minutes, realize it's the wrong one based on inconsistent naming, close it, try another. Asset discovery that should take seconds was taking 15-30 minutes.

Courier looked like five problems but was really one

A parallel tool called Courier handled shipping assets to external vendors. Production managers couldn't track what they'd sent. One PM described searching for past shipments:

"I'm just searching all these different variations of demon, demon bird, carpool, demon card..."

The bug list looked like five separate UX problems: noisy search, no direction filter, can't search by asset, multi-step filtering friction, no shipment history per asset.

When I mapped the architecture, they collapsed into one constraint. Courier had two separate data stores: Pack (the asset model—variants, types, paths) and Ship (shipment history—dates, packages). Users needed Pack-level precision AND Ship-level history at the same time. But the system forced them to choose.

A PM reframed it during discovery: "The reason you want to know when it shipped is to know which version of the file is shipped, right? So we didn't really solve the problem at all."

Five symptoms. One architectural cause.

---

The Adoption Challenge

This wasn't a greenfield build. Artists already had solutions: workarounds they'd built habits around, systems and processes they'd developed, even if manual and inefficient. Those solutions worked. They were known.

So our challenge wasn't just building something with feature parity. We needed to create something meaningfully better, where that meaningful difference could be realized within the first use.

We framed adoption as a three-stage journey: Learn, Trust, Rely. Artists first needed to understand how Rico worked differently from their current tools. Then they needed evidence it wouldn't fail them on deadline. Only then would they depend on it for their actual job—their livelihood.

We spent significant time thinking about:

First-time user experience (FTUX): When artists launched Rico, they saw their show's assets immediately. No empty state, no tutorial modal. Keyboard shortcuts weren't announced upfront; they were revealed contextually as artists built fluency. We designed a progression path from first-time user to power user, layering capability discovery over repeated use.

Platform strengths: We were building for the web. Artists could open multiple tabs to compare assets side-by-side, copy URLs and share asset links in Slack or email, bookmark searches. These weren't features we built; they were behaviors the browser already supported that we chose not to break.

The trust ladder: Users needed to (A) learn the tool, (B) trust it, and (C) rely on it to get their literal job done. Each step required showing value before the next became possible.

---

Solution

Rico: The Digital Asset Platform

What Rico is: A unified platform for finding, accessing, and reusing digital assets across all departments and all shows. One system of record instead of a patchwork of disconnected tools.

Decision 1: Win on workflow value, defer AI-search parity

The incumbent tool for Modeling, called Doris, had a 4-year head start on AI semantic search. Chasing parity immediately would have been a trap: high effort, low credibility, slow delivery.

Instead, I identified features where we could differentiate.

Character variants view. Doris displayed all character variants stacked on top of each other. Artists couldn't tell which costume or prop variant they were looking at. We built a dedicated variants view with side-by-side comparison. The Product Owner was initially skeptical. After seeing it in action, he became a strong advocate.

Multi-show access. Doris let you access one show or all shows. Nothing in between. We enabled selecting multiple specific shows simultaneously, matching how artists actually work.

Windows support. Doris was Linux-only. We supported both platforms, broadening access.

The AI search gap still mattered. But we had something real to offer on day one rather than telling users to wait 18 months.

Decision 2: Solve the underlying job, not the literal request

Previz artists told me about an organization problem. Assets could only live in one folder, even though they got used across multiple sequences. The obvious feature request: let assets exist in multiple folders.

I proposed eliminating the folder paradigm entirely. Replace hierarchy with tag-based filtering: search terms become filter tags, tags stack to refine results, hierarchy becomes optional.

A Previz artist validated the concept: "I thought search would just be like anything you search turns into a tag, and you just keep searching things. Feels natural."

That wasn't what anyone asked for. They asked for more flexible folders. I heard the underlying job—finding assets regardless of where they'd been installed—and designed something that made hierarchy optional rather than structural.

Decision 3: Collections as the adoption catalyst

Final Layout[flo] artists had been using two overlapping tools with fragmented workflows. The supervisor was blunt about the migration risk: "Without collections, migration appears to slow us down."

They needed assets pre-organized before work began, like a chef's mise en place. I validated a collections architecture with the FLO supervisor. She described the split:

"Personal: ones that I just did because I wanted to do these three shots. Public: certain kinds of bushes that we set dress in many locations throughout a movie."

Her verdict: "Seems perfect to me."

Collections became the carrot that made migration worthwhile.

Treating an Internal Tool Like a Consumer Product

Most enterprise software looks like enterprise software. Gray interfaces, dense forms, utilitarian design that signals "this is work." We went the opposite direction.

The design system treated Rico as a consumer product. Clean typography, generous whitespace, micro-interactions that responded to user actions with satisfying feedback. We shipped React 19 with Storybook reorganized for 1:1 parity with Figma. Typography tokens, spacing cues, and interaction states are documented and reused across every workflow.

We took care with the details:

Micro-interactions and microcopy: Loading states, empty states, error messages. I designed and wrote much of this myself. The product copy has personality without being cutesy.

Rico branding: The product is named after Rico, one of the penguins from Madagascar. We infused his character and tone throughout: loading animations, empty states, onboarding flows. Moments of delight in a tool that could have been purely utilitarian. When artists waited for a large file to process, Rico kept them company.

[PLACEHOLDER: Rico branding visuals—loading animation, empty state with Rico character, onboarding screen]

Interactive prototypes: Some of the interaction design I conceptualized—keyboard shortcuts, navigation patterns, search interactions—would have taken our designers too much time to produce in Figma. I built interactive prototypes myself to validate these patterns before committing engineering time.

This wasn't decoration. It was behavioral strategy. Artists spend 8-10 hours a day in their tools. A tool that feels good to use gets used more. A tool with personality creates emotional connection. A tool that treats users like consumers, not captive employees, earns loyalty rather than tolerance.

Training and Trading Cards

When Rico rolls out, it'll be part of DreamWorks' training curriculum for new hires. While we held a north star design principle that our product shouldn't need onboarding or training, we knew it would happen anyway. It wasn't really our choice.

We wanted to gamify it. I designed a series of trading cards for each of the different workflows and departments within Rico. Each card features the Rico penguin in a different pose, with key shortcuts and capabilities on the back. Artists could collect them, trade them, use them as quick references at their desks. What could have been a forgettable PDF became something artists actually wanted to keep.

[PLACEHOLDER: Trading card designs for Story, Modeling, Previz, FLO, DigiMatte workflows]

Courier: Connect to existing infrastructure

During a production manager sync, we found something unexpected. One team on a current production was already using ShotGrid's[shotgrid] Deliveries entity to track shipments (112 deliveries recorded). Another team on the same show didn't know this existed.

The "solution" wasn't new tooling. It was connecting teams to infrastructure that already existed. We reframed the Courier approach: integrate with ShotGrid rather than building Courier-native tracking. A 6-week sync path, not a 12-month rewrite.

Sometimes the best product work is making existing infrastructure visible.

---

Results

Shipped to production

Design system: Reusable component library with Figma-to-Storybook parity. Standardized interaction patterns across all workflow UIs.

Previz workflow: We shipped with tooltips for keyboard shortcuts. Nobody used them. Previz artists aren't trained to read interface instructions the way enterprise users might be. We iterated: moved tips into loading states (the way games teach controls while levels load) and added unobtrusive popups when a user performed a manual action that had a shortcut. Learning happens in context, not in documentation.

DigiMatte workflow: Visual previews let artists identify correct paintings before opening 20GB files. The open-wait-wrong-file loop that burned 2-5 minutes per attempt became a quick scan.

FLO Collections: Personal/public split with scope enforcement. Artists can curate assets before opening shots instead of searching mid-workflow.

Art Department: Searchable archive, legal clearance visibility, approval status, categorization. Artists can find concept art across shows for the first time.

Modeling Core: Character variants view, multi-show access, Windows support.

Validated impact

In timed validation sessions, representative "find the right asset" tasks completed in under 60 seconds with preview-first patterns—down from 15-30 minutes under legacy workflows.

A Grooming artist said the approach "could shave off weeks worth of work" by enabling asset reuse instead of recreating from scratch. A Final Layout supervisor called the Collections concept "a dream for us."

For Previz, after we demonstrated the multi-asset shopping cart concept, the supervisor's response was immediate: "Okay. It's happening. Yay. Exactly. That's perfect." She later shared something that wasn't in any planning document: they planned to deprecate their current library entirely. "I think very soon, we're gonna deprecate our Previz library. We will solely rely on [the new platform]." When users volunteer to abandon their current tools, you're solving a real problem.

Adoption targets with measurement discipline

We set concrete adoption targets: ≥70% of target imports via the new platform for 4 consecutive weeks on 2 shows (Modeling), 75% core active users within 3 months of show start (Previz), 60% core active users within 6 months of show start (FLO).

These measure whether artists actually changed their workflow, not whether they tried the tool once.

Metrics framework: changing how the organization thinks

I developed a North Star metrics framework centered on "Time to Actionable Asset": how long it takes an artist to find, access, and use an asset in their workflow.

The framework changed how the team talked about success. Before, they'd report usage numbers (logins, page views) without knowing whether those were real artists or test accounts. They'd been reporting these vanity metrics to their COO and VP-level stakeholders without understanding what they meant.

After, they started asking sharper questions: "Are we measuring real users? What's the segmentation between artists and dev/test?" The Product Owner began filtering out noise and focusing on behavior change.

The COO endorsed the approach and requested replication across all DreamWorks development teams.

The real impact was behavioral: The team went from not looking at metrics, to looking at vanity metrics, to understanding the power that quantitative research and data can provide. They're now making investments toward becoming a data-driven product organization. They're not there yet. Change and transformation doesn't happen overnight. But they're making progress. That's what matters.

[PLACEHOLDER: Link to my writing on analytics strategy and what it means to be data-driven]

---

What I'd Do Differently

Verify mandate with everyone in the chain, not just the sponsor. Our executive sponsor hired us to improve product processes but hadn't communicated that to his direct report. We spent months navigating the gap between stated sponsorship and actual authority.

Stop using framework language sooner. When I showed lo-fi mockups instead of talking about "discovery methodology," the Product Owner engaged. He needed to feel like he was shaping the process, not having it imposed. I could flex on how discovery happened, but I held firm on whether it happened at all.

Trust compounds. The metrics framework that got COO endorsement started as a side project I pitched three times before it got traction. Each small win created permission for the next larger initiative. Patience wasn't weakness; it was strategy.

Architecture beats UX when diagnosing chronic pain. Courier looked like five UX problems until I mapped the Pack/Ship split. The symptoms (noisy search, missing filters, can't search by asset) all traced back to one architectural constraint: the asset model and the shipment history lived in separate data stores. Once that was visible, the solution space snapped into focus. Patching UI wouldn't have fixed anything.

Platform problems require platform thinking. The insight that each department needs a different interface on common infrastructure shaped our entire approach. When you're serving 8 departments with genuinely different definitions of the same word, you can't design a single solution. You design a system that accommodates multiple solutions. I'll carry this framing forward.

---

What Made This Work

Yes, there was good product thinking, design sense, and process. I introduced frameworks for user discovery and provided resources, materials, and artifacts.

But what's actually distinctive about this work—and what I think matters in an era where code is getting cheaper and design is getting cheaper—is empathy that drives behavioral change.

Artists at DreamWorks aren't just completing tasks. They're protecting their creative output, managing deadline anxiety, navigating status dynamics with supervisors, building professional identity through their work. Every tool interaction happens inside that emotional context.

The Rico brand personality, the trading cards, the FTUX that showed your assets immediately—none of these came from requirements documents. They came from sitting with artists, listening to their frustrations, and caring enough to address the emotional layer alongside the functional one.

Understanding artists' emotions, the stakes of their work, the fear of adopting new tools that might slow them down during crunch time. Understanding that they'd built workarounds not because they loved them, but because they'd been burned before by tools that promised improvement and delivered friction.

The best product work isn't about features. It's about creating the conditions where people want to change their behavior. That requires understanding psychology as much as technology.

---

Collaborators

This project let me get hands-on: building interactive prototypes, debugging the Pack/Ship architecture with engineers, contributing directly to the design system. The Courier Product Owner embraced coaching and shifted from reactive to discovery-oriented. The UX Director and Lead Designer translated research into department-specific interfaces. Engineering leads implemented features and advised on constraints.

Department stakeholders across Story, Modeling, Previz, FLO, DigiMatte, Look Dev, Grooming, and Animation shared their workflows, validated concepts, and committed to adoption.

---

Case study documented December 2025. Training rollout and adoption metrics scheduled Q1 2026.

Interested in discussing this work? Contact me →