Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

Введение в целеориентированное




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

Глава 1. Проектирование, ориентированное на цели

Глава 2. Модели реализации и ментальные модели

Глава 3. Новички, эксперты и середняки

Глава 4. Как понять пользователей: качественные исследования

Глава 5. Модели пользователей: персонажи и цели

Глава 6. Основы проектирования: сценарии и требования

Глава 7. От требований к пользовательскому интерфейсу: общая инфраструктура и детализация


Проектирование, ориентированное на цели

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

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

Цифровым продуктам необходимы

более качественные методы проектирования

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

Проектирование, по мнению промышленного дизайнера Виктора Па-панека (Victor Papanek), есть сознательные и интуитивные усилия

Ак. 1494


34 Глава 1. Проектирование, ориентированное на цели

по созданию значимого порядка.1 Мы предлагаем несколько более подробное определение проектирования, ориентированного на людей:

• понимание желаний, потребностей, мотивации пользователей и кон
текста, в котором эти пользователи находятся;

• понимание возможностей, требований и ограничений бизнеса, тех
нологии и предметной области;

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

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

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

Современное проектирование цифровых продуктов

Цифровые продукты рождаются в результате перетягивания каната двумя нередко враждующими силами - разработчиками и маркетологами. Маркетологи, конечно же, хорошо замечают и оценивают возможности по выходу на рынок, способны представить и позиционировать продукт, однако их вклад в процесс проектирования продукта часто ограничивается списком требований, который передается разработчикам. Эти требования зачастую далеки от реальных потребностей и желаний пользователей и имеют гораздо большее отношение к борьбе с конкурентами, к управлению ИТ-ресурсами посредством перечня задач и к предположениям, которые построены на основе исследований рынка, представляющих информацию о том, что люди обещают покупать. (Вопреки интуитивному мнению, мало кто способен четко выразить свои потребности. Столкнувшись с прямыми вопросами относительно используемых продуктов, большинство людей сосредотачиваются на незначительных задачах или способах борьбы с изъянами продуктов.) К сожалению, перечень из сотен функций, к которому сводится интерактивный продукт, слабо пригоден для создания той

В. Папанек «Дизайн для реального мира». - Пер. с англ. - М.. Л. Aронов


2008.


Цифровым продуктам необходимы более качеавенные методы проектирования



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

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

К сожалению, результатом такого подхода становятся цифровые продукты, которые раздражают пользователя, снижают его производительность и не отвечают его потребностям. На рис. 1.1 представлена эволюция процесса разработки программного обеспечения и указано то место, которое в этом процессе отводится (когда отводится вообще) проектированию. Разработка большинства цифровых продуктов застыла на первом, втором или третьем шаге этой эволюции, где проектирование либо не играет роли, либо становится косметической заплаткой поверх некачественного взаимодействия - «макияжем для свиньи»1, как выразился один из наших клиентов. Процесс проектирования, как мы скоро увидим, должен предшествовать созданию кода и тестированию, иначе нельзя гарантировать, что продукт действительно будет соответствовать потребностям пользователя. За десятилетие, прошедшее с момента выхода первого издания этой книги, качество программ и интерактивных продуктов несомненно улучшилось. Многие компании начали уделять пристальное внимание тому, чтобы их продукция удовлетворяла нужды людей, и стали тратить время и деньги на раннее проектирование. Однако гораздо большему количеству компаний все еще не удалось включиться в эту игру, и до тех пор, пока они сосредоточены на технологии и рыночных

Имеется в виду английская пословица You can put lipstick on a pig, but it's still a pig (Свинья есть свинья, сколько ее ни крась). - Примеч. перев.



Глава 1. Проектирование, ориентированное на цели


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

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

Цифровые продукты грубы

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


Цифровым продуктам необходимы более качественные методы проектирования 37


 


Внимание! Не удалось уведомить библиотеку.


Рис. 1.2. Замечательно, спасибо за откровенность. Почему программа не уведомила библиотеку? О чем она хотела уведомить эту библиотеку? Почему она говорит об этом нам? С чем мы вообще соглашаемся? С какой стати сбой в программе - это «ОК»?

Программы часто допрашивают пользователя, засыпая его маловразумительными вопросами, на которые пользователь не готов или не склонен отвечать: «Куда ты подевал этот файл?» Снисходительные вопросы, вроде «Вы уверены?» и «Вы действительно хотите удалить этот файл или нажали на клавишу Delete по другой причине?», равно унизительны и неприятны.

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

Поделиться:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...