2K's Asset Review & Management
Replaced a broken asset review workflow with a purpose-built platform.
Role:
Lead Product Designer
Platform:
Progressive Web Application
Project Type:
Process and Platform Redesign
Deliverables:
Strategy, Research, Architecture, Ideation, Prototyping, Usability Testing
Team:
Product Manager, Researcher, Front-end & Back-end Engineers, Subject Matter Experts
Summary
Challenge
2K's game asset review process ran on outdated software burdened with years of neglect. It generated errors, slowed production, and frustrated three distinct user groups with fundamentally different needs and technical capabilities.
Approach
I led the full redesign: conducting research across three user personas, architecting a Kanban-based ticket system built for bulk workflows, and testing continuously in production, including a late-night contextual inquiry that surfaced pain points previous testing had missed entirely.
Results
67% reduction in errors
32% increase in production speed
Improved onboarding efficiency
Context / Background
Every asset that ships in a 2K game, every model, background, logo, athlete likeness, brand mark, and piece of third-party content must be reviewed and approved before it reaches players. That review process sits at the intersection of legal, production, and game development, and it runs on a tight timeline tied to annual release schedules.
When this project began, 2K was using outdated software that had accumulated significant technical and UX debt; the workflow was fragmented across siloed teams using different tools, and error rates were slowing production. The business case for replacing it was clear.
Audit of deprecated process
Challenge
The existing system was failing on multiple fronts simultaneously. Production was creating tickets manually for assets that arrived in batches of hundreds. This process created fatigue, errors, and delays. Legal users, who needed to compare assets against source material and consult with outside counsel, were resorting to email to share sensitive content because the platform gave them no better option. The interface itself had accumulated so much debt and bloat that new users struggled to orient themselves even after repeated use.
The combined effect wasn't just user frustration. Errors in the legal review process carried real downstream risk. Production delays in asset approval created bottlenecks that cascaded into release timelines. This was an operational problem with measurable business consequences.
User Journey Document
My Role
As Lead Product Designer, I directed the strategy, research, and design of the new process and product, which became known as the Legal Asset Review System (LARS).
⬩ Directed the full research program: user interviews, surveys, screen recordings, a heuristic evaluation of the existing product, and a live contextual inquiry.
⬩ Led persona development and journey mapping across three distinct user groups.
⬩ Architected the core ticket system and Kanban-based flow structure.
⬩ Directed ideation and concept development across all major features.
⬩ Drove testing throughout development including on prototypes and working software.
Strategy
LARS was a complex redesign serving three user groups with conflicting needs inside an organization under constant deadline pressure. The strategic core was straightforward:
Don't design for the average user.
Design for the hardest conditions any user would face.
That principle produced four decisions that defined the platform.
1. Build to Scale
The most important insight from research wasn't about the interface; it was about the workflow. Game assets arrived in large batches on compressed timelines, yet the existing system required users to create tickets one at a time, leading to repetitive data entry.
I designed LARS around bulk operations from the start. The CSV import workflow enabled users to organize and upload hundreds of assets at once, while the Kanban board and color-coded stages made large volumes of tickets easy to track at a glance, reducing the need to drill into individual records.
2. Design for the Least Experienced User
Research surfaced a detail that reshaped several design decisions: legal users were largely unfamiliar with common UI patterns. They weren't power users. They came to LARS under deadline pressure to perform high-stakes approvals. Designing for the UI literacy of the production team would have left legal users stranded.
This led us to prioritize clarity and navigation over features that assumed fluency. It also surfaced the external access problem: legal users needed to share sensitive assets with outside counsel, and they were doing it over email. I petitioned IT and engineering to expand vendor access, then designed a pinned-comment feature that let users annotate specific regions of an asset, which automatically generated a cropped view for outside counsel.
3. Use Gamification to Solve the Morale Problem
Research identified something that better information architecture alone couldn't fix: for some users, LARS was tedious. The work was repetitive, the volume was high, and the stakes made speed-versus-accuracy a constant tension. UX improvements made the system more efficient. But efficiency doesn't change how it feels to enter data for hours during crunch.
I designed a gamification layer, a leaderboard, and leveling system that awarded points and reward icons for completed tasks. Managers used it actively, organizing competitions with tangible prizes during critical work periods.
The leaderboard became one of the most discussed features after launch, and its impact on morale during crunch sessions was directly reported by users and managers. It's a feature that reads as whimsical on a spec sheet and proved essential in practice.
4. Test in the Conditions That Actually Matter,
Usability testing produced overwhelmingly positive feedback. I didn't trust it. The Hawthorne effect is a well-documented problem, and the gap between controlled testing and real production conditions is especially large for tools used during late-night crunch sessions under genuine deadline pressure.
I ran a contextual inquiry by joining users during an actual late-night production push. The feedback was significantly different. Users revealed pain points that hadn't appeared in our other sessions, including the error-handling behavior in the CSV import flow, where stopping the upload to flag errors felt too restrictive when hundreds of assets were queued and a deadline was imminent. I pivoted the design to let users decide how to handle flagged errors. A change that directly improved both productivity and satisfaction.
Results & Impact
LARS replaced an entrenched, error-prone workflow and delivered results that held up under real production conditions. Error frequency dropped 67%. Projects were completed 32% faster. Managers reported meaningfully faster onboarding of new users. The platform has processed over 700,000 assets since launch, and production teams now have the capacity to focus on areas of game development that the old process was crowding out.
67%
Error frequency reduction
32%
Increase in
production speed
740
Thousand assets
processed to date
