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

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


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

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

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



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

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


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



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

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

Тому, редизайн роботи інших людей — це дурість. Нове лого 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".

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.