< Часть пятая
Как правило, самые высокие расходы в бизнес — это стоимость рабочей силы. Каждый раз, когда пользователь должен ждать ответа системы, прежде чем он сможет продолжить, деньги улетают в трубу.
Для достижения максимальной эффективности бизнеса или другой организации вы должны максимизировать эффективность каждого, а не только эффективность одной группе.
Крупные организации, как правило, разрозненны, каждая группа в них ищет свои собственные интересы, иногда в ущерб всей организации. Отдел информационных ресурсов (Н) часто попадают в ловушку создания или адаптации систем, повышающих эффективность и снижающих расходы своего департамента ценой снижения производительности компании в целом.
Например, одна крупная корпорация в Калифорнии использовала магнитные диски в качестве носителя для реестра о доходах. В начале открытия реестра, каждый сотрудник получал диск с приложением реестра, который он или она должны были вставить в свой компьютер и запустить. После запроса имени сотрудника, его адреса, номера телефона, название отдела и так далее, сотруднику позволялось пройтись по всем видам доходов, в конечном счете, возвращая диск, содержащий все его ответы и варианты выбора. Отдел Н затем собирает данные с каждого диска, и вводил их в свою систему, всё автоматически. Отдел Н сохранил много денег в сравнении со старой системой, в которой они должны были переносить данные сотрудника с бумажной формы.
В чем была проблема? Вместо отдела Н, несущего тяготы переноса данных сотрудников, все сотрудники до единого сейчас погрузились в него, вводя свои имена, адреса, номера телефоном, названия отдела и так далее. Данная система так же неэффективны, как и прежде, но теперь затраты были разнесены на все отделы вместо того, чтобы остаться сосредоточенными в бюджете отдела Н.
Существенный прорыв в работоспособности программного обеспечения следует искать в принципиальной архитектуре системы, а не в поверхностном дизайне интерфейса
Эта простая истина, почему так важно для всех участвующих в разработке ощущать значимость создания программного обеспечения, ориентированного на задачи пользователя и понимать жизненно важную разницу между построением эффективной системы и повышением продуктивности пользователя. Эта истина является также ключом к необходимости тесного и постоянного сотрудничества, общения и соучастия между инженерами и дизайнерами интерфейса пользователя, если эта цель будет достигнута.
Составляйте сообщения и подсказки бережно, пусть они описывают проблему: хорошее написание с лихвой окупится пониманием и продуктивностью.
В названиях пунктов меню и кнопок ключевое слово должно идти сначала.
Пример из выдуманного текстового редактора:
Плохо
— Вставить разрыв страницы
— Добавить сноску
— Обновить оглавление
Хорошо
Вставить:
— Разрыв страницы
— Сноску
— Оглавление
Здесь первый пример с его начальными словами на самом деле более информативный и более точный: сноска не «вставляется», если она помещается после всех других сносок. И оглавление не вставляется, если оно уже присутствует. Оно просто обновляется. В то же время, второй пример демонстрирует большую продуктивность при испытании на время. Почему? Потому что дополнительная информация, предлагаемая в первом примере, не перевесит преимуществ возможности лишь пробежаться глазами, по первым словам, каждого из пунктов меню, а затем найти и конкретный пункт.