Forwarded from Теории и Практики
Правила пунктуации традиционно являются одной из самых сложных областей изучения. Вот только обычно страх и трепет вызывают запятые, тогда как использование остальных знаков препинания воспринимается как что-то простое и очевидное.
Прежде чем разбираться в правилах постановки тире, важно понять, что им является, а что — нет. Так, в пунктуации существует два вида тире, короткое и длинное, а также дефис.
Длинное тире (—) ставится во всех тех пунктуационных случаях, которые мы будем рассматривать ниже. Если вы собираетесь использовать в предложении тире как знак препинания, даже не задумывайтесь: ваш выбор — длинное тире.
Короткое тире (–) используется для обозначения диапазонов чисел и дат, например, 2010–2020.
Дефис (-) употребляется в так называемых сложных словах и составных фамилиях: юго-восточный, один-одинешенек, Петров-Водкин.
Собрали примеры, когда ставится тире, в карточки. Об остальных случаях рассказываем здесь.
Прежде чем разбираться в правилах постановки тире, важно понять, что им является, а что — нет. Так, в пунктуации существует два вида тире, короткое и длинное, а также дефис.
Длинное тире (—) ставится во всех тех пунктуационных случаях, которые мы будем рассматривать ниже. Если вы собираетесь использовать в предложении тире как знак препинания, даже не задумывайтесь: ваш выбор — длинное тире.
Короткое тире (–) используется для обозначения диапазонов чисел и дат, например, 2010–2020.
Дефис (-) употребляется в так называемых сложных словах и составных фамилиях: юго-восточный, один-одинешенек, Петров-Водкин.
Собрали примеры, когда ставится тире, в карточки. Об остальных случаях рассказываем здесь.
Ралука Будиу из Nielsen Norman Group написала о кнопках переключения состояния.
Такие кнопки часто содержат информацию о текущем состоянии системы и о состоянии, в которое она переключится после нажатия кнопки. Пользователи путаются.
Самое понятное решение — за каждую часть информации отвечает отдельный элемент. Например, на экране Controls в приложении Tesla иконка показывает текущее состояние, а текст — команду для его изменения.
Когда за всё отвечает один элемент, есть 2 варианта реализации.
1. Кнопка показывает состояние, в которое переключится система после нажатия (после нажатия текст или иконка меняются на противоположные):
— Так работают обычные кнопки — текст на них обычно говорит, что произойдёт после нажатия;
— Довольно понятное решение, если текущее состояние системы понятно из контекста. Например, кнопка «Пауза» при проигрывающемся видео.
2. Кнопка показывает свойство системы. Она может быть нажата (свойство активно) или нет:
— Например, в текстовом редакторе кнопка Bold нажата, если выделен полужирный текст;
— Показывать активность свойств системы следует одинаковым способом. В этом была ошибка WebEx.
Оба варианта с одним элементом не стоит использовать:
— Если пользователям надо быстро принимать решения в отношении этих кнопок;
— Не очевидно, что кнопка переключает между двумя противоположными состояниями.
https://vc.ru/design/169065
Такие кнопки часто содержат информацию о текущем состоянии системы и о состоянии, в которое она переключится после нажатия кнопки. Пользователи путаются.
Самое понятное решение — за каждую часть информации отвечает отдельный элемент. Например, на экране Controls в приложении Tesla иконка показывает текущее состояние, а текст — команду для его изменения.
Когда за всё отвечает один элемент, есть 2 варианта реализации.
1. Кнопка показывает состояние, в которое переключится система после нажатия (после нажатия текст или иконка меняются на противоположные):
— Так работают обычные кнопки — текст на них обычно говорит, что произойдёт после нажатия;
— Довольно понятное решение, если текущее состояние системы понятно из контекста. Например, кнопка «Пауза» при проигрывающемся видео.
2. Кнопка показывает свойство системы. Она может быть нажата (свойство активно) или нет:
— Например, в текстовом редакторе кнопка Bold нажата, если выделен полужирный текст;
— Показывать активность свойств системы следует одинаковым способом. В этом была ошибка WebEx.
Оба варианта с одним элементом не стоит использовать:
— Если пользователям надо быстро принимать решения в отношении этих кнопок;
— Не очевидно, что кнопка переключает между двумя противоположными состояниями.
https://vc.ru/design/169065
vc.ru
Элементы управления переключателем состояния: печально известный случай кнопки отключения звука — Дизайн на vc.ru
Всем привет, меня зовут Миша Хананашвили, я автор канала UXHorn и работаю исследователем в «Сбере».
Гиги Джанелидзе написал о принципах хорошего сервиса.
Хороший сервис:
1. Востребованный. Новые клиенты приходят сами по рекомендации знакомых, так как сервис хорошо решает их задачи;
2. Не заставляет думать. Если клиент не знает, что конкретно ищет, не может правильно сформулировать запрос, сервис помогает в поиске или предлагает решение, исходя из обстоятельств;
3. Говорит с клиентами на одном языке. И это живой язык, без канцелярита;
4. Легко транслирует свою ценность. Клиент должен хорошо знать, какие задачи решает сервис;
5. Прозрачный. Клиент понимает, какой результат за какое время и по какой цене он получит. Сервис не подводит эти ожидания;
6. Упрощает клиентам достижение их целей. Узнавайте реальный User Flow, внедряйте этап Discovery и Experience Research, чтобы понимать клиентские цели;
7. Выходит за рамки основного предложения. Сервис закрывает типовые ожидания клиентов в отношении подобных сервисов и предлагает что-то, соответствующее ещё только формирующимся ожиданиям;
8. Привычный. Не меняет радикально интерфейс, к которому пользователи привыкли. А если меняет, то тщательно об этом информирует;
9. Работает без лишних посредников. Например, чтобы пополнить счёт, не надо идти в отделение;
10. Бесшовный и консистентный. Принцип одного окна — клиент решает все свои задачи через один канал коммуникации;
11. Создаётся в компаниях с культурой прозрачности и доверия. Чем разобщённее компания внутри, тем разобщённее будут её сервисы;
12. Оптимизированный. Клиент делает минимальное количество шагов, необходимое для решения задачи. Автоматизировано всё, что можно;
13. Не создаёт дополнительных проблем. В сервисе проработаны не только основные сценарии, но и второстепенные, и нежелательные для компании (отказаться от кредитки должно быть так же просто, как приобрести её);
14. Инклюзивный. В реальном мире нет идеального пользователя;
15. Вдохновляет и дарит положительные эмоции при использовании;
16. Адаптирован под изменчивый мир. Изменения могут быть прямыми (все конкуренты добавили бесконтактную оплату) и косвенными (люди стали больше думать о приватности).
https://medium.com/gigijanelidze/77330ff7032
Хороший сервис:
1. Востребованный. Новые клиенты приходят сами по рекомендации знакомых, так как сервис хорошо решает их задачи;
2. Не заставляет думать. Если клиент не знает, что конкретно ищет, не может правильно сформулировать запрос, сервис помогает в поиске или предлагает решение, исходя из обстоятельств;
3. Говорит с клиентами на одном языке. И это живой язык, без канцелярита;
4. Легко транслирует свою ценность. Клиент должен хорошо знать, какие задачи решает сервис;
5. Прозрачный. Клиент понимает, какой результат за какое время и по какой цене он получит. Сервис не подводит эти ожидания;
6. Упрощает клиентам достижение их целей. Узнавайте реальный User Flow, внедряйте этап Discovery и Experience Research, чтобы понимать клиентские цели;
7. Выходит за рамки основного предложения. Сервис закрывает типовые ожидания клиентов в отношении подобных сервисов и предлагает что-то, соответствующее ещё только формирующимся ожиданиям;
8. Привычный. Не меняет радикально интерфейс, к которому пользователи привыкли. А если меняет, то тщательно об этом информирует;
9. Работает без лишних посредников. Например, чтобы пополнить счёт, не надо идти в отделение;
10. Бесшовный и консистентный. Принцип одного окна — клиент решает все свои задачи через один канал коммуникации;
11. Создаётся в компаниях с культурой прозрачности и доверия. Чем разобщённее компания внутри, тем разобщённее будут её сервисы;
12. Оптимизированный. Клиент делает минимальное количество шагов, необходимое для решения задачи. Автоматизировано всё, что можно;
13. Не создаёт дополнительных проблем. В сервисе проработаны не только основные сценарии, но и второстепенные, и нежелательные для компании (отказаться от кредитки должно быть так же просто, как приобрести её);
14. Инклюзивный. В реальном мире нет идеального пользователя;
15. Вдохновляет и дарит положительные эмоции при использовании;
16. Адаптирован под изменчивый мир. Изменения могут быть прямыми (все конкуренты добавили бесконтактную оплату) и косвенными (люди стали больше думать о приватности).
https://medium.com/gigijanelidze/77330ff7032
Medium
Принципы создания хорошего сервиса
Часто, перед тем, как бежать создавать новые фичи, лучше оглядеться вокруг и задать себе вопрос «Почему?»
Мэтью Стрём написал об аффордансах.
Аффорданс — это связь между свойствами объекта и возможностями агента, которая определяет, каким образом этот агент может использовать этот объект.
Дизайнеры определение немного изменили, теперь это свойства объектов, показывающие пользователям действия, которые они могут предпринять.
Ручка на двери показывает, что её можно открыть, потянув на себя. Плоская прямоугольная ручка показывает, что дверь надо толкать.
При взаимодействии с цифровыми объектами всё сложнее. Нет причин, по которым именно синим цветом стали обозначать гиперссылку. Первый браузер использовал подчёркивание для обозначения ссылки, возможно, потому что эта форма выделения не так часто использовалась в обычных документах. Так на заре интернета появлялись сотни аффордансов.
Хороший аффорданс в физическом мире — естественный способ взаимодействия. В цифровом — привычный способ, к которому пользователи привыкли, работая с другими цифровыми продуктами.
#affordance #definition
Аффорданс — это связь между свойствами объекта и возможностями агента, которая определяет, каким образом этот агент может использовать этот объект.
Дизайнеры определение немного изменили, теперь это свойства объектов, показывающие пользователям действия, которые они могут предпринять.
Ручка на двери показывает, что её можно открыть, потянув на себя. Плоская прямоугольная ручка показывает, что дверь надо толкать.
При взаимодействии с цифровыми объектами всё сложнее. Нет причин, по которым именно синим цветом стали обозначать гиперссылку. Первый браузер использовал подчёркивание для обозначения ссылки, возможно, потому что эта форма выделения не так часто использовалась в обычных документах. Так на заре интернета появлялись сотни аффордансов.
Хороший аффорданс в физическом мире — естественный способ взаимодействия. В цифровом — привычный способ, к которому пользователи привыкли, работая с другими цифровыми продуктами.
#affordance #definition
UXPUB 🇺🇦 Дизайн-спільнота
Аффордансы в дизайне. Дизайн привычных вещей
Давайте погрузимся в глубины дизайна интерфейсов, поговорим об аффордансах и выясним как они работают
Вадим Митякин опубликовал 5-ю главу книги «Метод параноика» о базовом принципе метода — проектировании.
— Проект требует усилий постоянно. Надо следить за возникающими рисками и вовремя их устранять. Главный противник — неопределённость;
— Без правильной мотивации, которая учитывает их личные цели, люди не могут день за днём быть изобретательными и творческими;
— Метод максимально полезен для проектов типа «Мозги», в которых происходит поиск новых способов использования технологических инструментов в бизнесе;
— Базовый принцип метода — проектирование, то есть продумывание решения до воплощения. Альтернатива — не отсутствие продумывания, а одновременность поиска решения и его воплощения;
— Разделение проектирования и воплощения всего проекта на 2 этапа было бы возвратом к водопадной модели. Вместо этого метод предполагает разделять на 2 этапа отдельные задачи;
— Проблема в том, что те, кто говорят, что делают проектирование, фактически его не делают. Проектирование ≠ UX Design;
— В рамках метода принцип проектирования распространяется на все аспекты проекта: от организационных задач до технических вопросов;
— Проблема традиционного подхода в том, что бизнес перед проектированием плохо формулирует цели, а разработчики игнорируют решения проектировщиков;
— Проектировщики работают с первоначальными требованиями и условиями, которые даёт бизнес (описание бизнес-модели, набор функций, схемы процессов, цели проекта), но в них тоже могут быть ошибки, это скрытая неопределённость;
— Проектирование должно быть фильтром для идей и решений, отсеивающим те, которым не стоит жить и на реализацию которых не стоит тратить ресурсы;
— 3 базовых идеи: 1) Каждое решение в проекте должно уменьшать неопределённость; 2) Каждое решение требует своего уровня абстракции, компетенции и ответственности; 3) Все решения должны быть связаны между собой;
— При проектировании будущего продукта ключевая задача состоит в том, чтобы в принципе разобраться, каковы действительные требования;
— С добавлением компонентов сложность системы возрастает не только за счёт количества новых компонентов, но и за счёт их взаимодействия (новые связи, новые сценарии, затрагивающие несколько компонентов);
— В проекте должен быть тот, кто будет в дальнейшем использовать разрабатываемый продукт;
— Продукт должен быть всегда готов, но с разным уровнем детализации и проработки в зависимости от этапа работ.
https://paranoidmethod.org/paranoid-method-book-05
— Проект требует усилий постоянно. Надо следить за возникающими рисками и вовремя их устранять. Главный противник — неопределённость;
— Без правильной мотивации, которая учитывает их личные цели, люди не могут день за днём быть изобретательными и творческими;
— Метод максимально полезен для проектов типа «Мозги», в которых происходит поиск новых способов использования технологических инструментов в бизнесе;
— Базовый принцип метода — проектирование, то есть продумывание решения до воплощения. Альтернатива — не отсутствие продумывания, а одновременность поиска решения и его воплощения;
— Разделение проектирования и воплощения всего проекта на 2 этапа было бы возвратом к водопадной модели. Вместо этого метод предполагает разделять на 2 этапа отдельные задачи;
— Проблема в том, что те, кто говорят, что делают проектирование, фактически его не делают. Проектирование ≠ UX Design;
— В рамках метода принцип проектирования распространяется на все аспекты проекта: от организационных задач до технических вопросов;
— Проблема традиционного подхода в том, что бизнес перед проектированием плохо формулирует цели, а разработчики игнорируют решения проектировщиков;
— Проектировщики работают с первоначальными требованиями и условиями, которые даёт бизнес (описание бизнес-модели, набор функций, схемы процессов, цели проекта), но в них тоже могут быть ошибки, это скрытая неопределённость;
— Проектирование должно быть фильтром для идей и решений, отсеивающим те, которым не стоит жить и на реализацию которых не стоит тратить ресурсы;
— 3 базовых идеи: 1) Каждое решение в проекте должно уменьшать неопределённость; 2) Каждое решение требует своего уровня абстракции, компетенции и ответственности; 3) Все решения должны быть связаны между собой;
— При проектировании будущего продукта ключевая задача состоит в том, чтобы в принципе разобраться, каковы действительные требования;
— С добавлением компонентов сложность системы возрастает не только за счёт количества новых компонентов, но и за счёт их взаимодействия (новые связи, новые сценарии, затрагивающие несколько компонентов);
— В проекте должен быть тот, кто будет в дальнейшем использовать разрабатываемый продукт;
— Продукт должен быть всегда готов, но с разным уровнем детализации и проработки в зависимости от этапа работ.
https://paranoidmethod.org/paranoid-method-book-05
Михаил Правдин рассказал, как проводить больше исследований.
— Дизайн-спринты идут параллельно спринтам разработки, их результат — проработанные и обоснованные предложения для беклога. Они опережают разработку на несколько недель и не тормозят выпуск обновлений;
— В одном спринте у дизайн-команды около 5 гипотез о проблеме и её решении. Их надо проверить в течение одного спринта;
— Чтобы лучше понять клиентов, найти или проверить гипотезы, компании чаще всего проводят интервью и usability-тесты;
— Как увеличить количество таких исследований: 1) Вовлечь дизайнеров (субъективно лучший вариант из этих трёх, но есть нюансы); 2) Взять отдельного исследователя; 3) Привлечь агентство;
— Ещё один вариант — привлечь внешних экспертов-фрилансеров. Их становится больше, работать с ними становится проще, но их сложно найти (в статье есть пример решения этой задачи);
— Подойдёт, если не уверены, что команде нужен исследователь, проект на начальном этапе, нет ресурса для самостоятельных исследований или нет уверенности в правильности своих действий, хотите получить непредвзятый взгляд со стороны;
— При работе с ними важно составить хороший бриф, согласовать и детально прописать работы, сроки и ответственных, показать примеры ожидаемого результата, создать условия для подключения команды на каждом этапе;
— В сравнении с агентством получается дешевле, выше качество, исследователь плотнее общается с командой, происходит взаимное обучение;
— В сравнении с собственными исследователями фрилансеры медленнее погружаются в задачу, хуже разбираются в вашем продукте, могут не обладать доступом к какой-то внутренней информации.
https://sense23.com/post/zachem-avito-oblachnye-ux-issledovateli-i-kak-s-nimi-rabotat
— Дизайн-спринты идут параллельно спринтам разработки, их результат — проработанные и обоснованные предложения для беклога. Они опережают разработку на несколько недель и не тормозят выпуск обновлений;
— В одном спринте у дизайн-команды около 5 гипотез о проблеме и её решении. Их надо проверить в течение одного спринта;
— Чтобы лучше понять клиентов, найти или проверить гипотезы, компании чаще всего проводят интервью и usability-тесты;
— Как увеличить количество таких исследований: 1) Вовлечь дизайнеров (субъективно лучший вариант из этих трёх, но есть нюансы); 2) Взять отдельного исследователя; 3) Привлечь агентство;
— Ещё один вариант — привлечь внешних экспертов-фрилансеров. Их становится больше, работать с ними становится проще, но их сложно найти (в статье есть пример решения этой задачи);
— Подойдёт, если не уверены, что команде нужен исследователь, проект на начальном этапе, нет ресурса для самостоятельных исследований или нет уверенности в правильности своих действий, хотите получить непредвзятый взгляд со стороны;
— При работе с ними важно составить хороший бриф, согласовать и детально прописать работы, сроки и ответственных, показать примеры ожидаемого результата, создать условия для подключения команды на каждом этапе;
— В сравнении с агентством получается дешевле, выше качество, исследователь плотнее общается с командой, происходит взаимное обучение;
— В сравнении с собственными исследователями фрилансеры медленнее погружаются в задачу, хуже разбираются в вашем продукте, могут не обладать доступом к какой-то внутренней информации.
https://sense23.com/post/zachem-avito-oblachnye-ux-issledovateli-i-kak-s-nimi-rabotat
Блог ProductSense
Зачем Авито «облачные» UX-исследователи и как с ними работать
Всем привет, меня зовут Михаил Правдин, я руковожу направлением качественных UX-исследований в Авито. Возможно, вы видели мой доклад на ProductSense о том, как в Авито проводят исследования, или сл…
❤1👍1
Иван Меллер побеседовал с Мишей (Pinkman) и Лерой Розов (Typical).
— Об HR-компании Леры Typical и подходе No Code;
— Появлении названия конкурса Position Oneum;
— Разных шаблонах письма с приглашением на церемонию награждения «Золотой сайт» (просто приглашение и настойчивое приглашение победителям);
— Оценке проектов на конкурсах (не рандом, а пулемёт, 20 секунд на каждую работу);
— Кейс-чемпионатах, как будет обеспечиваться объективность конкурса Position Oneum;
— Переходе дизайн-студий от дизайна к консалтингу;
— Проблеме выхода в СМИ с кейсами своих клиентов (нужны бизнес-показатели, которыми клиенты делиться не хотят);
— Заградительных критериях, когда компания хочет работать со студией, но всё равно должна провести открытый тендер;
— Статуэтках за победы в конкурсах (атавизм).
https://www.youtube.com/watch?v=SCYXYPMmv4k
— Об HR-компании Леры Typical и подходе No Code;
— Появлении названия конкурса Position Oneum;
— Разных шаблонах письма с приглашением на церемонию награждения «Золотой сайт» (просто приглашение и настойчивое приглашение победителям);
— Оценке проектов на конкурсах (не рандом, а пулемёт, 20 секунд на каждую работу);
— Кейс-чемпионатах, как будет обеспечиваться объективность конкурса Position Oneum;
— Переходе дизайн-студий от дизайна к консалтингу;
— Проблеме выхода в СМИ с кейсами своих клиентов (нужны бизнес-показатели, которыми клиенты делиться не хотят);
— Заградительных критериях, когда компания хочет работать со студией, но всё равно должна провести открытый тендер;
— Статуэтках за победы в конкурсах (атавизм).
https://www.youtube.com/watch?v=SCYXYPMmv4k
YouTube
Миша и Лера Розовы: о конкурсах, справедливости и тендерах | S1E01 Не о дизайне Podcast
Telegram https://tttttt.me/neodes
Михаил Розов - основатель и руководитель дизайн-лаборатории Pinkman, и Лера Розова - основатель Typical, рассказали о своем новом проекте Position Oneum, который должен перевернуть устои конкурсов в русском digital.
Автор/ведущий:…
Михаил Розов - основатель и руководитель дизайн-лаборатории Pinkman, и Лера Розова - основатель Typical, рассказали о своем новом проекте Position Oneum, который должен перевернуть устои конкурсов в русском digital.
Автор/ведущий:…
В Avanpost написали об авторизации.
Авторизация — процесс принятия решения о предоставлении субъекту доступа на выполнение операции на основании каких-либо знаний о субъекте.
Люди, которые говорят «авторизация», часто имеют в виду аутентификацию.
Аутентификация — проверка подлинности пользователя, например, путём сравнения введённого им пароля (для указанного логина) с паролем, сохранённым в базе данных пользовательских логинов.
Например, в процессе авторизации система решает, может ли конкретный пользователь видеть договор, учитывая существующие требования бизнеса и безопасности:
— Договор не видят пользователи, не имеющие к нему отношения;
— Автор договора видит его на всех этапах;
— Визирующий видит договор, начиная с поступления к нему на этап;
— И так далее.
Есть готовые модели управления доступом (часто используется их комбинация):
— Мандатная модель — доступ определяется уровнем: уровень доступа субъекта должен быть не ниже уровня секретности объекта;
— Прямое управление — доступ определяется наличием субъекта в списке доступа объекта;
— Ролевая модель — доступ определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу;
— Атрибутивная модель — доступ определяется динамически на основании анализа политик, учитывающих значения атрибутов субъекта, объекта и окружения.
https://habr.com/ru/company/avanpost/blog/480576/
Авторизация — процесс принятия решения о предоставлении субъекту доступа на выполнение операции на основании каких-либо знаний о субъекте.
Люди, которые говорят «авторизация», часто имеют в виду аутентификацию.
Аутентификация — проверка подлинности пользователя, например, путём сравнения введённого им пароля (для указанного логина) с паролем, сохранённым в базе данных пользовательских логинов.
Например, в процессе авторизации система решает, может ли конкретный пользователь видеть договор, учитывая существующие требования бизнеса и безопасности:
— Договор не видят пользователи, не имеющие к нему отношения;
— Автор договора видит его на всех этапах;
— Визирующий видит договор, начиная с поступления к нему на этап;
— И так далее.
Есть готовые модели управления доступом (часто используется их комбинация):
— Мандатная модель — доступ определяется уровнем: уровень доступа субъекта должен быть не ниже уровня секретности объекта;
— Прямое управление — доступ определяется наличием субъекта в списке доступа объекта;
— Ролевая модель — доступ определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу;
— Атрибутивная модель — доступ определяется динамически на основании анализа политик, учитывающих значения атрибутов субъекта, объекта и окружения.
https://habr.com/ru/company/avanpost/blog/480576/
Хабр
Никто (почти) не знает, что такое авторизация
За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу...
Ольга Ржанова написала, как проводить больше исследований силами команды в формате Speed Dating.
— Исследователь становится экспертом-консультантом, исследования проводят сами дизайнеры (и другие члены команды), при необходимости они обращаются к исследователю за помощью;
— Дизайнеры встречаются с респондентами каждую среду. К этому дню может появиться прототип или накопиться критическая масса вопросов;
— В понедельник исследователи уточняют, кто из команды готов участвовать. Если есть 4 желающих, начинают подбор респондентов;
— На встрече дизайнеры по очереди общаются с 6 респондентами в течение 5−20 минут. Поговорив с одним респондентом, дизайнер ждёт, когда освободится другой, с которым он ещё не общался (не нужны сложные схемы смены собеседников);
— В таком формате не тестируют большие и сложные сценарии и не проводят масштабные по количеству вопросов интервью.
https://medium.com/market-design/fa6ac307f752
— Исследователь становится экспертом-консультантом, исследования проводят сами дизайнеры (и другие члены команды), при необходимости они обращаются к исследователю за помощью;
— Дизайнеры встречаются с респондентами каждую среду. К этому дню может появиться прототип или накопиться критическая масса вопросов;
— В понедельник исследователи уточняют, кто из команды готов участвовать. Если есть 4 желающих, начинают подбор респондентов;
— На встрече дизайнеры по очереди общаются с 6 респондентами в течение 5−20 минут. Поговорив с одним респондентом, дизайнер ждёт, когда освободится другой, с которым он ещё не общался (не нужны сложные схемы смены собеседников);
— В таком формате не тестируют большие и сложные сценарии и не проводят масштабные по количеству вопросов интервью.
https://medium.com/market-design/fa6ac307f752
Medium
“Speed dating” с пользователями
UX-исследования — это не только увлекательныйпроцесс, но и возможность лучше узнать своих пользователей и, как результат, сэкономить…
Кейт Каплан из Nielsen Norman Group написала о проектировании сложных приложений.
Такое предложение поддерживает большой набор неструктурированных целей, отличается нелинейными рабочими процессами, требует от пользователей специфических знаний. Например, 1С Бухгалтерия.
1. Обучайте через действие. Разбивайте длинные процессы на короткие шаги и визуализируйте изменения на каждом шаге. Давайте возможность ошибиться и вернуться назад.
2. Рассказывайте, что приложение умеет. Показывайте контекстные подсказки для ускорителей (горячих клавиш, макросов, жестов) и дополнительных функций.
3. Избегайте жёстких линейных процессов. Давайте пройти или перепройти каждый из шагов, необходимых для получения результата, в любой момент выполнения задачи. Плюс пропускать шаги, возвращаться к предыдущим и так далее.
4. Помогайте зафиксировать промежуточные мысли и результаты работы (заметки, комментарии), чтобы прерваться и завершить задачу потом.
5. Прорабатывайте точки переключения между приложением и сторонними инструментами. Например, возможность выгрузки данных в Excel.
6. Показывайте дополнительные возможности по мере необходимости. Например, в Гугл Документах сначала открывается доступ к документу другим людям и только потом настраивается уровень доступа (читатель, комментатор или редактор).
7. Раскрывайте дополнительную информацию там же, где отображается главная. Пример: отображение деталей при наведении курсора на график.
8. Визуально выделяйте важную информацию. Удаляйте все лишние визуальные элементы, картинки, которые будут отвлекать и так далее.
https://vc.ru/design/175230
Такое предложение поддерживает большой набор неструктурированных целей, отличается нелинейными рабочими процессами, требует от пользователей специфических знаний. Например, 1С Бухгалтерия.
1. Обучайте через действие. Разбивайте длинные процессы на короткие шаги и визуализируйте изменения на каждом шаге. Давайте возможность ошибиться и вернуться назад.
2. Рассказывайте, что приложение умеет. Показывайте контекстные подсказки для ускорителей (горячих клавиш, макросов, жестов) и дополнительных функций.
3. Избегайте жёстких линейных процессов. Давайте пройти или перепройти каждый из шагов, необходимых для получения результата, в любой момент выполнения задачи. Плюс пропускать шаги, возвращаться к предыдущим и так далее.
4. Помогайте зафиксировать промежуточные мысли и результаты работы (заметки, комментарии), чтобы прерваться и завершить задачу потом.
5. Прорабатывайте точки переключения между приложением и сторонними инструментами. Например, возможность выгрузки данных в Excel.
6. Показывайте дополнительные возможности по мере необходимости. Например, в Гугл Документах сначала открывается доступ к документу другим людям и только потом настраивается уровень доступа (читатель, комментатор или редактор).
7. Раскрывайте дополнительную информацию там же, где отображается главная. Пример: отображение деталей при наведении курсора на график.
8. Визуально выделяйте важную информацию. Удаляйте все лишние визуальные элементы, картинки, которые будут отвлекать и так далее.
https://vc.ru/design/175230
vc.ru
Как проектировать сложные приложения. Восемь полезных советов
Перевод и адаптация статьи Kate Kaplan для NN Group.
Никита Лакеев, соавтор подкаста «Дизайн Такой», по моей просьбе посоветовал ещё подкастов для дизайнеров.
Дизайн Такой — подкаст о продуктовом дизайне, где ведущие общаются с экспертами индустрии. Нужен ли онбординг в приложениях, как пережить редизайн и почему все говорят про дизайн-системы.
— На разных платформах: https://taplink.cc/designtakoy
— Канал: @design_takoy
Редач — сначала это были короткие аудиозаметки о тексте в интерфейсе, а теперь — полноценные интервью с UX-писателями. Как задать голос продукта, адаптировать текст для инклюзивной версии приложения и локализовать сайт для Японии и Китая.
— На разных платформах: https://we.fo/1372441932
— Канал: @redachredach
make sense podcast — подкаст о том, что важно при создании продукта: люди, идеи, деньги, инструменты и практики. Подходит дизайнерам и другим участникам продуктовой команды.
— На разных платформах: https://sense23.com/podcasts
— Канал: @mspodcast
Дизис — длинно о дизайне, коротко обо всём. О хороших проектах, чётких дизайнерах и трудностях индустрии. Без цензуры, занудства и сомнений. Есть хорошо снятая видеоверсия на YouTube.
— На разных платформах: https://dictator.design/podcast/
— Канал: @dizispodcast
Запуск завтра — подкаст техдира Самата Галимова о технологиях, которые меняют нашу жизнь: как связаны дейтинг-приложения и система распознавания лиц, почему воюют пользователи и модераторы «Пикабу» и как главный факап «Сбербанка Онлайн» изменил всю компанию.
— На разных платформах: https://libolibo.ru/zapuskzavtra
— Канал: @ctodaily
UI Breakfast — один из лучших подкастов о UX-дизайне на английском. Обсудили уже всё что можно.
— На разных платформах: https://uibreakfast.com/category/podcast/
Дизайн Такой — подкаст о продуктовом дизайне, где ведущие общаются с экспертами индустрии. Нужен ли онбординг в приложениях, как пережить редизайн и почему все говорят про дизайн-системы.
— На разных платформах: https://taplink.cc/designtakoy
— Канал: @design_takoy
Редач — сначала это были короткие аудиозаметки о тексте в интерфейсе, а теперь — полноценные интервью с UX-писателями. Как задать голос продукта, адаптировать текст для инклюзивной версии приложения и локализовать сайт для Японии и Китая.
— На разных платформах: https://we.fo/1372441932
— Канал: @redachredach
make sense podcast — подкаст о том, что важно при создании продукта: люди, идеи, деньги, инструменты и практики. Подходит дизайнерам и другим участникам продуктовой команды.
— На разных платформах: https://sense23.com/podcasts
— Канал: @mspodcast
Дизис — длинно о дизайне, коротко обо всём. О хороших проектах, чётких дизайнерах и трудностях индустрии. Без цензуры, занудства и сомнений. Есть хорошо снятая видеоверсия на YouTube.
— На разных платформах: https://dictator.design/podcast/
— Канал: @dizispodcast
Запуск завтра — подкаст техдира Самата Галимова о технологиях, которые меняют нашу жизнь: как связаны дейтинг-приложения и система распознавания лиц, почему воюют пользователи и модераторы «Пикабу» и как главный факап «Сбербанка Онлайн» изменил всю компанию.
— На разных платформах: https://libolibo.ru/zapuskzavtra
— Канал: @ctodaily
UI Breakfast — один из лучших подкастов о UX-дизайне на английском. Обсудили уже всё что можно.
— На разных платформах: https://uibreakfast.com/category/podcast/
Taplink
Designtakoy at Taplink
❤1