Ответ на вопрос «сколько стоит редизайн сайта» полезен вместе с описанием результата. Оценка нового макета страницы и оценка готовой работающей версии — разные предметы разговора. Если не разделить их в начале, сравнение предложений будет неточным.
Здесь нет средней цены по рынку и прайса KEIVO: для них нужны подтверждённые условия и сопоставимые исходные данные. Вместо этого разберём, какие сведения стоит собрать, чтобы получить оценку именно своей задачи.
Считать адреса или шаблоны?
Сначала составьте перечень страниц, затем сгруппируйте их по устройству. Несколько адресов могут использовать общий шаблон. А внешне похожие страницы могут потребовать разных состояний и правил. В запросе на оценку нужны оба списка: что существует на сайте и какие самостоятельные решения предстоит спроектировать.
Например, у учебного каталога есть список товаров и карточка. Если карточки устроены одинаково, имеет смысл отдельно описать общий шаблон и перенос содержимого. Если часть товаров требует другой структуры характеристик, это нужно показать до оценки. Это условный пример состава работ, не расчёт реального проекта.
Не пытайтесь самостоятельно перевести число страниц в часы по универсальному коэффициенту. Уточните у исполнителя, какие элементы считаются повторными и какое различие меняет объём. Запишите это объяснение рядом с итоговой оценкой.
Что должно попасть в состав предложения
Удобно разделить результат на несколько частей. Это редакционная схема для обсуждения; конкретная команда может группировать работы иначе.
| Часть работы | Что уточнить |
|---|---|
| Подготовка | Кто проверяет текущую страницу, собирает ограничения и согласует содержание |
| Дизайн | Какие шаблоны, ширины, компоненты и состояния входят |
| Вёрстка | Какие экраны становятся HTML/CSS и какое поведение реализуется |
| Интеграция | Кто связывает интерфейс с действующей системой и данными |
| Содержание | Кто пишет, проверяет, переносит тексты и подготавливает изображения |
| Приёмка | Какие сценарии проверяются и кто фиксирует результат |
| Выпуск | Кто размещает изменения, проверяет адреса и готовит возврат версии |
Само наличие формы в макете не означает, что в предложение включены доставка сообщений и хранение данных. MDN различает браузерную и серверную проверку ввода. В смете также полезно разделять интерфейс и фактическую обработку обращения.
Для KEIVO текущая продуктовая основа — дизайн и вёрстка. Готовность интеграции с конкретной CMS, CRM или backend нельзя выводить из этого названия. Границы изложены на странице услуги редизайна.
Неизвестное лучше записать рядом с оценкой
Предположим, новую карточку нужно встроить в действующий магазин. Пока не проверены доступы и способ подключения шаблона, часть работы остаётся неизвестной. Попросите отдельно обозначить эту зависимость: что надо изучить, кто даст сведения и после какого решения оценка будет уточнена.
Такое уточнение не следует автоматически считать недостатком предложения. Проблема возникает, когда неопределённость скрыта за обещанием сделать всё, а участники понимают результат по-разному.
Сравнивайте также условия изменений. Что происходит, если после согласования появляется новый тип страницы? Как фиксируется новая версия задания? Какие замечания относятся к согласованному результату, а какие расширяют задачу? Ответы нужны до начала работы, без попытки заранее предсказать каждое возможное исправление.
Как сравнить предложения без догадок
Возьмите одну версию задания и отметьте, где предложения различаются. Если в одном есть вёрстка и перенос содержания, а в другом только макеты, итоговые суммы нельзя сравнивать как цену одной услуги. Сначала приведите к общему виду состав результата.
Не нужно требовать одинаковую внутреннюю разбивку у всех команд. Попросите понятное описание того, что вы получите и что останется на вашей стороне. Например, кто подготовит финальные тексты, проверит мобильные состояния и разберётся с действующей формой.
Если задача состоит в ограниченном обновлении, так и опишите её. Сохранение работающей структуры или части компонентов можно обсудить как вариант. Но заранее обещать экономию от повторного использования нельзя: сначала нужно проверить, действительно ли имеющееся решение подходит.
Перед оценкой полезны проверка необходимости редизайна и задание с критериями результата. Они помогают не заказывать полный пересмотр там, где пока подтверждена только одна проблема.
Что отправить для первой оценки
Подготовьте адрес существующего сайта, перечень изменяемых страниц, описание проблемы и желаемого результата. Приложите актуальное содержание и известные технические ограничения. Секреты и пароли в общий бриф включать не нужно: доступы передают отдельно по согласованному безопасному процессу.
Отметьте, что должно сохраниться: важные адреса, содержание, работающие действия и особенности текущей системы. Если неизвестно, потребуется ли менять URL, внесите это в список вопросов. Контроль поискового риска при редизайне рассматривается отдельно от визуальных макетов.
Результатом первого разговора должна стать понятная граница работы. Если граница всё ещё плавает, полезнее уточнить её, чем выбирать предложение по самой короткой итоговой строке. План последовательных решений — в материале об этапах редизайна.
Источники и границы
- MDN: проверка данных формы — техническое различие частей интерфейса и проверки ввода.
- Состав готовых услуг KEIVO подтверждён владельцем: дизайн и вёрстка. Полная интеграция с произвольной системой не заявлена готовой услугой.
Разбивка оценки и вопросы к предложению — редакционный рабочий подход. Оценка конкретного проекта требует его материалов и согласованного состава работы.