Так что же необходимо пользователю для работы с программой? Главное - это простота и понимание программы, того, что она делает. Переходя к деталям, это значит, что уже в названии желательно отразить суть и назначение программы, а в окне "About" суть и назначение изложить более подробно. Мне попадались программы, в которых не только я не смог разобрался, но и не понял даже для чего программы эти нужны и что они делают (а может я тупой :)).

Второе необходимое условие, которое следует учесть для постороения простого и понятного ПИ, это привычка. При построении ПИ важно угадать привычки пользователя. Если пользователь первый раз видит программу, с которой ему предстоит работать, то что он будет делать? Он будет сперва "тыкаться", пытаясь понять, как добиться от программы того, что нужно ему, пользователю. Глупо надеятся на то, что пользователь будет читать документацию (составленную, как правило, самими же разработчиками "непонятной" программы, так что ожидать от прочтения документации пользователю будет практически нечего). Тем более, что техническая документация, это не художественная литература и особого удовольствия от ее чтения мало. На HELP-ы тоже рассчитывать не стоит (много Вы читаете HELP-ов?). Исходя из этого, остается полагаться только на рабочий ПИ (HELP-ы и документация, это тоже элементы ПИ), т.е. компоновкой внешних элементов подсказывать пользователю как и что делать.

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

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

Говоря проще, ПИ - это язык, и если в сложившийся язык вносить некоторые изменения, то этот язык будет труднее понимать, так как человек по природе своей существо ленивое и консерватичное, и отказываться от привычек, и наоборот, привыкать к чему-то новому, особенно когда этого нового много, практически всегда неприятно (для большинства людей), и этот фактор необходимо учитывать. Так если Вы пишете программу, аналог которой уже существует и которым пользуются многие (например, какой-либо редактор), то имеет смысл посмотреть, как организовано взаимодействие с пользователем в этой, аналогичной программе (напрмер, в Word, если разговор о редакторе), и сделать примерно так же (позаимствовать основные принципы), так будет привычнее для пользователя, а главное ему будет легче перейти к Вашей программе, если она лучше той, аналогичной. Например, досовская оболочка Dos Navigator, сделанная в стиле Norton Commander, но более продвинутая, не вызывает отторжения, так как сделана в привычном стиле.

Во-вторых, необходимо тщательно продумать и осознать схему программы, приведя ее к системе (структуре, выстроенной по определенным правилам), и, соответственно, реализовав ПИ в соответствии с этой системой. Пользователю достаточно будет "схватить" суть, чтобы по аналогии разобраться в остальном. Следует избегать лишних элементов, чем меньше их будет, тем проще пользователю будет разобраться.

Компоновка. Очень распространенная ситуация: имеется поле с элементами, над которыми необходимо производить некоторые операции, например, поле ввода текста в окне и управляющие кнопки к нему, либо поле для рисования и набор инструментов к нему и т.д. В этой ситуации есть четыре варианта, как расположить кнопки относительно поля. В идеале, конечно, лучше бы было располагать управляющие элементы снизу или справа, так как это естественно. Естественность эта проистекает из того, что руки расположены ниже головы, соответсвенно средства отображения информации (СОИ) должны быть выше органов управления (ОУ), при этом следует учитывать, что основной рабочей рукой является правая. В силу этих обстоятельств сложился определенный стиль, воплощенный в различных устройствах и приспособлениях (примеры для для данного случая: калькулятор, компьютер и др.), и вошедший в привычку. Разумеется, непосредственное управление программой делается не руками, в а мышью, но тем не менее воспринимается все так же глазами и обрабатывается мозгом. Однако, в силу ряда причин, кнопки стали размещать не совсем естественно: сверху и слева. Так за "быстрыми" кнопками закрепилось положение сверху, как и меню. Слева, в некоторых случаях, размещают инструменты и прочие управляющие элементы. Снизу и справа остались лишь управляющие кнопки, типа ДА, НЕТ, ОТМЕНА, СПРАВКА и т.д. Чтобы не вносить разлад в исторически сложившуюся схему расположения ОУ, желательно придерживаться этой схемы, либо сделать так, чтобы панели с ОУ были "съемными", и могли перемещаться пользователем в произвольные места. Но, тем не менее, предоставлять пользователю слишком большие возможности по конфигурированию ПИ тоже не следует - зачастую пользователь просто путается и испытывает определенный дискомфорт от внесенных им изменений, считая в итоге, что ПИ, сконфигурированный разработчиком программы все равно был лучше, что разработчику лучше известно "как надо".

Другая ситуация: текст, поясняющий поле и само поле. Здесь однозначно: текст слева, поле справа, других вариантов нет. Уточнение: Checkbox-s и Radiobutton-ы, особый случай, так как поясняющая надпись, фактически, является продолжением поля, и их относительное расположение является корректным.

Расположение большого числа элементов. Как правило, такая ситуация возникает при необходимости настройки программы (Options). Здесь, по крайнее мере, следует отметить случай, когда на площади окна не помещаются все необходимые элементы, и приходится использовать страницы. Здесь есть один важный момент, который странно реализован в Windows - это элемент типа Pagecontrol (по крайней мере, в Дельфи он называется так), состоящий из страниц, корешками вверх. Странность этого элемента проявляется в том, что если корешки не помещаются на одной линии, то они располагаются в нескольких рядах и выбор какой-либо страницы приводит к перестановке этих корешков, так что пользователь путается и не помнит, на какой странице он был (названия страниц, как правило, не запоминаются за не надобностью). При использовании этого элемента (или любого аналогичного) желательно уместить все корешки в одну линию. С точки зрения "правильности" расположения корешков элемент с верхним расположением предпочтительней для людей, работающих (или работавших) с картотекой. Если картотеку не учитывать, то правильнее было бы использовать элемент переключения страниц с нижним расположением корешков, так что какой элемент использовать - дело вкуса и особенностей контингента людей, для которых предназначена программа. Наверное, не стоит напоминать, что форматирование на всех страницах должно быть единобразным (т.е. привязанным к неявной таблице), ничто так не раздражает пользователя, как явные "ляпы".

Меню. С меню все просто, если нельзя назвать первый пункт "Файл", то следует назвать его исходя из соображений системности, например, в качестве первого элемента меню можно выбрать тот предмет (объект), на работу с которым нацелена программа. Желательно придерживаться общепринятого, как уже говорилось выше, порядка расположения пунктов меню и порядка расположения элементов в самих пунктах. Идея проста, пользователь должен, ничего не зная о программе, быстро найти в меню то, что ему нужно. Например, ничего не зная о том, как работать с программой, но, пробуя что-либо сделать, пользователь знает, что отменить свое действие можно с помощью команды Edit | Undo. Названия пунктов тоже следует подбирать как можно стандартнее, дабы не запутать пользователя и не ломать его привычки.

Быстое меню так же следует делать с учетом привычек. Так если в программе предусмотрена работа через буфер (cut, copy, paste и др.), то следует в соответсвующем порядке разместить эти функции в быстром меню (позволю себе "наехать" на Борланд - в Дельфи быстрое меню почему-то не содержит этих функций, хотя по привычке при копировании текста постоянно его вызываешь).

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

К сожалению, физически нет возможности дать рекомендации "на все случаи жизни", но все описанное выше можно свести к нескольким правилам, по которым можно сделать приемлемый ПИ:

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

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

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