Интересная статья о ментальных моделях (ММ) для дизайнеров.
Я сперва подумал, что она как раз про мои любимые ММ, которые являют собой сторифреймы в персонах, но нет.
В статье речь ведётся скорее о методах мышления, то есть как следует думать и работать. Вот самые интересные из них:
1) Первопричины. Метод состоит в том, чтобы не пытаться проглотить кусок, который вам не по зубам. Вместо этого дифференцируйте проблему на мелкие первопричины и подбирайте решение к ним, после чего, соединяйте решения вместе. Таким образом у нас получится хорошо продуманная система и мы ничего не упустим. Например, проблема качественного роста вас как специалиста — это комплексная проблема, которая включает в себя вашу оценку, построение плана закрытия пробелов, поиск необходимой и релевантной информации и т.д. Если просто начать строить решение, боюсь вы никуда не продвинетесь. Но если рассмотреть каждый кусочек пазла отдельно, то решения для них найдутся довольно быстро: для оценки будем использовать гугллвый фреймворк, для оценки сходим на пару собесов и получим обратную связь, и т.д. Останется только собрать их воедино.
2) Инверсия. Мы часто концентрируемся на поиске идеального решения, однако порой это слишком тяжело даётся. Чтобы облегчить себе «роды» решения, можно воспользоваться инверсией: представить не самое хорошее решение, а наоборот, плохое. А после просто спросить, как нам этого избежать? Очень напоминает метод решения задач «от обратного», не правда-ли? Например, все таже проблема становления вас как прекрасного специалиста может впасть в ступор на вопросе «А кто такой этот прекрасный специалист?». Однако стоит вам задать вопрос, как «Кем он не является?», как сразу повалят признаки: звёздная болезнь, отсутствие опыта, теоретический дизайн, затворничество и т.д. Останется только придумать, как этого избежать и вуаля.
3) Лестница абстракции. Этот метод позволяет выйти из тупиковой ситуации, если задача кажется неразрешимой. В таком случае, нам стоит переместиться на уровень выше (построить надсистему по ТРИЗ) и рассмотреть проблему в ней. А делается это при помощи мозгов и качественных вопросов (почему, зачем, как, чем... и т.д.) Например, перед нами стоит задача создать ручку, которая будет писать в условиях невесомости. И это довольно сложная задача. Но если мы выйдем в надсистему «фиксирование информации в условиях невесомости», то на столе появляются и другие опции, типа «цифровой дисплей» или «простой карандаш». Конечно, каждый из них будет иметь свои недостатки, но и положительные моменты можно будет перенять.
Также в статье есть модели для принятия решений и коммуникации, но они примитивны, так что не попали в топ.
Наталья Стурза, автор канала @UX_sturzaman, рассказала, когда продуктам полезны UX-исследования:
1. Проверить идею, не создавая продукта. Хотели запустить маркетплейс для пенсионеров. Исследование показало, что люди старше 60 лет спокойно пользуются обычными интернет-магазинами.
2. Исправить запустившийся, но не сработавший продукт. Сервис показывал карту спортивных мероприятий, но продвигался на аудиторию с низким доходом, продаж не было. Составили портреты потенциальных пользователей и провели с ними кастдев. В итоге сосредоточились на сегменте спортивных путешественников и правильно донесли до них ценность сервиса.
3. Улучшить то, что работает. Клиенты банка заполняли юридически значимое поле «Назначение платежа» всякой белибердой. Юзабилити-тесты показали, что люди считают поле второстепенным и заполняют только затем, чтобы кнопка платежа активировалась. В итоге в плейсхолдере поля показали пример, и таких ситуаций стало на 30% меньше.
4. Сравнить между собой конкурирующие продукты или отдельные фичи.
5. Понять, сколько потенциальные клиенты готовы платить.
6. Найти ошибку в интерфейсе.
Исследования не пригодятся:
1. Сервисам про фан вроде MSQRD и сервисам-витаминкам вроде приложений для медитации. У них сложно выделить пользовательскую потребность или проблему.
2. Любым проектам в ситуации «Мы хотим, чтобы вы пришли и сказали, как решить наши проблемы». В этом случае лучше обратиться к консалтерам.
https://vc.ru/design/86942
Рефлексия
«Военачальник, который выигрывает сражения, прежде чем сражаться, много размышляет в своем храме»
© Сунь-Цзы, Искусство войны
Чем выше руководитель по уровню развития, тем больше времени он выделяет на размышления о развитии своего направления.
Кому и зачем нужна рефлексия?
Менеджер, который все время в огне и вечно занят, находится на соответствующей ступени своего развития.
Часто бывает так, что специалист еще вчера делал работу руками. Сегодня он пытается стать руководителем, продолжая работать руками, одновременно являясь наставником и делая все подряд.
Постепенно он закапывается в рутине вместо того, чтобы руководить. В этот момент его коллеги видят, как он разрывается, начинают его жалеть и одновременно подсознательно осуждать руководство, мол, это они его изматывают. В этом случае уместно сказать, что молодой руководитель слишком много на себя взял.
Он еще не понимает, что закапывание в рутине и работа сутками напролет — это не его заслуга, а банальное неумение расставлять приоритеты, неумение руководить. Можем сказать, что такой человек некомпетентен, как руководитель.
Ситуация может измениться, если он перестанет делать все за всех, и начнет делегировать, оставляя время на рефлексию. Руководитель не может считаться таковым, если у него нет времени на размышления об улучшении финансовых результатов своего направления.
О чем думать?
Ключевым моментом в такого рода рефлексии является конечная точка этих размышлений. Развитие должно прогнозируемо и понятно для самого руководителя выражаться в улучшении финансовых показателей в долгосрочной перспективе. Важно, чтобы руководитель досконально понимал влияние его мыслей и планов на выручку и прибыль.
— Мы будем делать более лучше и нам будут больше платить, — это рассуждение руководителя, которого не волнует прибыль, у него другие интересы и фокус внимания. Кому-то важно сделать красивый кейс для своего портфолио, кто-то хочет быть авторитетом для своих подчиненных, кто-то хочет «пилить» продукт / модуль своей командой, который обязательно когда-то пригодится, кто-то хочет осваивать новые технологии и внедрять их в своем отделе, потому что мы уже отстали от последних тенденций сферы или по другой причине, кто-то сфокусирован на обучении и из этого черпает вдохновение и т. д.
Все это замечательно и важно, но это процесс, а не результат. С таким подходом руководитель не может занимать высокий пост в компании. У руля должны быть люди, которые думают о главном — выручке и прибыли. Эти менеджеры понимают всю цепочку взаимосвязи планов и финансовых результатов.
Юлия Кожухова написала о разных инструментах, с помощью которых можно оформить результаты исследований.
Ещё перед началом исследования важно понять, что вы будете делать с результатами. От этого зависит, какие инструменты выбрать для составления отчёта, и сколько на него тратить времени.
Выбор зависит:
— От запроса команды. Какую потребность исследование должно закрыть?
— Отношения к исследованиям. Надо ли убедить команду в надёжности выводов?
— Особенностей продукта. Это прототип или готовый продукт?
— Связи исследователя с командой. Продолжите ли вы работать вместе после окончания исследования?
Юлия рассмотрела плюсы и минусы 4 основных инструментов и сделала выводы, для каких исследований они подходят:
1. PowerPoint. Подходит для результатов интервью, фокус-групп, юзабилити-тестов, а также если надо показать много скриншотов. Скорее подходит для крупных проектов, когда есть время на оформление слайдов, которые увидит много людей.
2. Miro. Можно представлять результаты глубинных интервью, фокус-групп. Подходит для проектов, где надо строить большие схемы, и когда необходимы частые правки и дополнения.
3. Excel или Google Таблицы. Подходит для любых количественных данных. На одном листе могут быть исходные данные, а на других — результат их обработки. Можно делиться с командой промежуточными результатами с дополнительными гипотезами и инсайтами.
4. Word или Google Документы. Подходит, когда не нужны рекомендации по изменениям, а нужны только факты по результатам исследования (например, перечень проблем, с которыми столкнулись пользователи). Отчёт в таком формате легко оформить.
Ура! Переходим к поиску решения!
На этом долгий процесс описания нашего исследования закончен, самое время перейти к описанию решения, к которому мы пришли.
Но сначала пару слов о проведенном исследовании.
Я так подробно описывал процесс работы полевиков, потому что в этом и есть вся суть блока исследования — как можно глубже прокопать проблематику, максимально вникнуть в боль наших пользователей, понять в чем причина их бед.
И если делать определённый вывод, то можно сказать, что полевиков в целом все устраивает. Да, им иногда не очень удобно переключаться между бумагой и телефоном, в некоторых методах много мороки с обработкой данных — но при этом, их работа никогда не превращается в рутину, потому что люди приходят на проект и не занимаются этой работой на постоянной основе: если ты пришёл на месяц, то тебе, в целом, все равно, что за инструменты у тебя в руках, главное, что работа сделана, деньги получены и даже удовлетворение от того, что в результате твоей работы мир стал чуточку лучше, присутствует.
Совсем другая ситуация у методологов, которые постоянно озабочены тем, как оптимизировать процесс, потому что для них это каждодневный труд, рутина в которую они погружены с головой. Многие городские исследователи искренне увеличены своей работой, и буквально живут тем, как сделать процесс круче. Именно таким образом этот проект и попал к нам в руки — им не все равно.
На каждом проекте методологи испытывают боль от того, что полевые исследования проходят по тем же технологиям, что и двадцать лет назад.
Если говорить предметно, то самая неоптимизированная часть всей работы в полях — это массовый опрос с картой. На выходе исследователи получают кипу бумажных карт, каждую из которой необходимо обработать вручную. На подсчетах потоков исследователям приходит таблица в электронном виде, но при сборе информации полевики вынуждены держать в руках несколько инструментов и как-то успевать следить за потоками.
На наблюдениях, казалось бы, методологи получают готовый проект, который сразу можно анализировать, но сам процесс сбора информации (3 часа в полях) и дальнейшая её обработка (2 часа за компом) занимает немало времени у полевиков, при том, что они делают, в целом, бессмысленную работу: переименовывают каждую фотографию определенным образом, вставляют её в проект, который воссоздают по своим бумажным записям.
И если говорить про решение, то нам предстояло понять, возможно ли перевести эти методы в электронный вид, а если возможно, то в какой формат? Приложение, десктоп, веб сервис, а может проблема вообще не в сборе данных и её нужно решать на уровень выше? Или уже существуют технологии, которые позволят вовсе отказаться от полевиков?
Необратимые действия
Есть действия, выполнение которых необратимо. Ну например,
- отправка e-mail, СМС и прочего;
- удаление чата;
- удаление профиля и т.п.
Обычно перед таким действием система спрашивает: Вы уверены?
Но люди не читают, не думают наперёд, торопятся и всё равно делают необратимое действие, а потом ищут способ восстановить.
На одном b2b проекте представитель заказчика просил добавить в систему двойной вопрос на удаление:
- Вы уверены?
<Да>
- Вы точно уверены?
Мы не сделали, конечно. Добавили вместо этого для админа возможность восстанавливать удалённые записи, чтобы он это не через поддержку делал, а сам.
Но есть действия, которые пользователь выполняет часто и "задалбывать" его вопросами про уверенность — лишний шаг.
Приличные продукты для таких необратимых действий делают возможность оперативной отмены по горячим следам.
Например, при отправке письма в gmail можно отменить отправку по-быстрому (временем отмены можно управлять).
Или при удалении чата в Телеге можно отменить удаление в течение 5 секунд.
Так вот, в gmail возможность отмены отправки работает в стрессовом для пользователя режиме: если ты хочешь отменить, то тянешь курсор к этой плашке в режиме ракеты, боясь опоздать.
А в телеге работает приятно — видно таймер и ты понимаешь, сколько осталось времени для отмены.
А выводы по необратимым действиям такие:
1. Если действие можно сделать обратимым — сделайте его таким. Особенно полезно в b2b-проектах, когда случайное удаление записи может приводить к тому, что люди готовы бэкап развернуть лишь бы восстановить.
2. Если действие необратимо и вы решили спрашивать подтверждение — спрашивайте максимально чётко с донесением последствий действий. У меня есть отдельная мини-заметка (https://telegra.ph/UX-neobratimyh-processov--pro-udalenie-04-17) про это.
3. Если делаете возможность отмены необратимого действия — покажите пользователю, сколько у него есть времени для отмены.