Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 1. Классификация

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

    Классификация прототипов


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

    Структурные схемы страниц (wireframes) или бумажные прототипы


    Wireframe главной страницы интранет-сайта для журналистов экономического форумаСперва это наброски ключевых страниц системы на бумаге, затем — отрисованные в MS Visio детальные схемы практически всех страниц и AJAX-взаимодействий. Их часто называют бумажными прототипами, но слово «бумажные» чаще всего теряется. Тут и начинаются терминологические споры — люди называют одним и тем же словом разные вещи, бесполезно спорят и вводят клиентов в заблуждение. Да и если посмотреть, к примеру, на аналогии в том же строительстве — тем есть и макеты (те самые модели из картона), и проекты — архитектурный, строительный, градостроительный и т.п… Поэтому я стараюсь говорить о них как о схемах страниц. Они дают первое наглядное представление о будущей системе, позволяют поставить задачи дизайнеру, верстальщику интерактивного прототипа, разработчикам.

    Интерактивный или кликабельный прототип


    HTML-прототип веб-приложения букинга мероприятий BOOCМатериал как раз о них. У нас это набор связанных между собой HTML-страниц, включающий имитацию AJAX-взаимодействий с помощью статичного JavaScript. Данных он обычно не сохраняет, но можно использовать те же cookies для имитации серверного взаимодействия. Есть и более простые варианты прототипирования — например, «оживление картинки» через Adobe Flash или просто макеты страниц с кликабельными зонами (imagemaps). Пользы от интерактивного прототипа много для всех участников процесса работы над системой, но об этом ниже.

    Функциональный прототип


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

    Аудитория


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

    Заказчик


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

    Пользователи системы


    Пользователи могут быть как внешними — работающими с основной функциональностью и контентом во front office, так и внутренними — обеспечивающими работоспособность системы через back office. Первые — это просто потребители, вторые — еще и часть команды заказчика. Поэтому для уверенности в успехе продукта с помощью прототипа можно узнать, что:
    • Продукт понятен пользователям и удобен в работе. На основе схем страниц или визуального дизайна можно проводить только достаточно ограниченное юзабилити-тестирование. А вот интерактивный прототип дает возможность увидеть, как пользователи выполняют в системе основные задачи, уже максимально приближенно к реальности. Особенно здорово то, что прототип можно быстро доработать и провести юзабилити-тестирование снова. А при наличии альтернативных вариантов — сделать модели всех из них и показывать пользователю по очереди. Конечно, все равно остаются оговорки — данные в прототипах сохраняются редко, нет особенностей взаимодействия с сервером и других рабочих моментов. Но чаще всего это касается нефункциональных требований — если костяк системы составляют независящие от пользователя функции, то и интерактивный прототип ей редко нужен. В любом случае, в итоге — проверены и доработаны основные сценарии работы пользователей с системой.
    • Все необходимые функции реализованы и работают эффективно. Это скорее продолжение предыдущего пункта — но удобнее выделить его в отдельный. Разница в том, что проверяется эффективность выполнения не отдельных задач, а целых процессов. Все ли в продукте есть для того, чтобы каждая группа пользователей выполняла свои задачи полноценно и эффективно? Можно ли достичь состояния потока, когда работа с системой идет «на одном дыхании» — она явно или неявно предлагает и подсказывает следующий шаг? В итоге дается ответ на то, работает ли система как полноценный продукт и помогает ли достижению бизнес-целей.
    • Систему можно обеспечить необходимым контентом, а ее функции — поддержкой. Успех веб-приложения или сервиса обычно строится на основе качественного контента или функциональности — в сумме или по отдельности. Важно знать, насколько возможна и затратна поддержка этих составляющих. Прототип показывает финальный результат работ, так что можно просчитать заранее, с какой периодичностью, в каких объемах, из каких источников, какими ресурсами, с какой доработкой брать информацию. Не забывая и про функции — на каких участках, кто, как и какими силами должен поддерживать успешную работу сервисов. Начиная от модерации user-generated content, заканчивая справочными службами и т.п. В итоге — проработка процесса поддержки системы и поиск путей облегчения работы в этом процессе.

    Команда разработки


    «Последняя миля» в создании системы — это команда разработки. Можно спроектировать фантастически удобный и понятный пользовательский интерфейс, но если не пересказать все его детали и особенности разработчикам — большой кусок аналитических усилий уйдет впустую. Интерфейс системы любом случае детально документируется и описывается. Но словесное описание можно понять не так, да и разработчики не всегда горят желанием копаться в куче документов. Так что им нужны инструкции и примеры того:
    • Как выглядит и работает система в целом. Разработчикам хочется понимать, что же они делают. Бумажные описания не очень-то цепляют — в них не видно финиша, того зачем все это затеяно. Как передать суть работы, основные идеи продукта тем людям, кто не принимал участия в аналитике и проектировании? Лучший способ — показать максимально похожую систему. Или интерактивный прототип той, которую нужно создать. В итоге — понимание сути работы.
    • Каковы особенности работы отдельных функций. В процессе разработки конкретной функциональности часто всплывают большие и маленькие вопросы по поводу того, как это все работает. Общая суть обычна понятна с первого взгляда, но вот последовательность процесса работы функции — источник множества потенциальных проблем. Например, нужно добавить новую квартиру в список объектов недвижимости. Как работают собственные поля ввода? Выдается ли какое-то сообщение при отправке формы? Нужно ли подсвечивать новую квартиру с общем списке после добавления? Прототип не отменяет необходимости описывать все эти и другие моменты в спецификации. Но наличие их в модели интерфейса помогает сократить список переделок. В итоге — более подробная и всеохватывающая спецификации системы.
    • Насколько возможно реализовать те или иные функции. В сложных системах невозможно описать в спецификации абсолютно все моменты. Разве что если отвести на это изрядное количество человеко-месяцев. Отчасти это связано с проблемами интеграции функциональности друг с другом. Отчасти потому что планируется использовать новые и неопробованные технологии. В процессе работы все это обсуждается на планерках или спонтанных митингах — словесно или на маркерных досках. Но особенно удобно, если при обсуждении можно обращаться к интерактивному прототипу. А еще лучше — тут же экспериментировать с функциональностью на его основе. В итоге — результаты обсуждений ближе к реальности, а не абстрактным предположениям.

    Осталось поставить у этого чеклиста галочки. И начать работу над самим прототипом.

    Читайте вторую часть материала с примерами интерактивных прототипов и третью с особенностями процесса их создания.

    Оригинал: Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 1. Классификация
    Поделиться публикацией

    Комментарии 44

    • НЛО прилетело и опубликовало эту надпись здесь
        –4
        ретро?
          –5
          классика?
            –5
            старо как мир?
              –5
              Сначала было это.
        –10
        баян
          –10
          Теперь банановый.
            0
            Бумажные описания не очень-то цепляют — в них не видно финиша

            Видимо никудышные описания. Мне казалось что смысл описания - именно в том, чтобы очертить границы того, что надо сделать.
              +2
              Дело не в качестве описаний. Дело в том, что часто (вне зависимости от качества и подробности документации) разработчики обращаются не к ней, а к визуальным документам — дизайну, прототипу, схемам страниц.

              Прототип не отменяет текстовые спецификации, он дает еще один взгляд на них. Который для многих гораздо нагляднее и удобнее.
                +2
                По нашему опыту талмуды с большим количеством текста программистами и менеджерами проекта игнорируются. Доходит до смешного — они начинают задавать вопросы, ответа на которых есть в этих документах.
                Картинки с небольшими компактными приложениями много доходчивее.
                  0
                  Во-во :) У нас недавно смешно получилось с use cases — они были описаны давно и очень подробно, с детальными алгоритмами работы страниц. Разработчики постоянно обращались с вопросами и очень удивились, когда вспомнили про них и увидели, что там все давно есть :)
                +8
                Я, конечно, понимаю, что «Хабр уже не тот» ©, где много букв прокатывает все реже. И да, статья уже была републикована на GUI.ru, но ведь не все читают GUI.ru и тем более мой блог. Но все равно, не очень понятна такая трешовая реакция. Хабру не нужны авторские материалы? За качество не буду говорить, но по-моему мнению и тех, кто статью републиковал — по крайней мере достаточно сносное.
                  +1
                  Юра, у тебя нет скандала! ;)
                    0
                    Ну если бы я хотел скандала — писал бы на Лепру :) Хотя реакция в комментариях такая, будто туда и написал :)
                    +1
                    Юра, мою статью здесь увели в -19 практически без каких-либо комментариев, так что ее вообще не найти, кроме как через мой профиль.
                      0
                      Холивары народу гораздо ближе :)
                    +3
                    спасибо. по делу.
                      +1
                      Незашт :) Приятно видеть адекватных людей, а не второй сезон упячки :)
                        0
                        мне, лично, на орфографию наплевать. Важен контент и его актуальность
                          0
                          Стараемся и там, и там удачно сделать :)
                          0
                          да, спасибо большое.
                            0
                            И снова незашт :)
                        +1
                        спасибо, очень интересно.
                        А кто создает прототип на html+js? Как я понял, команда разработки в этом не участвует. Значит, созданием прототипа занимаются менеджеры и аналитики?
                        Просто я слабо представляю себе менеджера, делающего html макет и аналитика, прикручивающего к нему заглушки на js.
                          +1
                          Есть два варианта интерактивных прототипов — грубо говоря, черно-белые на основе wireframes и цветные, на основе дизайна. Первые может генерировать автоматом менеджер или аналитик (если они сделаны в программе, которая это умеет), вторые делаются HTML-верстальщиком. В зависимости от свободных людей в команде, интерактивный прототип делается либо тот же человек, что верстает начисто, либо еще один. Многие считают, что делать две верстки дорого, но плюсов гораздо больше. Но не буду забегать вперед — об этом как раз во второй и третьей части :)
                            0
                            большое спасибо, вопрос исчерпан.
                        0
                        спасибо. Давно не заходил к Вам в блог, вот и пропустил обновление:))
                          +1
                          Значит все-таки не баян :)
                            0
                            Для некоторых баян, а для некоторых нет. Видимо здесь общество разношерстное и всем сразу не угодишь. Мне даже интересно читать двух разных авторов пишущих на одну и ту же тему. Вы пишите пишите. Эта тема для меня актуальна:)
                              0
                              Значит продолжим тему :)
                          +1
                          Спасибо. Читал статью на вашем блоге, интерестно. Особенно приятно, что публикация проиллюстрирована реальными примерами работ, которые можно посмотреть (http://uimodelling.com/) живьем (это относится к следующим частям).
                          Мог бы - поставил бы +
                            0
                            Стараюсь по-возможности иллюстрировать все материалы, но часть старых работ не могу подробно показывать, а часть текущих — потому что еще в работе. В феврале запускается два масштабных проекта, так что будет масса интересных историй и картинок :)
                            0
                            Классная статья! второй день собирался прочитать, наконец-то добрался :) как раз сейчас выводим это у нас в компании на новый уровень, и я собираюсь этим серьезнее заняться. теперь буду читать вторую часть. Спасибо!
                              0
                              Спасибо! Сейчас как раз закинул третью часть — там последние штрихи :)
                                0
                                спасибо :) я вчера перечитал почти весь Ваш блог. и нашел там третью статью :)
                                  0
                                  Надеюсь, нашлось еще много интересного :)
                                    +1
                                    да, у Вас действительно полезные статьи, читал одну за другой, не мог оторваться :) единственное чего не нашел - описание документов которые вы используете и их поддержки по ходу проекта. например у нас принято несколько: Vision/PFD(proposal for development), Estimate и SRS (Software requirements Specification), всей документацией на данный момент у нас занимаются руководители проектов. Думаю, что стоит добавить спецификацию по дизайну с более-менее четкими требованиями, насколько это возможно. и возможно стоит разнести в разные документы test cases и use cases со ссылками из Project Chapter документа. Также, я думаю, что стоит выделить отдельно человека для поддержки документов по проекту. в общем, хочется улучшить проектную документацию и повысить качество и эффективность работы команд. поэтому я сейчас стараюсь ознакомиться максимум с тем что уже есть и придумано, чтобы не изобретать велосипед. :) а за Ваши статьи большое спасибо! очень полезные :)
                                      0
                                      Спасиб еще раз! До документов я пока не добрался — писал про самые вкусные и понятные вещи вроде схем страниц и прототипов, но постепенно дойду и до них :) Мы пишем Vision, SRS и серию других документов. Не знаю точно, что именно у вас понимается под Estimate, но судя по предположению (объем работ, расчет сроков и стоимости) — также покрывается, но другими документами. Тут все зависит от построенного в компании процесса, так что их названия и состав могут различаться. Но в любом случае те три вещи, что у вас указаны — описание проекта, его оценка и техническое задание — в каком-то виде есть всегда.

                                      Про устав проекта, кстати, я писал недавно, а про остальное пока не успел :) Но со временем все это появится, так что подписывайтесь на RSS :)
                                        0
                                        спасибо за ответ :) буду ждать обновлений
                                          0
                                          На следующей неделе будет материал о user stories — это и часть оценки, и часть ТЗ. Надюесь, получится компактнее, чем с прототипами :)
                            • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                Автор, огромное спасибо! Подписался на RSS.
                                  0
                                  Взаимное спасибо :)

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое