Sketch принес совершенно новые стандарты в размерах файлов с дизайном. Теперь вы очень редко можете увидеть 10 гигабайтные файлы Photoshop-а. Тем не менее большие Sketch файлы существуют и когда вы с ними работаете, они влияют на производительность самого Sketch-а. В результате, замедляется ваша производительность, как дизайнеров.
Вот давайте будем откровенны сейчас: это не файлы Sketch-а становятся большими по магии. Это дизайнеры, которые заполняют свои файлы неиспользуемыми, не оптимизированными и скрытыми элементами, которые занимают так неприлично много места.
Мы в Flawless App лично столкнулись с проблемой чрезмерно больших Sketch файлов. Как правило, мы используем отдельный Sketch файл на каждый «продукт». Под «продуктом» я подразумеваю: наше основное menu bar приложение для macOS, сайт/лендинг, промо материалы для соц. сетей, пресс кит для медиа, иллюстрации статей на нашем medium блоге
Как любой другой инженер поступил бы в этой ситуации — мы написали скрипт, который автоматически чистил Sketch файл, чтобы уменьшить его размер.
Скрипт — прекрасное решение, но только если ты на одной волне с Терминалом. В конечном итоге мы решили, что нам необходимо что-то более человечное. Это позволило бы всей команде использовать этот инструмент, без лишнего дискомфорта как в случае с локальным скриптом. Мы также решили, что сделаем приложение публичным и бесплатным.
Первый прототип
У меня уже были некоторые абстрактные идея, прежде чем приступить непосредственно к UI. Основная цель была создать что-то что будет постоянно под рукой. Что-то что позволит оптимизировать и сжимать Sketch файлы настолько быстро насколько это возможно не отвлекаясь от рабочего процесса. macOS приложение для menu bar-а было очевидным выбором для нас:
- У нас уже был внутренний фреймворк для macOS menu bar приложений, с множеством возможностей, которых нет в стандартной библиотеке. Мы построили этот фреймворк для нашего основного продукта. Flawless App — это macOS menu bar приложение для iOS разработчиков, которое сравнивает насколько реализация разработчика соответствует первоначальному дизайну в реальном времени.
- Приложение в menu bar-е можно использовать даже если Sketch-а нет на компьютере или он закрыт.
- Писать приложение для macOS было для нас банально быстрее, чем разрабатывать с нуля плагин для Sketch-а (поскольку у нас уже были некоторые компоненты готовы)
Для нас также было важно дать пользователю возможность выбирать какие оптимизации будут применяться к выбранному файлу.
Ниже первый wireframe нарисованный карандашом на старой доброй бумаге, пока без никаких модных инструментов прототипирования.
Вывод 1:
Прежде чем приступать к рисованию интерфейса, созданию прототипов в бесконечном количестве доступных инструментов, даже к рисованию wireframe-ов на бумажке. Стоит подумать сначала какие цели вы хотите достичь вашим дизайном. Кто будет использовать ваш дизайн и как эти люди будут взаимодействовать с приложением.
Цветовая палитра и шрифты
Во время дискуссий с командой мы не нашли критичных UX проколов в первоначальных wireframe-ах. Поэтому я начал с создания подходящей цветовой палитры и выбора шрифтов для будущего приложения.
Я хотел чтобы приложение было светлым и визуально дифференцировалось от нашего основного продукта. Поэтому я подобрал следующие палитры цветов:
Структура следующая: первая строка предназначена для разных уровней текста, вторая строка — акцент цвета. Все второстепенные цвета были выведены из первоначального базового цвета применяя простые правила трансформации в системе HSB (Hue Saturation Brightness)
К примеру, давайте возьмем #4A90E2 (синий), что в системе HSB будет выглядеть как (212, 67, 89) в качестве первоначального базового цвета. Чтобы получить более темную вариацию этого цвета нам необходимо уменьшить Brightness, увеличить Saturation и совсем немного подвинуть Hue. Таким образом у нас получится #2477C9, что в HSB выглядит как (210, 82, 79). Я использовал это правило для получения всех вариации на картинке выше.
В конечном итоге я остановился на первой цветовой палитре (оранжевая). Sketch файлы и логотип Sketch выполнены в похожей палитре, поэтому наше приложение будет более гармонично смотреться.
Вывод 2:
Поиск правильного цвета для меня всегда был сложным процессом. Обычно я трачу слишком много времени, чтобы найти подходящий цвет. Вот несколько инструментов и ресурсов, которые я использую практически каждый день для ускорения этого процесса:
- Adobe Kuler поможет найти комплементарный цвет для любого выбранного цвета
- Khroma использует машинное обучение, чтобы генерировать палитры цветов на основе ваших предпочтений
- Статья Erik Kennedy Color in UI Design: A (Practical) Framework просто небывалой полезности материал. Я прочел его около 8 месяцев назад и с тех пор использую систему HSB гораздо чаще, чем стандартную RGB в Sketch-е
Если вы не планируете делать что-то совсем нестандартное, стоит использовать «родные» системные шрифты (в нашем случае шрифты предоставляемые macOS). Родные шрифты рендерятся быстрее и разработчику будет проще их интегрировать в приложение. Однако глубоко в душе я хотел попробовать Montserrat в macOS приложении, поэтому я просто не смог устоят 🙂
Вывод 3:
Существует огромное количество ресурсов для подбора шрифтов. Тем не менее я предпочитаю старый добрый Google Fonts чтобы понять, как определенный шрифт ведет себя в различных ситуациях.
Первая итерация дизайна
Я начал преображать wireframe-ы в какой-то более менее понятный интерфейс. Основная структура использования приложения задумывалась так:
- Пользователь перетаскивает Sketch файл в окно приложения
- Далее пользователь выбирает, какие оптимизации необходимо применить к файлу
- Собственно происходит процесс оптимизации
- Пользователь сохраняет файл
Весь дизайн я делал в Sketch-е и на данной стадии я был полностью удовлетворен результатом. Поскольку у меня уже был опыт проектирования macOS menu bar приложений, размер шрифта и отступы были мне понятны и являлись стандартными. Несмотря на это, с первой итерацией было достаточно много мелких проблем, которые я опишу ниже более подробно.
Вывод 4:
Если вы никогда не проектировали интерфейс для macOS — я рекомендую сперва изучить стандартные UI элементы в Facebook Desktop Design Kit. Прежде всего вы поймете «визуальный язык» системы, какие отступы и размеры для элементов являются приемлемы. Для macOS приложения 12 pt или 14 pt для шрифта — это вполне нормально.
Ошибка 1: Пропущенное состояние
С дизайном выше всё было хорошо, всё не считая того, что я напрочь забыл добавить состояние приложения во время оптимизации Sketch файла. Как мне известно из опыта, количество пропущенных состояний на стадии дизайна прямо пропорционально равняется степени головной боли инженеров на стадии разработки.
Как часто разработчики жалуются, что дизайнеры «творят» в вакууме? Обсуждая такие проблемы как: пропущенные состояния, использование идеальных данных, отсутсвие empty state-ов
Вывод 5:
.Прежде чем высылать дизайн разработчику, стоит убедиться, что не пропущены важные шаги в пользовательском flow. Гораздо лучше убедиться что все состояния специфицированы, чтобы избежать вопросов от разработчика наподобии: «Как это должно выглядеть [в таких-то условиях]?». Хорошая техника поиска таких пропущенных состояний — использовать инструменты для прототипирования. На данный момент я не знаю способа быстрее чем использовать Craft Prototype (от InVision) прямо в Sketch.