Дріббліфікація дизайнерів

Примітка: Dribbble - сервіс, де графічні дизайнери хваляться один перед одним своїми роботами.

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

У спільноті дизайнерів спостерігаються витратні тенденції. З одного боку ми спостерігаємо цікаві блоги від Райана Сінгера і Джулії Жуо, які розвивають наше ремесло. З іншого боку, все більша кількість народу постять свої роботи і обговорюють їх на Dribble, що в цілому рухає наше ремесло в зворотний бік. Цей пост - не про Dribble, як такий, він про те, що цінує це співтовариство. Я буду використовувати термін «дизайн продукту», але також буду мати на увазі дизайн користувацьких взаємодій з продуктом.

«Виглядає круто!» - як спільнота Dribbble винагороджує поверхневі роботи

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

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

Найважливіша робота в продуктовому дизайні зазвичай найбільш потворна

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

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

Тому редизайн роботи інших людей - це дурість. Нове лого Yahoo, iOS7, зміни Facebook, New New Twitter, ребрендинг American Airlines.

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

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

Продуктовий дизайн - це місія, бачення, архітектура.

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

Місія - для чого, крім заробляння грошей, існує компанія? Її цілі?

Бачення - яким ми бачимо майбутнє компанії? Як це допоможе нам у досягненні нашої місії?

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

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

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

Для Facebook, архітектура - довідник по людях, їхніх друзях та їхніх інтересах. Довідник по бізнесах, від міжнародних компаній до місцевих магазинчиків. І все це має карту, що показує взаємини всіх частин. Чітке і ясне уявлення продукту, яке зрозумілим чином пов'язане з місією. Дуже складно займатися дизайном без добре певної архітектури продукту. У багатьох випадках дизайнер же і розвиває цю архітектуру. Пояснюючи людям з боку роботу Facebook, я часто креслив подібні діаграми:

Архітектура продукту - це не інформаційна архітектура. Це не набір сторінок з перехресними посиланнями, не демонстрація форм або пояснення роботи кнопок. Прототип з цим краще впорається. Це на рівень нижче - це структура, це основні блоки. Об'єкти в системі та їх взаємодія. У компанії Intercom ми також думаємо про дизайн в контексті продуктової архітектури:

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

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

Грубі начерки і каракулі, що описують ці речі, більш важливі, ніж png з Dribbble. З початку створення до поставки готового продукту, psd і png мені найменш цікаві. Більш важливо - обговорення того, які були компроміси, що було «за» і «проти». Як ідеї поєднуються з баченням або поліпшуються у зв'язку з архітектурою продукту. Замальовки на дошці, на папірцях, на серветках - ось, що потрібно постити на Dribbble. Ось це мені покажіть. Навіть текстовий опис майбутнього продукту важливіший, ніж png, pdf та psd.

Чотири рівні дизайну

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

Результат - чого ми хочемо досягти. Що людям стане краще і легше робити?

Структура - необхідні компоненти системи і зв'язку між ними

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

Вигляд - після проходження попередніх шарів можна зайнятися зовнішнім виглядом. Зробити все красиво. Тепер ви можете скористатися сітками, кольором, шрифтами та іконками.

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

З повсюдним проникненням Мережі дизайн буде значити все більше

Винахід Мережі веде суспільство до найсильніших змін з часів індустріальної революції. Веб проникає скрізь - у будинки, на робочі місця, на приліжкову тумбочку і в кишені одягу. Веб завжди з нами. Він уже проник в автомобілі, одяг, у речі. До 2020 року будь-який бізнес буде пов'язаний з вебом. Як сказав Чарльз Еймс, «зрештою все з'єднується».

Розробка статичних сторінок з лінками - вмираюча професія. Підйом мобільних технологій, API, SDK і відкритих взаємодій між платформами і продуктами малює нам картину майбутнього, де всі ми будемо розробляти системи. PDF з каркасами і фотошоп з зображеннями - відмираючі інструменти. Просунуті дизайнери працюють з начерками, дошками та інструментами прототипування (Quartz Composer, After Effects, Keynote, CSS/HTML).

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

Розробка дизайну відповідно до Завдання

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

«Коли відбувається......, мені треба......, щоб я зміг......»

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

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

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

Примітки: чотирирівнева модель є адаптацією шестирівневої моделі UX (пропозиція, концепція, структура, інформація, взаємодія, зовнішній вигляд), яку ми використовували років вісім тому, а вона в свою чергу сталася від діаграми Джессі Джеймса Гаррета «The Elements of User Experience».

У наступній статті автор дає деякі пояснення і розвиває тему.