STOLZ о графическом дизайне
- Автор: Штольц Юлий
- Серия: STOLZ #2
- Год: 2021
- Язык: русский
- ISBN: 978-5-532-94029-1
- Жанр: Прочее домоводство
Электронная книга - «STOLZ о графическом дизайне». Краткое содержание книги:
Звучит она так: у вас один экран, часы — будильник и две или три кнопки. Как вы их расположите и почему?
В таком раскладе хватит и одной кнопки, но дизайнеры часто зависимы от объектов, которые в их руках. И пытаются использовать всё забывая о «UX». Не стоит делать то, что перегрузит и усложнит функционал. Для этого достаточно одной кнопки, с двумя положениями-включить и выключить.
UX вкратце (user experience)
Опыт пользователя с вашим дизайном и соответственно продуктом бывает двух типов плохо, хорошо третьего пока что не дано.
UX-дизайн — многомерное определение, которое охватывает широкую область знаний и характеризует ощущения пользователя, взаимодействующего с онлайн-ресурсом, и включает множество составляющих: интерактивный дизайн, информационную архитектуру, визуальный дизайн, юзабилити и взаимодействие между человеком и компьютером. (Википедия)
Другая главная постарается более глубже познакомить вас со схемами, внутренними переживаниями пользователя. Самая основная часть — дизайн интерфейса невозможен без схемы работы продукта. Схема должна обладать точками входа и выхода пользователя.
Модуль, grid
Для начала разработки «UI» стоит забыть про дизайн и вспомнить про модульную сетку. Как же вернее всего её искать и использовать?
Не стоит разрабатывать на первых этапах свою уникальную сетку. Для вас давно создан «Bootstrap framework», для веба и мобильных версии сайтов.
Для приложения «Google» и «Apple» так же уже всё разработали.
Берём готовые и верно отмеренные модули и ставим нужное место соответственно «UX» схеме. Дальше дело за малым создать дизайн соответственно этим ограничениям. Если обойти эти шаги, скорее всего ваш интерфейс не будет воплощён в коде. Во-первых, сложно пристраивать код используя не стандартизированный дизайн, во-вторых, это никому не нужно. Дизайн должен быть, но в этом направлении на мой взгляд он должен быть сдержанным соответственно «гайдам» от «Google» или «Apple». Если это веб, то нет ничего сложного и плохого использовать «Bootstrap framework» — он великолепен.
Шрифт
В интерфейсе главное это простота, я в свою очередь принял решение использовать стандартные шрифты для веба и приложений. Стандартный отступы и размеры написания. Возможно, это не слишком новаторски, хотя это позволяет добиться понимания интерфейса пользователем и разработчиком.
Дизайн уникальных фишек приложении можно применять, но не в самом интерфейсе. Это актуально в дополнительных материалах — баннеры, фотографии в карточках, микровзаимодействиями тому подобное. Шрифт в интерфейсе — это способ идеальной коммуникации с неизвестным икс. И если этот икс имеет свои индивидуальные проблемы и предпочтения — ваша идея уникальных шрифтов просто может не понравиться или быть не удобной. А шрифты по умолчанию разработались для стандартизации и простоты усвоения информации от приложения к приложению.
Как исключение сюда стоит добавить игры, хотя это я думаю и так ясно.
Прототип — прототипу рознь
Понимание прототипа у каждого специалиста разное. Часто бываю случаи конфликта понимания, человек от кода не понимает человека от дизайна. Понимание прототипа у разработчика на «React» совершенно отличается от «UI» дизайнера. Будьте готовы к спору: прототип в коде более прототип, чем то, что у вас.
Это не простительно со стороны разработчика так снисходительно относиться к дизайнерам. Разработчики часто забывают про то, что все книги, сайты, видео и прочий материал, по которому они учились кодить создавались дизайнерами, типографии и смежными профессиям.
Но это камень в их огороде, дизайнеру стоит помнить: не прототип, а визуальный прототип взаимодействия. Это как правило ставит на место заносчивых разработчиков. Которые понятия не имеют в большем случае о сетки Брокманна, о искусстве цвета от Иттена и другому ряду знаний, не относящихся к коду. Дизайнер в свою очередь должен понимать, что его услуги часто и не нужны, ведь существуют языки, которые могут создать интерфейс продукта и без него. Конечно, это будет «MVP» продукт, без изюминки и сложен для большинства пользователей.
Минимально жизнеспособный продукт (minimum viable product, MVP) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Основная задача — получение обратной связи для формирования гипотез дальнейшего развития продукта. Сбор информации от MVP зачастую дешевле, чем разработка продукта с большим количеством функций. (Википедия)