Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 2. Спираль повышения качества

Если подойти к описанным в первой части слоям проектирования немного с другой стороны — в последовательности шагов работы над проектом, — вырисуется последовательный процесс улучшения качества интерфейса. Причем процесс повторяющийся, так что можно говорить о “спирали” повышения качества. И почти каждый ее виток проходит по следующим шагам:

1. Бизнес-анализ

Мы анализируем задачи клиента и пользователей и определяем общие подходы к решению этих задач. Здесь обрисовываются контуры будущей системы, задаются общие направления движения. Тот бэкграунд, который позволяет в ходе дальнейших работ не забывать о целях и задачах проекта. Мы также находим существующие примеры того, как примерно должно получиться в итоге. Уже точно известно, что должна уметь делать система. А в голове и на бумаге возникают первые грубые наброски ключевых страниц. Как итог — описание продукта с примерно 5% точности.

2. Проектирование интерфейса

Мы прорабатываем точную структуру системы, распределяя всю запланированную функциональность по конкретным страницам. Так абстракция плавно приобретает конкретику и еще более конкретизируется в виде структурных схем страниц (wireframes). Расставляя информацию и элементы управления по страницам, мы между делом собираем дополнительные сведения о сущностях. Их атрибуты и методы собраны заранее, но когда дело доходит до конкретики, чего-то может не хватить.

В результате вместо общей фразы “пользователь оформляет заказ”, полученной в ходе бизнес-анализа, получается набор конкретных страниц. Каждая из которых содержит всю необходимую информацию для выполнения этой задачи. А также элементы управления, позволяющие выполнять частные подзадачи общего процесса и связывающие эти подзадачи между собой. Итоговый набор страниц должен выглядеть аккуратно, но без фанатизма. Ведь на этом этапе стоит задача именно распределения, а не оформления функциональности. Все это повысит точность описания до 40%.

3. Дизайн

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

Дизайнер, как человек со свежим взглядом на проблему, может предлагать свои решения. И если они окажутся лучше предварительно спроектированных — почему бы не воспользоваться ими? Еще более важно то, что он может заметить ошибки и нестыковки. Дизайнеру также может понадобиться объяснить те вещи, которые проектировщик забыл описать. И этот очередной уровень проверки интерфейсных решений дает 60% точности.

4. Интерактивный прототип

Мы делаем так, чтобы интерфейс будущей системы можно было “покликать”, поработав с ним в приближенном к реальному режиме. Несколько десятков HTML-страниц, созданных на основе дизайн-макетов, объединяются друг с другом и наполняются реальным контентом. В дополнение они оживляются скриптами, которые создают эффекты и имитируют работу серверных функций. Дизайнер и верстальщик общаются по ходу отрисовки страниц, поэтому технические ограничения предусматриваются и обходятся заранее.

Кроме того что это еще один свежий взгляд на проблему и еще один прогон интерфейса по “конвейеру”, интерактивный прототип позволяет почувствовать удобство конкретных качеств интерфейса. Скорость реакции на действия пользователя, попадание в нужный экран браузера, удобство чтения текста и другие полезные характеристики лучше проверять уже на реальном примере. Ведь до этого момента мы только предполагали, что, например, “пользователь перетаскивает блок, удерживая левую кнопку мыши нажатой на его заголовке”. Вполне возможно, что доступную для нажатия область заголовка лучше будет увеличить. Такая проверка повысит точность предположений до 70%.

5. Разработка

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

Команда разработки сама по себе не маленькая. К тому же состоит из людей, выполняющий разные роли — разработки, тестирования, менеджмента. А это значит очередной взгляд со стороны, причем с различных позиций — и уже 80% точности.

6. Пользовательское тестирование

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

При этом особенно важно проверить основные сценарии работы пользователей с системой — насколько они понятны и удобны. Основные проверки важно провести еще на ранних этапах, чтобы не было мучительно поздно. Но повысить качество этих процессов в конце было бы не менее здорово. К тому же могут обнаружиться интересные сценарии нетипичного или нецелевого использования системы, которые можно было бы развить в самостоятельные направления. Все это дает нам отличную цифру в 90% точности.

7. Реальная работа системы

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

До запуска по-настоящему плотно с продуктом имели дело разработчики и аналитики. После запуска акцент смещается на конечных пользователей и команду поддержки. Может оказаться, что, например, редакция портала получает от поставщика контента изображения далеко не того качества, как планировалось. Или пользователи пишут не 10, а 1000 комментариев к каждому материалу. Все это, конечно, примерно просчитывается в процессе разработки. Но это опять же предположения, которые с жизнью могут не совпасть.

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

8. Развитие продукта

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

Само собой, все эти проценты достаточно условны. Но они отражают то соотношение усилий, которые наиболее разумно прикладывать к повышению качества интерфейса. Здесь отлично работает правило 90:10, по-своему описанное в какой-то из книг по управлению проектами. 90% успеха достигается после затраты 90% усилий. Оставшиеся 10% достигаются вторыми 90% усилий. Каждая контрольная перепроверка сделанной работы дается все сложнее. Взгляд замыливается, процесс на это время стопорится, а уверенность в том что все хорошо с каждым разом все падает.

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

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

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

Все части материала:

17 Comments Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 2. Спираль повышения качества

  1. Pingback: Процесс и продукт проектирования.

  2. Pingback: Процесс и продукт проектирования.

  3. Прохожий

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

    Reply
  4. Juras Vetrau

    Прохожий,

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

    Reply
  5. Геннадій Драгун

    2 Прохожий,

    А чем по вашему мнению занимается Юрий на протяжениии всего проекта, как не повышением качества конечного пользовательского интерфейса. Если вы считаете пользовательское тестирование единственным способом поиска ошибок, то те, кто вам об этом сказал – жестоко вас обманули…

    Reply
  6. Juras Vetrau

    Гена,

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

    Reply
  7. Геннадий Драгун

    Юра,

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

    По моим профессиональным ощущениям, возможно достичь 70-80% уровня качества пользовательского интерфейса без проведения пользовательского тестирования, в первую очередь, за счет привлечения к проекту сильных аналитика и проектировщика.

    Reply
  8. Juras Vetrau

    Гена,

    Значит мы с тобой даже в процентах сошлись 🙂 Встраивание повышение качества в сам процесс — самый оптимальный вариант. А если еще и работать по нему профессионально и с умом — это повышение идет автоматически, без лишних затрат. Интерфейс получится как минимум хорошим, а после прогона в реальной работе — будь то юзабилити-тестирование или любое другое полевое испытание — станет просто конфеткой. Не проблема сделать просто достойный UI, проблема сделать его таким, чтобы еще и “внушало” 🙂

    Reply
  9. Прохожий

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

    Reply
  10. Геннадий Драгун

    2 Прохожий

    Именно. В самую точку.

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

    Кто платит деньги тот и заказывает музыку. Мы за зарплату работаем или как?

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

    Короткий вопрос: чем на ваш взгляд должен отличаться стул для секретарей от стула для дизайнеров или программистов?

    Иногда имеет смысл хорошо спроектировать для самих себя, тогда и другим это может понравиться.

    Reply
  11. Juras Vetrau

    Прохожий,

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

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

    К тому же я не раз упоминал о серьезной предварительной аналитике пользователей, бизнеса и предметной области, так что странно говорить о том что мы берем и делаем “от балды” 🙂

    Ну и Гена отлично продолжил и расширил мысль. Конечный потребитель — не единственное заинтересованное в проекте лицо. Поэтому мы и анализируем не только целевую аудиторию, но и задачи заказчика.

    Reply
  12. Прохожий

    Таки я вопросы задаю, чтобы получать на них ответы. 🙂

    Стул для дизайнера или для секретаря может отличаться, особенно если мы не смотрим на это поверхностно, а проводим какие-то полевые исследования. Я понимаю, что некторые работают в большой корпорации, где до полевых исследований как-то недосуг. Клиенты далеко, а до конкретных пользователей не дотянуться (сидят там где-то за океаном). Поэтому приходится использовать некую абстракцию метнально модели пользователя, например, заменить секретаря дизайнером. 🙂
    Вопрос в том: правильно ли это? С той же долей абстракции: правильно. Но несколько преступно утверждать, что это здоровый и непорочный путь. Вместо конкретной психологии мы заменяем ее на некую абстракцию психологии пользователя. И подобные абстракции служат рынку в большей степени, но могут (не значит, что совсем не могут) не отвечать запросам конечного пользователя.

    Reply
  13. Геннадий Драгун

    2 Прохожий

    То мы говорили о пользовательском тестировании, потом вдруг перескочили на полевые исследования…

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

    Если говорить о спирали качества в проектировании, то можно составить такие маленькие спиральки-лесенки для каждого из этапов:

    Исследования:
    – анализ литературы
    – анализ конкурентов + существующего приложения (если существует)
    – работа с заказчиком
    – работа с маркетологами
    – работа с экспертами в предметной области
    – заказчик как исследователь конечных пользователей
    – работа с конечными пользователями
    – фокус-группы
    – интервью
    – контекстные интервью + этнография

    Анализ и моделирование:
    – Неформальное моделирование
    – Моделирование по бизнес ролям
    – Моделирование персонажами
    – Выдуманные персонажи
    – Персонажи, основанные на исследованиях
    – Мозговой штурм, JAD

    Проектирование:
    – бумага/доска
    – каркасы (сториборды)
    – детальные прототипы
    – интерактивные прототипы
    – прототипы в среде разработки

    Валидация:
    – Инспекция
    – внутренняя (peer review)
    – заказчиком
    – специалистом в предметной области
    – командой разработки (JAI)
    – специалистами по юзабилити/ интерфейсам
    – конечным пользователем (Contextual Inquery)

    – Тестирование
    – внутренними пользователями (коридорный тест)
    – внешними пользователями
    – полевое тестирование

    Вот примерный набор методик, в моем представлении. И каждый ведущий проектировщик выбирает себе в проект из этого набора то, что лучшим образом соответствует конкретной ситуации.

    И помните про правило 90:10. Для того, чтобы пройти последние 10% процентов на пути к идеальности, небоходимо затратить почти столько же усилий, как и на предыдущие 90%. А требуется ли от вас такая идеальность? Стоит ли она того?

    Reply
  14. Juras Vetrau

    Гена,

    Комментарий достоин отдельного поста 🙂 Очень мощно расписал, спасибо! Самому пригодится не раз 🙂

    Reply
  15. Pingback: Процесс и продукт проектирования.

  16. Pingback: Процесс и продукт проектирования.

  17. Александр Волосюк

    Как на счёт стоимости каждого этапа в относительных единицах (процентах от общей стоимости)?

    Насколько значения стоимости одинакового этапа в разных проектах могут различаться?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *