В рамках серии внутренних образовательных семинаров у нас выступила Таня Мисютина с лекцией «Об интерфейсе».

Основы проектирования интерфейсов

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

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

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

Что такое интерфейс?

Раз уж мы с вами говорим сегодня об интерфейсах, наверное, сразу нужно понять, что же такое интерфейс. Как бы вы дали определение этому понятию? Есть какие-то версии? Часть, которая отвечает за взаимодействие с пользователем?

Мое любимое определение интерфейса дал Джефф Раскин, это такой гуру интерфейсов. «Интерфейс – это способ, которым выполняется какая-то задача при помощи каких-то средств, а именно: действие и ответ системы». На самом деле это понятие гораздо шире того, что обычно вкладывается в интерфейс, потому что интерфейсом обладают практически все окружающие нас вещи, при помощи которых мы выполняем определенные функции.

Например, интерфейс гамбургера очень понятен: его просто нужно взять и съесть. В этом смысле интерфейс гречки немного более сложен: сначала нужно раздобыть ложку и затем уже справляться с едой. Интерфейс кроссовок сложнее интерфейса тапочек. Хотя с другой стороны все интерфейсы окружающего мира нам с одной стороны привычны, а с другой стороны понятны без каких-либо дополнительных подсказок, как правило. Мы еще поговорим, почему это так. Но из этого правила тоже есть исключения: бывают разные странные предметы, например, экзотические фрукты, которые совершенно непонятно как есть, или какой-нибудь кран без вентилей, к которому непонятно как подступиться, двери без ручек… О таких вещах хорошо пишет Дональд Норманн в книге «Дизайн привычных вещей», которую я очень вам рекомендую для погружения в тему. Потому что, с одной стороны она очень простая и понятная, а с другой стороны там много интерфейсных приемов, разрешение таких проблем из физического и реального мира, которые можно использовать при проектировании интерфейсов «машина-человек», о которых мы тоже сейчас поговорим.

Эволюция машинных интерфейсов

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

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

Интерфейс пользователя. Основные ценности

1) Защита материальных ценностей

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

— На ваш взгляд, какой из этих интерфейсов лучше: первый или второй?

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

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

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

2) Интерфейсная защита от потери данных

Следующая очень важная ценность пользователя, которую компьютер должен беречь и очень много внимания на нее обращать – это введенные данные. Думаю, среди нас здесь нет такого человека, который в какой-то момент не терял несколько часов усердной работы, просто потому, что «вырубили» электричество, «вылетела» программа, что-то еще такое непредвиденное случилось, и естественно «Ctrl+S» последний раз мы нажимали давно. А на самом деле, это не проблема пользователей, это проблема людей, т.е. компаний, которые проектируют такие программы, которые позволяют в принципе данные потерять.

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

3) Сокращение времени на повседневные операции

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

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

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

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

Принципы хороших интерфейсов

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

1) Простота ментальной модели

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

Case: Вкладки браузеров

Первый пример – про вкладки. Вкладки – это не физическая аналогия, не физическая метафора, но эта метафора очень быстро прижилась. По-моему Opera первой внедрили концепцию или Firefox, не помню кто это сделал, но с тех пор вкладки очень быстро распространились на все браузеры, даже Internet Explorer у нас сейчас со вкладками. Почему так произошло? Потому что это простая, очень понятная парадигма. У нас есть несколько окон, так как мы находимся в браузере, все эти окошки собраны, и удобно между ними переключаться. Это с одной стороны удобно и быстро, с другой стороны – очень понятно. Вот собственно такая простая ментальная модель очень быстро завоевала себе рынок.

Другой пример хорошей ментальной модели – это кнопка. Почему кнопка – хорошая модель? Да потому что она понятна и физична. Сразу вспоминаем красную кнопку «Don’t push the button». Т.е. это прямая аналогия из реальной жизни. Кнопка нарисована на кнопке, она похожа на кнопку, она нажимается. Собственно это элемент, которому не нужна подпись, например, «кликни меня», потому что она всем своим видом говорит: «нажми». Тоже отличная простая ментальная модель.

И еще очень хороший пример использования вот такой физичности, таких ментальных моделей – это интерфейс «Айфона», причем вот здесь у меня показан, как вы видите скроллинг. Но здесь я скорее имела в виду вот эти «резиновые» эффекты. т.е. когда ты дотягиваешь до края, и при отпускании у тебя происходит такая «пружинка» с задержкой, с инерцией, вот такие всякие инерционные эффекты. В «Айфоне» вообще грамотно используется анимация. Там никогда не бывает эффекта ради эффекта. Если используется анимация, она всегда сделана для того, чтобы показать либо навигационные какие-то переходы, т.е. как мы сюда попали. Если экран съезжает вправо, мы понимаем, что тот экран, на котором мы были раньше, остался слева, и при этом у нас есть какая-нибудь стрелочка, которая показывает налево. Мы нажимаем на приложение, чтобы туда зайти, а оно как бы прилетает к нам, и фактически мы в него зумимся и понимаем, что, чтобы сделать «unzoom», уже знаете, какой-то четырехпальцевый жест уже работает на «Айпаде», чтобы когда, чтобы выйти из приложения, мы просто делаем такой «unzoom»… Ну, неважно.

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

Соответственно проще метафора, которая лежит в основе элемента интерфейса, всего интерфейса, тем соответственно проще этим интерфейсом пользоваться, тем проще в нем разобраться.

2) Доступность основных функций

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

Сложный / простой интерфейс текстовых редакторов

Вот здесь, как вы видите, у меня показан Word с его «риббоном», там уже наверное пять десятков разнообразных иконочек, функций, вкладочек, выпадающих списков. Все это в 90% случаев используется для того, чтобы «тупо» набрать текст. При этом, чем больше мы инструментов пользователю даем, тем у нас более интересные всякие такие штуки получаются. То есть у нас текст превращается из текста в какой-то арт-объект, который на самом деле совершенно может быть был и не нужен изначально. Поэтому мой любимый инструмент для набора разнообразных текстов – это просто в Гугле, просто в почте я задаю черновик, отключаю все форматирование, начинаю писать что-нибудь там, при этом в этом интерфейсе работает отлично автоматическое сохранение мгновенное, т.е. черновики постоянно сохраняются, информация никогда не теряется – это то, о чем мы говорили раньше. Чем проще функция, тем проще должен быть интерфейс.

3) Скорость работы

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

Проектирование интерфейса интранета для «Ренессанс Страхование»

Вот здесь как раз приведен скриншот из проекта интранета для Ренессанс Страхования (я в этом проекте достаточно активное участие принимала). Там была проблема. Мы придумали, что, ну так как в интранете понятно, что самый главный инструмент – это адресная книга. Т.е. большинство людей ходит в интранет только затем, что-бы найти там каких-нибудь своих сотрудников, коллег, по каким-то вопросам к ним обратиться. Мы придумали поиск по вот этой вот книге, который должен был уметь находить Васю с 4-го этажа. Т.е. там огромное количество сотрудников, огромный офис, и все, что тебе нужно сделать – это написать «Вася с 4-го этажа», и у тебя выпадет список всех Вась, которые работают на 4-м этаже. Программисты, конечно, смотрели на нас как на идиотов и говорили, что это невозможно сделать, что это «поиск по нашей базе данных, в которой 100 тысяч сотрудников, и на каждом сотруднике еще 50 полей разных параметров, а если мы все эти параметры будем пытаться учесть, это вообще все нереально, и надо как-то это дело упрощать». Мы им предложили добавить 51-е поле в базу данных, куда сложить текстом со-держание всех полей, которые уже есть, фактически такой индекс получился по каждой записи. Соответственно искать нужно толь в этом индексе, и если по каким-то записям есть совпадения, то дальнейшую какую-то релевантность уже определять, прогоняя запрос по конкретным полям именно в этих записях. Т.е. вместо того, чтобы искать по всем полям во всех записях, мы ищем сначала по одному полю во всех записях, потом то релевантность выставляем уже с учетом тех полей, где был найден запрос. Я это к чему все говорю? На самом деле это задача, прежде всего, проектировщиков интерфейсов – уметь, разбираться в таких вещах, хотя бы на высоком уровне уметь объяснить разработчику, что он должен сделать, чтобы вот это интерфейсное решение начало работать.

4) Обратная связь в интерфейсах

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

Кредитный калькулятор (мгновенная обратная связь в интерфейсе)

В мгновенной связи мне очень нравится пример кредитных калькуляторов. Вообще говоря, обратная связь – это, как я уже говорила, ее нужно обязательно предусматривать заранее и отдельно программировать. Обычно все ленятся это делать, поэтому примеров обратной связи в интерфейсах не так много. Но если вы зайдете на сайт какого-то банка, то кредитные калькуляторы процентов на 80 всегда сделаны с обратной связью. Т.е. у нас есть ползуночек, который можно подвигать и указывать разную сумму кредита, можно изменять срок выплат тоже с помощью ползуночка, можно какие-то еще поля задавать, и соответственно вот эти все данные, которые у нас показаны: сумма, процент, переплата – они будут пересчитываться в зависимости от того, что мы указываем. У меня есть теория, что именно в этой области обратная связь так распространена, потому что это действительно эффективный инструмент, он помогает продавать, а кредиты это основной, фактически, продукт банка. Поэтому банку выгодно вкладывать деньги в разработку интерфейса таких кредитных калькуляторов с обратной связью, и это действительно работает и приносит им дополнительные выгоды.

Масштабирование в Google Maps (графическая реализация обратной связи)

Еще очень интересный пример с обратной связью связан с картами. Раньше в Google Maps и, по-моему, Yahoo Maps была очень интересная история. При изменении вот этого ползуночка у нас происходила перерисовка карты. Причем очень грубая, в отвратительном масштабе, с огромными пикселями, но при этом карта как бы изменялась. Вот сейчас если вы зайдете и посмотрите, подвигаете этот ползунок, изменения происходят уже после того, как вы в каком-то месте его отпустили. Вот соответственно отпустили, и у вас там «зазумился» или «отзумился» вид. При этом очевидно, что вот это изменение при передвижении – это и была вот та самая обратная связь. И она хорошо работала, потому что она пусть и не позво-ляла хорошо увидеть какую-то картинку (потому что естественно, что так быстро ничего нельзя подгрузить), но при этом она позволяла понять степень изменения, т.е. это действительно была какая-то демонстрация масштаба – насколько масштаб изменится при передвижении ползунка в соседнее положение. Как ни удивительно, это исчезло абсолютно отовсюду. То есть какие вы карты сейчас ни посмотрите, во всяком случае, одни из известных – скажем, Google Maps, Yandex Maps, Yahoo Maps, – там нигде ничего подобного нет больше. Все это так странно, это какой-то шаг назад. Я, например, до сих пор не знаю объяснения этому факту. Обратная связь не является чем-то основным. В принципе, ты и так можешь понять – сейчас все так быстро работает, ткнул в одно место, ткнул в другое, все быстро перерисовалось. Но это была хорошая дополнительная помощь. При этом все уже наверное видели Google Instant Search, который показывает результаты по мере вбивания запроса. Это как раз опять вот эта наша мгновенная обратная связь, т.е. в поиске они как раз двигаются правильным маршрутом и идут как раз в сторону мгновенной обратной связи.

5) Отсутствие режимов предсказуемости

Следующий, тоже очень классный, очень правильный принцип – это отсутствие режимов предсказуемости интерфейсов. Что такое вообще «режим»? Если привести простой из жизни пример – все, наверное, себе представляют водопроводный кран в ванной. И есть вентиль, который перекрывает воду. Вот водопроводный кран имеет два режима. Когда вентиль открыт, вы крутите кран – течет вода. Когда вентиль, который перекрывает воду, закрыт, или, например, вода закончилась – есть второй режим, когда вы делаете все тоже самое. т.е. вы крутите вентиль, вода при этом не течет. В физическом мире здесь все довольно понятно. С одной стороны вы можете пойти и покрутить этот вентиль и понять перекрыта вода или нет. Если все же она не перекрыта, то, наверное, воду отключили.

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

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

Почему у меня здесь показан Photoshop? Photoshop, несмотря на то, что в нем огромное количество режимов, вот эти все инструменты, которые здесь есть… Кто пользуется Фотошопом, тот знает; кто не пользуется – например, есть инструмент «Выделение какой-то области», а есть инструмент «Рисование кистью», и когда вы выделяете какую-то область, у вас просто выделяется такой прямоугольник, а если вы точно так же проведете мышкой, которая находится в режиме кисти, то у вас просто нарисуется вот такая полоска, т.е. совершенно разная функциональность, несмотря на то, что действие абсолютно одно и то же. Но чем все таки хорош Photoshop – во-первых, здесь негативный эффект режимов сглаживается тем, что, как правило, курсор всегда показывает, в каком состоянии находится система, т.е. форма курсора соответствует вот этой иконочке, которая нарисована для обозначения инструментов. А так как курсор практически постоянно находится в локусе вашего внимания, когда вы работаете с Фотошопом, то вам очень сложно запутаться. Даже если иногда вы сделали случайно что-то не то, всегда есть Ctrl+Z, т.е. любую ошибку можно отменить.

Чем плохи режимы? Режимы плохи тем, что каждый раз, когда включается режим, перестают работать ваши привычки, а хороший интерфейс должен как раз работать над тем, что-бы формировать привычки потому что… Собственно, почему здесь я показала Photoshop? Photoshop – это мой основной инструмент на протяжении последних лет четырех, наверное. Это не самый хороший интерфейс, потому что чтобы сформировать привычки в Фотошопе, у меня, наверное, года два ушло. Но при этом, это – нормальный интерфейс, потому что в конце концов привычки сформировались, и сейчас я могу им пользоваться абсолютно… Т.е. это инструмент, который перестал для меня быть инструментом, а стал просто средством достижения цели. Т.е., когда я сейчас работаю с Фотошопом, я совершенно не думаю о том, какие действия я выполняю (они доведены до автоматизма) и думаю только о том, что я хочу сделать. Вот это – идеальный сценарий использования интерфейса, когда за счет привычки интерфейс делает вид, что его не существует. Т.е. он настолько до автоматизма доведен в мозгу, что фактически ты делаешь какие-то действия, не задумываясь о том, что ты делаешь, и получаешь результат. Это самый высший пилотаж с точки зрения интерфейса, когда он позволяет тебе добиваться таких результатов, т.е. не замечая его выполнять какие-то действия, которые ты хочешь сделать. В этом смысле, например, в Фотошопе есть отвратительный режим Quick Mask, которым я, например, никогда не пользуюсь, но он при этом периодически включается, и это, по-моему, один из немногих режимов, у которого нет явной индикации. Т.е. ничего не происходит с курсором, единственное, что происходит – вот здесь, где-то там в шапке окна пишется, что это Quick Mask, и это – полный ад, потому что первое время мне приходилось просто выключать Photoshop, перезагружать его, потому что я не понимала, что случилось. Теперь я уже разобралась, но все равно, это очень большая разница.

И еще следующий шаг по отношению к привычкам. Самые крутые интерфейсы не просто формируют привычки, они их предугадывают, т.е. иногда, например, ты знаешь, что чтобы выделить, например, два объекта, мы их выделяем Shift'ом. Почему бы нам не попробовать выделить три объекта тоже Shift'ом? Т.е. мы все знаем отлично, что это работает, но предположим, что этого знания у нас нет, и мы кликаем третий объект тоже Shift'ом, и он выбирается. Это функциональность, о которой мы не знали раньше, но она сработала как следствие из нашего предыдущего опыта. Я согласна, не очень хороший пример, сейчас попробую что-нибудь… Ну вот, например, такой пример. Я знаю, что можно, когда у нас выбран такой инструмент (не знаю, как он называется, честно говоря), можно с зажатым Ctrl'ом кликнуть любой объект, и слой с этим объектом выделится слева. В какой-то момент, соответственно, тот же самый сценарий – просто пытаешься зажать Ctrl одновременно с Shift'ом и выделить два объекта. И это работает. И это очень приятно, потому как это вроде как особо не задокументировано нигде, но он угадал, что ты хочешь сделать. А можно, например, вообще зажать Ctrl и провести мышкой на несколько объектов, и он выделит все слои с этими объектами. Это вообще моя любимая фигня в Фотошопе, не знаю, как люди без нее живут. Достаточно об этом, я думаю, основная мысль понятна про формирование привычек, про то, что надо стараться своими интерфейсами пользователю как можно больше предоставлять возможность формировать привычки пользоваться инструментом, не обращая внимания на сам инструмент.

6) Минимизация ошибок при пользовании интерфейсом

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

Недостатки интерфейса диалоговых окон

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

Действительно, сколько раз в день мы видим вот это диалоговое окно, которое при попытке совершить какое-то действие, т.е. мы высказываем желание закрыть окно, или что-то удалить, или что-то… Ну, например, удаление объекта – самый простой пример. Мы каждый день, допустим, удаляем какие-то файлы. Удаляем, удаляем, каждый раз нажимаем – «Вы действительно хотите?..» – «Да, хочу» – «Вы действительно?...» – «Да, хочу, хочу, хочу». И в тот единственный раз, когда мы случайно удаляем объект, в тот единственный раз, когда нам нужно будет нажать «Нет», мы просто по привычке, потому что мы изо дня в день повторяем вот эти действия, которые нас раздражают, и мы уже привыкли тыкать вот это «Да», в от единственный раз, когда вот это могло бы помочь, мы по привычке просто нажмем «Да», и этот объект улетит у нас в корзину, а может быть мы не очищаем корзину и потеряем что-то там навсегда. Мораль здесь такая, что как раз вот эти диалоги работают очень плохо, и решение правильное – это Undo, т.е. дать пользователю возможность исправить ошибку, а не спрашивать его лишний раз – хочет ли он ее совершить?

7) Информативность интерфейса

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

НЕинформативный интерфейс IPhone

Мой любимый пример на эту тему – это видео, которое публиковал Эдвард Тафти. Знает кто-нибудь, кто такой Эдвард Тафти? Я вам очень советую познакомиться с этим именем. Это такой гуру информационного дизайна, человек, который фактически возвел информационный дизайн в полноценную дисциплину, в науку. Он сейчас преподает в университетах американских, по-моему, он еще советник Обамы, но это я могу ошибаться уже. Сейчас я вам покажу видео. В шоке все мировое сообщество, охреневает от того, какой крутой IPhone, а Эдвард Тафти такое выпускает видео, что «IPhone, конечно же, ваш неплох, но в нем очень много проблем». И он в частности критикует вот этот Cartoon Style и говорит, что «нужно было все-таки вам, товарищ Стив Джобс, сделать более информативный, больше показывать информации в интерфейсе». В частности, он приводит пример с приложением «Погода». Вот в приложении его пример. Все то же самое. Все вот эти цифры он размещает на том экране, в том же самом разрешении, их видно, их можно прочитать, но огромную площадь экрана он отдает под такой живой прогноз погоды, спутниковую картинку, которую обычно показывают на фоне у тех, кто, собственно, рассказывает нам о погоде. Соответственно на этом маленьком экранчике можно в принципе увидеть гораздо больше информации, чем показано в «Айфоне». Т.е., чем больше информации, тем лучше на самом деле. Но для этого информацию нужно уметь подать. Давайте мы к обсуждению этого кейса еще вернемся – я знаю, что всегда больше всего нареканий тут возникает, подумываю о том, чтобы выкинуть этот слайд, но он мне просто слишком нравится.

Информативный интерфейс в CMS Webarama

Я покажу еще один пример – это, собственно, интерфейс, который я сама разрабатывала для сайта Webarama. Это такой сайт про музыку, куда можно загружать музыкальные файлы, и, чтобы на сайте они отображались более-менее хорошо, там есть внутренние алгоритмы, которые эти файлы при публикации на сайте обрабатывают. Как раз здесь у нас показана «админка» Webarama, и вот это конвейер обработки файлов. Т.е., например, вот здесь у нас показано, что 71 файл поступает сейчас; вот это показаны разные узлы в обработке, т.е. часть файлов загружается, часть – в поисках информации для них, часть файлов проверяется на конвейере на главную – т.е. это некие узлы в обработке как раз вот этих вот музыкальных файлов. На этих узлах у нас показана масса информации: сколько сейчас необработанных заявок, сколько заявок пришло, сколько заявок ушло, сколько времени в среднем уходит на обработку, здесь была предусмотрена еще какая-то оплата тем модераторам, которые работают на… Там были автоматические конвейеры, были конвейеры, которые работают вручную. Вот здесь указана ставка, которую получает модератор за то, что обрабатывает файл на конвейере вручную, какие модераторы работают на этом конвейере, запущен конвейер или нет. Кроме того, здесь использована метафора… Т.е. мы представили, что вот эти соединительные линии – это такие своеобразные проводки, которые, чем больше по ним проходит заявок, тем они краснеют, они как бы раскаляются. Т.е. они вот здесь… Есть серый цвет, есть красный цвет и их градации промежуточные, которые показывают, насколько сейчас узел или соединение это загружено. Соответственно информации здесь показано очень много и можно было бы, наверное, просто показать несколько точек, соединить их линиями и подписать, сколько сейчас на каждом конвейере… Но мы достаточно долго над этим работали, и в итоге удалось разместить максимум информации, и на мой взгляд – это хороший пример того, как, поработав над интерфейсом, можно сделать его гораздо более информативным.

Добрались до первого привала. Здесь выписаны все принципы, и, может быть, у вас есть какие-то вопросы?

Процесс проектирования интерфейсов

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

Собственно, процесс очень простой: Анализ – Концепт – Детальный дизайн – Сопровождение и внедрение. Здесь показаны еще результаты выхода из каждого этапа. Сейчас мы конкретно про каждый из этапов еще поговорим.

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

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

Для того, чтобы продемонстрировать концепт, как правило, достаточно самое небольшое количество экранов, т.е. это может быть главная страница сайта и две-три внутренних; либо, если мы говорим про какое-то устройство, терминал, мобильный интерфейс – может быть вообще один-два основных экрана, плюс навигационная концепция, т.е. как эти экраны между собой связаны. Причем, можно по-разному относиться к концептам: можно прорабатывать совсем детально, т.е. делать окончательный дизайн с оформлением; можно просто набрасывать «мокапы» в Бальзамике, – самое главное, чтобы здесь была вот эта главная идея – в чем суть нашего интерфейса, почему им удобно пользоваться, почему он предоставляет быстрый доступ к информации, к функциональности, которая важна. На следующем этапе прорабатываются все остальные этапы, выбирается фотографическое оформление, если этого не было сделано раньше, и на выходе мы получаем огромную стопку картинок уже графически оформленных плюс какие-то наборы пиктограмм, плюс какие-то графические элементы, описание поведения. Например, можно нарисовать не все экраны, а нарисовать половину экранов, а половину каким-то образом описывать текстом, говорить, что этот экран получается из такого, будет работать так-то. Т.е. на выходе из детального дизайна – у нас готовый дизайн продукта. И после этого идет самый важный, самый сложный этап, который сейчас игнорируют, но на самом деле – это единственный по сути… Т.е. если все этапы – они очень классные и интересные и важные для результата, то какой бы крутой дизайн у нас не получился на выходе из третьего этапа, если мы не проводим сопровождение и внедрение, то все наши труды абсолютно ничего не стоят. Т.е., единственное, что важно – это тот продукт, который получится, когда с ним закончат работать программисты. Потому что исключительно дизайнер интерфейсов несет ответственность за тот результат, который получится у программистов. И это правильно – брать на себя ответственность, потому что иначе результат будет очень сильно отличаться. Дизайнер будет говорить, что: «Я нарисовал такую красивую штуку, это программисты все зарубили», а программисты будут говорить: «Что он нам такое нарисовал вообще, как оно должно работать? Мы все переделали так, как мы понимаем». Собственно, получается какашка, за которую никто не отвечает – ни одна сторона, ни другая.

Давайте немножко подробнее по каждому этапу я расскажу.

1) Этап Анализа

Действительно, это очень интересная ступень. Она включает в себя очень тесное общение с заказчиком, продолжительные переговоры. Например, если вы видели на сайте бюро – у нас есть такой проект, называется «Регуляр». Это сайт про анализаторы влажности, газовые анализаторы, т.е. такие огромные промышленные системы, которые занимаются газовым и влажностным анализом. И когда мы готовили концепцию для этого сайта, мы очень глубоко погрузились в эту тему, т.е. нам присылали руководства по этим приборам, мы обсуждали с заказчиком, как они работают, какие технологии лежат в основе. Это безумно интересно было, особенно мне, потому что я буквально только год назад закончила физфак, и мне стало не хватать этой всей науки, а здесь действительно было что-то такое недизайнерское совсем. Это совершенно нормально, потому что только погрузившись в тему достаточно глубоко, вы можете какой-то вменяемый хороший результат предоставить. Ну и понятно, что тема темой, но очень важно и понять задачу, очень важно понять какие-то бизнес-процессы, которые лежат в основе вот этой системы, которую вы создаете, чтобы она в итоге оказалась не просто красивой игрушкой, а действительно работала и решала задачи заказчика.

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

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

Но на выходе – как я уже говорила – понимание, согласованное с заказчиком.

2) Этап разработки концепта интерфейса

Дальше – следующий наш творческий этап. В нем происходит работа над основной идеей – придумываем какие-то идеи, предлагаем какие-то гипотезы и, глядя на наши сценарии – на самом деле, гипотезы – мы предлагаем исходя из сценариев в первую очередь… Предположим, что у нас есть какой-нибудь почтовый клиент, и сценарий у нас такой, что Петя Васе пишет письмо. И мы говорим: «О, Так это же просто! Мы заходим в почту, у нас там есть окно, и мы там можем что-то написать, типа «Петя, и какой-то текст» и нажать Ctrl+Enter, и это отправится». Т.е. мы зашли прямо по сценарию. Но, сценарий – это хорошо, но нужно не забывать, что какая-то функциональность тоже должна поддерживаться, что наша гипотеза высказанная – она крутая, всем принципам соответствует, но при этом все-таки не поддерживает какую-то обязательную функциональность, которую необходимо предусмотреть, и тогда мы либо предлагаем совсем другую гипотезу, либо ее начинаем пересматривать, корректировать, и в соответствии с этим получаем какой-то более-менее окончательный концепт.

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

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

3) Этап детального дизайна интерфейса

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

4) Этап детального дизайна интерфейса

Про сопровождение и внедрение очень хочется поговорить подольше. В первую очередь о сопровождении и внедрении очень важно договориться с разработчиками интерфейса заранее, до того, как они в принципе начинают что-то делать, если это возможно. Потому что очень часто разработчик, например… В принципе, совершенно нормальная ситуация, что дизайнер рисует макет, передает его верстальщику, верстальщик ему присылает результат и говорит: «Вот, готово». Дизайнер смотрит, потом просто берется за голову и говорит: «Что это?» Т.е. вещи какие-то, которые совершенно очевидны дизайнеру: отступы, междустрочные расстояния, позиционирование каких-то элементов – они почти никогда не очевидны для верстальщика. Это очень большая удача, когда дизайнер работает с человеком, у которого очень наметан глаз, которому не нужно делать скриншот его картинки, скриншот твоей картинки, накладывать их друг на друга и говорить: «Посмотри – это вообще не одно и то же». На самом деле – это большая редкость, и в тот момент, когда верстальщик присылает уже готовый результат, бесится дизайнер, бесится верстальщик, говорит: «Ну все, вы мне пишите тогда документ, чтобы в нем были написаны все размеры шрифтов, где «болд», где «италик», чтобы все цвета были описаны, сетка описана, процентные соотношения, отступы в пикселях… Короче, давайте такой документ, тогда я сделаю, как вам нужно». И это уже тупик, это очень неприятная ситуация, потому что я, например, со всеми, с кем работаю, стараюсь заранее договариваться, о том, что никаких гайдлайнов, никаких сложных, на 50 страниц, документов по дизайну мы не пишем, но есть промежуточный результат – например, сверстана одна страничка – я сажусь рядом и говорю, что вот это надо подвинуть сюда на 10 пикселей, там шрифт увеличить, т.е. какие-то вещи, которые мне гораздо проще сказать вслух или написать коротенький паклист в письме. Т.е. это проще сделать уже после того, как часть работы сделана и все можно быстренько поправить, чем перед началом работы писать огромные талмуды с огромным количеством скриншотов, на них размечена сетка… Если внутри компании это все происходит – это вообще, на мой взгляд, бред. Если есть какие-то договоренности с внешним заказчиком – иногда действительно есть необходимость такую документацию писать, но мой опыт показывает, что даже в таких ситуациях можно, как правило, договориться. Весь вопрос в том, что вы просто по-человечески подходите и договариваетесь.

Еще очень важный момент. Понятно, что внешнее оформление – это одно, есть еще поведение. Даже когда, казалось бы, готов уже тотальный дизайн, и все файлики нарисованы, все подготовлено, все продумано – но так не бывает на самом деле. Всегда останется какой-то момент, который забыли, который не нарисовали; или в голове он у меня есть, а я не успела его как-то задокументировать, или я даже не подумала, а когда начал программировать программист, у него этот момент вылез. Обязательно нужно, в том числе, когда мы предварительно довариваемся, просить их, что, как только такой момент возникает, чтобы разработчики шли к дизайнерам. Я считаю, что это тоже задача дизайнера, но наверняка среди вас здесь много разработчиков, в общем, нужно обязательно идти к автору и пытать его до последнего, пока он не скажет, как нужно сделать. Потому что, каждый раз, когда разработчик делает: «А, ну ладно, тут написано, сделаю, как мне кажется правильным» – получается что-то не очень хорошее. Всегда дизайнер должен быть готов к таким вопросам, готов к тому, что они будут, и готов разрешить такие спорные моменты, предложить какие-то решения. То есть, это нужно планировать, это нужно вносить в план, это нужно всегда учитывать, что моменты такие обязательно будут, об этом нужно договориться, и на это понадобится время. Имейте в виду.

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

И последнее. Должна быть постоянно со стороны дизайнера инициатива – посмотреть, как идут дела. Постоянно нужно интересоваться, что получается, дай посмотреть, дай потыкать, пришли ссылочку. Потому что очень сложно вносить изменения, когда уже вся работа сделана, когда тебе присылают и говорят: «На вот смотри, все готово». Ты опять хватаешься за голову и думаешь: «Ну это, блин, полгода переделывать!». На самом деле, чем больше таких промежуточных точек контроля, тем дешевле сделать изменения, тем это проще чисто психологически, потому что психологически дизайнер понимает, что это всего лишь какой-то маленький кусочек, вот он сейчас там 10 багов напишет, их поправят, и все будет хорошо. Психологически проще разработчику, потому что некоторые из этих ошибок могут потом физически повторяться много-много раз, и если их поймать раньше, то в дальнейшем все будет сделано правильно, а если их поймать в самом конце, то придется переделывать все.

И на выходе у нас получается «Гвин енд» – готовый продукт, максимально соответствующий задумке дизайнеров. Наверное, есть такие случаи, когда это действительно случается.

Книги по проектированию интерфейсов

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

• «Дизайн привычных вещей», как я уже говорила – это такое погружение со сто-роны больше промдизайна, но там очень много полезных мыслей, которые мож-но легко перенести на веб и на искусственные интерфейсы.
• «Интерфейс» Джеффа Раскина – это просто библия. Не существует дизайнера интерфейсов, который не прочитал бы эту книжку. Потому что все остальные ребята неправильно, видимо, себя называют. Там такая концентрация вот этих ценных мыслей. Фактически все, о чем мы сегодня говорили – об этом упоминается в книжке, в общем я, наверное, именно оттуда все узнала, а сейчас просто применяю эти знания. Совершено гениально.
• Еще есть Алан Купер – «Психбольница в руках пациентов». Это заход со стороны сценариев, персонажей. К сожалению, не хватило у меня сил поподробнее вам рассказать. Это интересная тема. Можно попробовать познакомиться, можно пару раз спроектировать интерфейс с персонажами, понять, что это такое и понять, насколько это подходит лично вам, и насколько это удовлетворяет вашим потребностям.

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

Еще хочу посоветовать вам посмотреть несколько видеовыступлений. Есть просто потрясающие ролики. Так сложилось, что они все с 404-го Феста. Это такой фестиваль веб-разработчиков в Самаре. Я как раз присутствовала на всех этих трех выступлениях. На мой взгляд, это такой передний край дизайна интерфейсов.

• Гил Бакстон – это какой-то глава инновационных разработок Microsoft – очень интересный доклад, даже сложно описать, о чем он. Действительно инновационный, что называется.
• «Кривое зеркало» Чикуенка – это заход со стороны веб-разработки, т.е. с техни-ческой стороны, но тоже про интерфейсы. очень много про интерфейсы, очень интересно, очень содержательно.
• Илья Бирман «Интерфейс – зло» – это заход с дизайнерской стороны. Илья рассказывает о том, почему интерфейс – зло, почему его не должно быть. По сути, очень классно, очень интересно.

Ну и какие-то еще полезные сайты. Вот видите – edwardtaffty.com – это вот этот гуру информационного дизайна, о котором я говорила, ну и разные там блоги, просто то, что я читаю, то, что меня поддерживает в тонусе всей интерфейсной тематики.