Планируйте как можно меньше, начинайте проектировать интерфейс как можно раньше, зато переделывайте почаще.
Пара примеров такого рода работы из моей практики:
♦ Когда я разрабатываю интерфейсы сайтов, я полностью меняю вид навигации по сайту в среднем четыре раза за проект (всякий раз, когда обнаруживаются проблемы в текущей версии навигации).
♦ В одном из моих проектов общая структура интерфейса была настолько сложной, что я поначалу даже не пытался о ней думать. Примерно за месяц я нарисовал все фрагменты интерфейса и только в предпоследний день проекта, когда (наконец-то!) всё стало понятно, собрал все эти фрагменты в целостный интерфейс (разумеется, для этого их пришлось слегка доработать).
Чтобы начать так работать, вам потребуется хорошая технология прототипирования. Хорошая в том смысле, что она должна позволять побыстрее нарисовать первую, убогую версию интерфейса, но главное — обеспечивать максимально высокую скорость переделок.
На мой взгляд, сейчас лучшей такой технологией является сначала рисование прототипа на бумаге, а затем — финализация прототипа в Adobe InDesign.[7] Изначально это верстальная система для полиграфии, так что использовать её для прототипирования интерфейсов — всё равно что забивать гвозди микроскопом. Но почему бы не забивать, если микроскоп ухватистый, а стоит не дороже молотка?
По крайней мере, сейчас InDesign лучше альтернатив — он легче в изучении, чем специализированные средства разработки, к тому же, хоть и уступая им в скорости создания первой версии, лидирует в скорости модификаций. Наконец, InDesign, в отличие от средств разработки вроде Adobe Dreamweaver или Microsoft Visual Studio, универсален — в нем можно запрототипировать любой графический интерфейс, будь то интерфейс программы или сайта.
Но какую именно технологию вы будете использовать — дело десятое. Главное — выбрать максимально скоростную и выжимать из этой скорости как можно больше переделок. Я вообще считаю, что пока не появилось, по крайней мере, третьей версии интерфейса, о каком-то его качестве говорить вообще нельзя.
Начинайте работу с самой больной части
Иногда существуют причины, когда важно оценить что-то полностью, в целом. Например, ресторанный критик должен оценить в ресторане всё: и обстановку, и обслуживание, и меню (и ещё много разных факторов). Но посетитель ресторана, решая, остаться в этом ресторане или вернуться ли туда ещё раз, оценивает ресторан гораздо проще — решение принимается по худшей составляющей, а не по среднему баллу. Соответственно, ресторатор, пытающийся улучшить своё заведение, должен, безусловно, улучшать в нём всё — но начинать ему стоит с самой худшей составляющей, просто потому, что её исправление принесёт максимальный эффект.
Это соображение кажется трюизмом. Я бы даже не стал писать об этом, но — до чего же трудно начать лечить то, что действительно болит, а не то, что первым попалось на глаза.
Перед тем, как приступать к работе, узнайте, что хуже всего сейчас и начните с решения именно этой проблемы.
У меня богатая практика в этом плане — полтора десятка дизайнеров, прошедших через нашу компанию, в своих первых проектах всегда начинали с того, что, вооружившись отвагой, бросались лечить то, что не болело вовсе или же болело совсем не сильно. Вероятно, в начале моей карьеры был таким же и я. Возможно, так же действуете и вы.
Поймите меня правильно — я не берусь утверждать, что гг. дизайнеры делали то, что делать было вовсе не нужно. Может, и нужно. Но первое впечатление заказчика, который приходит к дизайнеру именно потому, что у него что-то болит, было резко отрицательным. Вам бы тоже не понравилось, если бы вы пришли к хирургу вырезать болезненный нарыв, а он бы сначала отправил вас к окулисту выписывать очки (даже если бы вы действительно в них нуждались).
Соответственно, каждый проект надо начинать с определения того, что у интерфейса болит. Нужно как минимум расспрашивать заказчика, как максимум — тестировать, опрашивать пользователей и т. п. А затем формулировать список проблем, которые вы собираетесь решить своей работой. Если вы этого не сделаете, а сразу приступите к работе над интерфейсом, вы, несомненно, обидите заказчика, что непрофессионально.[8]
Не ведите себя как эксперт
Всем известно, что «в грязи обитают мелкобы» и что они вредны для здоровья. Но это знание никак не коррелирует с количеством людей, моющих руки после посещения туалета (и тем более с количеством людей, моющих руки перед посещением). Знание есть у всех, а руки моет только малая часть людей.
Видно, что-то не так с этим знанием.
И я скажу, что именно не так — само по себе знание приносит власть бесполезно. Знание начинает приносить пользу, только когда оно превращается в конкретные действия.
Интеллектуальная ловушка здесь в том, что многие знания дают ощущение компетентности; кажется, что если я много знаю про дизайн интерфейсов, я могу расслабиться и всё равно получится хорошо.
Увы, не получится. В действительности многие знания приносят печали не сокращают объем необходимой работы, а, наоборот, его увеличивают. Например, раньше я проверял свежеразработанные мной интерфейсы на соответствие гораздо меньшему числу требований, чем проверяю сейчас — просто потому, что в начале моей карьеры я не считал эти параметры существенными или просто не знал о них.
Поэтому гораздо продуктивнее постоянно говорить себе, что «я ничего не знаю о дизайне интерфейсов». Эта установка ничего не сделает дурного с уже имеющимися у вас знаниями, но поможет избежать шапкозакидательства и в придачу откроет ваш разум для новых знаний (труднее учиться, если уже считаешь себя ученым).
И главное — надо делать, а не просто пассивно знать. Например, практически общеизвестно т. н. «правило 7±2», гласящее, что раз емкость кратковременной памяти человека редко бывает большей девяти элементов, делать меню большего размера неэффективно.[9] Трудно прочесть хоть одну книгу о дизайне интерфейсов и не наткнуться на него. Но вот вы его узнали, и что же? Станут ваши интерфейсы теперь самопроизвольно лучше или нет? Нет, не станут. Чтобы это правило действительно помогало, вам понадобится включить правило «Ни в одном меню не более семи элементов» в свой контрольный список проверки интерфейсов и в дальнейшем не лениться проверять свои интерфейсы по этому контрольному списку. И без этой работы ваше абстрактное знание не стоит и гроша.
Если вы не превращаете свои знания в конкретные проектные шаги — это бесполезные знания.
Не философствуйте; общих ответов на общие вопросы всё равно нет
Мне регулярно задают вопросы класса «что лучше, интерфейсное решение А или интерфейсное решение Б?», например, «где лучше располагать корзину в интернет-магазине, сверху справа или в каком-либо другом месте страницы?». Каждый раз я страшно теряюсь, поскольку (печальный) опыт убедил меня, что:
♦ Универсальных решений, работающих всегда, почти нет. Существуют общие законы, следование которым в интерфейсе всегда продуктивно (например, законы Фиттса и Хика).[10] К сожалению, открыта (и тем более доказана) только малая часть из них (собственно, только законы Фиттса и Хика), так что не будет преувеличением сказать, что мы, собственно, ничего про них и не знаем. Интересно при этом то, что все эти законы не говорят про конкретный интерфейс ничего — они описывают человека и особенности его восприятия/поведения, а не сами интерфейсы. Уверен, что так и будет продолжаться; что никогда человеческий разум не создаст, например, Общей Теории Корзины Покупок или Универсальной Парадигмы Чекбокса. А значит, не может быть и веры в возможность общих ответов на общие вопросы про интерфейс.
♦ Доказать работоспособность интерфейсного решения может только тестирование, а никак не интеллектуальные экзерсисы. Обилие факторов, влияющих на работоспособность интерфейсного решения, не позволяет ограничиться простым рассуждением при поиске общих ответов — рассуждение неизбежно будет длиннющим. А если рассуждение длительное, вероятность ошибиться возрастает на порядки. Зачем искать ответы, заведомо зная, что они могут оказаться неверными? А вот если вы интересуетесь конкретным вопросом про конкретный интерфейс — всё как раз просто. Протестируйте его. Если тестирование покажет, что интерфейс работает, значит, он действительно работает.
В этом смысле поиск ответов на общие вопросы просто бесперспективен — если вы уверены в верности ответа, вы, по всей видимости, ошибаетесь. Если неуверены, вы никогда не сможете найти верный ответ, потому что уже знаете слишком много «за» и «против» для каждого из возможных ответов.
Не задавайтесь общими, принципиальными проблемами, пока вы хотя бы трижды не нашли их частное решение.
Подводя итог, замечу, что, на мой взгляд, думание на общие, отвлеченные темы — занятие полезное, но не особо продуктивное. Гораздо продуктивнее задавать себе вопросы про конкретный интерфейс, а не про интерфейсы вообще.
Занимайтесь только той оптимизацией интерфейса, которая улучшает продукт
Вот диалоговое окно со списком закладок из Microsoft® Word 2007. Это окно не изменялось уже более десяти лет; точно таким же оно было в Word 97.
В этом окне есть неприятная интерфейсная проблема: оно очень маленькое, так что в него умещается всего несколько закладок и оно имеет фиксированный размер, который пользователь не способен изменить.
Для большинства пользователей эта проблема не важна, поскольку они закладками вообще не пользуются. Но для малой части аудитории эта проблема становится заметной: чем больше документ, тем удобнее работать с ним применяя закладки, и чем больше этих закладок сделать, тем будет удобнее работать. Но само окно содержит встроенный ограничитель этого удобства — если сделать много закладок, пользоваться ими будет неудобно, так как лишь неск