Про видимую демократию

Про видимую демократию

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

Вы наверняка такое видели или даже делали сами (я точно грешен): руководитель организует встречу для обсуждения какой-то проблемы. Но приходит туда с готовым решением или идеей. Или даже презентацией. Ну потому что ты же руководитель/снователь `— ты всегда должен знать, что делать дальше 🙂

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

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

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

Что с этим можно сделать руководителю? Во-первых, расслабиться и понять, что готовые решения никому не нужны. Не нужно пытаться быть самым сильным, смелым и умелым в работе с командой своих коллег. Командная работа не про это.

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

Умное отпиливание

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

В процессе работы, как я и говорил, мы отпиливали многие идеи и фичи о которых я писал выше.

Но отказ от одной конкретной идеи оказался очень показательный и лично для меня является мастер классом по обоснованию своих решений.

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

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

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

А вот и не совсем, мы были уверены в этом пока на одной из консультаций к нам не подошла Оля Сартакова…

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

Мы показали ей наш концепт с бесконечным скроллом, задали несколько вопросов. Она посмотрела на остальные макеты и… сломала мне голову!

Она за пять минут обосновала почему ТАК ДЕЛАТЬ НЕЛЬЗЯ, и сделала это так уверенно и обоснованно, что я был прямо таки поражен и захотел когда-нибудь научиться также.

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

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

Самое тонкое место в UX

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

А где самое тонкое место в UX?
Чаще всего самое тонкое место в UX — место, в котором пользователь соприкасается с человеком, представляющим продукт.
Для b2c продуктов узкое место в UX, как правило, поддержка.
Для b2b продуктов таких мест много: продажник, внедренец, поддерживатель.

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

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

Я решил уйти от МТС в Теле2 с сохранением номера.
На сайте Теле2 заполнил форму перехода, указал данные паспорта, чтобы, как написано на сайте: обработка запроса прошла быстрее в точке выдачи. Отправил запрос. Мне дали два дня, чтобы прийти в точку продаж, а после заказ протухнет.
Через день я пришёл в офис, а он закрыт, хотя время его работы уже давно наступило. А телефон менеджера офиса выключен или вне доступа. Подождал 15 минут и ушёл. Так меня Теле2 "выгнал" первый раз.

Я не сдался и написал сразу же красочное письмо в поддержку: пришёл, закрыто, как я могу вам доверять и что делать?
Мне не ответили в течение суток, как обещано на сайте Теле2. Я написал напоминание — сутки прошли, жду ответ.
Мне ответили и "не пустили" меня в продукт снова. Сапортница сказала: "Очень жаль. Заполните заявление на другой офис."
Другой офис, к слову сказать, в 10 км от меня. А новое заявление — это снова все поля и паспортные данные.

Что я подумал про такой сервис? Ничего хорошего. Заполнять я больше ничего не стал.

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

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

Джон Коулман из Intercom посчитал, что на стартовых экранах популярных приложений в среднем 36% текста.

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

1. Стремись к меньшему. Из двух вариантов, одинаковых по смыслу, предпочитай короткий.

2. Начни с «зачем». Всегда помни, зачем добавляешь слова.

3. Не заставляй думать. Используй слова, чтобы быть понятным, а не остроумным.


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

Недожали

Сегодня речь пойдет о таинственной формулировке «недожали» или особенности преподавания UI.

Как вы помните, UI не самая моя сильная черта (https://t.me/bukhtiyar/161), поэтому я поделюсь взглядом человека, которому нужен был спасательный круг в этой новой сфере. И судя по отзывам, многие, из пришедших в британку, также ждали прокачки своих скиллов в визуале. Но были ребята и с богатым опытом в полиграфии и иллюстрации — им, безусловно, было легче. Но ни я, ни многие другие не получили должного внимания со стороны преподавателей. Давайте попробуем разобраться почему.

Что вообще нужно для того, чтобы научиться делать красивый UI (ну, кроме таланта, конечно)? Необходимо пройти через большое количество проб и ошибок, т.е. чем больше повторений сделано — тем более качественный результат.

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

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

Недожали — это универсальный ответ, который я слышал практически на все действия по UI. Обычно это означало, что можно было сделать лучше. Причем, как именно лучше, было не совсем ясно. Все валится, ничего не выходит, не знаешь что делать дальше — ты просто «недожал».

Но однажды я все же получил небольшое пояснение этого термина. Одним вечером, после занятий я решил спросить, Сергея, что же делать когда ничего не получается? Он поделился своим опытом — когда ничего не получается можно начать решать проблемы постепенно, брать какую-то одну небольшую часть проекта, например, контролл и доводить его до совершенства. То есть фокусируешься на одном моменте, не отвлекаясь ни на что больше. И… постепенно «дожимаешь» весь проект.

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

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

Что же по обратной связи — то блок, который вел Женя закончился, и чтобы получать хоть какую-то обратную связь я стал донимать Сергея Гальцева, на что однажды получил комментарий, что он уже не отвечает за блок UI, т.к. со второго семестра является куратором курса. Исторически он вел блок UI, в первом семестре так и было. Но во втором семестре блок UI вел Женя Бондарев, при этом Сергей также продолжал комментировать макеты и принимать активное участие. Но четкого понимания, кто рулит процессом и несет ответственность не было. Я уже молчу про ситуации, когда комментарии разных преподавателей по одному макету противоречили друг другу.

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

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

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

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

Но практически до самой защиты я был недоволен результатом и постоянно переделывал экраны так или иначе.

Массовый опрос

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

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

После инструктажа и обучения, полевик выходит на точку (кластер). Обычно, в одном исследовании требуется собрать данные с 25 респондентов, число которых, в свою очередь, ограничено квотой — то есть заданным количеством людей определенного возраста. Например, 4 мужчины и 4 женщины возрастом от 18 до 34 лет и т.д.

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

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

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

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

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