Якщо ви витрачаєте більшу частину свого часу в статичних інструментах, таких як Sketch, то вам варто переїхати в браузер і чим раніше, тим краще.
Понад три роки тому я написав свій перший пост на тему «Дизайн у браузері». Пост називався «Як я задизайнив сайт без Фотошопу»
Він розповідав історію про те, як я створив закінчений сайт без використання Фотошопа. У ті дні Фотошоп був головним інструментом у вебдизайні. Але зараз це не так. З великовагового фото-редактора ми пересіли на Скетч, який був зроблений для створення інтерфейсів.
Скетч був великим стрибком вперед у порівнянні з тим, до чого ми звикли. Він поліпшив процес дизайну і зробив його більш ефективним. Артборди були прекрасні і ще в ньому не було зайвого лушпиння, що не стосується дизайну інтерфейсів. Я був настільки захоплений ним, що написав пост «10 трюків у Скетч для дизайнерів».
Хоча я дуже люблю Скетч, я не вважаю його ідеальним інструментом, тому що він не вирішує реальну проблему.
Проблема в тому, що ми, дизайнери, все ще малюємо статичний дизайн для інтерактивного середовища.
У програмах для статичного дизайну, таких як Фотошоп або Скетч, ви проводите більшу частину часу створюючи максимально вилизані картинки, які далекі як від реальності, так і від реалізації. Статичні картинки не враховують обмежень і особливостей браузерів, також, вони не здатні показати будь-які рухомі частини.
До того ж, вони не можуть передати весь функціонал. Погляньте на картинку нижче, вона може показати лише один ідеальний стан того як виглядає і працює додаток. Звичайно, ви можете намалювати кілька артбордів у Скетчі, щоб показати ще один стан, коли щось натиснуто, але ви ніколи не зможете показати будь-яку взаємодію.
Просто уявіть як все це працює
І це при тому, що носій для якого ми всі малюємо - інтерактивний.
Нові інструменти для створення прототипів такі як: Invision, Principle або Framer (насправді їх більше), звичайно, допомогли нам наблизиться до інтерактивності.
Але проблема цих інструментів полягає в тому, що ми всього лише роздмухуємо стек дизайну, додаючи проблем, в той час як виконана робота не наближає нас до реалізації.
Також, я знаходжу дивним, що ми просимо технологів (програмістів) відтворити те, що ми і так вже зробили в цих інструментах. Хіба ми (команда) не виконуємо роботу двічі, змушуючи технологів відтворити наш дизайн в HTML і CSS?
Щоб наблизити дизайн до реалізації, дизайнерам слід якомога швидше переводити свою роботу в браузер.
Я вважаю, що для того що б знати де все поламається, а де буде працювати, ви повинні бачити матеріал і взаємодіяти з ним в його природному середовищі проживання.
Особисто я виявив, що є багато переваг при переході на браузер:
- Ви отримуєте те, що бачите (WYSIWYG). Кольори, шрифти, розміри, відступи тощо. Все виглядає так, як побачить користувач.
- Кінець нескінченним артбордам. Тепер у вас тільки один canvas і це браузер, в якому присутня інтерактивність за замовчуванням.
- Не потрібно витрачати часу на замір пікселів перед передачею технологу. Все вже прописано в коді.
- Можна легко виправити щось у своєму дизайні без участі технологів або програмістів.
- При тестуванні ви бачите як насправді користувачі взаємодіють з вашим дизайном.
- Менше питань і нарад з інвесторами, клієнтами, програмістами = Зекономлений час = Зекономлені гроші
- Анімація більше не є запізнілою думкою. Навпаки, ви більше думаєте про те, як заанімувати стан наведення або як вирішити проблеми за допомогою взаємодії.
- Вам більше не потрібно витрачати гроші на дороге ПЗ для прототипування.
- Найкраще зі списку. Ви скорочуєте розрив між дизайном і реалізацією, дозволяючи програмістам працювати над більш цікавими сторонами проекту = Набагато більш щасливі інженери.
Існує, звичайно, одна річ, яка робить проектування в браузері важким, і це крута крива навчання.
Не всім легко навчитися кодити HTML/CSS/JS. Якщо є бажання вчитися, я раджу почати тут.
Я знаю, що заголовок поста може трохи ввести в оману.
Насправді я не думаю, що потрібно зовсім перестати дизайнити в Скетчі. Скетч - прекрасний інструмент, що дозволяє швидко накидати концепт того, що ви хочете створити. Але все ж потрібно переводити роботу в браузер якомога раніше. Вищезгадані переваги повинні відповісти на питання, чому.
