5Д — Десять дельных дел для дизайнера

designsniper 5Д — Десять дельных дел для дизайнера

◼️ Пересмотрите фильмы: «Бархатная бензопила» (2019 год), «Брачная история» (2019 год), «Большой куш» (2000 год), «Бёрдмэн» (2014 год), «Борьба с моей семьей» (2019 год) найдите в этих историях, картинах, эстетике и драме общие черты, общие закономерности, общие метафоры и символы или похожих героев. Выведь заметили, что все названия на общую для всех букву, может есть еще общее?

◼️ Перерисуйте десяток известных картин так, чтобы возник вид на сюжет картины в проекции сверху, как план изображения, как «карта картины», это помогает вашему восприятию активней использовать пространственное мышление и «крутить изображение» в воображении. Полезный навык.

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

◼️ Поиграть в Counter Strike так, чтобы не стрелять в противника, а отвлекать его от стрельбы по вашим коллегам по команде разным странным поведением и созданием отвлекающих маневров или используя только флэшбэнги «ослеплять» и тем самым отвлекать от действий коллег.

◼️ Посмотреть сериал в обратном порядке. От последней серии сезона к первой и выстроить свой собственный нарратив из такого подхода. Осмыслить как сюжет строится и в какой последовательности и как бывает интересно и сложно его нарушать.

◼️ Изучать популярные статьи о психологии и поведении человека. К каждой статье рисовать простую «смыслограмму» схему основного смысла и связей в статье примеров и выводов. Это помгает лучше понимать и запоминать.

◼️ Каждый день слушать новую музыку, исполнителя, жанр, причем так, чтобы пару первых треков зарисовывать эскизы образов возникающих в воображении от свежей и необычной музыки

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

◼️ Придумывать новые функции для обычных предметов, например для пожилых людей расширение функциональности обычной трости для ходьбы

Попробуйде 5Д и вам понравится

UX

В блок UX мы перешли из блока продукта, на руках у нас, к этому моменту, был список фич и примерное представление того, что мы хотим делать. На самом деле, только на блоке UX мы окончательно отпилили все, что нужно было отпилить и сфокусировались на решении одной конкретной задачи.

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

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

Так вот, закончили мы исследовать наш продукт и настало время для конкретных действий. За блок UX нам было необходимо:

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

После чего, в идеале, с протестированным прототипом и вайрфреймами мы должны перейти к блоку UI и начать поиск своего визуального языка…
___________

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

Проблема в том, что главный ограничитель наших требований — мы сами. Довольно сложно не уйти в частности и вовремя остановиться, расставив ограничения самим себе.

Например, в нашем приложении есть карточка заказа — как, без реальных бизнес метрик, определить какая информация важна, а какая нет? Нужен просто адрес или подробная карта? Как подать информацию об авторе объявления? Что из этого важнее и должно располагаться выше?

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

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

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

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

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

Подводя итог — на блоке UX каждая команда сначала придумывает бизнес ограничения, а потом героически их преодолевает.

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

Почему мы предпочитаем делать юзабилити-тесты финсервисов вживую?

Почему мы предпочитаем делать юзабилити-тесты финсервисов вживую?

Есть три группы ограничений, которые уводят в общение тет-а-тет.

1. Технические.
– Мы тестируем интерфейсы и важно видеть, как именно люди держат телефоны. Поэтому для удалённых тестов нужны камера и штатив.
– Надо рассылать инструкции, просить пользователя установить необходимое оборудование и подключить наушники. Уходит минут 20 на настройку и технические неполадки.
– Многие респонденты просто технически не продвинуты и не могут всё подготовить.
Эта возня отъедает время общения и терпение респондента.

2. Коммуникация.
– Часто люди волнуются перед тестом, стесняются. Когда разговариваешь с респондентом лично, представляешься и завязываешь беседу, располагаешь человека к себе.
– Люди быстрее доверят важную или личную информацию живому человеку, а не голосу в наушниках и картинке на экране.
– Важно и эмоциональное состояние — показатель отклика и реакции на удобство интерфейса: качественно такое можно считать только в офлайне.
– Кроме того, во время удалённого разговора респондента могут отвлечь: когда вы общаетесь лично, человек посвящает около часа тестированию один на один.
– Вы видите ситуацию целиком, считываете эмоции, реакцию, поведение и позу пользователя — это даёт контекст, который теряется при удалённом тесте.

3. Секьюрность.
– Мы работаем с чувствительными данными клиента, тестируя финансовые сервисы иногда на данных пользователя. В онлайне запустить такое сложно. У пользователя меньше доверия — он может опасаться, что лишние люди увидят экран.
– С другой стороны, мы работаем с банками-заказчиками под NDA и должны гарантировать, что новый продукт не утечёт за пределы команды дизайна, разработки и тестов до запуска проекта.

Иногда от этого приходится отходить, например, когда респонденты из Европы или США. Всё это грозит двойной потерей качества — из-за онлайна и языковых барьеров.

Шпаргалка продакта: жизненный цикл задачи

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

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

Как это работает

Сверху в шпаргалке стадии, под ними вопросы. Еще ниже инструменты, которые помогают на эти вопросы ответить.

Берёте задачу и прогоняете по вопросам. Находите то, о чем не подумали. Думаете, дополняете. На выходе получаете проработанное решение и план действий.
Пользуйтесь

Действие, не состояние

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

Неизвестная ошибка

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

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

Ошибка — попробуйте ещё раз или напишите нам

Или вот вы тест с несколькими вариантами на выбор. Если пропустить, появляется красненькая надпись:

Не выбрано ни одного пункта

Вроде пытаемся что-то донести, но что — еще надо додумать. Почему бы не избавить пользователя от лишних додумываний?

Выберите хотя бы что-то

Действует практически во всём. Попробуйте еще раз и напишите, если не получится.

Давай ещё раз про созвоны

Давай ещё раз про созвоны

Я не планирую новые дела «на сегодня». Новое — только с завтрашнего дня. Это даёт мне шанс выполнить сегодняшний план. Если сегодняшний день не защитить от вторжения новых дел, такого шанса не будет. (Книга Марка Форстера «Сделай это завтра».)

Я не отвечаю на сообщения до 14. И не ставлю встречи до 14 с редкими исключениями. Это даёт мне шанс сделать что-то своё, что важно сделать именно мне. Другого способа у меня нет, проверял. В проекте может быть жопа, а я всё равно не отвечу — проектов много, а жизнь одна.

У тебя один проект или, может, два-три. У меня пять-десять. Ты можешь в какой-то момент мобилизоваться и отдать проекту больше сил. Я могу только «ходить по клеточкам», строго в рамках своего расписания и правил. Если я сломаю свой режим работы — сломаются сразу все проекты.

К тому же я старый.

Поэтому твой план, который подразумевает, что я приму работу в день, когда ты её впервые покажешь — сломан изначально. Даже если в работе всё хорошо (а там обычно не всё хорошо).

Единственный способ гарантированно получить ответ — забить встречу. «На завтра», или сразу на пару дней в течение недели.

Да чёрт с ним, можно и «на сегодня», прямо с утра, прямо в календаре — вдруг я смогу. В чате не отвечу, а встречу подтвердить или отбить это ок, потому что там невозможен какой-то последующий диалог.

Второй по верности способ — спросить «когда ждать ответа», получить обещание и если я не сделаю — медленно уничтожать меня, пока я всё не выполню.

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