Le lancement de votre application web approche. Comment allez-vous gérer les changements UX/UI qui menacent la chronologie ?

In situations like these, I’ve found that maintaining flexibility while being decisive is crucial. It’s important to weigh the trade-offs carefully. Sometimes, it’s better to focus on core functionalities and user experience elements that can be refined post-launch. This ensures that you meet your launch deadline while still delivering a solid product. Collaborating closely with your UX/UI team to quickly identify which changes are essential and which can be deferred helps keep everyone aligned and focused. By striking a balance between meeting deadlines and ensuring a positive user experience, you can navigate last-minute changes without compromising the overall success of your launch.

According to experience, in such a situation the best solution is to focus on the main features and choose changes that are aimed at the final product that meets the main needs of the end user and continue to update the product according to the required changes. Because many changes may make the product out of user-friendly mode and the user needs to be constantly connected with new changes.

Yes, that's totally correct. Do the right thing. We need to aim for MinimumViableProduct(MVP) for the initial launch. Then we adopt the patterns and additional extensions to it as we move on.

If that changes fix UI issue that is blocking user from using the product then it is a high priority. The prioritization principle I think should be, in order: 1. Fixes that keeping the product usable. 2. Fixes that help customers on using the product, such as bug reports and improvement suggestions. 3. Fixes that can help to attract new customer.

It is all about applying agile to your benefit. Nowadays the web applications are hosted model. That is they are offered as a service so call SAAS model. So this gives a bit of freedom in terms of changing the user interface even after the product has been launched. That being said the user interface should be minimal but functional initially. Later on, based on the user feedback and further design engineering it should be improved and released in the subsequentyears.

Use Agile Kanban with no sprints so you don't have to focus on sprint impact and definition. Just keep your changes prioritized and small, then it is almost business as usual. You may need to table certain cards to free up resources to focus on higher priority cards. Using sprints in a pre-launch situation is likely excessive, especially if you have a small team. Remember that there is more to Agile than just Scrum, use a process that fits the current state of your business.

Agile introduced and used to achieve complex things in modular structure, So that continues development can take place in order to achieve long features.

Probably the biggest advantage of having an agile approach is that you can stop working on the feature any time, you will still have a version of the feature: you don't have to wait until everything is developed to be able to see the feature working. So the idea is to start with MRF (minimum representative feature - "just invented the expression" :-), to test if it grabs the time attention of your users, if the user interest is confirmed by numbers, iterate over that. Otherwise, you can stop anytime, and rethink.

Always show the demo and get the feedbacks from the concerned business or users. This will help in doing things in right way and right manner. User testing covers most of the real tome scenarios.

Break down testing into smaller stages. By focus on high-impact features rather than the entire product for example the checkout etc. This will help you have effective insights quickly.

There's a catch in "knowing" what the user will value most: it is not what you "think" the user will value most. And the only way to "know" is by asking the user. Read about ways to AB test users to obtain sufficiently representative user feedback. Start with a minimalistic version of your feature, if users complain about it not being well implemented, then you found a good feature: Users usually simply ignore things they don't care about, so if they took the time to complain, you're holding a feature they desperately need.

Don't forget that the product launch is not a day you wake up and launch, it is preceded by smaller user groups, preferably partners, testing and using your feature everyday, then expending the user count to verify that your servers will not start to smoke when higher loads will poke them. This all assumes you already verified that your feature is a gold mine, so it's rather a happy than a stressful journey, because you know you will have success after solving all the issues.

Stakeholders need to communicate about the feature you're about to release before your team finishes developing it. So it is crucial for them not to communicate a date, then discover that the feature is not ready yet. That's why it is always preferable to announce safe dates instead of trying to show that you are a smart team that works fast. Your stakeholders don't know the complexity of the task you're doing, if you say it will take 6 months, they will not argue that it can be done in two. Because first: they don't know, but mostly: they don't care. They have other concerns, and it's about what they will communicate and how much money it will bring, from their perspective, it is an expense, like buying a tool to get things done.

Be the user of your own application. See if the UI that is being proposed is doing what it meant to do at that moment of time. Changes will come and has to be incorporated as and when required.

What you see is what you get. An application with soild UI/UX can perform better in the market. Having said that, if the requested changes are of just additional nature they can surely wait else all the stakeholders need to adjust somewhat to reach the middle ground interms of timelines, impact etc.