Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 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%.

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

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

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

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

‍