Главная » Хабрахабр » Особенности подходов к дизайну в реальном производственном секторе

Особенности подходов к дизайну в реальном производственном секторе

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

  • определить задачу клиента;
  • сформировать свои гипотезы;
  • продумать метрики;
  • определить контекст использования, CJM, прочее;
  • продумать решение и его валидацию.

Для людей, привычных к дизайну продуктов, которыми пользуются миллионы пользователей по всему миру, этот фреймворк знаком (в том или ином виде).

Когда продакты думают, что точно знают, чего хочет пользователь

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

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

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

Отталкиваемся от пользователей, а не от бизнеса

Когда обходчики впервые пришли к технарям с просьбой придумать что-то повеселее блокнотиков, их проблему решили примерно так, как это обычно бывает с SAP в компаниях. Людям дали по сути неплохое коробочное решение, которое кастомизировали, настроили и пустили в плавание. Но не очень подумали о самом процессе использования этого решения. Да, у людей появился электронный журнал обходов. Но вот его синхронизация вызывала ряд вопросов — надо было дважды в день (в начале и в конце смены) шнурком подключать смартфон обходчика к специальному компу для переброса информации в архив. Занимала процедура около 30 минут. Явно немного не то, чего тебе хочется, когда смена закончилась и ты уже готов поехать к семье, а тут эта приблуда полчаса куда-то данные по шнурку передает. Где тут удобство для пользователя?

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

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

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

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

И вот здесь для нас как для дизайнеров появляются две довольно важные задачи.

  1. Мы используем цифровое устройство ввода-вывода информации. У обходчика есть смартфон, можно им трекать ряд параметров, чем-то помогать в осуществлении рабочих обязанностей.
  2. При этом надо постараться, чтобы человеку не нужно было вынимать смартфон из кармана. Ну серьезно. Это тебе на работе не влом каждые пять минут доставать мобилку из кармана и смотреть фейсбучек. А там у человека -40 за бортом. Перчатки. Плюс на трубе высотой с пятиэтажку. Поэтому мы программируем физические кнопки на андроидофонах. Так сотрудник может даже не вынимать смартфон из кармана — зажал во внутреннем кармане кнопку, запустил голосового помощника (сейчас как раз допиливаем подобное), и зафиксировал какую-то неполадку или расхождение нормативов.

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

Методика

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

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

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

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

Валидация гипотез и метрики

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

Метрики продумываются дизайнерами вместе с продактами на начальном этапе. На предприятии все по-своему. Вот тебе и валидация. Замерить такую метрику просто — можешь съездить и поработать по ней сам дней 10.

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

И еще про контекст

Несмотря на близость к пользователю и возможность часто опрашивать сотрудников, реальный CJM пользователя, его расписанный на 100% день специалистам СИБУРа не виден. Поэтому очень полезно брать разрабов на интервью с пользователями.

Приходит продакт, собирает команду, говорит: «Ребята, вот тут есть проблемка». Обычно как работает уведомление команды о проблеме. Все начинают думать, что это какая-то вообще полунадуманная проблема сферического пользователя в вакууме.

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

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

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

Почти все, кто начинает транслировать, что в компании используют Agile, Scrum и даже пару фломастеров купили для досок, так или иначе говорят про CJM. CJM вообще штука модная. У нас же сейчас CJM — это основа основ. Но на практике уделяют ему сильно меньше внимания, чем он того требует. И без понимания этой карты даже начинать накидывать свою гипотезу не имеет смысла. Мы накидываем людям просто на ватмане своеобразную карту действий: процесс – действие – проблема – решение.

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

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

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

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

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

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

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

Пишите мне на solomadinla@sibur.ru – обязательно отвечу Кстати, cейчас у нас есть 2 открытые вакансии для толковых дизайнеров цифровых продуктов.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

PHP-Дайджест № 154 (9 – 21 апреля 2019)

В выпуске: Zend Framework переходит под крыло Linux Foundation, новости из PHP Internals, порция полезных инструментов, и многое другое. Свежая подборка со ссылками на новости и материалы. Приятного чтения! Новости и релизы PHP Internals Инструменты pinba-server/pinba-server — Простой pinba-сервер на ...

Язык Bosque — новый язык программирования от Microsoft

Языку дали название Bosque. Буквально несколько дней назад компания Microsoft представила публике новый язык программирования. Главная миссия дизайна языка — лучше быть богатым и здоровым, чем бедным и больным чтобы он был прост и понятен как для человека, так и ...