Золотая эра UX-дизайнеров прошла, настал серебряный век
Прошли времена открытий, никто не вещает с умным видом про 7 объектов максимум, которые может воспринять человек, заказчики не требуют максимум 2 клика до любой страницы сайта. Элементы дизайна не называют в честь дизайнеров, новых шаблонов интерфейса почти не выходит, а каждый дизайнер научился ставить верное тире и кавычки, даже волосяным пробелом никого не уидивишь. Теперь все пожинают плоды открытий.
Почему это классно:
Никто не верит на слово. Раньше дизайнеры уповали на композицию, обмазывали всё инфостилем и выдавали: на этой странице люди поймут то-то и будут вести себя так. Это были гипотезы на основе книг и теорий, но на парктике проверять такое дорого. Теперь же проверка гипотез стала частью процесса дизайна, т.к. все поняли, что никто заранее не знает на 100% как сработает дизайн. Даже если в другом продукте он сработал отлично, в вашем он может провалиться. Настала эра доказательств.
Сформировались процессы. Все компании работают по более-менее одинаковому процессу. Уже давно не видел, чтобы кто-то доказывал рукводителю необходимость ретроспективы или восторжено объяснял про спринты.
Сформировалась профессия. Раньше дизайнеры бросались во всё: рисовать иконки, ретушировать, учили моушн, 3д, метод персонажей и программирование. Сейчас навыки идут из процессов: учат базе проектирования и красивому визуалу. Остальное подстраивается под компанию. А это значит, что теперь можно сформировать еткий учебный план и выпускать более подготовленных специалистов.
Что будет дальше:
1) Дизайнеры всё больше будут полагаться на измеримые данные, а не на теорию
2) Профессия будет дробиться на сферы. Как есть архитекторы промышленных и гражданских зданий, так и дизайнеры будут делиться больше на финтех, В2В и т.д. Эт омы наблюдаем уже сейчас
3) Вырастет порог вхождения в профессию. Теперь недостаточно будет нарисовать пару сайтов и прочитать все советы Бюро, чтобы получить работу. Уже недостаточно
4) Вырастет ценность образования. Выпускникам одной школы дизайна будут доверять куда больше, чем другой. Уже сейчас уменьшается количество курсов дизайнеров за месяц.
А что вы думаете об изменениях в UX-дизайне и его будущем?
Прошли времена открытий, никто не вещает с умным видом про 7 объектов максимум, которые может воспринять человек, заказчики не требуют максимум 2 клика до любой страницы сайта. Элементы дизайна не называют в честь дизайнеров, новых шаблонов интерфейса почти не выходит, а каждый дизайнер научился ставить верное тире и кавычки, даже волосяным пробелом никого не уидивишь. Теперь все пожинают плоды открытий.
Почему это классно:
Никто не верит на слово. Раньше дизайнеры уповали на композицию, обмазывали всё инфостилем и выдавали: на этой странице люди поймут то-то и будут вести себя так. Это были гипотезы на основе книг и теорий, но на парктике проверять такое дорого. Теперь же проверка гипотез стала частью процесса дизайна, т.к. все поняли, что никто заранее не знает на 100% как сработает дизайн. Даже если в другом продукте он сработал отлично, в вашем он может провалиться. Настала эра доказательств.
Сформировались процессы. Все компании работают по более-менее одинаковому процессу. Уже давно не видел, чтобы кто-то доказывал рукводителю необходимость ретроспективы или восторжено объяснял про спринты.
Сформировалась профессия. Раньше дизайнеры бросались во всё: рисовать иконки, ретушировать, учили моушн, 3д, метод персонажей и программирование. Сейчас навыки идут из процессов: учат базе проектирования и красивому визуалу. Остальное подстраивается под компанию. А это значит, что теперь можно сформировать еткий учебный план и выпускать более подготовленных специалистов.
Что будет дальше:
1) Дизайнеры всё больше будут полагаться на измеримые данные, а не на теорию
2) Профессия будет дробиться на сферы. Как есть архитекторы промышленных и гражданских зданий, так и дизайнеры будут делиться больше на финтех, В2В и т.д. Эт омы наблюдаем уже сейчас
3) Вырастет порог вхождения в профессию. Теперь недостаточно будет нарисовать пару сайтов и прочитать все советы Бюро, чтобы получить работу. Уже недостаточно
4) Вырастет ценность образования. Выпускникам одной школы дизайна будут доверять куда больше, чем другой. Уже сейчас уменьшается количество курсов дизайнеров за месяц.
А что вы думаете об изменениях в UX-дизайне и его будущем?
Livejournal
Строка Воронежского
Продолжаю сливать сверхсекретную и мегаэксклюзивную инфу по дизайну. Все для вас дорогие читатели :) Бывает так, что делаете вы многоколоночную верстку на сайте или еще где, типа такой: Но на деле-то, когда текст появляется, конечно, получается так: И кажется…
👍15❤3💯2
Дизайн-печь 🔥 Ваня Емелюшкин
Золотая эра UX-дизайнеров прошла, настал серебряный век Прошли времена открытий, никто не вещает с умным видом про 7 объектов максимум, которые может воспринять человек, заказчики не требуют максимум 2 клика до любой страницы сайта. Элементы дизайна не называют…
⬆️ Заходите в комменты, там дискуссия поинтереснее поста получилась
«Зебра» в таблице. Что говорят исследования
UX-дизайнер Джессика Эндерс провела 3 эксперимента и пришла к выводу, что Зебра полезна и нужна. Я прочитал её исследования и не согласен, т.к. они не объективны. Главное, что из исследований можно сделать выводы:
1. Чем больше расстояние между столбцами в таблице, тем больше вероятность ошибки
2. Людям нужно помогать выделять строку. А как это делать: линиями, подсветкой выбранной строки или всем сразу — решать вам.
В таком случае Зебра покажет себя лучше в таблице с огромными дырами между столбцами. В остальных случаях лучше обходиться без неё.
Читайте подробности в моей новой статье
https://awdee.ru/how-stripes-in-tables-affect-the-speed-of-working-with-them/
UX-дизайнер Джессика Эндерс провела 3 эксперимента и пришла к выводу, что Зебра полезна и нужна. Я прочитал её исследования и не согласен, т.к. они не объективны. Главное, что из исследований можно сделать выводы:
1. Чем больше расстояние между столбцами в таблице, тем больше вероятность ошибки
2. Людям нужно помогать выделять строку. А как это делать: линиями, подсветкой выбранной строки или всем сразу — решать вам.
В таком случае Зебра покажет себя лучше в таблице с огромными дырами между столбцами. В остальных случаях лучше обходиться без неё.
Читайте подробности в моей новой статье
https://awdee.ru/how-stripes-in-tables-affect-the-speed-of-working-with-them/
Оди. О дизайне
Как полосы в таблицах влияют на скорость работы с ними — Оди. О дизайне
Исследования о чересполосице. «Зебра» в таблицах вызывает вечные споры. Одни дизайнеры считают, что это признак дурного вкуса и полосы мешают восприятию. Другие полагают, что «зебра» помогает быстрее находить информацию. Разберёмся в вопросе с помощью исследований…
🔥9
Простой способ добавить анимации на вебе
Обожаю веб за библиотеки. Любой элемент можно найти в интернете и стащить себе. Поэтому и вдохнуть жизнь анимацией тут куда проще, чем на мобилке. Престный дизайн? Добавь анимаций. Люди не замечают важный элемент? Анимация!
Топ 3 библиотеки:
Микроанимации. Отсюда беру анимашки для ошибок в полях ввода, колокольчика уведомлений и прочей мелочи
https://webkul.github.io/micron/
Ультимативный конструктор интерфейсных анимаций. Выбираете тип, настраиваете как надо, передаёте разработчику. Красота!
https://animista.net/
Сюда заглядываю редко, т.к. анимации тут слишком активные, но если нужно собрать лендинг — подходят хорошо
https://animate.style/
Кидайте в комменты свои любимые библиотеки, соберём коллекцию.
Обожаю веб за библиотеки. Любой элемент можно найти в интернете и стащить себе. Поэтому и вдохнуть жизнь анимацией тут куда проще, чем на мобилке. Престный дизайн? Добавь анимаций. Люди не замечают важный элемент? Анимация!
Топ 3 библиотеки:
Микроанимации. Отсюда беру анимашки для ошибок в полях ввода, колокольчика уведомлений и прочей мелочи
https://webkul.github.io/micron/
Ультимативный конструктор интерфейсных анимаций. Выбираете тип, настраиваете как надо, передаёте разработчику. Красота!
https://animista.net/
Сюда заглядываю редко, т.к. анимации тут слишком активные, но если нужно собрать лендинг — подходят хорошо
https://animate.style/
Кидайте в комменты свои любимые библиотеки, соберём коллекцию.
webkul.github.io
Micron.JS - a [μ] microInteraction Library
a [μ] microInteraction library built with CSS Animations and controlled by JavaScript Power
👍12❤3🔥3
🤡 А это мы сделаем во второй версии
Не сделаем. Это ложь, чтобы вас успокоить. На улучшения почти никогда нет времени. Обычно этим приёмом пользуются менеджеры, чтобы не спорить с дизайнером и поскорее затащить фичу в продукт.
Как скорее всего будет:
1. Вы проектируете классный дизайн
2. Выпускать надо скорее, под нож идут анимации, сложные сценарии, новые компоненты
3. Фичу выпускают, она как-то закрывает потребности
4. Скорее делают следующую фичу. Улучшения и вторые итерации идут в беклог и покрываются мхом.
5. К фиче возвращаются через год-два, когда нужно решить новую проблему и скорее всего переделывают половину дизайна. Возвращаемся в 1 пункт 🤬
Конечно, есть нюансы. Если это основная фича продукта, то на неё будут брошены все силы. Если у проекта куча денег и он главный на рынке — скорее всего тоже. В остальной реальности дизайн «на бумаге» остаётся лучше, чем на проде. Сложно не нарисовать крутой дизайн, сложно его затащить.
Что можно сделать:
1. Определите действительно ли улучшения необходимы. Например, анимацию можно затащить в тест и собрать по ней обратную связь. Если появятся доказательства того, что людям она нравится, то затащить её будет проще. То же самое касается и новых компонентов. Если на тестах они показали себя лучше, то это хороший аргумент. Всегда можно провести коридорку.
2. Если фича не сработает какие улучшения останутся в новой версии? Например, если хотят обрезать интересную анимацию загрузки, которая полюбому будет в фиче независимо от версии, то какая разница когда тратить на неё средства? Аргумент слабоват, но иногда действует.
3. Обсудите с разработкой как можно дешевле и эффективнее затащить вашу идею. Часто менеджеры рубят идеи ещё до оценки. Если окажется, что улучшение стоит пару часов, а не дней, то скорее всего её протащат. Часто, эффективнее будет договориться с разработчиком напрямую.
Конечно, не всегда это работает. Иногда у проекта нет средств на интересный дизайн, но обычно это известно заранее. В любом случае, пробовать стоит.
Если у вас был подобный опыт — расскажите как вы затаскивали улучшения в проект.
Не сделаем. Это ложь, чтобы вас успокоить. На улучшения почти никогда нет времени. Обычно этим приёмом пользуются менеджеры, чтобы не спорить с дизайнером и поскорее затащить фичу в продукт.
Как скорее всего будет:
1. Вы проектируете классный дизайн
2. Выпускать надо скорее, под нож идут анимации, сложные сценарии, новые компоненты
3. Фичу выпускают, она как-то закрывает потребности
4. Скорее делают следующую фичу. Улучшения и вторые итерации идут в беклог и покрываются мхом.
5. К фиче возвращаются через год-два, когда нужно решить новую проблему и скорее всего переделывают половину дизайна. Возвращаемся в 1 пункт 🤬
Конечно, есть нюансы. Если это основная фича продукта, то на неё будут брошены все силы. Если у проекта куча денег и он главный на рынке — скорее всего тоже. В остальной реальности дизайн «на бумаге» остаётся лучше, чем на проде. Сложно не нарисовать крутой дизайн, сложно его затащить.
Что можно сделать:
1. Определите действительно ли улучшения необходимы. Например, анимацию можно затащить в тест и собрать по ней обратную связь. Если появятся доказательства того, что людям она нравится, то затащить её будет проще. То же самое касается и новых компонентов. Если на тестах они показали себя лучше, то это хороший аргумент. Всегда можно провести коридорку.
2. Если фича не сработает какие улучшения останутся в новой версии? Например, если хотят обрезать интересную анимацию загрузки, которая полюбому будет в фиче независимо от версии, то какая разница когда тратить на неё средства? Аргумент слабоват, но иногда действует.
3. Обсудите с разработкой как можно дешевле и эффективнее затащить вашу идею. Часто менеджеры рубят идеи ещё до оценки. Если окажется, что улучшение стоит пару часов, а не дней, то скорее всего её протащат. Часто, эффективнее будет договориться с разработчиком напрямую.
Конечно, не всегда это работает. Иногда у проекта нет средств на интересный дизайн, но обычно это известно заранее. В любом случае, пробовать стоит.
Если у вас был подобный опыт — расскажите как вы затаскивали улучшения в проект.
❤10👍4
Дизайн-печь 🔥 Ваня Емелюшкин
🤡 А это мы сделаем во второй версии Не сделаем. Это ложь, чтобы вас успокоить. На улучшения почти никогда нет времени. Обычно этим приёмом пользуются менеджеры, чтобы не спорить с дизайнером и поскорее затащить фичу в продукт. Как скорее всего будет: 1.…
Всё не так плохо и категорично
Понял, что этот пост звучит как плохая пропаганда: все плохие, вы хорошие, деритесь за себя. Это не так.
Я хотел подсветить крайние случаи, когда плохие менеджеры используют такой приём, чтобы быстрее релизнуться, а потом отчитаться начальству в конце года сколько всего крутого они затащили. Такие менеджеры, которые думают только о личной эффективности и карьере есть везде: в корпорациях, стартапах, студиях. Если вы замечаете, что часто слышите этот аргумент, а обещания не исполняются, то эта инструкция для вас. Если нет, то вам повезло работать в здоровой обстановке.
Моя мысль была направлена именно против таких менеджеров. Их легко распознать, ведь они дают оценку вместо разработки. Вот пример:
Нужно поднять конверсию в покупку товара интернет-магазина. Дизайнер предлагает решения и слышит:
1. Давайте покажем сколько людей купило этот товар. Социальное доказательство успокаивает и вызывает ощущение причастности. У нас нет таких данных, это бэк это сложно, давайте в беклог.
2. Давайте сделаем так, чтобы товар уменьшался и всегда оставался наверху карточкой. Товар всегда на виду, так проще будет добавить в корзину, когда принял решение. Это сложно, фронт такое не потянет, давай сейчас сделаем статично, а остальное в беклог.
3. Давайте сделаем анимацию, что товар улетает в корзину, чтобы привлечь к ней внимание и повысить конверсию перехода в крозину. Это вообще отдельная задача, хорошая идея, спасибо, давай в беклог
Часто такой аргументации менеджера достаточно, чтобы дизайнер сдался.
Понял, что этот пост звучит как плохая пропаганда: все плохие, вы хорошие, деритесь за себя. Это не так.
Я хотел подсветить крайние случаи, когда плохие менеджеры используют такой приём, чтобы быстрее релизнуться, а потом отчитаться начальству в конце года сколько всего крутого они затащили. Такие менеджеры, которые думают только о личной эффективности и карьере есть везде: в корпорациях, стартапах, студиях. Если вы замечаете, что часто слышите этот аргумент, а обещания не исполняются, то эта инструкция для вас. Если нет, то вам повезло работать в здоровой обстановке.
Моя мысль была направлена именно против таких менеджеров. Их легко распознать, ведь они дают оценку вместо разработки. Вот пример:
Нужно поднять конверсию в покупку товара интернет-магазина. Дизайнер предлагает решения и слышит:
1. Давайте покажем сколько людей купило этот товар. Социальное доказательство успокаивает и вызывает ощущение причастности. У нас нет таких данных, это бэк это сложно, давайте в беклог.
2. Давайте сделаем так, чтобы товар уменьшался и всегда оставался наверху карточкой. Товар всегда на виду, так проще будет добавить в корзину, когда принял решение. Это сложно, фронт такое не потянет, давай сейчас сделаем статично, а остальное в беклог.
3. Давайте сделаем анимацию, что товар улетает в корзину, чтобы привлечь к ней внимание и повысить конверсию перехода в крозину. Это вообще отдельная задача, хорошая идея, спасибо, давай в беклог
Часто такой аргументации менеджера достаточно, чтобы дизайнер сдался.
👍5
Дизайн-печь 🔥 Ваня Емелюшкин
Это слишком дорого в разработке Рассказал в новой статье что делать, если часто это слышишь и лучшая часть работы уходит в стол. Кратко: 1. Пусть решение оценивает разработчик, а не продакт 2. Помогите разработчику: поищите вместе фреймворку, поштурмите задачу.…
Частично я уже затрагивал эту проблему в этом посте. Второй частый аргумент таких менеджеров «это слишком дорого в разработке».
❤2
С наступающим, ребят! 🎄
Спасибо вам, что вы со мной и читаете канал) Пожалуйста, отдохните хорошенько, не берите проекты на праздники и абстрагируйтесь от работы хотя бы на пару дней — иначе так и сгореть не долго. Спасибо всем, кто присоединился. В этом году канал вырос в 2 раза! Спасибо всем комментаторам за обратную связь и жизнь на канале, спасибо за ваши реакции.
А теперь давайте решим какой первый пост будет в следующем году.
Спасибо вам, что вы со мной и читаете канал) Пожалуйста, отдохните хорошенько, не берите проекты на праздники и абстрагируйтесь от работы хотя бы на пару дней — иначе так и сгореть не долго. Спасибо всем, кто присоединился. В этом году канал вырос в 2 раза! Спасибо всем комментаторам за обратную связь и жизнь на канале, спасибо за ваши реакции.
А теперь давайте решим какой первый пост будет в следующем году.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14🎉4
Итак, пора выходить из Новогодней гибернации. С небольшим перевесом, победил вариант «как не ударить в грязь лицом, когда пришел в продуктовую команду». Начнём!
😱2
Итак, вы пришли в продуктовую команду. С чего начать, чтобы не ударить в грязь лицом: Чеклист
До этого вы просто рисовали интерфейсы, а тут продукт! Что делать? Я подготовил обширный список вопросов, которые стоит задать в первую же неделю.
👋 Познакомьтесь с ключевыми сотрудниками лично. Почему-то большинство дизайнеров пропускают этот пункт и зря. Это ваш шанс, узнать какие проблемы с дизайном сейчас есть между отделами и запомниться команде как инициативный сотрудник. Идите к лидам команды фронт-разработчиков, бекенда, продакт-менеджеров, аналитиков, биздевов, исследователей, ux-райтеров
🚀 Узнайте про продуктовый процесс у команды.
1. Как выглядит процесс поставки фичи от идеи до релиза?
2. Какой фреймворк организации задач? Скрам, Канбан, что-то иное?
3. Кто ставит задачи и следит за их исполнением? Где посмотреть?
4. Как поставить свою задачу? Какой уже есть беклог?
5. Как команда определяет, что задача завершена? Это релиз? Это достижение нужных метрик после релиза?
6. Кто принимает финальное решение о том как будет работать и выглядеть фича?
7. Как решается вопрос, когда команда не может договориться?
8. Откуда приходят требования?
9. Кто проводит исследования? Как начать своё?
10. Где прочитать результаты исследований? Что уже известно о пользователях?
11. Есть ли CJM, джобы, потртеты пользователей? Где?
12. У кого можно запросить недостающие метрики? Где вообще смотреть метрики?
13. Как построен процесс передачи дизайна разработчикам?
14. Как построена приёмка результата дизайнером?
15. Как построен процесс с редактором? Есть ли переводы? Как просить переводы и насколько заранее?
16. Где лежит документация? Что почитать в первую очередь?
17. Есть ли словарь? Редполитика?
18. Как команда решает проблемы внутри себя? Есть ли ретро? Тимбилдинги?
🎯Цели и планы
19. Какие цели у команды и продукта на год? Квартал?
20. Какие ключевые метрики у продукта? На что отвечаете лично вы? Как команда понимает, что у продукта всё хорошо, а что плохо?
21. Как ставятся цели и кто участвует в их постановке?
22. Каких целей уже достигли до вашего прихода? Какая история развития продукта?
23. Какие выводы и ошибки были сделаны? Что точно не хотим повторять, а в чём уверены?
24. Каких результатов ждут конкретно от вас и от команды дизайнеров?
🖼️ Как дизайнеры работают вместе
25. Какие принципы дизайна в продукте?
26. Какие правила? На какое разрешение готовятся экраны?
27. Кто занимается Дизайн Системой?
28. Как добавляются новые компонеты?
29. Как дизайнеры обмениваются информацией? Где хранят документацию, как часто синкаются?
30. Есть ли устоявшиеся паттерны?
31. Кто рисует иконки и иллюстрации? Как запросить, если не умеешь?
32. Кто готовит прототипы?
33. Кто готовит анимации? В каком виде они передаются?
🛠️ Разработка
Узнайте у разработчиков особенности архитектуры. Какие решения сделать будет просто, а что сложно и приносит боль? Так вы поймёте свои ограничения в дизайне
34. Как решаются вопросы, когда дизайнер и разработчик не могут договориться?
35. Какие ожидания у разработчиков от дизайнеров?
36. Какие сейчас проблемы с дизайном видит разработка?
37. Какие проблемы есть в разработке, о которых стоит знать?
38. Какие сильные стороны разработки, а какие слабые? Например, любые запросы на сервер могут стоить очень дорого. И наоборот, фронт может быть слабоват, зато с сервера можно получить любую информацию.
39. Как выглядит дизайн-система глазами разработчика?
40. Как разработка работает с анимациями, что умеет, а что нет?
💰Ресурсы
41. Какие есть возможности для обучения?
42. Есть ли деньги на инструменты? На стоковые фотографии? На плагины?
43. Как просить ресурсы? У кого? Насколько заранее?
До этого вы просто рисовали интерфейсы, а тут продукт! Что делать? Я подготовил обширный список вопросов, которые стоит задать в первую же неделю.
👋 Познакомьтесь с ключевыми сотрудниками лично. Почему-то большинство дизайнеров пропускают этот пункт и зря. Это ваш шанс, узнать какие проблемы с дизайном сейчас есть между отделами и запомниться команде как инициативный сотрудник. Идите к лидам команды фронт-разработчиков, бекенда, продакт-менеджеров, аналитиков, биздевов, исследователей, ux-райтеров
🚀 Узнайте про продуктовый процесс у команды.
1. Как выглядит процесс поставки фичи от идеи до релиза?
2. Какой фреймворк организации задач? Скрам, Канбан, что-то иное?
3. Кто ставит задачи и следит за их исполнением? Где посмотреть?
4. Как поставить свою задачу? Какой уже есть беклог?
5. Как команда определяет, что задача завершена? Это релиз? Это достижение нужных метрик после релиза?
6. Кто принимает финальное решение о том как будет работать и выглядеть фича?
7. Как решается вопрос, когда команда не может договориться?
8. Откуда приходят требования?
9. Кто проводит исследования? Как начать своё?
10. Где прочитать результаты исследований? Что уже известно о пользователях?
11. Есть ли CJM, джобы, потртеты пользователей? Где?
12. У кого можно запросить недостающие метрики? Где вообще смотреть метрики?
13. Как построен процесс передачи дизайна разработчикам?
14. Как построена приёмка результата дизайнером?
15. Как построен процесс с редактором? Есть ли переводы? Как просить переводы и насколько заранее?
16. Где лежит документация? Что почитать в первую очередь?
17. Есть ли словарь? Редполитика?
18. Как команда решает проблемы внутри себя? Есть ли ретро? Тимбилдинги?
🎯Цели и планы
19. Какие цели у команды и продукта на год? Квартал?
20. Какие ключевые метрики у продукта? На что отвечаете лично вы? Как команда понимает, что у продукта всё хорошо, а что плохо?
21. Как ставятся цели и кто участвует в их постановке?
22. Каких целей уже достигли до вашего прихода? Какая история развития продукта?
23. Какие выводы и ошибки были сделаны? Что точно не хотим повторять, а в чём уверены?
24. Каких результатов ждут конкретно от вас и от команды дизайнеров?
🖼️ Как дизайнеры работают вместе
25. Какие принципы дизайна в продукте?
26. Какие правила? На какое разрешение готовятся экраны?
27. Кто занимается Дизайн Системой?
28. Как добавляются новые компонеты?
29. Как дизайнеры обмениваются информацией? Где хранят документацию, как часто синкаются?
30. Есть ли устоявшиеся паттерны?
31. Кто рисует иконки и иллюстрации? Как запросить, если не умеешь?
32. Кто готовит прототипы?
33. Кто готовит анимации? В каком виде они передаются?
🛠️ Разработка
Узнайте у разработчиков особенности архитектуры. Какие решения сделать будет просто, а что сложно и приносит боль? Так вы поймёте свои ограничения в дизайне
34. Как решаются вопросы, когда дизайнер и разработчик не могут договориться?
35. Какие ожидания у разработчиков от дизайнеров?
36. Какие сейчас проблемы с дизайном видит разработка?
37. Какие проблемы есть в разработке, о которых стоит знать?
38. Какие сильные стороны разработки, а какие слабые? Например, любые запросы на сервер могут стоить очень дорого. И наоборот, фронт может быть слабоват, зато с сервера можно получить любую информацию.
39. Как выглядит дизайн-система глазами разработчика?
40. Как разработка работает с анимациями, что умеет, а что нет?
💰Ресурсы
41. Какие есть возможности для обучения?
42. Есть ли деньги на инструменты? На стоковые фотографии? На плагины?
43. Как просить ресурсы? У кого? Насколько заранее?
🔥39👍4❤2
Записывайте все свои наблюдения. Хорошо, если у команды уже есть карта продуктового процесса, роадмеп, база исследований и список всех проблем в процессах. На практике я ещё не встречал полного набора. Если вы составите такие документы хотя бы для себя и поделитесь с командой — это будет сильным артефактом улучшения прозрачности в процессах, а у вас не останется вопросов уже на первой неделе.
Пишите в комментах что вы обычно узнаёте по приходу в команду? Что я упустил? Что лишнее? Что стоит раскрыть подробнее?
Пишите в комментах что вы обычно узнаёте по приходу в команду? Что я упустил? Что лишнее? Что стоит раскрыть подробнее?
👍14
Так исторически сложился культ
2022 год. Твиттер снимает ограничения в 280 символов. Интернет заполоняют возгласы, что теперь Твиттер станет обычной сосетью, новой ЖЖ, Твиттер умер
2017 год. Твиттер увеличивает ограничения со 140 до 280 символов. Фанаты негодуют: это же было фишкой Твиттера! Он потеряет душу, концепцию!
...
2006 год. СМС-самый простой и надёжный способ отправить сообщение. Создатели Твиттера придумывают прорывную фишку: публикой пост в интернете с помощью СМС! И это работает! У СМС было ограничение в 160 символов, поэтому один твит ограничили в 140. 20 символов оставили для подписи.
Вот так из технического ограничения вырастает целая концепция, настолько сильная, что уже мало кто помнит оригинальную задумку.
Почитать про ограничения смс и Твитов. https://habr.com/ru/companies/veeam/articles/266733/
2022 год. Твиттер снимает ограничения в 280 символов. Интернет заполоняют возгласы, что теперь Твиттер станет обычной сосетью, новой ЖЖ, Твиттер умер
2017 год. Твиттер увеличивает ограничения со 140 до 280 символов. Фанаты негодуют: это же было фишкой Твиттера! Он потеряет душу, концепцию!
...
2006 год. СМС-самый простой и надёжный способ отправить сообщение. Создатели Твиттера придумывают прорывную фишку: публикой пост в интернете с помощью СМС! И это работает! У СМС было ограничение в 160 символов, поэтому один твит ограничили в 140. 20 символов оставили для подписи.
Вот так из технического ограничения вырастает целая концепция, настолько сильная, что уже мало кто помнит оригинальную задумку.
Почитать про ограничения смс и Твитов. https://habr.com/ru/companies/veeam/articles/266733/
Хабр
Почему SMS ограничены именно 160 символами, а сообщения в Twitter — 140 символами?
Документ из архива Твиттер, около 2000 г., рабочее название Твиттер — «Stat.us». Credit: Jack Dorsey Шел 1985 год. Фридхельм Хиллебранд напряженно работал, сидя за столом в пустой комнате своего дома...
🔥11
Пет-проект как свежий воздух
Иногда меня обуревает тоска по визуалу. Когда ты в продукте, то работаешь с одним и тем же узнаваемым стилем каждый день. Те же цвета, те же шрифты, те же ограничения. Иногда хочется похулиганить и создать что-то своё, свой стиль.
Когда чувствую, что задыхаюсь — беру пет-проекты. Недавно вышел последний из них, Fill Keys. Это приложение для гиков безопасности: хранилище паролей с несколькими уровнями шифрования и без доступа к серверу. Единственный способ украсть пароль — подобрать код для входа.
Тут я оторвался и сделал в приложение в моём стиле: тёмное, со свечением и акцентной типографикой.
Зацените в действии, пока только на Андроид
https://play.google.com/store/apps/details?id=team.fill.keys&pcampaignid=web_share
Иногда меня обуревает тоска по визуалу. Когда ты в продукте, то работаешь с одним и тем же узнаваемым стилем каждый день. Те же цвета, те же шрифты, те же ограничения. Иногда хочется похулиганить и создать что-то своё, свой стиль.
Когда чувствую, что задыхаюсь — беру пет-проекты. Недавно вышел последний из них, Fill Keys. Это приложение для гиков безопасности: хранилище паролей с несколькими уровнями шифрования и без доступа к серверу. Единственный способ украсть пароль — подобрать код для входа.
Тут я оторвался и сделал в приложение в моём стиле: тёмное, со свечением и акцентной типографикой.
Зацените в действии, пока только на Андроид
https://play.google.com/store/apps/details?id=team.fill.keys&pcampaignid=web_share
🔥16❤3👏3🤔2
Forwarded from Дизайн душнила 🌚 Саша Ефремов
Please open Telegram to view this post
VIEW IN TELEGRAM
😢8
Дизайн душнила 🌚 Саша Ефремов
И так каждый раз 😢
Когда научился составлять ТЗ, работать с правками и, наконец, готов работать над проектом мечты:
— Уменьшение бюджета
— Сокращение команды
— Пандемия
— Война
— Уменьшение бюджета
— Сокращение команды
— Пандемия
— Война
😢6😁1💯1
Предложить простое решение
Опытного дизайнера отличает умение предлагать быстрые решения, чтобы сэкономить силы разработки и быстрее проверить гипотезу:
Нужно сделать опрос почему клиент отменяет заказ. Неопытный дизайнер бросается рисовать опрос. Опытный думает как можно выкатить фичу попроще и пораньше: открывать опрос в Тайпформе или Сториз.
Дизайнер придумал крутой онбординг на основе персональных данных. Неопытный продумает кучу состояний и загрузит разработку. Опытный сначала проверит работу онбординга с фейковми данными, которые подойдут большинству. Возможно реализует его обычными картинками или через сториз;
Нужно проверить востребованость фичи. Неопытный дизайнер сразу продумает всю фичу, опытный добавит кнопку и заглушку, что фича скоро будет.
Опытного дизайнера отличает умение предлагать быстрые решения, чтобы сэкономить силы разработки и быстрее проверить гипотезу:
Нужно сделать опрос почему клиент отменяет заказ. Неопытный дизайнер бросается рисовать опрос. Опытный думает как можно выкатить фичу попроще и пораньше: открывать опрос в Тайпформе или Сториз.
Дизайнер придумал крутой онбординг на основе персональных данных. Неопытный продумает кучу состояний и загрузит разработку. Опытный сначала проверит работу онбординга с фейковми данными, которые подойдут большинству. Возможно реализует его обычными картинками или через сториз;
Нужно проверить востребованость фичи. Неопытный дизайнер сразу продумает всю фичу, опытный добавит кнопку и заглушку, что фича скоро будет.
❤15