Рівні системи проектування

Час для зрілих систем для підтримки рівнів роботи

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

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

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

Система може підтримувати рівні

Ідеї ​​спливають. Вони можуть почати з ідеї в думці однієї людини. Ця ідея корисна співпрацівнику, що знаходиться поруч. Інші поступово розуміють, що поділяють потребу. Врешті-решт ідея може - а може і не бути - актуальною для всіх. Ми можемо архітектурно проектувати системи, щоб вони відображали такі рівні.

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

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

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

Нагорі, «Основна», що відповідає всім

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

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

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

Винос: Після того, як почнуть з'являтися додаткові системні яруси, призначте "основний" рівень, корисний для всіх прийнятих та підтримуваний ідентифікованою базовою групою. Назвіть це, що ви хочете - серцевина, основа, фундамент, що завгодно - щоб чітко позначити ці найважливіші особливості вгорі.

Почніть з рівнів для бізнес-підрозділів ...

Набори функцій природним чином формуються в організаційних межах, таких як групи A, B, C і D, зображені нижче.

Підсистеми другого рівня, що підтримують різні напрямки бізнесу (A, B, C, D)

Мої спостереження в різних системах проектування припускають, що це вже відбувається, але тимчасово не керується командою системи. Одна команда системи запропонувала Core Kit активів Sketch та код компонента. У дикій природі дизайнери платформ у групах A&B зробили чітке розширення набору ескізів, а інженер зробив "C Kit" компонентного коду для своєї групи. У таких випадках системна програма може моделювати та надавати інструменти для таких розширень дизайну та коду.

… А також розширення можливостей рівнів ACROSS підрозділів

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

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

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

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

Розгорніть використання системних інструментів для багаторівневої роботи

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

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

Приклад: Організація збуту, що будує розширену бібліотеку компонентів

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

Винос: бізнес-підрозділи та лінійки продуктів мотивовані швидко працювати, виконувати цілі та використовувати їх разом із сусідніми командами. Системні інструменти дозволяють розробити швидку, систематичну практику проектування та розробки для того, щоб спонукати групи рухатися вперед, не обов'язково ускладнюючи основні системи.

Модельні дозволи для видимості та контролю

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

Команди можуть використовувати такі програми, як Анотація та додаток Lingo для розповсюдження активів бібліотеки Sketch для своєї системи. Комплект надає основні кнопки, прапорець та багато інших компонентів для всієї спільноти, хоча лише члени основної команди (та ключові партнери) мають доступ до редагування.

Додаткові набори (такі як Продукти, Рахунок, Подарунки та Оформити замовлення) можуть організувати другий рівень підгруп за досвідом. Ці підгрупи можуть розширювати компоненти, такі як картки та форми, а також включати активи (наприклад, зображення) та компоненти (наприклад, заголовок облікового запису), що стосуються лише їхньої команди. Незважаючи на те, що кожен набір видно всій спільноті дизайнерів, права редагування кожного набору обмежені дизайнерами в цьому бізнес-підрозділі, а також основною командою.

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

Куліруйте простір імен централізовано

Після того, як система заохочує внески різних груп, вона може стати диким диким заходом. Ви повинні стежити за премією: бібліотека, яка ділиться архітектурою без конфліктів і зіткнень. Нікому не потрібні прапорець, кнопка дії та кнопка дії-галочка-в-кнопці котиться навколо.

Для цього потрібно керувати простором імен для забезпечення нових функцій:

  • не перетинайтеся з іншими можливостями функції
  • не буде стикатися з іншими іменами функцій, як вони використовуються або рекламуються
  • мінімізує зміни імені, тому раннім особам, які прийматимуть їх, не доведеться переробляти пізніше

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

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

Розкрийте рівні в документації

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

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

Винос: Додавання наборів за межі ядра - це завдання архітектури інформації для інструментів та документації. Це змушує питання класифікації, організації та пріоритетності. Передбачте цільовий стан, а потім поступово будуйте інструменти для нього, по черзі.

Чим вище рівень, тим вище якість

Основні функції має бути найвищої якості. З появою ярусів якість нижче основної буде змінюватися. Атласкітські пакети коду Atlasssit натякають на другий рівень груп функцій як для бізнес-підрозділів (бітбукет), так і для функцій у групах (редактор, домашня сторінка, пошук та навігація), де якість деяких може бути нижчою, ніж у базовій. Документація щодо сайту IBM Carbon має два рівні: неявне ядро ​​та "експериментальний" другий рівень:

«Експериментальні компоненти, конструкції та інші ресурси представлені для тестування та зворотного зв’язку. Вони не призначені для виробничого використання ». - IBM Carbon

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

Критерії якості функцій за рівнем

Одна модель посилює контроль якості, виходячи з того, наскільки широко використовується ця функція для бізнес-підрозділів:

  • Функції рівня "Внутрішньої групи" повинні проходити перевірку веб-переглядача та зв'язування коду, вирішувати проблеми доступності, що стосуються тих, хто його робить, та бути стилем таким чином, що відповідає основній мові дизайну.
  • Функції рівня "через всі групи" також повинні бути чуйними, використовувати BEM CSS методологію, семантичну версію, зміни журналів, інкапсулювати стиль залежно від дизайнерських жетонів, блоку настройки та тестів візуальної регресії та бути затвердженим усіма спільнотами дизайну та / або розробки.
  • Елементи верхнього ядра ярусу також повинні пройти комплексний огляд доступності, включити розмір (S, M, L), працювати в фоновому режимі (білий, світлий, темний, чорний і бренд), а також увімкнути спеціальні функції тематизації, аналітики та інтернаціоналізації, такі як справа наліво.

Запустити систему сьогодні і ледве відповідати рівню якості «В межах групи»? Я не суджу тебе. Однак ваші усиновлювачі можуть бути. Тому подумайте, яка якість потрібна, і намітьте шлях, щоб дістатися туди.

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

Використовуйте рівні в розмовах про внески

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

  • Давайте організуємо функції редактора як набір ... ("Що?")
  • ... побудований на рівні 2 ... ("Де?" Та "Наскільки добре?")
  • … Що нам знадобляться 3 спринти (“Скільки це коштує?”)…
  • … Для обслуговування груп продуктів A і C, але не B, D або E ("Хто?").

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

Винос: Ви можете відображати можливості «внеску» як просування через яруси системи. Ці учасники потребують створення архітектури системи та членів колективу системи для виявлення можливостей та керування процесом.

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