Как дизайнеры рэп читали

Блок Саши Мемуса из двух занятий, посвященный сплочению и осознанности своих проектов, закончился тем, что мы провели рэп-баттл между командами. Да-да, в рифму и с панчами! Нужно было сначала обыграть тему своего проекта, а потом раскатать проект оппонента. Судьями выступали ребята из Redmadrobot.

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

После Мемус-батла Саша посвятил всех в таинство ретроспективы, объяснив суть и важность этого мероприятия.

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

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

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

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

Подводя небольшой итог занятий с Сашей: хорошая и сплоченная команда — это залог успеха.

Принцип «Направляй, а не ругайся»

Если клиент совершил ошибку, не стоит на него ругаться. Ошибки совершаются по невнимательности, но когда за них получешь — чувствуешь себя дураком. Никто не любит чувствовать себя дураком.

Если клиент не заполнил поле и жмёт на кнопку «далее» — направьте его: поставьте фокус на это поле, откройте клавиатуру. Можно написать аккуратное «Укажите» под полем ввода. Главное — не скатываться в нахально-безразличное «Обязательно для заполнения». Звучит, будто тётка на почте нахамила.

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

Юрий Ветров #2 - о дайджесте, конкурсе и продуктовом дизайне.

Директор по дизайну в Mail.Ru Group (продукты под брендом “Mail.Ru”).
jvetrau.com

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

Я в любом случае читаю уйму статей, чтобы оставаться в теме и находить новые направления для развития дизайна в Mail.Ru. Это очень здорово ускоряет изменения (и помогает писать талмуды про UX-cтратегию (uxstrategy.co)). Почему бы не поделиться этим с сообществом? :) Я трачу на это не сильно больше времени относительно чтения, зато лучше структурирую собственные мысли.

— Как происходит процесс сбора материалов для дайджеста? Сколько времени у тебя на это уходит?

У меня про это есть отдельная презентация (slideshare.net/jvetrau/wud2014-yvetrov-background-research) :) Где-то полчаса-час в день уходит на чтение. У меня тонна подписок в Feedly, это основной источник — читаю от корки до корки (блоги дизайн-команд и конкретных дизайнеров, специализированные журналы, пара других дайджестов). Есть издания, которые читаю отдельно (Engadget, периодически Fast Co Design), оттуда тоже иногда приходит. После этого сохраняю лучшее в Pinboard (pinboard.in/u:jvetrau), оттуда постепенно публикую в соц.сети, а в конце месяца собираю дайджест в разных форматах (часа 3 в месяц, причём по возможности просто обновляю черновик статьи по ходу каждого поста в соц.сети, так что к концу периода остаётся только вставить картинки).

— Какие темы продуктового дизайна сейчас наиболее актуальны?

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

— Вы уже пять лет проводите Russian Design Cup. Почему в этом году так мало участников, по сравнению с предыдущим?

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

— Вы приглашали к себе на работу участников с хорошими кейсами?

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

— Бургеры и пиво или вино и стейк?

Оба хороши, но первое чаще и более компанейское :)

— Что произойдет с интерфейсами за следующие 5 лет?

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

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

Шейн Дойл написал о неидеальных состояниях интерфейса.

Многие дизайнеры проектируют только идеальное состояние, когда всё отображается корректно и контент идеален. Но есть ещё состояния:

  1. Пустое: контент ещё не добавлен, нулевые результаты поиска, пользователь удалил контент.
  2. Загрузка: когда загружается контент или выполняется какое-то действие. Важно донести до пользователя, что программа не зависла.
  3. Частичная наполненность: когда есть только часть контента. Подумайте, как помочь пользователю сделать так, чтобы получить идеальное состояние.
  4. Неидеальное: слишком длинный или короткий текст, изображения в неправильном формате или отсутствуют, нет части контента. Пользователь не должен думать, что программа сломалась.
  5. Интерактивное: фокус на элементе, заполнение поля и другие изменения интерфейса после взаимодействия с пользователем.
  6. Ошибка: нет подключения к сети, пользователь сделал что-то не то, системная ошибка. Важно, чтобы пользователь понимал суть ошибки и что ему делать.
  7. Выполнение действия: когда пользователь справился со своей задачей. Состояние может отличаться для разных пользовательских задач.

https://ux.pub/proektirovanie-razlichnyh-sostoyaniy-interfeysa/

Возвращение

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

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

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

Прежде чем продолжить, для самых искушенных быстрые ссылки на прошлые серии:

Про бриф, особенности бизнес модели и большое легаси профиру — https://t.me/bukhtiyar/88

Дальше история продолжается рассказом о том, как мы примеряли сервис на себя и познали проблему курицы и яйца — https://t.me/bukhtiyar/88

Ну и как же без классической истории поиска решения — взяться за все проблемы сразу, чтобы в итоге найти одну самую большую и важную — https://t.me/bukhtiyar/88

А дальше я начал рассказ о том какие исследования мы провели и какие инсайты получили. Успел затронуть историю нашего заказа качестве клиента профиру, а также о том насколько непросто выманить мастеров для интервью — https://t.me/bukhtiyar/112

Закончилось все на предательском «Про полученные инсайты и конкурентов расскажу завтра.» 😂
Ну и вот спустя два месяца пожалуйста — история про конкурентов.

Вы правы, мало кто пройдет по ссылкам, поэтому вот, совсем краткий синопсис предыдущих серий:

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

Метод гипотез в решении технических задач

Бывают такие задачи, в которых решение очевидно не сразу. Скажем вы накопили третью сотню гигабайт в базе, и приложение начинает глючить, а в какой именно части: кеш, код, база или сеть — непонятно. Или новый апдейт яндекс-метрики перестает считать внутренние переходы внутри вашего SPA.

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

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

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

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