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

 

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

Автор: admin от 11-02-2019, 14:00, посмотрело: 21

Когда ты делаешь дизайн для цифровых продуктов, которыми будут пользоваться люди, чьи привычки и паттерны использования ты можешь предугадать, это не так сложно. Ты почти всегда знаешь, что человек по ту сторону будет держать смартфон вот так, доставать до элементов и контролов большим пальцем вот так, и прочее, прочее, прочее. К примеру, в 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 – обязательно отвечу

    Источник: Хабр / Интересные публикации

    Категория: Веб-разработка

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

    Добавление комментария

    Имя:*
    E-Mail:
    Комментарий:
    Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
    Введите два слова, показанных на изображении: *