Михаил Озорнин написал о выравнивании данных в таблице. Это не пересказ Мильчина, правила основаны на опыте Михаила.
1. По умолчанию всё выравнивайте по левому краю. Затем меняйте выравнивание нетекстовых данных.
2. Числа — по правому краю. Числами считаем то, что имеет смысл сравнивать друг с другом. Инвентарные номера, индексы, номера паспортов, IP-адреса — не считаем числами.
3. Диапазоны — по разделителю. Примеры пар чисел, написанных через разделитель: 1…15, 1—15, 1 / 15, 1 из 15. Разделитель становится для них осью.
4. Значки — по центру. Значки — это отдельные символы (плюс, минус), пиктограммы, эмодзи. Если в такой колонке оказывается текст вроде «нет данных», его выравнивайте тоже по центру.
5. Для чисел используйте моноширинные шрифты. Так числа вроде 1113 и 3800 будут совпадать по разрядам. В некоторых шрифтах есть и пропорциональные цифры, и моноширинные, но их надо специально включать.
http://mikeozornin.ru/blog/all/how-to-align-data-in-table/
1. По умолчанию всё выравнивайте по левому краю. Затем меняйте выравнивание нетекстовых данных.
2. Числа — по правому краю. Числами считаем то, что имеет смысл сравнивать друг с другом. Инвентарные номера, индексы, номера паспортов, IP-адреса — не считаем числами.
3. Диапазоны — по разделителю. Примеры пар чисел, написанных через разделитель: 1…15, 1—15, 1 / 15, 1 из 15. Разделитель становится для них осью.
4. Значки — по центру. Значки — это отдельные символы (плюс, минус), пиктограммы, эмодзи. Если в такой колонке оказывается текст вроде «нет данных», его выравнивайте тоже по центру.
5. Для чисел используйте моноширинные шрифты. Так числа вроде 1113 и 3800 будут совпадать по разрядам. В некоторых шрифтах есть и пропорциональные цифры, и моноширинные, но их надо специально включать.
http://mikeozornin.ru/blog/all/how-to-align-data-in-table/
mikeozornin.ru
Как выравнивать данные в таблице
Основные правила выравнивания в таблицах, чтобы вы могли не читать Мильчина
Рейчел Бергер написала о влиянии технологических компаний на дизайнерские портфолио.
Чтобы развиваться, дизайнеры следят за миром дизайна в том числе по чужим портфолио. Рейчел заметила, что дизайнеры, переходящие в технологические компании, перестают их обновлять.
Возможно, им запрещают контракты? Юристы крупных компаний и их независимые подрядчики подтверждают, что разрешение на публикацию работы в портфолио получить непросто.
Сами дизайнеры не считают это главной проблемой. Чтобы пополнять портфолио, надо делать проекты (1), которые хочется показать (2) в портфолио (3).
1. В быстрорастущих компаниях дизайнеры много времени проводят на встречах, просто чтобы со всеми синхронизироваться. Скриншот забитого встречами календаря в портфолио не положить.
Дизайнер не создаёт в одиночку что-то своё, он делает вклад в развитие системы. Сложно выделить часть продукта и назвать её своей работой. Также часто приходится работать в стол.
2. Непонятно, что дизайнер получит от пополнения портфолио. Работа у него и так есть.
Интуитивные, функциональные, почти невидимые интерфейсы, сильно влияющие на людские жизни, не выглядят так же интересно, как книги, постеры, стулья или автомобили, где видна дизайнерская индивидуальность.
3. Пара сочных картинок не передаст контекста, целей и ограничений, с которыми работал дизайнер. Без них обсуждать результат нет смысла. Как лучше донести до читателя историю проекта — непонятно. Но в любом случае создание рассказа потребует сил и времени.
Твит о запуске продукта, статья с анализом нового процесса регистрации, лекция и даже патентная заявка могут сработать лучше, чем портфолио.
Ещё надо поддерживать актуальностью портфолио, которое в технологических компаниях быстро устаревает. Дизайн сегодняшнего релиза создан несколько месяцев назад, и через несколько месяцев может обновиться.
Нужны новые способы показать свою работу. Кейс с описанием дизайнерского вклада на каждом этапе создания продукта полезнее дюжины картинок. Лучшие работодатели оценивают дизайнера не только по тому, что он сделал, но и — как он мыслит.
[English] https://modus.medium.com/218bcbc11080
Чтобы развиваться, дизайнеры следят за миром дизайна в том числе по чужим портфолио. Рейчел заметила, что дизайнеры, переходящие в технологические компании, перестают их обновлять.
Возможно, им запрещают контракты? Юристы крупных компаний и их независимые подрядчики подтверждают, что разрешение на публикацию работы в портфолио получить непросто.
Сами дизайнеры не считают это главной проблемой. Чтобы пополнять портфолио, надо делать проекты (1), которые хочется показать (2) в портфолио (3).
1. В быстрорастущих компаниях дизайнеры много времени проводят на встречах, просто чтобы со всеми синхронизироваться. Скриншот забитого встречами календаря в портфолио не положить.
Дизайнер не создаёт в одиночку что-то своё, он делает вклад в развитие системы. Сложно выделить часть продукта и назвать её своей работой. Также часто приходится работать в стол.
2. Непонятно, что дизайнер получит от пополнения портфолио. Работа у него и так есть.
Интуитивные, функциональные, почти невидимые интерфейсы, сильно влияющие на людские жизни, не выглядят так же интересно, как книги, постеры, стулья или автомобили, где видна дизайнерская индивидуальность.
3. Пара сочных картинок не передаст контекста, целей и ограничений, с которыми работал дизайнер. Без них обсуждать результат нет смысла. Как лучше донести до читателя историю проекта — непонятно. Но в любом случае создание рассказа потребует сил и времени.
Твит о запуске продукта, статья с анализом нового процесса регистрации, лекция и даже патентная заявка могут сработать лучше, чем портфолио.
Ещё надо поддерживать актуальностью портфолио, которое в технологических компаниях быстро устаревает. Дизайн сегодняшнего релиза создан несколько месяцев назад, и через несколько месяцев может обновиться.
Нужны новые способы показать свою работу. Кейс с описанием дизайнерского вклада на каждом этапе создания продукта полезнее дюжины картинок. Лучшие работодатели оценивают дизайнера не только по тому, что он сделал, но и — как он мыслит.
[English] https://modus.medium.com/218bcbc11080
Medium
The Death of Design Portfolios
How Big Tech is changing the way designers show their work
Анна Данилова написала о тире. То, что мы обычно называем просто «тире», — это длинное тире.
В зависимости от убеждений дизайнера, технических возможностей и характеристик шрифта, тире отбивается межсловными пробелами, тонкими пробелами или не отбивается вовсе.
Если говорить о характеристиках шрифта, например, в Arial у тире нулевые полуапроши (расстояние от края кегельной площадки до крайней точки рисунка символа), в других — авторы сознательно закладывают большие полуапроши, чтобы не отбивать тире вовсе.
В вебе всё усложняется тем, что набирать пробелы разных толщин с клавиатуры нельзя. При копировании из текстового редактора многие платформы заменяют специальный пробел на обыкновенный межсловный. В соцсетях и вовсе не получится пользоваться специальными пробелами.
Исторически длинное тире делалось размером с прописную М (поэтому оно называется Em dash). Некоторые иностранные типографы считают его слишком длинным и не используют в тексте. В современных шрифтах у тире бывают разные пропорции, а некоторые шрифтовики делают несколько типов длинного тире — «устаревшее» длинное, более современное покороче и т. д.
Короткое тире (En dash) в современном русскоязычном наборе чаще всего используется для обозначения числовых диапазонов, например 1990–1998. В текстах на английском короткое тире используется в любом диапазоне, даже если он набирается словами: October–November. Короткое тире в таких ситуациях не отбивается пробелами.
По русским правилам вёрстки тире не переносится на следующую строку, кроме случаев с прямой речью. Если тире стоит в начале строки, по правилам корректуры — это прямая речь. Поэтому в тексте тире стоит отбивать слева неразрывным пробелом.
https://type.today/ru/journal/dash
В зависимости от убеждений дизайнера, технических возможностей и характеристик шрифта, тире отбивается межсловными пробелами, тонкими пробелами или не отбивается вовсе.
Если говорить о характеристиках шрифта, например, в Arial у тире нулевые полуапроши (расстояние от края кегельной площадки до крайней точки рисунка символа), в других — авторы сознательно закладывают большие полуапроши, чтобы не отбивать тире вовсе.
В вебе всё усложняется тем, что набирать пробелы разных толщин с клавиатуры нельзя. При копировании из текстового редактора многие платформы заменяют специальный пробел на обыкновенный межсловный. В соцсетях и вовсе не получится пользоваться специальными пробелами.
Исторически длинное тире делалось размером с прописную М (поэтому оно называется Em dash). Некоторые иностранные типографы считают его слишком длинным и не используют в тексте. В современных шрифтах у тире бывают разные пропорции, а некоторые шрифтовики делают несколько типов длинного тире — «устаревшее» длинное, более современное покороче и т. д.
Короткое тире (En dash) в современном русскоязычном наборе чаще всего используется для обозначения числовых диапазонов, например 1990–1998. В текстах на английском короткое тире используется в любом диапазоне, даже если он набирается словами: October–November. Короткое тире в таких ситуациях не отбивается пробелами.
По русским правилам вёрстки тире не переносится на следующую строку, кроме случаев с прямой речью. Если тире стоит в начале строки, по правилам корректуры — это прямая речь. Поэтому в тексте тире стоит отбивать слева неразрывным пробелом.
https://type.today/ru/journal/dash
Вадим Митякин написал об индустрии создания цифровых продуктов — первая глава будущей книги о продюсерском подходе.
Индустрия — это экосистема. Большинство проектов реализуется несколькими компаниями, командами и отдельными специалистами в симбиозе. Клиенты обращаются в компанию, которая нанимает себе в помощь продакшн для разработки и т. п.
Типовая производительность в час — полная профанация. Точная предварительная оценка проекта невозможна в принципе. Всё зависит от конкретного проекта и конкретного специалиста.
Типы проектов:
1. Мозги — решение ранее неизвестных задач. Проект похож на исследовательскую работу и привлечённые специалисты должны быть опытными профессионалами, имеющими сложившийся подход к поиску нестандартных решений.
2. Седина — внедрение проверенных отраслевых или технологических наработок, которыми обладает компания-подрядчик. Например, программа лояльности в розничной сети. Компании, работающие над такими проектами, специализируются на определённых отраслях.
3. Процедуры — типовые задачи, с которыми могут справиться различные специалисты с заданной квалификацией. Например, разработка программных компонентов по детальной спецификации в уже определённой технологической среде.
Слабые специалисты не вытянут проект типа «мозги». Если крутые будут делать слишком простые проекты, разработка будет слишком дорогой, а специалисты потеряют мотивацию и покинут компанию.
Типы исполнителей:
1. Фармацевт (самый распространённый) — классический аутсорсинг. Клиент приходит со сформулированной задачей, исполнитель через некоторое время выдаёт результат.
2. Сиделка — агентства. Исполнитель интенсивно общается с клиентом, работа выстроена вокруг долговременных целей клиента.
3. Нейрохирург — системные интеграторы и технологические исследовательские центры. Похоже на фармацевта, но часто сутью задачи является выяснение, в чём именно заключается проблема клиента и поиск её решения. У задач — преимущественно технологический характер.
4. Психотерапевт — продюсеры ИТ-проектов. Клиент обозначает проблемы в бизнесе или возможные точки развития, а исполнитель помогает подобрать наиболее удачный способ решения.
Бизнес-модели:
1. Ресурсная — продажа труда специалистов по часам или проектам. Компания должна продать как можно больше ресурсов, что неизбежно приводит к типу проектов «процедуры» и формату работы «фармацевт» или «сиделка». Клиент всегда может сменить подрядчика. Подрядчики конкурируют ценой, уровнем специалистов и качеством менеджмента.
2. Продажа уникальных знаний — цена услуги формируется не себестоимостью, а ценностью для клиентского бизнеса.
«Любая компания с регулярными расходами пытается добиться регулярного поступления оплат от клиентов. А они возможны в случае, когда команда специалистов как можно дольше работает над одним и тем же проектом, и её состав не меняется. Именно с этим связана любовь компаний-разработчиков к скраму, т. к. у проекта нет разных по стоимости этапов, команда максимально однородна и специалисты взаимозаменяемы. Работа над проектом разбита на равные отрезки времени — спринты, за которые удобно выставлять регулярные счета. Дело как обычно в деньгах, а вовсе не в каком-то волшебном качестве скрама».
«Настоящее проектирование в руках профессионалов — это инструмент, который даёт возможность точно целиться в бизнес-цели проекта и дальше решительно действовать. Оно сокращает бюджет и сроки проекта: вместо поисков в темноте наугад проектирование как фары автомобиля освещает дорогу, по которой движется проектная команда. Проектированию предшествует этап анализа бизнес-задачи клиента. Если задачи не сформулированы, то проектирование не даст результата. Также оно связывает разных участников экосистемы».
https://mityakin.ru/paranoid-method-book-1
Индустрия — это экосистема. Большинство проектов реализуется несколькими компаниями, командами и отдельными специалистами в симбиозе. Клиенты обращаются в компанию, которая нанимает себе в помощь продакшн для разработки и т. п.
Типовая производительность в час — полная профанация. Точная предварительная оценка проекта невозможна в принципе. Всё зависит от конкретного проекта и конкретного специалиста.
Типы проектов:
1. Мозги — решение ранее неизвестных задач. Проект похож на исследовательскую работу и привлечённые специалисты должны быть опытными профессионалами, имеющими сложившийся подход к поиску нестандартных решений.
2. Седина — внедрение проверенных отраслевых или технологических наработок, которыми обладает компания-подрядчик. Например, программа лояльности в розничной сети. Компании, работающие над такими проектами, специализируются на определённых отраслях.
3. Процедуры — типовые задачи, с которыми могут справиться различные специалисты с заданной квалификацией. Например, разработка программных компонентов по детальной спецификации в уже определённой технологической среде.
Слабые специалисты не вытянут проект типа «мозги». Если крутые будут делать слишком простые проекты, разработка будет слишком дорогой, а специалисты потеряют мотивацию и покинут компанию.
Типы исполнителей:
1. Фармацевт (самый распространённый) — классический аутсорсинг. Клиент приходит со сформулированной задачей, исполнитель через некоторое время выдаёт результат.
2. Сиделка — агентства. Исполнитель интенсивно общается с клиентом, работа выстроена вокруг долговременных целей клиента.
3. Нейрохирург — системные интеграторы и технологические исследовательские центры. Похоже на фармацевта, но часто сутью задачи является выяснение, в чём именно заключается проблема клиента и поиск её решения. У задач — преимущественно технологический характер.
4. Психотерапевт — продюсеры ИТ-проектов. Клиент обозначает проблемы в бизнесе или возможные точки развития, а исполнитель помогает подобрать наиболее удачный способ решения.
Бизнес-модели:
1. Ресурсная — продажа труда специалистов по часам или проектам. Компания должна продать как можно больше ресурсов, что неизбежно приводит к типу проектов «процедуры» и формату работы «фармацевт» или «сиделка». Клиент всегда может сменить подрядчика. Подрядчики конкурируют ценой, уровнем специалистов и качеством менеджмента.
2. Продажа уникальных знаний — цена услуги формируется не себестоимостью, а ценностью для клиентского бизнеса.
«Любая компания с регулярными расходами пытается добиться регулярного поступления оплат от клиентов. А они возможны в случае, когда команда специалистов как можно дольше работает над одним и тем же проектом, и её состав не меняется. Именно с этим связана любовь компаний-разработчиков к скраму, т. к. у проекта нет разных по стоимости этапов, команда максимально однородна и специалисты взаимозаменяемы. Работа над проектом разбита на равные отрезки времени — спринты, за которые удобно выставлять регулярные счета. Дело как обычно в деньгах, а вовсе не в каком-то волшебном качестве скрама».
«Настоящее проектирование в руках профессионалов — это инструмент, который даёт возможность точно целиться в бизнес-цели проекта и дальше решительно действовать. Оно сокращает бюджет и сроки проекта: вместо поисков в темноте наугад проектирование как фары автомобиля освещает дорогу, по которой движется проектная команда. Проектированию предшествует этап анализа бизнес-задачи клиента. Если задачи не сформулированы, то проектирование не даст результата. Также оно связывает разных участников экосистемы».
https://mityakin.ru/paranoid-method-book-1
Адам Сильвер написал о всплывающих подсказках (tooltip).
Подсказки отображаются, когда пользователь наводит курсор на определённые элементы интерфейса. Они объясняют, что означают эти элементы и как работает интерфейс.
Проблемы:
1. Пользователи не всегда замечают, что подсказки есть.
2. Пользователь должен что-то сделать, чтобы получить подсказку. Плохо, если в ней находятся, например, требования к паролю. Скорее всего, пользователю придётся их посмотреть.
3. Подсказки могут частично закрывать содержимое и элементы интерфейса. Чтобы заполнить поле, пользователю придётся запомнить текст подсказки.
4. Подсказки могут обрезаться на маленьких экранах.
5. Элементом, с которым пользователь взаимодействует для отображения подсказки, может быть иконка без подписи. В этом случае не всегда бывает понятно, как указать на этот элемент при голосовом взаимодействии с интерфейсом. «Нажми на колокол, нажми на уведомления…»
6. Отображение подсказки при наведении курсора — не самый удобный способ взаимодействия: курсора нет на тачскринах, ховер может быть отключен, сложно прицелиться, пользователь может навести курсор случайно, нельзя взаимодействовать с текстом подсказки (например, скопировать).
Решения:
1. Переделайте дизайн. Если для работы с интерфейсом пользователю нужны подсказки, это плохой интерфейс.
2. Подпишите иконки или замените их на текстовые ссылки.
3. Сделайте важные пояснения видимыми по умолчанию.
4. Для подсказок используйте inline toggle, который активируется кликом и не скрывает содержимое с элементами управления.
https://ux.pub/problemy-s-podskazkami-tooltips-kak-ih-razreshit/
Подсказки отображаются, когда пользователь наводит курсор на определённые элементы интерфейса. Они объясняют, что означают эти элементы и как работает интерфейс.
Проблемы:
1. Пользователи не всегда замечают, что подсказки есть.
2. Пользователь должен что-то сделать, чтобы получить подсказку. Плохо, если в ней находятся, например, требования к паролю. Скорее всего, пользователю придётся их посмотреть.
3. Подсказки могут частично закрывать содержимое и элементы интерфейса. Чтобы заполнить поле, пользователю придётся запомнить текст подсказки.
4. Подсказки могут обрезаться на маленьких экранах.
5. Элементом, с которым пользователь взаимодействует для отображения подсказки, может быть иконка без подписи. В этом случае не всегда бывает понятно, как указать на этот элемент при голосовом взаимодействии с интерфейсом. «Нажми на колокол, нажми на уведомления…»
6. Отображение подсказки при наведении курсора — не самый удобный способ взаимодействия: курсора нет на тачскринах, ховер может быть отключен, сложно прицелиться, пользователь может навести курсор случайно, нельзя взаимодействовать с текстом подсказки (например, скопировать).
Решения:
1. Переделайте дизайн. Если для работы с интерфейсом пользователю нужны подсказки, это плохой интерфейс.
2. Подпишите иконки или замените их на текстовые ссылки.
3. Сделайте важные пояснения видимыми по умолчанию.
4. Для подсказок используйте inline toggle, который активируется кликом и не скрывает содержимое с элементами управления.
https://ux.pub/problemy-s-podskazkami-tooltips-kak-ih-razreshit/
UXPUB 🇺🇦 Дизайн-спільнота
Проблемы с подсказками (tooltips), как их разрешить
Подсказки - это сообщения, которые появляются, когда пользователь наводит указатель мыши на определенную часть интерфейса
👍1
Евген Эсану прочитал обновлённую версию «Не заставляйте меня думать» Стива Круга и сформулировал рекомендации, которые могут пригодиться даже опытным дизайнерам.
1. Люди не читают, а сканируют. Дробите текст, выделяйте ключевые слова.
2. Создавайте явную визуальную иерархию. Делайте заметнее более важные объекты, группируйте связанные.
3. Не изобретайте колесо. Придерживайтесь сложившихся сценариев взаимодействия. Предлагая новое решение, прикиньте, во сколько (времени и усилий) обойдётся его внедрение.
4. Убирайте инструкции, интерфейс должен быть понятен без них. Если без инструкций не обойтись, смотрите пункт 1.
5. Учитывайте, что люди не знают, как работает ваш продукт, и не хотят разбираться.
6. Людям не так уж важны едва уловимые детали и эффекты в ваших продуктах. Убедитесь, что пользовательский сценарий полностью проработан, и полируйте дизайн после этого.
7. Не путайте фокус-группы и юзабилити-тесты. Первое — обмен мнениями и групповое обсуждение (например, продукта). Второе — наблюдение за человеком, который использует продукт.
8. Помните, что люди не похожи на вас. Принимая решения, не концентрируйтесь только на личных ощущениях.
9. Учитесь задавать правильные вопросы.
10. Пользователь не должен думать «где я», «с чего мне начать», «куда делось …», «что здесь самое важное», «почему они так назвали это», «это реклама или часть сайта?». Это отвлекает его от более важных вопросов: «Зачем я здесь» и «Что мне надо сделать».
В переводной статье почему-то нет ссылки на оригинал и даже его названия, так что стоит сослаться здесь:
— Перевод: https://usabilitylab.ru/blog/10-melkih-oshibok-v-dizajne-kotorye-my-po-prezhnemu-sovershaem/
— Оригинал: https://uxplanet.org/1cd5f60bc708
1. Люди не читают, а сканируют. Дробите текст, выделяйте ключевые слова.
2. Создавайте явную визуальную иерархию. Делайте заметнее более важные объекты, группируйте связанные.
3. Не изобретайте колесо. Придерживайтесь сложившихся сценариев взаимодействия. Предлагая новое решение, прикиньте, во сколько (времени и усилий) обойдётся его внедрение.
4. Убирайте инструкции, интерфейс должен быть понятен без них. Если без инструкций не обойтись, смотрите пункт 1.
5. Учитывайте, что люди не знают, как работает ваш продукт, и не хотят разбираться.
6. Людям не так уж важны едва уловимые детали и эффекты в ваших продуктах. Убедитесь, что пользовательский сценарий полностью проработан, и полируйте дизайн после этого.
7. Не путайте фокус-группы и юзабилити-тесты. Первое — обмен мнениями и групповое обсуждение (например, продукта). Второе — наблюдение за человеком, который использует продукт.
8. Помните, что люди не похожи на вас. Принимая решения, не концентрируйтесь только на личных ощущениях.
9. Учитесь задавать правильные вопросы.
10. Пользователь не должен думать «где я», «с чего мне начать», «куда делось …», «что здесь самое важное», «почему они так назвали это», «это реклама или часть сайта?». Это отвлекает его от более важных вопросов: «Зачем я здесь» и «Что мне надо сделать».
В переводной статье почему-то нет ссылки на оригинал и даже его названия, так что стоит сослаться здесь:
— Перевод: https://usabilitylab.ru/blog/10-melkih-oshibok-v-dizajne-kotorye-my-po-prezhnemu-sovershaem/
— Оригинал: https://uxplanet.org/1cd5f60bc708
Usabilitylab
Юзабилити лаборатория в Москве - Заказать юзабилити услуги в компании UsabilityLab
➜ Проектирование пользовательских интерфейсов, программ и веб-сайтов. ✔ Юзабилити-консалтинг, а также тестирование продукта. ★ Услуги лаборатории UsabilityLab. ☎ Звоните: +7 800 511-52-48
❤1
Наталья Стурза рассказала, когда продуктам полезны UX-исследования:
1. Проверить идею, не создавая продукта. Хотели запустить маркетплейс для пенсионеров. Исследование показало, что люди старше 60 лет спокойно пользуются обычными интернет-магазинами.
2. Исправить запустившийся, но не сработавший продукт. Сервис показывал карту спортивных мероприятий, но продвигался на аудиторию с низким доходом, продаж не было. Составили портреты потенциальных пользователей и провели с ними кастдев. В итоге сосредоточились на сегменте спортивных путешественников и правильно донесли до них ценность сервиса.
3. Улучшить то, что работает. Клиенты банка заполняли юридически значимое поле «Назначение платежа» всякой белибердой. Юзабилити-тесты показали, что люди считают поле второстепенным и заполняют только затем, чтобы кнопка платежа активировалась. В итоге в плейсхолдере поля показали пример, и таких ситуаций стало на 30% меньше.
4. Сравнить между собой конкурирующие продукты или отдельные фичи.
5. Понять, сколько потенциальные клиенты готовы платить.
6. Найти ошибку в интерфейсе.
Исследования не пригодятся:
1. Сервисам про фан вроде MSQRD и сервисам-витаминкам вроде приложений для медитации. У них сложно выделить пользовательскую потребность или проблему.
2. Любым проектам в ситуации «Мы хотим, чтобы вы пришли и сказали, как решить наши проблемы». В этом случае лучше обратиться к консалтерам.
https://vc.ru/design/86942
1. Проверить идею, не создавая продукта. Хотели запустить маркетплейс для пенсионеров. Исследование показало, что люди старше 60 лет спокойно пользуются обычными интернет-магазинами.
2. Исправить запустившийся, но не сработавший продукт. Сервис показывал карту спортивных мероприятий, но продвигался на аудиторию с низким доходом, продаж не было. Составили портреты потенциальных пользователей и провели с ними кастдев. В итоге сосредоточились на сегменте спортивных путешественников и правильно донесли до них ценность сервиса.
3. Улучшить то, что работает. Клиенты банка заполняли юридически значимое поле «Назначение платежа» всякой белибердой. Юзабилити-тесты показали, что люди считают поле второстепенным и заполняют только затем, чтобы кнопка платежа активировалась. В итоге в плейсхолдере поля показали пример, и таких ситуаций стало на 30% меньше.
4. Сравнить между собой конкурирующие продукты или отдельные фичи.
5. Понять, сколько потенциальные клиенты готовы платить.
6. Найти ошибку в интерфейсе.
Исследования не пригодятся:
1. Сервисам про фан вроде MSQRD и сервисам-витаминкам вроде приложений для медитации. У них сложно выделить пользовательскую потребность или проблему.
2. Любым проектам в ситуации «Мы хотим, чтобы вы пришли и сказали, как решить наши проблемы». В этом случае лучше обратиться к консалтерам.
https://vc.ru/design/86942
vc.ru
UX-исследования не решат всех ваших проблем — Дизайн на vc.ru
Иногда исследования — просто трата времени. Нужны ли они вам? Разбираем в кейсах.
Игорь Штанг рассказал о вёрстке иллюстраций.
Разместить фото автомобиля на пустом листе А4 можно сотней разных способов. Игорь рассказал, как отличить хорошую компоновку от плохой, подружить иллюстрацию с форматом и рассказать историю с помощью композиции.
02:27 — Неоднородность пустого листа;
03:22 — Верх-низ, право-лево, центр-периферия;
06:09 — Кручу машинку на формате;
13:32 — Кадрирование;
17:26 — Сюжетная и композиционная динамика;
21:38 — Реклама Фольксвагена Жука 1960-х;
28:13 — Удачное и неудачное кадрирование;
32:20 — С полями или без;
35:47 — Ракурс.
Смотреть лучше на скорости 1,25 или 1,5.
https://www.youtube.com/watch?v=4DxJ84yfoh4
Разместить фото автомобиля на пустом листе А4 можно сотней разных способов. Игорь рассказал, как отличить хорошую компоновку от плохой, подружить иллюстрацию с форматом и рассказать историю с помощью композиции.
02:27 — Неоднородность пустого листа;
03:22 — Верх-низ, право-лево, центр-периферия;
06:09 — Кручу машинку на формате;
13:32 — Кадрирование;
17:26 — Сюжетная и композиционная динамика;
21:38 — Реклама Фольксвагена Жука 1960-х;
28:13 — Удачное и неудачное кадрирование;
32:20 — С полями или без;
35:47 — Ракурс.
Смотреть лучше на скорости 1,25 или 1,5.
https://www.youtube.com/watch?v=4DxJ84yfoh4
YouTube
Верстка иллюстраций | Игорь Штанг | Prosmotr
Лекция «Верстка иллюстраций» Игоря Штанга, графического и веб-дизайнера, автора курса «Типографика и верстка».
Пустой лист бумаги кажется однородным, но на самом деле он имеет множество искажений. Представьте, что вам нужно поставить фотографию автомобиля…
Пустой лист бумаги кажется однородным, но на самом деле он имеет множество искажений. Представьте, что вам нужно поставить фотографию автомобиля…
В Usethics написали о том, как объединить подход персонажей и Jobs to be done.
JTBD описывает потребности пользователя по формуле: когда X, я хочу Y, чтобы Z. «Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z).
Во подходе персонажей первое место занимает персонаж: как Х, я хочу Y, чтобы Z. «Как турист (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)». Персонажи рассказывают о пользователях продукта, а «работы» сообщают об их ключевых целях.
Подходы можно объединить: установки влияют на вероятность возникновения разных ситуаций, а ситуации влияют на конкретный опыт. На верхнем уровне — персонажи (основные типы пользователей), затем — «работы» (задачи персонажей в рамках определённых обстоятельств), а в основании — конкретные переживания пользователя на разных этапах пути.
У приложения-будильника ключевая работа — проснуться и встать вовремя. Используя JTBD, при редизайне мы не фиксируемся на конкретном решении в виде будильника. Человек может попросить другого человека разбудить или лечь спать заранее, чтобы проснуться самостоятельно и т.п.
Объединённый подход:
1. Выделяем типы пользователей. Думаем, какие индивидуальные особенности могут повлиять на их опыт выполнения работы (базовые шкалы свойств персонажей). Например: соседство с другими в спальне. Выдвигаем гипотезы о персонажах, но не наделяем их социально-демографическими характеристиками.
2. Проводим интервью, где оцениваем участников с точки зрения выделенных свойств, узнаём контекст, делим работу на составляющие («подработы»). Например: Подготовка ко сну → Планирование подъёма утром → Засыпание → Сон → Пробуждение → Подъём. Это не обязательно должна быть последовательность.
3. На интервью выясняем ключевые потребности и цели участника на каждом этапе. Важно, почему человек совершает те или иные действия.
4. Анализируем результаты, подтверждаем гипотезы о базовых шкалах свойств и персонажах, конкретизируем ключевую работу для каждого из них.
5. Составляем карту пользовательского опыта для каждого персонажа. В ней могут быть слои опыта: цели/потребности, опасения, действия, барьеры, инструменты, эмоции.
6. Profit (выявляем инсайты о проектируемом продукте).
https://medium.com/usethics-doc/b35d4174cea3
JTBD описывает потребности пользователя по формуле: когда X, я хочу Y, чтобы Z. «Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z).
Во подходе персонажей первое место занимает персонаж: как Х, я хочу Y, чтобы Z. «Как турист (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)». Персонажи рассказывают о пользователях продукта, а «работы» сообщают об их ключевых целях.
Подходы можно объединить: установки влияют на вероятность возникновения разных ситуаций, а ситуации влияют на конкретный опыт. На верхнем уровне — персонажи (основные типы пользователей), затем — «работы» (задачи персонажей в рамках определённых обстоятельств), а в основании — конкретные переживания пользователя на разных этапах пути.
У приложения-будильника ключевая работа — проснуться и встать вовремя. Используя JTBD, при редизайне мы не фиксируемся на конкретном решении в виде будильника. Человек может попросить другого человека разбудить или лечь спать заранее, чтобы проснуться самостоятельно и т.п.
Объединённый подход:
1. Выделяем типы пользователей. Думаем, какие индивидуальные особенности могут повлиять на их опыт выполнения работы (базовые шкалы свойств персонажей). Например: соседство с другими в спальне. Выдвигаем гипотезы о персонажах, но не наделяем их социально-демографическими характеристиками.
2. Проводим интервью, где оцениваем участников с точки зрения выделенных свойств, узнаём контекст, делим работу на составляющие («подработы»). Например: Подготовка ко сну → Планирование подъёма утром → Засыпание → Сон → Пробуждение → Подъём. Это не обязательно должна быть последовательность.
3. На интервью выясняем ключевые потребности и цели участника на каждом этапе. Важно, почему человек совершает те или иные действия.
4. Анализируем результаты, подтверждаем гипотезы о базовых шкалах свойств и персонажах, конкретизируем ключевую работу для каждого из них.
5. Составляем карту пользовательского опыта для каждого персонажа. В ней могут быть слои опыта: цели/потребности, опасения, действия, барьеры, инструменты, эмоции.
6. Profit (выявляем инсайты о проектируемом продукте).
https://medium.com/usethics-doc/b35d4174cea3
Medium
Персонажи + Jobs-to-Be-Done: опыт применения объединенного подхода
Когда одного фреймворка недостаточно.
👍1
Эмилия Городовых рассказала о применении JTBD в сложном продукте.
Диадок — сервис для обмена документами между организациями (с электронной подписью).
Решили использовать JTBD из-за проблемы: продукт менялся в основном с подачи крупных клиентов, т.к. их требования легко превращались в бизнес-метрики. Требования мелких клиентов просачивались в продукт только вместе с результатами внутренних юзабилити-тестов.
Термин «работа» заменили на «задачу», чтобы было проще разговаривать с клиентами. Они плохо понимали вопрос: «Для какой работы вы нанимаете Диадок?»
Юзабилити-тест показал: плохо работает расширенный поиск. С ним сталкиваются мелкие клиенты, работающие через сайт. Крупные клиенты работают в своих программах, интегрированных с Диадоком.
Оказалось сложно работать по формуле «Контекст — Мотив — Результат», решили её перевернуть и начинать с результата.
Пользователю надо подписать все входящие закрывающие документы по сделкам в этом месяце. Результат — закрыть сделки с клиентами. Мотив — чтобы компания получила деньги, а руководитель был им доволен. Контекст — сведения о том, как часто возникает эта задача, как пользователь о ней узнаёт, может ли её отложить и т.п.
Исследование дало слишком много данных для одной формулы. Поняли, что задача может состоять из подзадач, например:
1. Подготовка. Получить список документов для подписания. Выявленная проблема связана с этой подзадачей, т.к. не все пользователи знали про расширенный поиск и как работают его поля.
2. Выполнение. Проверить правильность документов и подписать их.
3. Отслеживание. Понять, все ли документы подписаны.
4. Завершение. Удостовериться, что компания получила все деньги вовремя. Если пришли не все деньги, понять, почему.
Ранжировали подзадачи по критериям: а) важность, б) доволен ли сейчас клиент, работающий над подзадачей. То, что важно и работает, надо не сломать. Что важно и не работает, надо починить. Остальное — нишевые подзадачи.
Расширенный поиск важен, а пользователи им недовольны. Чтобы перевести всё на уровень бизнес-метрик, посчитали количество пользователей и трафик документов, наложили цифры на контекст общей задачи (закрыть сделки). Получили оценку риска оттока пользователей, которые с ней не справляются.
В итоге получилось не просто устранение боли, а удержание конкретного количества пользователей в продукте.
https://www.youtube.com/watch?v=bc4OUnp7vdg
Диадок — сервис для обмена документами между организациями (с электронной подписью).
Решили использовать JTBD из-за проблемы: продукт менялся в основном с подачи крупных клиентов, т.к. их требования легко превращались в бизнес-метрики. Требования мелких клиентов просачивались в продукт только вместе с результатами внутренних юзабилити-тестов.
Термин «работа» заменили на «задачу», чтобы было проще разговаривать с клиентами. Они плохо понимали вопрос: «Для какой работы вы нанимаете Диадок?»
Юзабилити-тест показал: плохо работает расширенный поиск. С ним сталкиваются мелкие клиенты, работающие через сайт. Крупные клиенты работают в своих программах, интегрированных с Диадоком.
Оказалось сложно работать по формуле «Контекст — Мотив — Результат», решили её перевернуть и начинать с результата.
Пользователю надо подписать все входящие закрывающие документы по сделкам в этом месяце. Результат — закрыть сделки с клиентами. Мотив — чтобы компания получила деньги, а руководитель был им доволен. Контекст — сведения о том, как часто возникает эта задача, как пользователь о ней узнаёт, может ли её отложить и т.п.
Исследование дало слишком много данных для одной формулы. Поняли, что задача может состоять из подзадач, например:
1. Подготовка. Получить список документов для подписания. Выявленная проблема связана с этой подзадачей, т.к. не все пользователи знали про расширенный поиск и как работают его поля.
2. Выполнение. Проверить правильность документов и подписать их.
3. Отслеживание. Понять, все ли документы подписаны.
4. Завершение. Удостовериться, что компания получила все деньги вовремя. Если пришли не все деньги, понять, почему.
Ранжировали подзадачи по критериям: а) важность, б) доволен ли сейчас клиент, работающий над подзадачей. То, что важно и работает, надо не сломать. Что важно и не работает, надо починить. Остальное — нишевые подзадачи.
Расширенный поиск важен, а пользователи им недовольны. Чтобы перевести всё на уровень бизнес-метрик, посчитали количество пользователей и трафик документов, наложили цифры на контекст общей задачи (закрыть сделки). Получили оценку риска оттока пользователей, которые с ней не справляются.
В итоге получилось не просто устранение боли, а удержание конкретного количества пользователей в продукте.
https://www.youtube.com/watch?v=bc4OUnp7vdg
YouTube
Эмилия Городовых, СКБ Контур "Опыт применения JTBD на примере сложного продукта"
Выступление Эмилии Городых, UX-исследователь в СКБ Контур на онлайн-конференции UX-Марафон #14 "Проектирование сложных систем".
Эмиллия о своем выступление:
Расскажу наш опыт применения Jobs To Be Done на примере большого сложного продукта, в котором конкурируют…
Эмиллия о своем выступление:
Расскажу наш опыт применения Jobs To Be Done на примере большого сложного продукта, в котором конкурируют…
Эдвард Скотт написал о сравнении товаров в интернет-магазине.
Прежде, чем добавить эту функцию:
1. Проверьте, что у вас есть данные о параметрах товаров и что они структурированы, то есть, например, размеры не указаны то в сантиметрах, то в миллиметрах.
2. Попробуйте изменить список товаров так, чтобы в сравнении пропала необходимость. Например, покажите в списке сумок для ноутбуков ключевой параметр — максимальную диагональ ноутбука.
3. Выберите категории товаров, которым точно нужна возможность сравнения. Например, бытовые приборы и электроника. Особенно, если ваша основная аудитория — эксперты или профессионалы, которые умеют интерпретировать важные параметры товаров и методично их сравнивать.
Если вы уже добавили:
1. В десктопной версии в списке товаров показывайте контрол «Сравнить» при наведении курсора на карточку товара. Большинству он не нужен, нет смысла отображать его по умолчанию. Тот, кто хочет внимательно изучить товары, обратит внимание на появление контрола.
2. При наведении курсора на контрол «Сравнить» показывайте подсказку с кратким пояснением: что это за инструмент и как он работает. Так его не примут за функцию сравнения цен с другими магазинами.
3. Дайте легко перейти к сравнению выбранных товаров. Например, отобразите панель с кнопкой «Сравнить выбранные товары» и миниатюрами этих товаров, прикреплённую к нижней или верхней границе окна браузера.
https://ux.pub/ux-rekomendatsii-po-uluchsheniyu-instrumenta-sravnenie-tovarov/
Прежде, чем добавить эту функцию:
1. Проверьте, что у вас есть данные о параметрах товаров и что они структурированы, то есть, например, размеры не указаны то в сантиметрах, то в миллиметрах.
2. Попробуйте изменить список товаров так, чтобы в сравнении пропала необходимость. Например, покажите в списке сумок для ноутбуков ключевой параметр — максимальную диагональ ноутбука.
3. Выберите категории товаров, которым точно нужна возможность сравнения. Например, бытовые приборы и электроника. Особенно, если ваша основная аудитория — эксперты или профессионалы, которые умеют интерпретировать важные параметры товаров и методично их сравнивать.
Если вы уже добавили:
1. В десктопной версии в списке товаров показывайте контрол «Сравнить» при наведении курсора на карточку товара. Большинству он не нужен, нет смысла отображать его по умолчанию. Тот, кто хочет внимательно изучить товары, обратит внимание на появление контрола.
2. При наведении курсора на контрол «Сравнить» показывайте подсказку с кратким пояснением: что это за инструмент и как он работает. Так его не примут за функцию сравнения цен с другими магазинами.
3. Дайте легко перейти к сравнению выбранных товаров. Например, отобразите панель с кнопкой «Сравнить выбранные товары» и миниатюрами этих товаров, прикреплённую к нижней или верхней границе окна браузера.
https://ux.pub/ux-rekomendatsii-po-uluchsheniyu-instrumenta-sravnenie-tovarov/
UXPUB 🇺🇦 Дизайн-спільнота
UX-рекомендации по улучшению инструмента «Сравнение товаров»
Не всем сайтам нужен подобный инструмент, но, в определенных отраслях, он может быть невероятно полезен
Опубликованы записи докладов с Design Prosmotr 2019 (март, апрель).
1. Артур Арсёнов, Looi — Темная сторона продуктового дизайна
youtube.com/watch?v=B3oq4VDYbMA
2. Ноу Нейм, UX Live — UX 2077
youtube.com/watch?v=hfNN02_VYH8
3. Владимир Шрейдер, Glitché — Glitché. Ошибки поколения
youtube.com/watch?v=3Ft3cNaYTtU
4. Максим Ильяхов, Главред — Ваша последняя лекция про текст
youtube.com/watch?v=_jwKQ6ZCeAI
5. Роман Горбачёв, Логомашина — 10 инсайтов из 10 000 звонков
youtube.com/watch?v=B-zXiApNzbI
6. Александр Загорский, BBDO Branding — Я дизайнер. Зачем я это делаю?
youtube.com/watch?v=SoJGlftony0
7. Николай Хлопков, Whitemark — Бизнес и творчество в балансе
youtube.com/watch?v=o_CsjZqgun8
8. Юрий Ветров, Mail.Ru Group — Дайджест продуктового дизайна
youtube.com/watch?v=_bMlwh4xgdY
9. Игорь Штанг, Типографика и верстка — Верстка иллюстраций (было недавно в UX Notes)
youtube.com/watch?v=4DxJ84yfoh4
10. Вениамин Векк, М18 — Смотреть, ворчать и умнеть
youtube.com/watch?v=YXNp_F6XmYc
В одном альбоме ВК: vk.com/videos-50773057?section=album_33
1. Артур Арсёнов, Looi — Темная сторона продуктового дизайна
youtube.com/watch?v=B3oq4VDYbMA
2. Ноу Нейм, UX Live — UX 2077
youtube.com/watch?v=hfNN02_VYH8
3. Владимир Шрейдер, Glitché — Glitché. Ошибки поколения
youtube.com/watch?v=3Ft3cNaYTtU
4. Максим Ильяхов, Главред — Ваша последняя лекция про текст
youtube.com/watch?v=_jwKQ6ZCeAI
5. Роман Горбачёв, Логомашина — 10 инсайтов из 10 000 звонков
youtube.com/watch?v=B-zXiApNzbI
6. Александр Загорский, BBDO Branding — Я дизайнер. Зачем я это делаю?
youtube.com/watch?v=SoJGlftony0
7. Николай Хлопков, Whitemark — Бизнес и творчество в балансе
youtube.com/watch?v=o_CsjZqgun8
8. Юрий Ветров, Mail.Ru Group — Дайджест продуктового дизайна
youtube.com/watch?v=_bMlwh4xgdY
9. Игорь Штанг, Типографика и верстка — Верстка иллюстраций (было недавно в UX Notes)
youtube.com/watch?v=4DxJ84yfoh4
10. Вениамин Векк, М18 — Смотреть, ворчать и умнеть
youtube.com/watch?v=YXNp_F6XmYc
В одном альбоме ВК: vk.com/videos-50773057?section=album_33
YouTube
Темная сторона продуктового дизайна | Артур Арсёнов | Prosmotr
Лекция «Темная сторона продуктового дизайна» Артура Арсёнова, основателя и арт-директора Looi.
По мнению Артура уже не модно быть графическим, веб или UX-дизайнером — настало время продуктового дизайна. Сегодня каждый может называть себя продуктовым дизайнером…
По мнению Артура уже не модно быть графическим, веб или UX-дизайнером — настало время продуктового дизайна. Сегодня каждый может называть себя продуктовым дизайнером…
Игорь Штанг написал об использовании буллита как маркера в списке.
До 1990-х годов в русской типографике не было буллитов. Они пришли из американского набора с программами вроде Ворда и Поверпоинта. По умолчанию у последнего были такие настройки, с которыми не ставить буллиты было труднее, чем ставить.
В чем проблема: это единственный жирный символ в кириллице. В некоторых жанрах верстки сильные текстовые выделения считаются дурным тоном. Буллит выбивается из серой ткани набора и иногда даже больше напоминает иконку, чем знак препинания.
Как быть: в качестве маркера списка для кириллического набора использовать длинное тире.
Если надо использовать буллит:
1. Искусственно уменьшить кружок в полтора-два раза. Так он не будет жирнить. В некоторых шрифтах символ сам по себе небольшой.
2. Сделать буллит цветным или серым.
3. Оставить как есть или даже увеличить, но поддержать другими жирными элементами. Смотрите пример из книги Ласло Мохой-Надя «Живопись. Фотография. Кино», 1927.
https://nobelfaik.livejournal.com/199470.html
До 1990-х годов в русской типографике не было буллитов. Они пришли из американского набора с программами вроде Ворда и Поверпоинта. По умолчанию у последнего были такие настройки, с которыми не ставить буллиты было труднее, чем ставить.
В чем проблема: это единственный жирный символ в кириллице. В некоторых жанрах верстки сильные текстовые выделения считаются дурным тоном. Буллит выбивается из серой ткани набора и иногда даже больше напоминает иконку, чем знак препинания.
Как быть: в качестве маркера списка для кириллического набора использовать длинное тире.
Если надо использовать буллит:
1. Искусственно уменьшить кружок в полтора-два раза. Так он не будет жирнить. В некоторых шрифтах символ сам по себе небольшой.
2. Сделать буллит цветным или серым.
3. Оставить как есть или даже увеличить, но поддержать другими жирными элементами. Смотрите пример из книги Ласло Мохой-Надя «Живопись. Фотография. Кино», 1927.
https://nobelfaik.livejournal.com/199470.html
Livejournal
Тире или буллит
В эфире рубрика ??? . Мария спрашивает: Какие маркеры ставить в списках на русском языке: тире или буллиты? Вопрос непростой, поэтому начну издалека. История До 1990-х годов в русской типографике не было буллитов. Вы не найдете их ни в советских, ни в дореволюционных…
Дима Хими написал о неправильном примере Job story в статье Usethics про объединение подхода персонажей и Jobs to be done. (Было недавно в UX Notes.)
Из-за такого примера может возникнуть ощущение, что JTBD не закрывает все аспекты. Это может вызвать необоснованные претензии к подходу.
«Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)» — неправильная Job story, так как решение зеркалирует проблему и содержит в себе точное её решение. Мы сразу представляем себе навигатор.
Правильнее было бы написать так: «Когда мне нужно добраться из точки А в точку Б в требуемое время, я хочу понять, каким способом мне нужно это сделать, чтобы чувствовать, что я добрался до места оптимальным путём».
Тогда совсем не важно, к кому будет применима эта история: к человеку, который сидит у компьютера и только планирует путешествие, или к тому, кто уже находится в точке А и думает, как ему добраться до точки Б.
И решения могут быть совершенно разные: от конструктора маршрутов и службы частных проводников до бесконечности.
С другой стороны, использование «слабо выраженных персон» иногда всё же необходимо. Например, когда вы хотите сами явно разделить типы пользователей и их задачи или проблемы.
Я использую тут термин «роль». Для торгового центра можно разделить посетителей и работников, для интернет-магазина — пользователей и разработчиков, для служб такси — водителей и пассажиров (хотя каршеринг уже несколько подвергает сомнению такое разделение).
— Пост Димы: facebook.com/dimahimi/posts/2416057165179001
— Статья Usethics: t.me/uxnotes/505
Из-за такого примера может возникнуть ощущение, что JTBD не закрывает все аспекты. Это может вызвать необоснованные претензии к подходу.
«Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)» — неправильная Job story, так как решение зеркалирует проблему и содержит в себе точное её решение. Мы сразу представляем себе навигатор.
Правильнее было бы написать так: «Когда мне нужно добраться из точки А в точку Б в требуемое время, я хочу понять, каким способом мне нужно это сделать, чтобы чувствовать, что я добрался до места оптимальным путём».
Тогда совсем не важно, к кому будет применима эта история: к человеку, который сидит у компьютера и только планирует путешествие, или к тому, кто уже находится в точке А и думает, как ему добраться до точки Б.
И решения могут быть совершенно разные: от конструктора маршрутов и службы частных проводников до бесконечности.
С другой стороны, использование «слабо выраженных персон» иногда всё же необходимо. Например, когда вы хотите сами явно разделить типы пользователей и их задачи или проблемы.
Я использую тут термин «роль». Для торгового центра можно разделить посетителей и работников, для интернет-магазина — пользователей и разработчиков, для служб такси — водителей и пассажиров (хотя каршеринг уже несколько подвергает сомнению такое разделение).
— Пост Димы: facebook.com/dimahimi/posts/2416057165179001
— Статья Usethics: t.me/uxnotes/505
Telegram
UX Notes
В Usethics написали о том, как объединить подход персонажей и Jobs to be done.
JTBD описывает потребности пользователя по формуле: когда X, я хочу Y, чтобы Z. «Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти…
JTBD описывает потребности пользователя по формуле: когда X, я хочу Y, чтобы Z. «Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти…
Никита Вознесенский написал о макетировании книги.
Макет — набор величин, используемых в издании. Чтобы книга выглядела аккуратно, нужно сделать макет издания. Так можно избежать необдуманных, произвольных размеров: кегля шрифта, длины строки, отбивок между блоками текста, размеров полей и т. д.
Книжное макетирование отличается использованием красивых чисел, т. е. пропорций, которые могут быть рациональными (например, 3:4) и иррациональными (1:1,618).
Макет состоит из прямоугольников, такова природа оформления текста. Если поделить высоту одного из прямоугольников на его ширину, получится соотношение. Принято считать, что созерцание пропорциональных прямоугольников приятно глазу. Читая хорошо смакетированную книгу, мы видим тихую, неотвлекающую музыку пропорций.
С чем работает дизайнер книги:
1. Литера — отдельная буква или знак шрифта. Уже в ней есть пропорция — отношение высоты строчных букв к высоте прописных. Зная её и приняв кегль (размер шрифта) основного текста за единицу, можно назначить непроизвольные размеры шрифта дополнительного текста и разных уровней заголовков.
2. Строка. Надо гармонизировать соотношение белого внутри литер (внутрибуквенные просветы) с белым вокруг литер (межбуквенные пробелы). Здесь сложно говорить об измеримых пропорциях, действовать приходится на глаз.
3. Полоса. Надо назначить полосе какую-либо пропорцию, а также выбрать пробелы внутри неё: горизонтальные (например, абзацный отступ) и вертикальные (отбивка над и под заголовками).
4. Страница. Надо установить размеры страницы, а также пробелов вокруг полосы (полей).
Журнальный подход диктует порядок макетирования от формата издания к размеру шрифта, который губителен для книги, т. к. приводит к использованию типовых, повторяющихся из раза в раз абсолютных величин. Красота книги — в разнообразии её деталей, в том, что рисунок разных книжных шрифтов влечёт за собой различную гамму пропорций и размеров.
Дизайнеру книги следует стремиться проектировать макет изнутри наружу.
https://medium.com/nikve/e544f3ddd134
Макет — набор величин, используемых в издании. Чтобы книга выглядела аккуратно, нужно сделать макет издания. Так можно избежать необдуманных, произвольных размеров: кегля шрифта, длины строки, отбивок между блоками текста, размеров полей и т. д.
Книжное макетирование отличается использованием красивых чисел, т. е. пропорций, которые могут быть рациональными (например, 3:4) и иррациональными (1:1,618).
Макет состоит из прямоугольников, такова природа оформления текста. Если поделить высоту одного из прямоугольников на его ширину, получится соотношение. Принято считать, что созерцание пропорциональных прямоугольников приятно глазу. Читая хорошо смакетированную книгу, мы видим тихую, неотвлекающую музыку пропорций.
С чем работает дизайнер книги:
1. Литера — отдельная буква или знак шрифта. Уже в ней есть пропорция — отношение высоты строчных букв к высоте прописных. Зная её и приняв кегль (размер шрифта) основного текста за единицу, можно назначить непроизвольные размеры шрифта дополнительного текста и разных уровней заголовков.
2. Строка. Надо гармонизировать соотношение белого внутри литер (внутрибуквенные просветы) с белым вокруг литер (межбуквенные пробелы). Здесь сложно говорить об измеримых пропорциях, действовать приходится на глаз.
3. Полоса. Надо назначить полосе какую-либо пропорцию, а также выбрать пробелы внутри неё: горизонтальные (например, абзацный отступ) и вертикальные (отбивка над и под заголовками).
4. Страница. Надо установить размеры страницы, а также пробелов вокруг полосы (полей).
Журнальный подход диктует порядок макетирования от формата издания к размеру шрифта, который губителен для книги, т. к. приводит к использованию типовых, повторяющихся из раза в раз абсолютных величин. Красота книги — в разнообразии её деталей, в том, что рисунок разных книжных шрифтов влечёт за собой различную гамму пропорций и размеров.
Дизайнеру книги следует стремиться проектировать макет изнутри наружу.
https://medium.com/nikve/e544f3ddd134
Medium
Введение в макетирование книги
Макет — это набор величин, используемых в издании.
Мария Росала написала, как правильно работать с пользовательскими интервью.
1. С их помощью нельзя получить ответы на некоторые вопросы. Например: какие функции нужны людям в продукте — этот вопрос может быть обоснованием для исследования в целом. Интервью подойдёт, если вы хотите понять мысли людей, впечатления или восприятие опыта.
2. Стейкхолдеры могут не знать, чем отличаются разные методы исследования. Из-за этого — не выделять время на интервью в начале проекта и скептически воспринимать инсайты.
— Объясните выбор этого метода исследования.
— Дайте поучаствовать в подготовке: расставить приоритеты в вопросах, предложить свои. Вместе проранжируйте вопросы по важности.
3. Без планирования в интервью могут оказаться плохие, наводящие и закрытые вопросы. В лучшем случае это приведёт к поверхностным выводам.
— Поймите, что вы хотите узнать.
— Заранее сформулируйте вопросы, чтобы направлять интервью.
— Подготовьте общие вопросы, чтобы узнать больше о проблемном месте или опыте. Например: «Опишите типичный день, когда…».
— Подготовьте наводящие вопросы. Например: «Можете ли вы привести пример?».
— Проведите пилотное интервью и исправьте по итогам список вопросов.
— При планировании встреч с респондентами учитывайте, что интервью выматывает.
4. В отчёте могут оказаться только запоминающиеся идеи и личные предубеждения интервьюера.
— Делайте аудиозаписи интервью.
— Переводите аудиозаписи в текст.
— Просите команду прочитать транскрипты и выделить важные отрывки.
https://vc.ru/design/86929
1. С их помощью нельзя получить ответы на некоторые вопросы. Например: какие функции нужны людям в продукте — этот вопрос может быть обоснованием для исследования в целом. Интервью подойдёт, если вы хотите понять мысли людей, впечатления или восприятие опыта.
2. Стейкхолдеры могут не знать, чем отличаются разные методы исследования. Из-за этого — не выделять время на интервью в начале проекта и скептически воспринимать инсайты.
— Объясните выбор этого метода исследования.
— Дайте поучаствовать в подготовке: расставить приоритеты в вопросах, предложить свои. Вместе проранжируйте вопросы по важности.
3. Без планирования в интервью могут оказаться плохие, наводящие и закрытые вопросы. В лучшем случае это приведёт к поверхностным выводам.
— Поймите, что вы хотите узнать.
— Заранее сформулируйте вопросы, чтобы направлять интервью.
— Подготовьте общие вопросы, чтобы узнать больше о проблемном месте или опыте. Например: «Опишите типичный день, когда…».
— Подготовьте наводящие вопросы. Например: «Можете ли вы привести пример?».
— Проведите пилотное интервью и исправьте по итогам список вопросов.
— При планировании встреч с респондентами учитывайте, что интервью выматывает.
4. В отчёте могут оказаться только запоминающиеся идеи и личные предубеждения интервьюера.
— Делайте аудиозаписи интервью.
— Переводите аудиозаписи в текст.
— Просите команду прочитать транскрипты и выделить важные отрывки.
https://vc.ru/design/86929
vc.ru
Почему пользовательские интервью не работают
Перевод статьи исследовательницы Марии Росала для Nielsen Norman Group.
Ольга Коновалова написала, что в «СКБ Контуре» ожидают от начинающего проектировщика. К вопросу о том, какие пригодятся софт-скилы.
1. Умение объяснять свои решения. Вашим коллегам надо понять, почему надо делать именно так, а не иначе. Никто не хочет делать фигню. Чтобы помочь вам, они могут предложить альтернативные решения.
2. Умение задавать вопросы, слушать и договариваться. Задача не решена, пока все не сошлись на одном решении. Плохо, когда кто-то говорит «я не согласен, но делайте, что хотите».
3. Критическое мышление, чтобы докапываться до сути и решать задачи качественнее. Нормально, если вам не нравятся ваши старые решения. Не ленитесь придираться к своим решениям.
4. Здоровое отношение к критике. Не бойтесь показывать свои работы и не избегайте критики.
5. Неравнодушие. Если видите что-то неправильное (в интерфейсе, общении, процессе) — скажите и предложите возможное решение.
6. Самостоятельность, способность сориентироваться, с чего начать, кому задать вопросы по задаче, как построить свою работу.
7. Способность представить себе алгоритм решения задачи. С этим помогут готовые чеклисты.
8. Способность найти разные варианты решения одной задачи. Надо понять их плюсы и минусы, выбирать лучшее и отстаивать его.
https://medium.com/designkontur/cd756a4a4694
1. Умение объяснять свои решения. Вашим коллегам надо понять, почему надо делать именно так, а не иначе. Никто не хочет делать фигню. Чтобы помочь вам, они могут предложить альтернативные решения.
2. Умение задавать вопросы, слушать и договариваться. Задача не решена, пока все не сошлись на одном решении. Плохо, когда кто-то говорит «я не согласен, но делайте, что хотите».
3. Критическое мышление, чтобы докапываться до сути и решать задачи качественнее. Нормально, если вам не нравятся ваши старые решения. Не ленитесь придираться к своим решениям.
4. Здоровое отношение к критике. Не бойтесь показывать свои работы и не избегайте критики.
5. Неравнодушие. Если видите что-то неправильное (в интерфейсе, общении, процессе) — скажите и предложите возможное решение.
6. Самостоятельность, способность сориентироваться, с чего начать, кому задать вопросы по задаче, как построить свою работу.
7. Способность представить себе алгоритм решения задачи. С этим помогут готовые чеклисты.
8. Способность найти разные варианты решения одной задачи. Надо понять их плюсы и минусы, выбирать лучшее и отстаивать его.
https://medium.com/designkontur/cd756a4a4694
Medium
1. Начинающему проектировщику
Серия заметок о том, на чем стоит фокусироваться новому проектировщику, чтобы не растеряться в начале работы
Бывший издатель «Медузы» Илья Красильщик рассказал, что понял после перехода в фудтек-проект «Яндекс Лавка».
1. Непонятно, как сделать правильно.
В обычных магазинах продукты выкладывают по принципу: приехали 7 видов чипсов Pringles, ты их выложил рядом на одну полку. Так нельзя делать в магазине нашего формата.
У нас сборщик получает задание «возьми красный Pringles», он прибегает, на полке стоит 7 видов Pringles, он ищет, что конкретно нужно взять. Это занимает минуту времени.
В магазине без покупателей всё похожее должно быть максимально далеко друг от друга. Сотрудник должен собирать заказ максимально быстро.
2. Хороший продукт не просто работает, а удивляет.
Чтобы сделать хороший продукт, надо понять собственного пользователя, его желания, эмоции, проблемы, как он будет этим пользоваться, поставить себя на его место.
Почему время доставки именно 15 минут, а не 30? Потому что это удивляет человека. Причём это максимальное время, а среднее может быть 8 минут.
Люди не знали, а тут оказалось, что это возможно. Это отличительная черта новых сервисов и услуг, которых люди раньше не видели. Когда вы удивляете, вам прощают ошибки.
3. Приходится многое перепридумывать.
Люди, которые понимают, что такое «бакалея», оскорбляются, когда говоришь, что никто этого не знает. Вторая же половина людей и правда не знает значения этого слова. И таких слов много: галантерея, бижутерия и так далее.
Сборщик должен собрать заказ за короткое время. Норматив — 20 секунд на товар. Есть приложение, которое говорит, что надо собрать и выстраивает маршрут между полками.
Есть нюансы:
— Если надо взять 5-литровую канистру воды и ещё 10 товаров, маршрут сборщика должен быть таким, чтобы канистру он взял последней.
— Надо понимать, что на что нельзя ставить, что бытовую химию нельзя класть с продуктами.
— Важно понимать, что люди покупают чаще, а что реже. Частые товары должны быть ближе к пункту выдачи, чтобы за ними не бегать.
— В обычных магазинах на кассы кладут шоколадки. В жизни люди их редко покупают, а воду — чаще. Поэтому шоколадки нужно класть в самый конец, а пятилитровки — ближе.
4. Хочется положиться на показатели.
Когда начинаете что-то новое, вам страшно. Тогда вы хотите положиться на показатели. Это важно. Но понимание чувств аудитории, понимание себя и собственных потребностей сильно помогает делать продукт.
https://vc.ru/food/89580
1. Непонятно, как сделать правильно.
В обычных магазинах продукты выкладывают по принципу: приехали 7 видов чипсов Pringles, ты их выложил рядом на одну полку. Так нельзя делать в магазине нашего формата.
У нас сборщик получает задание «возьми красный Pringles», он прибегает, на полке стоит 7 видов Pringles, он ищет, что конкретно нужно взять. Это занимает минуту времени.
В магазине без покупателей всё похожее должно быть максимально далеко друг от друга. Сотрудник должен собирать заказ максимально быстро.
2. Хороший продукт не просто работает, а удивляет.
Чтобы сделать хороший продукт, надо понять собственного пользователя, его желания, эмоции, проблемы, как он будет этим пользоваться, поставить себя на его место.
Почему время доставки именно 15 минут, а не 30? Потому что это удивляет человека. Причём это максимальное время, а среднее может быть 8 минут.
Люди не знали, а тут оказалось, что это возможно. Это отличительная черта новых сервисов и услуг, которых люди раньше не видели. Когда вы удивляете, вам прощают ошибки.
3. Приходится многое перепридумывать.
Люди, которые понимают, что такое «бакалея», оскорбляются, когда говоришь, что никто этого не знает. Вторая же половина людей и правда не знает значения этого слова. И таких слов много: галантерея, бижутерия и так далее.
Сборщик должен собрать заказ за короткое время. Норматив — 20 секунд на товар. Есть приложение, которое говорит, что надо собрать и выстраивает маршрут между полками.
Есть нюансы:
— Если надо взять 5-литровую канистру воды и ещё 10 товаров, маршрут сборщика должен быть таким, чтобы канистру он взял последней.
— Надо понимать, что на что нельзя ставить, что бытовую химию нельзя класть с продуктами.
— Важно понимать, что люди покупают чаще, а что реже. Частые товары должны быть ближе к пункту выдачи, чтобы за ними не бегать.
— В обычных магазинах на кассы кладут шоколадки. В жизни люди их редко покупают, а воду — чаще. Поэтому шоколадки нужно класть в самый конец, а пятилитровки — ближе.
4. Хочется положиться на показатели.
Когда начинаете что-то новое, вам страшно. Тогда вы хотите положиться на показатели. Это важно. Но понимание чувств аудитории, понимание себя и собственных потребностей сильно помогает делать продукт.
https://vc.ru/food/89580
vc.ru
Что узнал о себе, медиа и рынке Илья Красильщик, перейдя из «Медузы» в «Яндекс.Лавку»
Конспект его лекции «Из медузы в арбузы» с форума Design Prosmotr.
Наталья Стурза рассказала, что на сайтах российских банков мешает клиентам (предпринимателям) выбрать оптимальный тариф.
Тёмные паттерны и просто плохой дизайн:
1. Важные условия и ограничения написаны мелко и малоконтрастно, чтобы человек не обратил на них внимания.
2. Тарифам даны эмоциональные названия. Например, тариф «Успех» (подороже) и «Лоукост» (самый дешёвый).
3. Некоторые важные условия тарифа есть только в огромном документе со всеми условиями. Например, показаны только лимиты, но не показано, что будет после их превышения.
4. Сломана привычная логика отображения информации. Например, показаны сначала свойства тарифа, а потом стоимость. Или показаны тарифы слева направо от большей стоимости к меньшей.
5. Общие формулировки и канцеляризмы.
6. Все тарифы показаны на отдельных страницах без единой сводной таблицы.
Как делать:
1. Расположите тарифы по возрастанию цены и предложения.
2. Выделите приоритетный тариф с помощью дизайна.
3. Дайте сравнить, но не больше 4 тарифов в таблице.
4. Называйте тарифы осмысленно, без манипуляций и оценок.
5. Чётко прописывайте 4 главных критерия: абонентскую плату, количество бесплатных платежей, комиссии за снятие и пополнение наличных, лимиты и комиссии на переводы физлицам.
6. Давайте ссылку на подробное описание тарифов.
7. Отдельно выносите скидки, они интересны только продвинутым пользователям.
8. Прописывайте пункты на языке пользователя: вместо «платежи» — «платежи юрлицам и ИП».
9. Расскажите про превышение лимитов.
10. Дайте посмотреть цены при ежемесячной оплате и оплате за год вперёд.
https://vc.ru/design/90038
Тёмные паттерны и просто плохой дизайн:
1. Важные условия и ограничения написаны мелко и малоконтрастно, чтобы человек не обратил на них внимания.
2. Тарифам даны эмоциональные названия. Например, тариф «Успех» (подороже) и «Лоукост» (самый дешёвый).
3. Некоторые важные условия тарифа есть только в огромном документе со всеми условиями. Например, показаны только лимиты, но не показано, что будет после их превышения.
4. Сломана привычная логика отображения информации. Например, показаны сначала свойства тарифа, а потом стоимость. Или показаны тарифы слева направо от большей стоимости к меньшей.
5. Общие формулировки и канцеляризмы.
6. Все тарифы показаны на отдельных страницах без единой сводной таблицы.
Как делать:
1. Расположите тарифы по возрастанию цены и предложения.
2. Выделите приоритетный тариф с помощью дизайна.
3. Дайте сравнить, но не больше 4 тарифов в таблице.
4. Называйте тарифы осмысленно, без манипуляций и оценок.
5. Чётко прописывайте 4 главных критерия: абонентскую плату, количество бесплатных платежей, комиссии за снятие и пополнение наличных, лимиты и комиссии на переводы физлицам.
6. Давайте ссылку на подробное описание тарифов.
7. Отдельно выносите скидки, они интересны только продвинутым пользователям.
8. Прописывайте пункты на языке пользователя: вместо «платежи» — «платежи юрлицам и ИП».
9. Расскажите про превышение лимитов.
10. Дайте посмотреть цены при ежемесячной оплате и оплате за год вперёд.
https://vc.ru/design/90038
vc.ru
Не обман, а дизайн: как банки манипулируют с помощью UX — Дизайн на vc.ru
Собрали неудачные практики дизайна или намеренные dark-UX-решения в тарифах для бизнеса: от «Тинькофф» до «Сбербанка». И сделали свой вариант идеальной тарифной таблицы.
Дмитрий Ваницкий написал о дофамине, серотонине, окситоцине и эндорфине в контексте проектирования взаимодействия.
Повышение уровня этих гормонов дарит ощущение умиротворения, радости и вдохновения. Понимая, как они работают, можно по-новому взглянуть на уже устоявшиеся методики и придумать новые, более эффективные способы проектирования взаимодействия, помочь людям обрести новые привычки. Моделируя поведение с выработкой этих гормонов, мы можем закрепить в памяти людей нужные нам паттерны.
Дофамин стимулирует искать новую информацию. Если хотите работать с дофамином, следуйте схеме: стимул — вовлечение — действие — вознаграждение — стимул. Так работает любого рода игрофикация.
Стоит рассказывать о новых функциях и поощрять пользователя самостоятельно изучать сервис. Например, с помощью онбординга, пасхальных яиц, случайных действий (при закрытии задачи в Asana иногда появляется единорог) или подарков.
Окситоцин вызывает у нас чувство удовольствия от оказанного нам доверия или от того, что есть кто-то, кому мы можем довериться.
Показывайте людям, что они принадлежат одной группе. Например, Nike организует сообщество любителей спорта, Twitter перед редизайном выделили группу лояльных пользователей и лидеров мнений и раскатали новую версию только на них.
Используйте социальные поглаживания (похвала или другой способ выражения одобрения, обличённый в социально приемлемую форму) и держите свои обещания.
Серотонин мы получаем, если в чём-то превосходим других.
Дайте людям измеритель чего-бы то ни было, и они начнут меряться. Это могут быть разного рода лидерборды (кто больше, кто быстрее, кто лучше, кто меньше и так далее), символы статуса и награды (бейдж awwwards или оценка курируемой галереи на Behance).
Эндорфин мы получаем во время опасности для нашей жизни, в основном при болевых ощущениях. Благодаря ему мы чувствуем радость, когда превозмогая боль достигаем цели: тренируемся на износ, заканчиваем что-то важное, бьём свои рекорды.
Сглаживайте негатив, который пользователю необходимо будет пережить, и усиливайте действие эндорфина с помощью юмора.
https://medium.com/design-spot/cb37b9e0b629
Повышение уровня этих гормонов дарит ощущение умиротворения, радости и вдохновения. Понимая, как они работают, можно по-новому взглянуть на уже устоявшиеся методики и придумать новые, более эффективные способы проектирования взаимодействия, помочь людям обрести новые привычки. Моделируя поведение с выработкой этих гормонов, мы можем закрепить в памяти людей нужные нам паттерны.
Дофамин стимулирует искать новую информацию. Если хотите работать с дофамином, следуйте схеме: стимул — вовлечение — действие — вознаграждение — стимул. Так работает любого рода игрофикация.
Стоит рассказывать о новых функциях и поощрять пользователя самостоятельно изучать сервис. Например, с помощью онбординга, пасхальных яиц, случайных действий (при закрытии задачи в Asana иногда появляется единорог) или подарков.
Окситоцин вызывает у нас чувство удовольствия от оказанного нам доверия или от того, что есть кто-то, кому мы можем довериться.
Показывайте людям, что они принадлежат одной группе. Например, Nike организует сообщество любителей спорта, Twitter перед редизайном выделили группу лояльных пользователей и лидеров мнений и раскатали новую версию только на них.
Используйте социальные поглаживания (похвала или другой способ выражения одобрения, обличённый в социально приемлемую форму) и держите свои обещания.
Серотонин мы получаем, если в чём-то превосходим других.
Дайте людям измеритель чего-бы то ни было, и они начнут меряться. Это могут быть разного рода лидерборды (кто больше, кто быстрее, кто лучше, кто меньше и так далее), символы статуса и награды (бейдж awwwards или оценка курируемой галереи на Behance).
Эндорфин мы получаем во время опасности для нашей жизни, в основном при болевых ощущениях. Благодаря ему мы чувствуем радость, когда превозмогая боль достигаем цели: тренируемся на износ, заканчиваем что-то важное, бьём свои рекорды.
Сглаживайте негатив, который пользователю необходимо будет пережить, и усиливайте действие эндорфина с помощью юмора.
https://medium.com/design-spot/cb37b9e0b629
Medium
Закрытые операции на мозге
Или управление гормонами при проектировании взаимодействия.