I tend to postpone the real UI design until most of a larger project is working. Starting with polished screens often leads me to discover that the underlying functionality doesn't fit the layout, so I keep rearranging components and tweaking details that may need to change again later.
Instead, I usually build a rough development interface first, complete the functional work, and then revisit the UI and UX to make everything clear and easy for users. The problem is that after coding and testing with the temporary interface for months, I become familiar with it and start resisting the move to a more professional design.
Would it be better to design the UI earlier, or is it reasonable to keep the rough interface until the functionality settles? How can I avoid mistaking familiarity with a development UI for genuinely good usability?
5 Answers
UI isn’t separate from the functional work—it’s the part of the functionality users actually experience. You don’t necessarily need to finish the visual design first, but user flows and usability should influence the project from the beginning. A technically complete system with an unintuitive interface may still fail its users.
A useful middle ground is to prototype the important user flows early, without spending time on visual polish. That lets you discover layout and interaction problems while the system is still flexible, but avoids locking you into a finished-looking design before the functionality is stable.
You can make the temporary interface deliberately disposable. Keep it plain and functional, and avoid investing in styling that might make you want to preserve it. The goal is to use it for testing the system, not to let it quietly become the product.
The impact of this depends on the technology stack. If the UI is difficult to change, planning more of it upfront may save rework. With a flexible stack, you can usually keep the implementation rough while iterating on the structure and interaction patterns without committing to a final visual style.
Show the development UI to someone who hasn’t been working on the project. Developers become experts at navigating around awkward flows because they already know how everything works, while a new user will immediately reveal confusing labels, missing guidance, or unintuitive steps. Early outside feedback can break that familiarity bias.
That distinction makes sense: the easier the interface is to modify, the less dangerous it is to defer visual polish, but the main workflows still need attention early.