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


