качественные исследования
Ожидание и реальность
Participatory Design, глубинные интервью, проверка концепции
дисклеймер
Все участники и гипотезы - это метафора
Реальное исследование под NDA, любые совпадения случайны.
В этом кейсе я расскажу о старте разработки крупного блока в условиях поступающих извне требований, которые предположительно усложняли пользовательский опыт.
В этом кейсе я расскажу о старте разработки крупного блока в условиях поступающих извне требований, которые предположительно усложняли пользовательский опыт.
Допустим, реализован toDo List
Он в минимуме выполняет свою задачу, но есть сиходные требования для сдачи.
Нужно его доработать так, чтобы :
- родители могли оставлять для своих детей списки дел и записки
- дети могли их компоновать на своих устройствах как им удобно
- интерфейс мог поддерживать все обновления от родителей, но так, чтобы не пострадали личные настройки детей (если они что-то перекомпоновали).
Родители, которые озвучили требования, так же сообщили, что примерно 10% детей реально заинтересованы что-то компоновать, но для них это очень важно: это их мотивирует на будущие достижения. Остальные дети предпочитают делать минимум дел, которые видно сразу. То есть для 90% детей - что не вижу — то не делаю.
Нужно его доработать так, чтобы :
- родители могли оставлять для своих детей списки дел и записки
- дети могли их компоновать на своих устройствах как им удобно
- интерфейс мог поддерживать все обновления от родителей, но так, чтобы не пострадали личные настройки детей (если они что-то перекомпоновали).
Родители, которые озвучили требования, так же сообщили, что примерно 10% детей реально заинтересованы что-то компоновать, но для них это очень важно: это их мотивирует на будущие достижения. Остальные дети предпочитают делать минимум дел, которые видно сразу. То есть для 90% детей - что не вижу — то не делаю.
После нескольких мозговых штурмов в команде появилась первичная концепция: нумеровать блоки со списками и разработать несколько шаблонов расположения этих блоков. За счет наследования нумерации, можно менять блоки местами, не теряя их содержимое.
Таким образом закрывалось требование по гибкости компановки, но с возможностью отображать обновления от родителей на перекомпанованных версиях списков у детей.
Также была заложена возможность разработать дополнительно конфигуратор шаблонов в будущем, если потребуется.
Таким образом закрывалось требование по гибкости компановки, но с возможностью отображать обновления от родителей на перекомпанованных версиях списков у детей.
Также была заложена возможность разработать дополнительно конфигуратор шаблонов в будущем, если потребуется.
Здесь у системного архитектора появилось техническое требование по реализации, что усложнило восприятие концепции.
Предлагалось внутри блоков располагать не сразу дела, а как бы списки дел, объединенные одним тэгом.
Дела объединяются в список -> список имеет тэг -> один или несколько тэгов попадают в один блок.
В каждом шаблоне строго прописано, какой блок содержит какие тэги.
И тогда в случае, если ребенок выбрал конфигурацию, в которой блоков меньше, чем по дефолту у родителя, дела из блока, который выпал, переедут в другие блоки в соответсвии с наследованием тэгов.
Кроме того, если родитель добавит новый список дел, то он отобразится у ребенка в том блоке, который содержит этот тэг.
Предлагалось внутри блоков располагать не сразу дела, а как бы списки дел, объединенные одним тэгом.
Дела объединяются в список -> список имеет тэг -> один или несколько тэгов попадают в один блок.
В каждом шаблоне строго прописано, какой блок содержит какие тэги.
И тогда в случае, если ребенок выбрал конфигурацию, в которой блоков меньше, чем по дефолту у родителя, дела из блока, который выпал, переедут в другие блоки в соответсвии с наследованием тэгов.
Кроме того, если родитель добавит новый список дел, то он отобразится у ребенка в том блоке, который содержит этот тэг.
Концепция звучала труднообъяснимой из-за многоуровневой вложенности и нуждалась в проверке.
Фокус-группа
Фокус-группа
На интервью родители не очень поняли, зачем тэги: они никогда не держали в голове разбиение дел по тэгам при планировании дня. Необходимость тэгов фокус-группе была непонятна.
Глубинные интервью
Глубинные интервью
Фокус-группа зачастую дает необъективный результат, тем более что концепция объяснялась на схемах. Проблема непонимания объективно присутствовала и подтвердилась на глубинных интервью, но так же требовалось проверить ее в использовании: на самом деле новый подход мог оказаться удобным, просто к нему не привыкли.
Participatory design
Participatory design
Были приглашены родители с реальными списками дел и подготовлен сценарий, которой соответствовал выдвинутой концепции.
Обработка результатов
Обработка результатов
Проявились полезные инсайты для дальнейшего проектирования. Но результат проверки концепции оказался противоречащим исходным данным.
проверка сценария
Participatory design
- Создание глобального списка всех дел родителяКаждый родитель принес реальные списки дел для своих детей. Принимали участие как многодетные семьи, так и с одним ребенком.01
- Распределение дел по спискамРодители подготовились заранее и уже принесли подготовленные списки. У каждого их было несколько: кто-то делил по детям, кто-то по времени дня, кто-то по важности.02
- Назначение спискам тэговТэги были предложены идейным основателем концепции. На основе своего обширного родительского опыта он выделил следующее:
— важное
— день
— вечер
— дополнительное03
Интуитивно хотелось назначать тэги не целым спискам, отдельным делам. Но мы не стали отвлекаться от заложенного сценария и прошли его по плану.
Сначала каждый список дел был вырезан из бумаги в одном экземпляре.
Мы распределили их ряды по тэгам. Сразу увидели перевес по распределению: дневные дела требуют больше места.
Затем мы переложили списки на конкретных детей:
размножили повторяющиеся списки и дела и разложили в матрицу:
Мы распределили их ряды по тэгам. Сразу увидели перевес по распределению: дневные дела требуют больше места.
Затем мы переложили списки на конкретных детей:
размножили повторяющиеся списки и дела и разложили в матрицу:
- Просмотр дел ребенкаКонфигурацию дел одного ребенка эмулировали так: брали все списки из столбца по ребенку и пытались наложить наиболее удобный шаблон на распределение по тэгам.04
Выявили:
Списки дополнительных и вечерних у всех очень короткие
Список важного всегда должен быть один в своем блоке, чтобы ничего важного не уехало под скролл
Важный список хочется расположить слева и выделить высоту, достаточную для всех возможных дел
Сделать меньше блоков, чем 4, не получилось, и тэги приравнялись блокам.
Списки дополнительных и вечерних у всех очень короткие
Список важного всегда должен быть один в своем блоке, чтобы ничего важного не уехало под скролл
Важный список хочется расположить слева и выделить высоту, достаточную для всех возможных дел
Сделать меньше блоков, чем 4, не получилось, и тэги приравнялись блокам.
итак,
Результат
Полученные toDo листы детей перенесли в макеты и увидели, что они нуждались в "тюнинге" и сразу не были удобными. Что-то уплывало в невидимую зону под скролл, в то время как другое было слишком пустым.
Выходило так, что либо родителю нужно "подтягивать" визуал (тогда зачем были лишние действия с тэгами?), либо оставлять это на усмотрение детей. Но изначально было оговорено, что интерес к конфигурированию листа есть только у 10% детей, а остальные могут проигнорировать то, что не видно сразу. Это привело к тому, что родители интуитивно подменяли тэги, зная как это скажется на переполнении блоков потом. Концепция противоречит либо исходным данным либо сама себе:
- либо заявленные 90% детей получат неудобные списки и будут игнорировать то, что вне фокуса
- либо родители будут подменять семантику тэгов, держа в голове то, как работает приложение
В реальном кейсе (которое под NDA) у админов не было бы выбора, и они не покинули бы продукт. Но время на настройку и отладку, а так же жалобы от "детей" могут существенно ударить по скорости отладки проектов и негативно сказаться на сдаче проектов заказчикам.
В этой разработке я выполняла только исследовательскую часть задачи. Все наработки я задокументировала и передала коллеге-дизайнеру, приложив свое UX-видение, минимизирующее риски, для случая, если владельцы продукта будут настаивать на реализации предложенного концепта.
Выходило так, что либо родителю нужно "подтягивать" визуал (тогда зачем были лишние действия с тэгами?), либо оставлять это на усмотрение детей. Но изначально было оговорено, что интерес к конфигурированию листа есть только у 10% детей, а остальные могут проигнорировать то, что не видно сразу. Это привело к тому, что родители интуитивно подменяли тэги, зная как это скажется на переполнении блоков потом. Концепция противоречит либо исходным данным либо сама себе:
- либо заявленные 90% детей получат неудобные списки и будут игнорировать то, что вне фокуса
- либо родители будут подменять семантику тэгов, держа в голове то, как работает приложение
В реальном кейсе (которое под NDA) у админов не было бы выбора, и они не покинули бы продукт. Но время на настройку и отладку, а так же жалобы от "детей" могут существенно ударить по скорости отладки проектов и негативно сказаться на сдаче проектов заказчикам.
В этой разработке я выполняла только исследовательскую часть задачи. Все наработки я задокументировала и передала коллеге-дизайнеру, приложив свое UX-видение, минимизирующее риски, для случая, если владельцы продукта будут настаивать на реализации предложенного концепта.