Блог Дмитрия Московского

Дизайнер пишет про работу, заметки в телеге
Оглавление и об авторе

8 частых ошибок дизайнеров в тестовом задании

Привет, рассказал какие видел самые частые ошибки продуктовых дизайнеров в тестовых работах. Если вы дизайнер, делаете тестовое задание и задаетесь вопросом «как сделать тестовое задание?», то вам будет полезно узнать на что я обратил внимание, проверив много дизайнерских тестовых заданий.

Копировать и вставить — обновление Figma. Быстрый разбор новых возможностей

В этом видео я собрал самые важные изменение Фигмы при обновлении функции copy/paste: позиционирование вставляемого элемента, мульти-вставка, paste here, вставка с заменой, вставка в зону видимости. Во второй части рассказываю как копировать стили в figma, как скопировать «as PNG» и как SVG.

Горячие клавиши в Фигме, которые я использую: как запомнить и как работать быстро (Figma Hotkeys)

В этом видео собрал 9 групп горячих клавиш, которые использую в своей работе. Чтобы быстро рисовать дизайн, нужно их запомнить и начать применять. Всем добра, пишите вопросы, пожелания к новым видео!

Исходник с презентацией

 Нет комментариев    682   11 мес   figma   видео

Figma: Интерактивные компоненты (бета)

Записал видео про интерактивные компоненты в фигме. Показываю что можно с ними сделать на своих кейсах. Мне кажется, это обновление поднимает уровень дизайнера на новую ступень. Я уже не говорю про открывающие возможности к тестированию проекта.

Ненужные функции

В админке CRM wordpress есть выбор первого дня недели.

Первый день недели может быть либо воскресение, либо понедельник, других вариантов я не знаю. Но в вордпрессе решили дать все дни на выбор. Представляю разговор разработчиков:
— А зачем нам ограничивать пользователя, вдруг кто-то захочет начинать неделю со среды. Давайте дадим эту возможность! Тем более это нам ничего не стоит, а пользователи оценят!

Так вот, большинство пользователей работают с настройками по умолчанию. С какого дня начинать неделю машина должна определять сама, в зависимости от региона использования. Чем больше интерфейс перекладывает на пользователя, тем менее он кажется понятным и удобным. Не делайте так.

Выступления в финале на хакатоне от вконтакте

Участвовал в двухнедельном хакатоне от вконтакте. Наша команда заняла 6 место из 600+ команд. Для финала за сутки нужно было продумать и презентовать случайную и смешную тему. У нас было приложение с дополненной реальностью для занятий спортом диснеевских принцесс. Было весело делать и выступать.

Из полезного: можно посмотреть или скопировать презентацию в фигме (для просмотра нажмите плей)

Дизайн мобильных приложений. Летний интенсив в Британке

После обучения в Бюро Горбунова я хотел попасть на обучение в Британку. Это случилось на летнем интенсиве 2019. Расскажу про свой опыт и проект, который мы там делали.

Всех учащихся разделили на команды по 4 человека. После первого дня лекций от разных спикеров, рассказали про задачу. Нам достался проект от Яндекс Почты: нужно было улучшить боковое меню.

В ходе обучение было весело, было сложно и было сжато. На что уходит месяц, нужно было сделать за 4 дня и применять новые знания, которые параллельно нам рассказывались.

На лекциях было много информации от разных спикеров.

У каждой команды был наставник, который включался в задачу и помогал. Завершением интенсива — выступление на большую аудиторию. Помимо строгих судьей, нас оценивали все желающие, которые пришли на открытую защиту. Часть из пришедших ищет дизайнеров к себе в компанию.

Наша презентация не обошлась без юмора

Наш концепт Яндекс Почты

Один из слайдов из презентации

Мое мнение: на интенсив я пошел уже имея за плечами почти год работы в Яндексе. Там еще раз прошелся по знакомым темам и структурировал знания. Узнал, что-то новое, но многое уже знал. Плюс прокачал навык презентации. Новичкам советую. Ссылка на интенсивы

Как дизайнеру перестать думать статически

Когда я начинал свой путь в дизайне, главное что меня беспокоило — как сделать финальную картинку. О том, как будет эта страница вести себя в цепочке остальных — я не задумывался. За полгода обучения в школе Горбунова, таких задач не возникало: мы проектировали не многостраничные сервисы, а что-то простое, одностраничное.

Образно, как я думал над макетом

На стажировке в Яндексе столкнулся со сложными взаимодействиями, но делал по-старинке: рисовал картинку, смотрел на неё, смотрел на отступы, как будет удобно расположить кнопки, что еще можно подвигать.

Потом, приносил этот макет на обсуждение команде опытных дизайнеров. Получал список замечаний в духе: а что будет если нажать на эту кнопку, а что будет если данных не будет или не загрузятся. Как будет после нажатия на меню — для меня была загадка;

Мой наставник по стажировке дал мне совет, в духе «начни представлять как будет работать интерфейс, что будет в динамике». Полностью прочувствовал этот совет совсем недавно :-)

Теперь для меня интерфейс — это история, которая движется во времени. Я прокручиваю в голове идеальный путь пользователя, как покадровая анимация. Затем ищу затыки, редкие кейсы, которые могут произойти у пользователя.

Проектируется не страница, а история

Для меня следующий этап, это продумывание анимации и микровзаимодействия, которая помогает связать экраны между собой и приносит удовольствие от использования. Буду рад советам, что почитать или посмотреть на эту тему?

Выводы: для проектирования интерфейсов представляйте как ваш интерфейс работает, как вы с ним взаимодействуете, прокрутите сценарий в голове от начала до конца. Все ли было окей? Где логика хромает? Если сложно представить, то поможет быстрый прототип в фигме, который можно дать «потыкать» кому-то ещё.

Проект Здоровье

Год назад принимал участие в интеграции приложения Яндекс Здоровье в приложение Яндекс . Задача заключалась в том, чтобы перевести функциональность приложения на новые компоненты и быстро запустить.

Посмотреть приложение можно внутри приложения Яндекс.

Дизайн счетчика баллов в репетиторе

Какое-то время назад я помогал сервису Яндекс Репетитор повысить вовлеченность учеников. Для этого команда предложила сделать счетчик баллов. В итоге появился блок с баллами, блок и раздел с достижениями ученика.

При выполнении задания счетчик растет, можно перейти в достижения и посмотреть свою статистику
При наведении на каждый из предметов можно увидеть статистику по предмету: сколько баллов за сегодня и вклад за неделю
При достижении определенных значений — выдается награда с анимацией

Вопросы для страницы при проектировании дизайна

— Постоянно забываю нарисовать какую-то фигню для разработчиков, а они меня потом достают 😡
— Держи чек-лист!

Перед сдачей дизайна сайта или приложения нужно пробежаться по списку. Я частенько не задумываюсь, все ли доделал. А потом разработчик отрывает от работы и просит доделать. Чтобы такого не было, внизу чек-лист:

Чек-лист для дизайнера перед сдачей макетов

  1. Состояние выделения у всех элементов, на которые можно нажать: кнопок, ячеек таблицы, инпуты.
  2. Пустые экраны: когда пользователь первый раз зайдет, когда у него ничего не будет, когда он все удалит, если нет аватарки.
  3. Что будет показываться, когда у пользователя медленный интернет: скелетон, картинка мелким размером, которая при дозагрузке станет четкой.
  4. Проверить текст на реальных данных. Что будет если текст не влезет, что если будет на других языках.
  5. Состояния ошибок, уведомления о действиях, алерты, попапы, 404 ошибка и т. д.
  6. Ну и само собой, если нарисовали веб-версию, не забываем про тачи и про ширину 320 px.
    Подробно об этом рассказывали в этом видео.

Чек-лист для проверки решения

А еще я для себя составляю чек-лист для этапа проверки своего решения, у кого есть идеи пишите в комментарии

  • Кто наши пользователи?
  • Какой основной сценарий выполняет пользователь на этом экране?
  • Как человек поймет, что это за интерфейс, будет ли обучение? Как разберется в нашем продукте?
  • Что главное должен считывать пользователь на этом экране?
  • Что не главное на этом экране?
  • Что если пользователь не готов выполнить наше действие или хочет отказаться?
  • Что если пользователя отвлекли? Он вспомнит что он делает на этом экране?
  • Как этот экран помогает пользователю выполнить его основной сценарий?
  • Какой будет не основной сценарий? А какой сценарий еще возможен?
  • Если есть цвета — как они помогают пользователю решить его задачу?
  • Нужны ли полоски внутри таблицы

    Решил разобраться как лучше сделать с полосками или нет.

    Сперва смотрю на сайте бюро: нашел статью про черезполосицу, они предлагают её убирать. А вот мнение Ильи Бирмана насчет линий. И у него же отличный пример таблицы без полосок:

    Нужно взглянуть на примеры других сервисов:

    В моем случае решил выбрать 1 вариант:

    Пример с работы: между строчек есть или нет разделительной линии (шапку замазал, чтобы ни кто не догадался)

    Для себя нашел такие зависимости:

    1. Если в таблице 2-3 значения цифр то можно обойтись и без полосок: смотрится вполне хорошо.
    2. Когда много цифр и они находятся на непредсказуемом расстоянии друг от друга, по всей длине экрана — то полоски лучше использовать.
    3. Черезполосицу просто так использовать не стоит, но в анализе финансовых показателей этот приём может обозначать рост и падение акций.
    4. Если делать полоски, то делать их незаметными, серенькими.

    Как оценивать UX дизайн бесплатно и без исследований

    Предположим у нас есть 2 варианта пути пользователя. Как определить, что один из них лучше другого? В моем примере ниже — это очевидно: чем меньше экранов, тем лучше.

    Два варианта сценария покупки

    Но, что делать если количество экранов равно? Когда я столкнулся с такой задачей, то начал считать количество действий пользователя. Например, тут нужно: навести на кнопку «купить», нажать на кнопку, на другом экране прочитать заголовок, навести на кнопку добавить в корзину и т. д. Когда все действия расписаны, легко заметить, где нужно совершить меньше движений.

    Метод GOMS

    Более продвинутую методику я услышал от одного из спикеров на Media & Design Conference. Они так же считают количество действий пользователя, но еще переводят действия в секунды и оценивают финально сколько пользователь тратит времени на каждый экран. Самое интересное — расчеты времени пользователя.

    K = 0,28 c — нажатие клавиши клавиатуры;
    B = 0,2 с — клик мышью;
    P = 1,1 с — среднее время нахождения любого объекта на сайте;
    H = 0,4 с — перемещения руки с клавиатуры на мышь (или обратно);
    M = 1,35 с — ментальная пауза (время на обдумывание следующего шага).

    Почему то запись этого доклада пропала, но я для себя наскриншотил самое важное:

    С помощью этого способа можно доказать удобство одного из вариантов, но этот метод имеет свои исключения: например огромную форму для заполнения лучше разбить на несколько экранов.

    Ранее Ctrl + ↓