# Нужен ли редизайн сайту: как отделить проблему от желания обновить картинку

Как проверить причины редизайна, отличить локальную ошибку от проблемы структуры и собрать наблюдения до заказа нового дизайна.

Автор: Редакция KEIVO
Дата публикации: 2026-10-28
Канонический URL: https://keivo.ru/blog/kogda-nuzhen-redizayn-sayta/

Фраза «сайту нужен редизайн» пока ничего не говорит о работе. Возможно, посетителю трудно найти условия. Возможно, текст не соответствует услуге. Или команда просто устала от прежнего оформления. Эти причины требуют разных решений, хотя в разговоре звучат одинаково.

Начните с задачи человека на сайте. Для страницы услуги это может быть проверка, подходит ли предложение, и поиск следующего шага. Для каталога — выбор подходящего товара. Не оценивайте весь сайт одним словом «современный»: попробуйте пройти конкретный путь.

Редакционная схема KEIVO. [Открыть схему в PNG](/blog/_media/p3-20261028/a01-4413d1bd04b7.png).

## Назовите проблему так, чтобы её можно было проверить

«Непонятная страница» — впечатление. «На странице не удаётся найти, входит ли доставка в заказ» — уже наблюдение. Во втором случае известно, что нужно искать и по какому признаку оценить изменение.

Запишите исходную задачу, место затруднения и условия просмотра. Имеет значение, проверяли ли вы телефон или большой экран, новый визит или страницу, которую сами знаете наизусть. Не превращайте собственную привычку в доказательство удобства для покупателя.

Если есть обращения клиентов, записи поддержки или доступная аналитика, сопоставьте их с наблюдением. Однако отсутствие клика не объясняет причину само по себе. Человек мог не заметить кнопку, не понять предложение или вообще прийти с другой задачей. Формулируйте несколько возможных объяснений, а не диагноз по одному показателю.

В [рекомендациях Nielsen Norman Group о редизайне](https://www.nngroup.com/articles/radical-incremental-redesign/) изменения связывают с пользовательскими данными и ясными целями. Это полезная отправная точка, а не доказательство, что конкретному сайту нужен полный пересмотр.

## Отделите содержание, интерфейс и техническую ошибку

Представим учебную страницу услуги. На телефоне кнопка закрывает часть текста, в описании остались старые условия, а форма не доставляет сообщение. Перерисовать первый экран недостаточно: здесь смешаны задачи вёрстки, содержания и приёма обращения.

| Наблюдение | Проверка и возможная работа |
| --- | --- |
| На странице не находят условия | Есть ли они вообще и понятно ли названы. Возможна правка текста и его расположения |
| Узкий экран перекрывает действие | Поведение конкретного блока на телефоне. Возможна локальная правка адаптива |
| Разные разделы по-разному объясняют одну услугу | Структура и актуальность содержания. Обсуждаем согласование страниц и шаблонов |
| Кнопку нажимают, но обращение не приходит | Реальный путь данных после нажатия. Нужна техническая проверка приёма, не только дизайн |

Таблица предлагает направления проверки. Она не устанавливает причину проблемы без изучения самого сайта.

Быстрый осмотр клавиатуры, заголовков и текстовых альтернатив изображений можно начать с [Easy Checks W3C](https://www.w3.org/WAI/test-evaluate/preliminary/). Авторы отдельно предупреждают: такой осмотр не заменяет полноценную оценку доступности. По той же причине один удачный просмотр на телефоне не закрывает весь сайт.

## Когда имеет смысл обсуждать более широкий редизайн

Полный пересмотр стоит рассматривать, если отдельные исправления упираются в общую проблему. Например, новая услуга не помещается в старую структуру, одинаковые сценарии собраны из несогласованных шаблонов или навигация отражает устройство компании, а не задачи посетителя.

Это повод сравнить варианты, а не команда немедленно заменить всё. Попросите описать, что сохраняется, что меняется и почему локальной правки недостаточно. Иногда подходящим решением окажется новый шаблон для части разделов. Иногда сначала понадобится привести в порядок содержание.

Срок существования сайта сам по себе не задаёт решение. Полезнее проверить, изменились ли продукт, аудитория и задачи. Если причина только в том, что оформление надоело внутри команды, это следует честно назвать визуальным обновлением и оценивать его в этих границах.

↗

Логика решения

Задача посетителя → наблюдаемое препятствие → проверка причины → минимально достаточное изменение.

## Что сохранить до обсуждения новых экранов

Соберите список важных страниц и действий, которые уже работают. Отметьте содержание, которое нельзя потерять, внешние ссылки и узнаваемые элементы. Новый макет не должен случайно удалить то, ради чего человек пришёл.

Для каждой найденной проблемы сохраните пример: адрес, снимок или описание сценария. Рядом укажите, что считаете приемлемым результатом. «Страница должна нравиться» оставляет спор открытым. «Условия доступны со страницы услуги и читаются на телефоне» позволяет проверить результат.

Эту подготовку удобно превратить в [техническое задание на редизайн](/blog/tehnicheskoe-zadanie-na-redizayn/). Если пока непонятен масштаб, сначала разберите [из чего складывается стоимость](/blog/stoimost-redizayna-sayta/): там отделены отдельные страницы, общие шаблоны и зависимости.

## Как принять первое решение

Выберите следующий шаг по собранным свидетельствам. Локальная проблема — ограниченная проверка и исправление. Несогласованные страницы — работа со структурой и шаблонами. Неясная причина — дополнительное изучение задачи до заказа макетов.

Не обязательно иметь окончательный план всего сайта. Достаточно объяснить, какая проблема уже подтверждена, что осталось предположением и как вы собираетесь различить эти варианты. С таким списком можно обсуждать конкретную границу дизайна и вёрстки.

В [описании услуги редизайна KEIVO](/services/redesign/) отдельно обозначены дизайн, вёрстка и задачи, которые требуют дополнительного согласования. Если решение об обновлении уже принято, следующий материал — [этапы редизайна и точки приёмки](/blog/etapy-redizayna-sayta/).

## Источники и границы

- [NN/g: радикальный редизайн и последовательные изменения](https://www.nngroup.com/articles/radical-incremental-redesign/) — основание для проверки целей перед масштабным изменением.
- [W3C: предварительные проверки доступности](https://www.w3.org/WAI/test-evaluate/preliminary/) — примеры проверок и ограничение их полноты.

Матрица решения и учебная страница в статье предложены редакцией KEIVO. Это не клиентский кейс, исследование аудитории вашего сайта или обещание роста обращений.