Васе и Пете не мешало бы скооперироваться, чтобы сделать единое удобное решение, но они узнают о существовании друг друга только после релиза (а то и вообще не узнают). В итоге в продукте для курьеров может так и не появиться классное решение из продукта для почтальонов. Хорошая работа может остаться забытой, потому что с ней не нашли общих точек другие подразделения и сервисы.
Другой пример: дизайнер Надя делает классную фичу — дистанционную запись в отделения в мобильном приложении. Фича полезна в условиях коронавируса, но работает через раз, потому что за работу отделений отвечает другое подразделение. Оно может не знать о запуске новой фичи. Не знает подразделение — не знают и операторы.
Со временем продуктовые процессы становятся более зрелыми, и проблема перестаёт быть такой острой. Появляются стандарты, да и люди естественным образом учатся договариваться друг с другом. Но пока большие компании, вставшие на путь цифровизации, ещё не отточили процессы, дизайнеру придётся иметь дело с несогласованностью релизов и функций, с частичным дублированием систем и наступанием друг другу на пятки. Одни проекты бегут быстро, другие мучительно тормозят и, тормозя, затрагивают соседей.
Что с этим делать: при проектировании исследовать не только пользователя и бизнес-заказчика, но и смежные системы.
Мне помогает такой список вопросов:
- Сталкиваются ли с нашими проблемами другие команды Почты? Какие именно команды? Как они решают эти проблемы?
- Откуда приходят данные? Кто за них отвечает? Эти данные шэрятся только нам или нескольким командам?
- Где точка входа в наш сервис? Есть ли другие точки входа и что мы будем делать, если завтра одна из них отвалится или появится новая?
Ещё частично помогает инициирование новых процессов: например, если мы видим, что какой-то продукт существенно рассинхронизировался с другими, можно назначить ревью (как разовое решение) и регулярные встречи для отслеживания ситуации.
Проблема 3: слишком много данных
Беда, похожая на предыдущую — низкая информированность. Данных настолько много, что трудно их собрать, вникнуть, проанализировать и одновременно донести до людей. Сотрудники Почты могут ничего не знать о том, как работает соседний почтовый процесс. А клиент Почты может рьяно и справедливо ругать компанию, не зная, что его проблему она уже решила.
Например, владельцы микробизнесов часто не в курсе, что есть сервис массовой отправки: можно оформить посылки на сайте, там же получить трек-коды для клиентов и в нужное время просто сдать уже оформленные посылки в ближайшем отделении. Будет и быстрее, и проще. Вместо этого они мучаются с ручным оформлением сотни посылок в отделении, а потом проклинают Почту. Проклинают справедливо, но проблема не в отсутствии сервиса, а в пробелах информирования.
Что с этим сделать: не пытаться угнаться за всеми данными (всё равно не получится), но приучить себя к постоянному поиску путей. Дизайнеру часто нужны не сами данные, а понимание, где и как их достать.
Для комфортной работы в компаниях вроде Почты у дизайнера должен сформироваться условный рефлекс: видим незнакомую аббревиатуру — идём в словарь сокращений; нужен доступ к сервису — стучимся с заявкой к таким-то людям; не хватает данных о пользователях — разыскиваем их в такой-то директории. Хорошая новость: это понимание формируется в первые 2–3 месяца работы.
Проблема 4: дизайн, конечно, спасает мир, но не всегда
Экзистенциальный вопрос для дизайнера, мечтающего спасти мир: насколько реально что-то изменить в масштабах многовековой структуры. В небольшом продукте каждое телодвижение дизайнера заметно; а здесь, в такой огромной организации, где легко потеряться, что конкретно я могу сделать лучше, и могу ли хоть что-то?
Нам, продуктовым и сервисным дизайнерам, хочется верить, что мы в состоянии помочь клиенту во всех точках пересечения с Почтой. Точек много: каждый россиянин хотя бы раз в полгода заглядывает в ближайшее отделение. Тем обиднее осознавать, что не всегда есть прямая связь между вложенными усилиями и результатом на стороне клиента. Какие бы классные интерфейсы управления дронами мы ни сделали, для клиента в абстрактном маленьком посёлке Забайкальского края Почта по-прежнему будет выглядеть устаревшим и некачественным сервисом.
Для меня этот вопрос стал болезненным на пике первой волны пандемии. Клиенты Почты часто жаловались на то, что международные отправления застревают на границе. Международные пассажирские рейсы, занимавшие солидное место в логистической цепочке, были отменены, а грузовых рейсов не хватало. Посылки и письма стало буквально не на чем вывозить, и почтовые центры в аэропортах (их называют МППО) стали бутылочным горлышком, где посылки лежали месяцами.
Я смотрела на это и думала: вот мы, разработчики, аналитики и дизайнеры, бегаем здесь, чтобы собрать обратную связь и что-то улучшить в интерфейсе учёта. Но, когда вокруг завал, любой, даже самый удобный интерфейс — мёртвому припарка. Пока не рассосётся коронавирусный коллапс, бесполезно пытаться облегчить людям жизнь с помощью юзабилити. Им тяжело, а ты смотришь на это и ничего не можешь сделать. Это может стать особой болью для дизайнеров с развитой эмпатией и синдромом спасателя.
Что с этим делать? Принять, что дизайнер не всесилен.
Честный ответ на вопрос «Могу ли я что-то поменять в Почте?»: да. Но надо быть готовым к тому, что не всё находится в нашей зоне ответственности. Cлучаются кризисы, когда конкретно наш продукт оказывается не нужен, или проблемы со снабжением, или неравномерное внедрение, или провалы в клиентском сервисе, из-за которого все продукты в глазах потребителя оказываются одинаково плохими. Так бывает не всегда, но бывает. Надо тренировать у себя сердечную мышцу, которая помогает справляться с такими периодами-провалами, которые от нас не зависят. Чёрные дни рано или поздно проходят, а польза навсегда.
Загрузка...
