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 literacy levels.
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 running that process on software that hadn't been meaningfully updated in years. The platform had accumulated significant technical and UX debt, the workflow was fragmented across siloed teams using different tools, and error rates were high enough to slow production across the entire publishing operation. The business case for replacing it was clear.
Challenge
The existing system was failing on multiple fronts simultaneously. Production teams were creating tickets manually, one at a time, for assets that arrived in batches of hundreds. This process created fatigue, errors, and delays during the most time-pressured moments of game development. Legal users, who needed to compare assets against source material and route approvals to outside counsel, were resorting to email to share sensitive content because the platform gave them no better option. And the interface itself had accumulated so much debt 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, and the existing software had no path to fixing it incrementally; it needed to be replaced.
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). I worked closely with a product manager, researcher, engineers, and subject matter experts across legal, production, and game development to define requirements, align stakeholders, and deliver the solution.
◆ Directed the full research program: 8 user interviews, 26 surveys, 5 screen recordings, a heuristic evaluation of the existing product, and a live contextual inquiry during a late-night production crunch.
◆ Led persona development and journey mapping across three distinct user groups.
◆ Architected the core ticket system and Kanban-based flow structure, including color-coded stage tracking and bulk CSV import.
◆ 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.
Build to Scale, Not for One-at-a-Time
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 during periods when fatigue and errors were most likely. Any redesign that failed to address this was solving the wrong problem.
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.
Design for the Least Experienced User in the Room
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 because the platform offered nothing better. 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 without requiring email attachments of sensitive content.
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 a production 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.
Test in the Conditions That Actually Matter,
The Hawthorne Effect
Structured usability testing produced overwhelmingly positive feedback. I didn't trust it. The Hawthorne effect, users performing better when they know they're being observed, is a well-documented problem in usability research, 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 and continue the import rather than stopping it — a change that directly improved both productivity and satisfaction in the highest-pressure moments the platform was built to serve.
Results & Impact
LARS replaced an entrenched, error-prone workflow and delivered results that held up under real production conditions. Error frequency dropped 68%. Projects were completed 32% faster. Managers reported meaningfully faster onboarding of new users — a significant operational gain in an industry with high turnover. The platform has processed over 100,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
2
Million assets
processed to date
Ticketing Flow chart
Individual Ticket Creation
