How long does it take to design a game's UI?

The short answer

Two numbers per row, because they are not the same. Design days is the work. Elapsed weeks is how long it takes in the real world, including your feedback, approvals and the days nobody is available.

The five stages, and what each needs

Every project I run has the same five stages, whether it is one screen or thirty. Percentages are of total design time.

1. 01

   Discovery, about 10 percent

   Play the build, read the systems, list every screen and state, agree what is in scope. One to three days. Skipping this does not save time, it moves the same work into week four where it is more expensive.

2. 02

   Flow and wireframes, about 25 percent

   Structure, navigation, hierarchy, greyscale. This is the cheapest place to be wrong and the stage that most affects the final result. Expect roughly a quarter of the schedule here and resist the urge to compress it.

3. 03

   Visual direction, about 15 percent

   One or two screens taken to final quality to establish the language: type, colour, spacing, component style. Everything downstream inherits from this, which is why it gets a milestone of its own.

4. 04

   Production screens, about 40 percent

   Applying the approved language across everything else. The largest block, and the most predictable one: once the system exists, screens land at a steady rate.

5. 05

   Handoff and support, about 10 percent

   Exports, naming, a spec, and answering questions during implementation. Teams that skip this pay for it in engineering hours instead.

The useful consequence of those percentages: at the end of week one you should have wireframes, not artwork. If you are being shown finished screens in the first few days, structure is being skipped, and that is the most reliable predictor of a project that overruns.

What makes it take longer

1. More than one decision maker. The single biggest multiplier on elapsed time. Three people with equal authority can add weeks without adding a single hour of design.
2. Slow or scattered feedback. Notes arriving over four days instead of in one list turns a one-day revision into a four-day one.
3. Systems still changing. If the crafting rules change in week three, the crafting screens restart. Design cannot be more finished than the design of the game.
4. Content arriving late. Real item names, longest strings and biggest numbers. Layouts break on real content, and they break late if you supply it late.
5. A second platform added mid-project. Adding console after the layouts are locked means rethinking navigation on every screen.
6. No engineer available. Handoff questions that wait three days each add up faster than anyone expects.

What makes it faster

• One decision maker with authority. Worth more than any other single factor.
• Feedback in one consolidated list, within an agreed window, from one person.
• A screen list before day one, even a rough one. It removes the discovery guesswork.
• Real content up front. Cheap for you, expensive to be without.
• Approving the visual direction properly, once, rather than revisiting it in week six.
• Accepting that some screens can inherit the system instead of being individually designed.

Run it in parallel with development, not after it

The most common scheduling mistake is treating interface design as a phase near the end, after the systems are built. It is the most expensive way to sequence it, for two reasons.

First, the UI regularly reveals that a system asks the player for too much. Discovering that while the system is still being written costs a conversation. Discovering it after it ships costs a rewrite. Second, a finished game with placeholder menus cannot be shown to anyone: not press, not publishers, not a store page, which quietly delays everything commercial.

The right shape is design running one step ahead of implementation, screen by screen, from the moment the core loop is playable. It also spreads the cost across production instead of concentrating it in one invoice at the worst possible moment.

A realistic eight-week schedule

For a small-to-mid title, roughly 20 screens, one designer part-time alongside your team.

Weeks four to seven are the ones that stretch when feedback is slow. Weeks one to three are the ones people try to cut, and cutting them is what makes weeks four to seven stretch.

What actually gets cut when you rush

A rushed schedule does not produce the same UI faster. It produces a different, thinner UI. Knowing what gets dropped lets you choose deliberately instead of finding out later.

If the deadline genuinely cannot move, cut screens, not stages. Four screens designed properly and sixteen inheriting a system beats twenty screens that all skipped wireframes.

How to protect your date

1. 01

   Work backwards from the milestone, not forwards from today

   Put handoff a full two weeks before your deadline. Implementation always takes longer than the estimate, and that gap is the only thing standing between you and a bad week.

2. 02

   Name one decision maker in writing

   Not a committee, not "we will discuss it". One person whose approval is final, with a named substitute for when they are away.

3. 03

   Agree a feedback window

   Two working days per milestone, one consolidated list. Write it into the schedule so late feedback is visibly a schedule change rather than a favour.

4. 04

   Front-load the visual direction decision

   Have the argument about how it looks in week three, on two screens. Having it in week seven means repainting twenty.

5. 05

   Book the handoff week

   Reserve your engineer's time for it in advance. A design delivered to nobody is not delivered.

The Astro Protocol interface was built this way across a full production: direction decided early, then defended screen by screen as the feature list grew. That is what keeps a schedule intact, not working faster.