#инфоарх /// Интерпретируемость
Пользователь "общается" с системой для достижения цели, используя интерфейс. Интерфейсом является всё, с чем пользователь взаимодействует:
- адресный контент, который он ищет, с которым работает;
- навигация, по которой он добирается до этого адресного контента.
(а все остальное можно свести к этим двум)
Чтобы достигнуть цели, пользователь "читает" интерфейс, а в процессе чтения интерпретирует его в концепты, которыми мыслит.
Верно прочитанный интерфейс — понятый таким образом, чтобы достигнуть цели кратчайшим путем.
Та степень, в которой интерфейс верно понимается — его интерпретируемость.
Информационная архитетктура служит для увеличения интерпретируемости.
Интерпретируемость наряду с находимостью (findability) и доступностью (accessibility) является частью общего понятия эргономики (usability).
Интерпретируемость складывается не только из семантики (связь обозначения контента и самого контента, связь ярлыка и элемента за этим ярлыком), но также из считывания контекста, возможности для пользователя быстро прочитать конструкцию:
- я нахожусь в___,
- для того, чтобы___
- я попал сюда из___,
- и дальше я перейду к___.
Эта конструкция объединяет свойства находимости и назначения, включенные в "прочтение", и дающие в результате интерпретируемость.
__
#информационная_архитектура #интерфейс #навигация
Пользователь "общается" с системой для достижения цели, используя интерфейс. Интерфейсом является всё, с чем пользователь взаимодействует:
- адресный контент, который он ищет, с которым работает;
- навигация, по которой он добирается до этого адресного контента.
(а все остальное можно свести к этим двум)
Чтобы достигнуть цели, пользователь "читает" интерфейс, а в процессе чтения интерпретирует его в концепты, которыми мыслит.
Верно прочитанный интерфейс — понятый таким образом, чтобы достигнуть цели кратчайшим путем.
Та степень, в которой интерфейс верно понимается — его интерпретируемость.
Информационная архитетктура служит для увеличения интерпретируемости.
Интерпретируемость наряду с находимостью (findability) и доступностью (accessibility) является частью общего понятия эргономики (usability).
Интерпретируемость складывается не только из семантики (связь обозначения контента и самого контента, связь ярлыка и элемента за этим ярлыком), но также из считывания контекста, возможности для пользователя быстро прочитать конструкцию:
- я нахожусь в___,
- для того, чтобы___
- я попал сюда из___,
- и дальше я перейду к___.
Эта конструкция объединяет свойства находимости и назначения, включенные в "прочтение", и дающие в результате интерпретируемость.
__
#информационная_архитектура #интерфейс #навигация
#дизайн /// 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 #мероприятия #метод_описания #коммуникация #ЖЦ
#дизайн /// UX-марафон 26-4 — Проектирование сложных систем
UX-исследования сложных систем: как проводить и выстроить плодотворные отношения с заказчиками
Анна Черныш, ВКонтакте для бизнеса
(Рассказ о том, как устроены исследования в большой бизнесовой платформе)
1. Рассказ будет не про юзабилити, а про UX в целом
2. Почему Реклама VK сложный продукт:
⁃ два продукта — навороченный декстоп для профи-спецов и приложение попроще для мелких общих рекламных задач
⁃ широкая функциональность; много сущностей
⁃ много частей в общем сценарии, составные сценарии и программы сценариев
3. Далее про подход — исследовать на разных уровнях: точечные, быстрые, сквозные
⁃ Точечные исследования — выявляется потребности, восприятие конкурентов, воскр новых фичей, etc
⁃ Сквозные — выявить целиком весь путь через платформу, выявить проблемы переходов между стадиями/модулями платформы, проанализировать ключевые фичи, провести аудит текущего продуктов; такие исследования важно делать постоянно, по сути это постоянный мониторинг взаимодействия пользователя со всей платформой — это требует инициативы исследователей
⁃ Быстрые тестирования — принять решение по конкретному вопросу, фиче
4. Далее про работу с внутренними заказчиками:
⁃ Следить за контекстом — участие в синках, чатах, етс
⁃ Общение даже при наличии подробного брифа
⁃ Построение коммуникации между всеми СХ и участниками
⁃ Инициировать исследования в проблемных точках
⁃ Публиковать позитивные случаи из набор исследований — канал с положительным фидбэком и веселыми историями
⁃ “Живой справочник” по пользователям — живая база знаний или хранитель базы знаний
5. Далее про донесение результатов — это ответственность исследователей:
⁃ Инсайт или проблема до подготовки отчета сразу отправляется в тематический чат
⁃ Разные форматы для отчета — длинный с подробностями и краткий + все инсайты собираются в отдельный CJM
⁃ Обеспечить прозрачность — отчеты и записи (не только отчеты) доступны всей команде и не только заказчикам
⁃ Пересылка инсайтов конкретным людям — на основании знания или гипотезы, что этом человеку пригодится этот инсайт
⁃ Регулярный возврат за фидбэком решена ли проблема
6. Далее про кейсы — точечное и сквозное исследование:
⁃ Кейс точечного исследования — про смещение выбора формата на выбор цели: клиент раньше выбирал формат, а стал выбирать цель, и уже по цели подбирался формат — слайд с программой тестирования; важные нюансы: лучше пойти к респондентам кто еще не рассказывал про это взаимодействие, интервью в начале задает контекст, тестируйте все макеты что есть даже если уже команда склонна выбрать какой-то.
⁃ Кейс сквозного исследования — дневник для новичка, запускающего рекламу в ВК; решение — снятие видео экрана с параллельным комментирование пользователем; какие этапы 1) заманить, было приглашение 2) вводное интервью 3) подробная инструкция 4) сам дневник в видео 5) ответы на вопросы команды, впечатления 6) заключительное интервью — было 10 человек
7. Как писать инструкцию — цели, что требуется, длительность, вознаграждение, все правила участия (в тч про возможность выхода), инструкция как записывать дневник, вопросы для итога
8. Еще нюансы:
⁃ Вознаграждение больше обычного — надо обсуждать с юристами: есть ограничения по величине вознаграждения
⁃ Оплата по этапам — 30% после первого видео, 70% после завершения + многие соглашались в тч из-за возможности пообщаться с командой и получить консультацию
⁃ 20% не дошли до конца
⁃ Просмотр и вопросы надо просматривать сразу же после получения от респондента, чтобы нюансы уточнить у него пока она помнит
⁃ Саммари (от респондента) помогает запустить рефлексию, самоописание эмоций работает плохо, люди не склонны описывать свои эмоции
UX-исследования сложных систем: как проводить и выстроить плодотворные отношения с заказчиками
Анна Черныш, ВКонтакте для бизнеса
(Рассказ о том, как устроены исследования в большой бизнесовой платформе)
1. Рассказ будет не про юзабилити, а про UX в целом
2. Почему Реклама VK сложный продукт:
⁃ два продукта — навороченный декстоп для профи-спецов и приложение попроще для мелких общих рекламных задач
⁃ широкая функциональность; много сущностей
⁃ много частей в общем сценарии, составные сценарии и программы сценариев
3. Далее про подход — исследовать на разных уровнях: точечные, быстрые, сквозные
⁃ Точечные исследования — выявляется потребности, восприятие конкурентов, воскр новых фичей, etc
⁃ Сквозные — выявить целиком весь путь через платформу, выявить проблемы переходов между стадиями/модулями платформы, проанализировать ключевые фичи, провести аудит текущего продуктов; такие исследования важно делать постоянно, по сути это постоянный мониторинг взаимодействия пользователя со всей платформой — это требует инициативы исследователей
⁃ Быстрые тестирования — принять решение по конкретному вопросу, фиче
4. Далее про работу с внутренними заказчиками:
⁃ Следить за контекстом — участие в синках, чатах, етс
⁃ Общение даже при наличии подробного брифа
⁃ Построение коммуникации между всеми СХ и участниками
⁃ Инициировать исследования в проблемных точках
⁃ Публиковать позитивные случаи из набор исследований — канал с положительным фидбэком и веселыми историями
⁃ “Живой справочник” по пользователям — живая база знаний или хранитель базы знаний
5. Далее про донесение результатов — это ответственность исследователей:
⁃ Инсайт или проблема до подготовки отчета сразу отправляется в тематический чат
⁃ Разные форматы для отчета — длинный с подробностями и краткий + все инсайты собираются в отдельный CJM
⁃ Обеспечить прозрачность — отчеты и записи (не только отчеты) доступны всей команде и не только заказчикам
⁃ Пересылка инсайтов конкретным людям — на основании знания или гипотезы, что этом человеку пригодится этот инсайт
⁃ Регулярный возврат за фидбэком решена ли проблема
6. Далее про кейсы — точечное и сквозное исследование:
⁃ Кейс точечного исследования — про смещение выбора формата на выбор цели: клиент раньше выбирал формат, а стал выбирать цель, и уже по цели подбирался формат — слайд с программой тестирования; важные нюансы: лучше пойти к респондентам кто еще не рассказывал про это взаимодействие, интервью в начале задает контекст, тестируйте все макеты что есть даже если уже команда склонна выбрать какой-то.
⁃ Кейс сквозного исследования — дневник для новичка, запускающего рекламу в ВК; решение — снятие видео экрана с параллельным комментирование пользователем; какие этапы 1) заманить, было приглашение 2) вводное интервью 3) подробная инструкция 4) сам дневник в видео 5) ответы на вопросы команды, впечатления 6) заключительное интервью — было 10 человек
7. Как писать инструкцию — цели, что требуется, длительность, вознаграждение, все правила участия (в тч про возможность выхода), инструкция как записывать дневник, вопросы для итога
8. Еще нюансы:
⁃ Вознаграждение больше обычного — надо обсуждать с юристами: есть ограничения по величине вознаграждения
⁃ Оплата по этапам — 30% после первого видео, 70% после завершения + многие соглашались в тч из-за возможности пообщаться с командой и получить консультацию
⁃ 20% не дошли до конца
⁃ Просмотр и вопросы надо просматривать сразу же после получения от респондента, чтобы нюансы уточнить у него пока она помнит
⁃ Саммари (от респондента) помогает запустить рефлексию, самоописание эмоций работает плохо, люди не склонны описывать свои эмоции
Хороший доклад про исследования. Практики исследования упакованы в кустарный (в хорошем смысле) фреймворк, который используется, и, судя по рассказу, приносит профит.
Системно:
⁃ Снова дается определение — какие системы считать сложными; и снова среди признаков множество сущностей и связей между ними, множество сценариев упакованы в мета-сценарий.
⁃ Далее рассказ про разные уровни в системе, на которых применяются исследования. Похоже, что речь идет именно про системные уровни. Например, сквозное исследование направлено на весь жизненный цикл сервиса, а точечные исследования целятся в конкретные стадии этого цикла. Упомянутые быстрые исследования, вероятно, нацелены еще на более мелкие части системы в декомпозиции.
⁃ Два блока целиком посвящены коммуникации — работа с внутренними заказчиками и донесение результатов это самая коммуникация и есть. Цель этой коммуникации — обсудить интересы проектных ролей и договориться о методе описания и доступности рабочих артефактов.
⁃ Кейсы сквозного и точечного исследований подтверждают фокусировку на разных уровнях: глобально вся система и 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 #мероприятия #практика #менеджмент #исследования #роли
#дизайн /// Требования в UI-задачах
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.
#систематика /// Прогресс и инновации
Прогресс в технологиях случается непредсказуемо как следствие скрещения новых технологий (в составе результирующей), которые сами по себе начинают дешеветь, и становятся массово доступны.
Можно выделить 4 стадии:
- Стандартизация — технология описана для общего использования.
- Удобство использования / юзабилити — разработка доступного массам интерфейса, её могут использовать не только специалисты, а широкая аудитория.
- Распространение, переход в массовое потрбеление.
- Встраивание в инфраструктуру — когда новая технология уже везде, кажется и считается повсеместной, привычной, обыденной.
С появлением новых технологий меняются работы, которые выполняют по практикам/сервисам, и как результат появляются новые рынки.
Пример: сервис перевозки остался, но обеспечивающая система и связанные с ней работы поменялись; ранее это были диспетчеры и таксопарки, сейчас же это приложения и практика подбора машины с водителем (агрегатор такси).
Еще пример: сервис хранения и передачи данных остался, но ранее это были, например, CD-диски с обеспечивающей системой в виде компьютера и дисковода, теперь же это хранение на удаленном дата-центре с обеспечениев в виде сайта/приложения с доступом к этим данным в облаке.
___
#Технология #прогресс #интерфейс
[[Практика, дисциплина, технология]] — технология есть инструмент, позволяющая выполнять практику или оказывать сервис, при этом развитие технологий меняет работы в системах обеспечения, порождая новые рынки.
Прогресс в технологиях случается непредсказуемо как следствие скрещения новых технологий (в составе результирующей), которые сами по себе начинают дешеветь, и становятся массово доступны.
Можно выделить 4 стадии:
- Стандартизация — технология описана для общего использования.
- Удобство использования / юзабилити — разработка доступного массам интерфейса, её могут использовать не только специалисты, а широкая аудитория.
- Распространение, переход в массовое потрбеление.
- Встраивание в инфраструктуру — когда новая технология уже везде, кажется и считается повсеместной, привычной, обыденной.
С появлением новых технологий меняются работы, которые выполняют по практикам/сервисам, и как результат появляются новые рынки.
Пример: сервис перевозки остался, но обеспечивающая система и связанные с ней работы поменялись; ранее это были диспетчеры и таксопарки, сейчас же это приложения и практика подбора машины с водителем (агрегатор такси).
Еще пример: сервис хранения и передачи данных остался, но ранее это были, например, CD-диски с обеспечивающей системой в виде компьютера и дисковода, теперь же это хранение на удаленном дата-центре с обеспечениев в виде сайта/приложения с доступом к этим данным в облаке.
___
#Технология #прогресс #интерфейс
[[Практика, дисциплина, технология]] — технология есть инструмент, позволяющая выполнять практику или оказывать сервис, при этом развитие технологий меняет работы в системах обеспечения, порождая новые рынки.
#систематика /// Бесконечное развитие
Развитие — освоение новых практик (в отличие от совершенствования, когда практика остается та же, но улучшаются технологии для её выполнения). Бесконечное развитие заключается в том, чтобы постепенно (!) осваивать новые практики и навыки для достижения локальных (!) целей. Именно постепенно и именно локальных, потому что только такой подход позволит гибко подстраиваться под постоянной и быстро изменяющиеся условия (общий прогресс, сменяющиеся рынки, востребованные навыки и компетенции). Если же ставить цель глобально, то слишком велик шанс упереться в барьер изменившихся условий, так и не достигнув цели.
Самая простая аналогия — движение малыми отрезками с остановкой и переориентированием на каждом пункте. При таком подходе 1) быстрее рисуется общая картина (карта открывается постепенно, но постоянно) и 2) происходит локальное микрообучение на каждой точке / остановке, что усиливает все последующие обучения, а также 3) позволяет тратить меньше ресурсов и своевременно их восполнять.
___
#развитие #совершенствование #практики #цель
[[Практика, дисциплина, технология]] — при развитии, то есть освоении новых практик, стоит ставить локальные малые цели, это даёт необходимую гибкость и экономию ресурсов.
Развитие — освоение новых практик (в отличие от совершенствования, когда практика остается та же, но улучшаются технологии для её выполнения). Бесконечное развитие заключается в том, чтобы постепенно (!) осваивать новые практики и навыки для достижения локальных (!) целей. Именно постепенно и именно локальных, потому что только такой подход позволит гибко подстраиваться под постоянной и быстро изменяющиеся условия (общий прогресс, сменяющиеся рынки, востребованные навыки и компетенции). Если же ставить цель глобально, то слишком велик шанс упереться в барьер изменившихся условий, так и не достигнув цели.
Самая простая аналогия — движение малыми отрезками с остановкой и переориентированием на каждом пункте. При таком подходе 1) быстрее рисуется общая картина (карта открывается постепенно, но постоянно) и 2) происходит локальное микрообучение на каждой точке / остановке, что усиливает все последующие обучения, а также 3) позволяет тратить меньше ресурсов и своевременно их восполнять.
___
#развитие #совершенствование #практики #цель
[[Практика, дисциплина, технология]] — при развитии, то есть освоении новых практик, стоит ставить локальные малые цели, это даёт необходимую гибкость и экономию ресурсов.
#систематика /// Стратегирование
Стратегирование — постоянный процесс выбора стратегий, одной или нескольких.
При бесконечном развитии, при шагах по оптимальным ступенькам, стоит оперировать малыми локальными стратегиями, на каждый локальный шаг. Для достижения локальной цели нужна локальная стратегия, уместная здесь и сейчас.
И самым главным оказывается на сама стратегия, а именно навык/привычка/метод постоянной смены и/или подстройки стратегий, выбор новых стратегий и отказ от старых. Это и есть стратегирование.
___
#стратегия #развитие #цель #стратегирование
Стратегирование — постоянный процесс выбора стратегий, одной или нескольких.
При бесконечном развитии, при шагах по оптимальным ступенькам, стоит оперировать малыми локальными стратегиями, на каждый локальный шаг. Для достижения локальной цели нужна локальная стратегия, уместная здесь и сейчас.
И самым главным оказывается на сама стратегия, а именно навык/привычка/метод постоянной смены и/или подстройки стратегий, выбор новых стратегий и отказ от старых. Это и есть стратегирование.
___
#стратегия #развитие #цель #стратегирование
#систематика /// Инновация
Инновация — доведение идеи до рынка.
Сама идея и даже модель её воплощения не является инновацией, это всё еще модель, описание идеи-как-продукта.
Инновацией следует считать серийное производство и реализацию продукта или сервиса. Для этого необходимо гораздо больше ресурсов и усилий — построить прототип устройства гораздо легче, чем найти или построить завод и серийному производству устройств; собрать прототип цифрового продукта сильно проще, чем собрать команду/фирму/отдел по разработке продуктива с его отладкой, поддержкой и масштабированием.
___
#инновация #модель #обеспечение
Инновация — доведение идеи до рынка.
Сама идея и даже модель её воплощения не является инновацией, это всё еще модель, описание идеи-как-продукта.
Инновацией следует считать серийное производство и реализацию продукта или сервиса. Для этого необходимо гораздо больше ресурсов и усилий — построить прототип устройства гораздо легче, чем найти или построить завод и серийному производству устройств; собрать прототип цифрового продукта сильно проще, чем собрать команду/фирму/отдел по разработке продуктива с его отладкой, поддержкой и масштабированием.
___
#инновация #модель #обеспечение
#систематика /// Интеллект, обучение и компетенции
Интеллект и навыки
Мозг нужен для "думания", но это "думание" может быть разным.
Верхнеуровнево это думание можно поделить (!!!очень условно!!!) на сложное и простое.
Сложное — это процесс мышления, при котором проблемы переводятся в задачи, клубки данных "распарсиваются", взятая "на разбор" часть мира перемалывается и выражается в объяснениях — и как результат упаковывается в модели с определенной степенью предсказательности.
Простое думание — процесс применения результатов-моделей из сложного мышления. Либо проверка гипотез-моделей, либо применение проверенных моделей уже как инструментов.
Интеллект занимается первым, сложным, процессом думания, исследованиями.
Навыки занимаются применением освоенных моделей, сборкой решений из готового материала.
Прокачивать интеллект — прокачивать умение решать неизвестные задачи, то есть превращать проблемы (задачи неизвестного класса) в задачи и подбирать к ним уже освоенные навыки.
Двухтактное обучение
Интеллект прокачивается обучением. Качественное обучение состоит из двух тактов — предобучение и прикладное обучение.
Предобучение — освоение практик мышления, развитие интеллекта; оно необходимо для более быстрого освоения прикладных навыков. Это большая и сложная часть обучения, но необходимая в современном мире, где не прожить с одним прикладным навыком (профессией).
Например, практиками предобучения являются логика, системное мышление, управление вниманием (собранность).
Прикладное обучение — освоение прикладных практик, "работ руками" (на самом деле и головой тоже, но чаще всего это простые вычисления, но не мышление в виде исследования).
Прикладными практиками являются, например, проектирование, инженерия, программирование; причем далее может следовать разделение на более узкие практики: UX-проектирование, инженерия загородных домов, backend-разработка.
Можно осваивать прикладные навыки и без предобучения, но это неэффективно: без предобучения прикладные навыки не получится освоить с полным пониманием, за рамками освоения останутся причинно-следственные связи, объяснения и понимание почему это так работает. С предобучением же освоение прикладных практик больше похоже на подстройку / тюнинг базовых умений, полученных из трансдисциплин.
Т-компетенции
Результат обучения выражается в компетенциях.
Компетенции необходимы для успешного встраивания в проекты — устройства на работу, ведения бизнеса, выполнения разовых заказов, построения личного бренда.
Компетенции бывают прикладные и базовые.
Прикладные — те, которые используются для выполнения конкретных рабочих задач, например, нарисовать иллюстрацию.
Базовые — переносимые не только из проекта в проект, но и из отрасли в отрасль: умение организовать (себя и команду), готовность агентно коммуницировать, работать в команде, etc.
Если представить, что прикладные компетенции выражены вертикальной чертой |, а базовые компетенции выражены горизонтальной --, то вместе их можно преставить как Т-образную характеристику. (Полагаю, что именно "Т" для удобства, по идее уместо было бы использовать и "__|__" и "-|-" и "+"; но обозначение неважно). Иногда две горизонтальных половинки разделяют на две части базовых навыков — коллективных (лидерство, организация, etc) и личных (этические установки, собранность, etc).
Самое важное — одно без другого не работает. Без базовых компетенций не встроиться в команду, не скоммуницировать, не построить стратегию для единоличных проектов. Без прикладных навыков просто нечего будет делать: встроиться в команду и системно мыслить мало, за это не платят зарплату и это нельзя продать клиентам.
Компетенции — базовые трансдисциплины и прикладные дисциплины — необходимы для успешного отыграывания ролей: на работе, в проектах, в бизнесе, etc.
___
#интеллект #мышление #навык #трансдисциплина #практика #роль #компетенция #дисциплина
Интеллект и навыки
Мозг нужен для "думания", но это "думание" может быть разным.
Верхнеуровнево это думание можно поделить (!!!очень условно!!!) на сложное и простое.
Сложное — это процесс мышления, при котором проблемы переводятся в задачи, клубки данных "распарсиваются", взятая "на разбор" часть мира перемалывается и выражается в объяснениях — и как результат упаковывается в модели с определенной степенью предсказательности.
Простое думание — процесс применения результатов-моделей из сложного мышления. Либо проверка гипотез-моделей, либо применение проверенных моделей уже как инструментов.
Интеллект занимается первым, сложным, процессом думания, исследованиями.
Навыки занимаются применением освоенных моделей, сборкой решений из готового материала.
Прокачивать интеллект — прокачивать умение решать неизвестные задачи, то есть превращать проблемы (задачи неизвестного класса) в задачи и подбирать к ним уже освоенные навыки.
Двухтактное обучение
Интеллект прокачивается обучением. Качественное обучение состоит из двух тактов — предобучение и прикладное обучение.
Предобучение — освоение практик мышления, развитие интеллекта; оно необходимо для более быстрого освоения прикладных навыков. Это большая и сложная часть обучения, но необходимая в современном мире, где не прожить с одним прикладным навыком (профессией).
Например, практиками предобучения являются логика, системное мышление, управление вниманием (собранность).
Прикладное обучение — освоение прикладных практик, "работ руками" (на самом деле и головой тоже, но чаще всего это простые вычисления, но не мышление в виде исследования).
Прикладными практиками являются, например, проектирование, инженерия, программирование; причем далее может следовать разделение на более узкие практики: UX-проектирование, инженерия загородных домов, backend-разработка.
Можно осваивать прикладные навыки и без предобучения, но это неэффективно: без предобучения прикладные навыки не получится освоить с полным пониманием, за рамками освоения останутся причинно-следственные связи, объяснения и понимание почему это так работает. С предобучением же освоение прикладных практик больше похоже на подстройку / тюнинг базовых умений, полученных из трансдисциплин.
Т-компетенции
Результат обучения выражается в компетенциях.
Компетенции необходимы для успешного встраивания в проекты — устройства на работу, ведения бизнеса, выполнения разовых заказов, построения личного бренда.
Компетенции бывают прикладные и базовые.
Прикладные — те, которые используются для выполнения конкретных рабочих задач, например, нарисовать иллюстрацию.
Базовые — переносимые не только из проекта в проект, но и из отрасли в отрасль: умение организовать (себя и команду), готовность агентно коммуницировать, работать в команде, etc.
Если представить, что прикладные компетенции выражены вертикальной чертой |, а базовые компетенции выражены горизонтальной --, то вместе их можно преставить как Т-образную характеристику. (Полагаю, что именно "Т" для удобства, по идее уместо было бы использовать и "__|__" и "-|-" и "+"; но обозначение неважно). Иногда две горизонтальных половинки разделяют на две части базовых навыков — коллективных (лидерство, организация, etc) и личных (этические установки, собранность, etc).
Самое важное — одно без другого не работает. Без базовых компетенций не встроиться в команду, не скоммуницировать, не построить стратегию для единоличных проектов. Без прикладных навыков просто нечего будет делать: встроиться в команду и системно мыслить мало, за это не платят зарплату и это нельзя продать клиентам.
Компетенции — базовые трансдисциплины и прикладные дисциплины — необходимы для успешного отыграывания ролей: на работе, в проектах, в бизнесе, etc.
___
#интеллект #мышление #навык #трансдисциплина #практика #роль #компетенция #дисциплина
#систематика /// Усиление интеллекта
Интеллект — как способность осваивать новые классы задач — можно и нужно развивать.
Это делается
- с помощью освоения трансдисциплин (дисциплинарный стек)
- последовательно, то есть не решая сложные задачи "в лоб", а постепенно наращивая сложность задач.
И вот этот последовательный микс освоения мыслительного стека и наращивания сложности задач качественно усиливают способность решать новые задачи, то есть интеллект.
___
#интеллект #развитие #трансдисциплина
Интеллект — как способность осваивать новые классы задач — можно и нужно развивать.
Это делается
- с помощью освоения трансдисциплин (дисциплинарный стек)
- последовательно, то есть не решая сложные задачи "в лоб", а постепенно наращивая сложность задач.
И вот этот последовательный микс освоения мыслительного стека и наращивания сложности задач качественно усиливают способность решать новые задачи, то есть интеллект.
___
#интеллект #развитие #трансдисциплина
#систематика /// Дисциплинарный стек
Описал набор дисциплин, которые помогают (задействованы) в решении нетиповых задач.
Сам их набор соответствут набору от ШСМ, я же даю собственное понимание их.
По ссылке их описание (в моём понимании), ниже просто список:
- Понятизация
- Собранность
- Семантика
- Теория информации
- Теория понятий
- Онтология
- Алгоритмика
- Логика
- Объяснения
- Эстетика
- Исследования
- Этика
- Риторика
- Методология
- Экономика
- Системное мышление
- Труд
Описал набор дисциплин, которые помогают (задействованы) в решении нетиповых задач.
Сам их набор соответствут набору от ШСМ, я же даю собственное понимание их.
По ссылке их описание (в моём понимании), ниже просто список:
- Понятизация
- Собранность
- Семантика
- Теория информации
- Теория понятий
- Онтология
- Алгоритмика
- Логика
- Объяснения
- Эстетика
- Исследования
- Этика
- Риторика
- Методология
- Экономика
- Системное мышление
- Труд
#систематика /// Системный менеджмент
Системный менеджмент — набор дисциплин/практик построения систем обеспечения. Основан на системном мышлении и работает с альфами работ, метода, команд; обязательно строит эти альфы вокруг целевой системы, тем самым создавая обеспечивающую систему. При менеджменте сервиса также необходимо прослеживать связь с целевой системой. Это важно, так как для разных целевых систем будут разные обеспечивающие системы.
Рассматривается только в связке с предпринимательством (что делать) и инженерией (как делать). Системный менеджмент НЕ работает с содержанием (!), а только с обеспечением, содержанием же занимаются предпринимательская и инженерная зоны интереса. Это контринтуитивно, однако позволяет фокусироваться на обеспечении, то есть на альфах работы, метода и команды.
Системный менеджмент рассматривает создание систем по их уровням, на каждом из которых меняется состав менеджерских альф.
Чуть подробнее
---
#менеджмент
Системный менеджмент — набор дисциплин/практик построения систем обеспечения. Основан на системном мышлении и работает с альфами работ, метода, команд; обязательно строит эти альфы вокруг целевой системы, тем самым создавая обеспечивающую систему. При менеджменте сервиса также необходимо прослеживать связь с целевой системой. Это важно, так как для разных целевых систем будут разные обеспечивающие системы.
Рассматривается только в связке с предпринимательством (что делать) и инженерией (как делать). Системный менеджмент НЕ работает с содержанием (!), а только с обеспечением, содержанием же занимаются предпринимательская и инженерная зоны интереса. Это контринтуитивно, однако позволяет фокусироваться на обеспечении, то есть на альфах работы, метода и команды.
Системный менеджмент рассматривает создание систем по их уровням, на каждом из которых меняется состав менеджерских альф.
Чуть подробнее
---
#менеджмент
#систематика /// Эстетика, красота, изящность, элегентность
Дисциплина эстетики обсуждает критерий изящности/красоты у решения. Причем как решения задач по созданию систем, так и для художественных задач.
Само решение по созданию и/или описанию системы может и должно быть элегантным, красивым.
Для художественных задач (а лучше сказать устремлений) эстетика может проявляться на нескольких уровнях — на уровне самой идеи, на уровне формы выражения, на уровне обсуждения художественного акта и т.д.:
- что сотворено? — концепт, понятие
- в каком виде выражено — знак, язык, формат, модель
- как представлено и воспринято — коммуникация, агентное восприятие
Все эти уровни могут быть по-своему красивы. Но могут и не быть, что оказывается весьма трагично.
Взаимное влияние эстетики этих уровней — то, что стоит продумать.
В рациональном (не художественном) рассмотрении также можно мыслить красотой самого решения, красотой описания и красотой обсуждений по решению; однако здесь вступает чистый прагматизм и целеполагание, весомо влияющие на уровень эстетики в совокупном решении (мега-модели).
---
#эстетика #модель #описание #концепт
Дисциплина эстетики обсуждает критерий изящности/красоты у решения. Причем как решения задач по созданию систем, так и для художественных задач.
Само решение по созданию и/или описанию системы может и должно быть элегантным, красивым.
Для художественных задач (а лучше сказать устремлений) эстетика может проявляться на нескольких уровнях — на уровне самой идеи, на уровне формы выражения, на уровне обсуждения художественного акта и т.д.:
- что сотворено? — концепт, понятие
- в каком виде выражено — знак, язык, формат, модель
- как представлено и воспринято — коммуникация, агентное восприятие
Все эти уровни могут быть по-своему красивы. Но могут и не быть, что оказывается весьма трагично.
Взаимное влияние эстетики этих уровней — то, что стоит продумать.
В рациональном (не художественном) рассмотрении также можно мыслить красотой самого решения, красотой описания и красотой обсуждений по решению; однако здесь вступает чистый прагматизм и целеполагание, весомо влияющие на уровень эстетики в совокупном решении (мега-модели).
---
#эстетика #модель #описание #концепт
#систематика /// Практика в менеджменте
Оргроль — это про практики, так как роль проектная, а проект требуется осуществления / выполнения практик.
Оргзвено — это про работы, так как оргзвено есть исполнитель+инструмент, и этот исполнитель делает работу, играя оргроль по какой-либо практике / каким-либо практикам.
Как сказано выше, оргроль выполняется оргзвеном, то есть исполнитель в ходе работ применяет инструмент (становится оргзвеном), чтобы выполнить практики, соответствующие занимаемой исполнителем (оргзвеном) оргроли.
Практика определяется дисциплиной, а не технологиями. Основной прием определения / выявления практики — спросить / понять “откуда знание о том, как выполнить работы (по обсуждаемой практике)?”. Ответ будет указывать на дисциплину, теорию / обучение — и это позволяет определить практику.
Пример:
— Вы взялись сшить панамку, откуда вы знаете как это делать?
— Я окончил курсы кройки и шитья, вот на мне жилет и под ним рубашка, они сшиты мною.
— И у вас есть весь необходимый инструмент?
— О да, я вожу с собой швейную машинку Panamaster, всё, что мне нужно — это сырьё и дизайн изделия.
Из ответов можно понять, что исполнитель заступает на роль швейного мастера и будет выполнять практику “ткацкого дела на швейной машинке” по одноименной дисциплине с применением соответствующей технологии (швейная машинка Panamaster).
— — —
#практика #дисциплина #роль #оргзвено
Оргроль — это про практики, так как роль проектная, а проект требуется осуществления / выполнения практик.
Оргзвено — это про работы, так как оргзвено есть исполнитель+инструмент, и этот исполнитель делает работу, играя оргроль по какой-либо практике / каким-либо практикам.
Как сказано выше, оргроль выполняется оргзвеном, то есть исполнитель в ходе работ применяет инструмент (становится оргзвеном), чтобы выполнить практики, соответствующие занимаемой исполнителем (оргзвеном) оргроли.
Практика определяется дисциплиной, а не технологиями. Основной прием определения / выявления практики — спросить / понять “откуда знание о том, как выполнить работы (по обсуждаемой практике)?”. Ответ будет указывать на дисциплину, теорию / обучение — и это позволяет определить практику.
Пример:
— Вы взялись сшить панамку, откуда вы знаете как это делать?
— Я окончил курсы кройки и шитья, вот на мне жилет и под ним рубашка, они сшиты мною.
— И у вас есть весь необходимый инструмент?
— О да, я вожу с собой швейную машинку Panamaster, всё, что мне нужно — это сырьё и дизайн изделия.
Из ответов можно понять, что исполнитель заступает на роль швейного мастера и будет выполнять практику “ткацкого дела на швейной машинке” по одноименной дисциплине с применением соответствующей технологии (швейная машинка Panamaster).
— — —
#практика #дисциплина #роль #оргзвено