20 заметок с тегом

дизайн

Позднее Ctrl + ↑

Планы на 2020 год

План победы: 2017 · 2018 · 2019 · 2020

Фокус в 2020 хочу направить на следующие направления:

  • мобильный дизайн,
  • дизайн-менеджмент,
  • фронтенд,
  • пользовательский опыт.

Прочитать

  1. «Envisioning Information» Edward Tufte
  2. «The Handbook of Design Management» Rachel Cooper, Sabine Junginger, Thomas Lockwood
  3. «Бизнес с нуля» Эрика Риса
  4. «Дизайн привычных вещей» Дональда Нормана
  5. «О продакт менеджменте» Интеркома

Сходить

  1. Фестиваль дизайна и цифрового искусства OFFF Moscow 2020

Поучиться

  1. «Как руководить дизайнерами» Костя Горский Очень круто. Обязательно к изучению.
  2. «Быстрая анимация иллюстрации в After Effects» Константин Новиков
  3. «Как организовать команду» Ольга Герасименко Максимально полезным оказалась последняя лекция. Написал даже конспект на эту тему семь фаз формирования команды.
  4. «Дизайн своей карьеры» Дмитрий Карпов Хороший быстрый интенсив нацеленный на новых людей в профессии.
  5. «UX: Поведенческое проектирование» Дмитрий Карпов
  6. «Здоровые настройки» Ольга Герасименко
  7. «Принципы Principle» Александр Токарев
  8. «Как победить конкурентов и инерцию выбора» Ивана Замесина
  9. «Мобилизация» Школы дизайна Яндекса
  10. «Управление проектами и продуктом» Школы менеджмента Яндекса
  11. Mobile Product
  12. User Research — Methods and Best Practices
  13. User Experience (UX): The Ultimate Guide to Usability and UX
  14. Beyond Usability: Learn the User Research Toolkit
  15. «Основы JavaScript» HTML Academy
  16. «Паттерны дизайн-менеджмента» Юрий Ветров

Сделать

  1. Работать над Wash.me
  2. Сделать три мобильных жизнеспособных проекта
  3. Сделать что-то, где я сам попрактикуюсь с JavaScript
  4. Собрать крепкую дизайн-команду
  5. Систематизировать процесс работы над задачами
  6. Довести до завершения «Радиоэмоции»
  7. Составить планы на 2021

План победы: 2017 · 2018 · 2019 · 2020

Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме или RSS.

Макетная актуальность

Проектируя что-то новое на основании старого, дизайнеру необходимо куда-то обращаться за информацией. Например, как это работает, а как выглядит этот модуль, как себя поведет система?

У нас в команде есть 5 источников таких знаний:

  • требования в Jira,
  • макеты в Zeplin,
  • статическая вёрстка,
  • cтейджинг,
  • голова дизайнера.

Итак, разложим каждый по характеристикам: лёгкость поиска, читаемость, близость к правде, видимость деталей.

Требования в Jira

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

Макеты в Zeplin

Макеты легко найти, но тяжело поддерживать. У них понятная структура, нейминг и есть превьюшки. Они близки к правде и показывают почти все состояния элементов интерфейса и детали сценариев.

Статическая вёрстка

К ним простой доступ по домену. Есть структура как у макетов, но не настолько детальная. Они близки к правде, так как они и есть правда. Как правило, верстка не показывают все состояния элементов интерфейса и детали сценариев.

Стейджинг

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

Голова дизайнера

К сожалению в свою голову всё не помещается, а чужая часто недоступна. Дизайнер скорее всего хорошо знает структуру, детали и состояния, но это не точно. Он легко может ошибиться или забыть.

Вывод

Требования Макеты Вёрстка Стейджинг Голова
Лёгкость поиска + + +
Читаемость + +
Правдивость +/− + + + +/−
Видимость деталей +
Итого −3 4 3 0 −3

Вот и решайте теперь, стоит держать макеты актуальными или нет.


Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме или RSS.

Глубинное интервью

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

Закрытые вопросы

Почти всегда задавать закрытые вопросы — это плохо. Они предполагают бинарный или однозначный ответ: да или нет.

Преимущества:

  • позволяют получить конкретную информацию
  • подтвердить или опровергнуть гипотезы, проверить, правильно ли вы поняли
  • хорошая смена темы

Недостатки:

  • получаем мало информации
  • нет деталей и подробностей
  • можем навязать свое мнение

Открытые вопросы

Эти обычно начинаются со слов: «почему, зачем, как, опишите, расскажите, что вы думаете и прочее».

Преимущества:

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

Недостатки:

  • могут спровоцировать длинный сумбурный ответ
  • собеседник может увлечься и уйти «не туда»

Грязный приём, как превратить закрытый вопрос в открытый. Закрытый вопрос + «Расскажите...» = Открытый вопрос.

Техника «Пять почему»

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

Часто повтор одного и того же вопроса вызывает дискомфорт. Как сгладить его:

  1. Переформулировать, например «Что является причиной?» или «Из-за чего ... происходит?» или «А чего так?».
  2. Сказать, что будете спрашивать «Почему?», потому что хотите докопаться до первопричины.

Техника «Что? Кто? · Где? Когда? · Как? Почему?»

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

  • Что произошло? Что было самое сложное? Что делает человек? Кто ещё вовлечён? Что не устраивает в текущем решении?

Узнать контекст. Где это происходит и когда.

  • Где это происходило? Когда это происходило в последний раз?

Как они это делают. Как решают задачи уже. Почему так.

  • Как именно это произошло? Почему это было сложно? Как вы справились? Как часто повторяется? Поменялась ли решение проблемы со временем и почему?

Стадия: подготовка

Подготовка заключается в шести шагах:

  1. Понять цель интервью.
  2. Сделать кабинетное исследование по теме.
  3. Составить план: вопросы, ситуации, особенности.
  4. Сформулировать гипотезы.
  5. Задуматься, что ещё может пригодиться на интервью.
  6. Иметь 3 главных вопроса.

Стадия: интервью

Начало

  • Расскажите, кто вы и зачем это интервью проводите.
  • Обозначьте продолжительность.
  • Скажите, что нет неправильных ответов. Вы здесь для того, чтобы узнать реальный опыт человека.
  • Первые вопросы стоит делать вводными, чтобы расположить респондента к себе.

Основная часть

  • Говорите о жизни собеседника, а не о вашей идее.
  • Спрашивайте о конкретных вещах, которые происходили в прошлом, а не о взглядах или мнениях на перспективу.
  • Меньше говорите, больше слушайте.
  • Используйте техники «Пять почему» и «Что? Кто? · Где? Когда? · Как? Почему?», чтобы копать глубже.
  • Проявляйте дружелюбие и интерес. Будьте проще.
  • Разговаривайте на одном языке
  • Сохраняйте нейтральность вопроса. Не высказывайте своё мнение. Не оценивайте.
  • Просите сравнивать.

Окончание
Поблагодарите собеседника. Узнайте, не хочет ли человек что-то добавить или спросить у вас. Спросите контакты других людей, с которыми можно поговорить. Договоритесь о потенциальном продолжении.

Сложные ситуации: молчаливый респондент

Иногда респондент попадается совсем неразговорчивый. Тут следует рассказать о ценности этого разговора. Рассказать, кто вы и зачем это всё сейчас происходит. Так сказать, заинтересовать респондента. Отодвинуть цель в сторону и наладить личный контакт.

Сложные ситуации: неуверенный

Бывает респондент на каждый вопрос даёт размытые ответы. И да и нет, и так и сяк. Возможно, это даже очень хорошо. У респондента может быть разный опыт и тут стоит покапать глубже. Расспросите про каждый вариант в отдельности, почему да, почему нет. Попросите привести примеры всех ситуаций.

Сложные ситуации: говорливый

Респондент после вопроса уходит в сторону и дает совсем бесполезную информацию. Иногда таких даже невозможно остановить, а время интервью тикает. Тут важно умело останавливать респондента. Например, предлагать обсудить это позже. Прерывать нужно тоже аккуратно, старайтесь это делать «на вдохе».


Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме или RSS.

Уровень проработки

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

Как бы времени у нас совсем нет, а функциональность урезать нельзя. Остается только снизить уровень проработки. Мы решили понижать его не для всех задач, а только для некоторых. Тут на помощь пришёл Купер, а с ним и три уровня проработки.

Пользовательские сценарии в любом продукте можно разделить на три уровня. Уровень первый — сценарии, которыми люди пользуются чуть ли не каждый день. Мы такие сценарии назвали магистральными. Второй — важные, но нужные не часто. Эти сценарии назвали промежуточными. Третий — скорее исключения, это как раз те сценарии про которые обычно совсем забывают.

Магистральные сценарии

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

Промежуточные сценарии

Это сценарии важные, но при этом ими пользуются не так часто. Например, настройки профиля. В таких сценариях нужно не меньше времени уделить проектированию и проверкам, но можно более хладнокровно относиться к ошибкам. Тут учитывать хоткеи уже нет смысла и если какой-то сценарий приведет к ошибке — это не так страшно, как в первом случае. Говорят, что именно поэтому в автомобиле салон сделан максимально комфортным, по сравнению с моторным отсеком. Таких сценариев обычно намного больше, чем первых.

Сценарии исключения

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

Как определить сценарии, если это неочевидно

Тут мы придумали простую систему. Берем три метрики: количество пользователей, частота встречи сценария, серьезность. И оцениваем каждую либо 0, либо 1. Как правило, магистральные сценарии получают оценку 3, промежуточные 2, а исключения 1 или 0.

Что делать, если и на первые два уровня уже нет ресурсов

Первое о чем стоит подумать — это делать ли эти сценарии вообще. Ну а если уже решили всё же делать, то делайте низкую проработку модульно. Определите часть системы, которую позже комплексно можно будет переделать.

Вывод

Никому не нужен магазин с идеально продуманным сценарием добавления товара в «Избранное» в двух вкладках браузера, когда поиск товаров работает плохо и непонятно.


Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме или RSS.

Общение в команде

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

Общая цель и миссия

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

Беда в той команде, где люди идут к разным целям. Из этого вытекает следствие, что цель проекта должна быть выше, чем личная. Проблема в том проекте, в котором у дизайнера цель сделать портфолио, у программиста — поехать на конференцию в Амстердам с клёвым докладом, а у маркетолога — победить в конкурсе «Бренд года».

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

«Программисты думают только о себе, а не о пользователях»

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

Общее решение

Самая большая ошибка, это пойти сразу рисовать макеты. Рисовать их неделю. Две. А потом бежать с этими макетами к разработчикам (вокруг макетов лучи нимба), а они в итоге говорят, что есть решение проще или еще хуже:

«Это сделать невозможно!»

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

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

«Ничего не знаю, так было в макете!»

Вообщем, решение должно быть общим, больше общения и будет всем хорошо.

Общая точка успеха

Определили точку успеха. Что будет являться успешным завершением проекта или задачи в первом подходе. Это избавит проект от лишних хотелок. И вы тогда никогда не услышите от программистов:

«У вас концепция постоянно меняется, достали»

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

Равенство

Уважайте друг друга. Дизайнер является полноценным членом команды разработки. Разработчики — тоже дизайнеры. У вас без друг друга врядли что-то хорошее получится, уважайте профессию друг друга. Учитесь слушать и слышать, договариваться. Это чтобы не было таких фраз в вашу сторону:

«А почему у меня не спросили?»

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


Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме или RSS.

Ранее Ctrl + ↓