Прототипирование как коммуникация

    Продолжение статьи о мышлении дизайнера.
    «Процесс важнее результата. Когда результат довлеет над процессом, вы начинаете с того места откуда начинали. Когда процесс ведет нас, мы не знаем, куда мы зайдем, но если окажемся там, где нужно, то сразу поймем это»
    Bruce Mau, «Неполный манифест творческого роста»



    Я продолжу противопоставлять ТЗ и прототип, чтобы выявить неочевидные свойства прототипа и эффекты от его применения. Противопоставление ТЗ и прототипа стоит понимать как противопоставление того, что у вас есть в производственном процессе, с тем, что в нём может появиться.

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

    Здесь возникают как минимум 3 неприятные вещи. Первая — каждый определяет для себя проект в своих собственных терминах, представление о конечном продукте становится набором пересекающихся (иногда очень слабо) множеств, каждое из которых — представление отдельного сотрудника. Многообразие представлений является потенциальным источником ошибок интерпретации, недопонимания, стрессовых ситуаций и даже межличностных конфликтов. Вторая — возникают т.н. зоны ответственности, когда каждый отвечает только за свою часть работы, и, как сказал Питер Морвиль, через трещины между этими зонами ответственности часто и вытекает весь «смак» ваших продуктов. Есть надёжные индикаторы таких ситуаций: когда коллеги выговаривают что-то вроде «если бы мы знали это с самого начала, то сделали бы все по-другому» и «я предоставил им отличный дизайн/документацию/etc., почему же они так всё испортили». Третья — заказчики и конечные пользователи остаются на обочине общения и практически не могут вмешаться в процесс обсуждения, влиять на принятие решений.

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

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

    Мистер Федерман (Federman) раскрывает смысл высказывания МакЛюэна (McLuhan) «the Medium is the Message» такими фразами: «природа средства коммуникации является сообщением» и «новое средство коммуникации несёт новый тип информации». Представим прототип как новое средство коммуникации на проекте.

    Простой в реализации практический пример: взять в качестве инструмента прототипирования Axure. Вообще выбору инструмента прототипирования должны предшествовать 2 вещи: определение характеристик/параметров прототипа и метода прототипирования, Axure хорош тем, что подходит для многих комбинаций, а для участников процесса разработки не составит труда научиться пользоваться этим инструментом (разумеется, заказчикам и конечным пользователям этого делать не придется, им должны прийти на помощь ребята из вашей проектной команды). Сочетание Axure с http-сервером (хороший пример) становится медийной базой для трансляции на широкую аудиторию сообщений-прототипов. Причём, уже начиная с первого прототипа-черновика, в котором описывается бизнес-идея заказчика, все сгенерированные html-прототипы, выложенные на http-сервере, доступны для обозрения в единой интерпретации. Добавьте к этому wiki-подобный движок для обсуждений. Сделайте так, чтобы редактируя исходный файл прототипа в Axure, генерируя и выкладывая свою версию прототипа как иллюстрацию к высказываниям, каждый смог бы представить свои идеи не столько словами, сколько прототипом-сообщением.

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

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

    Мы можем представить нашу пищевую цепочку из участников проектной команды как своеобразный канал связи, по которому проходят сообщения-прототипы. Оценить этот канал и «откалибровать» его можно, проделав например следующее. Маркетолог составляет brand expression продукта, с помощью проектной команды создаётся прототип, в полной мере отражающий expression, затем этот прототип предоставляется пользователям, собираются их отзывы и реакции. На руках для сравнения будут 2 вещи: точно сформулированное brand expression и то, каким оно было воспринято пользователями. Можно сопоставлять чёткий посланный сигнал с принятым, что даёт возможность исследовать соотношение сигнал/шум в канале, где и почему возникают искажения или помехи. Не стоит конечно забывать, что ошибки могут быть в ожиданиях или самом послании маркетолога — но так или иначе пользователи откорректируют его. И запуская в канал чёткое сообщение brand expression и разобравшись с тем, какие мутации происходят с ним, — можно прогнозировать и получить больший контроль уже над прохождением и изменениями сообщений (обычно гораздо менее чётких) от заказчиков.

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

    Вы можете выйти на новый уровень мотивации, организовав прототипирование-коммуникацию как процесс съёмки кино: подбор актёров — по методу Persona, написание сценариев, сцены-wireframes, раскадровки-storyboards, прототипы-презентации-пробы-съёмки-монтаж.

    Но самое приятное, что может и должно измениться, — участвуя в ясном и конструктивном общении, каждый в большей степени концентрируется на выполнении своих непосредственных профессиональных обязанностей, занимаясь вопросами творчества, а не вопросами условий творчества. В идеале — каждый участник видит ясные цели, лучше концентрируется и глубоко погружается в свою сферу, получает обратную связь, чувствует участие всей команды, быстрее включается, легче обучается и больше верит в свои силы, и как итог — чаще находится в состоянии потока.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 10

      +4
      То что вынесено в преамбулу («процесс важнее результата») — бич нашей страны. Прототипирование — это инструмент достижения нужного (клиенту и исполнителю) результата. Также это часть процесса работы команды надо получением результата. И результат всегда важнее того, было выполнено прототипирование или нет, и если да, то как. Другое дело, что чаще всего, качество результата зависит от качества процесса выполнения заказа…
        +2
        я заметил ещё такую вещь — процесс важнее результата — это мантра всех дизайнерских школ запада, преподаватели постоянно заостряют вопрос на том КАК, а не ЧТО делать студенту-дизайнеру для выполнения заданий, повторяя, что стремясь к тому, чтобы быть в хороших творческих кондициях, можно с легкостью выдавать отличные результаты, а если стремиться к какому-то конкретному результату, то и кондиции и результат будут страдать и деградировать; а мы все еще внутренне ориентированы на торжественную сдачу «объекта» к очередному празднику-дэдлайну
        0
        Цитата, вынесенная в заголовок, весьма интересна:
        … вы начинаете с того места откуда начинали.

        а можно ли иначе? начать не с начала?
          0
          имеется в виду — воз и ныне там, сколько бы проектов не сделали — качественная сторона процессов не изменяется, новые проекты сползают в пародию на уже сделанные
          0
          Хорошая статья. Но ее можно было бы сделать еще лучше:
          — добавив несколько нейтральных, но соответствующих теме иллюстраций.
          — выделить разделы текста подзаголовками (например, «стандартная ситуация», «пример использования» и т.п.)
          — небольшой конкретный пример, хотя бы из своей практики
            0
            спасибо, учту, боялся сделать статью, кот. отпугивала бы своим объёмом
            0
            Сделайте, пожалуйста, ссылки на предыдущие статьи из цикла — многие термины в этой статьи взяты из первой и просто так их не «вкурить»)
              0
              добавил в самом начале
              +1
              Зачем вы противопоставляете ТЗ и прототипы? Прототипирование помогает в написании проектной документации и наоборот. Прототипы- артефакты работы UX и дизайнера важны, как и UML диаграммы, унаследованный код и тд.

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

              — версии для прототипов (даже простой статичный прототип это часть проекта, используйте версионинг)
              — создайте онлайн архив прототипов (обучение сотрудников, быстрый доступ, шаблонные решения в хорошем смысле:) мы юзаем google site- простой WYIWYG wiki движок)
              — выбор софта и технологий прототипирования: тестируйте как можно больше различных вариантов, ваш арсенал пополнится несколькими орудиями
              — начните с бумажного прототипирование прямо сейчас

              Сергей, спасибо за интересные статьи!
                +1
                Спасибо за комментарий, противопоставление здесь больше как приём, чтобы ярче раскрыть свойства прототипа и эффекты от его использования в контрасте, как бы на фоне ТЗ. Основная мысль — показать, что прототип может отыграть уникальную роль на проекте, которую отыграть ТЗ в общем случае не получится. Есть ещё момент — поворот лицом к UCD (а сейчас уже к HCD) многие компании начинают с попыток организовать что-то вроде юзабилити-тестирования (из-за раскрученности этой темы) и часто терпят различные бедствия из-за неполноты знаний, мне же хочется подсказать, что именно выработка навыков прототипирования может стать основой для мягкого перехода и постепенного освоения многих вещей, кот. ярко описываются в блогах и на различных семинарах по юзабилити и UI, подготовиться к надвигающемуся стандарту ISO HCD.

              Only users with full accounts can post comments. Log in, please.