Діаграми архітектури систем проектування

Візуальний словник для відношення систем, продуктів та марок

Тож багато підприємств представляють екосистеми набагато складнішими, ніж «одна система дизайну, вся наша продукція». Все більше і більше, я вважав дискусії між групами та лідерами систем складними. Поки що мені не вистачало словникового запасу, щоб швидко показати та навчити широту цих багатьох систем та те, як вони обслуговують різних внутрішніх клієнтів з різними можливостями.

У цій статті пропонується візуальний словник брендів, систем та продуктів. Словниковий запас позначає різні проектні системи, межі документації, прийняття та організаційні межі системи проектування. На закінчення словниковий запас проілюстровано за допомогою повного, заснованого на сценарії прикладу.

Символи

Діаграми системної архітектури використовують символи (алмази, кола та квадрати) для конотування об'єктів (систем, продуктів та ідентифікацій марки відповідно).

Система, як Diamond

Кожен алмаз являє собою явний або неявний набір функцій системи дизайну, включаючи, але не обмежуючись, певний візуальний стиль, застосований до одного або декількох компонентів інтерфейсу, що пропонуються як засоби дизайну та / або коду.

Мітки заголовка та опису необов'язково відображаються вгорі праворуч під поворотом на 45 градусів. Хоча можна змінити розташування міток у міру появи діаграми, цей замовчування виявилося найменш ймовірним для конфлікту з об'єктами та роз'ємами.

Системні інструменти - Дизайн активів та код - як напівдиаманти

Кожна система пропонує засоби дизайну (наприклад, Sketch, Figma або Invision Studio), бібліотеку кодів або те і інше. Тому алмаз системи розділений, щоб позначати, чи пропонує він проектні активи (червоний D у лівій половині символу), код (синій C у правій половині символу) або обидва його клієнти.

Правила дизайну та посилання на код як алмазний фон

Більшість систем проектування візуально документують приклади та - за наявності - код, який використовується для отримання цього результату. Однак не всі системи дизайну пропонують більш глибокі рекомендації щодо дизайну та довідкові матеріали коду. Обидва зазвичай спілкуються через добре розроблений веб-сайт. Тому жовті фони з лівого та правого боку алмазу системи вказують на наявність відповідно до проектних інструкцій та довідкового коду відповідно.

Наприклад, IBM Carbon, Shopify Polaris, Morningstar, REI Cedar (розкриття: я сприяв останнім двом) надають детальні рекомендації щодо дизайну та довідковий матеріал для коду. Тому кожен повинен містити повний жовтий діамант за виходами D&C.

З іншого боку, Origami Financial Times пропонує посилання на код без інструкцій щодо дизайну. Матеріал Google давно пропонував великі рекомендації щодо дизайну без коду, хоча останнім часом вони змінилися своїми більш вільно пов'язаними вказівками та кодом у різних архітектурах значно ширшого сайту.

Salesforce Lightning Design System пропонує досить обмежене керівництво по дизайну, яке поєднується з документацією на компоненти, орієнтовані на код. Тому я зазначив - неохоче - що на цьому веб-сайті немає детальних інструкцій щодо дизайну.

Продукти як кола

Діаграмування зв'язків між системою проектування та її замовниками є надзвичайно важливим. Деякі можуть не вважати свою роботу самим собою «продуктом». Тим не менш, коло представляє будь-який цифровий досвід (або його частину), створений командою, яка могла б прийняти систему.

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

Кількість продукту як значки

Для екосистеми з багатьма продуктами консолідуйте один раз символ, який представляє багато, і позначте кількість значком.

Статус прийняття продукту як колір

Прийняття продукту системи нерегулярне. Тому використовуйте колір, щоб конотувати статус як прийнятий за допомогою системного коду (чорний), вбудовуючи дизайн системи в код замовника товару (сірий) або взагалі не приймаючи систему (білий).

Вони також можуть бути консолідовані, використовуючи значки за кількістю.

З'єднувачі, лінії зверху вниз

Вертикальні з'єднувачі зверху вниз представляють вироби залежно від системи. У той час як ліво-праворуч і радіальні дисплеї пропонують чіткі можливості (зокрема, радіальну «красу»), орієнтація зверху вниз покращує зорову ефективність, прискорює розуміння та полегшує виробництво та обслуговування.

Лінії повертаються закругленими, кутами 90 градусів. Прямі або вигнуті з'єднувачі перекриваються та з'єднуються з іншими роз'ємами та об'єктами, що робить презентацію безладним та маршрутами важче дотримуватися.

Ці діаграми тісно пов'язані з діаграмами залежності, які укладають з'єднувачі зі стрілкою. Однак відгуки настійно підказували, що вертикальна орієнтація діаграми передбачала спрямованість. "Стрілки забивають діаграму", - стверджували мої колеги. Тому для об'єктів покладайтеся на простий, нижній контрастний колір лінії.

Позначення марки як квадрати

Іноді забавно бачити, як професіонали системи дизайну здивовано нагадують, що їх система не є вершиною піраміди. Кожна система цифрового дизайну, якою я працював, успадковує основні візуальні основи - колір, типографіку, ілюстрації - та інші властивості однієї чи декількох ідентифікацій бренда, керованих у бренда чи маркетингової команди. Бренди представлені у вигляді квадрата.

Кілька брендів як батьків однієї системи

Відображення брендів корисно для зображення багатьох ідентичностей, підтримуваних єдиною системою. Наприклад, система дизайну Marriott включала правила для різних готельних властивостей, таких як Courtyard, Renesance та JW Marriott.

Організаційні межі як стовпці

Жодна архітектура систем проектування на підприємстві не є повною без зазначення організаційного підрозділу (служб), який обслуговує кожен. Вони можуть мати форму доменів, племен та загонів. Або, можливо, бізнес-напрямки. Або сегменти подорожі клієнта. Незалежно від того, як ваша компанія ділить роботу та команди, якщо вона має будь-який масштаб, вона має підрозділи.

Я вирішив використовувати фіолетові межі, пунктирні та товщі, ніж лінії, що з'єднують вузли. Крім того, одно- або дворівневі фіолетові мітки, орієнтовані на базову лінію діаграми, чітко позначають кожну область.

Приклади

Щоб побачити візуальну лексику в дії, я навожу цілий ряд прикладів, підтримуваних описовими історіями, щоб встановити контекст та розкрити проблеми високого рівня, з якими стикаються ці системи (системи).

Приклад: Центральна система з посередниками

Ця архітектурна система дизайну означає визнану єдину систему, від якої залежать усі цифрові продукти. Деякі продукти приймають систему безпосередньо. В інших випадках до системи залучаються команди, які пропонують JavaScript на основі React і Vue перекладів своєї ванільної HTML та CSS-бібліотеки.

Команда проектувальної системи визнала архітектурну надмірність та складність, ведучи наступне покоління робіт, щоб запропонувати веб-компоненти, щоб полегшити потребу в таких перекладах.

Приклад: Малі банки та страхові компанії

Багато страхових компаній та банків організовують команди з цифрових продуктів, коли воронка протікає від маркетингу .com через торгові лійки, що набувають клієнтів для обслуговування досвіду управління операціями, такими як вимоги та переказ грошей відповідно. Це може призвести до, щонайменше, двох систем проектування, розділення принаймні .com та обслуговування, якщо не третьої системи для потоків, що залучають клієнтів у розщепленому просторі між.

Приклад: Програмне забезпечення як послуга (Освіта)

Розглянемо портфель програмного забезпечення під парасолькою материнської компанії. Їх система виникла завдяки перепроектуванню їхнього флагманського пропозиції: вмісту та інтерактивних медіа як навчальних програм.

Після того, як флагмани були розгорнуті, команди застосували систему до інструментів для наскрізних продуктів (аутентифікація, домашня сторінка, панель інструментів, пошук та управління обліковими записами) та адміністративні консолі, де викладачі керували даними учнів та доступом до них. Зі зростанням успіху вони почали дивитися на осередок, який створював власні сайти з білою етикеткою для клієнтів.

Приклад: бізнес-підрозділи за типом клієнта

Одна компанія організувала цифрові команди в підрозділи з розробки продуктів, які окремо обслуговували споживачів, роботодавців та їх працівників та великі установи у своїй галузі. В результаті в кожному підрозділі з'явилися чіткі системи.

Системні команди ділилися практикою та інструментами, але залишалися автономними для оптимального обслуговування окремих клієнтів. Це допомогло уникнути проблем, як-от передчасне зближення мови дизайну, яка ще не була пріоритетною.

Приклад: Програмне забезпечення як послуга (підприємство)

Програмна компанія створила потужну централізовану систему із впровадженням усіх флагманів та вторинних продуктів. При цьому, зберігається окремий досвід проектної документації, окрім універсально застосованих кодованих компонентів. Деякі ключові продукти розширили систему, будь то дизайнери з продуктів A&B, що керують бібліотеками Sketch, або інженер, що підтримує код компонентів для її команд. Крім того, потенційне придбання призведе до обговорення інтеграції на рівні продукту, системи та бренда.

Ви можете завантажити файл ескізів символів та прикладів, відображених тут.