Баттхёрт) С крепостничеством не связывал бы, там другие процессы. Но по сути — ес, справедливо, проблема имеет место быть.
Медленно еду по этой колее прямо сейчас, мысли примерно те же. Как в той песне, «when the party is over, you got no way to go». По счастью, худо-бедно хватает ума осознавать и не питать иллюзий.
Просадка ЗП до рынка — полбеды. Есть ещё потеря автономии и прочих негласных привилегий. Их рынок с порога не даст в любом случае, поэтому их жальчее. Вот и едут до финала даже очень неглупые люди.
«Уважаемые господа, семечки в офисе есть запрещено!»
(2013, офис клиента, объявление в приёмной. И рядом станина под штангу, поверх ковра :).
Но самое смешное, что люди оказались хорошие.
Вообще, базовый словарный запас и грамматика — не совсем то же, что «уровень владения языком». Всё-таки реальное владение подразумевает понимание всяких речевых фишек: интонаций, метафор, фразеологизмов, сарказма и иронии, юмора, ситуативных реплик и т.п. И возможность использовать всё это самому.
Ещё одна важная вещь — способность вычленять на слух слова из беглой речи. Это не совсем то же самое, что понимать диалоги в зарубежном кино или смотреть ролики на ютубе, где всё более-менее внятно проговаривается. На родном языке мы понимаем даже что-то походя сказанное в трубку на фоне уличного шума. Аналогично с произношением интонаций и звуков. Одно и то же слово можно очень по-разному произнести. Мы ведь в русском на слух легко различаем манеру речи условного «гопника» и условного «интеллигента», даже если они проговаривают одинаковую фразу.
К слову, один знакомый Сергей рассказывал, как сдуру представился партнёрам Сержем (Serge) и потом вздрагивал в конфе каждый раз, когда кто-то упоминал поисковые системы (search). :) То есть оба слова вроде как прекрасно знакомы, но…
Лично меня часто ставят в тупик реплики с идиомами или отсылками к зарубежным книгам/фильмам/поговоркам и т.п. Если их не знаешь, некоторые фразы выглядят ну прям очень странно :) Типа, когда тебе внезапно желают сломать ногу «Break a leg!», имея в виду «Удачи!».
А самое смешное, что чем лучше владеешь родным языком, тем сложнее нормально общаться на другом. Потому что если привык думать точными формулировками и использовать образную речь, то при переходе на иностранный каждую фразу приходится сначала искусственно упрощать до уровня «моя-твоя-понимать». Очень неприятное ощущение, на грани беспомощности — как будто кусок личности ампутировали) Флирт, юмор, эрудиция — до свидания) Если привык ощущать себя хорошим собеседником, то довольно тяжко внезапно оказаться этаким говорящим поленом, которое в любой момент может ляпнуть что-то в духе «я есть Грут».
Так что вокабуляр и грамматика — это прекрасно, но и питать иллюзии на этот счет не стоит) Полноценное владение языком для иностранца практически недостижимо, если сопоставлять с его же уровнем владения родным. Всегда будет существенно ниже, всегда secondary. Понятно, что русскоязычный профессор-гуманитарий наверняка сможет посостязаться в грамматике с англоговорящим гопарем, но вот при общении с нативом-профессором разница все равно останется заметной.
Тут нюанс есть: более-менее доброжелательные к вам нативы в любом случае ответят, что вы говорите, как минимум, хорошо. Независимо от того, как обстоят дела. Прямой ответ типа "всё плохо" считается невежливым и токсичным. Людей принято хвалить с сильным перекосом в позитив. Грубо говоря, их perfect и excellent — это примерно в диапазоне от "нормально" до "хорошо" (читайте, "нас устраивает"). "Отлично" выражают обычно дифирамбами, типа fantastic, amazing и т.п. Good — это примерно уровень "так себе". Ну а всякие там nice try и it's ok — это типовая реакция на провальные проекты, ошибки и т.п. В этом смысле спрашивать бесполезно, вам никогда не скажут прямо. Не принято. Культурные различия)
Это позволит снизить порог входа, но не позволит сделать интерфейс удобнее, чем у конкурентов.
Тут нет противоречия, если смотреть в корень. За любой удачной «новой» фишкой стоит заимствование из смежных отраслей или глобальных человеческих привычек. Это тоже использование поведенческих паттернов)
По моим личным ощущениям, львиная доля косяков и проблем UX возникает именно там, где дизайнеры пытаются внедрять необкатанные теоретические удобства, не имеющие в основе устоявшихся паттернов. Фишки основанные на «здравом смысле», голой логике и т.п. постоянно вступают в противоречие с реалиями эксплуатации.
Образно говоря, дизайнер-новатор старательно проектирует в столе «удобные» пазы под планшеты и чашки, а потом выясняется, что они мешают людям заниматься сексом) Все способы использования интерфейса вряд ли возможно предсказать на этапе проектирования. Невозможно теоретически вычислить идеальное расположение кнопки, потому что на практике люди могут держать телефон в двух руках, или в одной, или в зубах, или нажимать на нее ухом случайно, или коннектиться с утюга...) Все это вылезает только на практике и на больших выборках. Поэтому с точки зрения бизнеса выгодно использовать решения, которые опираются на обкатанные паттерны. В этом смысле всё сказанное выше верно.
Это никак не ограничивает попытки сделать интерфейс удобнее, чем у конкурентов. Выбор тех или иных паттернов и определяет UX. Кто точнее попадет в привычки своих [потенциальных] пользователей, у того и получается удобнее. Собственно, это и есть суть UX в чистом виде. Мостить дорожки там, где люди уже ходят.
Хм. Работает, проверил специально только что:
(Слои внутри компонента Item, вложенного в компонент Items).
Не работать может, например, если тестировать на мастер-компоненте. Мастер-компонент по умолчанию исключается из синхронизации, данные вставляются только в копии. (Можно изменить, добавив «+» перед названием).
Еще там бывают заморочки с именованием родительских объектов и листов таблицы. Недавно схему чуток изменили, похоже. Теперь имя листа в родительских контейнерах указывается через двойной слеш, а не решётку: «Container \\my-sheet-name».
Горячо рекомендую документацию вот эту, а не ту, которая в описании плагина. Сам не сразу ее обнаружил — много времени зря потратил)
P.S. Ivan_Fil, спасибо за пост) Немного опередили, тоже думал на эту тему написать.
Из крупных и интересных есть ещё:
Themer — сохраняет наборы стилей «Фигмы» через jsonbin. Это позволяет создавать светлые/темные темы в одном макете и переключаться между ними. Плагин сыроватый и немного замороченный, т.к. хранит данные на стороннем сервисе. Живых проектов на нём я ещё не пилил, но на своих тестовых пробовал — работает.
MapMaker — вставка карт на основе GoogleMaps или Mapbox. Использовал уже неоднократно, довольно полезный.
FontReplacer и FontFascia — для поиска из замены шрифтов в проекте. Удобно при копировании компонентов из одного проекта в другой, где отличается типографика. Плюс помогает находить слои и компоненты, в которых остался старый шрифт после каких-нибудь экспериментов и замен.
Similayer — позволяет выбирать на странице слои с одинаковыми свойствами (цвет, обводка, текстовые и т.п.). Помогает разгребать плохо структурированные макеты, где автор поленился или забыл объединить часть элементов в компоненты.
1. Меню такого объема лучше делать вертикальным: нет лимита по длине, избавляет от «Ещё...», можно интуитивно сортировать и фильтровать (расположив инпут/панель фильтров над меню). Плюс это позволит выполнить пункт 2.
2. Минимальные габариты кликабельной плашки желательно делать такими, чтобы туда влезал палец (48x48 px и более). Это очень сильно снижает количество мискликов и, след-но, отказов. На десктопе тоже! Не забывайте, что не все люди обладают точной моторикой и зрением, а с возрастом всё это проседает. Чем старше аудитория, тем критичнее размеры областей клика.
3. В идеале меню должно управляться и табуляцией. Включая перемещение по подпунктам с клавиатуры. У нас все забивают, но в зарубежных проектах это бывает базовым требованием. Там больше доля ридеров и всяких гаджетов, поэтому все помешаны на accessibility. В разметке желательно следить за семантикой (nav), в некоторых случаях внедрятьARIA-roles и т.д.
4. Нежелательно делать «выворотку» (светлый текст на темном фоне) для светлых тем. Контраст цветов фона и текста лучше держать повыше (примерно как у вас в выделенных пунктах).
5. Минимальный размер шрифта сейчас желательно делать минимум 16px для десктопа, причем брать гротески а не антиквы. Для сжатых и мелких гарнитур (Pt Sans и др) размер шрифта надо брать даже чуть больше — ~18 или выше.
6. В меню такой вложенности желательно показывать кол-во дочерних элементов и товаров, особенно если вы требуете полный клик, чтобы показать подуровень. Иначе у вас будут ситуации, когда человек делает 3-6 кликов, а в итоге оказывается в пустой или почти пустой подподкатегории, где нечего выбирать.
7. Желательно обрабатывать не только состояние hover, но и active и pressed/selected. Т.е. меню должно чем-то реагировать на нажатие и различать текущую цепочку навигации (на какой странице находимся) от простой подсветки пунктов при их просмотре (какой пункт меню под мышкой).
8. Не очень удачно делать два ряда горизонтальных меню друг под другом. См п.1.
9. Про скрытие меню по клику на оверлей (вне меню) уже написали выше. В идеале ещё по клавише Esc (и «назад» на телефонах)
10. В идеале (без прямолинейного сео) вложенность основного меню надо уменьшать до 1-2 уровней. А более глубокую рубиркацию показывать после перехода внутрь. Точкой входа в магазин почти всегда становится не главная, а внутренняя страница. Т.е. человеку, который пришел по запросу «Сантехника», выгоднее на первом же уровне (без кликов) показать Унитазы и Раковины, а не Инструмент и Краску. Верхний уровень на внутряках как раз лучше показывать по прямому запросу, то есть по клику на общую кнопку типа «Все рубрики», «Полный каталог» и т.п.
P.S. 36k — это не настолько много) Норма для большого тематического магазина. А ведь есть ещё гипермаркеты)
Это очень прикольно в качестве гимнастики ума. Но палитры на выходе сами всё демонстрируют) Потому что в цветовосприятии важна не столько физика, сколько физиология.
1. Восприятие цвета в спектре (в отличие от звука) дискретно или, точнее, неравномерно на разных участках в силу того, что число светочувствительных клеток-колб отличается. Поэтому, например, гармоничные сочетания из трех оттенков зелёной части спектра составить проще, чем миз жёлтой. А удачные сочетания чистых цветов не всегда остаются удачными при равномерном изменении их яркости или насыщенности. Плюс есть ещё культурные/эволюционные особенности, которые позволяют жителям джунглей различать больше оттенков зелёного, а жителям побережья — синего и т.д. Это мелочи но этот факт сам по себе ломает аналогию с музыкальными интервалами и четко показывает, что понятие гармонии опирается не на объективные метрические параметры, а на их восприятие и интерпретацию.
2. На сайте результирующие цвета сплошь тёмные, даже для светлых образцов (в терминах HSB — brightness не бывает высокой, болтается внизу). Получается, что в этой системе не существует светлых чистых гамм.
3. Аналогично с насыщенностью: saturation всегда выше среднего, даже если образец откровенно десатурированный, пастельный. Такая гамма разваливается, насыщенные цвета забивают пастельный. Примерно как при плохом сведении звука одни инструменты забивают другие.
4. При средней brightness образца получаем проблемы с контрастом между вторым и третьим цветом: тона почти сливаются. Для глаза в плане гармонии это худший вариант, потому что затрудняется идентификация границ объектов. Примерно как сросшиеся сиамские близнецы: явно не один цельный человек, но и явно не два самодостаточных.
Словом, все это интересно, но немножко конь в вакууме. Пока что довольно далеко от прикладного дизайна.
Я не эксперт по Инсте, но в своё время был кое-какой опыт работы с продвижением разных штук в разных рынках. Заметки на полях:
1. Строить гипотезы на малых выборках — вредно
Когда вы оперируете единичными продажами, любое наблюдение будет в пределах случайности или погрешности. Ну то есть, если у вас 2 продажи и одну из них сделал, допустим, хромой пенсионер-кошатник — это вовсе не значит, что хромые пенсионеры-кошатники составляют 50% вашей ЦА :) Кроме того, перелить ~50 подписчиков из аккаунта с 400 — это само собой должно получаться, без всякого маркетинга и сложных теорий, поэтому никаких глобальных выводов из этого делать не нужно.
2. Мудрить — не значит продавать. Инструменты большого маркетинга не предназначены для микробизнеса
Портреты покупателей выделять нет смысла (см. п.1). У вас по определению будут довольно разношерстные клиенты. Нет смысла группировать их и сегментировать ЦА. Тут либо каждый клиент образует отдельную группу, либо получатся слишком общие признаки. Заметьте, под ваши два портрета (женщины + мужики творческих профессий) попадает практически вся инста :) Такое сегментирование не даёт никакого профита, потому что у всех этих людей разные вкусы, разный образ жизни, разные интересы. Эта сегментация не влияет на тактику продаж.
Вообще, если вам кто-то в контексте Инсты и SMM (на курсах и т.п.) начинает затирать что-то из «взрослого» маркетинга (ёмкость и объем рынка, потенциальный спрос и т.п.), гоните в шею. Для всех этих понятий существуют точные определения и формулы расчёта, математический аппарат. В смм они сродни карго-культу)
3. Мышление с позиции ценника даст больше толку
Не забывайте, что цена должна примерно соответствовать уровню доходов покупателя и, в данном случае, стоимости того окружения, для которого картину покупают. Поэтому ценник влияет на модель продаж больше, чем что бы то ни было.
Если у вас продукт со «средней» ценой под «средние» доходы — это не только хорошо (потенциальных покупателей много), но и плохо (максимум конкурентов, расходы на рекламу распыляются, низкая конверсия).
Подход «от ценника» гораздо конструктивнее. Возникает понимание, что товар — это (условно) не «картина», а «хендмейдовый подарок за 100 баксов». Как только вы начинаете думать в этих категориях, представление об аудитории, конкуренции и самом продукте меняется. Вы быстро перестанете ориентироваться на всякую стереотипную ерунду, типа «мужчин творческих профессий»* и начнёте искать тех, кто реально готов дарить кому-то хендмейд за стольник. Угол зрения совершенно иной. Иногда в результате и сам ценник тоже двигается, причем не обязательно вниз.
* Знакомые мне UI/UX дизайнеры через одного технари, практичные, семейные, себе дарят скорее гаджеты, да и жёнам-любовницам тоже. Ваще на ваша ЦА. Совершенно.
4. Нельзя игнорировать личный фактор
Когда строите маркетинговые теории, не забывайте, что соцсети (в отличие от поточных производств) едут на личном общении. Это значит, что решающим фактором продажи может быть тупо знакомство с автором) И следовательно, если ваш знакомый дизайнер купил у вас картину, это отнюдь не значит что дизайнеры ваша ЦА — возможно, ему просто нравятся ваши сиськи, например) Ну или прекрасный внутренний мир. (Хотя, зная мужской стиль мышления, я бы всё-таки поставил на сиськи :) Я к тому, что нельзя экстраполировать опыт личных продаж на работу с холодной аудиторией. Это две разные вещи. Учитывайте статистику именно по тому каналу, который используете. Опыт с других каналов/площадок может существенно отличаться.
5. Не надо ориентироваться на клиентов других художников
Если человеку нравится творчество Вани Иванова — это вообще никак не значит, что он заинтересуется творчеством Пети Петрова.
Я не знаю, почему все сммщики так любят таргетиться на конкурентов — это прямо паталогия какая-то. Такой подход отбивается по продажам ровно в одном случае: когда ты толкаешь абсолютно идентичный продукт, но ниже по цене. (И еще в массированных РК, когда бюджет конский и задача мельтешить по максимуму, но это другая история).
Покупки таких картин либо спонтанные, либо завязаны на персоналию или авторский стиль (см. выше). Поэтому потенциал подписоты Вани для Пети такой же или ниже, чем у любой другой случайной выборки. Вопреки стереотипам, выгоднее и дешевле обрабатывать свежую аудиторию, чем уже окученную кем-то.
Типичный автор типичных SMM курсов обычно думает с точностью до наоборот. Возможно, поэтому он и занимается подобной ерундой)
P.S. Хорошая самопроверка: допустим, в расчете на «ЦА № 2» вы опубликовали пост в нескольких нерелевантных хабах и собрали 3k просмотров. Если ваши гипотезы верны, то на такой выборке за ближайшие сутки чисто статистически должно получиться где-то с полсотни новых подписчиков и, минимум, 1-2 продажи (именно с хабра). Если этого нет, значит гипотезы не работают и надо что-то переосмысливать.
В принципе, что пнём о сову, что совой об пень :) Большая часть вопросов, упомянутых тут, не очень зависит от инструментария фронтендера и остается актуальной хоть с «Зеплином» хоть без него. Всё равно ведь компоненты надо как-то именовать, стандарты отступов и сеток согласовывать и т.д. «Зеплин» с «Фигмой» неплохо интегрированы. Глобальные стили из Ф уже импортируются, импорт компонентов тоже на подходе, вроде как. Но «Зеплин» не отменяет необходимость договариваться об именовании и приводить базу компонентов в какой-то единообразный вид.
Плюс, по чисто личному ощущению, темп развития «Фигмы» выше, и есть ненулевая вероятность, что она со временем перекроет функционал Зеплина собственным, развив свой read-only режим в полноценный интерфейс для разработчиков.
Не :) В стандартном синтаксисе всё наоборот: двойное нижнее подчеркивание отделяет элемент, а одинарное — модификатор.
Есть ещё несколько популярных альтернативных схем (они тоже есть там по ссылке, к концу ближе). У каждой есть плюсы, в зависмости от того, какие языки или фреймворки применяются в проектах чаще. Но ваша схема уникальна :) Нигде не встречал.
В принципе, если ваши коллеги не возражают, то можно и так, наверное. Но при смене коллектива та же путаница будет постоянно возникать. Возможно, есть смысл вернуться к классике :)
А вот это вопрос интересный и годный. Чисто теоретически, на уровне архитектуры, я согласен, что в идеале не-компонентных частей в компонентном дизайне быть не должно. И наверное, если речь идёт о каком-то отдельно взятом проекте, то этого можно добиться. Здесь дизайн-система по сути просто обеспечивает консистентность интерфейса, который сравнительно легко можно унифицировать.
Но если мы всё-таки говорим о какой-то универсальной дизайн-системе, цель которой организовать рабочий процесс между дизайнером, верстаком и т.д. в общем потоке разных проектов, то тут речь будет скорее о рамочном соглашении , а не жестком стандарте не все случаи жизни. Иначе система начнет мешать в работе, потому что сами задачи могут быть разнородными.
Грубо говоря, например. Делаем на потоке промо-сайты, у каждого первый экран главной страницы представляет собой обложку с ярким коллажем с анимированными элементами. Логически такая обложка — компонент. Она есть на каждом сайте, имеет стандартное место в лейауте, стандартный размер, поведение брейкпоинтов и т.п. Но поскольку начинка обложки всегда разная (и в этом, собственно, её функция) унифицировать её толком мы не можем, да и выносить в библиотеку нет практического смысла, т.к. переиспользуется только голый фрейм.
Или другого плана пример. Рисуем контентную страницу, типа лонгрида. Логически в тексте много разных переиспользуемых компонентов: абзацы, врезки, цитаты, списки, мелкий текст и т.п. Но если делать их именно компонентами (отдельными блоками-экземплярами), то при любом изменении объема текста вся колбаса поедет и нужно будет руками переставлять все блоки. Если же считать компонентом родительский фрейм (весь контейнер с текстом статьи), то его не получится переиспользовать, потому что структура врезок, цитат и т.п. не совпадёт. Переиспользуемым в данном случае является оформление элементов, а не сам текст. Поэтому в «Фигме» такие вещи выносятся в стили, а не компоненты. И соответственно, на уровне «Фигмы» такие текстовые слои лучше оставлять как есть, вне компонентов. Предполагая, что на уровне верстке они имеют произвольную разметку, которая может содержать в себе компоненты, примеси и т.д.
Словом, дизайн-система и её техническая реализация дадут некоторую разбежку по-любому. Поэтому я сторонник того, чтобы стандарт вычленялся из кейсов. То есть стандартизировалось только то, что на практике повторяется и переиспользуется.
Люди не уловили юмор, видимо)
К слову, если брать именно UI, то при жестком выборе из набора «дизайнер, верстальщик, „Фигма“» я бы оставил все-таки верстальщика :)
Система вводится не ради «пиксель пёрфекта» (визуального), а ради стандартизации рабочего процесса. Со всеми её плюсами и минусами.
Представьте себе open source проект, в который могут коммитить совершенно посторонние люди. Там максимальный профит от стандартизации, потому что без неё каждый лепит по-своему. Кому-то нравится паддинг 5 пикселей, кому-то 3; кто-то считает с учетом border-box, кто-то нет и т.п. Никаких ресурсов не хватит делать ревью визуально для каждого такого коммита. А при наличии системы можно и людей обучить, и ревью частично автоматизировать.
В студии профит не так очевиден, но принцип тот же.
Думаю, четвёрку выбрали потому, что из всех клавиш-цифр она ближе всего к указательному пальцу при зажатых «Ctrl+Shift». Фотошоповский «Ctrl+;» плох тем, что правую руку нужно отрывать от мыши. Субъективно, подход «Фигмы» всё-таки удобнее после адаптации, хотя в первые недели я тоже вешался)
Про «дачную скатерть» сказано метко, но особой проблемы нет. Во-первых, сетка многослойная. Лишнюю разлиновку можно держать по умолчанию скрытой, если мешает. Во-вторых, «магнитная» привязка работает даже если сетка едва видимая или прозрачная. На скринах она ярче раз в 5, чем нужно — для иллюстрации.
Вы хорошо реагируете. По 2 и 3 давайте так сделаем: я черкну себе в туду и по возможности в течение 3-4 недель попробую оформить комментом или постом. Нужны иллюстрации, т.к. всё пляшет от сеток. Не гарантирую, но постараюсь.
Вы теоретически рассуждаете или пробовали сравнивать оба подхода (Фигма/Adoby) на объемных проектах? В моем случае эти аргументы отпали уже после 3-4 проектов в Фигме.
Делать компоненты смарт-объектами/файлами по сравнению с Ф крайне неудобно: можно утонуть в состояниях и модификаторах. Банально, у вас есть компонент header, в нём зашит компонент nav-menu со ссылками. И есть макеты страниц (много), где в шапке выделены соответствующие родительские пункты меню (разные). Попробуйте собрать всё это на смарт-объектах так, чтобы получить полноценный экспорт в результирующих файлах. Я имею в виду, свободно менять типографику элементов меню из любого места, переключать в 1 клик состояния :hover и :active и т.п. для отдельно взятого пункта в отдельном макете. В таком духе:
В Фигме, к слову, вы можете всё это ещё и показать интерактивно: потестить «живьём» нажатие кнопок, показать всплывание окон и оверлеев, поведение фиксированных элементов при скроллинге и др. — без необходимости экспортировать статику и собирать из неё потом что-то сторонними примочками).
При атомарном подходе в PS у вас на нормальном проекте постоянно будут получаться смарт-объекты с 5-10 уровнями вложенности. Управлять ими адски геморройно. В сравнении:
Опять же, с респонсивностью холста что? Ничего. Портировать какой-нибудь баннер под 20 размеров (привет, Яндекс.Директ и т.п.) придётся чуть ли не руками. А в Фигме вы делаете 1 компонент, потом тянете его как угодно — содержимое само «едет» куда нужно или выравнивается. Причем правки вносятся во все артборды сразу и экспорт всей пачки jpeg происходит в 1 клик. Вот вам такой «смарт-объект» (накинул в один компонент от балды случайных элементов из либы для демонстрации выравнивания):
А теперь вносим туда 3 правки, примерно за 5 секунд:
Сколько возни было бы со смартами, чтобы раскидать 3 правки на на 4 разноформатных артборда (не пропорционально, а респонсивно)?
И это всё очень лишь мелкие частности. Их таких миллион.
В общем, собирать все эти вещи из смарт-объектов кажется удобным только до тех пор, пока не поработаешь плотно с компонентами. Я ещё не встречал людей, которые освоив Фигму (до стадии преодоления начальных привычек), вернулись бы потом на смарт-объекты. Это просто бессмысленно.
Да, при освоении первую неделю тяжко, хочется ругаться матом (то горячие клавиши не совпадают, то выделение слоев непривычное, то что-то ведёт себя «нелогично» и т.п.). Но это обычная история при миграции на новый софт после многолетней привычки.
Повторюсь, обратно в ФШ/Люстру возвращаться не тянет ни на йоту. Хотя я тоже консерватор и тоже относительно долго от неё отбрыкивался :) Почти год присматривался, ковырял по вершкам. Но по факту Фигма действительно экономит уйму времени и энергии. Навскидку, процентов на 20 производительнее стал.
Figma не является аналогом PS/AI, это продукты совершенно разного назначения. PS не умеет ничего из того, ради чего создавалась Фигма.
1. Там нет компонентной системы и нормальной возможности повторно использовать компоненты между макетами (статичные Смарт-объекты это совсем не то).
2. Там нет возможности наследовать стили от родительских проектов.
3. Там нет совместного доступа.
4. Там нет режима прототипирования.
…
Там нет ничего для работы с проектами на 50-100 артбордов. И не должно быть, потому что PS — это редактор растровых изображений, а не сервис для разработки и прототипирования интерфейсов. Когда вы просите дизайнера сделать интерфейс в PS, это всё равно что попросить его рисовать макеты от руки в тетрадке или, скажем, вырезать из цветной бумаги: технически возможно, но бестолково, бессмысленно и абсолютно не технологично.
В Фигме сейчас с плагинами можно создавать даже пакеты стилей (темы). То есть в 1 клик переключать темы по всему проекту (тёмная/светлая и др.) А в PS чтобы поменять цвет 1 базовой кнопки для 100 артбордов, нужно открыть все 100 макетов и руками перекрасить каждый экземпляр, да ещё потом экспортнуть всё заново. (Да, можно частично автоматизирвоать это экшнами/скриптами, но по сравнению с Фигмой это костыли).
Я пользовался PS как основным граф. редактором лет 10, да и до сих пор пользуюсь для работы с растром. Могу даже изредка какой-нибудь сайтец набросать, если там много растровой графики (промо и т.п.). Но рисовать в PS интерфейсы после выхода Фигмы — не дай боже. Зачем?
Возможно, вы не сталкиваетесь в своей работе с этими проблемами PS и, соответственно, просто недооцениваете сильные стороны Фигмы. Но тогда и глобальных выводов делать не стоит.
Я не идеализирую Фигму, в ней полно всяких заморочек (как и в любом другом редакторе). Но по темпу развития и специализации уже сейчас видно, что она становится стандартом индустрии. Люди слезают даже со Скетча, что уж про PS говорить. Adoby свой XD бесплатно раздавала и всё равно толком не забрала свою прежнюю дольку. Если кто-то и будет конкурировать с Фигмой в ближайшем будущем в области интерфейсов, то аналоги из того же поколения «CSS-based» редакторов. Типа Webflow или каких-нибудь гибридных решений с участием avocode, invisionapp и т.п. Но даже у них на данном этапе перспективы похуже, на мой взгляд. Фигма быстро движется и явно монополизирует нишу.
Баттхёрт) С крепостничеством не связывал бы, там другие процессы. Но по сути — ес, справедливо, проблема имеет место быть.
Медленно еду по этой колее прямо сейчас, мысли примерно те же. Как в той песне, «when the party is over, you got no way to go». По счастью, худо-бедно хватает ума осознавать и не питать иллюзий.
Просадка ЗП до рынка — полбеды. Есть ещё потеря автономии и прочих негласных привилегий. Их рынок с порога не даст в любом случае, поэтому их жальчее. Вот и едут до финала даже очень неглупые люди.
(2013, офис клиента, объявление в приёмной. И рядом станина под штангу, поверх ковра :).
Но самое смешное, что люди оказались хорошие.
Ещё одна важная вещь — способность вычленять на слух слова из беглой речи. Это не совсем то же самое, что понимать диалоги в зарубежном кино или смотреть ролики на ютубе, где всё более-менее внятно проговаривается. На родном языке мы понимаем даже что-то походя сказанное в трубку на фоне уличного шума. Аналогично с произношением интонаций и звуков. Одно и то же слово можно очень по-разному произнести. Мы ведь в русском на слух легко различаем манеру речи условного «гопника» и условного «интеллигента», даже если они проговаривают одинаковую фразу.
К слову, один знакомый Сергей рассказывал, как сдуру представился партнёрам Сержем (Serge) и потом вздрагивал в конфе каждый раз, когда кто-то упоминал поисковые системы (search). :) То есть оба слова вроде как прекрасно знакомы, но…
Лично меня часто ставят в тупик реплики с идиомами или отсылками к зарубежным книгам/фильмам/поговоркам и т.п. Если их не знаешь, некоторые фразы выглядят ну прям очень странно :) Типа, когда тебе внезапно желают сломать ногу «Break a leg!», имея в виду «Удачи!».
А самое смешное, что чем лучше владеешь родным языком, тем сложнее нормально общаться на другом. Потому что если привык думать точными формулировками и использовать образную речь, то при переходе на иностранный каждую фразу приходится сначала искусственно упрощать до уровня «моя-твоя-понимать». Очень неприятное ощущение, на грани беспомощности — как будто кусок личности ампутировали) Флирт, юмор, эрудиция — до свидания) Если привык ощущать себя хорошим собеседником, то довольно тяжко внезапно оказаться этаким говорящим поленом, которое в любой момент может ляпнуть что-то в духе «я есть Грут».
Так что вокабуляр и грамматика — это прекрасно, но и питать иллюзии на этот счет не стоит) Полноценное владение языком для иностранца практически недостижимо, если сопоставлять с его же уровнем владения родным. Всегда будет существенно ниже, всегда secondary. Понятно, что русскоязычный профессор-гуманитарий наверняка сможет посостязаться в грамматике с англоговорящим гопарем, но вот при общении с нативом-профессором разница все равно останется заметной.
Тут нюанс есть: более-менее доброжелательные к вам нативы в любом случае ответят, что вы говорите, как минимум, хорошо. Независимо от того, как обстоят дела. Прямой ответ типа "всё плохо" считается невежливым и токсичным. Людей принято хвалить с сильным перекосом в позитив. Грубо говоря, их perfect и excellent — это примерно в диапазоне от "нормально" до "хорошо" (читайте, "нас устраивает"). "Отлично" выражают обычно дифирамбами, типа fantastic, amazing и т.п. Good — это примерно уровень "так себе". Ну а всякие там nice try и it's ok — это типовая реакция на провальные проекты, ошибки и т.п. В этом смысле спрашивать бесполезно, вам никогда не скажут прямо. Не принято. Культурные различия)
Тут нет противоречия, если смотреть в корень. За любой удачной «новой» фишкой стоит заимствование из смежных отраслей или глобальных человеческих привычек. Это тоже использование поведенческих паттернов)
По моим личным ощущениям, львиная доля косяков и проблем UX возникает именно там, где дизайнеры пытаются внедрять необкатанные теоретические удобства, не имеющие в основе устоявшихся паттернов. Фишки основанные на «здравом смысле», голой логике и т.п. постоянно вступают в противоречие с реалиями эксплуатации.
Образно говоря, дизайнер-новатор старательно проектирует в столе «удобные» пазы под планшеты и чашки, а потом выясняется, что они мешают людям заниматься сексом) Все способы использования интерфейса вряд ли возможно предсказать на этапе проектирования. Невозможно теоретически вычислить идеальное расположение кнопки, потому что на практике люди могут держать телефон в двух руках, или в одной, или в зубах, или нажимать на нее ухом случайно, или коннектиться с утюга...) Все это вылезает только на практике и на больших выборках. Поэтому с точки зрения бизнеса выгодно использовать решения, которые опираются на обкатанные паттерны. В этом смысле всё сказанное выше верно.
Это никак не ограничивает попытки сделать интерфейс удобнее, чем у конкурентов. Выбор тех или иных паттернов и определяет UX. Кто точнее попадет в привычки своих [потенциальных] пользователей, у того и получается удобнее. Собственно, это и есть суть UX в чистом виде. Мостить дорожки там, где люди уже ходят.
(Слои внутри компонента Item, вложенного в компонент Items).
Не работать может, например, если тестировать на мастер-компоненте. Мастер-компонент по умолчанию исключается из синхронизации, данные вставляются только в копии. (Можно изменить, добавив «+» перед названием).
Еще там бывают заморочки с именованием родительских объектов и листов таблицы. Недавно схему чуток изменили, похоже. Теперь имя листа в родительских контейнерах указывается через двойной слеш, а не решётку: «Container \\my-sheet-name».
Горячо рекомендую документацию вот эту, а не ту, которая в описании плагина. Сам не сразу ее обнаружил — много времени зря потратил)
P.S. Ivan_Fil, спасибо за пост) Немного опередили, тоже думал на эту тему написать.
Из крупных и интересных есть ещё:
Успехов!
2. Минимальные габариты кликабельной плашки желательно делать такими, чтобы туда влезал палец (48x48 px и более). Это очень сильно снижает количество мискликов и, след-но, отказов. На десктопе тоже! Не забывайте, что не все люди обладают точной моторикой и зрением, а с возрастом всё это проседает. Чем старше аудитория, тем критичнее размеры областей клика.
3. В идеале меню должно управляться и табуляцией. Включая перемещение по подпунктам с клавиатуры. У нас все забивают, но в зарубежных проектах это бывает базовым требованием. Там больше доля ридеров и всяких гаджетов, поэтому все помешаны на accessibility. В разметке желательно следить за семантикой (nav), в некоторых случаях внедрятьARIA-roles и т.д.
4. Нежелательно делать «выворотку» (светлый текст на темном фоне) для светлых тем. Контраст цветов фона и текста лучше держать повыше (примерно как у вас в выделенных пунктах).
5. Минимальный размер шрифта сейчас желательно делать минимум 16px для десктопа, причем брать гротески а не антиквы. Для сжатых и мелких гарнитур (Pt Sans и др) размер шрифта надо брать даже чуть больше — ~18 или выше.
6. В меню такой вложенности желательно показывать кол-во дочерних элементов и товаров, особенно если вы требуете полный клик, чтобы показать подуровень. Иначе у вас будут ситуации, когда человек делает 3-6 кликов, а в итоге оказывается в пустой или почти пустой подподкатегории, где нечего выбирать.
7. Желательно обрабатывать не только состояние hover, но и active и pressed/selected. Т.е. меню должно чем-то реагировать на нажатие и различать текущую цепочку навигации (на какой странице находимся) от простой подсветки пунктов при их просмотре (какой пункт меню под мышкой).
8. Не очень удачно делать два ряда горизонтальных меню друг под другом. См п.1.
9. Про скрытие меню по клику на оверлей (вне меню) уже написали выше. В идеале ещё по клавише Esc (и «назад» на телефонах)
10. В идеале (без прямолинейного сео) вложенность основного меню надо уменьшать до 1-2 уровней. А более глубокую рубиркацию показывать после перехода внутрь. Точкой входа в магазин почти всегда становится не главная, а внутренняя страница. Т.е. человеку, который пришел по запросу «Сантехника», выгоднее на первом же уровне (без кликов) показать Унитазы и Раковины, а не Инструмент и Краску. Верхний уровень на внутряках как раз лучше показывать по прямому запросу, то есть по клику на общую кнопку типа «Все рубрики», «Полный каталог» и т.п.
P.S. 36k — это не настолько много) Норма для большого тематического магазина. А ведь есть ещё гипермаркеты)
Успехов!
1. Восприятие цвета в спектре (в отличие от звука) дискретно или, точнее, неравномерно на разных участках в силу того, что число светочувствительных клеток-колб отличается. Поэтому, например, гармоничные сочетания из трех оттенков зелёной части спектра составить проще, чем миз жёлтой. А удачные сочетания чистых цветов не всегда остаются удачными при равномерном изменении их яркости или насыщенности. Плюс есть ещё культурные/эволюционные особенности, которые позволяют жителям джунглей различать больше оттенков зелёного, а жителям побережья — синего и т.д. Это мелочи но этот факт сам по себе ломает аналогию с музыкальными интервалами и четко показывает, что понятие гармонии опирается не на объективные метрические параметры, а на их восприятие и интерпретацию.
2. На сайте результирующие цвета сплошь тёмные, даже для светлых образцов (в терминах HSB — brightness не бывает высокой, болтается внизу). Получается, что в этой системе не существует светлых чистых гамм.
3. Аналогично с насыщенностью: saturation всегда выше среднего, даже если образец откровенно десатурированный, пастельный. Такая гамма разваливается, насыщенные цвета забивают пастельный. Примерно как при плохом сведении звука одни инструменты забивают другие.
4. При средней brightness образца получаем проблемы с контрастом между вторым и третьим цветом: тона почти сливаются. Для глаза в плане гармонии это худший вариант, потому что затрудняется идентификация границ объектов. Примерно как сросшиеся сиамские близнецы: явно не один цельный человек, но и явно не два самодостаточных.
Словом, все это интересно, но немножко конь в вакууме. Пока что довольно далеко от прикладного дизайна.
1. Строить гипотезы на малых выборках — вредно
Когда вы оперируете единичными продажами, любое наблюдение будет в пределах случайности или погрешности. Ну то есть, если у вас 2 продажи и одну из них сделал, допустим, хромой пенсионер-кошатник — это вовсе не значит, что хромые пенсионеры-кошатники составляют 50% вашей ЦА :) Кроме того, перелить ~50 подписчиков из аккаунта с 400 — это само собой должно получаться, без всякого маркетинга и сложных теорий, поэтому никаких глобальных выводов из этого делать не нужно.
2. Мудрить — не значит продавать. Инструменты большого маркетинга не предназначены для микробизнеса
Портреты покупателей выделять нет смысла (см. п.1). У вас по определению будут довольно разношерстные клиенты. Нет смысла группировать их и сегментировать ЦА. Тут либо каждый клиент образует отдельную группу, либо получатся слишком общие признаки. Заметьте, под ваши два портрета (женщины + мужики творческих профессий) попадает практически вся инста :) Такое сегментирование не даёт никакого профита, потому что у всех этих людей разные вкусы, разный образ жизни, разные интересы. Эта сегментация не влияет на тактику продаж.
Вообще, если вам кто-то в контексте Инсты и SMM (на курсах и т.п.) начинает затирать что-то из «взрослого» маркетинга (ёмкость и объем рынка, потенциальный спрос и т.п.), гоните в шею. Для всех этих понятий существуют точные определения и формулы расчёта, математический аппарат. В смм они сродни карго-культу)
3. Мышление с позиции ценника даст больше толку
Не забывайте, что цена должна примерно соответствовать уровню доходов покупателя и, в данном случае, стоимости того окружения, для которого картину покупают. Поэтому ценник влияет на модель продаж больше, чем что бы то ни было.
Если у вас продукт со «средней» ценой под «средние» доходы — это не только хорошо (потенциальных покупателей много), но и плохо (максимум конкурентов, расходы на рекламу распыляются, низкая конверсия).
Подход «от ценника» гораздо конструктивнее. Возникает понимание, что товар — это (условно) не «картина», а «хендмейдовый подарок за 100 баксов». Как только вы начинаете думать в этих категориях, представление об аудитории, конкуренции и самом продукте меняется. Вы быстро перестанете ориентироваться на всякую стереотипную ерунду, типа «мужчин творческих профессий»* и начнёте искать тех, кто реально готов дарить кому-то хендмейд за стольник. Угол зрения совершенно иной. Иногда в результате и сам ценник тоже двигается, причем не обязательно вниз.
* Знакомые мне UI/UX дизайнеры через одного технари, практичные, семейные, себе дарят скорее гаджеты, да и жёнам-любовницам тоже. Ваще на ваша ЦА. Совершенно.
4. Нельзя игнорировать личный фактор
Когда строите маркетинговые теории, не забывайте, что соцсети (в отличие от поточных производств) едут на личном общении. Это значит, что решающим фактором продажи может быть тупо знакомство с автором) И следовательно, если ваш знакомый дизайнер купил у вас картину, это отнюдь не значит что дизайнеры ваша ЦА — возможно, ему просто нравятся ваши сиськи, например) Ну или прекрасный внутренний мир. (Хотя, зная мужской стиль мышления, я бы всё-таки поставил на сиськи :) Я к тому, что нельзя экстраполировать опыт личных продаж на работу с холодной аудиторией. Это две разные вещи. Учитывайте статистику именно по тому каналу, который используете. Опыт с других каналов/площадок может существенно отличаться.
5. Не надо ориентироваться на клиентов других художников
Если человеку нравится творчество Вани Иванова — это вообще никак не значит, что он заинтересуется творчеством Пети Петрова.
Я не знаю, почему все сммщики так любят таргетиться на конкурентов — это прямо паталогия какая-то. Такой подход отбивается по продажам ровно в одном случае: когда ты толкаешь абсолютно идентичный продукт, но ниже по цене. (И еще в массированных РК, когда бюджет конский и задача мельтешить по максимуму, но это другая история).
Покупки таких картин либо спонтанные, либо завязаны на персоналию или авторский стиль (см. выше). Поэтому потенциал подписоты Вани для Пети такой же или ниже, чем у любой другой случайной выборки. Вопреки стереотипам, выгоднее и дешевле обрабатывать свежую аудиторию, чем уже окученную кем-то.
Типичный автор типичных SMM курсов обычно думает с точностью до наоборот. Возможно, поэтому он и занимается подобной ерундой)
P.S. Хорошая самопроверка: допустим, в расчете на «ЦА № 2» вы опубликовали пост в нескольких нерелевантных хабах и собрали 3k просмотров. Если ваши гипотезы верны, то на такой выборке за ближайшие сутки чисто статистически должно получиться где-то с полсотни новых подписчиков и, минимум, 1-2 продажи (именно с хабра). Если этого нет, значит гипотезы не работают и надо что-то переосмысливать.
В любом случае, успехов!
Плюс, по чисто личному ощущению, темп развития «Фигмы» выше, и есть ненулевая вероятность, что она со временем перекроет функционал Зеплина собственным, развив свой read-only режим в полноценный интерфейс для разработчиков.
Есть ещё несколько популярных альтернативных схем (они тоже есть там по ссылке, к концу ближе). У каждой есть плюсы, в зависмости от того, какие языки или фреймворки применяются в проектах чаще. Но ваша схема уникальна :) Нигде не встречал.
В принципе, если ваши коллеги не возражают, то можно и так, наверное. Но при смене коллектива та же путаница будет постоянно возникать. Возможно, есть смысл вернуться к классике :)
Но если мы всё-таки говорим о какой-то универсальной дизайн-системе, цель которой организовать рабочий процесс между дизайнером, верстаком и т.д. в общем потоке разных проектов, то тут речь будет скорее о рамочном соглашении , а не жестком стандарте не все случаи жизни. Иначе система начнет мешать в работе, потому что сами задачи могут быть разнородными.
Грубо говоря, например. Делаем на потоке промо-сайты, у каждого первый экран главной страницы представляет собой обложку с ярким коллажем с анимированными элементами. Логически такая обложка — компонент. Она есть на каждом сайте, имеет стандартное место в лейауте, стандартный размер, поведение брейкпоинтов и т.п. Но поскольку начинка обложки всегда разная (и в этом, собственно, её функция) унифицировать её толком мы не можем, да и выносить в библиотеку нет практического смысла, т.к. переиспользуется только голый фрейм.
Или другого плана пример. Рисуем контентную страницу, типа лонгрида. Логически в тексте много разных переиспользуемых компонентов: абзацы, врезки, цитаты, списки, мелкий текст и т.п. Но если делать их именно компонентами (отдельными блоками-экземплярами), то при любом изменении объема текста вся колбаса поедет и нужно будет руками переставлять все блоки. Если же считать компонентом родительский фрейм (весь контейнер с текстом статьи), то его не получится переиспользовать, потому что структура врезок, цитат и т.п. не совпадёт. Переиспользуемым в данном случае является оформление элементов, а не сам текст. Поэтому в «Фигме» такие вещи выносятся в стили, а не компоненты. И соответственно, на уровне «Фигмы» такие текстовые слои лучше оставлять как есть, вне компонентов. Предполагая, что на уровне верстке они имеют произвольную разметку, которая может содержать в себе компоненты, примеси и т.д.
Словом, дизайн-система и её техническая реализация дадут некоторую разбежку по-любому. Поэтому я сторонник того, чтобы стандарт вычленялся из кейсов. То есть стандартизировалось только то, что на практике повторяется и переиспользуется.
К слову, если брать именно UI, то при жестком выборе из набора «дизайнер, верстальщик, „Фигма“» я бы оставил все-таки верстальщика :)
Классический синтаксис БЭМ:
Если где-то текст не соответствует, тыкайте меня носом, подправлю :)
Спасибо за комментарий!
Представьте себе open source проект, в который могут коммитить совершенно посторонние люди. Там максимальный профит от стандартизации, потому что без неё каждый лепит по-своему. Кому-то нравится паддинг 5 пикселей, кому-то 3; кто-то считает с учетом border-box, кто-то нет и т.п. Никаких ресурсов не хватит делать ревью визуально для каждого такого коммита. А при наличии системы можно и людей обучить, и ревью частично автоматизировать.
В студии профит не так очевиден, но принцип тот же.
Про «дачную скатерть» сказано метко, но особой проблемы нет. Во-первых, сетка многослойная. Лишнюю разлиновку можно держать по умолчанию скрытой, если мешает. Во-вторых, «магнитная» привязка работает даже если сетка едва видимая или прозрачная. На скринах она ярче раз в 5, чем нужно — для иллюстрации.
Делать компоненты смарт-объектами/файлами по сравнению с Ф крайне неудобно: можно утонуть в состояниях и модификаторах. Банально, у вас есть компонент header, в нём зашит компонент nav-menu со ссылками. И есть макеты страниц (много), где в шапке выделены соответствующие родительские пункты меню (разные). Попробуйте собрать всё это на смарт-объектах так, чтобы получить полноценный экспорт в результирующих файлах. Я имею в виду, свободно менять типографику элементов меню из любого места, переключать в 1 клик состояния :hover и :active и т.п. для отдельно взятого пункта в отдельном макете. В таком духе:
В Фигме, к слову, вы можете всё это ещё и показать интерактивно: потестить «живьём» нажатие кнопок, показать всплывание окон и оверлеев, поведение фиксированных элементов при скроллинге и др. — без необходимости экспортировать статику и собирать из неё потом что-то сторонними примочками).
При атомарном подходе в PS у вас на нормальном проекте постоянно будут получаться смарт-объекты с 5-10 уровнями вложенности. Управлять ими адски геморройно. В сравнении:
Опять же, с респонсивностью холста что? Ничего. Портировать какой-нибудь баннер под 20 размеров (привет, Яндекс.Директ и т.п.) придётся чуть ли не руками. А в Фигме вы делаете 1 компонент, потом тянете его как угодно — содержимое само «едет» куда нужно или выравнивается. Причем правки вносятся во все артборды сразу и экспорт всей пачки jpeg происходит в 1 клик. Вот вам такой «смарт-объект» (накинул в один компонент от балды случайных элементов из либы для демонстрации выравнивания):
А теперь вносим туда 3 правки, примерно за 5 секунд:
Сколько возни было бы со смартами, чтобы раскидать 3 правки на на 4 разноформатных артборда (не пропорционально, а респонсивно)?
И это всё очень лишь мелкие частности. Их таких миллион.
В общем, собирать все эти вещи из смарт-объектов кажется удобным только до тех пор, пока не поработаешь плотно с компонентами. Я ещё не встречал людей, которые освоив Фигму (до стадии преодоления начальных привычек), вернулись бы потом на смарт-объекты. Это просто бессмысленно.
Да, при освоении первую неделю тяжко, хочется ругаться матом (то горячие клавиши не совпадают, то выделение слоев непривычное, то что-то ведёт себя «нелогично» и т.п.). Но это обычная история при миграции на новый софт после многолетней привычки.
Повторюсь, обратно в ФШ/Люстру возвращаться не тянет ни на йоту. Хотя я тоже консерватор и тоже относительно долго от неё отбрыкивался :) Почти год присматривался, ковырял по вершкам. Но по факту Фигма действительно экономит уйму времени и энергии. Навскидку, процентов на 20 производительнее стал.
Figma не является аналогом PS/AI, это продукты совершенно разного назначения. PS не умеет ничего из того, ради чего создавалась Фигма.
1. Там нет компонентной системы и нормальной возможности повторно использовать компоненты между макетами (статичные Смарт-объекты это совсем не то).
2. Там нет возможности наследовать стили от родительских проектов.
3. Там нет совместного доступа.
4. Там нет режима прототипирования.
…
Там нет ничего для работы с проектами на 50-100 артбордов. И не должно быть, потому что PS — это редактор растровых изображений, а не сервис для разработки и прототипирования интерфейсов. Когда вы просите дизайнера сделать интерфейс в PS, это всё равно что попросить его рисовать макеты от руки в тетрадке или, скажем, вырезать из цветной бумаги: технически возможно, но бестолково, бессмысленно и абсолютно не технологично.
В Фигме сейчас с плагинами можно создавать даже пакеты стилей (темы). То есть в 1 клик переключать темы по всему проекту (тёмная/светлая и др.) А в PS чтобы поменять цвет 1 базовой кнопки для 100 артбордов, нужно открыть все 100 макетов и руками перекрасить каждый экземпляр, да ещё потом экспортнуть всё заново. (Да, можно частично автоматизирвоать это экшнами/скриптами, но по сравнению с Фигмой это костыли).
Я пользовался PS как основным граф. редактором лет 10, да и до сих пор пользуюсь для работы с растром. Могу даже изредка какой-нибудь сайтец набросать, если там много растровой графики (промо и т.п.). Но рисовать в PS интерфейсы после выхода Фигмы — не дай боже. Зачем?
Возможно, вы не сталкиваетесь в своей работе с этими проблемами PS и, соответственно, просто недооцениваете сильные стороны Фигмы. Но тогда и глобальных выводов делать не стоит.
Я не идеализирую Фигму, в ней полно всяких заморочек (как и в любом другом редакторе). Но по темпу развития и специализации уже сейчас видно, что она становится стандартом индустрии. Люди слезают даже со Скетча, что уж про PS говорить. Adoby свой XD бесплатно раздавала и всё равно толком не забрала свою прежнюю дольку. Если кто-то и будет конкурировать с Фигмой в ближайшем будущем в области интерфейсов, то аналоги из того же поколения «CSS-based» редакторов. Типа Webflow или каких-нибудь гибридных решений с участием avocode, invisionapp и т.п. Но даже у них на данном этапе перспективы похуже, на мой взгляд. Фигма быстро движется и явно монополизирует нишу.