Пролистал. Любопытно. Про 1C улыбнуло. Им несколько другими надо вещами заниматься к примеру внутренней архитектурой продукта, а то там такой ужас... даже переход на СУБД мало что дал.
Никакое хорошее юзабилити не поможет проекту у которого такая "замечательная" внутренняя архитектура. Вот почитайте 1C:Предприятие 8.1. Тестовая версия Тезисы, ответы на вопросы, комментарии
Меня особенно порадовал пункт Почему реализован собственный механизм транзакционных блокировок?. После прочтения этого документа первая мысль была: Мы рассмотрели ваш проект и решили закупить некоторое количество травы которую вы курите.
В своей жизне я минут 5 сидел за 1С:Предприятием (слава богам, уберегли), мне объяснили что нужно сделать - надо было какую то хрень переместить в из одного списка в другой. Я минуты 2 не мог понять куда надо нажать.
:(
Ну я согласен, просто никто не говорит — это хорошо, это плохо. Есть набор мнений.
Тезис, под которым лично я готов подписаться: "Нельзя не заниматься проблемой, если ее решение (исследование) очень сложное или затруднено по каким-либо причинам."
Если сделать самую главную кнопку большой и выделить полужирным шрифтом, 90% людей (на сегодня, в этом вебе, на планете Земля) поймут, что эта кнопка главнее чем другая, более маленькая и тусклая. Этим и можно воспользоваться при проектировании UI.
Есть куча приемов как стоит делать и как не стоит делать. Они действительно поддаются классификации и могут сильно изменяться, но это же не значит что поэтому надо откинуть мысль о накоплении какого либо обобщающего опыта и каждый раз делать все с нуля.
Желательно иметь инструкцию к применению инструмента. Те же паттерны которые широко применяются по сути являются удачными приемами которые могут быть повторены много раз. Так что почему не?
Люди, озабоченные юзабилити, могли бы начать с юзабилити слова юзабилити, и ввести нормальный термин.
Не говоря уже о глубоко русском словосочетании "Юзабилити Бюллетень".
Первый юзабилити бюллетень от Дмитрия Сатина