The important aspects would be 1. The most requested changes from the app's real users. 2. The impact of design changes on development. So, sorting the list of requested changes based on the development impact would be an ideal approach. And the release can be divided into the phases accordingly.

Quand le temps presse pour apporter des améliorations, je préfère d'abord prendre du recul et faire une liste exhaustive de toutes les modifications possibles, peu importe leur niveau d'importance. Ensuite, en me basant sur les retours utilisateurs, je priorise uniquement les modifications qui apporteront plus de valeurs et d'impact dans l'expérience des utilisateurs. À ce niveau, le maitre mot n'est pas toujours la perfection, mais la rapidité d'implémentation des modifications.

Focus on elements that directly impact user experience and help users achieve their goals efficiently. Ensure core functionality works seamlessly.

Use data and feedback to identify the most problematic areas. If users are dropping off at a particular point, focus on optimizing that part of the design

One thing I’ve found helpful in such time constraints situations is to go back to the 80/20 rule. Collaborate with the stakeholders and come up with the top 20% changes which brings the most value to the user as well as fulfils the business objectives. And, if you already have a product roadmap or backlogs it’s even easier. Also, the design principles which you already have will guide you to prioritise the moral and ethical choices related to the design changes.

Make a list of all possible changes no matter how important they are. Gather user experience data doing a whole app survey from testers. Based on the user feedback , prioritise changes that can bring more value and also helps in the user experience.

What outcomes are the changes trying to produce and what will they drive for our business? Once that is determined for each suggested change, prioritize the ones that align with the impact leadership wants and choose a metric. Implement the change and measure success.

Functionality First! You can add small details and features after the fact, and ensure the basics to make it work are there. If the user can accomplish their aim, you have a functioning product. If you have enough for the engineers to begin building the functionality, you can usually give yourself time to clean up and polish the design or add more to it after the fact. Remember you are a cog in the machine, if your cog isn't completed, the entire machine doesn't work. But also remember, you can create extra work for the entire machine if you do not think through everything and you put forth something that needs to be redone on the next iterations of updates.

Check if it is compatible with the plan so that the application will be taken to get the right result when upgrading does not have a problem

Focus on critical functionality, ensuring usability and accessibility. Address high-visibility areas or frequent pain points, and consider quick wins that offer the most improvement with minimal effort.