2K26 - Character Editor Redesign

Role: Design Lead, UI/UX | Timeline: 4 months | Team: Engineering, UI/UX

Problem

The game had four separate but nearly identical menus for editing players, creating characters, customizing coaches, and applying tattoos. Each one was built years apart with completely unique components, so maintaining them meant maintaining four independent systems that all did roughly the same thing.

The navigation was slow. Users sat through transition animations that existed only because removing them would break something. The build art was bloated with features stacked on top of each other in the same groups, making it difficult for anyone else to touch without risking a bug. And because each menu evolved separately, none of them matched the visual direction of the rest of the game.

I pushed for this redesign specifically because the design system I had been building made it possible. We finally had the infrastructure to consolidate all four menus into one without rebuilding everything from scratch.

(Previous character builder throughout different cycles)

(Old transition animations)

Approach

The goal was to build the entire feature using only core components from the system. No one-offs, no custom art, no special treatments. I wanted other build artists to be able to open this screen in the future and immediately understand how it worked.

I designed nested groups of assets and worked with engineering to pioneer new nesting features in our game engine. The cleanup happened at the implementation level, not just in design files. We restructured how components were built in-engine so the hierarchy stayed simple and maintainable.

Because everything was built from the in-engine component library, the entire menu could update dynamically based on game mode, changing color to match MyCAREER or MyNBA or any other context automatically.

(Same screen structure, colors update automatically based on game mode. Built entirely from system components in-engine.)

Pushback

Some designers felt the new direction was too simple. They wanted more color, more visual flair, more one-off art to make it feel special. I pushed back. The player model was the star here, not the UI. If the system components weren't enough, that was a signal to improve the system, not to work around it.

I got approval to build it my way with the understanding that if it felt bland in testing we would revisit. Once playtests happened and some bugs got resolved, everyone was satisfied. The simplicity made it faster to use, and the focus stayed on the player.

Outcome

Four legacy menus became one unified player editor. The whole feature took about a month to concept and get approved, compared to the two months a project like this would normally take. Waiting on engineering availability was the main bottleneck, not design iteration.

It shipped as intended. Some legibility adjustments happened after build since the design removes most panel backgrounds, but the core stayed intact. Other artists can now work on this screen without getting lost in the setup because the in-engine structure uses lists throughout and follows the same patterns as everything else in the system.

This was the proof that the design system investment paid off. Not just cleaner Figma files, but actual production speed and a better product.

(The shipped player editor. One unified menu replacing multiple others)