Digital Design Agency Development Planning | Blog | Digital Marmalade [Skip to main content](#main-content) ![](https://www.digitalmarmalade.co.uk/pagebuilder/920/download/content_id) Development usually becomes slower and more expensive when projects move into build before the foundations are clear. Unresolved journeys and weak structure create rework during development, and loose requirements make that worse. The question is what needs fixing before those problems reach build. This is the point where a [digital design agency](../../../services) starts affecting delivery, not just design. Before anyone commits to layouts or build estimates, the project needs clarity on what the product is meant to do, how people move through it, and which assumptions still have not been tested properly. On the surface, the project can still look organised. Underneath, scope may still be moving, journeys may not be fully agreed, and decisions that looked minor at first can already start affecting timelines. Why do projects start slowing down before build begins? ------------------------------------------------------- Most delays do not start with code. They start when a project moves into build before the brief can hold up under real use and real content demands. In digital design agency work, this is often where avoidable rework begins. A business may know it wants a new platform or app but still lack clarity on what users need to do, how information should be structured, and what the product must support once real content and real workflows start pushing against it. That usually shows up in familiar ways. Scope shifts after design are approved. Journeys get revisited once edge cases appear. Functionality that sounded simple starts affecting templates or integration work. Approved design stops matching what now needs building. Development slows down for reasons that have very little to do with development capability. What should be fixed before development starts? ----------------------------------------------- This is the stage where key decisions either get settled or come back later and slow build down. Start with the product itself. Then decide how it should appear on screen. For any digital design agency, this is the point where early thinking either gives the project shape, or leaves build to absorb too much uncertainty. Strategic briefing helps bring that shape to the project before build starts taking on too much uncertainty. Why do user journeys need defining before development starts? ------------------------------------------------------------- User journeys need defining early because they decide what the product has to support once real people start using it. If the route from landing page to enquiry, checkout, booking, account action, or admin task is still vague, design and development both start filling the gaps with assumptions. That usually becomes clear once the first simple journey stops being the only journey. A customer needs an extra step. An internal user needs a different route. A task that looked straightforward in design turns out to need clearer prompts, extra states, or stronger admin handling once real use cases start surfacing. This is where projects start slipping. Map the main journeys early, pressure-test the logic behind them, and work out where friction is most likely to appear. That is where user journeys need proper attention, before edge cases start reopening decisions during build. Why should information structure be resolved before build? ---------------------------------------------------------- Information structure needs resolving before build because loose hierarchy usually creates more change later. Pages and content blocks may start taking shape in design files, but the logic behind them often still shifts once real content, real priorities, and real stakeholder input enter the discussion. That is where the pressure starts showing up. Navigation changes late. Page templates start carrying content they were never meant to hold. Stakeholders reopen decisions because the structure still does not reflect what users need to find, what the business needs to prioritise, or what the platform actually has to support. Resolve what content matters most and how users should find it. Then organise the platform around that structure. A [digital design agency](../../../services) should be settling that hierarchy before build starts leaning on it. When hierarchy is clear first, design decisions stop drifting and templates hold up better once real content starts landing in them. Why does functional scope need more definition before development? ------------------------------------------------------------------ Functional scope needs more definition before development because broad ideas stop being useful once build begins. At that point, the project needs sharper answers about what must exist for launch, what can wait, what integrations matter, and what internal workflows the product has to support from the start. This is often where projects get caught out. A feature that sounded small in early discussion starts affecting admin logic, handoff between systems, user permissions, or what phase one now needs to cover. That is when a clean-looking scope starts stretching underneath the surface. Shape the requirement set early. You do not need to lock every detail down too rigidly. You do need enough definition for development to start without constant reinterpretation. In digital design agency work, this is often where cleaner scope protects delivery later. Once requirements keep shifting inside build, time starts going into correction instead of progress. Why should UX logic come before visual design? ---------------------------------------------- UX logic should come before visual design because polished screens can make unresolved product thinking look more complete than it really is. A design can look convincing long before the user flow, edge cases, or internal handling have been worked through properly. That is where false confidence creeps in. A journey looks clean in a presentation, but starts breaking once extra steps, edge cases, admin actions, or different user types enter the picture. By then, visual design may already feel approved, even though the product logic is still moving. Resolve flows, priorities, and interaction logic first. Then build visual design on top of something that can hold up under real use. That sequence reduces redesign later and gives development something more reliable to build from. Why does technical direction need clarifying early? --------------------------------------------------- Technical direction needs clarifying early because design and scope decisions can drift quickly when the build path is still unclear. A project does not need every engineering detail defined before build starts, but it does need enough clarity to stop design work moving away from what the product can realistically support. That usually comes down to practical questions. Is the platform leaning on a CMS, custom functionality, or a mix of both? How complex are the integrations? What does scalability actually mean for this project? How much custom behaviour will the build need to support once real users and real data enter the system? Digital Marmalade helps connect early design thinking to the [software development](../../../services/development) path ahead. That keeps the project grounded and reduces the chance of expensive changes once implementation is under way. This is often the point where projects either stay aligned, or start drifting into rework. If technical direction is still uncertain, this is the point to stop guessing and define what the build actually needs to support. [Talk to Digital Marmalade](../../../contact) before more decisions start compounding the problem. Why does this work need to happen before development starts? ------------------------------------------------------------ Because fixing unresolved decisions during development usually costs more. Once a project enters build, one open question often starts affecting several other areas. Design changes reach into implementation. Requirement changes create rework. New functionality becomes harder to add cleanly because the structure underneath it is still moving. This is also where [discovery work](../../../services/discovery-and-prototyping) What happens when projects skip this stage? ------------------------------------------- When projects skip this stage, drift usually starts early. Reactive decisions replace planned ones, scope grows unevenly, and development begins carrying work that should have been settled before build. That does not always create dramatic failure. More often, it creates drag. Delivery slows down, budget stretches further than expected, and the project keeps solving new versions of the same underlying problem. Digital Marmalade helps prevent that by dealing with those issues before they spread into the build phase. What do you gain when this is done properly? -------------------------------------------- You gain a project that is clearer to build, easier to review, and less likely to keep reopening early decisions. That matters because development moves with more confidence, user experience improves, and the final product has a stronger base because the project has not spent months correcting upstream issues. Digital Marmalade helps settle the logic, structure, and priorities development needs to run properly. When should you bring in a digital design agency? ------------------------------------------------- The best time is before development starts reacting to uncertainty. If the project is still defining journeys, reshaping scope, debating structure, or trying to reconcile business goals with product requirements, that work needs proper attention before build begins. Once development starts carrying that uncertainty, the cost of fixing it rises quickly. That is usually the point where bringing in a [digital design agency](../../../services) saves time and reduces rework. It gives the project a clearer route forward before uncertainty starts setting the pace. Left too late, that uncertainty starts running more of the project than it should. Why this stage shapes everything that follows --------------------------------------------- User journeys, structure, scope, and technical direction shape the outcome long before the first release. Leave them unresolved, and the project carries that cost all the way through. Digital Marmalade can help define what the product needs to do and where the friction sits before development starts. That gives the project a clearer brief and a build phase that does not keep shifting underneath it. [Get in touch](../../../contact) if you want to review what still needs defining, where delivery risk is building, and what the next step should look like before development moves any further. [ Back to news ](/news) June 2026 ### [ How to Implement Software Changes Without Disrupting Ongoing Systems ](https://www.digitalmarmalade.co.uk/news/how-to-implement-software-changes-without-disrupting-ongoing-systems) Read more June 2026 ### [ What Happens When Your Web Apps Stop Matching the Way Your Business Operates ](https://www.digitalmarmalade.co.uk/news/what-happens-when-your-web-apps-stop-matching-the-way-your-business-operates) Read more May 2026 ### [ How website and software development will evolve ](https://www.digitalmarmalade.co.uk/news/how-website-and-software-development-will-evolve) Read more Allow cookies