Начните с решения, которое нужно принять
На консультацию удобно приходить с вопросом, на который пока нет уверенного ответа: переделывать сайт или исправлять отдельные страницы, выпускать приложение или начать с адаптивной версии, подключать новую систему или разобраться с текущим процессом. Цель встречи — прояснить ситуацию и выбрать разумный следующий шаг. Полное техническое задание для этого не требуется.
Сформулируйте ожидание одним предложением: «Хотим понять, почему обращения не доходят до сотрудников» или «Нужно определить, что проверять в первой версии приложения». Если вопросов много, выберите главный. Иначе разговор легко уйдёт в оформление экранов, когда препятствие находится в обработке заявок или составе продукта.
Опишите симптомы, не назначая решение заранее
Запишите, что происходит сейчас, кому это мешает и при каких условиях повторяется. «Нужен современный дизайн» мало рассказывает о проблеме. «На телефоне посетитель не видит условия доставки до оформления» уже позволяет обсудить конкретный сценарий. Предложенное вами решение тоже полезно, но его стоит отделить от наблюдения.
Для каждого симптома подготовьте короткую запись:
- что человек пытается сделать;
- какой результат ожидает;
- что происходит фактически;
- где это можно увидеть или воспроизвести;
- какие последствия известны, а какие только предполагаются.
Например, несколько жалоб на авторизацию — основание проверить вход, но ещё не доказательство необходимости заменить весь личный кабинет. Не называйте причиной то, что пока известно только со слов одного участника.
Соберите небольшой комплект материалов
Достаточно ссылки на действующий продукт, нескольких снимков проблемных экранов и описания процесса. Если есть макеты, предыдущая оценка, список доработок или аналитика, добавьте ссылки с пояснением, что именно нужно посмотреть. Отметьте актуальную версию: разные варианты одного документа без даты усложняют обсуждение.
Вместо архива всей переписки подготовьте несколько характерных примеров. Обезличьте клиентские обращения и уберите пароли, платёжные данные и закрытые сведения. Для демонстрации доступа используйте согласованный тестовый аккаунт с нужной ролью. Доступ к рабочей системе и возможность что-либо менять обсуждаются отдельно; для первой встречи часто достаточно совместного просмотра экрана.
Назовите ограничения до обсуждения функций
Сообщите, какие системы уже используются, что нельзя остановить и кто будет работать с результатом. Для сайта это могут быть каталог, CRM и редактор материалов. Для приложения — существующая серверная часть, способы входа и необходимые платформы. Если точный состав неизвестен, отметьте вопрос для проверки, вместо того чтобы предполагать готовность интеграции.
Укажите желаемую дату и причину, с которой она связана. Полезно также обозначить доступный бюджетный ориентир и способ согласования решения. Это помогает выбирать между проверкой гипотезы, ограниченной доработкой и отдельным этапом проектирования. Ориентир на встрече не заменяет согласованную оценку работ.
Пригласите людей, которые знают процесс
На разговоре полезны участник, принимающий решение, и человек, сталкивающийся с проблемой ежедневно. Их роли могут совпадать. Если тема касается заявок, объяснение сотрудника, который их обрабатывает, иногда важнее длинного перечня желаемых экранов. Если обсуждается приложение, нужен владелец основного пользовательского сценария.
Заранее договоритесь, кто покажет продукт и кто зафиксирует итог. Не обязательно приглашать всю команду: дополнительные участники нужны, когда без них нельзя ответить на существенный вопрос. Неизвестные детали можно вынести в список уточнений с ответственными.
Подготовьте вопросы о следующем шаге
Хорошие вопросы связывают рекомендацию с её основанием: «Что нужно проверить, прежде чем оценивать разработку?», «Можно ли проверить этот сценарий на прототипе?», «Какие сведения понадобятся для расчёта интеграции?». Попросите объяснить, что входит в предложенный этап и какой результат можно будет принять.
Для работающего сайта отдельно обсудите, можно ли устранить препятствие до большого редизайна. В материале о выборе между редизайном и доработкой разобраны признаки таких ситуаций. Для приложения полезно сопоставить идею с составом первой версии, сохранив неизвестные вопросы открытыми.
Зафиксируйте итог, который можно использовать
После встречи сохраните краткую запись: исходная задача, наблюдения, ограничения, рассмотренные варианты и выбранное действие. Отдельно перечислите то, что ещё требует проверки. Рекомендация «проверить передачу заявки» и подтверждённая ошибка передачи — разные результаты; смешивать их в итоговом документе не стоит.
Практический шаблон следующего шага: «Проверяем конкретный сценарий; получаем список подтверждённых препятствий; после этого выбираем объём доработки. Материалы предоставляет один участник, решение согласует другой». Добавьте ответственного и дату следующего контакта. Если следующий этап — оценка разработки, используйте структуру задания на сайт.
Выберите подходящий формат встречи
Для просмотра сайта, макетов и обсуждения функций обычно удобно начать онлайн. Выезд команды имеет смысл обсуждать, если важно увидеть рабочую среду или участие нескольких сотрудников на месте. Формат выбирают по задаче, а не по предполагаемой сложности будущего продукта.
В DDRW доступна консультация по цифровому продукту. Дату, время и место встречи согласуем после оформления заказа; работы по проекту оцениваются отдельно. По итогам обсуждения можно перейти к оценке сайта для бизнеса или мобильного приложения, если именно этот шаг соответствует вашей ситуации.
