Technically, the short answer is both never and when reaching the release-ready stage - a solution that solves users' core problems and needs - at the same time. The caveat here is not to get carried away with visual enhancements and interactions before you feel comfortable releasing your product into the world. As with anything creative, there will always be an opportunity to improve, so it's essential to have a solid foundation to build upon and a product that will be in demand.
Some people are visionaries who can predict user behavior even if there isn't a need for the product - and there's nothing worse than putting all your sweat, tears, and effort into something that nobody will ever want. Future products also follow the same rule to answer this all-important question - the design is complete when it reaches the pinnacle of solving a problem for its user.
Align on the most viable product
It's almost easier to work on a short deadline because you will prioritize more efficiency and create a lean product to test and release. Not only this, but you will receive your feedback quicker, allowing you to move on to the next -and hopefully improved - version. When working on a longer timeline, it's vital to have a clear scope of vision and break the design down into stages. Agree with your stakeholders on what the MVP is, test it with your users, and make all of the necessary updates - the features and visuals will be simple, but at the end of the day, that's the whole point.
What's wrong with polishing and trying to do a little more to make the design better, you might ask? While there's nothing wrong with going beyond P0 and P1, it’s a trickle-down process in development. Just because you designed it now doesn't mean it will get implemented right away. It’s also important to note that you work in a team so remember your designated race - you are in the relay, not a sprint, and you have to ensure you don't hold up the engineers. Crucially, while some changes will be necessary and inevitable problems will need to be addressed immediately, this isn't the case for the entire design.
The product may work just fine without Y and Z, but not X - so prioritize and focus on getting X completed and validated before moving on to any other additional features.
Proper fidelity
The design you create needs to solve and circle back to the original problem statement - but UX alone isn't enough, and proper visual fidelity needs to be in place. Does your company use a style guide? Follow it to make the process easier and work with your team on any new components that need to be created for your product. If you are in a position where there is no style guide in place, no product, and you are starting from the ground up, make sure you still stick to solving the UX first and work on the visuals later. While exploring your design journey, it's good to keep thinking of what the design system would look like, so try to stick to standard interaction elements where possible when building the first version of the product. Another way to think about it is trying to see how much you can cut before the product breaks. You should be left with the bare bones of the experience, allowing you to validate and then build upon it.
Sometimes the design isn't finished
For products that haven't reached their EOL (end of life), there will always be iterations and new features to add. Adding those features on top of what has already been created involves the same process as building something from scratch - you have to solve the problem in place with proper fidelity, test it and then release it. You're probably left thinking, "so when do I get to make something really cool?" Solving a problem and helping users is already great! Still, if you are looking for slick visual coolness, that can be done as a separate project - usually a part of P2 - and is when the engineering team can implement all the fancy visuals and animations you want.
