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

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

1 В. Папанек «Дизайн для реального мира». – Пер. с англ. – М.: Д. Аронов, 2008.

 

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

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

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

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

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

 

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

Рис. 1.1. Эволюция процесса разработки программного обеспечения.

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

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

до начала дорогостоящей и сложной фазы создания продукта

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

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

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

 

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

 

 

Рис. 1.2. Замечательно, спасибо за откровенность. Почему программа

не уведомила библиотеку? О чем она хотела уведомить эту библиотеку? Почему она говорит об этом нам? С чем мы вообще соглашаемся?

С какой стати сбой в программе – это «OK»?

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

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