Когда по объективным причинам клиенту нельзя на цифрах показать (гарантировать) “что будет, если нас нанять”, можно ему показать “что было, когда нас наняли” другие клиенты. А уже на этом примере сравнивать что было “до”, а что стало “после”.

Единственная сложность - клиенты, на которых ссылаетесь должны быть или очень крупными и известными ВСЕМ, или известными хотя бы внутри отрасли/направления к которой относится текущий клиент (т.е. ссылаться страховой компании на офигенные успехи и положительные фидбэки в области проектирования интерфейсов для заборостроительных заводов, по меньшей мере смешно).

Также хочется задать вопрос – есть какие-нибудь данные о том, какой процент бюджета нужно выделять на ПИ/юзабилити?

По другим составляющим проекта такие данные есть. Например, на управление – порядка 10-15%, на обеспечение качества – 15-20%, на требования – около 20%, на риски – чем больше тем лучше и т.д. (естественно данные разняться у разных авторов, для разных типов ПО, но есть МНОГО исследований на этот счет, сослаться всегда есть на что).

По поводу процента на ПИ - все зависит от проекта.
В значительной части веб-проектов затраты на ПИ куда больше, чем на техразработку.

В “тяжелых” приложениях не так, конечно. Здесь в среднем 10-20%, на мой взгляд. Конечно, я не имею в виду совсем “дохлые” проекты, где вся работа заключаеися в лихорадочном “причесывании” готовой системы в последний месяц.

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

То ли не заметил, то ли третий пункт был дописан позже.
Но в любом случае, а почему он тогда третий, раз “самое эффективное”?

Что стоило главный вывод статьи выделить визуально от остального текста? Вы же, юзабилисты, сами везде кричите, что в интернете люди не читают, а просматривают инфу…

Конечно может. Но как это расходится с оговоренными тезисами?

Чтобы до _переработки_ интерфейса зафиксировать требования в формате GOMS - надо их специально измерить, об этом написано.

А прописать в виде требований к несуществующему интерфейсу - при _разработке_с_нуля_ параметры GOMS невозможно - ведь у нас нет представления даже о сценариях, структуре системы и перечне экранов, не говоря уж о конкретных сценариях-функциях конкретных экранов.

Разве не так?

В случае же редизайна хотя и есть возможность замерить временные параметры есть другая проблема, наврятли, заказчик с большим энтузиазмом воспримет предложение о кардинальной переработке сложного продукта с целью повышения скорости работы интерфейса (это замечание по поводу сложности продукта и времени обучения для использования). А без этого , imho, сложно качественно переделать интерфейс. Данная тема неплохо описана у Купера где он отмечает что сложные в использовании продукты получаются именно потаму что специалиста по юзабилити если и приглашают то обычно на последней стадии проекта где он может сделать лишь “косметический ремонт”

Несуществующие системы тоже разные бывают
Если система вообще инновационна - то есть у нее и конкурентов нет, то тут Вы, думаю, согласитесь: никаких количественных данных мы прогнозировать не можем. Тем более в привязке к конкретным окнам/сценариям. Здесь может быть другое: бизнес-требованием к системе может служить определенная скорость работы, но в таком случае эта скорость - не дополнительная (оценочная) характеристика интерфейса, а явная цель.

В случае же разработки системы, у которой есть предшественники или аналоги - да, конечно, шикарно сначала измерить скорость, эффективность и т.д. аналогов. И пообещать ее улучшить в нашей системе. Но тут я еще раз повторю одно из своих утверждений: заказчик хочет знать эти данные, но не хочет платить за их получение. И полбеды, если проект утвержден: количественные данные сами по себе полезны, и мы можем их измерить “за свой счет” - в ходе исследований. Но когда заказчик желает только принять решение о проекте, имея перед собой эти данные - вот тут и возникает проблема. Да, в часть потенциальных проектов мы, например, инвестируем свои ресурсы. Но отнюдь не во все. И не все специалисты готовы тратить свое время в таких случаях, тем более что гарантированных заказов вполне хватает.

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

Хорошо, с новыми системами разобрались))

Но в случае редизайна если Вы пишете что гарантированных заказов хватает.. то в чём тогда проблемы ? Ну и пускай заказчик не оплачивает тестирование своей системы. Вы для его конкурента сделаете редизайн и он тогда задумается, оплачивать или нет))

“Кстати, часть заказчиков именно что готовы кардинально перерабатывать интерфейс именно с целью повысить (даже немного) скорость работы с ним. В тех случаях, когда повышение скорости быстро окупается.” - А вот это радует))

Я и не утверждаю что это огромная проблема, которая не дает работать/развиваться. Но проблема есть, и я ее описываю и пытаюсь найти пути ее решения.
Наплевать на всех заказчиков, если они периодически требуют количественных гарантий - не выход. Надо думать, как действовать в рамках этой тенденции. Для сильно интересных клиентов можно часть работы сделать условно бесплатно. Менее интересным приходится подробно разъяснять свою позицию, что я и сделал в статье.