Продолжение
4. О методах проектирования
Для того чтобы сделать программы более человечными, существует ряд методик, используемых проектировщиками. Главная из них — «персонажи».
Перед началом разработки проектировщики проводят исследование с целью выявления портрета будущего пользователя. Кажется, что правильно было бы найти реального пользователя и проектировать для него. Но такой подход плох — нельзя найти среднего пользователя, у каждого человека есть свои индивидуальные особенности, и невозможно подстроить программу под все особенности каждого человека. Вместо этого намного эффективнее выдумать пользователя с усредненными свойствами. Это не будут реальный человек, но гипотетический архетип. Этот вымышленный пользователь и будет персонажем, для которого происходит проектирование.
Процесс подбора и описания персонажа очерчивает круг будущих пользователей, людей, для которых эта программа должна быть привлекательна. Логика подсказывает, что лучше придумать несколько персонажей, однако на деле это приводит к созданию продуктов, которыми не будет пользоваться никто. Нельзя сделать программу удобной и для офисного работника, и для пожилой домохозяйки — это слишком разные люди. Опыт показывает, что в действительности бывает обратный процесс. Продукт, спроектированный для одного персонажа, неожиданно становится популярным для других людей.
Так, чемодан с колесиками был изначально придуман для членов экипажей самолетов, но после его создания пассажиры самолетов быстро оценили его преимущества.
Для эффективного проектирования персонаж должен быть предельно конкретным, следует описывать его до мелочей, как будто это реальный человек. Чем больше деталей, тем лучше. У него должно быть имя, вы должны знать, где он работает, сколько у него детей, на какой машине он едет на работу и так далее. Описание не должно быть идеальным, но непременно должно быть подробным. Подробности помогают действительно понять, что для персонажа является «удобным».
Преимущества ввода персонажа:
1. Он дает представление о реальном уровне подготовленности («компьютерной грамотности») потребителей.
2. Персонажи закрывают споры о функциях. В диалоге с программистом на его вопрос «Почему бы нам не добавить функцию вывода на печать?» проектировщик может ответить, что персонажу не нужна печать, и описать причины, по которым он так считает, обращаясь к фактам, касающимся персонажа.
3. Персонажи дают всем участникам процесса разработки единую систему отсчета, точку опоры. Это дает представление о стадии работы и готовности продукта — продукт можно считать готовым, только когда цели персонажа удовлетворены.
У процесса проектирования должны быть четкие цели. Проектирование без целей — все равно что отсутствие проектирования. Под целями проектирования понимаются цели персонажа. Цели (так же как и персонаж) — это твердая точка опоры для принятия решений в ходе разработки. Для проектирования важны все цели персонажа, как практические, так и личные.
Процесс проектирования достигает поставленных целей путем решения задач. В то время как цели неизменны, задачи зависят от технологий, доступных способов решения.
Не менее важно, ориентируясь на практические цели персонажа, помнить, что любой человек в первую очередь не хочет чувствовать себя дураком, быть кем-то раскритикованным за неумение справиться с программой, не хочет испытывать раздражение при использовании продукта — в этом заключаются его личные цели. Программистам свойственно игнорировать личные цели пользователей, так как им не знакомы такие чувства. Типичные личные цели любого человека при использовании техники:
• Не чувствовать себя глупо.
• Не совершать ошибок.
• Выполнять адекватный объем работы.
• Развлечься (или хотя бы не страдать от скуки).
Помимо личных и практических целей пользователя, также существуют два других типа целей: корпоративные и ложные цели. Корпоративные цели ставят перед профессиональными программами, которыми пользуются сотрудники компаний. Типичные корпоративные цели:
• Увеличить прибыль.
• Увеличить рыночную долю.
• Победить конкурентов.
• Нанять больше сотрудников.
• Предложить новые продукты и услуги.
Корпоративные цели нельзя игнорировать, однако их можно назвать «гигиеническими». Проектирование решает их лишь косвенно, потому что в конце концов программами будут пользоваться люди, а их интересуют практические и личные цели. Можно сказать, что практические цели соединяют корпоративные цели компании и личные цели работника, который будет использовать программу.
Ложные цели — это цели, поставленные перед проектированием ПО в терминах программирования. На первый взгляд такие цели действительно относятся к конечному пользователю, однако не стоит путать их с настоящими целями проектирования, потому что они сформулированы в терминах архитектуры кода и технических требований, иначе говоря, в терминах задач, а не целей. Типичные примеры ложных целей:
• Экономия памяти.
• Улучшение внешнего вида.
• Обеспечение целостности данных.
• Простота в освоении.
• Поддержка работы во всех браузерах.
• Уменьшение потребности в клавиатурном вводе.
Естественно, при использовании нового устройства человек неизбежно должен будет приложить какие-то усилия. Чтобы сделать этот опыт безболезненным, необходимо соблюдать важный в проектировании принцип соразмерности усилий: человек с радостью приложит усилия, чтобы научиться пользоваться продуктом, если будет видеть, что продукт «идет ему навстречу» и «прилагает усилия», чтобы помочь разобраться.
Так как люди часто эмоционально реагируют на «поведение» программы, вплоть до ведения словесной беседы с компьютером, проектировщикам необходимо делать поведение программ таким, чтобы взаимодействие с программой было похоже на общение с приятным (воспитанным, вежливым) человеком. «Вежливая» программа соответствует ряду характеристик:
• Интересуется мной — тем, кто я такой, что мне нравится, запоминает мои прошлые предпочтения.
• Относится ко мне уважительно — предлагает, а не приказывает; предполагает, а не заключает.
• Обходительна — она должна выстраивать предположения о моих дополнительных потребностях, даже если я не спросил о них напрямую, если это разумно и вероятно с точки зрения человека.
• Ведет себя разумно — в интерфейсе большинства программ востребованные и простые функции расположены вперемежку со сложными настройками для немногочисленных профессионалов.
• Предвидит мои потребности — компьютер может легко подготовиться к моим возможным действиям; например, браузер может начать заранее загружать страницы по доступным на текущей странице ссылкам, тогда мне не придется ждать, когда я нажму на одну из ссылок.
• Отзывчива — компьютер часто может самостоятельно отреагировать на мои действия и имеет для этого все возможности, но не делает этого и заставляет меня делать дополнительную работу вручную.
• Не склонна делиться своими личными проблемами — программы часто сообщают совершенно ненужную мне техническую информацию: коды ошибок, состояние памяти компьютера и так далее.
• В курсе происходящего — программы иногда предлагают воспользоваться функциями, которые оказываются недоступны в данный момент, хотя этого можно было избежать и не тратить время пользователя.
• Проницательна — например, одни люди предпочитают использовать окна программ развернутыми на весь экран, другие предпочитают маленькие окна, чтобы видеть файлы на рабочем столе; проницательная программа должна была бы запомнить мои предпочтения и создавать новые окна в соответствии с ними.
• Уверена в себе — компьютеру не следует постоянно спрашивать у меня подтверждения действий, вместо этого лучше давать возможность отменить их, если я действительно совершил ошибку.
• Всегда сосредоточена — такая программа не задает лишних вопросов, которые уводят меня от выполнения текущей задачи.
• Покладиста — цифровые системы часто требовательны к человеку, заставляя вводить точные и полные данные; люди привыкли (и это удобно) иметь возможность оставить какую-то работу на потом или перескочить какой-то шаг процесса, оставив его на потом.
• Дает мгновенное удовлетворение — программа не должна откладывать вознаграждение пользователя на момент, когда он проделает огромное количество работы, она должна поощрять человека чаще.
• Ей можно доверять — вежливая программа заслуживает доверия и избавляет меня от желания лишний раз проверять правильность ее работы.
Еще один важнейший инструмент проектирования — сценарии. Сценарии представляют собой описание ситуаций и поведения персонажа в этих ситуациях. Здесь детализация персонажа играет большую роль — она помогает проектировщикам вжиться в роль и создавать реалистичные сценарии. Это похоже на воображаемую актерскую игру в кино. Сценарии создаются на основе информации, собранной в ходе первоначального исследования — интервью и наблюдения за будущими пользователями. Сценарий должен описывать процесс от начала до конца. В сценарии не следует включать исключительные ситуации.
Повседневные сценарии — самые полезные и важные. Они описывают основные действия, которые происходят чаще всего. Например, для календаря повседневные сценарии — это добавление нового события и поиск по существующим событиям. У программ бывает не больше 2–3 повседневных сценариев. Эти сценарии нуждаются в самом качественном взаимодействии с пользователем, так как работа с ними происходит наиболее часто.
Обязательные сценарии — это ситуации использования, которые возникают нечасто, но обязательно должны быть реализованы в программе. Количество обязательных сценариев обычно также невелико, но, как правило, их чуть больше, чем повседневных.
В реальности существуют исключительные сценарии, и им почему-то уделяют особое внимание программисты. Однако проектировать взаимодействие для таких сценариев можно грубо и прятать его в глубине интерфейса. Программа должна учитывать исключительные ситуации, но успех продукта зависит от того, как она справляется с повседневными и обязательными сценариями.
Персонажи, цели и сценарии — это тяжелая артиллерия проектирования. Эти инструменты используются в каждом проекте.
Есть еще ряд второстепенных инструментов и хитростей.
• Адаптирующийся интерфейс. В каждый момент времени пользователю, как правило, нужны лишь некоторые функции программы. Хитрость в том, чтобы в зависимости от контекста скрывать от него функции, ненужные в данный конкретный момент.
• В ходе проектирования необходимо помнить, что подавляющее большинство пользователей можно считать «середняками» в обращении с техникой. Они редко бывают новичками или экспертами.
• Полезно представлять себе ситуации и строить предположения, не думая о технических ограничениях. Если в процессе проектирования изначально задавать их, то будет невозможно сосредоточиться на целях — вы будете работать в контексте задач.
• В процессе проектирования всем участникам проекта следует выработать и конкретизировать свой словарь терминов. Распространено явление, когда люди, работающие над одним продуктом, обозначают одними и теми же словами совершенно разные сущности.
• Если в коллективе уже сложились какие-то внутренние термины, то следует при работе по проектированию избегать таких слов, а вводить и использовать новые понятия. Старые понятия могут нести с собой груз предвзятого понимания, родившийся в другом контексте или под влиянием ложных целей.
В попытках сделать свои продукты лучше компании часто применяют в разработке процессы, которые, по их представлению, должны усовершенствовать тот или иной продукт. Многие из этих методов действительно оказывают хорошее влияние на продукты, но не решают проблемы проектирования в целом.
Например, распространена практика юзабилити-тестирования. Готовую программу дают в руки реальных пользователей, наблюдают за ними, из наблюдений делают выводы и «доводят» программу в соответствии с полученными данными. Такой подход не ориентирован на цели пользователей, а изменения, вносимые в уже готовую программу, едва ли могут что-то принципиально улучшить — большая часть работы уже позади. Тестирование уже выпущенного продукта помогает «отшлифовать» его, но ошибки, допущенные в самом начале, уже не исправить.
Часто встречается практика проектирования, когда группа проектировщиков собирается из представителей всех задействованных в создании продукта сфер: маркетологов, менеджеров, программистов, пользователей и тестировщиков. Однако такой подход не решает проблему, так как у всех участников «круглого стола» различные интересы и многие из них отличаются от интересов пользователей программы. Проектирование — это профессиональная сфера, в которой должны работать специальные люди.
Еще один путь улучшения программ — использование фокус-групп. В разработке программ — в области с невероятно высоким когнитивным сопротивлением — ориентация на фокус-группы может не только оказаться бесполезной, но и приводить к проблемам. Участники фокус-групп в своих предложениях опираются на негативный опыт использования плохо спроектированных программ и оказываются в плену этого опыта. Они часто озвучивают недальновидные и некомпетентные требования, а многие из них просто боятся предлагать действительно интересные идеи из страха показаться глупыми.
Должное проектирование, выполненное до начала программной разработки, дает руководителям контроль над продуктом. Разработку ПО можно сравнить с созданием фильма — в начале пишется сценарий и проводится подготовительная работа, и только когда заранее определен и описан процесс съемки, начинается непосредственно съемка. После съемок происходит монтаж и продвижение на рынке. В разработке можно соответственно выделить стадии проектирования, программирования и отладки. Как в кино, так и в разработке подготовительная стадия позволяет минимизировать длительность средней стадии. В обоих случаях первая стадия — это способ быстро и дешево избежать ошибок, которые на более поздних стадиях могут обойтись значительно дороже. Проектирование помогает контролировать самый непредсказуемый процесс в разработке — непосредственно написание кода.
Проектирование полезно всем:
• Проектирование полезно и выгодно для программистов, потому что делает их работу более определенной, снижает уровень стресса. Когда все с самого начала ориентируются на описанное и единое видение проекта, снижается вероятность, что придется существенно переписывать код на поздней стадии, а для программистов это огромный бонус.
• Проектирование полезно для маркетинга, потому что маркетологи могут ориентироваться на персонажа, выведенного в процессе проектирования. По сути, проектировщик, помимо прочего, является связующим звеном между маркетингом и программированием — он переводит язык маркетологов на язык программистов. Также проектирование за счет работы с целями персонажей дает маркетологам понимание того, как следует описать преимущества продукта покупателям.
• Проектирование помогает в разработке документации и в технической поддержке. Чем лучше проектирование — тем проще будет документация и тем проще будет работа технической поддержки.
• Проектирование однозначно полезно для руководителей разработки — процесс обретает единую для всех участников плоскость координат, объединяет терминологию всех уровней компании. Для руководителя процесс создания программного продукта и его успех на рынке становятся более предсказуемыми и прогнозируемыми.
Заключение
Программные продукты больше других подвержены когнитивному сопротивлению — пользователям тяжело предсказать их поведение и понять, как они устроены.
Программы следует делать более удобными, чтобы привлекать своих потребителей.
Для цифровых продуктов повышение качества значительно важнее, чем снижение издержек, так как для пользователя удобный продукт всегда привлекательнее более «мощного», но неудобного.
Для повышения качества программ необходимо проектирование пользовательского взаимодействия.
При этом не следует путать проектирование программ и проектирование взаимодействия. Программисты пишут инструкции для компьютеров и работают в контексте, в котором цели пользователей не учитываются.
Проектирование должно стать частью процесса разработки и непременно должно предшествовать написанию кода.
Проектирование полезно для всех участников процесса разработки, так как дает единую систему понятий и позволяет определить степень готовности программы.
Программное обеспечение — самый гибкий вид продуктов, которые когда-либо создавали люди, и ему следует научиться изменяться под нужды своих потребителей.
Отлично! Вы прочитали книгу! 👍
Теперь вернитесь к боту и нажмите под этой книгой "✔️ Я прочитал", оцените ее и пройдите тест.