То, что имеет смысл «здесь», может потерять его «там»

Должны ли действия задаваться кнопками или ссылками? Это зависит от действия. Должны ли даты выбираться из списка или из сетки календаря? Это зависит от того, где будут показаны даты и какой временной период они задают. Нужны ли все линки навигации на каждой странице? Нужна ли всюду строка поиска? Нужно ли повторять колонтитул на каждой странице? Правильный ответ: «смотря по обстоятельствам.»

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

Каждая буква имеет значение

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

Назовёте ли вы кнопку «ОК» или «Сохранить» или «Обновить»? «Добавить» или «Создать»? Это копирайтинг. Напишите ли вы три предложения или пять? Объясните ли вы на общих примерах или со всеми подробностями? Пометите ли вы записи как «Новые», «Недавно обновлённые» или «Измененные». «Всего новых сообщений: 5» или «5 новых сообщений»? «5» или «пять»? «сообщений» или «постов»? Всё имеет значение.

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

Хорошая документация — это хороший дизайн. Это редкое исключение когда слова не соответствуют дизайну. Иконки, названия, формы примеров, надписи на кнопках, пошаговые инструкции, понятное объяснение правил возврата денег — все это дизайн интерфейсов.

Объединяйте настройки с основным интерфейсом

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

Не создавайте отдельного интерфейса для настроек, просто встройте его функции в основной.

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

Сохраняйте код как можно более простым

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

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

Главное здесь — переформулировать любую сложную задачу, требующую много кода, в простую задачу, которая требует кода намного меньше. Возможно, вы уже не будете решать в точности ту же задачу — это нормально. Решить 80% первоначальной задачи, затратив 20% усилий — это большой выигрыш. Первоначальный вариант задачи обычно никогда не является настолько важным, чтобы затрачивать в пять раз больше времени на ее решение.

Меньший объем программы значит, что вам не придется теряться в догадках. Вместо попыток предугадать проблемы в будущем, вы решаете только сегодняшние проблемы. Почему? Страхи, которые вы питаете по поводу будущего, как правило, не оправдываются. А потому не толкайте себя в болото, пытаясь бороться с призраками.

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

* Меньшим объемом программы легче управлять.

* Меньший объем программы — меньше кода, а это значит

* Меньше скучной работы по сопровождению (и более счастливый персонал).

* Меньший объем программы снижает стоимость изменений — так что вы можете быстрее адаптироваться к обстоятельствам. Вы можете менять свои решения без того, чтобы менять мегабайты кода.

* Меньше кода — меньше ошибок.

* Меньше кода — меньше техподдержки.

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