#инфоарх /// Информационная архитектура 2021
Устанавливаю в очередной раз собственное понимание информационной архитектуры (ИА).
Пререквизит:
1) Определение ИА от 22 марта 2021: "информационная архитектура — самое важное про интерпретацию системы агентом".
2) Критика ИА как дисциплины, серия 1 (2003), серия 2 (2004) — "ИА не есть дисциплина, а лишь новый должностной/профессиональный лэйбл"; ИА не формирует новых сущностей в проектировании, но является сборников таковых из других дисциплин.
3) Мысль о том, что ИА есть всегда, независимо от того, планировалось ли её разработать/создать/настроить. Она есть, хорошая или плохая.
Я готов согласиться, что ИА не является дисциплиной. Действительно, все практики, выполняемые для проработки успешной интерпретации (собственно, для проработки ИА) — практики проектирования архитектуры данных, интерфейса пользователя, семантических настроек системы. Если взять одну из "раскадровок" проработки ИА, то ровно это мы и получим:
- онтология и семантика — дисциплины логики, онтологии, лингвистики/стилистики, etc;
- структура, таксономия, классификация — дисциплины систематики;
- оркестровка, дирижирование, хореография — use-case-ориентированные дисциплины: проектирование ПО и системная инженерия.
Также стоит упомянуть про широчайший разброс определения ИА от тех, кто этой ИА занимается. Посмотрите любой WIAD — множество докладов начинаются с определения что есть информационная архитектура, и все эти определения разные, вольно трактуемые. Цельного определения нет, и об этом прямо пишут.
При этом я не готов отрицать наличие ИА в системах. И тем более не готов отрицать её важность. Повторю свою мысль снова: ИА есть всегда, хорошая или плохая. Важно то внимание, которое ей уделяется.
Вся эта ситуация похожа на свистопляску вокруг UX, который есть следствие, как и ИА. Он есть всегда, хороший или плохой, вопрос в том кто его прорабатывает и с помощью каких практик. Если ты работаешь над UI для улучшения UX, то ты UI-дизайнер. Если ты работаешь над сценариями взаимодействия с продуктом/сервисом, то ты product/service-дизайнер (хотя справедливости ради в любом случае, даже если у продукта/сервиса множество каналов, взаимодействие-то через интерфейс, то есть все эти приставки product/service — всё равно про UI).
Продавец на рынке, раскладывающий товар по группам, позволяющий выбирать самостоятельно экземпляры товара, предлагающий упаковку — тоже UX-дизайнер, влияет на опыт приобретения овощей-фруктов-etc. Результатом работы всякого дизайнера в любом случае будет опыт использования, хороший или плохой.
И в любом случае у продукта/сервиса/системы будет как-то организована информация, упакована в какую-то архитектуру — а значит и ИА в любом случае будет. И она влияет на UX, она его часть (здесь должны быть ссылка про affordance, но она у меня пока только в заготовке, будет нескоро).
Итого:
- Информационная архитектура есть часть UX, тот опыт "понятности"/"интерпретируемости" системы (тянет написать "квалиа интерпретации").
- Нет цельной практики информационной архитектуры, однако есть ряд практик, позволяющих качественно проработать ИА в создаваемом продукте; эти практики очень близки к практикам проектирования систем. Хорошая ИА есть результат выполнения практик проектирования.
ИА не есть дисциплина, но ИА зависит от выполнения практик по дисциплинам проектирования.
__
#инфоарх #информационная_архитектура #дисциплина #практика #интерфейс #ui #ux
Устанавливаю в очередной раз собственное понимание информационной архитектуры (ИА).
Пререквизит:
1) Определение ИА от 22 марта 2021: "информационная архитектура — самое важное про интерпретацию системы агентом".
2) Критика ИА как дисциплины, серия 1 (2003), серия 2 (2004) — "ИА не есть дисциплина, а лишь новый должностной/профессиональный лэйбл"; ИА не формирует новых сущностей в проектировании, но является сборников таковых из других дисциплин.
3) Мысль о том, что ИА есть всегда, независимо от того, планировалось ли её разработать/создать/настроить. Она есть, хорошая или плохая.
Я готов согласиться, что ИА не является дисциплиной. Действительно, все практики, выполняемые для проработки успешной интерпретации (собственно, для проработки ИА) — практики проектирования архитектуры данных, интерфейса пользователя, семантических настроек системы. Если взять одну из "раскадровок" проработки ИА, то ровно это мы и получим:
- онтология и семантика — дисциплины логики, онтологии, лингвистики/стилистики, etc;
- структура, таксономия, классификация — дисциплины систематики;
- оркестровка, дирижирование, хореография — use-case-ориентированные дисциплины: проектирование ПО и системная инженерия.
Также стоит упомянуть про широчайший разброс определения ИА от тех, кто этой ИА занимается. Посмотрите любой WIAD — множество докладов начинаются с определения что есть информационная архитектура, и все эти определения разные, вольно трактуемые. Цельного определения нет, и об этом прямо пишут.
При этом я не готов отрицать наличие ИА в системах. И тем более не готов отрицать её важность. Повторю свою мысль снова: ИА есть всегда, хорошая или плохая. Важно то внимание, которое ей уделяется.
Вся эта ситуация похожа на свистопляску вокруг UX, который есть следствие, как и ИА. Он есть всегда, хороший или плохой, вопрос в том кто его прорабатывает и с помощью каких практик. Если ты работаешь над UI для улучшения UX, то ты UI-дизайнер. Если ты работаешь над сценариями взаимодействия с продуктом/сервисом, то ты product/service-дизайнер (хотя справедливости ради в любом случае, даже если у продукта/сервиса множество каналов, взаимодействие-то через интерфейс, то есть все эти приставки product/service — всё равно про UI).
Продавец на рынке, раскладывающий товар по группам, позволяющий выбирать самостоятельно экземпляры товара, предлагающий упаковку — тоже UX-дизайнер, влияет на опыт приобретения овощей-фруктов-etc. Результатом работы всякого дизайнера в любом случае будет опыт использования, хороший или плохой.
И в любом случае у продукта/сервиса/системы будет как-то организована информация, упакована в какую-то архитектуру — а значит и ИА в любом случае будет. И она влияет на UX, она его часть (здесь должны быть ссылка про affordance, но она у меня пока только в заготовке, будет нескоро).
Итого:
- Информационная архитектура есть часть UX, тот опыт "понятности"/"интерпретируемости" системы (тянет написать "квалиа интерпретации").
- Нет цельной практики информационной архитектуры, однако есть ряд практик, позволяющих качественно проработать ИА в создаваемом продукте; эти практики очень близки к практикам проектирования систем. Хорошая ИА есть результат выполнения практик проектирования.
ИА не есть дисциплина, но ИА зависит от выполнения практик по дисциплинам проектирования.
__
#инфоарх #информационная_архитектура #дисциплина #практика #интерфейс #ui #ux
#дизайн /// UX-марафон 26. Проектирование сложных систем
Вчера состоялся 26-й UX-марафон, который я посмотрел и по мере возможности проконспектировал и сегодня в течение дня опубликую; 6 докладов — 6 постов.
Сам конспект на основе фраз, цитат и слайдов.
Мои комментарии даны курсивом и только там, где я не могу не высказаться.
Если мои комменты покажутся резкими — ну сорян : )
В конце каждого конспекта я пишу кратко впечатление + пытаюсь разложить основные мысли доклада через призму системного мышления.
———
#проектирование #UX #мероприятия
Вчера состоялся 26-й UX-марафон, который я посмотрел и по мере возможности проконспектировал и сегодня в течение дня опубликую; 6 докладов — 6 постов.
Сам конспект на основе фраз, цитат и слайдов.
Мои комментарии даны курсивом и только там, где я не могу не высказаться.
Если мои комменты покажутся резкими — ну сорян : )
В конце каждого конспекта я пишу кратко впечатление + пытаюсь разложить основные мысли доклада через призму системного мышления.
———
#проектирование #UX #мероприятия
#дизайн /// UX-марафон 26-1 — Проектирование сложных систем
Компьютерное зрение в сервисах Яндекса
Алексей Белицкий, Яндекс
(Рассказ про функцию “Умная камера” в приложении Яндекса)
1. Компьютерное зрение — ввод данных в компьютер через изображение
2. Для перевода изображения в данные используют алгоритмы, а для улучшения алгоритмов — нейронные сети
3. Сети обучаются через разметку, которую делают люди
4. Одно из актуальных применений — распознавание лиц
5. В Яндексе это применяется для распознавания актеров (Кинопоиск), дополнения составных фото-видео (авто.ру), etc
6. Продуктовые поиски Яндекса — что б такого сделать с компьютерным зрением? (То есть у вас есть функция, а цели нет, и вы думаете, куда б ее можно применить, для каких целей использовать… ну ладно, допустим)
7. Подборка уже существующих референсов приложений с компьютерным зрением
8. Применение двойного бриллианта (хм, ну в том виде как это рассказано, это частный случай V-диаграммы для придумывания)
9. Тестирование одной из концепций в UX-лабе Яндекса
10. Детальные пробы одного из интерфейсов (распознавание объектов на фото)
11. Мысли о режимах использования кадра (решение уравнений, перевод, сканер, etc)
12. Решение проблемы ощущения зависшей камеры — параллакс
13. “Выходить за рамки, но в рамках того, что уже сделано” (что? Разверните мысль, пожалуйста)
14. Статистика “что загружают в умную камеру”
15. Варианты обвеса результата поиск по фото, на примере авто
16. Аналогичные решения для фотографий еды и продуктов питания
17. Прочие нюансы отображения результата и его обвеса
18. Заключение:
- Mood board помогает выбрать стиль,
- двойной бриллиант позволяет выйти за рамки (как он помогает? И за рамки чего?),
- дизайнер должен влиять на продукт на каждом этапе (помимо того, что это очевидно, ничего не было сказано про сами этапы).
В целом доклад показался очень поверхностным, а скорее даже рекламой приложения яндекса и этой конкретной функции; про сложность систем не было сказано ничего.
Системно:
Компьютерное зрение — актуальная развивающаяся технология.
В докладе рассказано о том, для выполнения каких функций (для закрытия каких потребностей клиентов) можно применить такую технологию.
В общем виде технологии поддерживает практики; и было бы интересно узнать какие практики поддерживаются технологией компьютерного зрения. Очевидно, что спектр максимально широкий, так как любе визуальные данные можно поставлять на вход. В докладе речь шла в основном про поиск информации об объекте, это общая практика, входящая в более узкие, про которые было бы здорово услышать в будущем.
———
#проектирование #UX #мероприятия #практика #технология
Компьютерное зрение в сервисах Яндекса
Алексей Белицкий, Яндекс
(Рассказ про функцию “Умная камера” в приложении Яндекса)
1. Компьютерное зрение — ввод данных в компьютер через изображение
2. Для перевода изображения в данные используют алгоритмы, а для улучшения алгоритмов — нейронные сети
3. Сети обучаются через разметку, которую делают люди
4. Одно из актуальных применений — распознавание лиц
5. В Яндексе это применяется для распознавания актеров (Кинопоиск), дополнения составных фото-видео (авто.ру), etc
6. Продуктовые поиски Яндекса — что б такого сделать с компьютерным зрением? (То есть у вас есть функция, а цели нет, и вы думаете, куда б ее можно применить, для каких целей использовать… ну ладно, допустим)
7. Подборка уже существующих референсов приложений с компьютерным зрением
8. Применение двойного бриллианта (хм, ну в том виде как это рассказано, это частный случай V-диаграммы для придумывания)
9. Тестирование одной из концепций в UX-лабе Яндекса
10. Детальные пробы одного из интерфейсов (распознавание объектов на фото)
11. Мысли о режимах использования кадра (решение уравнений, перевод, сканер, etc)
12. Решение проблемы ощущения зависшей камеры — параллакс
13. “Выходить за рамки, но в рамках того, что уже сделано” (что? Разверните мысль, пожалуйста)
14. Статистика “что загружают в умную камеру”
15. Варианты обвеса результата поиск по фото, на примере авто
16. Аналогичные решения для фотографий еды и продуктов питания
17. Прочие нюансы отображения результата и его обвеса
18. Заключение:
- Mood board помогает выбрать стиль,
- двойной бриллиант позволяет выйти за рамки (как он помогает? И за рамки чего?),
- дизайнер должен влиять на продукт на каждом этапе (помимо того, что это очевидно, ничего не было сказано про сами этапы).
В целом доклад показался очень поверхностным, а скорее даже рекламой приложения яндекса и этой конкретной функции; про сложность систем не было сказано ничего.
Системно:
Компьютерное зрение — актуальная развивающаяся технология.
В докладе рассказано о том, для выполнения каких функций (для закрытия каких потребностей клиентов) можно применить такую технологию.
В общем виде технологии поддерживает практики; и было бы интересно узнать какие практики поддерживаются технологией компьютерного зрения. Очевидно, что спектр максимально широкий, так как любе визуальные данные можно поставлять на вход. В докладе речь шла в основном про поиск информации об объекте, это общая практика, входящая в более узкие, про которые было бы здорово услышать в будущем.
———
#проектирование #UX #мероприятия #практика #технология
#дизайн /// UX-марафон 26-2 — Проектирование сложных систем
Как сделать интерфейс атомной электростанции понятным для всех
Диана Ударцева, Никита Беллер, Тинькофф
(Рассказ про опыт проектирования внутренних бизнес-продуктов для профессиональных сотрудников — разработчики, аналитики, трейдеры, etc)
1. Какие задачи решают — берут данные и делают интерфейсы для работы с ними
2. Сложности со сложными системами
⁃ отсутствие референсов,
⁃ техническая сложность разработки,
⁃ проф-пользователи и их майндсет,
⁃ каждая задача — выход из зоны комфорта (кажется, имелось в виду, что каждая задача решается нетипичным образом; это имхо никак не связано с комфортом)
3. Порог входа VS эффективность интерфейса
⁃ “Продукт должен быть легким” — утопия для сложных интерфейсов;
⁃ человек с улицы НЕ должен сразу разобраться в сложном интерфейсе;
⁃ сразу закладывается обучаемость, etc
4. Пример: приложение для инвестиций — для всех, низкий порог входа, а терминал для трейдинга — для знающих трейдеров, высокий порог входа
5. Про мнимое упрощение — если бездумно упростить, то может получиться хуже, так как многие сложные/непонятные (массам) вещи являются якорями и ориентирами в сложных интерфейсах (показалось невнятно или не уловил мысль, изложил как понял )
6. Пример сложности с терминами, их не стоит упрощать, например, margin call, “ноут” — устоявшиеся термины; их упрощение — мнимое
7. Разрабатывайте на реальных данных — предполагаемые данные и их отображение могут не соответствовать реальности и моделирование нарушается
8. Учитывайте масштабируемость — заложите на будущее функционал + пример: шапка страницы под десяток пунктов, а их по факту на порядок больше
9. Определяйте ограничения заранее — выявляйте технический границы решений + пример, таблицы не получилось представить дашбордами, так как данные принимаются не в реальном времени, а раз в сутки
10. Прорабатывайте алгоритмы — работайте с (базовыми) сценариями, и только потом с интерфейсами
11. (Показан скрин диаграммы — гибрид bpmn и service blueprint)
12. Коммуницируйте с командой, особенно с аналитиками и разработчиками
13. Таймлайн жизни на проекте:
⁃ прогресс от полугода: 0-1 месяц это понимание “что вообще происходит” — потому что во внутренних системах проектировщик на является пользователем;
⁃ 2-4 месяц это стадия более уверенного решения задач, продолжаем постигать;
⁃ 5-8 месяц это стадия некоторой экспертизы, мышление базовыми и смежными сценариями, все равно продолжаем постигать;
⁃ примерно 1 год это стадия уверенной экспертизы, есть риск профдеформации и замыленности/зашоренности, продолжаем коммуницировать с коллегами, в тч из смежных направлений для размыливания.
14. Заключение: сложность — это прокачка софтовых и хордовых скиллов;
Хороший доклад, ориентированный на junior/middle-проектировщиков.
Системно:
⁃ Сформулирована “сложность” систем — отсутстивие или недоступность типовых решений, выделенная профессиональная аудитория (а она — один из основных стейкхолдеров),
⁃ Указано на назначение сложных систем — ими пользуются для выполнения профессиональных, рабочих задач (практик), а не повседневных и бытовых.
⁃ Сказано про язык коммуникации с пользователем — примеры с терминами и мнимым упрощением как раз про общение с аудиторией в его концептуальной сетке его языком.
- Моделирование на реальных данных — абсолютно согласен; важно моделировать на реальных данных, если есть возможность, это позволяет приблизить модель к отсечкам проверки и приемки.
- Сказано про работу с требованиями (правда другими словами) — масштабируемость и технические ограничения это именно работа с требованиями, их выявление, трассировка потребностей к требованиям, обозначение и снятие ограничений.
- Моделирование по сценариям — названо проработкой алгоритмов, но суть та же; все сценарные методы и фреймворки (JTBD, CJM, US map, Service Blueprint) действительно позволяют выявить теневые кейсы и учесть множество требований на ранних этапах.
———
#проектирование #UX #мероприятия #моделирование #коммуникация #требования
Как сделать интерфейс атомной электростанции понятным для всех
Диана Ударцева, Никита Беллер, Тинькофф
(Рассказ про опыт проектирования внутренних бизнес-продуктов для профессиональных сотрудников — разработчики, аналитики, трейдеры, etc)
1. Какие задачи решают — берут данные и делают интерфейсы для работы с ними
2. Сложности со сложными системами
⁃ отсутствие референсов,
⁃ техническая сложность разработки,
⁃ проф-пользователи и их майндсет,
⁃ каждая задача — выход из зоны комфорта (кажется, имелось в виду, что каждая задача решается нетипичным образом; это имхо никак не связано с комфортом)
3. Порог входа VS эффективность интерфейса
⁃ “Продукт должен быть легким” — утопия для сложных интерфейсов;
⁃ человек с улицы НЕ должен сразу разобраться в сложном интерфейсе;
⁃ сразу закладывается обучаемость, etc
4. Пример: приложение для инвестиций — для всех, низкий порог входа, а терминал для трейдинга — для знающих трейдеров, высокий порог входа
5. Про мнимое упрощение — если бездумно упростить, то может получиться хуже, так как многие сложные/непонятные (массам) вещи являются якорями и ориентирами в сложных интерфейсах (показалось невнятно или не уловил мысль, изложил как понял )
6. Пример сложности с терминами, их не стоит упрощать, например, margin call, “ноут” — устоявшиеся термины; их упрощение — мнимое
7. Разрабатывайте на реальных данных — предполагаемые данные и их отображение могут не соответствовать реальности и моделирование нарушается
8. Учитывайте масштабируемость — заложите на будущее функционал + пример: шапка страницы под десяток пунктов, а их по факту на порядок больше
9. Определяйте ограничения заранее — выявляйте технический границы решений + пример, таблицы не получилось представить дашбордами, так как данные принимаются не в реальном времени, а раз в сутки
10. Прорабатывайте алгоритмы — работайте с (базовыми) сценариями, и только потом с интерфейсами
11. (Показан скрин диаграммы — гибрид bpmn и service blueprint)
12. Коммуницируйте с командой, особенно с аналитиками и разработчиками
13. Таймлайн жизни на проекте:
⁃ прогресс от полугода: 0-1 месяц это понимание “что вообще происходит” — потому что во внутренних системах проектировщик на является пользователем;
⁃ 2-4 месяц это стадия более уверенного решения задач, продолжаем постигать;
⁃ 5-8 месяц это стадия некоторой экспертизы, мышление базовыми и смежными сценариями, все равно продолжаем постигать;
⁃ примерно 1 год это стадия уверенной экспертизы, есть риск профдеформации и замыленности/зашоренности, продолжаем коммуницировать с коллегами, в тч из смежных направлений для размыливания.
14. Заключение: сложность — это прокачка софтовых и хордовых скиллов;
Хороший доклад, ориентированный на junior/middle-проектировщиков.
Системно:
⁃ Сформулирована “сложность” систем — отсутстивие или недоступность типовых решений, выделенная профессиональная аудитория (а она — один из основных стейкхолдеров),
⁃ Указано на назначение сложных систем — ими пользуются для выполнения профессиональных, рабочих задач (практик), а не повседневных и бытовых.
⁃ Сказано про язык коммуникации с пользователем — примеры с терминами и мнимым упрощением как раз про общение с аудиторией в его концептуальной сетке его языком.
- Моделирование на реальных данных — абсолютно согласен; важно моделировать на реальных данных, если есть возможность, это позволяет приблизить модель к отсечкам проверки и приемки.
- Сказано про работу с требованиями (правда другими словами) — масштабируемость и технические ограничения это именно работа с требованиями, их выявление, трассировка потребностей к требованиям, обозначение и снятие ограничений.
- Моделирование по сценариям — названо проработкой алгоритмов, но суть та же; все сценарные методы и фреймворки (JTBD, CJM, US map, Service Blueprint) действительно позволяют выявить теневые кейсы и учесть множество требований на ранних этапах.
———
#проектирование #UX #мероприятия #моделирование #коммуникация #требования
#дизайн /// UX-марафон 26-3 — Проектирование сложных систем
Как мы проектируем медицинскую систему EMИAC
Дария Потеряхина, Solit Clouds
(Рассказ о процессе проектирования продуктов для системы; с примерами)
1. Solit Clouds разрабатывают продукты для системы ЕМИАС (примерно 70 интерфейсных продуктов, десктоп, планшет, мобильные); другие компании также разрабатывают продукты для ЕМИАС
2. Ключевые особенности разработки медицинской системы:
⁃ Особый нюанс при переносе сценариев с “бумаги” в “цифру”, например, работа с документами
⁃ Количество данных колоссально, необходимо обрабатывать много разнородной информации
3. Далее про процесс разработки в Solit Clouds:
⁃ Бизнес-анализ
⁃ проектирование интерфейсов
⁃ (параллельно с 2 и после) — системный анализ
⁃ описанные результаты из 2 и 3 передаются в разработку
⁃ тестирование
4. Слайд про усложнение этого процесса и взаимосмешивание шагов
5. Коммуникация необходима на каждом шаге и, важно, между шагами
6. Далее про ошибки — распространенные и допущенные:
⁃ Ошибка 1 — неумение грамотно задавать вопросы и задавать грамотные вопросы + нежелание задавать вопросы; + примеры из практики
⁃ Ошибка 2 — НЕфискирование договоренностей; + примеры из практики
⁃ Ошибка 3 — не управлять ожиданиями => не соответствовать им (на самом деле это про критерии приемки)
⁃ Ошибка 4 — не описывать макеты; + слайды с примерами не описанных альтернативных состояний, кейсов, etc
⁃ Ошибка 5 — принятие решений НЕ на основе метрик
⁃ Ошибка 6 — не прорабатывать состояния компонентов
⁃ Ошибка 7 — не прорабатывать альтернативные сценарии
7. Далее про решения, которые переросли в практики:
⁃ Решение 1 — после получения БТ нажначается встреча для обсуждения деталей и нюансов
⁃ Решение 2 — все решения фиксируются (конфлюенс, почта)
⁃ Решение 3 — проговаривается объем, срок и формат представления работ
⁃ Решение 4 — опираемся на результаты исследований и опросов
⁃ Решение 5 — макеты обязательно презентуются, а не просто высылаются
⁃ Решение 6 — интерфейс проектируется вместе с аналитиками и разработчиками
⁃ Решение 7 — в макетах обязательно проработаны состояния компонент, особенно нестандартных
8. Далее несколько слов про удаленный формат — необходимо поддерживать коммуникацию, удаленно она строится иначе; это ответственность руководителей и лидеров.
Доклад показался очень очевидным, интересен скорее тем, кто хочет узнать нюансы профессии, или специалистам на стадии стажёр/джуниор. Отмечу методологический вектор доклада — о том, КАК происходит процесс проектирования, с примерами, что весьма ценно для аудитории на старте. Однако, про сложность систем и как эту сложность уменьшать, ничего сказано не было.
Системно:
Речь идет о том, что сложные системы обеспечивают множество рабочих сценариев (а по факту практик, деятельностей) профессионалов, в том числе работу с документами и большой объем типовых кейсов (тиражирование запусков этой системы в обеспечении).
Процесс разработки — жизненный цикл проекта, и показана его модель в пошаговом (“Водопад”) виде и также очевидная несостоятельность этой модели в системах со многими интеграциями.
Сказано про коммуникацию — это и очевидно, что коммуникация необходима, стоит обозначить, что необходима в разрезе обсуждения интересов (в данном случае интересов проектных и внешних ролей, вместе с их предпочтениями в интересе и намерениями).
Ошибки — неудачные коммуникации, несогласованные методы описания и моделирования, неучтенных кейсы и неудачные верификации. Вполне логично, что они “намотаны на ус” и представлены следов в виде “решений” (а в идеале их упаковать в чеклисты для внутренней валидации).
Слова про удаленный формат это еще раз про коммуникацию и методы описания, которые меняются при изменении взаимодействия с оффлайн на онлайн.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ
Как мы проектируем медицинскую систему EMИAC
Дария Потеряхина, Solit Clouds
(Рассказ о процессе проектирования продуктов для системы; с примерами)
1. Solit Clouds разрабатывают продукты для системы ЕМИАС (примерно 70 интерфейсных продуктов, десктоп, планшет, мобильные); другие компании также разрабатывают продукты для ЕМИАС
2. Ключевые особенности разработки медицинской системы:
⁃ Особый нюанс при переносе сценариев с “бумаги” в “цифру”, например, работа с документами
⁃ Количество данных колоссально, необходимо обрабатывать много разнородной информации
3. Далее про процесс разработки в Solit Clouds:
⁃ Бизнес-анализ
⁃ проектирование интерфейсов
⁃ (параллельно с 2 и после) — системный анализ
⁃ описанные результаты из 2 и 3 передаются в разработку
⁃ тестирование
4. Слайд про усложнение этого процесса и взаимосмешивание шагов
5. Коммуникация необходима на каждом шаге и, важно, между шагами
6. Далее про ошибки — распространенные и допущенные:
⁃ Ошибка 1 — неумение грамотно задавать вопросы и задавать грамотные вопросы + нежелание задавать вопросы; + примеры из практики
⁃ Ошибка 2 — НЕфискирование договоренностей; + примеры из практики
⁃ Ошибка 3 — не управлять ожиданиями => не соответствовать им (на самом деле это про критерии приемки)
⁃ Ошибка 4 — не описывать макеты; + слайды с примерами не описанных альтернативных состояний, кейсов, etc
⁃ Ошибка 5 — принятие решений НЕ на основе метрик
⁃ Ошибка 6 — не прорабатывать состояния компонентов
⁃ Ошибка 7 — не прорабатывать альтернативные сценарии
7. Далее про решения, которые переросли в практики:
⁃ Решение 1 — после получения БТ нажначается встреча для обсуждения деталей и нюансов
⁃ Решение 2 — все решения фиксируются (конфлюенс, почта)
⁃ Решение 3 — проговаривается объем, срок и формат представления работ
⁃ Решение 4 — опираемся на результаты исследований и опросов
⁃ Решение 5 — макеты обязательно презентуются, а не просто высылаются
⁃ Решение 6 — интерфейс проектируется вместе с аналитиками и разработчиками
⁃ Решение 7 — в макетах обязательно проработаны состояния компонент, особенно нестандартных
8. Далее несколько слов про удаленный формат — необходимо поддерживать коммуникацию, удаленно она строится иначе; это ответственность руководителей и лидеров.
Доклад показался очень очевидным, интересен скорее тем, кто хочет узнать нюансы профессии, или специалистам на стадии стажёр/джуниор. Отмечу методологический вектор доклада — о том, КАК происходит процесс проектирования, с примерами, что весьма ценно для аудитории на старте. Однако, про сложность систем и как эту сложность уменьшать, ничего сказано не было.
Системно:
Речь идет о том, что сложные системы обеспечивают множество рабочих сценариев (а по факту практик, деятельностей) профессионалов, в том числе работу с документами и большой объем типовых кейсов (тиражирование запусков этой системы в обеспечении).
Процесс разработки — жизненный цикл проекта, и показана его модель в пошаговом (“Водопад”) виде и также очевидная несостоятельность этой модели в системах со многими интеграциями.
Сказано про коммуникацию — это и очевидно, что коммуникация необходима, стоит обозначить, что необходима в разрезе обсуждения интересов (в данном случае интересов проектных и внешних ролей, вместе с их предпочтениями в интересе и намерениями).
Ошибки — неудачные коммуникации, несогласованные методы описания и моделирования, неучтенных кейсы и неудачные верификации. Вполне логично, что они “намотаны на ус” и представлены следов в виде “решений” (а в идеале их упаковать в чеклисты для внутренней валидации).
Слова про удаленный формат это еще раз про коммуникацию и методы описания, которые меняются при изменении взаимодействия с оффлайн на онлайн.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ
Хороший доклад про исследования. Практики исследования упакованы в кустарный (в хорошем смысле) фреймворк, который используется, и, судя по рассказу, приносит профит.
Системно:
⁃ Снова дается определение — какие системы считать сложными; и снова среди признаков множество сущностей и связей между ними, множество сценариев упакованы в мета-сценарий.
⁃ Далее рассказ про разные уровни в системе, на которых применяются исследования. Похоже, что речь идет именно про системные уровни. Например, сквозное исследование направлено на весь жизненный цикл сервиса, а точечные исследования целятся в конкретные стадии этого цикла. Упомянутые быстрые исследования, вероятно, нацелены еще на более мелкие части системы в декомпозиции.
⁃ Два блока целиком посвящены коммуникации — работа с внутренними заказчиками и донесение результатов это самая коммуникация и есть. Цель этой коммуникации — обсудить интересы проектных ролей и договориться о методе описания и доступности рабочих артефактов.
⁃ Кейсы сквозного и точечного исследований подтверждают фокусировку на разных уровнях: глобально вся система и zoom-in на одну из подсистем.
⁃ Третий блок про коммуникацию — на этот раз с клиентом. Подробно расписан метод описания (инструкция для респондента).
⁃ Приведены наблюдения из практики (в данном случае имею в виду деятельность исследователя), используемые для донастройки метода / фреймворка.
Доклад показывает, что исследования это в первую очередь коммуникация; направлена в разные концы — респондент и коллеги, цели коммуникации отличаются; и фреймворки позволяют более слаженно выстроить и процесс и коммуникации.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ
Системно:
⁃ Снова дается определение — какие системы считать сложными; и снова среди признаков множество сущностей и связей между ними, множество сценариев упакованы в мета-сценарий.
⁃ Далее рассказ про разные уровни в системе, на которых применяются исследования. Похоже, что речь идет именно про системные уровни. Например, сквозное исследование направлено на весь жизненный цикл сервиса, а точечные исследования целятся в конкретные стадии этого цикла. Упомянутые быстрые исследования, вероятно, нацелены еще на более мелкие части системы в декомпозиции.
⁃ Два блока целиком посвящены коммуникации — работа с внутренними заказчиками и донесение результатов это самая коммуникация и есть. Цель этой коммуникации — обсудить интересы проектных ролей и договориться о методе описания и доступности рабочих артефактов.
⁃ Кейсы сквозного и точечного исследований подтверждают фокусировку на разных уровнях: глобально вся система и zoom-in на одну из подсистем.
⁃ Третий блок про коммуникацию — на этот раз с клиентом. Подробно расписан метод описания (инструкция для респондента).
⁃ Приведены наблюдения из практики (в данном случае имею в виду деятельность исследователя), используемые для донастройки метода / фреймворка.
Доклад показывает, что исследования это в первую очередь коммуникация; направлена в разные концы — респондент и коллеги, цели коммуникации отличаются; и фреймворки позволяют более слаженно выстроить и процесс и коммуникации.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ
#дизайн /// UX-марафон 26-5 — Проектирование сложных систем
Объектно-ориентированный UX
Алексей Сорокин, Мой склад
(Метод, применяемый для проектирования сложных продуктов и систем, основанный на ОО-практиках)
1. Есть дизайн “по-быстрому” — понять задачу > применить интуицию, опыт, здравый смысл, насмотренность > макет/гипотеза
2. Во втором шаге происходит “магия”
3. При применении JTBD, CJM, etc — задача уточняется, но “магия” остается
4. Статистика с прода, тестирования, etc — это все равно обвес вокруг “магии”, лишь уточняющий данные на вход
5. Макет/гипотеза — подчиняется циклу гипотеза > эксперимент > сбор данных > анализ и вывод; цикл стоит денег
6. Чем точнее гипотеза, тем меньше циклов
7. Сложный продукт — где много сценариев; аналогия: сам интернет-магазин это поезд, он едет по рельсам, а админка интернет-магазина это самолет, он летает как хочет
8. В сложном продукте тем более цикл выглядит так: гипотеза > эксперимент > сбор данных > “магия”
9. “Попробуем без сценариев” (без сценариев? Интересно как это…)
10. Три вопроса про пользователя: каков его опыт? в каком состоянии/контексте пользователь? использует систему чтобы что?
⁃ На первые два вопроса отвечает метод персон, на третий отвечает jtbd
⁃ Задачи в персонах — это job в jtbd
11. Пользователь работает с объектами; работа = действие + объект + контекст
12. Далее про связь объектов и их обозначений
13. Объект в системе: у него есть свойства, методы, представления
⁃ Свойства — атрибуты объекта, то, как его можно охарактеризовать
⁃ Методы — действия, которые можно сделать с объектом
⁃ Представления объекта — проекция объекта из ментальной модели пользователя на интерфейс; полное представление есть перечисление всех его свойств и методов; например, в навигации используются краткие представления объектов
14. Принципы работы с представлениями:
⁃ Нужно полное представление объекта — вся информация для создания проекций; пример: карточка объекта
⁃ Нужен полный набор допустимых действий над объектом
⁃ Нужно дать пользователю контроль над “его” объектами
⁃ Если связь между объектами есть, то ее необходимо показать в интерфейсе
15. Далее про сценарии:
⁃ На основе сценариев выбираем представления объектов в контекстах
⁃ Также на основе сценариев строим порядок представления объектов
⁃ На основе сценариев понимаем необходимый набор представлений
⁃ И также на основе сценариев …не успел записать…
16. Для работы с объектами помогает ER-диаграмма, отражающая набор объектов, их свойства и методы, и связи объектов
17. Заключение — что дает OOUX:
⁃ Доп. инструмент проектирования
⁃ Меньше “магии” и больше аргументировать
⁃ “Меньше интуиции, больше логики”
⁃ Можно не держать в голове сложные объекты
Доклад на важную тему — о том как превратить интуицию и “магию” проектирования в объясняемые паттерны.
Что хорошо — доклад вызывает интерес к моделированию на концептуальном уровне.
Что плохо — не звучало убедительно: да, есть объекты и у них есть свойства и представления; но как связаны объекты и функции (операции пользователя, поддерживаемые интерфейсом)? Методы и функции? Непонятно, почему на первое место выносится то, что можно делать с объектом, а не то, что делает пользователь (та самая Job из jtbd).
Я ожидал развитие доклада с Profsoux-2020, но показалось даже более смазанным.
На январском UX-марафоне про ИА был доклад на почти эту же тему, мне он показался более цельным.
Системно:
⁃ Сделана попытка рассмотреть моделирование сценариев через модули системы — названы объектами, — обеспечивающие операции — названы методами, но в пассивном рассмотрении: действия “над объектом” вместо “модуль выполняет функцию F”.
⁃ Показалось, что есть попытка рассмотреть метод вне сценарной парадигмы, но я не понял, как от неё отказаться, так как про цели-операции-действия пользователя не было сказано.
———
#проектирование #UX #мероприятия #функция #модуль #сервис
Объектно-ориентированный UX
Алексей Сорокин, Мой склад
(Метод, применяемый для проектирования сложных продуктов и систем, основанный на ОО-практиках)
1. Есть дизайн “по-быстрому” — понять задачу > применить интуицию, опыт, здравый смысл, насмотренность > макет/гипотеза
2. Во втором шаге происходит “магия”
3. При применении JTBD, CJM, etc — задача уточняется, но “магия” остается
4. Статистика с прода, тестирования, etc — это все равно обвес вокруг “магии”, лишь уточняющий данные на вход
5. Макет/гипотеза — подчиняется циклу гипотеза > эксперимент > сбор данных > анализ и вывод; цикл стоит денег
6. Чем точнее гипотеза, тем меньше циклов
7. Сложный продукт — где много сценариев; аналогия: сам интернет-магазин это поезд, он едет по рельсам, а админка интернет-магазина это самолет, он летает как хочет
8. В сложном продукте тем более цикл выглядит так: гипотеза > эксперимент > сбор данных > “магия”
9. “Попробуем без сценариев” (без сценариев? Интересно как это…)
10. Три вопроса про пользователя: каков его опыт? в каком состоянии/контексте пользователь? использует систему чтобы что?
⁃ На первые два вопроса отвечает метод персон, на третий отвечает jtbd
⁃ Задачи в персонах — это job в jtbd
11. Пользователь работает с объектами; работа = действие + объект + контекст
12. Далее про связь объектов и их обозначений
13. Объект в системе: у него есть свойства, методы, представления
⁃ Свойства — атрибуты объекта, то, как его можно охарактеризовать
⁃ Методы — действия, которые можно сделать с объектом
⁃ Представления объекта — проекция объекта из ментальной модели пользователя на интерфейс; полное представление есть перечисление всех его свойств и методов; например, в навигации используются краткие представления объектов
14. Принципы работы с представлениями:
⁃ Нужно полное представление объекта — вся информация для создания проекций; пример: карточка объекта
⁃ Нужен полный набор допустимых действий над объектом
⁃ Нужно дать пользователю контроль над “его” объектами
⁃ Если связь между объектами есть, то ее необходимо показать в интерфейсе
15. Далее про сценарии:
⁃ На основе сценариев выбираем представления объектов в контекстах
⁃ Также на основе сценариев строим порядок представления объектов
⁃ На основе сценариев понимаем необходимый набор представлений
⁃ И также на основе сценариев …не успел записать…
16. Для работы с объектами помогает ER-диаграмма, отражающая набор объектов, их свойства и методы, и связи объектов
17. Заключение — что дает OOUX:
⁃ Доп. инструмент проектирования
⁃ Меньше “магии” и больше аргументировать
⁃ “Меньше интуиции, больше логики”
⁃ Можно не держать в голове сложные объекты
Доклад на важную тему — о том как превратить интуицию и “магию” проектирования в объясняемые паттерны.
Что хорошо — доклад вызывает интерес к моделированию на концептуальном уровне.
Что плохо — не звучало убедительно: да, есть объекты и у них есть свойства и представления; но как связаны объекты и функции (операции пользователя, поддерживаемые интерфейсом)? Методы и функции? Непонятно, почему на первое место выносится то, что можно делать с объектом, а не то, что делает пользователь (та самая Job из jtbd).
Я ожидал развитие доклада с Profsoux-2020, но показалось даже более смазанным.
На январском UX-марафоне про ИА был доклад на почти эту же тему, мне он показался более цельным.
Системно:
⁃ Сделана попытка рассмотреть моделирование сценариев через модули системы — названы объектами, — обеспечивающие операции — названы методами, но в пассивном рассмотрении: действия “над объектом” вместо “модуль выполняет функцию F”.
⁃ Показалось, что есть попытка рассмотреть метод вне сценарной парадигмы, но я не понял, как от неё отказаться, так как про цели-операции-действия пользователя не было сказано.
———
#проектирование #UX #мероприятия #функция #модуль #сервис
#дизайн /// UX-марафон 26-6 — Проектирование сложных систем
Философия производства сложных интерфейсов
Алексей Курлаев, Сбер
(Попытка ответить на вопросы про сложные системы, заданные в чате)
1. Что считать сложными системами — (не все простые системы внутри просты и наоборот) — вот такие:
⁃ Критично важно стоит вопрос о скорости решения сценария (решения сценария? Что это значит???)
⁃ Сценариев много. Основных может быть около 10, но суммарно будет на порядок больше
⁃ Пользователи продвинуты, их можно назвать “операторами интерфейса” (это правда)
⁃ Место на экране плотно забито, подчинено строгой иерархии/навигации, к месту на экране относимся критично (это очень натянуто, тогда и выдачу товаров в Amazon можно назвать сложными и покупателей считать операторами интернет-магазина)
2. Продуктовый дизайнер VS дизайнер сложных систем
⁃ Разные пользователи — массовый VS “Оператор” (вот это TRUE)
⁃ Работа на проекте — 1-2 года VS 3+ или всю жизнь (ну блин, неправда, при хорошем кругозоре и опыте можно и за год на сложных системах трудиться продуктивно)
⁃ Пример с редизайном Flash — с Macromedia на Adobe, с “подстройкой” под интерфейс Фотошопа, Иллюстратора, etc; здесь сложный проф-интерфейс, пользователь принимает такое, переучивается.
⁃ Пример с редизайном Кинопоиска — здесь публичный массовый интерфейс, пользователь негодует, протестует.
3. Какие навыки необходимы для проектирования сложных систем, но не обязательны для проектирования простых
⁃ Методы исследований — опросные (интервью, фокус-группа, анекты) и неопросные (наблюдение, эксперимент, анализ)
⁃ Про тепловую карту — это пример про большие и малые данные — 10к и 100к (серьезно? 10К и 100К это малые и большие данные? про саму тепловую карту VS коридорку TRUE)
4. Работа с пользователем массового продукта
⁃ Анализ больших объемов пользователей (что за бред? Есть множество сложных систем с относительно небольшой аудиторией и массовых продуктов с почти бескрайней аудиторией)
⁃ Критичность “модного” дизайна
⁃ Навыки интуитивного дизайна (Что такое интуитивный дизайн? может имеется в виду интуитивный интерфейс?)
5. Работа с пользователем массового продукта
⁃ интервью с пользователем — основной инструмент работы со сложными системами
⁃ Стоит учитывать работу памяти человека: внушение, заблуждение, критичность кол-ва интервью и выбор способа проведения, столкновение интересов…
⁃ Аналитические навыки в продукте (ну тут без них никуда, надо уметь в анализ, с этим не поспорить)
⁃ Навыки работы с пространством — скорость важнее удобства (что есть скорость и что есть удобство в этом контексте понять не удалось)
6. Лучшие (а также не лучшие, но используемые) практики “удержания всего вместе, чтобы ничего не упустить” — Расстановка приоритетов: ИА > сбор инфо о тех.ограничениях > редизайн системы (размыто сформулировано; звучит так, что ИА важнее учета технических ограничений, но если так, то на стоит ли проанализировать взаимные влияния ИА и этих ограничений?)
7. Общий journey map — оказалось, что для пользователя два продукта воспринимались как один.
Доклад в целом расстроил, показался непоследовательным. Многие утверждения хоть и верные, но они как будто понадерганы из разных частей большего (раз так в 10) доклада.
Системно:
⁃ Делается попытка объяснения какую систему считать сложной — пользователи-профессионалы, которые с помощью интерфейса выполняют рабочие практики, функций много и потому сценариев в интерфейсе много и они сильно ветвятся => интерфейс насыщен, чтобы это множество сценариев/функций поддержать.
⁃ Упоминается практика проектирования — исследования (опросы и эксперименты); её корректно считать одной из основных, так как пользователь один из основных стейкхолдеров, выявление его интересов-предпочтений-намерений возможно через исследования.
⁃ Упомянуты приоритеты в работе, это практики на стыке (само)менеджмента — какие работы выполнять в какую очередь.
———
#проектирование #UX #мероприятия #практика #менеджмент #исследования #роли
Философия производства сложных интерфейсов
Алексей Курлаев, Сбер
(Попытка ответить на вопросы про сложные системы, заданные в чате)
1. Что считать сложными системами — (не все простые системы внутри просты и наоборот) — вот такие:
⁃ Критично важно стоит вопрос о скорости решения сценария (решения сценария? Что это значит???)
⁃ Сценариев много. Основных может быть около 10, но суммарно будет на порядок больше
⁃ Пользователи продвинуты, их можно назвать “операторами интерфейса” (это правда)
⁃ Место на экране плотно забито, подчинено строгой иерархии/навигации, к месту на экране относимся критично (это очень натянуто, тогда и выдачу товаров в Amazon можно назвать сложными и покупателей считать операторами интернет-магазина)
2. Продуктовый дизайнер VS дизайнер сложных систем
⁃ Разные пользователи — массовый VS “Оператор” (вот это TRUE)
⁃ Работа на проекте — 1-2 года VS 3+ или всю жизнь (ну блин, неправда, при хорошем кругозоре и опыте можно и за год на сложных системах трудиться продуктивно)
⁃ Пример с редизайном Flash — с Macromedia на Adobe, с “подстройкой” под интерфейс Фотошопа, Иллюстратора, etc; здесь сложный проф-интерфейс, пользователь принимает такое, переучивается.
⁃ Пример с редизайном Кинопоиска — здесь публичный массовый интерфейс, пользователь негодует, протестует.
3. Какие навыки необходимы для проектирования сложных систем, но не обязательны для проектирования простых
⁃ Методы исследований — опросные (интервью, фокус-группа, анекты) и неопросные (наблюдение, эксперимент, анализ)
⁃ Про тепловую карту — это пример про большие и малые данные — 10к и 100к (серьезно? 10К и 100К это малые и большие данные? про саму тепловую карту VS коридорку TRUE)
4. Работа с пользователем массового продукта
⁃ Анализ больших объемов пользователей (что за бред? Есть множество сложных систем с относительно небольшой аудиторией и массовых продуктов с почти бескрайней аудиторией)
⁃ Критичность “модного” дизайна
⁃ Навыки интуитивного дизайна (Что такое интуитивный дизайн? может имеется в виду интуитивный интерфейс?)
5. Работа с пользователем массового продукта
⁃ интервью с пользователем — основной инструмент работы со сложными системами
⁃ Стоит учитывать работу памяти человека: внушение, заблуждение, критичность кол-ва интервью и выбор способа проведения, столкновение интересов…
⁃ Аналитические навыки в продукте (ну тут без них никуда, надо уметь в анализ, с этим не поспорить)
⁃ Навыки работы с пространством — скорость важнее удобства (что есть скорость и что есть удобство в этом контексте понять не удалось)
6. Лучшие (а также не лучшие, но используемые) практики “удержания всего вместе, чтобы ничего не упустить” — Расстановка приоритетов: ИА > сбор инфо о тех.ограничениях > редизайн системы (размыто сформулировано; звучит так, что ИА важнее учета технических ограничений, но если так, то на стоит ли проанализировать взаимные влияния ИА и этих ограничений?)
7. Общий journey map — оказалось, что для пользователя два продукта воспринимались как один.
Доклад в целом расстроил, показался непоследовательным. Многие утверждения хоть и верные, но они как будто понадерганы из разных частей большего (раз так в 10) доклада.
Системно:
⁃ Делается попытка объяснения какую систему считать сложной — пользователи-профессионалы, которые с помощью интерфейса выполняют рабочие практики, функций много и потому сценариев в интерфейсе много и они сильно ветвятся => интерфейс насыщен, чтобы это множество сценариев/функций поддержать.
⁃ Упоминается практика проектирования — исследования (опросы и эксперименты); её корректно считать одной из основных, так как пользователь один из основных стейкхолдеров, выявление его интересов-предпочтений-намерений возможно через исследования.
⁃ Упомянуты приоритеты в работе, это практики на стыке (само)менеджмента — какие работы выполнять в какую очередь.
———
#проектирование #UX #мероприятия #практика #менеджмент #исследования #роли