Путь к ЕГЭ — мобильное приложение для подготовки к экзамену по русскому
Собрал продукт с нуля: разрозненные идеи клиента свёл в поэкранную карту, по ней спроектировал сценарии и интерфейс обеих платформ, реализацию сверял с макетами на каждом этапе разработки. Опубликовано в Google Play и RuStore.
Контекст и задача
«Путь к ЕГЭ» — мобильное приложение для подготовки к ЕГЭ по русскому языку. В основе — видеоразборы и шпаргалки от автора курса, репетитора с большим стажем. Приложение собирает их в понятную структуру и добавляет проверку знаний и игровой режим.
Аудитория — школьники, которые готовятся к экзамену. Устанавливают и сами ученики, и родители, учителя, репетиторы.
Клиент пришёл в студию YŪGA VISION с задачей «разработать приложение» и набором идей: видеоуроки, тесты, скачиваемые шпаргалки, концепция четырёх тематических «миров» и желание добавить режим, где пользователи соревнуются в знаниях. Часть видео уже была записана. Готового ТЗ не было — структуру продукта предстояло собрать с нуля.
Моя роль
Единственный дизайнер проекта: отвечал и за интерфейс, и за продуктовую логику приложения. Команда — четыре человека: я, бэкенд-разработчик и двое фронтендеров, с которыми работал в плотной связке. Менеджеры вели организационную часть — созвоны, протоколы, координацию с клиентом.
Что делал:
- интервью с основателем проекта и его помощником;
- поэкранная карта приложения в FigJam — стала каркасом для обсуждений с разработкой и основой всего дизайна;
- пользовательские сценарии и UI обеих платформ;
- ревью реализации на каждом этапе разработки — сверка вёрстки и логики с макетами.
Все ключевые решения по флоу и интерфейсу — мои, в согласовании с клиентом и техническими ограничениями команды.
Ключевые решения
Карта продукта вместо брифа.
Готового ТЗ не было — клиент описывал продукт словами. Параллельно с интервью я фиксировал его в поэкранную карту в FigJam. Менеджер собирал текстовое ТЗ для разработки, а карта стала визуальным каркасом: по ней мы обсуждали технические решения с разработчиками, и из неё вырос весь дальнейший дизайн.
Структура «миры → уроки → проверка».
Контент уложил в четыре тематических мира — нормы, текст, пунктуация, орфография. Внутри мира — уроки, в каждом три способа работать с темой: видеоразбор, шпаргалка и тест. Порядок не навязан: можно сразу пройти тест, затем подтянуть теорию по шпаргалке и видео и перепровериться. Прогресс считается по миру в целом. Это сняло линейность «сначала посмотри всё, потом проверяйся» и дало пользователю самому выбирать маршрут.
Собрал дизайн-систему приложения.
Под кросс-платформенный UI завёл единую систему: цветовые токены с назначением (акцент, фоны, состояния ответов, текст, градиенты кнопок), типографику и библиотеку компонентов — инпуты, кнопки, карточки, прогресс-бары и круги, аватарки. Благодаря ей приложение выглядело одинаково на iOS и Android, а разработчикам не пришлось в сжатые сроки верстать две версии интерфейса — команда сосредоточилась на полировке функций единого интерфейса для обеих платформ.
Поединки: адаптировал проверенную механику, а не изобретал с нуля.
У клиента было желание «чтобы пользователи соревновались», но без чёткого видения. Я взял за референс знакомую механику викторины-поединка (приложение «Борьба умов»), разобрал её UX по шагам, зафиксировал пользовательский путь скриншотами и адаптировал под ЕГЭ: 7 вопросов, два варианта ответа, выбор тапом по карточке, без ввода текста. Это упростило и проектирование, и разработку, клиент утвердил режим с первого предложения, а команда клиента получила понятные рамки, под которые составлять вопросы. Режим живой: соперник — реальный пользователь, вставший в поиск в тот же момент. Асинхронного соперника обсуждали и отложили на поздние версии — по оценке разработчиков это требовало другой реализации и больше времени.
27 типов заданий — в четыре формата карточек.
Вместе с клиентом разобрали структуру экзамена: из 27 типов заданий в первую версию вошли 24 — исключили сочинение и два задания на соответствие: их механика потребовала бы отдельной сложной реализации. Оставшиеся уложил в четыре формата карточки: вопрос с инпутом; вопрос с чекбоксами; предложение с чекбоксами; скрываемый текст с чекбоксами или инпутом. Это резко сократило интерфейсные вариации — быстрее разработка, проще интерфейс; расширение форматов и возврат исключённых типов заложили в следующие версии.
Свёл регистрацию и вход в один экран.
Сначала развёл их на две ветки. На обсуждении с бэкендером и фронтендером проверили гипотезу: можно ли определять нового и существующего пользователя одной проверкой номера в базе. Подтвердили — и я сразу перепроектировал вход в единый флоу. Меньше работы фронтенду, целостнее путь для пользователя.
Результат
Приложение опубликовано в Google Play и RuStore; в RuStore — 1000+ установок. Дизайн кросс-платформенный, с учётом гайдлайнов iOS и Android.
iOS-релиз остановился на ревью App Store из-за оплаты полной версии для пользователей из РФ. Подготовил обходное решение через external purchase link, который Apple незадолго до этого разрешил для санкционных регионов, — две дополнительные страницы на сайте проекта и отдельный экран в приложении. Дальше всё упёрлось в эквайринг на стороне клиента; к этому моменту проект уже был передан его команде.
Из метрик мне были доступны только установки. В команде с аналитикой первым делом смотрел бы прохождение уроков внутри «миров» и возврат в поединки — две механики, ради которых приложение и собиралось.
Рефлексия
Две вещи сделал бы иначе. Первое — визуал «миров»: карточки генерировал в Midjourney начала 2024-го, и композиции вышли недостаточно согласованными между собой; сегодня собрал бы их консистентнее на более управляемых инструментах. Второе — ветку уроков и тестов проектировал последней и в сжатые сроки, на меньшем числе итераций; ей не хватило отдельного раунда на юзабилити и визуальную доводку.