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