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