Forwarded from Shock Design
Арты, выполненные в необычной технике, напоминающей коллажи или аппликации цветной бумаги
Forwarded from Дизайн-Телега 🔥
This media is not supported in your browser
VIEW IN TELEGRAM
Приложение доставки еды.
• Шаблон пользовательского интерфейса для дизайна приложений для еды, разработанным с нуля.
#app #mobile #uik
Открыть в Figma
• Шаблон пользовательского интерфейса для дизайна приложений для еды, разработанным с нуля.
#app #mobile #uik
Открыть в Figma
Forwarded from Дизайн-Телега 🔥
This media is not supported in your browser
VIEW IN TELEGRAM
Набор пользовательского интерфейса.
• Компоненты с вариантами.
• Стили текста.
• Цветовые стили.
#app #mobile #uik
Открыть в Figma
• Компоненты с вариантами.
• Стили текста.
• Цветовые стили.
#app #mobile #uik
Открыть в Figma
Forwarded from UI_UX inspiration
sasaki-agent: как я собрал агента для поиска работы
Статья об упрощении поиска новой работы. Автор рассказывает о различных технологиях, которые помогут найти подходящую вакансию: от тг-каналов и агрегаторов до линкедин и карьерных страниц компаний. Как использовать технологии для поиска работы?
Читать на дизайнерс | #статья
Статья об упрощении поиска новой работы. Автор рассказывает о различных технологиях, которые помогут найти подходящую вакансию: от тг-каналов и агрегаторов до линкедин и карьерных страниц компаний. Как использовать технологии для поиска работы?
Читать на дизайнерс | #статья
Forwarded from Дизайн-Телега 🔥
sasaki-agent: как я собрал агента для поиска работы
Статья об упрощении поиска новой работы. Автор рассказывает о различных технологиях, которые помогут найти подходящую вакансию: от тг-каналов и агрегаторов до линкедин и карьерных страниц компаний. Как использовать технологии для поиска работы?
Читать на дизайнерс | #статья
Статья об упрощении поиска новой работы. Автор рассказывает о различных технологиях, которые помогут найти подходящую вакансию: от тг-каналов и агрегаторов до линкедин и карьерных страниц компаний. Как использовать технологии для поиска работы?
Читать на дизайнерс | #статья
Forwarded from PSD | Дизайн-пространство
sasaki-agent: как я собрал агента для поиска работы
Статья об упрощении поиска новой работы. Автор рассказывает о различных технологиях, которые помогут найти подходящую вакансию: от тг-каналов и агрегаторов до линкедин и карьерных страниц компаний. Как использовать технологии для поиска работы?
Читать на дизайнерс | #статья
Статья об упрощении поиска новой работы. Автор рассказывает о различных технологиях, которые помогут найти подходящую вакансию: от тг-каналов и агрегаторов до линкедин и карьерных страниц компаний. Как использовать технологии для поиска работы?
Читать на дизайнерс | #статья
Forwarded from Цифровой геноцид
The Decision Ladder как паттерн при проектировании
https://publications.ergonomics.org.uk/uploads/Using-the-decision-ladder-to-reach-a-better-design.pdf
Лестница решений (первоначально разработанная Йенсом Расмуссеном в 1974 году) — это инструмент когнитивной инженерии, который отображает процесс решения проблем и принятия решений человеком в виде семи последовательных ментальных стадий. Она иллюстрирует шаги обработки информации, которые человек проходит, переходя от наблюдения за ситуацией к выполнению и оценке решения.
Связь между качеством пользовательского интерфейса и производительностью системы сейчас практически повсеместно признана. Для очень простых взаимодействий, таких как приложение будильника для мобильного телефона, разработка интерфейса может быть интуитивным и прямолинейным процессом. Принятие руководства по стилю и учёт набора эвристик (например, Nielsen & Molich, 1990) могут быть достаточными для обеспечения удобного дизайна. Однако сложность задачи пропорциональна сложности проектируемого продукта или услуги. Важным фактором при выборе подхода являются также последствия отказа системы: если отказ будильника может привести к пропущенным встречам или даже рейсам, он вряд ли станет причиной летального исхода. Напротив, в системах, критически важных для безопасности, цена отказа может быть гораздо выше.
Большинство разработок интерфейсов начинается с определения информационных требований. Чаще всего эти требования оформляются в виде текстового документа. Получившийся документ обычно служит мостом между системными архитекторами или инженерами и дизайнерами интерфейса. Неудивительно, что качество этих информационных требований напрямую влияет на качество результирующего интерфейса и на производительность систем, в которых они используются. Поэтому для обеспечения безопасности, эффективности, результативности, удобства использования и устойчивости продуктов и услуг важно, чтобы процесс разработки информационных требований соответствовал поставленным целям.
Таким образом, по крайней мере на первый взгляд, основой хорошо спроектированного интерфейса является установление:
(1) какая информация требуется;
(2) когда её нужно отображать;
(3) где она должна отображаться;
(4) кому она должна отображаться;
(5) как — в каком формате.
Принятие решений лежит в основе всех задач управления. Было множество попыток смоделировать деятельность по принятию решений. Большинство из них включают некоторую форму наблюдения информации, ориентации в текущей ситуации, выбора действия и, наконец, самого действия.
Лестница решений (Rasmussen, 1974) — это инструмент, наиболее часто используемый в рамках когнитивного анализа работы (Cognitive Work Analysis) для описания деятельности по принятию решений. В отличие от некоторых других моделей, её фокус направлен на весь процесс принятия решений, а не только на момент выбора между вариантами.
Она не привязана к какому-либо одному актору, а представляет процесс принятия решений всей рабочей системы в целом. Во многих случаях процесс принятия решений может быть совместным и распределённым между различными человеческими и техническими лицами, принимающими решения. Ожидается, что начинающие пользователи (в данной ситуации) будут проходить лестницу решений линейно. Левая сторона лестницы решений представляет наблюдение текущего состояния системы, а правая — планирование и выполнение задач и процедур для достижения целевого состояния системы.
Метод выявления системных информационных требований основан на серии полуструктурированных интервью с экспертами системы и/или заинтересованными сторонами. Эти интервью строятся вокруг шаблона, в центре которого находится лестница решений. Процесс заключается в фиксации вопросов, которые лица, принимающие решения, задают себе и системе на каждом этапе процесса принятия решений. Для каждой ключевой ситуации следует создавать отдельную модель. Такие ситуации обычно выявляются с помощью шаблона контекстной деятельности или иерархического анализа задач (HTA).
Этап 0 – Определение шагов задачи
Перед началом интервью деятельность следует разложить на отдельные части. Оптимальный метод декомпозиции зависит от системы. Деятельности, которые легко разделяются на ряд заметно различающихся шагов задачи, лучше всего декомпозировать с помощью методов анализа задач, таких как иерархический анализ задач (HTA). Деятельности, определяемые скорее условиями среды (например, местоположением), лучше декомпозировать с помощью шаблона контекстной деятельности. Для каждого шага задачи или ситуации следует создавать отдельную лестницу решений.
Этап 1 – Определение цели
Этап 2 – Оповещение (Alert)
Эксперта следует попросить начать прохождение процесса с его хронологического начала. Оповещения фиксируют события, которые впервые привлекают внимание к необходимости принятия решения
Этап 3 – Информация
Эксперта просят перечислить информационные элементы, которые он использовал бы для понимания ситуации. Информационные элементы — это «крупицы» информации, которые можно объединить, чтобы понять состояние системы.
Этап 4 – Состояние системы
Состояния системы представляют собой воспринятое понимание рабочей системы, основанное на интерпретации ряда информационных элементов. Ключевое отличие между информационным элементом и состоянием системы состоит в том, что состояния системы формируются из более чем одного количественно различного элемента информации
Этап 5 – Варианты (Options)
Варианты в лестнице можно описать как возможности изменить состояние системы с целью достижения общей цели. Пункты формулируются в виде вопросов: «Возможно ли (…)»?
Этап 6 – Выбранная цель
Выбранная цель в любой момент времени определяется тем, какому из ограничений отдаётся наивысший приоритет. Здесь можно указать на те цели, которые являются промежуточными или необходимыми для ситуации
Этап 7 – Целевое состояние
Целевые состояния зеркально отражают доступные варианты: как только выбран конкретный вариант, он становится целевым состоянием.
В общем на лестнице принятия решений предполагается отрисовать два пути
Сначала - левая сторона идёт вверх
От оповещения (Alert) → информации → состояния системы → диагностики.
Здесь человек поднимается от сырых данных к пониманию ситуации и целям (от skill-based / rule-based к knowledge-based уровню).
А затем - правая сторона идёт вниз
От выбранной цели (Chosen Goal) → целевого состояния → задач → процедур → выполнения.
Здесь человек спускается от абстрактной цели к конкретным действиям, которая является реакцией на алерты и состояния системы
https://publications.ergonomics.org.uk/uploads/Using-the-decision-ladder-to-reach-a-better-design.pdf
Лестница решений (первоначально разработанная Йенсом Расмуссеном в 1974 году) — это инструмент когнитивной инженерии, который отображает процесс решения проблем и принятия решений человеком в виде семи последовательных ментальных стадий. Она иллюстрирует шаги обработки информации, которые человек проходит, переходя от наблюдения за ситуацией к выполнению и оценке решения.
Связь между качеством пользовательского интерфейса и производительностью системы сейчас практически повсеместно признана. Для очень простых взаимодействий, таких как приложение будильника для мобильного телефона, разработка интерфейса может быть интуитивным и прямолинейным процессом. Принятие руководства по стилю и учёт набора эвристик (например, Nielsen & Molich, 1990) могут быть достаточными для обеспечения удобного дизайна. Однако сложность задачи пропорциональна сложности проектируемого продукта или услуги. Важным фактором при выборе подхода являются также последствия отказа системы: если отказ будильника может привести к пропущенным встречам или даже рейсам, он вряд ли станет причиной летального исхода. Напротив, в системах, критически важных для безопасности, цена отказа может быть гораздо выше.
Большинство разработок интерфейсов начинается с определения информационных требований. Чаще всего эти требования оформляются в виде текстового документа. Получившийся документ обычно служит мостом между системными архитекторами или инженерами и дизайнерами интерфейса. Неудивительно, что качество этих информационных требований напрямую влияет на качество результирующего интерфейса и на производительность систем, в которых они используются. Поэтому для обеспечения безопасности, эффективности, результативности, удобства использования и устойчивости продуктов и услуг важно, чтобы процесс разработки информационных требований соответствовал поставленным целям.
Таким образом, по крайней мере на первый взгляд, основой хорошо спроектированного интерфейса является установление:
(1) какая информация требуется;
(2) когда её нужно отображать;
(3) где она должна отображаться;
(4) кому она должна отображаться;
(5) как — в каком формате.
Принятие решений лежит в основе всех задач управления. Было множество попыток смоделировать деятельность по принятию решений. Большинство из них включают некоторую форму наблюдения информации, ориентации в текущей ситуации, выбора действия и, наконец, самого действия.
Лестница решений (Rasmussen, 1974) — это инструмент, наиболее часто используемый в рамках когнитивного анализа работы (Cognitive Work Analysis) для описания деятельности по принятию решений. В отличие от некоторых других моделей, её фокус направлен на весь процесс принятия решений, а не только на момент выбора между вариантами.
Она не привязана к какому-либо одному актору, а представляет процесс принятия решений всей рабочей системы в целом. Во многих случаях процесс принятия решений может быть совместным и распределённым между различными человеческими и техническими лицами, принимающими решения. Ожидается, что начинающие пользователи (в данной ситуации) будут проходить лестницу решений линейно. Левая сторона лестницы решений представляет наблюдение текущего состояния системы, а правая — планирование и выполнение задач и процедур для достижения целевого состояния системы.
Метод выявления системных информационных требований основан на серии полуструктурированных интервью с экспертами системы и/или заинтересованными сторонами. Эти интервью строятся вокруг шаблона, в центре которого находится лестница решений. Процесс заключается в фиксации вопросов, которые лица, принимающие решения, задают себе и системе на каждом этапе процесса принятия решений. Для каждой ключевой ситуации следует создавать отдельную модель. Такие ситуации обычно выявляются с помощью шаблона контекстной деятельности или иерархического анализа задач (HTA).
Этап 0 – Определение шагов задачи
Перед началом интервью деятельность следует разложить на отдельные части. Оптимальный метод декомпозиции зависит от системы. Деятельности, которые легко разделяются на ряд заметно различающихся шагов задачи, лучше всего декомпозировать с помощью методов анализа задач, таких как иерархический анализ задач (HTA). Деятельности, определяемые скорее условиями среды (например, местоположением), лучше декомпозировать с помощью шаблона контекстной деятельности. Для каждого шага задачи или ситуации следует создавать отдельную лестницу решений.
Этап 1 – Определение цели
Этап 2 – Оповещение (Alert)
Эксперта следует попросить начать прохождение процесса с его хронологического начала. Оповещения фиксируют события, которые впервые привлекают внимание к необходимости принятия решения
Этап 3 – Информация
Эксперта просят перечислить информационные элементы, которые он использовал бы для понимания ситуации. Информационные элементы — это «крупицы» информации, которые можно объединить, чтобы понять состояние системы.
Этап 4 – Состояние системы
Состояния системы представляют собой воспринятое понимание рабочей системы, основанное на интерпретации ряда информационных элементов. Ключевое отличие между информационным элементом и состоянием системы состоит в том, что состояния системы формируются из более чем одного количественно различного элемента информации
Этап 5 – Варианты (Options)
Варианты в лестнице можно описать как возможности изменить состояние системы с целью достижения общей цели. Пункты формулируются в виде вопросов: «Возможно ли (…)»?
Этап 6 – Выбранная цель
Выбранная цель в любой момент времени определяется тем, какому из ограничений отдаётся наивысший приоритет. Здесь можно указать на те цели, которые являются промежуточными или необходимыми для ситуации
Этап 7 – Целевое состояние
Целевые состояния зеркально отражают доступные варианты: как только выбран конкретный вариант, он становится целевым состоянием.
В общем на лестнице принятия решений предполагается отрисовать два пути
Сначала - левая сторона идёт вверх
От оповещения (Alert) → информации → состояния системы → диагностики.
Здесь человек поднимается от сырых данных к пониманию ситуации и целям (от skill-based / rule-based к knowledge-based уровню).
А затем - правая сторона идёт вниз
От выбранной цели (Chosen Goal) → целевого состояния → задач → процедур → выполнения.
Здесь человек спускается от абстрактной цели к конкретным действиям, которая является реакцией на алерты и состояния системы
Forwarded from Цифровой геноцид
В советских книжках, например, Галактионова о проектировании тоже можно найти что-то подобное, кстати, но описанная процедура более интересна, что она позволяет пройтись по интерфейсу, который уже создает проблемы