Улучшение процесса проектирования в вашей организации

Как дизайнеры и исследователи пользовательского опыта (UX), мы чаще всего слышим жалобы от пользователей:

«Почему они не думают о том, что мне нужно?»

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

Результатом является плохой дизайн, который снижает производительность. Например, эффективности в здравоохранении мешают электронные медицинские карты (ЭМК). Жалобы на эти программные системы легион. Доктор Стивен Уджент, бостонский дерматолог и выпускник Йельской медицинской школы, не является исключением.

С 2010 года д-р Уджент использовал две системы ЭМИ: до 2010 года он заканчивал работу ровно в 5:15 каждый день. Поскольку он и его коллеги начали использовать ЭМИ, он обычно работает от получаса до 1,5 часов вечером. «Я не знаю ни одного врача, который был бы доволен своей системой медицинской документации. Сумасшествие в том, что я был намного эффективнее, когда использовал ручку и бумагу».

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

Уджент кратко резюмирует проблему с ЭМИ:

«Люди, которые проектируют ее [систему EMR], не понимают моего рабочего процесса. Если бы они это сделали, они бы разработали другую систему».

Врачи не одиноки в своем недовольстве неуклюжим программным обеспечением. Потребители и профессионалы по всему миру высказывают схожие жалобы:

«Почему я не могу найти то, что мне нужно?»

«Почему они делают это так сложно?»

«Зачем мне создавать логин, если я просто хочу купить этот товар. Я даю им деньги. Разве этого недостаточно?»

Основной причиной неуклюжего программного обеспечения являются ошибочные процессы проектирования. В этой статье мы обрисуем четыре проблемы процесса проектирования и объясним, как их решить.

1. Сложность
2. Синдром следующего выпуска
3. Недостаточно времени для итераций дизайна
4. Передача контроля внешним поставщикам

1. Сложность

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

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

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

Как объясняет Джефф Хорват, доктор философии, UX-консультант с большим опытом работы в здравоохранении: «Эти требования на пару порядков повышают строгость написания протоколов испытаний, настройки испытаний, сбора данных, анализа, контроля качества и получить одобрение на проведение исследования в первую очередь». Например, один раунд юзабилити-тестирования увеличивается с шести недель (разумный срок для стандартного юзабилити-теста) до шести месяцев. И это при одном раунде юзабилити-тестирования . Часто необходимы два или более раундов тестирования.

Такой уровень строгости является тревожным звонком для компаний, плохо знакомых с FDA. Не раз Хорват сталкивался с жесткими разговорами с клиентами, которые не были готовы к продлению сроков и дополнительному бюджету, необходимому для выполнения требований FDA. Это тяжело, но необходимо. «Тщательность стоит того, — говорит Хорват. В 2018 году FDA одобрило всего 11% предпродажных заявок.

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

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

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

Восемь часов спустя МакКрей был объявлен мертвым от передозировки морфина. Основным фактором этой трагедии была несовершенная конструкция инфузионного насоса, используемого для введения лекарств. Для насоса потребовалось 27 шагов программирования. Неспособность решить эту сложность путем разработки более интуитивно понятного пользовательского интерфейса привела к ненужной смерти.

Решение

Решение состоит в том, чтобы признать сложность и решить ее. Это звучит логично. Тем не менее, как объяснялось выше, сложные правила FDA часто удивляют руководителей компаний. Отрицание не работает. Неспособность планировать означает, что ваша организация, скорее всего, попадет в число 89 % дорыночных заявок, отклоненных FDA в 2018 году.

При проведении юзабилити-тестов исследователи пользовательского опыта должны предпринять три шага, чтобы справиться со сложностью, связанной с правилами FDA:

1. Модератор (человек, который проводит юзабилити-тест) должен быть сверхвнимателен. Например, если при МРТ-сканировании требуется, чтобы технический специалист выполнял строгую последовательность шагов при использовании соответствующего программного обеспечения, модератор должен внимательно наблюдать, чтобы определить, следует ли участник инструкциям в точности. В противном случае задача оценивается как невыполненная, что означает, что и дизайн интерфейса, и сопутствующая документация потребуют модификации;
2. Модератор также должен отслеживать близкие звонки. Например, участник может сначала выполнить шаги не по порядку, обнаружить ошибку и восстановиться, соблюдая правильную последовательность. FDA считает это промахом, и модератор должен сообщить об этом как таковой;
3. Модератор также должен оценить знания участника. Считает ли она, что следовала правильной последовательности? Верно ли это убеждение?

2. Синдром следующего выпуска

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

Любой, кто занимается дизайном и разработкой продукта, должен бороться с синдромом следующего релиза. Два примера подтверждают это:

• Мы обнаружили серьезные недостатки в дизайне программного обеспечения для отслеживания состояния здоровья клиента. Компания решила выпустить программное обеспечение без решения этих проблем. Неудивительно, что клиенты были недовольны.
• Мы провели юзабилити-тесты для крупного кредитного союза в США. Участники были опытными финансовыми консультантами. Тестирование выявило серьезные недостатки дизайна, включая запутанные значки состояния, кнопки с неясным назначением и почти скрытую ссылку, которая не позволяла участникам отображать важные данные. Помните, если пользователь этого не видит, значит, его там нет. Когда мы сообщили о результатах, нам ответили: «Мы исправим это в следующем выпуске». Как и ожидалось, веб-приложение не было хорошо принято. Ответы пользователей включали: «Почему вы попросили нас проверить приложение, если вы не собирались вносить изменения?»

Решение: отказаться от менталитета «Все исправлю в следующий раз»

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

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

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

Переопределение ценности, по сути, является улучшением процесса, поскольку оно устанавливает новый набор приоритетов, которые лучше служат клиентам и долгосрочным интересам вашей компании. Как сообщает McKinsey в «Бизнес-ценности дизайна»: «Компании высшего квартиля используют полный пользовательский опыт; они разрушают внутренние барьеры между физическим, цифровым и сервисным дизайном».

3. Недостаточное время для итераций дизайна

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

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

Решение: дизайнерские шипы

Одно решение приходит из мира кодирования. В своей статье «Внедрение масштабного UX в гибкую разработку» Дэймон Диммик предлагает идею всплесков дизайна, «пузырей времени, которые позволяют дизайнерам сосредоточиться на сложных проблемах UX». Они вписываются в структуру Scrum, временно заменяя обычный спринт.

Дизайнерские шипы обладают рядом преимуществ:

• Они позволяют UX-командам сосредоточиться на целостных проблемах и не увязнуть в мелких проблемах дизайна, которые иногда акцентируются в рамках одного спринта;
• Они дают возможность исследовать сложные вопросы UX с высокого уровня. При необходимости команда UX-дизайнеров также может в любой момент заняться дизайн-ориентированным мышлением для решения более крупных задач UX;
• Внедряя всплески дизайна, UX-команды могут использовать ту же гибкость, что и команды разработчиков в гибком процессе, и уделять время, необходимое для сосредоточения внимания на проблемах дизайна, которые не всегда хорошо вписываются в стандартный спринт схватки;
• Разработка, на которую вряд ли повлияют дизайнерские решения, может продолжаться.

Естественно, итерации дизайна часто затрагивают определенные части кода сайта, приложения или программного продукта. По этой причине во время всплесков дизайна любой код, на который, вероятно, повлияет скачок дизайна, не может двигаться вперед. Но, как четко заявляет Диммик, эта «задержка», скорее всего, сэкономит время, избегая повторной работы. Просто не имеет смысла писать код сейчас, а затем переписывать его через несколько недель после того, как команда согласовала пересмотренный дизайн. Короче говоря, отсрочка кодирования на самом деле экономит время и бюджет.

4. Слишком сильно полагаться на поставщиков

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

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

Работая в этой фирме дизайнером UX, я часто сталкивался с такой динамикой:

Менеджер : «Эй, Эрик, не могли бы вы оценить это программное обеспечение для претензий, которое мы планируем купить? Мы просто хотим убедиться, что все работает так, как задумано».

Я : «Конечно, я пришлю вам свои предварительные выводы к концу недели».

Менеджер : «Отлично»

На следующей неделе:

Менеджер : «Спасибо за отзыв. Я вижу, что вы обнаружили три серьезные проблемы: трудно найти номер для существующей претензии, экраны со слишком большим количеством текста, который трудно прочитать, и сложность возврата к предыдущему экрану при обработке новой претензии. Это касается. Считаете ли вы, что эти проблемы будут снижать производительность?»

Я : «Да, я думаю, что эти проблемы увеличат нагрузку и время обработки в Центре претензий. Я очень обеспокоен, потому что моя предыдущая работа с командой Джанет показала, что представители Центра претензий и без того испытывают сильный стресс».

Менеджер : «Очень приятно знать. Я только что отправил чек. Я попрошу поставщика устранить проблемы перед отправкой».

Я (кричу внутри): «Неееееет!»

Этот благонамеренный менеджер поступил совершенно неправильно. Он попросил внести изменения после отправки чека. Неудивительно, что поставщик так и не внес запрошенные изменения. Почему они? У них были свои деньги.

Мало того, что этот сценарий неоднократно повторялся в этой компании, я был свидетелем этого на протяжении всей своей карьеры UX.

Решение

Решение ясно. Если продукт поставщика не соответствует потребностям клиента и бизнеса, а запрашиваемые вами изменения находятся в пределах объема, не платите до тех пор, пока поставщик не внесет изменения. Это действительно настолько просто.

Заключение

В этой части мы определили четыре общих барьера на пути к качественному дизайну и соответствующие решения:

1. Сложные правила и стандарты
   Решение состоит в том, чтобы признать и устранить сложность, разработав реалистичные сроки и достаточный бюджет для исследований и итеративного проектирования.
2. Доставка программного обеспечения с ошибками с обещанием исправить их позже
   Решение состоит в том, чтобы избежать синдрома следующего выпуска и решить серьезные проблемы сейчас. Убедите лиц, принимающих решения, переопределив значение ценности в вашей организации.
3. Недостаточно времени для итераций дизайна
   Решение состоит в том, чтобы включить пики дизайна в процесс гибкой разработки. Эти пузыри времени временно заменяют спринт и позволяют дизайнерам сосредоточиться на сложных проблемах UX.
4. Слишком сильно полагаться на поставщиков
   Решение состоит в том, чтобы сохранить рычаг, удерживая окончательный платеж до тех пор, пока поставщик не внесет запрошенные изменения, если эти изменения находятся в пределах первоначального объема проекта.

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