Дизайн пользовательского интерфейса. Искусство мыть слона

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

Я обнаружил, что существует несколько простых правил поведения (можете считать их заповедями), позволяющих избежать низкой продуктивности. Разумеется, список этих правил неполон — составить его может только существо безгрешное, а сам я, безусловно, не таков. Но лучше что-то, чем вовсе ничего.

Улучшайте, а не делайте хорошо

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

Всё это оптический обман. На самом деле почти ничего не готово, а то, что таки готово, готово не потому, что оно действительно готово, а потому, что так получилось.

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

Это же соображение верно для монитора, стола и стула — разве что они ещё менее готовы, чем здание или блюдо. Монитор, стол и стул — товары массового шаблонного производства. Они производятся из года в год, поэтому их можно улучшать до бесконечности. Да, монитор уже готов — но только этот конкретный экземпляр и только для вас. Вполне возможно, что его производитель уже опознал несколько ошибок (или технологическая база улучшилась) — и уже продается новая, улучшенная модель. Причем здесь не идет речь о персональном опыте конкретного разработчика монитора — производитель может нанять другого инженера или дизайнера, и его навыки и мастерство позволят ещё немножко улучшить продукт.

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

Примеров тому множество.[5] Корпорация Toyota внедрила т. н. экономное производство, при котором, в частности, безостановочно улучшаются все стадии технологического цикла — неважно, сильно или слабо, лишь бы было постоянное улучшение. Sony не ставит перед своими дизайнерами задачи сделать хороший продукт — вместо этого дизайнеры непрерывно улучшают продукцию предыдущего года.

Но это примеры сознательного применения этого подхода. Даже если его не осознавать, он действует всё равно, хотя не всегда эффективно. Например, каждая новая версия плееров iPod была лучше предыдущих, хотя, судя по впечатлениям владельцев, каждая версия была форменным совершенством. Лучше становятся вообще все плееры, хотя те же славящиеся низким качеством дизайна корейские производители улучшаются несколько медленнее. И это при том, что конечные потребители могут заметить только улучшения потребительских свойств продукта. Например, для потребителя всё равно, что Sony за время производства игровой приставки PlayStation 3 успела вдвое сократить её себестоимость (в основном за счет сокращения числа деталей), — хотя для Sony это, безусловно, значимое и очень приятное достижение.[6]

Но, конечно, лучше этот подход всё-таки осознавать — т. е. признавать, что вам есть что улучшить и улучшить это надо — и использовать по максимуму. Если вы признаёте, что то, что вы делаете, никогда не будет готово до конца:

♦ Вам легче будет относиться к своей работе пессимистично (о пользе чего я буду говорить далее).

♦ Вы не будете тратить время на полировку того, что полировать ещё не нужно. Раз некоторые недостатки проекта можно обнаружить только после того, как он сделан до стадии неизменяемости (т. е. например, здание построено, а новая версия сайта выложена на рабочую площадку), полировать что-либо до посинения нужно только тогда, когда не осталось ничего менее готового. Например, непродуктивно полировать новую функцию программы, пока она ещё не выпущена и, соответственно, ещё не известно, как в действительности ей будут пользоваться. Проще и эффективнее просто реализовать эту функцию, выпустить продукт с ней, посмотреть на её реальную работу — и тогда уже эту функцию отполировать.

♦ Наконец, отношение к продукту как к неготовому позволяет ещё и избежать вечной беды IT-индустрии — гонки за новыми функциями (creeping featurism). Субъективно готовый продукт незачем улучшать, поэтому он просто становится больше (за счет функций). А вот субъективно неготовый — улучшать можно и нужно, т. е. не только что-то хорошее добавлять, но и плохое исправлять.

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

Относитесь к своей работе пессимистично

Очевидно, что через _{__впишите период времени__} когда выйдет новая версия сайта или программы, над которой вы сейчас работаете, текущее состояние продукта будет казаться вам убогоньким — новая-то версия будет лучше. А раз новая версия будет лучше, текущая версия плоха.

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

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

Самый простой способ достигнуть такого пессимизма — повесить над своим столом табличку со словами «Это можно сделать ещё лучше». Конечно, настроение она поначалу портит. Но качество работы — улучшает.

Стройте работу так, чтобы не думать о том, что именно вы могли забыть

Большая часть работы дизайнера интерфейсов, во всяком случае, по затраченному времени — это думание. Чем сильнее мы ускорим это думание, тем быстрее и производительнее начнем работать. Эта задача может показаться невыполнимой (как же, для этого нужно стать умнее, что явно невозможно), но на самом деле она вполне реалистична — для этого всего лишь нужно изъять из нашего думания непроизводительные потери.

На мой взгляд, главной такой потерей является вопрос «О чём я забыл(а)?». Хороший интерфейс — явление многофакторное, об одном факторе вовремя не вспомнишь и всё придётся переделывать. Моё главное такое «достижение» было, когда я, нарисовавши прекрасный интерфейс главной страницы сайта, выверенный до мельчайших деталей, обнаружил, что забыл оставить в нём место для поля поискового запроса. Вуаля — целый день работы насмарку. Ошибка в пятисекундном рассуждении привела к совершенно неприличному объему потерянного времени.

Самый простой способ избавиться от таких потерь — всё записывать. Если перед тем, как рисовать интерфейс, вы напишете список всех его объектов — вероятность ошибки снижается на порядок. Если вместо того, чтобы долго разглядывать свеженарисованный интерфейс в поиске ошибок, просто прогнать его по контрольному списку — скорость проверки вырастет на порядок. Если записать перед началом проектирования интерфейса его желаемые эргономические качества (такой перечень вряд ли будет больше абзаца), вы не забудете о них в процессе работы, а значит, все их и обеспечите (по мере сил).

Запись всего и вся — не единственный вариант решения. Если вы не умеете быстро писать, для вас он может оказаться неэффективным. Главное — построить свою работу так, чтобы вопрос «что забыто?» вообще не возникал. Например, через перманентные переделки.

Переделывайте, а не думайте

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

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

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

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

Пара примеров такого рода работы из моей практики:

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

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

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

На мой взгляд, сейчас лучшей такой технологией является сначала рисование прототипа на бумаге, а затем — финализация прототипа в Adobe InDesign.[7] Изначально это верстальная система для полиграфии, так что использовать её для прототипирования интерфейсов — всё равно что забивать гвозди микроскопом. Но почему бы не забивать, если микроскоп ухватистый, а стоит не дороже молотка?

По крайней мере, сейчас InDesign лучше альтернатив — он легче в изучении, чем специализированные средства разработки, к тому же, хоть и уступая им в скорости создания первой версии, лидирует в скорости модификаций. Наконец, InDesign, в отличие от средств разработки вроде Adobe Dreamweaver или Microsoft Visual Studio, универсален — в нем можно запрототипировать любой графический интерфейс, будь то интерфейс программы или сайта.

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

Начинайте работу с самой больной части

Иногда существуют причины, когда важно оценить что-то полностью, в целом. Например, ресторанный критик должен оценить в ресторане всё: и обстановку, и обслуживание, и меню (и ещё много разных факторов). Но посетитель ресторана, решая, остаться в этом ресторане или вернуться ли туда ещё раз, оценивает ресторан гораздо проще — решение принимается по худшей составляющей, а не по среднему баллу. Соответственно, ресторатор, пытающийся улучшить своё заведение, должен, безусловно, улучшать в нём всё — но начинать ему стоит с самой худшей составляющей, просто потому, что её исправление принесёт максимальный эффект.

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

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

Поймите меня правильно — я не берусь утверждать, что гг. дизайнеры делали то, что делать было вовсе не нужно. Может, и нужно. Но первое впечатление заказчика, который приходит к дизайнеру именно потому, что у него что-то болит, было резко отрицательным. Вам бы тоже не понравилось, если бы вы пришли к хирургу вырезать болезненный нарыв, а он бы сначала отправил вас к окулисту выписывать очки (даже если бы вы действительно в них нуждались).

Соответственно, каждый проект надо начинать с определения того, что у интерфейса болит. Нужно как минимум расспрашивать заказчика, как максимум — тестировать, опрашивать пользователей и т. п. А затем формулировать список проблем, которые вы собираетесь решить своей работой. Если вы этого не сделаете, а сразу приступите к работе над интерфейсом, вы, несомненно, обидите заказчика, что непрофессионально.[8]

Не ведите себя как эксперт

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

Видно, что-то не так с этим знанием.

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

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

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

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

И главное — надо делать, а не просто пассивно знать. Например, практически общеизвестно т. н. «правило 7±2», гласящее, что раз емкость кратковременной памяти человека редко бывает большей девяти элементов, делать меню большего размера неэффективно.[9] Трудно прочесть хоть одну книгу о дизайне интерфейсов и не наткнуться на него. Но вот вы его узнали, и что же? Станут ваши интерфейсы теперь самопроизвольно лучше или нет? Нет, не станут. Чтобы это правило действительно помогало, вам понадобится включить правило «Ни в одном меню не более семи элементов» в свой контрольный список проверки интерфейсов и в дальнейшем не лениться проверять свои интерфейсы по этому контрольному списку. И без этой работы ваше абстрактное знание не стоит и гроша.

Не философствуйте; общих ответов на общие вопросы всё равно нет

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

♦ Универсальных решений, работающих всегда, почти нет. Существуют общие законы, следование которым в интерфейсе всегда продуктивно (например, законы Фиттса и Хика).[10] К сожалению, открыта (и тем более доказана) только малая часть из них (собственно, только законы Фиттса и Хика), так что не будет преувеличением сказать, что мы, собственно, ничего про них и не знаем. Интересно при этом то, что все эти законы не говорят про конкретный интерфейс ничего — они описывают человека и особенности его восприятия/поведения, а не сами интерфейсы. Уверен, что так и будет продолжаться; что никогда человеческий разум не создаст, например, Общей Теории Корзины Покупок или Универсальной Парадигмы Чекбокса. А значит, не может быть и веры в возможность общих ответов на общие вопросы про интерфейс.

♦ Доказать работоспособность интерфейсного решения может только тестирование, а никак не интеллектуальные экзерсисы. Обилие факторов, влияющих на работоспособность интерфейсного решения, не позволяет ограничиться простым рассуждением при поиске общих ответов — рассуждение неизбежно будет длиннющим. А если рассуждение длительное, вероятность ошибиться возрастает на порядки. Зачем искать ответы, заведомо зная, что они могут оказаться неверными? А вот если вы интересуетесь конкретным вопросом про конкретный интерфейс — всё как раз просто. Протестируйте его. Если тестирование покажет, что интерфейс работает, значит, он действительно работает.

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

Подводя итог, замечу, что, на мой взгляд, думание на общие, отвлеченные темы — занятие полезное, но не особо продуктивное. Гораздо продуктивнее задавать себе вопросы про конкретный интерфейс, а не про интерфейсы вообще.

Занимайтесь только той оптимизацией интерфейса, которая улучшает продукт

Вот диалоговое окно со списком закладок из Microsoft® Word 2007. Это окно не изменялось уже более десяти лет; точно таким же оно было в Word 97.

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

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

Вот вам задание: найдите остальные интерфейсные проблемы этого окна (а пока вы ищете, не переходите на следующую страницу).

А теперь печальный факт — независимо от того, сколько проблем вы насчитали (лично я насчитал 4 мелких проблемы, не считая той, о которой шла речь на предыдущем слайде), их число незначимо. Просто потому, что все проблемы этого окна незначимы.

Вот простая «формула» для оценки результата работы дизайнера интерфейсов:

Итоговое улучшение интерфейса = % пользователей затронутого фрагмента интерфейса * коэффициент важности этого типа аудитории * заметность улучшения качества интерфейса

Разберем эти составляющие:

«% пользователей затронутого фрагмента интерфейса» определяет частотность взаимодействия с этим куском интерфейса и количество пользователей соответствующей функциональности. Например, все пользователи сохраняют документы в Word, но только некоторые пользователи пишут в нём макросы.

«Коэффициент важности этого типа аудитории» — показатель того, насколько значим для успеха продукта тот тип аудитории, который взаимодействует с искомым фрагментом интерфейса. Например, можно постановить, что:

♦ обычные пользователи получают коэффициент!

♦ спорадические пользователи, которые сами не покупают продукт (например, дети и любители пиратских копий), получают 0,5

♦ эксперты, влияющие на факт покупки продукта другими пользователями, получают 1,5

♦ начальство, подписывающее платежку магазину, получает коэффициент 5.

«Заметность улучшения качества интерфейса» — показатель улучшения интерфейса. Если пользователь, впервые увидевший новый интерфейс, начинает кричать от восторга, это одно. Если же пользователь просто думает про себя «Ну, давно пора было это сделать», это другое. А что, если пользователь просто не замечает улучшения? Предположим, что 1 балл — это безразличная реакция пользователей на улучшение, а 5 баллов — просто-таки пароксизмы восторга.

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

♦ Процент пользователей затронутого фрагмента интерфейса здесь совершенно мизерный, вероятно, не более процента пользователей вообще знают про это диалоговое окно. Ставим коэффициент 0,01.

♦ А вот коэффициент важности этого типа аудитории, наоборот, велик, поскольку это именно эксперты. Ставим 1,5.

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

Получается, что итоговое улучшение продукта равняется 0,0165.[11] Явно очень и очень мало. Разумеется, это число совершенно волюнтаристское, коэффициенты я назначал как бог на душу положит — но число говорит само за себя.

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

Конечно, в идеальном мире (где всё сферическое и повсюду сплошной вакуум) это улучшение оправданно — много маленьких улучшений эквивалентны одному большому, так что всё равно что делать, если в результате станет лучше.

Но мир, в котором мы живем, не идеальный. В нём есть сроки/бюджет, начальство и маркетинг:

♦ Если сроки/бюджет сжаты (а они сжаты всегда), разумнее тратить время на работу, обладающую возможно большим КПД. Любой проект по оптимизации интерфейса сравнительно велик — он занимает недели работы и десятки|сотни тысяч рублей. Времени просто не хватает на работу, не дающую значительной отдачи. Думаю, никто не будет спорить, что в Microsoft Word был (и есть) резерв для улучшения, более значительный, чем окно закладок. Собственно говоря, разработчики Word уже доказали это, полностью переделав (и сильно, на мой взгляд, улучшив) систему меню в Word 2007.

♦ Любое начальство по своей природе будет запрещать работу, которая не дает заметного изменения — просто потому, что малозаметные изменения начальству труднее проконтролировать. Представьте, что разработчик пришел к своему менеджеру отчитываться о своей работе и говорит «Я потратил полдня и улучшил окно закладок». Менеджер смотрит и не видит особых изменений. «Он меня дурачит!» — понимает менеджер и лишает разработчика премии.

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

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

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

Вот пара примеров из моей собственной практики (оба — трагичные):

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

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

Здесь я одумался и перестал делать то, что нравится, а во всё освободившееся время теперь стараюсь делать то, что нужно. Советую поступать так и вам. Начиная какую-то работу, следует спрашивать себя, улучшит ли это продажи, т. е. сделает ли эта работа лучше не только интерфейс, но и продукт.

Если вы профессионал, ведите себя профессионально

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

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

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

— У вас ярко выраженный случай синдрома Маркса-Спенсера, осложненный олигоптеризмом. Необходима немедленная операция. Если мы проведем её прямо сейчас, можете быть спокойны — в таких случаях выздоровление практически гарантированно.

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

Легче, впрочем, сказать, чем сделать. Постоянно ловишь себя на том, что ведешь себя непрофессионально, например:

♦ используешь непрофессиональную лексику

♦ гарантируешь излечение

♦ потворствуешь пациенту.

Разберу эти пункты подробнее.

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

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

Во всех этих случаях единственно профессиональный метод наименования — пользоваться глоссарием. Глоссарий, в свою очередь, такая штука, что кто первый встал, того и тапки. Первой встала компания Microsoft — во всех их продуктах соответствующие понятия называются именно так, как написано выше (флажок, вкладка и т. п.), и что ещё важнее, называются именно так с незапамятных времен. Нравятся вам эти переводы или нет — но они привычны подавляющему большинству отечественных пользователей, а все другие наименования — нет.

Другое дело слово «юзер». Его использование — верный признак снисходительного отношения к пользователям (я, дескать, лучше этих мужланов, то бишь юзеров). На мой взгляд, при таком подходе сделать что-то хорошее этим пользователям несколько затруднительно.[12]

Знание терминологии — навык приобретённый, а не врождённый. Соответственно, все дизайнеры поначалу говорят и пишут непрофессионально. Лечение, впрочем, просто, хоть и утомительно — надо взять глоссарий Microsoft и заучить его наизусть (очень помогает работать только на локализованных версиях программ, если они есть).

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

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

В этом смысле лучше даже не говорить, что в вашей практике были громадные улучшения. Ну, были. Но если вы это говорите, вам придется объяснять почти всем следующим клиентам, почему в их случае вам не удалось добиться такого же улучшения (они-то выбрали вас именно потому, что вы такого улучшения когда-то достигли). Вдобавок вам придется объясняться ещё и со своими коллегами и конкурентами — придется очень убедительно доказывать, что улучшения добились именно вы, а не, например, дизайнер-график (он ведь тоже работал над интерфейсом новой версии). Если вы этого не сделаете, вам будут обеспечены диагноз «трепло» и презрение.[13]

Поэтому ни в коем случае нельзя обещать клиенту значительных улучшений интерфейса. Процентов 10–15 ещё можно (этого можно достичь почти всегда), но не больше. Разумеется, нужно стараться добиться большего, но…

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

Если вы выписали больному таблетки, а он их не ест — это ваши проблемы. Больной-то уверен, что раз он уже побывал у врача, излечение ему обеспечено. И когда ему станет хуже, придет к вам ругаться (если не помрет; в этом случае придут родственники). Конечно, вашей вины в том, что пациент не принимает лекарства, нет никакой. Но проблемы будут и без вины.

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

Необходимо явно и недвусмысленно объяснять таким заказчикам, что вам лично глубоко наплевать, будут они или не будут следовать вашим рекомендациям. Но если они не будут, вся ответственность ляжет на них самих и только на них, а вы, в свою очередь, ограничите свою роль получением оплаты за проект. Например, если вы обнаружили, что заказчик нанял дизайнера-графика, который портит ваш проект, вы должны немедленно отправиться к заказчику и честно сказать, что дизайнер халтурит по-черному и его нужно немедленно сменить или по крайней мере дать ему пару раз по голове.[14] Да, вы испортите отношения с заказчиком — но вы испортите их в любом случае, когда выйдет продукт с убогим дизайном и за провал которого будут винить и вас. Однако если вы поссоритесь с клиентом сразу, будет, по крайней мере, шанс, что клиент выживет и впоследствии сможет понять вашу правоту. Если же вы будете ждать, шансов на это у вас не будет.

Не занимайтесь тем, что у вас всё равно не получается

Чтобы заниматься чем-то хорошо, нужен талант или, по крайней мере, предпосылки. Можно вполне профессионально рыть канавы, не имея особой мускулатуры, но эта работа не будет особенно эффективной (к счастью, от рытья канав мускулы нарастают очень быстро). Это, правда, сравнительно простая работа. Гораздо сложнее играть на рояле, если у вас нет слуха, с детства неправильно поставлены руки или же просто тремор такой, что вы и стакан-то держать не можете. Ещё хуже, если вы ленивы и нелюбопытны — тогда вы не сможете даже научиться играть лучше, не то что играть хорошо.[15]

Это верно и для дизайна интерфейсов — если у вас нет таланта или хотя бы предпосылок, вы никогда не сможете делать это хорошо. Талант вы сможете обнаружить в себе со временем (или не обнаружить), о нем мне сказать особо нечего. Но о предпосылках сказать можно многое. Невозможно научиться делать роскошные интерфейсы, если вы:

♦ не умеете говорить и, особенно, слушать

♦ не имеете вкуса

♦ не умеете писать

♦ не умеете долго думать логично

♦ нелюбопытны.

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

Проблема с этим утверждением заключается в том, что, подобно тому, как все уверены, что у них есть чувство юмора, все уверены, что с эмпатией у них всё очень хорошо.[16]

Проверьте себя. Если вы не согласны (полностью или частично) с утверждениями:

…у вас, по всей видимости, проблемы с эмпатией. Придя на интервью с заказчиком, вы, скорее всего, слышите себя (а не заказчика), поскольку у вас нет стимула узнать что-то о другом человеке (я предполагаю, что для того, чтобы что-то узнать, нужно сначала признать, что это что-то ещё неизвестно). Это преодолимо, нужно всего лишь регулярно и методично напоминать себе, что другие люди — именно что другие. Кроме того, великолепно помогает тренировке эмпатии присутствие при юзабилити-тестировании своего интерфейса (можно смотреть записи его же; даже записи тестов чужих интерфейсов неплохо помогают тренировать эмпатию).[17]

Чтобы появилось само понятие красивого человека, большинство людей должно быть некрасивыми. Это же верно и для вкуса, с той только поправкой, что красота во многом есть свойство врождённое, а вкус — всегда приобретённый, никто не рождается с развитым чувством прекрасного. Его развитие занимает годы, и эти годы не просто надо прожить, но тратить время и усилия на развитие своего вкуса.[18]

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

Проверьте себя. Если вы:

♦ в последние годы не были ни на одной художественной выставке

♦ не купили в прошлом хотя бы трёх альбомов по искусству

♦ не можете назвать хотя бы пять художников, которых вы особенно любите, и не можете объяснить, за что именно вы их любите

♦ не знаете названий хотя бы пяти архитектурных стилей и не можете объяснить, чем они отличаются друг от друга

…по-видимому, вы никогда не старались развить свой художественный вкус и, соответственно, у вас его нет. Идите в музей, прочтите несколько книг по искусствоведению, купите абонемент в консерваторию и т. п.

Мысли имеют неприятное обыкновение из чётких и ясных становиться неоднозначными и неполными (а зачастую и самопротиворечивыми), стоит их только записать. Объясняется это просто — пока они ещё в голове, многие выводы, не говоря уж о противоречиях, попросту не видны. На бумаге же проблемы проступают немедленно.

Согласно Федору Тютчеву, мысль изречённая есть ложь. Мысль записанная тоже может быть ложью, но ложь эта, по крайней мере, не гарантированная, как в случае мысли высказанной.

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

Проверьте себя. В 2000 знаков опишите, что вы видите вокруг в этот самый момент, отмечая самое замечательное в том, что вы видите. Покажите текст кому-нибудь, кто, по вашему мнению, хорошо «знает русского языка». Если задание далось вам с большим трудом или знаток языка раскритиковал его в пух и прах, поздравляю — вы не писатель. Купите пару книг по редактуре (см. раздел Рекомендуемая литература) и практикуйтесь до посинения. Лично я научился хоть как-то писать только после семисот тысяч написанных знаков.

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

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

Проверьте себя. Найдите какую-нибудь книгу логических задач (особо рекомендую книги Раймонда Смаллиана) и попробуйте решать их, не отвлекаясь, не менее полутора часов подряд. Если дело не идет — найдите ещё десяток таких книг и решайте, решайте, решайте. Интеллектуальный марафон не повредит.

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

Проверьте себя. Если вы:

♦ не знаете, кто такие Джозайа Веджвуд и Раймонд Лоуи

♦ не знаете, что такое интерлиньяж

♦ не можете перечислить хотя бы пять интерфейсных решений, которые в Windows лучше по сравнению с MacOS (и обратно)

…у вас скоро будут проблемы с полимерами (или уже). Решение очевидно: поставьте себе за цель каждый месяц читать хотя бы одну книгу по дизайну. Через год сами поймете, как развиваться дальше.

Подводя итог — все эти недостатки можно преодолеть (теоретически), но это потребует нешуточных усилий. Большинство людей страдают от этих недостатков, так что чисто статистически можно предположить, что они есть и у вас. Если вы не сможете их исправить, что ж, эта книга не пойдет вам на пользу — всё равно будете делать ерунду. Уж лучше заняться чем-нибудь другим.

Признайте, что вы перманентно и неизбежно ошибаетесь

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

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

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

♦ воспринимает в интерфейсе

♦ думает

♦ хочет добиться.

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

Да, многое предсказуемо. Гештальт-психология, к примеру, узнала многое о восприятии. Но знаем мы по-прежнему очень мало. И непохоже, что в обозримое время узнаем достаточно, что, к примеру, появится чёткая и доступная практику Теория, Предсказывающая Любое Поведение Человека Или Группы Людей В Определенных Ситуациях.

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

Однако рано или поздно наступает момент, когда переделки интерфейса лечат часть эргономических проблем, но создают примерно столько же проблем новых (это отчетливо видно на любых зрелых продуктах с большим количеством версий; например, на программах из Microsoft Office). В такой ситуации надо что-то делать. На мой взгляд, необходимо:

1 Признать, что интерфейс плох и будет плох, потому что плох я, дизайнер.

2 Начать интерфейсы тестировать.

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

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

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

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

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

У этого подхода, впрочем, есть два недостатка:

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

♦ Из одного только объема продаж невозможно узнать, что именно плохо — слишком уж много факторов (цена, реклама, работа службы продаж, графический дизайн и т. д.) влияет на успех, выделить в (не) успехе сугубо роль интерфейса нипочем не получится.

Так что лучше уж тестировать.

Я давно уже мечтал написать главу из одного единственного предложения, но не удержался вам об этом сообщить. Так что предложений тут три. Узнать почти всё о юзабилити-тестировании вы можете из моей статьи Юзабилити-тестирование по дешевке.