Если дизайнер один — заказчик реально может комментариями «кнопку побольше» сделать лучше. У дизайнера-одиночки замыливается глаз, ему нужно сообщество. Когда я был единственным дизайнером на проекте, я каждую неделю старался встречаться с бывшими коллегами, показывал дизайн программистам и аналитикам.
Для меня было открытие, что взгляд со стороны даже совсем левого человека может открыть лучшее решение. Забавно, но в дальнейшем мои мысли тоже помогали разработчикам найти лучшее инженерное решение. Так они прокачивались в UX, я в логике разработки и команда становилась прочнее.
Для меня было открытие, что взгляд со стороны даже совсем левого человека может открыть лучшее решение. Забавно, но в дальнейшем мои мысли тоже помогали разработчикам найти лучшее инженерное решение. Так они прокачивались в UX, я в логике разработки и команда становилась прочнее.
Forwarded from UX-Craft
Сейчас будет небольшого философствования пост. Он про дизайн, но на самом деле не только.
Дизайнер — эксперт по дизайну. Заказчик — эксперт по целевой аудитории его бизнеса. Зачастую заказчик вламывается на зону ответственности дизайнера и начинает вмешиваться именно в дизайн, при этом не предоставляет подробную информацию про свою ЦА, т.к. это целая работа, разобраться во всем этом.
Когда, я узнал что для многих эта ситуация — норма. Как норма — идти на поводу у заказчика. Еще для меня таким открытием стало то, что заказчик пинками улучшает дизайн. То есть после его вмешательства становится лучше.
Например, он знает про то как хорошо у конкурентов. Дизайнер не изучил рынок и предлагает свое решение. А дизайнер конкурентов хорошо проработал решение и у него правда лучше. Заказчик говорит «А почему у нас так все простенько. Давайте сделаем как у вон тех. У них интересненько».
Какие выводы я сделал.
1. Нужно чтобы у работы был уровень сильно выше чем все что есть у конкурентов заказчика и того что он может нафантазировать. Для этого нужен прицел на Европу, на лучшие работы лучших студий. Нужна сильная философия того, каким должен быть дизайн. И дизайнер этой философией должен сильно фонить и постоянно вовлекать клиента в то, как же круто делать вот так. На этапе знакомства, референсов и каждого шага работы. Тогда он будет больше чем просто рабочие руки и его будут слушать.
2. Плохо, когда заказчик более энергичен и его идеи лучше. Значит дизайнер ленится. Нужно ускоряться. Мотивация «сделать шедевр» — должна быть у дизайнера. Стоит стать пассивным — тут же теряешь инициативу и тобой командуют. Мне кажется, это связано с беспокойством за то что получится фигня.
3. В целом, любые идеи заказчика (даже бредовые) вносят некий дисбаланс в картинку. И дизайнер в поисках нового баланса (ведь просто прилепить не получится) делает работу лучше или показывает наглядно, что эта идея не работает. С такого ракурса, мне нравится эта история.
Дизайнер — эксперт по дизайну. Заказчик — эксперт по целевой аудитории его бизнеса. Зачастую заказчик вламывается на зону ответственности дизайнера и начинает вмешиваться именно в дизайн, при этом не предоставляет подробную информацию про свою ЦА, т.к. это целая работа, разобраться во всем этом.
Когда, я узнал что для многих эта ситуация — норма. Как норма — идти на поводу у заказчика. Еще для меня таким открытием стало то, что заказчик пинками улучшает дизайн. То есть после его вмешательства становится лучше.
Например, он знает про то как хорошо у конкурентов. Дизайнер не изучил рынок и предлагает свое решение. А дизайнер конкурентов хорошо проработал решение и у него правда лучше. Заказчик говорит «А почему у нас так все простенько. Давайте сделаем как у вон тех. У них интересненько».
Какие выводы я сделал.
1. Нужно чтобы у работы был уровень сильно выше чем все что есть у конкурентов заказчика и того что он может нафантазировать. Для этого нужен прицел на Европу, на лучшие работы лучших студий. Нужна сильная философия того, каким должен быть дизайн. И дизайнер этой философией должен сильно фонить и постоянно вовлекать клиента в то, как же круто делать вот так. На этапе знакомства, референсов и каждого шага работы. Тогда он будет больше чем просто рабочие руки и его будут слушать.
2. Плохо, когда заказчик более энергичен и его идеи лучше. Значит дизайнер ленится. Нужно ускоряться. Мотивация «сделать шедевр» — должна быть у дизайнера. Стоит стать пассивным — тут же теряешь инициативу и тобой командуют. Мне кажется, это связано с беспокойством за то что получится фигня.
3. В целом, любые идеи заказчика (даже бредовые) вносят некий дисбаланс в картинку. И дизайнер в поисках нового баланса (ведь просто прилепить не получится) делает работу лучше или показывает наглядно, что эта идея не работает. С такого ракурса, мне нравится эта история.
У Авито рожица в кружке выбора аватарки движется в зависимости от положения телефона. Делается не сложно, а выглядит приятно. Хочется поиграться и вызывает эмоциональную связь. Жаль, что в личном кабинете не продублировали.
#ux_мелочи
#ux_мелочи
Гугл в результатах поиска предлагает отрывок видео по теме. Так он сильно экономит наше время, пропуская приветствие и рекламу. Так держать, Гугл.
#ux_мелочи
#ux_мелочи
У меня тут накопилось историй, с чего начать?
Anonymous Poll
29%
Как мобильные разработчики наши дизайны собирают
30%
Как накосячил и что из этого узнал
6%
Кусок истории дизайна
12%
О будущем дизайна
24%
Бесячие решения других дизайнеров
О том как я косячил как руководитель
Я хотел вам рассказать историю, а получилась целая пачка. Растяну на пару месяцев, чтоб интереснее было. Первая история — завтра утром. А пока затравка.
Когда мне было только месяцев 7, как дизайнеру, мне дали в подчинение совсем зелёного новичка, потом ещё одного и ещё. Так, спустя всего 1,5 года в профессии я обнаружил у себя команду в 15 человек, йо-хо-хо и бутылку рома. Я ничего не знал о том, как быть хорошим руководителем и косячил напропалую. Тогда мне помог блог Александра Ложечкина. Каждая его история откликается во мне болезненным жизненным опытом, о котором я буду рассказывать. Если у вас недавно появился подчинённый — не ждите моих рассказов о косяках, листайте блог Александра в самый низ и впитывайте мудрость.
Жаль, но заметки уже год как перестали регулярно выходить =(
https://medium.com/@allo
Ошибки начинающего руководителя
https://medium.com/@allo/о-17-типичных-ошибках-начинающих-руководителей-a00b04623e43
Ошибки опытного руководителя
https://medium.com/@allo/о-17-ошибках-опытных-руководителей-6a05cc307663
Я хотел вам рассказать историю, а получилась целая пачка. Растяну на пару месяцев, чтоб интереснее было. Первая история — завтра утром. А пока затравка.
Когда мне было только месяцев 7, как дизайнеру, мне дали в подчинение совсем зелёного новичка, потом ещё одного и ещё. Так, спустя всего 1,5 года в профессии я обнаружил у себя команду в 15 человек, йо-хо-хо и бутылку рома. Я ничего не знал о том, как быть хорошим руководителем и косячил напропалую. Тогда мне помог блог Александра Ложечкина. Каждая его история откликается во мне болезненным жизненным опытом, о котором я буду рассказывать. Если у вас недавно появился подчинённый — не ждите моих рассказов о косяках, листайте блог Александра в самый низ и впитывайте мудрость.
Жаль, но заметки уже год как перестали регулярно выходить =(
https://medium.com/@allo
Ошибки начинающего руководителя
https://medium.com/@allo/о-17-типичных-ошибках-начинающих-руководителей-a00b04623e43
Ошибки опытного руководителя
https://medium.com/@allo/о-17-ошибках-опытных-руководителей-6a05cc307663
Medium
Alexander Lozhechkin – Medium
Read writing from Alexander Lozhechkin on Medium. Александр Ложечкин (https://medium.com/@allo/%D0%BE-%D0%B7%D0%B0%D0%BC%D0%B5%D1%82%D0%BA%D0%B0%D1%85-ce3a8bdd56af)
Как я замкнул всю работу на себе и разорвался
У нас в отделе была такая иерархия:
1. Начальниник отдела
2. Руководитель направления
3. Тимлид
4. Миддл
5. Джун
Когда меня только назначили на скромную руководящую должность — миддл, я почувствовал невероятную важность и ответственность. Моя задача была — развивать совсем юных дизайнеров, джунов, и отвечать за результат, который они выдают. А результат был плох. Невероятно плох. Я понял, что мне нужно контролировать каждый шаг дизайнера, чтобы получить приемлемый результат и не сорвать дедлайны. Я расписывал им график работы с внутренними сроками, не пускал дизайн посмотреть разрабам, пока я не посмотрю и обо всех решениях просил советоваться со мной.
Краткий план моего новичка на день мог выглядеть так:
1. Ознакомиться с ТЗ
2. Собрать референсы
3. Нарисовать наброски
4. Показать референсы и наброски Ване (это я)
5. Исправить и повторять пункт 2—5 пока Ваня не скажет «норм»
6. Нарисовать первый экран, показать Ване
7. Нарисовать остальные, показать Ване
8. Показать разработчику, собрать замечания, посоветоваться с Ваней
9. Вместе с Ваней разобрать замечания и доделать работу
Я понимал, что без жесткого плана, результат будет удручающий. Пока джунов было только 3 — я справлялся, когда 8 — стало тяжко. На 10 джуне я понял, что весь день только и делаю, что контролирую и советую. Без меня работа не шла, я был очень важен, мои джуны не знали что делать, если я опаздывал на работу. Это была самая главная проблема. Я почти не рисовал, работа перестала приносить радость, я начал путаться в показаниях. Наступила бесконечная жопа контроля.
К моменту самой жопы, я был уже тимлидом.
Решение я нашел радикальное — ограничил время согласований до двух часов в день: с 12 до 13 и с 16 до 17. Я просто отключал уведомления и, если ко мне подходили с несрочным вопросом, отправлял ждать. Кроме того, я скинул контроль за джунами полностью на миддлов.
Другие тимлиды предсказывали, что мой план не сработает: проблем в день больше, чем на 2 часа. Первые пару дней так и было. Потом, моя команда поняла, что помощи от меня ждать долго и начала решать проблемы самостоятельно. Оказывается то, что я брал на себя ответственность за результат, расслабляло ребят и они скидывали мне сырое решение, в надежде, что я поправлю.
Не сразу, но постепенно я всё меньше замыкал процессы на себе. Спустя месяц, я тратил на команду 40 минут в день, вместо 4–6 часов. Тогда я понял, что главная задача руководителя наладить процесс так, чтобы стать ненужным.
По теме:
https://medium.com/@allo/о-главной-задаче-руководителя-69b8de225f1b
У нас в отделе была такая иерархия:
1. Начальниник отдела
2. Руководитель направления
3. Тимлид
4. Миддл
5. Джун
Когда меня только назначили на скромную руководящую должность — миддл, я почувствовал невероятную важность и ответственность. Моя задача была — развивать совсем юных дизайнеров, джунов, и отвечать за результат, который они выдают. А результат был плох. Невероятно плох. Я понял, что мне нужно контролировать каждый шаг дизайнера, чтобы получить приемлемый результат и не сорвать дедлайны. Я расписывал им график работы с внутренними сроками, не пускал дизайн посмотреть разрабам, пока я не посмотрю и обо всех решениях просил советоваться со мной.
Краткий план моего новичка на день мог выглядеть так:
1. Ознакомиться с ТЗ
2. Собрать референсы
3. Нарисовать наброски
4. Показать референсы и наброски Ване (это я)
5. Исправить и повторять пункт 2—5 пока Ваня не скажет «норм»
6. Нарисовать первый экран, показать Ване
7. Нарисовать остальные, показать Ване
8. Показать разработчику, собрать замечания, посоветоваться с Ваней
9. Вместе с Ваней разобрать замечания и доделать работу
Я понимал, что без жесткого плана, результат будет удручающий. Пока джунов было только 3 — я справлялся, когда 8 — стало тяжко. На 10 джуне я понял, что весь день только и делаю, что контролирую и советую. Без меня работа не шла, я был очень важен, мои джуны не знали что делать, если я опаздывал на работу. Это была самая главная проблема. Я почти не рисовал, работа перестала приносить радость, я начал путаться в показаниях. Наступила бесконечная жопа контроля.
К моменту самой жопы, я был уже тимлидом.
Решение я нашел радикальное — ограничил время согласований до двух часов в день: с 12 до 13 и с 16 до 17. Я просто отключал уведомления и, если ко мне подходили с несрочным вопросом, отправлял ждать. Кроме того, я скинул контроль за джунами полностью на миддлов.
Другие тимлиды предсказывали, что мой план не сработает: проблем в день больше, чем на 2 часа. Первые пару дней так и было. Потом, моя команда поняла, что помощи от меня ждать долго и начала решать проблемы самостоятельно. Оказывается то, что я брал на себя ответственность за результат, расслабляло ребят и они скидывали мне сырое решение, в надежде, что я поправлю.
Не сразу, но постепенно я всё меньше замыкал процессы на себе. Спустя месяц, я тратил на команду 40 минут в день, вместо 4–6 часов. Тогда я понял, что главная задача руководителя наладить процесс так, чтобы стать ненужным.
По теме:
https://medium.com/@allo/о-главной-задаче-руководителя-69b8de225f1b
Medium
О главной задаче руководителя
Люди, полагающие, что они никому не нужны, на самом деле часто самые нужные. Эрих Мария Ремарк
Мои лучше заметки за последний год
Если вы на канале недавно, они помогут понять о чём я пишу и решить насколько канал интересен.
Что делать, если статьи и книги по дизайну больше не приносят удовольствия
https://news.1rj.ru/str/Design_fire/554
Как выровнять цвета по тону. Несколько записей подряд
https://news.1rj.ru/str/Design_fire/591
Нельзя просто взять и сделать как в другом продукте
https://news.1rj.ru/str/Design_fire/598
Как дизайнеру найти задачи
https://news.1rj.ru/str/Design_fire/631
Зачем хранить старые работы и мысли
https://news.1rj.ru/str/Design_fire/646
Пустой экран как точка старта, а не тупик
https://news.1rj.ru/str/Design_fire/649
Критикуешь — не жести
https://news.1rj.ru/str/Design_fire/652
Нативные и кастомные элементы. Каюсь, называл нативные элементы стандартными, но это немного неверно.
https://news.1rj.ru/str/Design_fire/661
Любой процесс сложнее, чем выглядит сначала
https://news.1rj.ru/str/Design_fire/665
Правила, чтобы не выгореть
https://news.1rj.ru/str/Design_fire/701
Как устроены тени в Андроиде и что с этого дизайнеру
https://news.1rj.ru/str/Design_fire/706
Ещё я показываю интерфейсные находки у разных сервисов и рассказываю почему они хороши. Найти их можно по тегу #ux_мелочи
Если вы на канале недавно, они помогут понять о чём я пишу и решить насколько канал интересен.
Что делать, если статьи и книги по дизайну больше не приносят удовольствия
https://news.1rj.ru/str/Design_fire/554
Как выровнять цвета по тону. Несколько записей подряд
https://news.1rj.ru/str/Design_fire/591
Нельзя просто взять и сделать как в другом продукте
https://news.1rj.ru/str/Design_fire/598
Как дизайнеру найти задачи
https://news.1rj.ru/str/Design_fire/631
Зачем хранить старые работы и мысли
https://news.1rj.ru/str/Design_fire/646
Пустой экран как точка старта, а не тупик
https://news.1rj.ru/str/Design_fire/649
Критикуешь — не жести
https://news.1rj.ru/str/Design_fire/652
Нативные и кастомные элементы. Каюсь, называл нативные элементы стандартными, но это немного неверно.
https://news.1rj.ru/str/Design_fire/661
Любой процесс сложнее, чем выглядит сначала
https://news.1rj.ru/str/Design_fire/665
Правила, чтобы не выгореть
https://news.1rj.ru/str/Design_fire/701
Как устроены тени в Андроиде и что с этого дизайнеру
https://news.1rj.ru/str/Design_fire/706
Ещё я показываю интерфейсные находки у разных сервисов и рассказываю почему они хороши. Найти их можно по тегу #ux_мелочи
Telegram
Дизайн печь 🔥
Что делать, если статьи и книги по дизайну больше не приносят удовольствия
Расширять кругозор, только так. Дизайнер тем ценнее, чем больше знает о мире. Все методы по решению дизайнерских задач, что я видел, основаны на переборе инструментов, что могут решить…
Расширять кругозор, только так. Дизайнер тем ценнее, чем больше знает о мире. Все методы по решению дизайнерских задач, что я видел, основаны на переборе инструментов, что могут решить…
Что нужно знать дизайнеру о том, как мобильные разработчики собирают карточки.
🧐О чём речь
В iOS три элемента, похожих на карточки:
1. Карточка
2. Шторка
3. Карточный вид.
🧑💻Как делают
Карточка — простой кастомный элемент. Это значит, что разработчику либо придётся писать с нуля, либо искать библиотечку. Если вы хотите сделать карточку «как в App Store», то придётся описывать как работает карточка, следить, что анимация по времени такая же, тень пушистая, карточка нажимается сразу при тапе и т.д. Благо, карточка делается не сильно сложно и любой iOS разработчик сможет её сделать.
Шторка — сложный кастомный элемент. Хоть она появилась в приложениях Apple (Карты, Команды, Акции), в стандартные компоненты её не добавили. Значит разработчик будет делать с нуля или возьмёт готовую библиотеку. Проблема готовых библиотек, в том, что их надо проверять. Возможно, что библиотека написана криво и в ней что-то отвалится с выходом новой версии Оси.
Карточный вид — нативное представление для экрана. Разработчик может сделать такое за 5 минут. Есть ограничения:
1. Пипки сверху, за которую можно сворачивать окно по-умолчанию нет. Её можно добавить наверх карточки, но это будет непросто. Почему эппл её не сделали — не знаю.
2. Свайпать экраны в карточном виде нельзя.
3. В iOS 12 нет карточного вида. В iOS 12 экран будет на всю высоту.
Если вам нужно выйти за ограничения, то опять же писать с нуля.
😎 И что теперь
Обсуждайте дизайн с разработчиками до того, как покажете заказчику. Если до релиза неделя, то шторку скорее всего не сделают, а вот карточку успеют. А может разработчик новичок и не справится и с карточкой. Просите оценить разработчиков сложность реализации и сколько времени это займёт. Спросите какие баги могут вылезти. Возможно, что для него в норме вещей будет, что заголовок будет дергаться, но узнаете вы об этом только после недели реализации.
🧐О чём речь
В iOS три элемента, похожих на карточки:
1. Карточка
2. Шторка
3. Карточный вид.
🧑💻Как делают
Карточка — простой кастомный элемент. Это значит, что разработчику либо придётся писать с нуля, либо искать библиотечку. Если вы хотите сделать карточку «как в App Store», то придётся описывать как работает карточка, следить, что анимация по времени такая же, тень пушистая, карточка нажимается сразу при тапе и т.д. Благо, карточка делается не сильно сложно и любой iOS разработчик сможет её сделать.
Шторка — сложный кастомный элемент. Хоть она появилась в приложениях Apple (Карты, Команды, Акции), в стандартные компоненты её не добавили. Значит разработчик будет делать с нуля или возьмёт готовую библиотеку. Проблема готовых библиотек, в том, что их надо проверять. Возможно, что библиотека написана криво и в ней что-то отвалится с выходом новой версии Оси.
Карточный вид — нативное представление для экрана. Разработчик может сделать такое за 5 минут. Есть ограничения:
1. Пипки сверху, за которую можно сворачивать окно по-умолчанию нет. Её можно добавить наверх карточки, но это будет непросто. Почему эппл её не сделали — не знаю.
2. Свайпать экраны в карточном виде нельзя.
3. В iOS 12 нет карточного вида. В iOS 12 экран будет на всю высоту.
Если вам нужно выйти за ограничения, то опять же писать с нуля.
😎 И что теперь
Обсуждайте дизайн с разработчиками до того, как покажете заказчику. Если до релиза неделя, то шторку скорее всего не сделают, а вот карточку успеют. А может разработчик новичок и не справится и с карточкой. Просите оценить разработчиков сложность реализации и сколько времени это займёт. Спросите какие баги могут вылезти. Возможно, что для него в норме вещей будет, что заголовок будет дергаться, но узнаете вы об этом только после недели реализации.
Открывать поиск по свайпу вниз — невероятно удобная фишка. Не надо тянуться пальцем наверх, а если свайпнул случайно, то просто скроллишь вниз. Свайпом вниз искать быстрее. Надеюсь, Эппл тоже такую фишку введут на уровне оси.
Приложения Things и Bear
#ux_мелочи
Приложения Things и Bear
#ux_мелочи
Давайте отметим такое круглое число небольшим интерактивом. Задавайте направление, что вам интересно?
Anonymous Poll
19%
Вы задаёте мне любые вопросы в личку или комментарии, а я отвечаю на них серией постов %)
39%
Вы кидаете мне своих работ, я их смотрю и нежно линчую =3
42%
Ничего не надо, лучше напишу что-нить, как умею
0%
Свой вариант в личку или комментарии
Вот это битва! То второй пункт обгонял, то третий. Я вижу, что у вас есть интерес к нежным линчам. Кидайте свои работы в личку @Nordicus, я буду их смотреть по одной и раз в неделю показывать на канале =)
А сегодня я обящательно напишу что-нить, как умею.
А сегодня я обящательно напишу что-нить, как умею.
Обещал рассказать о бесячих решениях других дизайнеров. Так вот…
Не скрывайте информацию
😡 Что бесит
Бесит, когда дизайнеры скрывают важную информацию и ты потом ничего не можешь сделать.
Например, когда пытаешься скачать фотку и в итоге дергаешь её из исходного кода страницы, хотя кнопка скачать была спрятана в тоненьком троеточии в левом верхнем углу страницы.
Или когда приходит не тот товар, а оказывается, что ты не заметил скромную «читать описание» рядом с фотографией.
😡 Что бесит
Бесит, когда дизайнеры скрывают важную информацию и ты потом ничего не можешь сделать.
Например, когда пытаешься скачать фотку и в итоге дергаешь её из исходного кода страницы, хотя кнопка скачать была спрятана в тоненьком троеточии в левом верхнем углу страницы.
Или когда приходит не тот товар, а оказывается, что ты не заметил скромную «читать описание» рядом с фотографией.
Я каждый раз туплю на Юле, когда нужно изменить объявление. Они спрятали кнопку в троеточие, хотя Снять с публикации и Сделать скидку вшиты в само объявление. Можно было бы избавить от троеточия и написать понятное Изменить.
🤷♂️Почему так происходит
Дизайнер не разобрался
Маркетолог проводит исследование рынка и видит, что кнопки «поделиться в соцсеть» под товаром в интернет магазине увеличивают возвраты клиентов. Клиенты кидают их сами себе в сообщения и возвращаются за товаром. Ставит задачу дизайнеру. Дизайнер думает «да ну, фигня какая! Если клиент захочет — скопирует ссылку и отправит сам себе! Я так не делаю, да кому это вообще надо?!» и ставит кнопку где-то еле-заметно сбоку. Т.е. формально задача выполнена, но ничего переделывать не надо.
Дизайнер поленился
Пришел дизайнеру важный текст описания, а у него в макете больше трёх строк некрасиво смотрится. Он делает кнопку «смотри далее» и отдаёт в продакшн. Однажды я покупал 2 книги, а мне пришло 3. В описании было сказано, что первая книга идёт в комплекте со второй. Да, эта информация была спрятана под раскрывашкой.
Дизайнер не разобрался
Маркетолог проводит исследование рынка и видит, что кнопки «поделиться в соцсеть» под товаром в интернет магазине увеличивают возвраты клиентов. Клиенты кидают их сами себе в сообщения и возвращаются за товаром. Ставит задачу дизайнеру. Дизайнер думает «да ну, фигня какая! Если клиент захочет — скопирует ссылку и отправит сам себе! Я так не делаю, да кому это вообще надо?!» и ставит кнопку где-то еле-заметно сбоку. Т.е. формально задача выполнена, но ничего переделывать не надо.
Дизайнер поленился
Пришел дизайнеру важный текст описания, а у него в макете больше трёх строк некрасиво смотрится. Он делает кнопку «смотри далее» и отдаёт в продакшн. Однажды я покупал 2 книги, а мне пришло 3. В описании было сказано, что первая книга идёт в комплекте со второй. Да, эта информация была спрятана под раскрывашкой.