Прототипирование для ИТ: мышление дизайнера, метафоры среди алгоритмов

    Впервые опубликована на usability.by

    Прототипирование для ИТ


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

    В своей первой статье я хочу рассказать о вещах, которые могут быть не замечены или недооценены руководителями отделов разработок, дизайн-департаментов, бизнес-аналитиками, помочь отыскать упущенные возможности и подсказать некоторые ходы, пригласить вас заглянуть в философию дизайна. Потребность в прототипировании чаще всего вырастает из потребности сделать наглядной и более прозрачной фазу сбора информации и написания технического задания (ТЗ, спецификации, vision) [1], но я хочу рассказать о менее очевидных вещах.

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

    Мышление дизайнера, метафоры среди алгоритмов

    'Why,' said the Dodo, 'the best way to explain it is to do it.'
    Lewis Carroll, Alice in Wonderland


    Свойства мышления определяют свойства создаваемых этим мышлением продуктов. Сравним мышление аналитика, создающего ТЗ, с мышлением дизайнера [2], создающего прототип. Методологи и теоретики дизайна Ловсон (Lawson) и Пенг (Peng), проводя исследования и эксперименты для выделения специфики дизайнерской деятельности (в отличие от деятельности аналитической или гуманитарной), выяснили, что для мышления дизайнера свойственны следующие моменты:
    1. Аналитики прибегают к стратегии систематического исследования, чтобы найти правило, дизайнеры же склоняются к тому, чтобы выработать серию решений и, постепенно отсеивая многие из них, найти соответствующее требованиям; это скорее процесс удовлетворения, нежели оптимизации, это попытка создать ряд удовлетворительных решений, а не одно оптимальное.
    2. Аналитики выбирают стратегию, сконцентрированную вокруг проблемы, дизайнеры — вокруг решения, т.к. проблемы, с которыми сталкивается дизайнер, часто плохо сформулированы и плохо структурированы, это проблемы, для решения которых часто нет всей необходимой информации и даже нет надежды на её появление, поэтому стратегия, ориентированная на выдачу результата продуктивнее.
    3. Дизайнер рассчитывает на возможно быстрое отыскание удовлетворительного решения, а не на длительный анализ проблемы.
    4. Дизайнеру свойственно изменять проблему для того, чтобы найти решение, дизайн конструктивен, он не изучает вещи, как они есть, он имеет дело с вещами, как они должны быть, создание моделей важнее процесса их осознания.
    5. Дизайнер занят поиском емкой метафоры, аналитик — обобщающего правила, формулы, алгоритма.

    Остановимся на последнем моменте. Содержание хорошего ТЗ похоже на набор алгоритмов, прототип состоит из первичных моделей-идей.

    Внедрение фазы прототипирования в процесс разработки привносит в коммуникационное поле проекта сообщения (и возможность ими обмениваться) на ещё одном языке — языке метафор (metaphorist pattern, Peng). Изъясняться на таком языке для очень многих (включая ваших заказчиков) естественнее и продуктивнее, чем на языке формализованных описаний или инструкций.

    Но самое главное — сообщения, «написанные» на этом языке, повсюду.

    Эти сообщения вдохновляют дизайнеров, подпитывают их творческую энергию, стимулируют коммуникацию и снижают стрессовый фон. Мне нравится формулировка теоретика дизайна Сидоренко: «предметы выступают формой знания относительно того, как удовлетворяются определенные требования и как решаются определенные задачи. […] Изобретение часто опережает теорию, сфера творчества и исполнения, как правило, опережает сферу понимания — технология ведёт к науке, а не наоборот. Дизайнеры обладают способностью одновременно „читать“ и „писать“ в материальной культуре: они понимают, что говорит предмет, и могут создать новые предметы, которые воплощают в себе новые сообщения».

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

    В следующей статье — собираем форум мнений вокруг прототипа и соревновательное прототипирование.

    Примечания:

    1 — здесь я использую как синонимы
    2 — я обобщаю в этой роли многие позиции, в названии которых есть UI, UX, IxD


    Литература по теме:

    Bryan Lawson — «How Designers Think, The Design Process Demystified», 4th edition, 2005, ISBN–13: 978-0-7506-6077-8, ISBN–10: 0-7506-6077-5
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 22

      +1
      У вас есть конкретный пример проблемы, ее прототип и решение?
        +1
        спасибо за вопрос, я как раз собираюсь своими статьями расширить видение прототипов, рассказать, что это не только «решение вот такой конкретной проблемы», но что прототипирование содержит в себе и тонкие вещи, влияющие на весь процесс. Понимаю, что раздражаю философствованиями и абстракциями. Могу ответить так: пример проблемы — устоявшееся узкое представление о прототипах, я опишу несколько схем получения дополнительных побочных продуктов (помимо визуализации и использования прототипов в юзабилити-тестировании) от использования прототипов; решение — например эта статья может подсказать вам решение, ходы в ситуации, когда свойства мышления дизайнера обнаружатся у кого-нибудь из вашей проектной командыи вы будете знать, чем этого человека лучше нагружать. Конкретика будет позже, т.к. она обычно задавливает собой тему, кот. я собираюсь раскрыть.
          0
          Довольно интересная статья, но недостаточно живая в силу отсутствия примеров. Теория хороша, но интересна бывает только с примерам из практики или, если в процессе читатель сопоставляет её со своей личной практикой.
            0
            спасибо, учту, я ставил целью привлечь ваше внимание исключительно к почве, на кот. прототипы вырастают, чтобы можно было её рассмотреть за прототипами, обычно, когда приводишь конкретный пример — всё внимание достаётся только ему
          +1
          Лично для меня в статье не хватает практических примеров.
            +2
            в следующей приведу пример организации коммуникации на проекте спомощью прототипов, эта статья задумывалась как рассказ о мышлении, а не о его продуктах
              0
              Ок, пусть будет так. Ждем-с.
            0
            Полезная статья. Хотя и многословна да заумна. Но хоть что-то.
            Давно уже пора отказаться от разработки «снизу — вверх» (от кода или *sic* базы к пользовательскому интерфейсу) в пользу разработки «сверху — вниз» (от интерфейса к исполняемому коду).
            Но пока будут финансироваться пустые обещания и стартовые фазы проектов типа: «1. создания структуры базы данных, 2. настройка движка и классов, 3. оптимизация под многомильенную посещаемость ...» вряд ли что изменится.
              0
              спасибо, я очень боялся перенести язык первоситочников (загляните как-нить в них) в пост, недофильтровал язык
              +2
              Еще неплохо было бы сделать обзор используемого инструментария.
              0
              А можно ещё добавить сюда программистов и тестеров, а не только дизайнеров? Ну чтоб полная команда получилась.
                0
                Да, и как обеспечить их взаимодействие при создании прототипа.
                  +1
                  в следующей статье я как раз собираюсь рассказать, как организовать общение на почве прототипов
                  +1
                  описанное «мышление дизайнера» может быть свойственным кому угодно, а «мышление аналитика» вполне может оказаться у дизайнера
                    +1
                    +1 за этот комментарий.
                      0
                      задело за живое?
                        0
                        Нет, скорее — наоборот. ) Многое добавило к пониманию написанного.
                  0
                  Ценность этой статьи для *этих пользовательских интерфейсов* в первую очередь я вижу в том, что предпринята попытка посмотреть на дизайнеров не просто как на рисовальщиков графики и участников обсуждений, а как на людей со своеобразной организацией мышления при решении трудовых задач.
                  Хотелось бы, конечно, увидеть какие-то более практические выводы.
                  И да. Я бы назвал подобного рода прототипы набросками (как-то более по-дизайнерски=)). Всё-таки под прототипами в контексте этого блога понимается несколько иное.
                    0
                    практический вывод — обратить внимание и на то, что люди с таким мышлением могут оказаться не только среди дизайнеров и что было бы неплохо дать им возможность выражать себя в прототипах (каких угодно)
                    0
                    Мне контекст слова «дизайн» не очень понятен. Всё равно мозг «сползает» на рисование и прочие подобные вещи.

                    А в целом статья очень ценная. Качественной актуальной русскоязычной информации о процессе requirements analysis и смежных областях очень мало. Практических примеров ещё меньше.
                      0
                      спасибо, дизайн здесь как проектирование, интерпретация замысла

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