Чуйний дизайн

І роль розвитку в дизайні

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

Чуйний веб-дизайн. Темне мистецтво?

Це 2018 рік. Чому ми все ще говоримо про чуйний дизайн?

Я вперше навчився чуйного дизайну ще в 2011 році. Почав читати книгу Ітана Маркота «Чуйний веб-дизайн».

Темне мистецтво веб-дизайну?

Чуйний дизайн був річчю приблизно 8-9 років. У перші дні було просто вражаюче побачити чуйний веб-сайт! Майже, «темне мистецтво» веб-дизайну. Але, це було давно.

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

"... чуйний веб-сайт ..."

Моя перша думка - це завжди:

"Ну, очевидно ..."

Але значна частина моєї позаштатної роботи з веб-розробки стосується "прискорення речей". Дизайнери просять мене створити їм веб-сайт, а потім надішліть мені макет веб-сайту лише для настільних ПК. І моє перше питання завжди:

"Як це виглядає на мобільному телефоні? На планшеті? "

Подумайте за межами робочого столу

Цитувати з книги Етана:

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

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

Історія жахів веб-дизайну пішла не так

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

Компанія витратила 3+ місяців і більше 100 000 доларів на масштабний переробку свого веб-сайту. Вони створили чудову концепційну роботу, але вони ніде не були близькі до готового для побудови дизайну, і важко запускається дата, яка болісно зростала.

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

Вони тільки розробили гарну картинку веб-сайту. Не все, що можна було б побудувати.

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

Коли я відкрив їх перший PSD, я виявив, що контейнер веб-сайту був приблизно 1,750 пікселів. Якщо ви ще не задихаєтесь, вважайте, що ця ширина спрацювала б лише для 1-5% трафіку!

Трохи копавши, причини цього стали зрозумілими:

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

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

Зрештою, вони запустили (щось) в термін. Але, маючи лише половину створеного веб-сайту, безліч питань та безліч незадоволених зацікавлених сторін сердито запитують:

"Як це сталося ?!"

Розробники зрозуміють це

Це, на жаль, так думає багато дизайнерів.

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

Як дизайнер я заповнюю прогалини в роботі інших дизайнерів. Але, як розробник, я переходжу над та далі *, щоб закінчити те, що повинен мати дизайнер.

* Примітка: Чесно кажучи, я насправді (іноді) насолоджуюся цим завданням як творчий розробник. Це більше сказати; Ваш середній розробник / розробник не оцінить це.

Що ми можемо з цим зробити?

Я вважаю, що це зводиться до зміни способу мислення:

  • Думати чуйно.
  • Щоб переосмислити процес розробки.

Пізніше в цій статті я розповім про деякі речі, які я спробував з дизайнерськими командами, з якими я працював, і виявився успішним. Але спочатку; Найсуперечливіша частина цієї статті… Намацуйте себе…

Справа для дизайнерів, які навчаються кодувати

Я стирчаю тут шию ... Але не бійся! Продовжуйте читати моє повне обґрунтування. Це не так "чорно-біле", як ви могли подумати ...

Таке мислення «розробники зрозуміють це» недостатньо добре.

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

Це не так чорно-біло, як "дизайнери повинні кодувати". Це не. Але, це допомагає.

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

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

Це гравюра 16-го століття, італійський скульптор Доменіко дель Барб'єр, яку називають "двома в'ялими людьми та їх скелетами".

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

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

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

Розсікання популярної аналогії

Якщо ви коли-небудь дискутували про те, "чи повинні дизайнери знати код" з візуальними дизайнерами, ви, ймовірно, чули цей рядок:

"Але архітектори не знають, як будувати!"

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

Мій тато був обстежувачем кількості. Його робота полягала в оцінці ризику та вкладанні ціни на бачення архітекторів - часто нереальне. І зрозуміло, він не захоплювався деякими архітекторами, з якими працював! (Наскільки добре знайомі стосунки між візуальними дизайнерами та розробниками? ")

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

Моя чесна порада:

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

Але, якщо цього не зробити:

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

Два способи наблизитись до чуйного веб-дизайну

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

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

Підхід 1: Коли хтось інший збирається будувати те, що я проектую

У цьому випадку як дизайнер:

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

І кінцевий продукт виглядає приблизно так:

Дизайнерський кейс веб-сайту Adobe Portfolio (2016)

Підхід 2: Коли я збираюся будувати те, що сам проектую

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

Прикладом такого підходу є мій особистий проект «Клуб хвиль:

Клубний проект «Клуб хвиль»

Як ви бачите вище, я лише висміяв основні сторінки на робочому столі.

Мій процес проектування пройшов приблизно так:

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

Ще один приклад такого підходу до веб-дизайну - веб-сайт Owl Studios. Я знущався над цим на робочому столі, як видно нижче:

Тематичне дослідження дизайну Owl Studios

І тоді я розважався з ним, у браузері:

У мене не було реального плану, як анімувати веб-сайт. Я просто відчув це, написав код і оновив браузер, поки не був задоволений цим. Це була дуже "річ у розробці", але 100% частина проектування.

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

Питання тонкої настройки

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

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

  • Чи постачаєте ви їх за допомогою раунду після раунду перетворень електронною поштою?
  • Ви їх на Слэкса заїжджаєте?
  • Ви подаєте десятки випусків GitHub?
  • Ви надаєте їм новий дизайн-файл, в якому висвітлюються зміни кілька разів?
  • Або ти йдеш сидіти поруч із ними і кажеш їм, що робити !?
Обіцяю вам, жоден розробник не хоче дизайнера через їх плече, керування на задньому сидінні!

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

Розробка - це дизайн

Дизайнерам, менеджерам продуктів, менеджерам дизайну і навіть розробникам потрібно припинити думати про розробку як про окремий від дизайну.

І це не повинно означати:

  • "Дизайнери повинні кодувати".
  • Або; "Розробники повинні розробляти".

Це означає; Ми повинні працювати разом.

HTML, CSS і навіть JavaScript сьогодні є частиною процесу проектування.

Дизайн не припиняється, як тільки ви залишите Sketch, Photoshop або XD. Або коли ви запустили веб-сайт або продукт.

  • Ми налаштовуємо свої дизайни у ​​браузері.
  • Ми протестуємо свої проекти з реальними людьми,
  • Потім дизайнери та розробники працюють разом, щоб переробити дизайн.

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

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

Епікурсія №6 та основна культура, про що йдеться у статті:

Якщо розробка подібних речей не вважається креативною чи частиною процесу дизайну… Тоді я не знаю, що таке.

Отже, що стосується ролі розробки в дизайні:

Зробіть:

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

Не роби:

Просто скиньте дизайни розробникам в кінці процесу і сподівайтеся, що все нормально. Або ви почнете страшилку, щоб протистояти моїм раніше!

Ви команда, дійте як один

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

  • Поділ вашої команди ставить непотрібні межі.
  • Створює подільну культуру.
  • І ускладнює співпрацю.

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

Мислення чуйно

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

Отже, як ми навчаємо візуальних дизайнерів мислити чуйно?

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

Нижче наведено 5 речей, які я спробував із командами дизайнерів у Нью-Йорку, які виявились ефективними:

1) Дизайн із чуйними шаблонами

Ось шаблон Sketch, який я створив для команди дизайнерів на попередній роботі:

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

Хороший чуйний шаблон включає в себе:

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

Тепер, я повинен сказати; Я думаю, що важливо не думати про веб-сайт як про "робочий стіл", "планшет" і "мобільний". Або "точка розриву 1", "точка розриву 2" і так далі ... Але це ефективний спосіб обрамлення її для людей, які не мають технічних питань. І досить добре для такого візуального підходу.

Я думаю, що тут важливим є урок:

Стресовий тест

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

2) Це не "версія"

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

  • Це не версія.
  • Це той самий веб-сайт.
  • Це той самий HTML-код.
  • Змінено лише CSS.

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

Я думаю, що саме цей «варіант мислення» - це те, що деякі дизайнери відштовхуються від дизайну.

"Хтось ще придумає іншу версію ..."

Або;

"Не так багато людей побачать це на мобільному телефоні ..."

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

3) Розробка для всіх сценаріїв, а не лише найкращого сценарію

Подумайте про чуйний макет як:

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

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

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

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

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

4) Подумай у відсотках, а не в пікселях

Ви можете розробити щось із шириною 100 пікселів у вашому програмному забезпеченні. Але в браузері 100px буде відсотковою шириною контейнера. Отже, коли ширина браузера зменшиться, ваш 100px стане більше схожим на 80px, 60px, 40px тощо.

Тепер подумайте про вміст, який ви маєте в цій області 100 пікселів ...

  • Чи буде вона працювати при меншій ширині, ніж 100 пікселів?
  • Якщо ні, то вам потрібно або переосмислити макет, або вміст.
  • Або створити точку перерви, щоб висвітлити те, що відбувається, коли воно більше не працює.

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

Я створив цей швидкий макет (вище), щоб продемонструвати цю точку молодшим (та старшим) візуальним дизайнерам на моїй останній роботі, яка виявилася дійсно ефективною!

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

Іноді бачити - це вірити. Демонстрація таких речей, як макет дизайну або швидка демонстрація у веб-переглядачі (через таку послугу, як Codepen), може бути ключовою для розуміння людей.

5) Переглядайте конструкції в браузері або на пристрої

Повернувшись до моєї історії жахів раніше: помилки легко робляться, коли ми не грунтуємо свою роботу в реальності. Так:

  • Не переглядайте свою роботу лише на великих моніторах чи телевізійних екранах.
  • Не друкуйте (лише) макети і не переглядайте їх, закріплених на стіні.

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

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

Сподіваюся, це демонструє мою точку зору:

Зліва - макет дизайну веб-сторінки. Ваша команда розглядає це як цілий, згуртований дизайн, так само, як ви б фрагмент графічного дизайну.

Але праворуч - це те, що користувач насправді бачить - у браузері - під час прокрутки. Є велика різниця! Отже, ви повинні врахувати цю реальність, більше, ніж сторінку в цілому.

Це не графічний дизайн, це веб-дизайн.

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

Важливо зберігати перспективу та обґрунтовувати свої проекти в реальності.

Оновлення: 2019. Я написав книгу про дизайн системи та керівництво цифровими брендами! https://designsystemfoundations.com