Худший UX для лучшего продукта: как мыслить результатами

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

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

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

Комплектация заказов: розничная торговля

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

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

Приложение для сканирования штрих-кодов

Во всех трех категориях используется внутреннее приложение, работающее на сканере штрих-кодов на платформе android. Каждый товар и каждый заказ имеет штрих-код, сканирование которого позволяет нам запускать действия в программе (мой коллега проделал великолепную работу по написанию приложения на React Native, если вам интересно).

Приложение показывает, сколько всего товаров вам осталось собрать и сколько вы уже собрали. Таким образом, разные работники могут одновременно работать над одним и тем же типом предметов.

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

Функция №1: ввод количества товаров из приложения

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

Функция №2: пакетная обработка похожих заказов для повышения эффективности

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

Эти две функции звучат как хороший продуманный UX, не так ли? Мы прекрасно покрываем крайние случаи (смятые штрих-коды) и повышаем эффективность за счет сокращения перемещений по складу.

Проблема: многие заказы не могли быть выполнены из-за отсутствия товаров.

Но у нас была и другая проблема. Часто при сортировке заказов в них отсутствовали позиции. Если при сортировке не хватает какого-то предприятия, нам теперь приходится перемещать товары обратно на склад (поскольку неполный заказ не мог быть выполнен), приходится обновлять инвентаризацию «задним числом», все это непросто. Это происходит не так часто, чтобы для этого был выделен отдельный штат работников, поэтому люди занимались этим на стороне, когда было время. Это был дорогостоящий беспорядок.

Проблема в том, что если вам нужно отобрать 50 одинаковых товаров, то часто легко пропустить один и вместо него отобрать 49, потому что вы не можете просто визуально проверить, что у вас правильный подсчет. Кроме того, сканирование 50 предметов — это утомительное занятие. Предметы хранятся близко к земле (из-за типа товаров, которыми торгует предприятие), поэтому вам приходится нагибаться (или вставать на колени) и бездумно сканировать что-то 50 раз.

Люди не глупы, они просто посчитают растения, затем введут их количество в приложении (поскольку знают, сколько их нужно собрать), и на этом все закончится, даже если штрихкоды не будут смазаны.

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

Решение: усложнить процесс комплектации

Шаг 1: сделать подборку менее эффективной

Первое «ухудшение» заключалось в том, чтобы сделать комплектацию партий менее эффективной, но более разнообразной. Вместо того чтобы пытаться делать большие партии с 50 одинаковыми товарами, мы теперь создаем партии с гораздо меньшим количеством одинаковых SKU. Это не только облегчает проверку правильности количества товаров, но и, хотя ходить по складу стало немного дольше, приятнее. Вместо того чтобы сканировать 50 товаров подряд, вы можете отсканировать 6, затем немного пройтись и размяться, а потом отсканировать еще 8. День гораздо меньше похож на рутину, а работники более бдительны.

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

Шаг 2: Убрать подсчет предметов из приложения

Вторым «ухудшением» было полное удаление подсчетов из приложения. Когда вы смотрите на список товаров, вы не видите, сколько товаров вам нужно забрать, и сколько вы уже забрали. Вы видите только зеленую или красную линию. Пока она не станет зеленой, вы должны продолжать собирать. Таким образом, вы не можете просто набрать необходимое количество после беглого подсчета. Можно сказать, что люди могут просто многократно сканировать один и тот же штрих-код, пока линия не станет зеленой, но люди не хотят играть в эту систему. Им просто нравится, когда их тело и мозг получают передышку и некоторое разнообразие.

Шаг 3: Требуйте, чтобы контролер отменял ввод штрих-кода

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

Думайте о проблеме, а не о программном обеспечении

Как мы видели в этом примере, у нас были прекрасно продуманные функции программного обеспечения. Мы отображали полную информацию о партии, и у нас был надлежащий UX для таких нестандартных ситуаций, как смятые штрихкоды. Но для решения проблемы (чтобы работники хорошо выполняли работу, не уставая умственно и физически) потребовалось сделать программное обеспечение «хуже».

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