UX/UI Design Services for Games

UX/UI for Games

You open someone else's Unity project and see: one Canvas for the entire game, a hundred nested panels, Layout Groups inside Layout Groups, and the profiler shows 4ms just on UI recalculation per frame. Not uncommon. Game UI often gets built on-the-fly without architecture, and by project's end becomes a constant source of bugs and performance dips.

We design and implement game UI: from wireframes to finished components in-engine, with performance and maintainability in mind.

Prototyping and Design

Any UI starts with understanding information flow: what should the player see at each moment, what actions are available, how to transition between screens. Without this, development becomes a series of "make it, wrong, remake" cycles.

Prototyping tool: Figma. Not chosen for fashion, but for specific capabilities:

• Component system with variants—instantly verify how a button looks in Normal/Hover/Pressed/Disabled states
• Auto Layout—honest simulation of UI behavior at different text sizes (critical for multilingual games)
• Prototypes with transitions—test navigation flow before writing a line of code

Most UX problems surface at prototype stage: unclear transitions, crowded screens, wrong information hierarchy. Fixing this in Figma takes 15 minutes. Fixing it in finished Unity project takes half a day.

uGUI vs. UI Toolkit

Unity now has two UI frameworks, and the choice isn't obvious.

uGUI (Canvas-based) — mature system, exists since Unity 4.6. Works with RectTransform, rich ecosystem of ready components and assets. Practically all existing game UI on Unity is written in uGUI.

UI Toolkit — new system based on XML (UXML) and CSS-like styles (USS). Originally built for editor tools (Editor Extensions), officially supported for runtime UI since Unity 2021. Architecturally closer to web development.

When to choose UI Toolkit:

• New project, team ready for learning
• Need complex theming and skinning systems
• Actively developing custom editor tools

When to stay with uGUI:

• Maintaining existing project
• Need maximum Asset Store compatibility
• Team already knows uGUI, timeline tight

Deeper: Canvas Performance and Draw Calls

This is where game UI differs fundamentally from regular app UI. In games, UI updates every frame, and inefficient implementation can eat 3–5ms from frame budget.

How Canvas Batching Works

Unity combines Canvas elements into a single draw call if they use the same material and texture atlas. Breaking the batch means an extra draw call, directly hitting performance.

What breaks batching:

• Different textures in neighboring elements (solution: sprite atlas via Sprite Atlas)
• Mask component creates stencil and breaks batch (alternative: RectMask2D—cheaper)
• Canvas with different Render Mode—batching works only within one Canvas
• Any Graphic Raycaster adds overhead—use only on interactive Canvas

Separating Canvas by Content Type

Main architecture recommendation: separate static and dynamic content.

When any Canvas element changes, Unity rebuilds the entire Canvas. If one Canvas holds both static HUD frame and animated health bar—every second the Canvas rebuilds entirely.

Proper structure:

Canvas (Screen Space - Overlay)
├── Canvas_Static     — backgrounds, frames, unanimated icons
├── Canvas_Dynamic    — HP bars, timers, resource counters
└── Canvas_Popup      — modal windows, notifications

Each child Canvas isolates rebuild from parent. Changes in Canvas_Dynamic don't affect Canvas_Static.

TextMeshPro and Text Batching

TextMeshPro (TMP) is the standard for text in Unity. Unlike legacy Text, uses SDF rendering: text stays sharp at any scale. But TMP has a batching quirk: each unique font atlas is a separate material, thus separate draw call.

If game uses three font variants (body, heading, digital) plus versions for each language, text batching breaks. Solution: TMP Font Asset Creator to merge glyphs for needed languages in one atlas. For Cyrillic + Latin + digits typically one 2048×2048 atlas suffices.

Responsive UI for Different Aspect Ratios

Mobile platforms add a problem PC doesn't have: UI must work correctly on 16:9, 18:9, 19.5:9, 4:3, and iPad aspect ratios simultaneously.

Tools:

• Canvas Scaler with Scale With Screen Size mode—basic setup. Reference Resolution 1080×1920 for mobile, Match parameter 0.5 (balance between width and height)
• Anchor Presets—each element pinned to correct edge or center. Screen corner element—to corner, center element—to center
• Safe Area—on notched and rounded-corner devices, buttons shouldn't fall in inaccessible zones. Solution: Screen.safeArea in code, adjusts root RectTransform

Testing happens not just in Game View editor—physical testing on devices or Device Simulator (built into Unity).

UI Localization

Not a separate task, but an architecture requirement from day one. Typical problem: UI designed for Russian text with N characters. German translation is 1.5× longer. Buttons break, text overflows.

At design stage:

• All text fields with Auto Size in TMP or explicit min/max size
• Buttons with Horizontal Layout Group + Content Size Fitter instead of fixed width
• Icons and decorative elements not inserted inline with text via concatenation

For localization implementation, use Unity Localization Package (official) or I2 Localization (asset, more flexible for complex cases).

What This Service Includes

• Design navigation structure and screen flow
• Prototype in Figma and hand off designs to development
• Implement UI components in Unity (uGUI or UI Toolkit)
• Audit existing UI for performance: analyze draw calls, Canvas rebatch, unnecessary Raycaster
• Configure localization system and test with long translations
• Adapt for mobile aspect ratios and Safe Area