Учебник по юзабилити: Работа с измеримыми и конечными ресурсами25.08.2016 17:22

UX-исследователь, юзабилити-евангелист Сергей Немеров пишет книгу — учебник по юзабилити. Новые главы книги первым делом появятся в блоге «Нетологии». Сегодня — четвертая глава «Работа с измеримыми и конечными ресурсами».

Невозможно управлять тем, что нельзя измерить

Древнеримская поговорка

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

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

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

С другой стороны, любая оптимизация и структурирование бизнес-процессов у нас в России находится еще настолько в зачаточной стадии, что пока кажется чрезмерно оптимистичным выделение целой главы учебника под эту, еще только зарождающуюся профессию. На данном этапе чаще всего Заказчик сам выстраивает свои процессы на свой вкус, сам нанимает кадры для их выполнения, сам анализирует собственные цели и выдает проектировщику уже готовый пул задач, к выполнению которых нужно приступить as is, ни в коем случае не пытаясь что-либо по-настоящему оптимизировать.

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

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

Разумеется, и у нас в стране есть буквально 2–3 специалиста запредельно высокого уровня, (как, например, многоуважаемый Денис Бесков), которые при выстраивании схемы наиболее оптимальных бизнес-процессов имеют затем реальные полномочия перекраивать советы директоров Газпрома или Роснефти для соответствия с созданной ими более эффективной схемой бизнес-процессов, гарантируя одним своим именем максимальный рост всех требуемых показателей. Но таким экспертам давно уже не нужен вообще никакой учебник.

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

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

Каждому проектировщику нужно уметь обязательно измерять будущий интерфейс в систем координат «Время-Деньги-Безопасность».

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

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

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

Итак, вопрос сегодня ставится прямо: способно ли эффективное проектирование информационной системы, основанное на анализе предпочтений пользователей и по-возможности, бизнес-целей заказчика (даже учитывая, что реальный бизнес-план или даже «Стратегию развития компании до 2025 года» — новичку никогда не покажут) — ощутимо помочь бизнесу стать более прибыльным?

Может. Прежде всего за счет экономии конечных ресурсов:

• сроков на разработку,

• бюджета и количества фич внутри системы,

• времени на переучивание и адаптацию будущих пользователей.

О ресурсах в инфосистемах

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

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

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

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

• И его девушка,

• И его желание изучать английский,

• И свежекупленная игра No Mans Sky;

• И чтение ленты в проектируемой вами сейчас новой революционной социальной сети…

• ОДИНАКОВО конкурируют за его внимание, свободное время и доступные деньги!!!

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

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

Рассмотрим подробнее правильный практический подход к такому ресурсоориентированному проектированию на практике.

Практическая работа

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

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

Допустим, у приложения есть четыре режима:

• Assist

• Hazard

• Emergency

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

На первый взгляд, все выглядит очень мудро и продуманно, не так ли? Что же тут можно улучшить?

Выбор системы измерения

Еще раз повторим главную мысль четвертой главы нашего учебника: Улучшать что-либо можно только выбрав предварительно систему измерений, чтобы любое найденное решение можно было объективно сравнивать с текущим.

Отталкиваясь от десятилетнего опыта работы автора данной главы с реальными системами безопасности движения в ОАО РЖД, была сформулирована следующая гиппотеза:

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

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

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

• Снять варежки,

• Достать смартфон из кармана (не уронив вниз),

• Повернуть к себе экраном,

• Разблокировать смартфон,

• Войти в нужное приложение,

• Убедиться, что данные с GPS подхвачены верно,

• Принять решение о том, какая из опций больше подходит в текущей ситуации: Звонок другу или Emergency,

• Попасть пальцем в пиктограмму нужной опции,

• Дождаться вызова, после чего уверенным голосом пояснить ситуацию Начальнику смены,

• Убрать смартфон в карман, чтобы не потерять.

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

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

Естественно, что крупная компания (например, такая как ОАО РЖД) — никогда не заказала бы подобное приложение для смартфонов со столь сложными пользовательскими сценариями и минимальными гарантиями принесенного эффекта на каждый затраченный рубль бюджета.

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

Это непреложный факт.

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

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

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

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

Были разработаны основные принципы действия такого смарт-ремня: при разовом нажатии на кнопку на ремне устройство переходит в режим чекина, двойном назатии — в режим Assist, при тройном быстром клике в режим Emergency, при длительном клике (более 2 секунд) — осуществляет вызов на номер телефона, по умолчанию зашитый в устройстве. Также было предложено использовать принцип, когда одно нажатие на единственную кнопку ремня в зависимости от предыдущего состояния системы — влияет на логику дальнейшей работы:

• Если система ранее находилась в пассивном положении с режимом sing off — то первое же нажатие на кнопку с выбором режима автоматически переводит систему в активный статус и запускает таймер,

• Если режим sign on был уже запущен ранее по разовому клику и автоматически начался отсчет времени, то повторное разовое нажатие на ту же кнопку автоматически переводит систему в положение sign off.

Таким образом, общий сценарий активации режимов такого ремня вне экстренных ситуаций в течении суток снижается до 2–3 нажатий на одну и ту же кнопку ремня. Также было предложено в такой ремень встроить ударостойкий индикатор «Красный-Желтый-Зеленый», напоминающий работнику о текущем режиме, в котором работает устройство на данный момент.

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

1. Дотянуться одной рукой до пряжки на смарт-ремне (не снимая варежки);

2. С силой надавить около двух секунд на единственную кнопку;

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

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

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

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

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

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

Решение-костыль

Однако, даже существующее сегодня мобильное приложение можно было значительно упростить и ускорить за счет использования тех же самых принципов, озвученных еще Стивом Джобсом «Одна кнопка или меньше». Прежде всего можно попробовать рассмотреть способы решения проблемы долгого выбора и ввода за счет того, что все три кнопки режимов заменить одной, но крупной, применив к ней ту же самую логику — один клик, дабл-клик, долгий клик, свайп и т.д. — для переключения режимов. Также и сочная цветовая индикация у единственной кнопки однозначно может указывать на текущий режим.

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

Отказ от обязанности самостоятельно вносить все пользовательские настройки способен в 2–3 раза снизить процент дальнейших пользовательских ошибок. Для обычного верхолаза все эти настройки должны быть заблокированы, также как и ручной ввод GPS (он либо есть, либо нет):

Также отлично упрощает взаимодействие с интерфейсом отказ от окон are you shure Лучше заложить программно, что при быстром возврате (менее 2 секунд) пользователем режима или таймера в начальное состояние — имела место случайна ошибка или сбой, и режим фактически не отключался.

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

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

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

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

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

• времени ввода данных,

• удерживания внимания на системе (а не на своих первичных обязанностях);

• и самих бесценных жизней.

Время для притчи:

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

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

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

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

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

• Письма? Через почту? Значит на протяжении пятнадцати лет я каждое утро беру вот этот телефон, включаю громкую связь и по очереди лично выслушиваю ежесуточные доклады всех начальников ПТО. И каждый из них, мертвый или живой, больной или здоровый, в отпуске или в полете — ежедневно обязан мне вслух отчитаться о результатах работы за сутки, задать вопросы и выслушать все мои оперативные распоряжения. Более того, каждый из них, каждую ночь на протяжении всей своей жизни должен вздрагивать в холодном поту в ожидании этого отчета и быть готовым, что за малейший косяк он получит от меня такой нагоняй, что забудет собственное имя… И вот если завтра, предположим, вместо этой стандартной утренней взбучки — они получат от меня электронное, б***, письмо, — то все в этом мире мгновенно рухнет. Почему? Да все они тут же решат, что старик уже сдулся, что настали новые времена, что можно уже халтурить, левачить, пьянствовать — ведь им теперь, видите ли, уже пишут письма и заставляют вводить циферки. А неизбежная кара за косяки и утренняя «линейка» в виде моего яростного ора — якобы уже ушла на пенсию. Значит вот им теперь уже, поглядывая на экранчики и нажимая на кнопочки, можно творить любую ерунду за тысячу километров от моих глаз. Не дождетесь!

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

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

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

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

Все главы книги:

• Глава 1: «Сначала — технология»
• Глава 2: «Его Величество Контент»
• Глава 3: «Точки соприкосновения»
• Глава 4: «Работа с измеримыми и конечными ресурсами»

Полный текст статьи читайте на Нетология