6 принципов системного дизайна

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

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

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

‍Системный дизайн является аналогом творческой картографии. Это равносильно созданию карты перед созданием самой территории.

Создание системного дизайна

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

На практике результат работы над системным дизайном обычно выливается в диаграмму: боксы и стрелки, описывающие основные части продукта, и то, как они все взаимодействуют друг с другом. Хороший системный дизайн выявляет:

• Составные части: Какие основные элементы и объекты есть в системе?
• ‍Взаимосвязи: Как между собой соединены элементы? Какие существуют взаимосвязи? Где располагаются входы и выходы?
• ‍Цель: Чего мы способны достичь?

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

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

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

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

Согласование системного дизайна

‍Добраться до этого момента может быть не просто. Вот некоторые общие проблемы, с которыми вы можете столкнуться:

• ‍Субъективные предпочтения: Часто не все согласны с тем, какой вариант является лучшим и достойным реализации.
• ‍Стремление к "идеальной" системе: Вы можете заплутать в проектировании системы, где целью становятся идеал и совершенство, а не практическая ценность.
• ‍Различные ментальные модели: Дизайнеры, естественно, склонны мыслить с точки зрения композиции и пользовательского опыта, разработчики — с точки зрения архитектуры кода. Эти точки зрения должны сходиться.
• ‍Разрастание сферы применения: Мы часто ожидаем слишком многого от системы и считаем, что она должна решить все проблемы. Как только люди начинают работать над проектом, они видят, что все взаимосвязано. Это заставляет их добавлять все больше и больше функций.

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

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

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

Цель принципов

‍Если вы знакомы с данным этапом, то уже знаете, что чаще всего он происходит в Design Crit, где вы даете отзыв о пользовательском интерфейсе. Вы высказываете свои замечания, используя общепринятые принципы.

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

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

Недавно мы столкнулись с такой ситуацией у себя в компании. Вместо того, чтобы оценивать дизайн и полагаться на чрезмерно субъективные интерпретации ("Мне это не нравится" или "Я не совсем так себе это представляю"), мы попытались оценить, насколько хорошо дизайн системы укладывается в описанные ниже критерии.

Принципы хорошего системного дизайна

1.Делайте как можно проще

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

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

‍Вопросы для самоанализа: Можем ли мы сделать систему проще? Не делаем ли мы слишком много предположений о том, что может потребоваться в будущем?

2. Убедитесь, что все понятно

‍Хорошая система должна быть простой и доступной для понимания пользователями, когда они взаимодействуют с продуктом. Они должны быть способны посмотреть на пользовательский интерфейс (пока мы его проектируем) и иметь возможность приблизительно определить, что это за часть системы. Slack является отличным примером.

‍Вопросы для самоанализа: Очевидна ли архитектура системы в интерфейсе? Смогут ли пользователи разобраться в ней без дополнительных объяснения?

3. Переместить сложные элементы в редко используемые части системы

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

‍Вопросы для самоанализа: Является ли эта система слишком сложной изначально? Какие пользователи взаимодействуют с каждой частью системы?

4. Не беритесь за непрофильные проблемы

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

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

‍Вопросы для самоанализа: Подходит ли этот уровень рассмотрения проблем для данной диаграммы? Действительно нам нужно решать эту часть проблемы на системном уровне?

5. Стройте систему от простого к сложному

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

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

‍Вопросы для самоанализа: Какие части системы актуальны для всех пользователей? Какие части являются нишевыми?

6. Приоритет отдается существующей системе

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

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

‍Вопросы для самоанализа: Насколько сложно добраться до уровня существующих систем?

Заключение

‍Это не универсальные принципы, но надеюсь, что они послужат примером, который поможет вам оценить вашу собственную работу по проектированию системы.

‍"Проектирование системы похоже на план к действию, которая в дальнейшем будет служить руководством для всей команды".

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

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