“Жизнь без розовых пони”: как мы делали дизайн для дистанционной системы обучения

Как бы хотелось, чтобы все было, как в идеальном мире: заказчик подробнейше рассказывает про проект, предоставляет полный карт-бланш, расписывает все нюансы работы будущей системы, а вы рекомендуете, что и как будет лучше сделать, согласовываете и круто решаете бизнес-задачу. Но у нас не идеальный мир с розовыми пони, а жиза.

Привет! На связи Sheverev и это вторая часть статьи по работе над системой дистанционного обучения.

Запрос “сделайте” не опишет вам всех плюшек и бессонных ночей. Это довольно жесткое ограничение по срокам на проектирование, сбор данных, а также исследования и прочие умные вещи. Ну и, конечно, полный дизайн всего этого. На все про все — три месяца (на секунду забегая в будущее — вышло 486 макетов вместе с адаптивом!).

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

Сложность №1: заказчик уже использовал в работе чудесное (тут должны были быть маты) творение айти-сектора под названием Moodle (да, по названию уже есть намеки на то, что с ним будут проблемы).

В общем, для того, чтобы понять, как устроена работа онлайн университета, нам пришлось погрузиться в пучины безумия Moodle. Сказать, что система, построенная на базе Moodle, была устаревшая и неудобная — сделать большой комплимент. Устаревший уже как лет 10 дизайн, полное отсутствие внятного UX подхода при проектировании... Но это все цветочки: все усугубляла запутанная структура, дублирование функционала, 50% которого не понимали ни мы, ни заказчики, которые, к слову, уже больше года работали в системе.

Сложность №2 или вишенка на торте: до этого проекта мы многое не понимали в организации внутреннего процесса онлайн-обучения. Странные и допсессии, непрозрачная система блокировки и отчисления студентов, монструозная система групп, подгрупп, отделений и еще много всего подобного. В общем, начало обещало быть очень увлекательным.

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

1. Проводить с заказчиком столько встреч, сколько нужно для обеих сторон: так мы разобрались со всей этой непонятной котовасией онлайн-обучения. Иногда казалось, что мы задаем одни и те же (возможно) глупые вопросы. Но в конце концов это дало свои плоды, и скоро мы уже четко понимали, кто чем занимается и за что ответственен в университете.

2. Собрать все вводные данные, какие можете. Тут все по классике: собрали все информацию по ЦА, проанализировали около 30 прямых и косвенных конкурентов, отобрали из них около 10 по-настоящему релевантных. Составили mindmap текущей системы, чтобы выявить ее слабые стороны и составить в будущем свой идеальный майнд-мэп с блэк джеком и… ну вы поняли.

3. Подготовить качественные исследования. Первым делом мы подготовили и согласовали группы респондентов, разделенных на “методистов”, “преподавателей” и “студентов”.

Далее составили опросники, релевантные для каждой из групп. В целом, все прошло гладко: мы получили тонны информации о нашей ЦА, ее работе в системе, образе мышления и прочее. Но основная неудача была в том, что мы получили не так много инсайтов, которые в будущем мы могли бы использовать для формирования гипотез по улучшению будущей платформы.

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

В общем, это вывод в том, что надо четко ставить цели при проведениях интервью, то есть “что мы хотим получить в итоге”: познакомиться с ЦА и узнать о точках взаимодействиях с продуктом или же мы хотим протестировать и найти какие-то решения, а также подтвердить или опровергнуть гипотезы.

4. Подготовить функциональные требования. Функциональные требования довольно обширная тема и на каждом из проектов их объем и разнообразие может меняться. Более подробно можно почитать в этой статье, там наш аналитик вещает обо всем этом интересно и наглядно.

5. Подготовка прототипов. Для нас и заказчика крайне важным было визуализировать будущую структуру и функционал новой платформы.На проектирование основных сценариев и подготовку прототипов ушло пара недель. Были жаркие обсуждения: методисты со стороны заказчика постоянно пытались “впихнуть невпихуемое” и добавить еще +100500 функционала, классных и не очень идей.

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

На удивление, дальше все пошло как по маслу.

Разработали стиль графики и визуального оформления, выбрали сетку, шрифты, иконки и цвета. Интерфейс получился лаконичным и понятным, что в дальнейшем не раз было подтверждено методистами и студентами.

Полностью спроектировали и задизайнили с нуля новый интерфейс работы с группами студентов.

Теперь вся важная информация находится на одном экране: оценки студентов с разделение по семестрам, возможность группового редактирования и многое другое.

Сделали новый интерфейс онлайн-мероприятий.

Студенты и преподаватели видят все ближайшие активности, по окончании мероприятия можно скачать его запись.

Переосмысли конструктор дисциплин.

Раньше дисциплины создавались посредством визуального редактора, все было свалено в кучу, из-за чего методисты тратили много времени на создание и редактирование дисциплин.

Сейчас конструктор разделен на логические блоки, структура максимально гибкая, разделы можно менять местами, добавлять функциональные блоки (лекции, информационные страницы, презентации, видеолекции) и многое другое.

Гибкий конструктор лекций.

Раньше методисты жаловались на нелогичный процесс создания лекций, теперь все максимально просто.

У заказчика была довольно ветвистая структура лекционных блоков. Пришлось хорошенько подумать над тем, как ее логично уместить в конструкторе. В конечном итоге мы пришли к следующей схеме: в конструкторе лекций создаются темы, в темы добавляются лекции, а уже лекции наполняются конспектами по главам в отдельном окне.

А вот еще некоторые страницы системы:

Также мы подготовили адаптивы, так что каждый студент/преподаватель/методист может воспользоваться сайтом так, как ему будет удобно.

Чтобы сильно не растягивать статью, мы упомянули лишь малую часть задач, но, поверьте, было еще много интересного в процессе.

В течение месяца мы задизайнили все основные макеты. Перед тем, как окончательно отдать весь дизайн разработчикам, было принято волевое решение провести небольшое тестирование hi-fi макетов на реальных пользователях (да, понимаю, что это надо было делать пораньше).

Реализовано это было простым и незамысловатым образом, с помощью интерактивных прототипов в Figma. Мы связали пару сотен макетов и составили пользовательские задачи, которые должны были выполнять пользователи рамках тестирования. Помолившись и перекрестившись (опять помедитировав на рассвет, а потом и на закат), отправили нашу Настеньку-аналитика в славный рабочий путь.

Вернувшись через пару дней Настя поведала, что от пользователя не так то просто добиться выполнения простых задач. Но в целом, супер-критичных ошибок при проектировании дизайна допущено не было, кое-что мы сразу поправили, часть взяли на карандаш. Остальное пообещали себе поправить в следующих релизах (что и делаем, продолжаем и будем).

Дальше было взаимодействие с фронтами и бэками, обычные жалобы, что местами можно было сделать функционал и попроще, что мы не ищем легких путей и все в таком духе. О том, что было на этапе разработки подробно и умно написал наш CTO Александр в статье “За 5 месяцев до дедлайна: как мы успели сделать систему онлайн-обучения к 1 сентября”.