Добрый день, уважаемые хабравчане! Продолжаю радовать вас уникальными статьями по пользовательским интерфейсам с живыми примерами на русском языке. Сегодня мы будем обсуждать серебряную пулю разработки программного обеспечения — настройки приложений.
Что такое настройки, все себе более или менее представляют. Любой пользователь компьютера рано или поздно с ними сталкивается. Только не всегда победителем из этого столкновения выходит пользователь. Основных проблем, с которыми приходится иметь дело, три: нужную настройку трудно найти, нужной настройки нет, и не понятно, что делает та или иная настройка.
Чтобы разобраться, давайте задумаемся, откуда берутся настройки? Теоретически, настройки — это способ для разработчика приспособить программу под разные сценарии использования. Пользователи разные, одному нужно одно, другому другое, и если различия в сценариях незначительные, выбор между ними отдается на откуп пользователю. Отсюда следует, что чтобы сделать правильный экран настроек, надо знать цели и задачи пользователей. Это в теории. Что же происходит на практике?
Основная проблема — непонимание целей и задач пользователя — приводит к тому, что разработчик (в широком смысле — компания, производящая программный продукт) принимает неверное решение по поводу той или иной настройки: добавляет ненужное и не добавляет нужного. Нехватка настроек — плохо, но хотя бы не фатально, после релиза пользователи поправят — начнут требовать настройку. А с добавлением лишних настроек уже интереснее. Назвав настройки серебряной пулей ПО в начале статьи, я имел в виду следующее распространенное заблуждение: считается, что если для реализации некоторой функциональности есть несколько способов, и не ясно, какой выбрать, то выбор следует дать пользователю с помощью настройки. Кажется, что такой вариант беспроигрышен, ведь что бы пользователю ни было нужно, он сам сможет выбрать нужный способ, а с нас взятки гладки. Давайте разбираться в этом заблуждении подробно.
Во-первых, из нескольких вариантов не ясно, какой выбрать. Тут нужно сделать одну простую вещь — задуматься о пользователях. «Каким вариантом они будут пользоваться? Будет ли им достаточно только первого варианта? Только второго?» — это простые и очевидные вопросы, однако меня приводит в ужас, что даже когда на них можно получить ответ (весьма часто), в реальности люди, отвечающие за интерфейс продукта, их просто не задают, ведь легче добавить настройку, это снимает ответственность и для этого не надо думать. По уму же, если варианты эквивалентны с точки зрения использования, то нужно выбрать один, реализовать только его и не парить мозг пользователям (на эту тему хорошо рассуждают в [1]), а настройку делать, если варианты разные с точки зрения использования и пользователям будут нужны оба. Кстати, отвечая для себя на этот вопрос, можно развеять идеалистическую мечту сделать одну программу для всех пользователей — разные пользователи и разные задачи часто требуют взаимоисключающих решений, и тут уже настройки не спасут — настолько разные им нужны продукты.
Размышляя об этой проблеме, я осознал, что в жизни присутствует интересный саморегулирующий механизм: если в компании есть человек, понимающий в проектировании интерфейсов, или проводилось хорошее исследование пользователей, то естественным образом добавят только нужные настройки. Иначе разработчик страхуется и добавляет столько настроек, сколько сможет придумать, и, как ни странно, именно это дает возможность воспользоваться этим продуктом (подобрав нужную комбинацию настроек) тем людям, кому продукт действительно нужен, вопреки отсутствию какого-либо проектирования интерфейса.
Иллюстрация к проблеме (знакомая ситуация, не правда ли?):
Во-вторых, про беспроигрышность. У каждой настройки есть своя цена. Ковыряние в настройках в задачи пользователя не входит, следовательно время, потраченное на работу с настройками, пользователь справедливо записывает как потраченное впустую, и ответственность за то, что пользователь тратит это время, лежит на разработчике продукта. Поэтому нужно стремиться это время минимизировать — а из психологии мы знаем, что время реакции при выборе из некоторого числа альтернативных сигналов возрастает пропорционально логарифму от их числа (Закон Хика). То есть, чем больше настроек, тем сложнее выбрать нужную. Ну и скорость чтения у человека сильно ограничена (5 слов в секунду примерно).
Иллюстрация:
В-третьих, казалось бы, разработчик должен сам стремиться уменьшать количество настроек, ведь на каждую из них нужно разработать и поддерживать альтернативную ветку кода, что означает дополнительные трудозатраты и в конечном итоге выльется в деньги. Однако это соображение часто игнорируется в пользу упрощения принятия решений — я назову это явление Великим Парадоксом Настроек.
С мифом о серебрянной пуле встретиться легко. Почти при любом обсуждении интерфейса рано или поздно всплывает предложение «а давайте сделаем это настройкой» (я не стал далеко ходить, погуглил «добавить опцию site:habrahabr.ru» и нашел, например: раз, два, три и т.д.). Думаю, вы и сами много раз сталкивались как с этим мифом, так и с результатом его применения в программных продуктах.
Иллюстрация:
Тоже иллюстрация (казалось бы, всего лишь программа выключения компьютера):
Есть еще одна проблема, связанная с настройками, в начале статьи я обозначил ее как «не понятно, что делает та или иная настройка». Имеется в виду проблема несоответствия модели реализации (implementation model) и мысленной модели пользователя (user's mental model, к сожалению, нет под рукой русского перевода [2], так что перевод терминов мой). У человека, пользующегося программой, есть представление о том, как она работает. Это называется мысленной моделью пользователя. Штука в том, что это представление не обязано соответствовать (и не соответствует) тому, как программа на самом деле работает (модель реализации). Правило состоит в том, что интерфейс (в том числе и настройки) должен быть построен на основе мысленной модели пользователя, а не на модели реализации, иначе у пользователей начнутся сложности. Например, когда я перетаскиваю картинку из Safari в Mail, создается письмо с картинкой. В моей мысленной модели картинка была передана из одной программы в другую. Если бы в Safari была настройка «папка для временных файлов при перетаскивании», то я бы не понял ее смысл, потому что это уже подробности из модели реализации, которых в моей мысленной модели нет.
Иллюстрация (выдуманная):
Иллюстрация (реальная):
Проблема раздутости настроек mail.ru очевидна, но мы рассмотрим их с точки зрения моделей пользователя/реализации. У них там три (!) разных места, в которых можно указать город/часовой пояс. Насколько я понимаю, причина в том, что у них есть три модуля, которым эта информация нужна (модель реализации). Однако в моей мысленной модели mail.ru — это интерфейс моего личного почтового ящика, а я все-таки живу в одном городе и не понимаю, почему должен указывать эту информацию трижды. Ну и до кучи, даже если указать город во всех трех местах, то время получения письма все равно будет показываться московское — тот случай, когда нужной настройки нет.
Подведем итоги. Экран настроек — это часть интерфейса вашей программы, следовательно, он должен подчиняться всем законам интерфейса. Его нужно проектировать с учетом целей и задач пользователей. Помните, что общение с настройками не входит в задачи пользователя, и старайтесь время этого общения минимизировать, оставляя только нужные вашим пользователям настройки. Наконец, проектируя настройки, делайте это в терминах задач пользователей, их мысленной модели.
P.S. Если у кого-то найдутся примеры невероятно плохо спроектированных настроек, буду рад увидеть их в комментариях (скриншоты приветствуются вдвойне).
Ссылки:
Что такое настройки, все себе более или менее представляют. Любой пользователь компьютера рано или поздно с ними сталкивается. Только не всегда победителем из этого столкновения выходит пользователь. Основных проблем, с которыми приходится иметь дело, три: нужную настройку трудно найти, нужной настройки нет, и не понятно, что делает та или иная настройка.
Чтобы разобраться, давайте задумаемся, откуда берутся настройки? Теоретически, настройки — это способ для разработчика приспособить программу под разные сценарии использования. Пользователи разные, одному нужно одно, другому другое, и если различия в сценариях незначительные, выбор между ними отдается на откуп пользователю. Отсюда следует, что чтобы сделать правильный экран настроек, надо знать цели и задачи пользователей. Это в теории. Что же происходит на практике?
Основная проблема — непонимание целей и задач пользователя — приводит к тому, что разработчик (в широком смысле — компания, производящая программный продукт) принимает неверное решение по поводу той или иной настройки: добавляет ненужное и не добавляет нужного. Нехватка настроек — плохо, но хотя бы не фатально, после релиза пользователи поправят — начнут требовать настройку. А с добавлением лишних настроек уже интереснее. Назвав настройки серебряной пулей ПО в начале статьи, я имел в виду следующее распространенное заблуждение: считается, что если для реализации некоторой функциональности есть несколько способов, и не ясно, какой выбрать, то выбор следует дать пользователю с помощью настройки. Кажется, что такой вариант беспроигрышен, ведь что бы пользователю ни было нужно, он сам сможет выбрать нужный способ, а с нас взятки гладки. Давайте разбираться в этом заблуждении подробно.
Во-первых, из нескольких вариантов не ясно, какой выбрать. Тут нужно сделать одну простую вещь — задуматься о пользователях. «Каким вариантом они будут пользоваться? Будет ли им достаточно только первого варианта? Только второго?» — это простые и очевидные вопросы, однако меня приводит в ужас, что даже когда на них можно получить ответ (весьма часто), в реальности люди, отвечающие за интерфейс продукта, их просто не задают, ведь легче добавить настройку, это снимает ответственность и для этого не надо думать. По уму же, если варианты эквивалентны с точки зрения использования, то нужно выбрать один, реализовать только его и не парить мозг пользователям (на эту тему хорошо рассуждают в [1]), а настройку делать, если варианты разные с точки зрения использования и пользователям будут нужны оба. Кстати, отвечая для себя на этот вопрос, можно развеять идеалистическую мечту сделать одну программу для всех пользователей — разные пользователи и разные задачи часто требуют взаимоисключающих решений, и тут уже настройки не спасут — настолько разные им нужны продукты.
Размышляя об этой проблеме, я осознал, что в жизни присутствует интересный саморегулирующий механизм: если в компании есть человек, понимающий в проектировании интерфейсов, или проводилось хорошее исследование пользователей, то естественным образом добавят только нужные настройки. Иначе разработчик страхуется и добавляет столько настроек, сколько сможет придумать, и, как ни странно, именно это дает возможность воспользоваться этим продуктом (подобрав нужную комбинацию настроек) тем людям, кому продукт действительно нужен, вопреки отсутствию какого-либо проектирования интерфейса.
Иллюстрация к проблеме (знакомая ситуация, не правда ли?):
Во-вторых, про беспроигрышность. У каждой настройки есть своя цена. Ковыряние в настройках в задачи пользователя не входит, следовательно время, потраченное на работу с настройками, пользователь справедливо записывает как потраченное впустую, и ответственность за то, что пользователь тратит это время, лежит на разработчике продукта. Поэтому нужно стремиться это время минимизировать — а из психологии мы знаем, что время реакции при выборе из некоторого числа альтернативных сигналов возрастает пропорционально логарифму от их числа (Закон Хика). То есть, чем больше настроек, тем сложнее выбрать нужную. Ну и скорость чтения у человека сильно ограничена (5 слов в секунду примерно).
Иллюстрация:
В-третьих, казалось бы, разработчик должен сам стремиться уменьшать количество настроек, ведь на каждую из них нужно разработать и поддерживать альтернативную ветку кода, что означает дополнительные трудозатраты и в конечном итоге выльется в деньги. Однако это соображение часто игнорируется в пользу упрощения принятия решений — я назову это явление Великим Парадоксом Настроек.
С мифом о серебрянной пуле встретиться легко. Почти при любом обсуждении интерфейса рано или поздно всплывает предложение «а давайте сделаем это настройкой» (я не стал далеко ходить, погуглил «добавить опцию site:habrahabr.ru» и нашел, например: раз, два, три и т.д.). Думаю, вы и сами много раз сталкивались как с этим мифом, так и с результатом его применения в программных продуктах.
Иллюстрация:
Тоже иллюстрация (казалось бы, всего лишь программа выключения компьютера):
Есть еще одна проблема, связанная с настройками, в начале статьи я обозначил ее как «не понятно, что делает та или иная настройка». Имеется в виду проблема несоответствия модели реализации (implementation model) и мысленной модели пользователя (user's mental model, к сожалению, нет под рукой русского перевода [2], так что перевод терминов мой). У человека, пользующегося программой, есть представление о том, как она работает. Это называется мысленной моделью пользователя. Штука в том, что это представление не обязано соответствовать (и не соответствует) тому, как программа на самом деле работает (модель реализации). Правило состоит в том, что интерфейс (в том числе и настройки) должен быть построен на основе мысленной модели пользователя, а не на модели реализации, иначе у пользователей начнутся сложности. Например, когда я перетаскиваю картинку из Safari в Mail, создается письмо с картинкой. В моей мысленной модели картинка была передана из одной программы в другую. Если бы в Safari была настройка «папка для временных файлов при перетаскивании», то я бы не понял ее смысл, потому что это уже подробности из модели реализации, которых в моей мысленной модели нет.
Иллюстрация (выдуманная):
Иллюстрация (реальная):
Проблема раздутости настроек mail.ru очевидна, но мы рассмотрим их с точки зрения моделей пользователя/реализации. У них там три (!) разных места, в которых можно указать город/часовой пояс. Насколько я понимаю, причина в том, что у них есть три модуля, которым эта информация нужна (модель реализации). Однако в моей мысленной модели mail.ru — это интерфейс моего личного почтового ящика, а я все-таки живу в одном городе и не понимаю, почему должен указывать эту информацию трижды. Ну и до кучи, даже если указать город во всех трех местах, то время получения письма все равно будет показываться московское — тот случай, когда нужной настройки нет.
Подведем итоги. Экран настроек — это часть интерфейса вашей программы, следовательно, он должен подчиняться всем законам интерфейса. Его нужно проектировать с учетом целей и задач пользователей. Помните, что общение с настройками не входит в задачи пользователя, и старайтесь время этого общения минимизировать, оставляя только нужные вашим пользователям настройки. Наконец, проектируя настройки, делайте это в терминах задач пользователей, их мысленной модели.
P.S. Если у кого-то найдутся примеры невероятно плохо спроектированных настроек, буду рад увидеть их в комментариях (скриншоты приветствуются вдвойне).
Ссылки:
- Getting Real by 37signals
- Алан Купер об интерфейсе. Основы проектирования взаимодействия. Символ-Плюс, 2009 г.
- Комикс OK/Cancel отсюда
- Часть примеров из топика на stackoverflow.com Worst UI You’ve Ever Used
