As a designer, your job could be described, fundamentally, as "to find/create the best solution(s) to a given set of challenges". Within that function are the tasks of recognising, and responding to a solution that is not working out. You'll find people on your team, and further afield that help you with the recognising part, but the response part, that probably rests squarely on your shoulders.
Your response will fall into one of two categories: 1) Adapt/tweak/iterate. 2) In the immortal words of Edwyn Collins - rip it up and start again. The first option will usually be the way to go, but sometimes the second option is the best path forward, however daunting.
If you're working in an environment that is genuinely in pursuit of good design/solutions, then time will not be the dominant factor in your decision making. Chances are though, more often than not, it's going to be a pretty big one. Making the decision to start over can feel like a step backwards; taking a step backwards can feel counterproductive with a deadline looming. I prefer though to think of it as a step forward; a step forward for the design, as opposed to a step backwards on the timeline. After all, time is a secondary concern here, right? There can also be a reluctance that stems from the time invested in the thing you are about to "throw away". This is an understandable concern, but you shouldn't let it tempt you down the wrong path. If you are confident that you can get to where you want to be, without using the stuff you've already made, with the resources you have left, then this has to be a valid option. There's a limited window here, there will usually come a point in a project where starting again is just not feasible. As much as I argue for quality over speed, a timeline is a real, and important aspect of any project. The further along that timeline you find yourself, the more difficult it is going to be to make the decision to go back to the drawing board. In my experience, the counterintuitive path can actually be a more efficient route to where you want to be. The alternative can mean sinking a lot of time and energy into trying to tweak your way to a completely new solution.
To keep the rip it up option alive, you need to obtain and understand the game changing insights as early as possible. There are established processes in the design world, built for this purpose, such as getting feedback to wireframes/schematics before spending time on comprehensive designs. In any such process that allows you to gain insight from a minimal investment of time, there is a balance to be found between time invested in something that will not form part of the finished product and time potentially wasted working on the wrong finished product. This is an accepted principle in the design industry, most web designers will be happy to spend the "extra" time on schematics, in order to minimise the chance of more costly reworkings further down the line. Decisions of this nature are made throughout a project and effect the options available to you when those game changing insights surface. The right decisions are going to differ from project to project, from designer to designer, but I believe it is essentially about striking a balance between allowing yourself freedom to experiment and get things wrong, and committing to an idea when the time is right. For example, a decision I make when designing a webpage is whether to design in an image editing application or in code. There are many good arguments for the latter, and there are people who will argue that if your not designing in code then you are doing it wrong, but I typically like to incorporate a phase of static designs, because I feel it gives me more of the aforementioned freedom (this probably also means getting designs in front of stakeholders more quickly, so they can give you the feedback that they should have given you when looking at the wireframes). I don't do this because I prefer designing statically per se. To be clear, I'm someone who spends a lot of time designing in code, and believe it is the right way to go, but only once the initial experimentation (and possibly getting things wrong) is done. Code (at least good code that you intend to be used in the live project) represents a significant investment, one that can be difficult to discard. So I go out of my way to design in the old-school way in order to maintain the freedom to make big changes.
We probably all like to believe that we'll get things right first time, especially in matters that we consider ourselves expert. I advocate for recognising when we don't. In order to get things right on the next attempt, we need to give ourselves the freedom to rip it up and start again.
Wait, what's all this about moving to the other end of the country? I'm currently one third of the way through a Masters degree, at my first choice of university for this course - Norwich University of the Arts. In practice it hasn't felt quite like the right fit for for me. I feel I am in that critical period where starting over still feels feasible. So having considered both the tweak and rip it up options, I'm taking my own advice and seeking a new solution. I'm very excited to have accepted a place on a Masters at Edinburgh Collage of Art.