Когда ты делаешь дизайн для цифровых продуктов, которыми будут пользоваться люди, чьи привычки и паттерны использования ты можешь предугадать, это не так сложно. Ты почти всегда знаешь, что человек по ту сторону будет держать смартфон вот так, доставать до элементов и контролов большим пальцем вот так, и прочее, прочее, прочее. К примеру, в B2C есть определенный набор инструментов, помогающих дизайнеру в исследованиях. Есть и общепринятый набор правил, по которым ты собираешь обратную связь, нащупываешь возможные проблематики, выдвигаешь гипотезы и прочее. Например, вот довольно понятный и удобный фреймворк:
- определить задачу клиента;
- сформировать свои гипотезы;
- продумать метрики;
- определить контекст использования, CJM, прочее;
- продумать решение и его валидацию.
Для людей, привычных к дизайну продуктов, которыми пользуются миллионы пользователей по всему миру, этот фреймворк знаком (в том или ином виде).
Когда продакты думают, что точно знают, чего хочет пользователь
Но все это претерпевает довольно неслабые изменения, когда ты начинаешь делать дизайн на предприятии. Начнем хотя бы с того, что клиентов как таковых у нас нет — у нас есть пользователи. И штука в том, что мы находимся очень близко к пользователям. Не в плане, что вот есть аккаунт, и мы можем просмотреть подробную инфу о нем, привычные заказы и модель поведения, нет. Мы знаем, что конкретно вот этот пользователь — это Саня, который вчера при тебе залезал на 20-метровую вышку, чтобы с помощью твоего приложения записать данные в журнал обходов. И что ежедневные задачи у Саши довольно сложные и нетривиальные.
Меня зовут Лев, я ведущий дизайнер функции «Цифровые технологии» в СИБУРе, и я расскажу вам о том, как работается дизайнерам приложений и интерфейсов в условиях, когда часть твоих пользователей — это коллектив обходчиков на производственной площадке в Тобольске, которые используют твое приложение немного не в тех условиях, в которых ты это приложение сделал.
Давайте сразу определимся, что дизайнер — это не человек, который нарисует тебе пару красивых картинок или сделает выезжающую менюшку на мобилке. Дизайнер ответственен за единый рабочий продукт целиком, за то, как он воспринимается пользователем, какой опыт ему приносит и какие реальные задачи помогает решать.
Подразделение цифрового дизайна появилось в СИБУРе не так давно, но мы уже нашли кучу возможностей упростить бытие работника на предприятии. Например, мы не так давно писали про мобильные обходы. Де-факто это третья большая итерация процесса. Но между классикой жанра вида «записать все в бумажный блокнот» и нашим приложением был еще один этап.
Отталкиваемся от пользователей, а не от бизнеса
Когда обходчики впервые пришли к технарям с просьбой придумать что-то повеселее блокнотиков, их проблему решили примерно так, как это обычно бывает с SAP в компаниях. Людям дали по сути неплохое коробочное решение, которое кастомизировали, настроили и пустили в плавание. Но не очень подумали о самом процессе использования этого решения. Да, у людей появился электронный журнал обходов. Но вот его синхронизация вызывала ряд вопросов — надо было дважды в день (в начале и в конце смены) шнурком подключать смартфон обходчика к специальному компу для переброса информации в архив. Занимала процедура около 30 минут. Явно немного не то, чего тебе хочется, когда смена закончилась и ты уже готов поехать к семье, а тут эта приблуда полчаса куда-то данные по шнурку передает. Где тут удобство для пользователя?
Кончилось тем, что в конце концов все равно вернулись к бумажным блокнотам. Почему? Да потому что так удобнее. Люди пользуются тем, что удобнее. Если ты сделал что-то неудобное — не будут пользоваться. Поэтому, когда решением проблемы занялось наше подразделение, мы шли прежде всего от комфорта пользователей и от их потребностей. Это логично и это правильно — ведь пользоваться тем, что ты радостно надизайнишь, будут они. Причем в условиях, ощутимо отличных от твоего опенспейса.
Это был первый шаг. Сейчас мы активно имплементируем в устоявшуюся систему СИБУРа наш подход, дизайнеры ведут переговоры с представителями различных бизнес-линий, чтобы все ощутили важность и целесообразность этого подхода.
Вот еще живой пример. У нас есть лаборатория, которая постоянно берет пробы готовой продукции на качество. Все-таки, производство нефтехимическое, надо за всем следить. И вот эта лаборатория взаимодействует как с самим производством, так и с государственными органами контроля, осуществляет калибровку самого производства. И сотрудникам лаборатории надо регулярно брать пробы.
Тобольск, -40, темно, видимость не особо, ты ходишь брать пробы. К тебе приходят ребята из цифрового подразделения и радостно сообщают: «Все, порешали мы твою проблему с бумажками, на тебе, мужик, смартфон». А ты сидишь и думаешь — ну офигеть теперь, на 20 метров забираться, а там еще смартфон этот доставать и тыкать чего-то.
В перчатках с параметрами «Мелкая моторика -50».
И вот здесь для нас как для дизайнеров появляются две довольно важные задачи.
- Мы используем цифровое устройство ввода-вывода информации. У обходчика есть смартфон, можно им трекать ряд параметров, чем-то помогать в осуществлении рабочих обязанностей.
- При этом надо постараться, чтобы человеку не нужно было вынимать смартфон из кармана. Ну серьезно. Это тебе на работе не влом каждые пять минут доставать мобилку из кармана и смотреть фейсбучек. А там у человека -40 за бортом. Перчатки. Плюс на трубе высотой с пятиэтажку. Поэтому мы программируем физические кнопки на андроидофонах. Так сотрудник может даже не вынимать смартфон из кармана — зажал во внутреннем кармане кнопку, запустил голосового помощника (сейчас как раз допиливаем подобное), и зафиксировал какую-то неполадку или расхождение нормативов.
Без контекста использования черта с два мы бы сделали такой кейс. И в случае с контекстом мы заморачиваемся очень сильно.
Методика
Допустим, надо собрать обратную связь от пользователей твоего продукта. Вот как это обычно работает (на примере банков). Есть колл-центр, куда поступает множество звонков. Есть социальные сети, куда клиенты довольно часто жалуются на любые косяки со стороны банка в целом или твоего приложения в частности. Есть возможность пойти в офис и пообщаться там с клиентами, поспрашивать, чего как у них, все ли устраивает, что бы хотели изменить в приложении.
На предприятии вообще все по-другому в этом плане. Это иногда становится причиной разрыва шаблона у дизайнеров, приходящих к нам из других компаний. Там-то ты сидел и вставлял кнопочки в приложение, которое раз в сутки запускают миллионы пользователей. А у нас команда разработки может создавать и совершенствовать продукт, которым де-факто пользуются 10 человек. Но экономический эффект, который может принести твое приложение в связке с этими 10-ю юзерами, сильно выше, чем от всех этих многомиллионных аудиторий. Поэтому фиксация их проблематик очень важна.
Плюс здесь в том, что у нас есть прямой доступ к пользователям. Если нам надо собрать и посчитать индекс удовлетворенности пользователя, или что-то еще — можно просто лично их собрать и все уточнить.
А что еще круче — можно взять каску, спецовку и пойти просто поработать с ними в привычных для них условиях с недельку, чтобы в реальных условиях оценить, чего ты там навертел своим дизайном и удобно ли это людям вообще. Мы гораздо ближе к пользователю нашего продукта. Это же касается и онбоардинга — никаких непоняток и разночтений. Собираем ребят, показываем им, как именно порешали их проблему, чего и где изменилось, как пользоваться всем этим.
Валидация гипотез и метрики
Давайте опять сравним этот процесс в B2B или B2C. Родилась у тебя отличная идея, хочешь ты ее проверить. Запускаешь пару-тройку лендингов, смотришь на обратную связь. Обвешиваешь все это различными метриками, смотришь на цифры, проверяешь на больших аудиториях.
На предприятии все по-своему. Метрики продумываются дизайнерами вместе с продактами на начальном этапе. Замерить такую метрику просто — можешь съездить и поработать по ней сам дней 10. Вот тебе и валидация.
Тут важно помнить еще вот о чем. Цифровизация просто ради цифровизации — это идиотизм. С помощью такой цифровизации можно очень легко испортить людям условия труда. Существует куча простых вещей, которые вообще не надо цифровизировать, которые не требуют смартфонов, графиков всяких и прочего.
И еще про контекст
Несмотря на близость к пользователю и возможность часто опрашивать сотрудников, реальный CJM пользователя, его расписанный на 100% день специалистам СИБУРа не виден. Поэтому очень полезно брать разрабов на интервью с пользователями.
Обычно как работает уведомление команды о проблеме. Приходит продакт, собирает команду, говорит: «Ребята, вот тут есть проблемка». Все начинают думать, что это какая-то вообще полунадуманная проблема сферического пользователя в вакууме.
А здесь мы собираем разрабов и пользователей, чтобы пользователи могли прямо сказать, что именно в решении разрабов им вообще не нужно. Или что работает не так, как задумывалось. И уже в этой ситуации разрабы проникаются связью с пользователями — понимаешь, что вот конкретно у этого человека с нормальным выполнением рабочих задач именно из-за тебя, из-за того, что ты вот вписал какую-то фичу в приложение.
Звучит все просто — собрал две стороны и дал им поговорить. На самом же деле на предприятии это сделать сложно из-за разницы менталитета. Рабочие, обходчики, сотрудники предприятия и цехов воспринимают людей из цифровых отделов не просто как еще одних сотрудников компании, а как отдельную субкультуру. Как куча панков, которые сидят у себя в интернетах, фигачат свой дизайн, а им, нормальным людям, потом разгребай последствия всего этого.
А работать надо, CJM никто не отменял, без него нельзя. У нас ни один проект не стартует, если еще нет точного понимания того, как пользователь будет следовать по процессу. Всегда есть какой-то бизнесовый процесс as is, все вокруг будут говорить, что да, все клево, все работает в точности, как задумывалось. А люди на производстве тебе правду скажут — да нифига не работает. И на изучение этого процесса нужно тратить время. Порой много времени, соблюдая все правила кастдева.
CJM вообще штука модная. Почти все, кто начинает транслировать, что в компании используют Agile, Scrum и даже пару фломастеров купили для досок, так или иначе говорят про CJM. Но на практике уделяют ему сильно меньше внимания, чем он того требует. У нас же сейчас CJM — это основа основ. Мы накидываем людям просто на ватмане своеобразную карту действий: процесс – действие – проблема – решение. И без понимания этой карты даже начинать накидывать свою гипотезу не имеет смысла.
Потому что получится, что ты что-то делаешь для вида, а пользы от этого никакой. Например, обратились к тебе сотрудники, сказали, что у них проблема с ведением бумажных отчетов и подобного. А ты пошел и купил им интерактивную панель на 64 дюйма. Решил ты их проблему? Да нифига, ты просто панель им купил. Теперь у них есть проблема с отчетами и здоровенная панель. Ты должен четко понимать, в чем именно проблема. А люди могут выразить свои мнения о том, как ее можно решить.
Плюс важно работать с ожиданиями. Люди довольно часто могут сами запрашивать нужные фичи, это нельзя игнорировать, потому что они как раз и являются конечными пользователями твоего продукта. Иногда сотрудник цифрового подразделения может считать, что ему-то как раз видней, а люди за периметром не в теме даже собственных хотелок. Реальность вносит свои коррективы — у нас очень прошаренные работники производства.
Поэтому мы создаем с ними общие чатики, в которые они могут напрямую нам закидывать свои хотелки к новым фичам. Частенько, правда, получается так, что пользователь описывает новый и необходимый ему инструмент, а ты ему в ответку — мужик, это же Realtime Board, просто начни пользоваться им для решения описанной проблемы.
Продакты следят за этим и постоянно собирают обратную связь через доступные каналы коммуникации — это может быть чатик в телеграм, у кого есть, или чатик в вайбер, или тот же Typeform.
В общем и целом, у нас получается немного перевернутый классический фреймворк, потому что мы работает от CJM, с прицелом на пользователей сразу, это является отправной точкой любой задачи.
В одном из следующих постов я постараюсь рассказать именно про интерфейсы на большом предприятии. Тут тоже все не так просто, как кажется. Начиная от того, что кнопки интерфейса могут быть размером с ваш 13-дюймовый макбук (потому что так надо), и заканчивая правильным подбором шрифтовых пар. Потому что ты не можешь просто взять и использовать стандартные визуальные представления отчетов и статистики, когда речь идет о 75-дюймовой сенсорной панели.
Более того, даже разрабатывать такие кнопки только на маке без привязки к самой панели не получится.
Кстати, cейчас у нас есть 2 открытые вакансии для толковых дизайнеров цифровых продуктов. Пишите мне на solomadinla@sibur.ru – обязательно отвечу
Автор: Solomadin
