How to prepare your teams for a redesign (without internal chaos)

A redesign rarely starts with a team problem. It starts with a simple intention: improving the site, correcting what no longer works, passing a course.

Then, quite quickly, the subject changes.

Discussions no longer focus on pages or features, but on arbitrations. Who decides? What is the priority? How far to go? And above all: who will really make the site live once online?

This is often where complexity arises. Not because the project is not well thought out, but because it puts into tension topics that have remained implicit until then: roles, responsibilities, modes of collaboration.

Redesign acts as a revelation.

Essential in 30 seconds

A redesign does not derail because the solution is bad. It slips because the organization around is not ready.

When the rules of the game are not clear – who decides, who produces, who validates – the project advances... then slows down. Decisions come back, priorities move, and energy is dispersing.

Conversely, when these points are set early, everything becomes simpler: arbitrations are faster, teams are more autonomous, and the site has a real chance to exist after it is put online.

Redesign rarely fails for technical reasons

At first, everything seems fluid. The workshops are moving forward, the screens are taking shape, the teams are involved. We talk about user experience, design, sometimes performance.

Then, gradually, something changes. A validated decision returns to the table. A subject that was thought to be decided becomes open again. Backlog grows without really structure.

And with the approach to online publishing, a simple question comes up, often too late: who will manage the site on a daily basis? Who publishes? Who's valid? At what level of autonomy? On what content?

At that time, the project slowed down. Not because the technique blocks, but because the next was not actually thought out.

Classic mistakes and how to recognize them early

Some signals appear early, but often go unnoticed.

The first is when the redesign is approached as a design topic before being a business subject. Discussions revolve around pages, inspirations, interface. Everything is consistent... But no one clearly formulates what the site must produce: more leads, better qualify, shorten a sales cycle.

The result, a few months later, is quite classic: a more modern site, but difficult to drive. The contents exist, but they do not serve a clear mechanics.

Another frequent signal is that governance is based on simplicity.
"We decide together" works very well... until the moment when we have to decide. There, decisions stretch, meetings lengthen, and some topics come back several times without ever being really closed.

This is not a problem of competence. It's a framework problem.

There's also everything. as regards exploitation, often postponed to the end. As long as the site is not online, the question seems secondary. And yet, it is she who conditions everything: if publishing a page requires too much effort, too many validations, or too much technique, the site will not live.

Finally, there is the gap between teams. Marketing advances with its content and conversion issues. TIT, with its security, performance and integration constraints. Both are legitimate. But without explicit alignment, arbitrations come too late, and everyone feels like they are going through the decisions.

Taken separately, these points are manageable. Together, they create an inertia difficult to catch.

The 5-pillar method to prepare your team

Preparing teams does not mean adding complexity or producing more documentation.

Rather, it means making certain things clear before they become problems.

1. Clarify vision

First, the direction. Not a theoretical vision, but something useful to decide. When a project moves forward without explicit priorities, everything becomes important. And when everything is important, nothing really is anymore. On the other hand, a few well-established objectives are often sufficient to simplify arbitration considerably.

2. Structure governance

Then the decision. Many projects simply slow down because no one is legitimate to decide quickly. Clarify who decides, on which topics, immediately changes the dynamics. This is not a question of hierarchy, but of responsibility.

3. Define roles

Roles play the same role of accelerator — or brake. As long as everyone "can" produce, validate or publish, everything depends on people and situations. As soon as these roles are stabilized, even in a simple way, friction decreases sharply.

4. Anticipating exploitation

Exploitation deserves to be thought early. Not in detail, but in general: what types of content will be produced, how often, with what level of autonomy. A site based on permanent special cases quickly becomes unmanageable. A site that relies on a few clear models becomes usable.

5. Supporting Change

Finally, there is adoption. A new tool, even well designed, is not required. Without a minimum of accompaniment, the teams bypass, return to their habits, or constantly seek the same people. A few demonstrations, concrete examples, and a simple framework are often enough to avoid this.

None of this is complex. But none of this happens on its own!

Two contexts, the same issue

According to the organizations, the recast does not pose exactly the same challenges.

When marketing alone drives, the main issue is autonomy. Produce, publish, test without dependent on technique. The temptation is then to want too much flexibility, at the risk of making the tool difficult to use.

When IT is heavily involved, other constraints come into play: safety, performance, integration into the IS. Arbitrations are more structuring, but also more sensitive.

In both cases, the key point remains the same: making explicit who decides, and on which topics.

This is what prevents tensions from moving in the project.

"Are we ready?" Rapid diagnosis

Some clues are quite reliable.

When site objectives are difficult to formulate simply, decisions will be made.
When arbitrations systematically require consensus, they will take time.
When no one really knows who will publish in a few months, adoption will be fragile.

Conversely, when these points are clear – even imperfectly – the project becomes much more legible.

And often, faster.

What it changes, concretely

The difference is not spectacular at first.

The workshops remain the same. Deliverables too. Nothing seems radically different.

But gradually, the differences appear.

On the one hand, projects where decisions stretch, where teams adjust constantly, where online placement marks almost the end of the topic.

On the other hand, projects where arbitrations are simpler, where teams know what to do, and where the site actually starts to live once published.

It's not a miracle method.
It is a question of clarity.

When to get help

It is not always necessary to do more. Often the real need is to make explicit what is not yet clear: who decides, how teams work together, which is really a priority.

An external look can help. Not to complicate, but to structure. Put words on blurred areas, put a readable frame, and avoid some critical topics appearing too late.

A redesign remains a technical project. But its success is almost always organizational.

If you are in this phase of clarification, you can also flatten your situation with us, just to see more clearly.