История одного дня пользователя

Еще один метод, способный проиллюстрировать флоу взаимодействия пользователя с будущим продуктом с учетом контекста. Этот метод помогает понять мотивы и примерный бэкграунд в котором находится пользователь — что было до того как у него возникла потребность в продукте? Что он делал после, почему поступил так, а не иначе?

Итак, история про Алексея:
«Алексей офисный работник, который проводит на работе с 9 до 19. У него нет свободного времени. Алексей женат, но жена, также, все время проводит на работе. Они живут в старой квартире, которая досталась от бабушки. Жена, периодически пилит Алексея, что он никак не может сделать хотя бы косметический ремонт. В конце концов, Алексей накопил денег и решил для начала поменять старый паркет. Он задумался над тем, что ему нужен хороший специалист, который выполнит конкретную работу. Но он не знал как отобрать нужного кандидата, чтобы и по цене не обманули и по качеству не кинули. На работе Алексей поделился проблемой со своим коллегой Леонидом, и тот посоветовал сервис профи.ру.

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

В итоге, Алексей получил список подходящих специалистов. Он выбрал лучшего по соотношению рейтинга/цены/отзывов. Оставил заявку. Приложение потребовало сделать оплату, Алексей воспользовался Apple Pay. Оплата прошла. Через какое-то время мастер ответил согласием и взялся за заказ.

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

-сделана ли работа полностью?
-производились ли дополнительные работы?
Приложение просит оценить специалиста и его работу, он ставит 5 звезд.
После чего Алексей видит, что заказ закрыт и деньги за работу списаны.
В этот вечер у Алексея был секс».

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

Валерия Курмак написала об организации юзабилити-тестов, в которых участвуют люди с инвалидностью

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

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

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

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

Договариваясь о встрече, спросите, нужна ли человеку помощь, чтобы добраться до вас, и какая. Если никогда не общались с человеком с инвалидностью, прочитайте специальные правила этикета.

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

Эффективно, когда команда встречается с незрячим тестировщиком, вместе с ним тестирует интерфейс и на месте договаривается о том или ином решении.

https://medium.com/Valeria.kurmak/73845933b550

Модель двойного алмаза

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

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

Если рассматривать этот процесс в рамках разработки продукта, то получится примерно такая история:

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

Решительность и находчивость

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

Сегодня про решительность.

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

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

👎 Я проверил, но ты тоже посмотри, чтобы наверняка.

👎 Никто не говорил, что так можно делать.

👎 Я сделаю, но под твою ответственность.

👎 Я написал в поддержку, если не ответят за два дня, тогда позвоню.

👎 Обычно это делает Володя, поэтому я и не стал делать.

👎 Давайте соберёмся и обсудим.
...

Нерешительные коллеги могут порождать лишние итерации в работе: кто-то лишний раз смотрит, перепроверяет, ждёт. Создаётся дисбаланс и лишние трудозатраты. Если вы когда-либо сдавали дизайн или иную работу внешнему заказчику, то могли видеть, как нерешительность растягивает время. Если есть ЛПР, который решает — сдаётся быстро, а если есть коллективная ответственность — адская возня.

Задача лидеров направлять нерешительных коллег в решительное русло, выгонять их из зоны комфорта: сам проверь и подведи итог; а сам как думаешь?; позвони сразу в поддержку; Володи нет — сам сделай; не надо собираться — сам реши. Лидер должен решительно бороться с нерешительностью.

Я какое-то время писал статьи и публиковал их только в личный блог. Понятно, что мало прочтений (почти ноль), мотивация писать новое близка к нулю. Я не знал хорошо ли пишу или нет, но я знал, что есть только один способ это узнать — опубликовать статью в тематическом паблике. И вот в конце 2018 года я написал статью про способы onboarding пользователей и решился пригласить коллег из отрасли её почитать — запостил ссылку в UX club на Facebook.

Я переживал. Но пошли лайки и положительные комментарии, которые мотивировали меня писать ещё и звать коллег почитать. Теперь приглашать читателей в мои статьи стало для меня комфортным занятием — зона комфорта расширилась, пришла уверенность.
Конечно, обратная связь могла бы быть негативной. Но это тоже хорошо — я бы раньше понял, что незачем тратить время.

Прокачивали свою решительность и многие известные (теперь уже известные) люди. Например, знаменитый физик Лев Ландау был очень стеснительным. Но решил бороться с этим: в юном возрасте он привязывал к своей шляпе воздушный шарик и гулял так по Невскому проспекту в Ленинграде. Это было в начале 20-го века. Возможно, не решись он на такую прокачку он бы и не стал учёным, который мог сформулировать и реализовать самые смелые идеи.

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

Решительность хороша в связке с находчивостью, но об этом в следующий раз.

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

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

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

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

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

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

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

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

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

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

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

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

Вопрос: есть команда из трёх человек

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

Давайте для начала разберёмся, почему вы считаете сильным того программиста, который буллит? Судя по вашему описанию, второй программист гораздо сильнее, чем первый — за ним не приходится переделывать.

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

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