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