Лекция 14.

Проектирование пользовательского интерфейса. Основные принципы и этапы проектирования пользовательского интерфейса: выбор структуры диалога, разработка сценария диалога, определение и размещение визуальных компонентов. Гибкие интерфейсы. Средства поддержки пользователя, справочные системы

Пользовательский интерфейс – это совокупность информационной модели проблемной области, средств и способов взаимодействия пользователя с информационной моделью, а также компонентов, обеспечивающих формирование ин­формационной модели в процессе работы программной системы (слайд 14.1) .

Под информационной моделью понимается условное представление проблемной области, формируемое с помощью компьютерных (визуальных и звуковых) объектов, отражающих состав и взаимодействие реальных компонентов проблемной области.

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

Качество пользователь­ского интерфейса является самостоятельной характеристикой программного про­дукта, сопоставимой по значимости с такими его показателями, как надежность и эффективность использования вычислительных ресурсов.

Согласно исследованиям, проведенным компанией Xerox и ее сотруднику Дэвиду Лиддлу, пользовательский интерфейс состоит из следующих основных компонентов, представленных в виде айсберга.

Согласно данному исследованию, интерфейс состоит из трех основных частей - подачи информации пользователю, взаимодействию и взаимосвязям между объектами. При этом «видимая» часть айсберга значительно меньше его «невидимой», скрытой части (слайд 14.2). Верх айсберга - информация для пользователей (цвет, анимация, звук, форма объектов, расположение информации на экране, графика) составляет всего 10% и является отнюдь не самой важной составляющей пользовательского интерфейса. Следующая часть пользовательского интерфейса (30% модели проектировщика) - это техника общения с пользователем и обратная связь с ним. И, наконец, нижняя часть айсберга (60%) модели проектировщика - наиболее важная его часть - это свойства объектов и связи между ними.

14.1. Основные принципы проектирования пользовательского интерфейса

Основное достоинство хорошего интерфейса пользователя заключается в том, что пользователь всегда чувствует, что он управляет программным обеспече­нием, а не программное обеспечение управляет им.

Для создания у пользователя такого ощущения «внутренней свободы» интер­фейс должен обладать целым рядом свойств (слайд 14.4) :

Естественность интерфейса.

Согласованность интерфейса.

Дружественность интерфейса (Принцип «прощения пользователя»)

Принцип «обратной связи».

Простота интерфейса.

Гибкость интерфейса.

Эстетическая привлекательность.

Естественность интерфейса. Естественный интерфейс - такой, который не вынуждает пользователя суще­ственно изменять привычные для него способы решения задачи. Это, в частности, означает, что сообщения и результаты, выдаваемые приложением, не должны тре­бовать дополнительных пояснений.

Согласованность интерфейса. Согласованность позволяет пользователям переносить имеющиеся знания на но­вые задания, осваивать новые аспекты быстрее, и благодаря этому фокусировать внимание на решаемой задаче, а не тратить время на уяснение различий в использо­вании тех или иных элементов управления, команд и т.д. Обеспечивая преемствен­ность полученных ранее знаний и навыков, согласованность делает интерфейс узна­ваемым и предсказуемым.

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

Согласованность в пределах продукта. Одна и та же команда должна выполнять одни и те же функции, где бы она ни встре­тилась, причем одним и тем же образом.

Согласованность в пределах рабочей среды. Поддерживая согласованность с интерфейсом, предоставляемым операционной сис­темой (например, ОС Windows), пользовательское приложение может «опираться» на те знания и навыки пользователя, которые он получил ранее при работе с другими приложениями.

Согласованность в использовании метафор. Если поведение некоторого программного объекта выходит за рамки того, что обычно подразумевается под соответствующей ему метафорой, у пользователя могут возникнуть трудности при работе с таким объектом.

Дружественность интерфейса (Принцип «прощения пользователя»). Пользователи обычно изучают особенности работы с новым программным про­дуктом методом проб и ошибок. Эффективный интерфейс должен принимать во внимание такой подход. На каждом этапе работы он должен разрешать только соот­ветствующий набор действий и предупреждать пользователей о тех ситуациях, где они могут повредить системе или данным; еще лучше, если у пользователя суще­ствует возможность отменить или исправить выполненные действия.

Даже при наличии хорошо спроектированного интерфейса пользователи могут делать те или иные ошибки. Эти ошибки могут быть как «физического» типа (слу­чайный выбор неправильной команды или данных) так и «логического» (принятие неправильного решения на выбор команды или данных). Эффективный интерфейс должен позволять предотвращать ситуации, которые, вероятно закончатся ошибка­ми. Он также должен уметь адаптироваться к потенциальным ошибкам пользовате­ля и облегчать ему процесс устранения последствий таких ошибок.

Принцип «обратной связи». Необходимо всегда обеспечивать обратную связь для действий пользователя. Каждое дей­ствие пользователя должно получать визуальное, а иногда и звуковое подтверж­дение того, что программное обеспечение восприняло введенную команду; при этом вид реакции, по возможности, должен учитывать природу выполненного действия.

Обратная связь эффективна в том случае, если она реализуется своевременно, т.е. как можно ближе к точке последнего взаимодействия пользователя с системой. Когда компьютер обрабатывает поступившее задание, полезно предоставить пользо­вателю информацию относительно состояния процесса, а также возможность пре­рвать этот процесс в случае необходимости. Ничто так не смущает не очень опытно­го пользователя, как заблокированный экран, который никак не реагирует на его действия. Типичный пользователь способен вытерпеть только несколько секунд ожи­дания ответной реакции от своего электронного «собеседника».

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

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

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

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

Одной из методологических основ организации управления процессом обработки является использование «метафор» - содержательных аналогов целевой обработки данных, но в областях более обыденных для человека, чем автоматизация.

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

Пользователь может переносить информацию из одного документа в другой путем включения нужных частей одного документа в соответствующие места другого документа. Это связывается с другой метафорой – «буфером вырезок». До появления систем автоматизированной обработки текстов был традиционный способ облегчения верстки: вклейка вырезанного фрагмента вместо перепечатывания страницы. WIMP-интерфейсы обеспечивают аналогичные возможности вырезки и вставки, но при этом буфер, в который помещается вырезанный фрагмент, дает возможность вставки стольких копий элементов данных, сколько требуется.

Метафорический принцип положен и в основу технологии WISIWIG - немедленную визуализацию на экране результатов действий. Это означает, что экран должен имитировать средства полиграфической печати, и если пользователь хочет напечатать часть текста курсивом, то он и на экране должен быть набран курсивом. Если файл уничтожается, то пользователь видит, что файл исчезает из изображенного на экране списка файлов. Интерфейс в естественной форме обеспечивает пользователя информацией о состоянии объекта, подтверждая, что действие было выполнено. Можно сказать, что эта метафора более точно соответствует формуле «Ты видишь то, что получил в результате своих действий» .

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

Эстетическая привлекательность. Корректное визуальное представление используемых объектов обеспечивает передачу весьма важной дополнительной информации о поведении и взаимодействии различных объектов. В то же время следует помнить, что каждый визуальный элемент, который появляется на экране, потенциально требует внимания пользователя, которое, как известно, не безгранич­но.

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

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

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

Скорость решения задачи с помощью данного приложения; при этом должнооцениваться не быстродействие системы и не скорость ввода данных с клавиатуры, авремя, необходимое для достижения цели решаемой задачи. Исходя из этого, критерий оценки по данному показателю может быть сформулирован, например, так: пользо­ватель должен обработать за час не менее 20 документов с ошибкой не более 1 %.

Субъективная удовлетворенность пользователя при работе с системой (которая количественно может быть выражена в процентах или оценкой по n-бальной шкале).

На этой стадии собираются и анализируются данные о пользователях, формализуется функциональность и определяются объективные критерии успеха проекта.

Формализация контекста использования

Формализация объективных критериев успеха

Анализ целей

Формализация бизнес-ролей пользователей

Формализация функциональности

Формализация сценариев действий пользователей

Обзор интерфейса конкурирующих систем

Формализация привычек и ожиданий пользователей

Формализация контекста использования

На этом этапе собирается большинство сведений о пользователях. Описываются следующие свойства аудитории системы:

Характеристики пользователей: их опыт работы с компьютером, знание предметной области, мотивы, размер/важность групп пользователей, образцы (типовые ситуации) использования;

Цели и задачи пользователей;

Задачи проекта: что послужило причиной создания проекта, этапы создания проекта, какие результаты должны быть получены, какая информация необходима и когда;

Технология разработки и платформа, на которой будут работать пользователи;

Среда, в которой будет создаваться и использоваться проект (физическая, рыночная, организационная и культурная).

На входе: доступ к имеющимся и потенциальным пользователям системы, экспертам и проектной документации.

На выходе: описание контекста использования системы, возможно более детальное описание свойств пользователей.

наверх к оглавлению

Формализация объективных критериев успеха.

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

Соответственно, на данном этапе создается реальное задание на проектирование интерфейса. Например:

Группа пользователей постоянно меняет свой состав и предполагаемый образец использования используется нечасто. Необходимо акцентировать внимание на простоте понимания интерфейса.

Одна и та же задача повторяется многократно, а группа пользователей довольно большая. Необходимо акцентировать внимание на эффективности использования.

на 20% снизить количество человеческих ошибок.

На входе: доступ к пользователям, экспертам и проектной документации.

На выходе: список объективных критериев успеха.

наверх к оглавлению

Анализ целей

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

Разницу подходов к выбору функциональности удобно проиллюстрировать на примере тостера. Стандартный подход, при котором функции выбираются фактически произвольно, в лучшем случае приведет к такому заданию: «Нужен ящик с узкой прямоугольной дыркой и нагревателем внутри» . Анализ целей пользователя приведет к другой формулировке:«Нужен поджаренный хлеб. Похоже что проще всего добиться этого созданием ящика с дыркой по форму куска хлеба и нагревателем внутри. С другой стороны, похоже, что этот способ не единственный» . Второй вариант при полном развитии этого метода может привести не только к созданию тостера, но и также и ростера (т.е. устройства, в котором можно поджаривать не только хлеб).

Результатом этого процесса должен являться список целей, например, для тостера финальный список целей должен выглядеть очень просто: «Должен поджаривать мелкие кусочки пищи, преимущественно хлеб» .

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

На входе: доступ к пользователям, экспертам и проектной документации

На выходе: перечень целей внедрения нового интерфейса с весовыми характеристиками каждой.

наверх к оглавлению

Формализация бизнес-ролей пользователей

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

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

Обычно есть несколько разных способов реализации одной и той же функции. Анализ действий пользователей как раз и позволяет определить, какой именно способ следует реализовать. Поскольку на этом этапе мы узнаём, какая именно функциональность нужна для каждой бизнес-роли, можно избрать верный путь по правилу «чем меньше действий требуется от пользователя, тем лучше».

На выходе: описание бизнес-ролей пользователей.

наверх к оглавлению

Формализация функциональности

На этом этапе, основываясь на информации, выработанной на предыдущих этапах, окончательно формируется список функциональных возможностей новой версии системы. Ранее сформированное ТЗ порой не включает части необходимой функциональности, либо содержит функциональность, реально не требующуюся, пользователям.

На входе: доступ к пользователям, экспертам и проектной документации, знание основных аспектов предметной области.

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

наверх к оглавлению

Формализация сценариев действий пользователей

На этом этапе частично изучаются, частично разрабатываются типовые сценарии действий пользователя: формализуются данные, необходимые пользователям для выполнения работы, последовательность самой работы, критерии завершенности этой работы.

Цель этого этапа – написать словесное описание взаимодействия пользователя с системой, не конкретизируя, как именно проходит взаимодействие, но уделяя возможно большее внимание всем целям пользователей. Количество сценариев может быть произвольным, главное, что они должны включать все типы задач, стоящих перед системой, и быть сколько-нибудь реалистичными. Сценарии очень удобно различать по именам участвующих в них вымышленных персонажей.

Предположим, что необходимо разработать сценарии для будущей почтовой программы. Судя по всему, для этой задачи необходимо три сценария:

Елизавета Петровна запускает почтовую программу. Она включает процесс скачивания новой почты. Получив почту, она читает все сообщения, затем часть их удаляет, а на одно сообщение отвечает. После чего выключает почтовую программу.

Андрей Фёдорович делает активным окно уже открытой почтовой программы и включает процесс скачивания новой почты. Получив почту, он ее читает. Одно сообщение он пересылает другому адресату, после чего удаляет его, а еще одно печатает. После чего переключается на другую задачу.

Пришло новое сообщение, и системный администратор Андрей воспринимает соответствующий индикатор. Он делает активным окно почтовой программы и открывает полученное сообщение. Он читает его, после чего перемещает его в другую папку. После чего переключается на другую задачу.

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

На входе: доступ к пользователям, экспертам и проектной документации, знание основных аспектов предметной области.

На выходе: сценарии работы пользователей (разработанные сценарии, как правило, представляются в виде блок-схем, описывающих весь процесс использования системы для выполнения той или иной задачи).

наверх к оглавлению

Обзор интерфейса конкурирующих систем

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

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

На входе: доступ к конкурирующим системам.

На выходе: обзор преимуществ и недостатков интерфейса конкурирующих систем.

наверх к оглавлению

Формализация привычек и ожиданий пользователей

На данном этапе изучаются субъективные ожидания пользователей от системы. Без этого исследования трудно или невозможно предугадать отношение пользователей к будущей системе.

На входе: доступ к пользователям.

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

Базовые требования к веб интерфейсу сформулированы Якобом Нильсеном в виде , которые не теряют своей актуальности с 1990 года, когда они были впервые опубликованы. Впоследствии этот список был доработан, расширен, формализован и лег в основу

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

5 этапов создания интерфейса

В зависимости от потребностей клиента и степени готовности проекта мы можем проектировать:

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

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

Анализ

По порядку собираем, изучаем и анализируем всю нужную для создания веб интерфейса информацию:

1. Потребности бизнеса: для чего создается проект, какие бизнес-задачи он должен решать, как будет монетизироваться в дальнейшем.
2. Потребности аудитории: зачем проект аудитории, чего именно хотят пользователи, какие именно их проблемы и боли решает проект.
3. Базовые характеристики и уникальные преимущества проекта на уровне идеи: почему именно этот проект может решить задачу лучше, чем конкуренты, что для этого нужно.
4. Точки соприкосновения: в каком месте интересы аудитории и бизнеса пересекаются - ищем драйверы для создания оптимальных пользовательских сценариев.

Что именно мы изучаем:

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

Основная задача - собрать в одном документе всю доступную информацию по сайту, обработать ее и окончательно определиться, куда именно и как нужно двигаться в дальнейшей работе.

Представление

1. Формируем концепцию будущего проекта, продумываем и создаем пользовательские истории.
2. Разрабатываем информационную архитектуру и определяемся с функционалом системы.
3. Продумываем пользовательские сценарии и особенности взаимодействия пользователей с интерфейсом.

На этом этапе формируется скелет интерфейса и определяются принципы и правила внутренней работы системы и ее взаимодействия с пользователями. Фактически это самый важный этап проектирования, так как именно здесь закладывается базовая логика проекта.

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

Прототипирование

Непосредственное создание прототипа интерфейса веб-сайта, его отрисовка в Axure, графическом редакторе или любой другой программе. На этом этапе идеи и решения уже нужно

Обычно для одного интерфейса разрабатывают несколько равноценных версий. В ходе A/B-тестирований, по результатам интервью и онлайн опросов выбираются решения, которые в большей степени соответствуют бизнес-задачам и потребностям аудитории.

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

Плохая новость: возможно, придется вернуться к началу и провести дополнительные исследования.

Хорошая новость: если найти и исправить недочеты на этом этапе, то их не придется исправлять в готовом продукте, что стоит на порядок дороже.

Дизайн и разработка

По результатам юзабилити-тестов и на основе утвержденного с клиентом прототипа создается графическое оформление интерфейса. На этом же этапе разрабатывается функционал и бэкенд проекта.

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

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

Аналитика

Готовый продукт уже после релиза проходит самую важную проверку - в условиях реального мира. Пользователи, как правило, взаимодействуют с интерфейсом естественным образом - они не ограничены рамками исследования, на них не давит необходимость сделать по результатам тестов отчет, они не думают о том, как выглядят в глазах организатора исследования.

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

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

Итоговые выводы

• Базовые принципы проектирования интерфейсов описаны в эвристиках Нильсена и в стандарте ISO 9241-110.
• Проектирование осуществляется на трех уровнях: логика, функционал, графическое представление.
• В процессе можно выделить 5 этапов: предпроектный анализ, представление, прототипирование, дизайн и разработка, аналитика.
• Тестирование и проверка идей, теорий и решений - непрерывный процесс и начинается с того самого момента, когда у нас появляются первые скетчи и наброски прототипов.
• Готовый интерфейс тестируется как с привлечением респондентов, так и средствами веб-аналитики на реальных пользователях - по итогам тестов формируется техзадание для его последующей доработки.

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

Разработка пользовательского интерфейса (ПИ) ведется параллельно разработке программного продукта в целом и в основном предшествует его внедрению. Процесс разработки эргономичного ПИ разбивается на следующие этапы:

1. Постановка задачи.

На этой стадии собираются и анализируются данные о пользователях, формализуется функциональность, и определяются объективные критерии успеха проекта.

Формализация контекста использования

Описываются следующие свойства аудитории системы:

Характеристики пользователей: их опыт работы с компьютером, знание предметной области, мотивы, размер/важность групп пользователей, образцы (типовые ситуации) использования;

Цели и задачи пользователей;

Задачи проекта: что послужило причиной создания проекта, этапы создания проекта, какие результаты должны быть получены, какая информация необходима и когда;

Технология разработки и платформа, на которой будут работать пользователи;

Среда, в которой будет создаваться, и использоваться проект (физическая, рыночная, организационная и культурная).

Формализация объективных критериев успеха.

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

Анализ целей

Разработчику необходимо четко осознавать, что пользователям не нужны инструменты сами по себе, нужны лишь результаты их работы.

Никому не нужен текстовый процессор - нужна возможность с удобством писать тексты. Никому не нужна программа обработки изображений - нужны уже обработанные изображения. Это значит, что сами по себе функции никому не нужны и не важны. Людям нужно средство вообще, делающим возможным выполнять какую-либо работу .

Формализация бизнес-ролей пользователей

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

Формализация сценариев действий пользователей

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

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

Обзор интерфейса конкурирующих систем

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

2. Высокоуровневое проектирование

На этой стадии начинается непосредственное проектирование интерфейса; предыдущие этапы посвящены исключительно сбору данных и постановке задачи.

Проектирование структуры экранов системы

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

По сути, на этом этапе выделяются отдельные функциональные блоки. Под функциональными блоками будем подразумевать функцию или группу функций, связанных по назначению или области применения в случае программы и группу функций/фрагментов информационного наполнения в случае сайта.

Существует три основных вида связи между блоками. Это логическая связь, связь по представлению пользователей и процессуальная связь .

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

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

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

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

Процессуальная связь. Процессуальная связь описывает не вполне логичное, но естественное для имеющегося процесса взаимодействие.

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

Проектирование навигационной системы

На основе разработанной ранее структуры экранов на этом этапе выбирается наиболее адекватная навигационная система и разрабатывается её детальный интерфейс.

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

Проектирование структуры справочной системы

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

3. Низкоуровневое проектирование

Разрабатываются интерфейсы конкретных экранов системы (состав, взаимное расположение и поддерживающие текст интерфейсных элементов).

Проектирование основных экранов

На данном этапе разрабатываются интерфейсы основных экранов системы.

Тестирование

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

Проектирование второстепенных экранов

На данном этапе разрабатываются интерфейсы второстепенных экранов системы. К ним относятся диалоговые окно и всевозможные сообщения.

Финальное тестирование

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

Наиболее известные языки проектирования на 2010 год:

VHDL (англ. VHSIC (Very high speed integrated circuits) Hardware Description Language) - язык описания аппаратуры высокоскоростных интегральных схем. Язык проектирования VHDL является базовым языком при разработке аппаратуры современных вычислительных систем.

Был разработан в 1983 г. по заказу Министерства обороны США с целью формального описания логических схем для всех этапов разработки электронных систем, начиная модулями микросхем и заканчивая крупными вычислительными системами.

Verilog - это язык описания аппаратуры, используемый для описания и моделирования электронных систем. Этот язык (также известный как Verilog HDL) позволяет осуществить проектирование, верификацию и реализацию (например, в виде СБИС) аналоговых, цифровых и смешанных электронных систем на различных уровнях абстракции SystemC - язык проектирования и верификации моделей системного уровня, реализованный в виде C+ библиотеки с открытым исходным кодом. Библиотека включает в себя ядро событийного моделирования, что позволяет получить исполняемую модель устройства. Язык применяется для построения транзакционных и поведенческих моделей, а также для высокоуровневого синтеза. ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который

Обеспечивает Наглядность) - визуальный алгоритмический язык, созданный в рамках космической программы Буран. Разработка данного языка была начата в 1986 г. под руководством Владимира Паронджанова. В разработке языка принимали участие Российское космическое агентство (НПЦ автоматики и приборостроения им. акад. Н.А. Пилюгина, г. Москва) и

Российская академия наук (Институт прикладной математики им. акад. М.В. Келдыша).

Одно из задач, ставившихся перед разработчиками, было создание единого универсального языка, который должен был заменить специализированные языки ПРОЛ2 (для разработки бортовых комплексных программ Бурана), ДИПОЛЬ (для создания наземных программ Бурана) и ЛАКС (для моделирования) .

Работы по разработке языка были закончены в 1996г. (спустя 3 года после закрытия программы Буран), когда была создана автоматизированная технология проектирования программных систем (CASE-технология)

Язык ДРАКОН может удачно применяться для специфицирования протоколов взаимодействия (например, клиент-серверных). UML (сокр. от англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

Заключение

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

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

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

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

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

Пользовательский интерфейса включает также программы обучения, справочный материал, возможность подстройки внешнего вида программ и содержания меню под надобности пользователей (индивидуальные настройки) и другие сервисы. Сюда же входят дизайн, пошаговые подсказки и визуальные реплики (использование «Помощника»). Однажды грамотно разработанный интерфейс пользователя позволяет экономить время пользователей и разработчиков.

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

Международная организация по стандартам (International Standard Organization, ISO) и другие организации (МСЭ, МЭК и др.). Обычно разработанные ими стандарты носят рекомендательный характер.

Процесс разработки эргономичного пользовательского интерфейса разбивается на следующие этапы:

1. Постановка задачи, где собираются и анализируются данные о пользователях, формализуется функциональность, и определяются объективные критерии успеха проекта.

2. Высокоуровневое проектирование, на котором начинается непосредственное проектирование интерфейса, предыдущий этап посвящен исключительно сбору данных и постановке задачи.

3. Низкоуровневое проектирование, где разрабатываются интерфейсы конкретных экранов системы (состав, взаимное расположение и поддерживающие текст интерфейсных элементов).

Большинство программных продуктов, ориентированных на конечного пользователя, работают в диалоговом режиме взаимодействия с пользователем, при котором ведется обмен сообщениями, влияющими на обработку данных. При проектировании ПИ необходимо определить:

1. Структуру диалога.

2. Возможный сценарий развития диалога.

4. Визуальные атрибуты отображаемой информации (синтаксис сообщений)

Список использованной литературы

1. Баканов А.С., Обознов А.А. Проектирование пользовательского интерфейса: эргономический подход - М.: Изд-во «Институт психологии РАН», 2009. - 184 с.

2. Благодатских В.А. Стандартизация разработки программных средств: Учеб. пособие. - М.: Финансы и статистика, 2003. - 288 с.

3. Бурцева Е.В., Селезнёв А.В., Терехов А.В. Информационные системы: Учеб. пособие. - Тамбов: Изд-во Тамб. гос. техн. ун-та, 2009. - 128 с.

4. Волков А.К. Информационные технологии (для экономиста): Учебное пособие. - М.: ИНФРА-М, 2001. - 310с.

5. Гаврилов М.В. Информатика и информационные технологии: Учебник для вузов. - М.: Гардарики, 2006.

6. http://www.km.ru/referats/6893BB3095D64A08BC33DCF5ADB20A88

7. http://www.km.ru/referats/6893BB3095D64A08BC33DCF5ADB20A88

Я хотел бы дать вам простой, но парадоксальный совет: не верьте всему, что говорят про проектирование.

Всё дело в том, что проектирование в веб-разработке в силу многих исторических причин развивалось через пень-колоду и до сих пор представляет собой размытое, плохо описанное и мало кем понятое определение. Ситуация потихоньку выправляется в последние годы, но разъяснительной работы предстоит много - а потому любому, кто хочет разобраться в проектировании, нужно включать свою голову и не бояться подвергать сомнению каждую прописную, казалось бы, истину.

Таких «прописных» истин много, и они вместе рождают страшный и ужасный набор мифов про проектирование - о самых главных из них я бы и хотел сегодня поговорить.

Миф № 1. Проектирование - это дополнительная услуга

Проектировщик, занятый важным общественно-полезным делом

Многие считают, что этап проектирования - это дополнительная услуга, которой можно пренебречь. Это не так.

Ради чего мы создаем IT-продукты? Если мы находимся в своём уме и доброй памяти, мы создаем их ради решения бизнес-задач (своих собственных или своих клиентов - не так важно); решение этих бизнес-задач, в свою очередь, опирается на выполнение создаваемым продуктом задач пользователей с учётом условий рынка, технологических ограничений и всего прочего.

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

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

Можно ли сделать сколь-нибудь сложный и полезный продукт, миновав все эти этапы? Согласитесь: вряд ли. А между тем все описанные процессы и составляют то, что принято называть проектированием - анализ (разбор условий задачи), синтез (формирование продукта) и фиксация (составление правильной проектной документации).

Проектирование не может быть дополнительной услугой , коль скоро это плоть от плоти веб-разработки и нацелено на понятный результат, а не на освоение бюджетов или борьбу за всё хорошее против всего плохого.

Миф № 2. Проектирование стоит дорого

Менеджер проекта выколачивает бюджет из заказчика

Бытует мнение, что этап проектирования только удорожает продукт.

В этой связи я обожаю цитировать Карла Вигерса - патриарха системного проектирования, автора чудесной книги «Разработка требований к программному обеспечению» и просто умного человека.

Карл Вигерс как-то провел исследование американского рынка IT-разработки и подсчитал, что в среднем 40% бюджетов разработки тратится впустую , причём эти деньги теряются не по вине криворуких разработчиков или плохих заказчиков, а всего лишь потому, что две стороны - заказчик и разработчик - просто не смогли договориться между собой .

Сорок процентов - и это для Америки, где царят совершенно иные отношения между заказчиком и разработчиком! Для России, мне кажется, эта цифра ещё выше - раза эдак в полтора.

При этом правильное системное проектирование, по подсчётам того же Вигерса, отнимает 15-20% бюджетов на разработку (и эта цифра полностью подтверждается нашим опытом).

Получается интересный эффект: мы тратим фиксированные 15-20% на проектирование, но при этом сводим к минимуму «пустые» траты (те самые 40% бюджета), которые потенциально могут похоронить проект и, к тому же, чрезвычайно затягивают сроки получения работоспособного продукта.

Таким образом, стоимость правильного проектирования парадоксальным образом влияет на стоимость всего проекта в целом: с одной стороны, этап проектирования не бесплатен и отнимает определённое количество бюджета, но с другой - снижает стоимость всего проекта в целом за счёт снятия рисков, связанных с плохо продуманным и потому непредсказуемым продуктом.

Миф № 3. Проектирование - это написание ТЗ

Слон, сделанный по ТЗ

Часто приходится слышать, что проектирование - это процесс написания ТЗ, который можно приложить к договору. Это не так.

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

• проектирование позволяет учесть интересы пользователей (и тем самым минимизировать риски разработки);
• проектирование позволяет учесть интересы заказчика (и тем самым минимизировать риски разработки);
• проектирование позволяет учесть все значимые внешние факторы (и тем самым минимизировать риски разработки);
• проектирование позволяет сторонам получить единое видение продукта (и тем самым минимизировать риски разработки);
• проектирование позволяет точно спрогнозировать сроки и стоимость разработки (и тем самым… ну, вы поняли).

Написание ТЗ - это всего лишь один из инструментов, который позволяет однозначно, достаточно, системно и отчуждаемо зафиксировать требования к продукту в формате, понятном для разработчика. Да, этот инструмент можно назвать важнейшим, но этап проектирования несёт куда более важную задачу - и это нужно помнить.

Миф № 4. Проектирование - это про пользовательские интерфейсы

Продукт с продуманным дружественным интерфейсом

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

Действительно, интерфейсы - это самая заметная часть продукта: именно с ней будут контактировать пользователи, которые будут выполнять при помощи продукта свои задачи и тем самым способствовать выполнению задач заказчика.

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

Пользовательский интерфейс - это всего лишь один из компонентов продукта, служащий для доступа пользователей к функциям и данным продукта. Проектировать его важно, но ограничиваться только им - вредно.

Миф № 5. Проектировать может и менеджер

Менеджер, занятый профильной активностью

Как мы уже выяснили, проектирование - сложный процесс, связанный с кропотливой, тонкой работой. Чтобы проектирование выполняло свои задачи, эта работа должна быть выполнена максимально качественно и вдумчиво. Проектирование, иными словами, требует от исполнителя наличия очень специфической системы ценностей, где качество работы и персональная ответственность будут превыше всего.

При этом проектирование часто отдают в руки менеджерам как людям, которые сводят воедино все процессы и нити разработки. Казалось бы, всё логично и правильно, но не учитывается один важный момент: у хороших менеджеров совершенно иная система ценностей, где во главе всего стоят сроки проекта и его бюджет.

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

И так будет на всем протяжении разработки. Если к этому ценностному аспекту прибавить аспект профессиональный (всё-таки проектировщик должен уметь многое из того, что не обязан знать менеджер), то легко понять, почему проектированием должен заниматься отдельный, специально обученный человек со своей системой ценностей.

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

Миф № 6. Проектированием должны заниматься психологи

Техническое содержание продукта по версии психолога

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

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

Миф № 7. Проектирование должны заниматься инженеры

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

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

Кто же такой проектировщик?

Кем же должны быть проектировщики? Это очень сложный вопрос, на который я вкратце могу ответить так.

• Стоит смириться, что на «правильных» системных проектировщиков нигде пока не учат.
• Чаще всего правильный проектировщик рождается на стыке между условными гуманитарными и техническими науками.
• Чаще всего хороший проектировщик не знает, что он - хороший проектировщик, и работает по левой специальности, которая его не радует.
• У такого «неактивированного» хорошего проектировщика шизофренический послужной список, околотехническое образование, широкий кругозор и склад ума хорошего классического инженера.
• Проектировщик должен понимать дизайнеров, разработчиков, заказчиков и пользователей.
• Проектировщик должен уметь общаться с людьми.

Лично мой опыт показывает, что проектировщик - понятие скорее врождё нное: обучить проектировщика нужным инструментам и приёмам можно относительно быстро (серьёзно, от трёх месяцев до полугода), а вот вложить в него нужную систему ценностей и склад ума практически невозможно.

Но такие люди есть - и именно для их поиска и формирования я создал в свое время Гильдию вольных проектировщиков, и это тоже отдельная тема для разговора.

Единого подхода к проектированию не существует

Проектировщик не выдерживает накала страстей на проекте

Подходов к проектированию много, и неискушенный читатель может запросто сойти с ума от обилия приемов, подходов и аббревиатур, щедро сдобренных терминологическим бардаком (всеми этими UX, UI, CX, HCD и прочими IDDQD с кривыми русскоязычными аналогами).

Некоторые, впрочем, пытаются вывести универсальные модели проектирования, но в итоге получается так, что в попытке объединить существующие 20 (условно) подходов к проектированию мы получаем в итоге 21 подход - и методологии, как кажется, начинают плодить самих себя.

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

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

Вместо заключения

Итак, что мы с вами сегодня выяснили?

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

И последняя просьба: не верьте на слово даже мне - я буду только рад, если вы не будете не соглашаться со мной и отстаивать свою точку зрения: это будет поводом для полезного и большого разговора, в ходе которого может появиться очередная истина - и это ли не здорово?