
Платформа для соревнований по спортивному программированию: пользователи решают алгоритмические задачи на любом языке программирования, участвуют в командных и одиночных турнирах и создают собственные соревнования.
Особенность проекта — бриф состоял из функциональных требований без единого макета-референса: визуальную концепцию, структуру экранов и часть функциональности пришлось определять самостоятельно

Бриф без брифа
Заказчик — разработчик, который делал дипломный проект и хочет в перспективе развивать его как реальный сервис. Функциональные требования он сформулировал четко: пользователи решают задачи на любом языке программирования, сайт сразу проверяет решение, при повторной попытке после ошибки начисляется меньше баллов, предусмотрены командные соревнования, есть возможность как решать чужие задачи, так и создавать свои.
А вот с тем, как это должно выглядеть и как быть устроено по экранам — референсов не было вообще. Единственная отправная точка на визуал — фильм «Матрица». Задачи по структуре интерфейса, количеству экранов и сценариям взаимодействия заказчик не ставил — их нужно было определить самой, отталкиваясь только от списка функций

Задача без референса
Раз готового визуального направления не было, взяла за основу единственный ориентир заказчика — «Матрица» и перевела его в конкретный язык интерфейса: темная тема как основная, монохромный зеленый на черном, моноширинный шрифт, а служебные подписи разделов стилизованы под консоль («C:\SYSTEM_COMPETITIONS\ROOT-EXECUTE_PROTOCOL_V2.EXE»). Это не декоративный прием, а способ сразу считать тематику продукта — соревнования для разработчиков.
Аватар в профиле и названия команд по умолчанию («Навуходоносор», «Morpheus», «Neo», «Trinity») тоже отсылают к фильму — деталь, которая работает на цельность образа при регистрации команды.
Отдельно сделала светлую тему — те же экраны, но в light-палитре с сохранением зеленого акцента, для пользователей, которые не любят темный интерфейс или используют сайт при ярком освещении

UI-кит и компонентная система
Разработала UI-кит: поля форм и их состояния, кнопки (default / hover / disabled), карточки, выпадающие фильтры, чекбоксы, статус-теги с цветовым кодированием (например, «Прием заявок» зеленым, «Завершен» серым, ошибка — красным), строки таблиц, пагинация.
Для типографики сознательно смешала два слоя шрифтов: моноширинные шрифты для кода и основного текста (JetBrains Mono, IBM Plex Mono) — для читаемости и «программистского» ощущения, и пиксельные/ретро-игровые шрифты для акцентных заголовков (Press Start 2P, 8bitoperator JVE) — чтобы добавить характер терминала старой видеоигры, не жертвуя читаемостью основного контента.
Именно то, что карточки и фильтры были спроектированы как универсальный компонент UI-кита, а не под конкретный раздел, позволило быстро переиспользовать их между каталогом соревнований и тренировочными модулями — это была не случайная экономия времени, а результат того, что компонентная система строилась заранее

От списка функций к структуре
Первым делом разложила функциональность на сущности и их связи: соревнования (одиночные / командные), наборы задач (готовые от других пользователей / собственные), пользователь и его прогресс, тренировочные модули. Это дало карту разделов сайта: Главная, Соревнования, Тренировки, Новости, Профиль — и стало ответом на отсутствие брифа по структуре: вместо того чтобы ждать уточнений, предложила заказчику готовую информационную архитектуру на созвоне и дальше отталкивались от нее

Регистрация на соревнование
Ключевое требование заказчика — избежать отдельной страницы для регистрации на каждое соревнование, чтобы участие оформлялось максимально быстро. Решила это через карточку: вся необходимая информация (дата, дедлайн подачи заявки, уровень сложности, стек, требование к команде) уместилась в саму карточку в каталоге.
Для одиночного соревнования регистрация происходит по одному клику на кнопку в карточке — без перехода куда-либо. Для командного — по клику открывается модальное окно с полями команды (название, капитан, участники), но пользователь все равно не покидает страницу каталога. Уровень сложности и статус приема заявок вынесены как отдельный акцент на карточке — это то, по чему пользователь фильтрует соревнования в первую очередь

Тренировочные модули
Заказчик изначально не запрашивал ничего, кроме соревнований. На одном из созвонов предложила добавить тренировочные модули — блок, где пользователь может отрабатывать конкретный язык программирования и решать задачи из прошлых соревнований вне турнирного контекста. Логика предложения: без этого блока сайт был бы полезен пользователю только в дни соревнований, а все остальное время простаивал. Тренировки дают повод возвращаться на платформу регулярно и служат мягким онбордингом перед первым реальным соревнованием.
Реализовала тренировки на той же карточной системе и тех же фильтрах (стек, уровень, статус), что и каталог соревнований — вместо того чтобы придумывать отдельный паттерн, переиспользовала уже проверенный компонент. Для пройденных модулей статус кнопки меняется на «Пройден»

Создание своего соревнования
Создание соревнования — самая тяжелая по количеству полей задача в интерфейсе: нужно задать название, описание, сложность, формат, командное/одиночное участие (с условным полем «количество человек», которое появляется только если включено командное участие), приватность, даты регистрации и проведения, набор языков программирования и отдельно набор задач для этого соревнования.
Чтобы не заваливать пользователя одной длинной формой, разбила создание на три шага-вкладки: «Соревнование» (общие параметры) → «Наборы задач» → «Задачи». Каждый шаг логически независим: организатор может использовать уже готовый набор задач от других пользователей или создать свои с нуля, не блокируя заполнение остальных параметров соревнования


Что получилось в итоге
В результате получилась целостная платформа с понятной структурой разделов, переиспользуемой карточной системой для двух разных сущностей (соревнования и тренировки) и визуальным языком, который считывается с первого экрана

Что бы сделала иначе: проект не проходил пользовательское тестирование. Заказчик решил, что на этапе диплома это не требуется. Поэтому решения по структуре и флоу основаны на логическом разборе функциональных требований, а не на данных от пользователей. Если проект пойдёт дальше как реальный сервис, следующим шагом стоит проверить на пользователях именно сценарий создания своего соревнования — это самая сложная по количеству полей часть интерфейса, и здесь высок риск, что часть организаторов будет теряться на шаге с наборами задач