Що ускладнює продукт?

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

Шляхи ускладнення

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

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

Якісь продукти переживають ускладнення та стають успішніші, якісь навпаки помирають від надлишкових ускладнень.

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

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

Розділяй та управляй

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

Принципи розподілу команд:

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

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

Така взаємодія потребує певних підходів для синхронізації спільної роботи команд.

Синхронізація

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

Артефакти, що допомагають втримати єдину візію:

Єдина інформаційна архітектура

Інформаційна архітектура – це мапа основних розділів додатку, що показує групування розділів та вкладені функції, основа навігації. Може містити розділи одного так і різні додатки.

Будується на основі ментальної моделі предметної області. Можна залучати користувачів та досліджувати їх ментальні моделі методом сортування карток (card sorting)

За наявності різних груп користувачів в рамках одного додатку, може відображати доступ різних груп користувачів.

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

Дизайн принципи

Дизайн принципи – це певні твердження про очікування від дизайну на рівні компанії чи продукту. Їх зазвичай не багато.

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

Підбірка дизайн принципів різних компаній

Examples

An Open Source collection of Design Principles and methods

principles.design

Аналіз впливу (impact analysis) при змінах

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

Щоб ефективно впровадити зміни, варто:

1. Ознайомитися з інсуючою версію:
1. Коли зробили,
2. Чому,
3. Як працює,
4. Що є схожого
2. Проаналізувати фідбек від користувачів (спитати напряму та запросити інформацію в команди підтримки)
3. Замапити зміни на CJM
4. Замапити зміни на інформаційну архітектуру
5. Загрумити з розробниками
6. Переходити до дизайну екранів
7. Бути готовим до ітерацій

Деякі зміни можуть зачипити вашу дизайн систему, інформаційну архітектуру та навіть дизайн принципи. По масштабності впливу можна розрізняти малі (S), середні (M), та глобальні знміни (XL ... XXXL).

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

Дизайн системи

Досить популярний нині тренд в дизайн спільноті. Допомагають випрацювати:

• Єдину візуальну мову продукту (Styleguide)
• Ієрархію елементів управління (UI Kit)
• Можуть включати єдиний стиль комунікації (Tone of voice)
• Основні типи екранів та патерни організації екранів додатку

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