Объяснение закона сохранения сложности

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

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

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

Закон сохранения сложности, также называемый законом Теслера, гласит:

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

- Ларри Теслер

В середине 1980-х годов, работая в Xerox PARC, Ларри Теслер понял, что то, как пользователь взаимодействует с приложением, так же важно, как и то, что приложение делает. Книга Дэна Саффера «Проектирование для взаимодействия» включает интервью с Теслером. В книге Теслер объясняет, как он придумал закон сохранения сложности:

На заре нашей деятельности, когда я работал в Xerox PARC, идея единообразия пользовательского интерфейса была новой и противоречивой. Многие из нас поняли, что согласованность принесет пользу не только пользователям, но и разработчикам, поскольку стандарты можно инкапсулировать в общие библиотеки программного обеспечения. Мы выдвинули экономический аргумент: если мы установим стандарты и будем поощрять последовательность, мы сможем сократить время выхода на рынок и размер кода.

Позже Ларри присоединился к Apple и работал над разработкой объектно-ориентированной среды MacApp, там он формализовал свои взгляды на сложность и программное обеспечение:

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

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

ОЦЕНКА ЦЕННОСТИ (ИЛИ СТОИМОСТИ) ДЛЯ ПОЛЬЗОВАТЕЛЯ

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

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

• Средняя частота в неделю, с которой пользователь сталкивается с рассматриваемой сложностью
• Количество активных пользователей в неделю
• Ценность/стоимость — единица измерения, показывающая, что получит один пользователь от изменения или затрат, понесенных пользователями из-за рассматриваемой сложности.

Например, предположим, что пользователи сталкиваются со сложностью, которую мы можем устранить, три раза в неделю, в неделю имеется 1 000 000 активных пользователей, и допустим, эта сложность обходится пользователям в 0,5 минуты за встречу. Рассчитаем 3 * 1 000 000 * 0,5 = 1 500 000 секунд или 25 000 минут, или 416 часов, или чуть более 17 дней. Более того, это всего лишь показатель времени, возвращенного пользователям за одну неделю.

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

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

УПРОЩЕНИЕ

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

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

Автор: Майкл Каллея — продуктовый стратег/дизайнер, обладающий опытом разработки ориентированных на пользователя решений, которые приносят ощутимую пользу и радуют пользователей.