What Happens When Development Starts Before UI/UX Design Is Ready?
— QUESTIONS & ANSWERS
What Happens When
Development Starts
Before
UI/UX Design Is Ready?
Project Management + UI/UX Delivery
When development starts before important UI/UX decisions are ready, unanswered design questions become engineering decisions by default. Developers may have to invent workflow behavior, missing states, navigation details, and interface patterns simply to keep implementation moving. The result can be rework, inconsistency, additional QA, and expensive changes after code already exists.
This does not mean every screen must be finished before development begins. It means approved design should stay far enough ahead of implementation that engineering is building known decisions rather than filling product gaps under deadline pressure.
Unanswered UX Questions Become Engineering Decisions
A developer receives a requirement, encounters a missing interaction, and makes a reasonable choice. Another developer encounters a similar situation somewhere else and makes a slightly different choice. Both decisions may be defensible in isolation.
The problem appears when those local decisions accumulate across the product. Navigation, validation, actions, terminology, and states begin to behave differently because there was no shared UX direction at the time the code was written.
Missing States Surface Late
Software needs more than the ideal path. Loading, errors, permissions, empty data, unavailable actions, validation, interrupted processes, success states, and unusual data conditions all affect what users see and what engineering must build.
If those states are not considered during design, development either has to stop and request them or create them independently. Both outcomes can affect the schedule, and both increase the chance that important behavior is discovered during QA instead of before implementation.
Rework Gets More Expensive After Code Exists
Changing a workflow in a flow map or prototype is usually faster than changing the same workflow after front-end logic, backend dependencies, analytics, testing, and multiple responsive states have been implemented.
That is one of the practical business values of UI/UX design. It gives the team a less expensive environment for resolving product decisions before engineering invests heavily in them.
Keep Approved Design Ahead of Implementation
Large software projects can still move quickly by running design and development in planned phases. Engineering begins on the workflows that are approved while UI/UX continues working ahead on what comes next.
The project manager should make the boundary visible. Teams need to know which areas are ready to build, which are still under review, and which decisions remain unresolved so implementation does not outrun the product.
AVASIS
Construction Management Platform
AVASIS is a direct example of what can happen when development gets ahead of UI/UX. Development had already started before The Skins Factory was brought into the project, and the client had initially allowed the development team to drive product and interface decisions in order to keep the build moving.
Once UI/UX was brought in, the platform had to be reorganized around the needs of project owners, architects, engineers, contractors, subcontractors, title and insurance companies, and bankers. Budgets, schedules, teams, action items, communication, documents, photos, roles, and permissions all had to work together as one coherent system. The project illustrates why engineering should implement defined product decisions rather than being forced to make them by default.
View the AVASIS Project →Common Questions
Frequently Asked Questions
Should development wait until every UI/UX screen is finished?
No. Design and development can run in parallel when the project is phased carefully. Engineering should begin with workflows that have been reviewed, approved, and defined well enough to build, while the UI/UX team stays ahead on the next implementation areas. The goal is not to finish the entire product before coding starts. It is to maintain enough design runway that developers are not routinely waiting for decisions or inventing missing behavior themselves.
What UI states are commonly missed when development starts too early?
Common gaps include empty states, validation, errors, loading, permissions, unavailable actions, success states, confirmation behavior, responsive states, and what happens when a process is interrupted. These states often look secondary during early planning, but they are part of the real product experience and still have to be implemented. When they are discovered during development or QA instead of design, the team may have to revisit screens, logic, copy, and acceptance criteria that were already considered complete.
Should UI/UX designers stay involved after development begins?
Yes. Questions often appear during implementation because engineers are translating approved designs into working software and encountering real technical conditions, edge cases, or data behavior. Keeping designers available lets the team resolve ambiguity quickly, clarify intended interactions, and review whether implementation still matches the approved experience. Handoff should be a transition into implementation support, not the point where UI/UX disappears from the project.
Continue Exploring
Explore More
SaaS UI/UX Design for Enterprise Software
See how The Skins Factory approaches complex enterprise software where workflows, roles, implementation constraints, and product decisions all have to stay aligned.
→ Further ReadingHow to Build an MVP for a Startup
See how product definition, user flows, prototyping, UI/UX design, and phased development can reduce uncertainty before too much implementation work is already in place.
→Is Development Moving Faster Than the Product Decisions?
The Skins Factory can step into an active software project and work with your product and engineering teams to resolve UI/UX before uncertainty turns into more implementation rework. We focus on clear workflows, interface behavior, prototypes where needed, and development-ready source files.
Development already moving? Let's chat.
Thank you for reaching out.
We will be in touch within one business day.