Вопрос-ответ: о работе со сложными системами
Анонимно:
Я начинающий дизайнер и мне поручили обновить интерфейс сложной банковской системы. С чего лучше начать работу, как удержать в голове зависимости между разными элементами? Таблицы и списки, кажется, только сильнее запутывают.
Представьте, что перед вами гигантский паззл. Вы можете сначала рассмотреть и классифицировать все кусочки, а потом приступить к сборке. Или взяться за небольшой фрагмент, собрать его, перейти к следующей тематической горстке, и так, пока «слепых пятен» почти не останется.
В работе над сложными системами я придерживаюсь второго пути: начинаю с относительно небольшой, но важной задачи, досконально разбираюсь в ней, предлагаю решение и довожу его до внедрения. Один хороший интерфейс в системе — это уже польза, а в качестве бонуса я получаю близкое знакомство с частью системы и плюс в репутацию. Чем больше таких готовых фрагментов, тем более полная картина складывается в голове, тем более сложные и комплексные задачи я готова решать. Ничего страшного, если после «вскрытия» очередного пласта какие-то из ранних решений придётся пересмотреть, к тому времени они уже принесут пользу.
Я всегда ставлю задачу самостоятельно. Обсуждаю проект с ответственными лицами, разбираюсь, задаю вопросы, после чего формулирую задачу своими словами в 2-3-4 абзаца текста. В «Нет-крекере» я периодически сталкивалась с длинными ТЗ, но мне всегда удавалось договориться о живом обсуждении и ни разу не пришлось тратить время на изучение многостраничной документации.
Во время работы над задачей я «загружаю» всю доступную информацию в мозг и даю ей «повариться», пока решение не будет готово. После этого я «выгружаю» готовый фрагмент (фиксирую решение в виде картинок с пояснениями, например, в бейскемпе) и готова приступать к следующей задаче. Пока я ищу решение, я не берусь за другие проекты, не участвую в обсуждениях и встречах, не относящихся к теме. Входящая информация по другим задачам копится в почте и ждёт своего часа.
Резюме
Не пытайтесь объять необъятное, начните с быстрых побед. Ставьте задачу сами, избегайте формальных ТЗ. Сохраняйте фокус, работайте над одной задачей в один момент времени. Фиксируйте результаты для быстрого доступа в будущем. Постепенно собирайте «большую картину» из качественно проработанных фрагментов.
Подробный рассказ о моём опыте работы со сложными системами в «Нет-крекере», 2011 год:
Присылайте вопросы на почту data@datalaboratory.ru — о визуализации данных и не только.
Я бы посоветовал изучить стандартный подход к проектированию интерфейсов, который применяется в рамках столь нелюбимой дизайнерами дисциплины «юзабилити».
Там есть такие инструменты, как навигационная диаграмма, объектная модель, информационная архитектура, пользовательские сценарии, юзкейсы, и так далее.
Это все позволяет описывать и прояснять для себя зависимости между объектами, элементами, понимать, как связаны разные элементы на разных экранах друг с другом.
Также в юзабилити есть KPI, улучшение которых должно достигаться в результате перепроектирования. Когда мы перепроектируем интерфейсы профессиональных систем, обычно мы стремимся к достижению одной или нескольких из вот таких целей:
Лично мной и другими этот подход с успехом применялся для различных банковских систем, В2В и В2С (CRM, банк-клиенты, АРМ операциониста в отделении, каналы ДБО (банкомат, интернет-банк, мобильный банк, и т. п.).
Что почитать на русском: одной книги нет, но можно начать вот с этих:
Луи Розенфельд. Информационная архитектура.
Алан Купер и др. Алан Купер об интерфейсе.
Джеф Раскин. Интерфейс.
“В работе над сложными системами я придерживаюсь второго пути...”
В работе над сложными (действительно) системами (действительно) второй путь — “путь сквозь туман в никуда через грабли”, ибо проектирование небольшого фрагмента всегда происходит на небольшом количестве данных о всей системе. (А “все данные” станут доступны после изучения “всей системы”). И следствием, это будет всегда так: “ой, в контексте новой информации старое решение совсем не подходит/не уместно/не являлось проблемой (а являлось побочным следствием)” и так далее.
Михаил, вы считаете, что выбранный вами и работающий для вас метод — единственный правильный, и предполагаете, что сторонники других методов со сложной (действительно) работой не сталкивались и не справлялись. Ваша точка зрения не подразумевает уважения и интереса к чужой работе, поэтому ответить мне вам нечего.
Таня, ваш ответ говорит что в этой профессиональной области вы боитесь вероятного критического замечания которому окажется нечего противопоставить.
Но не о том, что вам нечего ответить. Вы уже многое написали, верно?
Михаил, вот вы с какой целью уже второй комментарий оставляете?
Если мой метод у вас вызывает недоумение, и вам интересно, как я его применяю в сложных задачах, о задачах какой сложности идёт речь, почему я делаю так, а не иначе, это одно дело. Задайте вопрос и я с удовольствием вам отвечу.
Если же вы считаете, что метод нерабочий, со сложными задачами я не сталкивалась и моя компетенция недостаточна, чтобы на такие вопросы отвечать, это тоже ок. Высказать своё мнение — ваше право. Моё право вам ничего не доказывать, не оправдываться, не противопоставлять и не пытаться вас переубедить. Оставайтесь при своём мнении, пожалуйста.
Таня,
Ранее мне вы написали “отвечу вам в своем блоге”. И я до сих пор не могу получить ответа. Точнее — ответа по сути своего замечания. Я получаю ответы о форме в которой пишу или в которой мне следовало писать.
Расскажите пожалуйста: (1) сталкивались ли вы с ситуациями, когда контекст новых данных меняет суть ранее решенной задачи (или саму задачу)? (2) Как вы характеризуете “сложность” задачи и о какой сложности (сложности какого типа) идёт речь? (3) Как долго шла работа над самыми сложными задачами, с которыми вы сталкивались в своей практике (то есть буквально — как долго такие задачи находились в постоянном процессе “проектирования”)? (4) на чём основывается ваш метод, который вы применяете в сложных задачах?
Предпочитаю общаться уважительно, сожалею, что вам это доставляет неудобства.
Работа над самой сложной задачей в моей практике началась около полутора лет назад и продолжается до сих пор (конца пока не видно), всё это время проект находится в постоянном процессе проектирования. Это система аналитики рынка ценных бумаг, в её основе — визуализация данных о рынке, которая помогает оценивать ситуацию и принимать решения о покупке/продаже, работать с банковским портфелем, обмениваться информацией между лицами, принимающими решения, и операционными сотрудниками, работать с документацией. Не знаю, как оценить сложность задачи и как определить её тип (поможете?), но могу сказать, что задача велика вширь (много высокоуровневых сценариев, пять больших разделов) и вглубь (по каждому мини-сценарию — море теории, формул, математики). В начале работы над проектом мы за неделю сделали прототип главного графика, которым можно было пользоваться сразу и который работает до сих пор. Всё это время он обрастал функциями и сценариями, мы его дорабатывали, дополняли новыми графиками, диаграммами и большими разделами. Сейчас, спустя полтора года, мы созрели для того, чтобы пересмотреть ядро, тот самый график, с которого всё началось, и предложить новое решение, которое учитывает все многочисленные грабли, на которые мы наступили за это время. Всё это время наш заказчик пользовался системой и, насколько мне известно, вывел работу с ценными бумаги в своём банке на качественно новый уровень.
(1) сталкивались ли вы с ситуациями, когда контекст новых данных меняет суть ранее решенной задачи (или саму задачу)?
Бывает, что мы выкидываем и переделываем сделанную работу. Иногда это связано с новым пластом информации, чаще с изменением сценариев и эволюцией самой концепции проекта. Ещё чаще добавление новой функциональности даётся нам легко, потому что мы хорошо разбираемся в продукте, «видим» его насквозь и знаем, как встроить новые блоки в существующую структуру. Это «видение» охватывает весь продукт и вырастает из кропотливой работы с небольшими задачами.
(4) на чём основывается ваш метод, который вы применяете в сложных задачах?
Метод базируется на принципе ФФФ, который я трансформирую и дополняю, исходя из своего опыта и потребностей проекта.
Михаил, я буду очень признательна, если вы в двух словах расскажете о своём методе. Сколько времени уходит на изучение сложной системы перед началом проектирования? В какой форме вы «фиксируете» результаты? Сталкивались ли вы с ситуациями, когда новые данные или неожиданные изменения в проекте меняют суть ранее описанной и решённой задачи?