Путь к ЕГЭ — мобильное приложение для подготовки к экзамену по русскому

Спроектировал с нуля мобильное приложение для подготовки к ЕГЭ по русскому языку: разрозненные идеи клиента собрал в поэкранную карту, спроектировал по ней все сценарии и интерфейс обеих платформ и сверял реализацию с макетами на каждом этапе разработки. Опубликовано в Google Play и RuStore; 1000+ установок в RuStore.

Продуктовый дизайнер · январь–сентябрь 2024 · YŪGA VISION · Android / iOS / RuStore
4 тематических «мира»2 платформысобственная дизайн-система1000+ установок
COVER · Путь к ЕГЭ

Контекст и задача

«Путь к ЕГЭ» — мобильное приложение для подготовки к ЕГЭ по русскому языку. В основе — видеоразборы и шпаргалки от автора курса, репетитора с большим стажем. Приложение собирает их в понятную структуру и добавляет проверку знаний и игровой режим.

Аудитория — школьники, которые готовятся к экзамену. Устанавливают и сами ученики, и родители, учителя, репетиторы.

Клиент пришёл в студию YŪGA VISION с задачей «разработать приложение» и набором идей: видеоуроки, тесты, скачиваемые шпаргалки, концепция четырёх тематических «миров» и желание добавить режим, где пользователи соревнуются в знаниях. Часть видео уже была записана. Готового ТЗ не было — структуру продукта предстояло собрать с нуля.

Моя роль

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

Что делал:

  • интервью с основателем проекта и его помощником;
  • поэкранная карта приложения в FigJam — стала каркасом для обсуждений с разработкой и основой всего дизайна;
  • пользовательские сценарии и UI обеих платформ;
  • ревью реализации на каждом этапе разработки — сверка вёрстки и логики с макетами.

Все ключевые решения по флоу и интерфейсу — мои, в согласовании с клиентом и техническими ограничениями команды.

ЭКРАН 1 · Путь к ЕГЭ
ЭКРАН 2 · Путь к ЕГЭ

Ключевые решения

01

Карта продукта вместо брифа.

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

02

Структура «миры → уроки → проверка».

Контент уложил в четыре тематических мира — нормы, текст, пунктуация, орфография. Внутри мира — уроки, в каждом три способа работать с темой: видеоразбор, шпаргалка и тест. Порядок не навязан: можно сразу пройти тест, затем подтянуть теорию по шпаргалке и видео и перепровериться. Прогресс считается по миру в целом. Это сняло линейность «сначала посмотри всё, потом проверяйся» и дало пользователю самому выбирать маршрут.

03

Собрал дизайн-систему приложения.

Под кросс-платформенный UI завёл единую систему: цветовые токены с назначением (акцент, фоны, состояния ответов, текст, градиенты кнопок), типографику и библиотеку компонентов — инпуты, кнопки, карточки, прогресс-бары и круги, аватарки. Благодаря ей приложение выглядело одинаково на iOS и Android, а разработчикам не пришлось в сжатые сроки верстать две версии интерфейса — команда сосредоточилась на полировке функций единого интерфейса для обеих платформ.

04

Поединки: адаптировал проверенную механику, а не изобретал с нуля.

У клиента было желание «чтобы пользователи соревновались», но без чёткого видения. Я взял за референс знакомую механику викторины-поединка (приложение «Борьба умов»), разобрал её UX по шагам, зафиксировал пользовательский путь скриншотами и адаптировал под ЕГЭ: 7 вопросов, два варианта ответа, выбор тапом по карточке, без ввода текста. Это упростило и проектирование, и разработку, клиент утвердил режим с первого предложения, а команда клиента получила понятные рамки, под которые составлять вопросы. Режим живой: соперник — реальный пользователь, вставший в поиск в тот же момент. Асинхронного соперника обсуждали и отложили на поздние версии — по оценке разработчиков это требовало другой реализации и больше времени.

05

27 типов заданий — в четыре формата карточек.

Вместе с клиентом разобрали структуру экзамена: из 27 типов заданий в первую версию вошли 24 — исключили сочинение и два задания на соответствие: их механика потребовала бы отдельной сложной реализации. Оставшиеся уложил в четыре формата карточки: вопрос с инпутом; вопрос с чекбоксами; предложение с чекбоксами; скрываемый текст с чекбоксами или инпутом. Это резко сократило интерфейсные вариации — быстрее разработка, проще интерфейс; расширение форматов и возврат исключённых типов заложили в следующие версии.

06

Свёл регистрацию и вход в один экран.

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

ЭКРАН 1 · Путь к ЕГЭ
ЭКРАН 2 · Путь к ЕГЭ
ЭКРАН 3 · Путь к ЕГЭ

Результат

Приложение опубликовано в Google Play и RuStore; в RuStore — 1000+ установок. Дизайн кросс-платформенный, с учётом гайдлайнов iOS и Android.

iOS-релиз остановился на ревью App Store из-за оплаты полной версии для пользователей из РФ. Подготовил обходное решение через external purchase link, который Apple незадолго до этого разрешил для санкционных регионов, — две дополнительные страницы на сайте проекта и отдельный экран в приложении. Дальше всё упёрлось в эквайринг на стороне клиента; к этому моменту проект уже был передан его команде.

Из метрик мне были доступны только установки. В команде с аналитикой первым делом смотрел бы прохождение уроков внутри «миров» и возврат в поединки — две механики, ради которых приложение и собиралось.

Рефлексия

Две вещи сделал бы иначе. Первое — визуал «миров»: карточки генерировал в Midjourney начала 2024-го, и композиции вышли недостаточно согласованными между собой; сегодня собрал бы их консистентнее на более управляемых инструментах. Второе — ветку уроков и тестов проектировал последней и в сжатые сроки, на меньшем числе итераций; ей не хватило отдельного раунда на юзабилити и визуальную доводку.

Другие кейсы