В практике проектирования и
разработки программного продукта (ПО) часто возникают ситуации, когда
происходит обсуждение вопросов, затрагивающих интересы пользователя. Если
автоматизируемые бизнес-операции (в разрезе функциональных требований к ним)
являются предметом детального изучения, то проблемам, связанным с
деятельностью пользователя, уделяется мало внимания, и они рассматриваются в
последнюю очередь.
Специалист по эргономике или, чаще
всего, выполняющий эту роль дизайнер пользовательского интерфейса (ПИ),
участвует (во всяком случае, - должен) в работе проектной группы при
обсуждении деталей проекта, касающихся взаимодействия пользователя и
программного продукта. Предметом его забот являются интересы пользователя,
эффективность, производительность и удобство работы пользователя.
Однако, у эргономиста могут
возникнуть трудности в отстаивании своих позиций. Иногда сложно
определить интересы всех участников обсуждения и найти сильную
аргументацию для парирования возражений коллег. Задачей данной статьи является
подготовка к ведению деловых бесед по вопросам проектирования и
разработки пользовательского интерфейса. Представленный материал поможет
добиться понимания и принятия позиции эргономиста в проекте при
отстаивании интересов пользователя.
Возражения
"Мы провели анализ рынка и на управленческом совещании
выяснили и решили, какой продукт мы будем разрабатывать."
"Я опытный менеджер и в компьютерном бизнесе уже N лет. Я
знаю, что пользователю нужно…"
"Я сам пользователь и я знаю, что мне нужно"
Продвинутое: «Мы провели маркетинговые исследования, поэтому
мы знаем, что нужно потребителю."
Оценка ситуации
Менеджеры знают о будущих пользователях в той части, что
им необходимо для описания функциональности информационной системы.
Взаимодействие пользователя с приложением редко является объектом изучения
из-за отсутствия знаний в этой области.
Аргументация
То, что менеджеры в компании–разработчике
программного продукта предлагают в пользовательском интерфейсе, это представляет
собой определенный интерес, однако эти менеджеры не являются будущими
пользователями. То, что они хотят увидеть в пользовательском интерфейсе, – необязательно
то, что нужно пользователям. Все достоинства продукта могут исчезнуть
при неэффективной работе пользователя (сотрудника) на спроектированном
автоматизированном рабочем месте (АРМ) вплоть до отказа обучаться и использовать ПО.
Статистические методы, используемые в маркетинговых исследованиях,
часто не дают адекватных задачам пользователя качественных данных. С помощью
них фиксируются лишь общие, часто встречающиеся желаемые результаты взаимодействия
целевой аудитории с программных продуктом. Для дизайна пользовательского интерфейса
необходимо понимать модель данных и сценарий работы потенциального пользователя
программного продукта, что требует методов анализа, характерных для эргономического
исследования.
Возражения
«У нас есть группа с интересными идеями, новыми концепциями,
мощными технологиями. Несомненно, они могут разработать большую систему, главное
предоставить пользователю новые функции, а не более красивые картинки.»
«Мы делаем абсолютно новую вещь, никто не в состоянии проанализировать
ее. Нам все равно как люди работают сейчас, в результате реализации концепции
нашей системы они будут работать по-другому.»
«Мы можем сделать систему, превосходящую по функциям
аналог NNN, надо добавить то-то и изменить это, их неплохой пользовательский
интерфейс можно просто воспроизвести у нас.»
Оценка ситуации
Чаще всего функции креативщика
выполняет технический специалист по перспективным технологиям. Он хорошо
разбирается в достоинствах и недостатках аналогов, программных платформ,
движков, ядер и пр., но редко проводит детальную оценку новаций в библиотеках
поддерживающих пользовательский интерфейс. В новых программных решениях
практически не учитывается поведение новой аудитории пользователей,
востребованность отдельных функций пользовательского интерфейса. И наоборот,
часто не обсуждается и не оценивается, насколько предлагаемые новаторами
особенности ПИ («фичи») будут целесообразны для пользователя. Решения по
дизайну ПИ обсуждаются со специалистами по эргономике время от времени и нередко принимаются по принципу
«я так вижу».
Аргументация
Конечно, новые идеи и технологии обеспечивают решения. Но
необходимо ответить - насколько новаторство этого продукта будет реально востребовано
пользователями, и они его будут применять. Возможно, продукт, в силу его непривычности,
будет пользователями отвергнут, или окажется трудным в обучении или использовании.
Вы хотите разработать продукт, который разработчикам кажется
великолепным или тот, который большинство пользователей будут считать таким?
Если новизна системы не обусловлена ее полезностью для пользователя
и не понятна ему, то есть высокая вероятность, что никто не поймет ее функций и
не сможет использовать систему. Поэтому, если пользователи откажутся использовать
из-за неудобства и сложности Ваш продукт, Вы, вероятно, не имеете рынка для
него.
Если Вы не знаете о том, как сейчас
пользователь решает свои задачи на аналогах Вашему продукту и какие он испытывает
трудности, как Вы будете знать, какой способ взаимодействия пользователя и
системы будет более эффективным? Вы уверенны, что Вы не повторите ошибок
продуктов–аналогов или не создадите новых проблем? На чем базируются Ваши решения, каких
принципов в проектировании ПИ Вы придерживаетесь, если Вы не знаете принципов работы
с уже действующими системами?
Возражение
«Исследование требований и проектирование специального интерфейса
пользователя не специфично для нашего продукта и нашей компании. Мы не хотим
платить за это. Вы - специалист по дизайну интерфейсов. Вы должны сообщать
нам о пользователях, которым нужен наш продукт и характерных для них особенностях
интерфейса»
Оценка ситуации
Последние годы практически во все
новые проекты привлекают специалиста в профессиональной области – бизнес аналитика.
Они, детально представляя свою профессиональную область, бизнес-процессы, скованы
привычными представлениями об элементах пользовательского интерфейса и иногда не могут
по-новому взглянуть на взаимодействие пользователя и программного продукта. Разработка
же рабочих мест сотрудников не включает требований к устойчивости и
надежности работы пользователей. В Интернет-проектах требования к пользователю часто
воспринимаются экспертами как маркетинговые профили пользователей Интернет-страницы
компании, портала и пр., поэтому у экспертов по отношению к эргономисту возникают
ожидания в выявлении рыночных потребностей пользователя и его соответствующего
поведения на Web-сайте.
Аргументация
Компания, разрабатывающая продукт с развитой диалоговой системой,
не должна полагаться на общее представление о пользователях. Чтобы выиграть
рыночное соревнование с другими системами, Вы должны узнать более о пользователях,
чем Ваш конкурент.
Эргономист не может быть экспертом во всех областях. Его
специальные знания состоят из методов, помогающих узнать о потребностях пользователя
и его навыках, для того чтобы потом перевести их в принципы и решения пользовательского
интерфейса.
Детальное, конкретное знание потребностей пользователя –
реальное конкурентное преимущество, которое требует соответствующей подготовки
и технологии работы.
Методы работы эргономиста позволяет изучить предполагаемую
на АРМе работу на основе наблюдений, интервью, анализа документов и проведения
испытаний на прототипах.
Возражения
"Пользователи не могут уделить время от их работ, чтобы участвовать
в анализе требований потребителя и тестировании прототипов."
«Это не вписывается в наше планирование, мы имеем очень сжатые
сроки, нам надо внедрить продукт уже через N месяцев.»
Оценка ситуации
Руководители проекта часто не имеют
возможности организовать контакт с реальными пользователями или заказчиками,
которые хорошо знают их трудовой процесс. Кроме того, традиционно в практике
разработки ПО российскими компаниями доля фазы проектирования намного меньше,
чем у аналогичных компаний, например, в Европе. Сокращения времени чаще всего
приходиятся на мало понятные по результату (с точки зрения руководителя
проекта) этапы проектирования взаимодействия системы с пользователем. Чаще всего проектирование клиентской части
рассматривает как процесс организации ввода – вывода данных для поддержки
серверной бизнес - логики.
Аргументация
Обычно сроки проектов очень жесткие. Но надо учитывать, что
даже если специально не планировать время на отдельные этапы проектирования
ПИ, такие, например, как анализ пользовательских требований, разработку принципов
интерфейса, разработку сценария диалога и пр., то они обязательно присутствуют
и реализуются в процессе жизненного цикла разработки ПО. В результате временной
ресурс все равно расходуется, но во внеплановом порядке и в большой степени.
Кроме того, время на проведение необходимых технологических
этапов по проектированию интерфейса можно масштабировать по величине в соответствии
со сроками проекта. Лучше должно сделать 5-дневный анализ требований пользователя
в процессе формирования функциональных требований к системе, чем отказаться
от него вообще.
Конечно, вовремя выйти на рынок с новым продуктом (новой
версией) важно для получения рыночного преимущества и сокращения времени окупаемости
капиталовложений. Но важно не только выпустить релиз, но также и не менее
важно появиться на рынке с продуктом необходимым и востребованным пользователями.
Преимущество создается не внедрением, а эффективным использованием продукта.
Если пользователь долго пытается разобраться, как пользоваться продуктом,
борясь с собственными привычными представлениями о «правильной работе», то
теряются все преимущества быстрого запуска продукта.
Возражение
«Мы не имеем бюджет для анализа требований пользователя.»
«Проведение оценки и тестирования прототипов требует значительных
дополнительных расходов на оплату работы тестеров.»
Оценка ситуации
У менеджеров проектов нет представления о том, какие результаты
можно получить, работая в непосредственном контакте с пользователями или их
представителями. Кроме того, менеджеры глубоко не вникают в технологию работы
эргономиста – методики, процедуры и пр. Как результат – менеджер проектов,
даже при желании внедрить необходимые эргономические этапы в процесс проектирования
ПО, не может заложить в смету расходов и обосновать затраты финансовому менеджеру
на данную деятельность.
Аргументация
Изучение потребностей пользователя на ранних этапах
анализа позволит спроектировать пользовательский интерфейс, соответствующий
целям и задачам пользователя, более адекватный автоматизируемым бизнес-процессам.
Выявление дополнительных требований и процедур на этапе тестирования и внедрения
продукта влечет за собой переделку готового продукта, и будет стоить намного
дороже для производства по сравнению с расходами на ранних этапах проектирования.
Возражение
«Ваши методы больше похожи на научные исследования, нежели
на практические технологии проектирования. Мы не - в университете. Мы – компания,
разрабатывающая конкретный программный продукт и не можем тратить ресурсы
на разработки, не имеющие реальной коммерческой отдачи.»
Оценка ситуации
Менеджеры в IT-компаниях направлены на конкретный коммерческий
результат в четко ограниченные сроки. Методы, применяемые эргономистами, отличаются
своей гуманитарной основой от технических методов, поэтому часто трудно предсказать,
какие результаты будут получены и как они будут интегрированы в документы
проекта.
Аргументация
Эргономические методы действительно используют некоторые
техники, которые использовались ранее в научных исследованиях. Однако, как
и многие другие технологии, родившиеся в академической среде, они были адаптированы
для коммерческих целей и успешно подтвердили свою эффективность в практике
проектирования. Сейчас широко используются техники общения для сбора требований
пользователя, способы анализа и построения концептуальной модели данных, методы
эргономической оценки прототипов пользовательского интерфейса, приемы компоновки
графических окон и пр.
При своей схожести по форме с научными методами, технологии
эргономического проектирования выполняют чисто утилитарную функцию. А именно
- дают в руки разработчиков средства получить конкретный результат при
описании и моделировании взаимодействия определенного типа пользователей с
конкретным программным продуктом. Наиболее эффективными результатами являются
список требований пользователя к продукту, нормативные показатели его работы,
сценарий работы пользователя, прототип графического (или звукового) интерфейса,
отзывы о работе с продуктом.
Возражение
«Пользователи не знают, что они хотят.»
«Пользователи противоречат в требованиях сами себе.»
«Сколько пользователей, столько и мнений. Каждый хочет увидеть
в интерфейсе нечто свое, на всех не угодишь.»
Продвинутый подход: «Вместо того, чтобы анализировать требования
пользователя, мы сделаем прототип и оттестируем это с пользователями."
Оценка ситуации
В проектах с сильно сжатыми сроками разработки
программисты сокращают этап бизнес-анализа до минимальных функциональных требований, известных
им по аналогам или предыдущим проектам. В отсутствии контакта и апробированных
методах сбора требований к пользовательскому интерфейсу, разработчики часто
пытаются предложить свое уже готовое решение пользователю, редко интересуясь,
устраивает ли оно их или нет. Практика и особенности конкретной работы пользователя
игнорируются, рабочее место пользователя проектируется на основе стандартных
и легко реализуемых, но чаще всего неудобных для пользователя элементов
интерфейса.
Аргументация
Пользователи действительно не являются специалистами
в области информационных технологий, и не могут сказать какие возможности
и ограничениях интерактивных систем можно применить для разработки их рабочего
места. Но они прекрасно знают, какие действия (бизнес-процедуры) они должны
совершать, чтобы выполнить свою задачу.
Существуют психологически обусловленные
алгоритмы работы пользователей, основанные на закономерностях восприятия и
обработке информации (однако, некоторые механизмы имеют социально-культурные различия, которые
надо учитывать в проектировании ПИ).
Пользователю хочется получить средства для стандартного выполнения
задачи в виде диалоговых процедур программного продукта. Такие средства трудно
разработать без знания типовых сценариев работы и привычных понятий пользователей,
что в свою очередь требует целенаправленной работы с пользователем от анализа
его требований до оценки и тестирования с его помощью прототипов.
Тестирование прототипа пользовательского интерфейса без начальной
формулировки требований и показателей к нему – бесполезное занятие с точки
зрения эффективности работы. Оно лишь позволяет отсеять грубые ошибки и недоработки
в процессе дизайна пользовательского интерфейса пользователя.
Без использования специальных методов дизайна интерфейса
есть больший риск получить если не опасный для психики и здоровья, то громоздкий
и неудобный для пользователя продукт. Эту работу должен выполнять профессионал,
который с одной стороны, знает особенности поведения человека, его трудовой
(или иной) деятельности, а с другой стороны возможности программных платформ
и интерфейсных библиотек.
Развитие информационных систем показывает, что конкуренция
продуктов из области функциональности перемещается в область удобства и комфортности
их для пользователей. В этих условиях, эргономические методы проектирования
становятся технологиями, обеспечивающие рыночный успех проекту. источник http://www.usability.ru/Articles/Andreev_VIII.htm
автора - Виктор Андреев
| 
