#систематика /// Практика, дисциплина, технология
Практика — поведение действия, направленные на создание рабочего продукта, с применением необходимых знаний.
Дисциплина — свод знаний, который с помощью технологий воплощается в виде практики.
Теория, лежащая в основе практики, способ мышления для выполнения практики — дисциплина. Дисциплине обучают, чтобы оргзвено могло успешно сыграть оргроль для выполнения соответствующей практики по этой дисциплине.
Технология — инструмент, с помощью которого оргзвено играет оргроль, воплощая / реализуя дисциплину в практику.
___
#практика #дисциплина #технология #оргроль #оргзвено
Практика — поведение действия, направленные на создание рабочего продукта, с применением необходимых знаний.
Дисциплина — свод знаний, который с помощью технологий воплощается в виде практики.
Теория, лежащая в основе практики, способ мышления для выполнения практики — дисциплина. Дисциплине обучают, чтобы оргзвено могло успешно сыграть оргроль для выполнения соответствующей практики по этой дисциплине.
Технология — инструмент, с помощью которого оргзвено играет оргроль, воплощая / реализуя дисциплину в практику.
___
#практика #дисциплина #технология #оргроль #оргзвено
#систематика /// Совершенствование и развитие
Изменение технологий, их изучение и внедрение — это совершенствование, так как дисциплина и практика остаются те же самые, улучшается только инструмент.
Изменение дисциплин и практик, выполняемых для достижения результата — развитие.
Совокупность практик, направленных на реализацию типового рабочего продукта — метод
Регулярное выполнение практики — деятельность
При реализации стандарта практики от стандарта стоит брать только самое необходимое, в отличие от стандартов интерфейсов и портов, их содержащих, которые следует реализовывать в наибольшей степени строго и полно.
_
#практика #дисциплина #технология #роль #совершенствование #развитие #метод #деятельность
Изменение технологий, их изучение и внедрение — это совершенствование, так как дисциплина и практика остаются те же самые, улучшается только инструмент.
Изменение дисциплин и практик, выполняемых для достижения результата — развитие.
Совокупность практик, направленных на реализацию типового рабочего продукта — метод
Регулярное выполнение практики — деятельность
При реализации стандарта практики от стандарта стоит брать только самое необходимое, в отличие от стандартов интерфейсов и портов, их содержащих, которые следует реализовывать в наибольшей степени строго и полно.
_
#практика #дисциплина #технология #роль #совершенствование #развитие #метод #деятельность
#систематика /// Оргзвено
Оргзвено есть сотрудник или группа сотрудников вместе с вверенным ему/ей/им инструментами (технологиями), играющие оргроль, частный случай роли.
И вот та активность, которую эта оргроль выполняет есть практика по соответствующей дисциплине.
____
#оргзвено #практика #роли #оргроль #дисциплина
Оргзвено есть сотрудник или группа сотрудников вместе с вверенным ему/ей/им инструментами (технологиями), играющие оргроль, частный случай роли.
И вот та активность, которую эта оргроль выполняет есть практика по соответствующей дисциплине.
____
#оргзвено #практика #роли #оргроль #дисциплина
#имплозия /// Не-играние роли
Роль играется человеком только при коммуникации. С другими ролями или с самим собой (например, с собой-в-будущем). Также роль может играться при какой-то сосредоточенной деятельности, пусть это даже творчество для себя (это тоже коммуникация с самим собой).
Без коммуникации роль не нужна на осознанном уровне. Например, читая в одиночестве, роль не играется намеренно, но всё же это деятельностная роль, пусть и не осознаваемая, не выделяемая явно чтецом при активности "чтение".
При всем этом можно намеренно не играть роль. Если намеренно "снять" с себя все роли при коммукации, то эти коммуникации обречены на провал (если только перед вами не стоит цель строго оборвать все коммуникации). К тому же, это действительно сложно — намеренно не играть ни одну из ролей, находясь в обществе.
Чуть проще в уединении — намеренное сложение с себя ролей и сопутствующих им конструктов легче дается без коммуникаций и может быть полезно, проявляясь в виде, например, медитации.
Здесь возникает интересный парадокс — практика не-играния-роли при медитации есть, но ролей, выполняющих такую практику, нет. Или же при медитации появлется роль "не-играющий-ни-одну-из-ролей"?
___
#роль #роли #коммуникация #медитация #практика
Роль играется человеком только при коммуникации. С другими ролями или с самим собой (например, с собой-в-будущем). Также роль может играться при какой-то сосредоточенной деятельности, пусть это даже творчество для себя (это тоже коммуникация с самим собой).
Без коммуникации роль не нужна на осознанном уровне. Например, читая в одиночестве, роль не играется намеренно, но всё же это деятельностная роль, пусть и не осознаваемая, не выделяемая явно чтецом при активности "чтение".
При всем этом можно намеренно не играть роль. Если намеренно "снять" с себя все роли при коммукации, то эти коммуникации обречены на провал (если только перед вами не стоит цель строго оборвать все коммуникации). К тому же, это действительно сложно — намеренно не играть ни одну из ролей, находясь в обществе.
Чуть проще в уединении — намеренное сложение с себя ролей и сопутствующих им конструктов легче дается без коммуникаций и может быть полезно, проявляясь в виде, например, медитации.
Здесь возникает интересный парадокс — практика не-играния-роли при медитации есть, но ролей, выполняющих такую практику, нет. Или же при медитации появлется роль "не-играющий-ни-одну-из-ролей"?
___
#роль #роли #коммуникация #медитация #практика
#систематика /// Инструменты мышлений
Все мышления производятся не только головой или внутри головы, но и с применением инструментов (блокнотов, компьютеров), позволяющих осуществлять мышление практически (от слова практика): моделировать, прописывать, выражать мысли в виде артефактов (записей, схем, etc).
Инструменты применяются на всей иерархии мышлений от трансдисциплин до фрагментарных прикладных. Сами инстурменты зависят от типа мышления и выполняемой задачи.
___
#практика #мышление
Все мышления производятся не только головой или внутри головы, но и с применением инструментов (блокнотов, компьютеров), позволяющих осуществлять мышление практически (от слова практика): моделировать, прописывать, выражать мысли в виде артефактов (записей, схем, etc).
Инструменты применяются на всей иерархии мышлений от трансдисциплин до фрагментарных прикладных. Сами инстурменты зависят от типа мышления и выполняемой задачи.
___
#практика #мышление
#систематика /// Работы
Работы есть рассмотрение состава проекта или деятельности организации как модулей.
Функции работ как модулей не рассматриваются, интересует только кто (проектные роли) и когда какие работы (их названия) выполняет.
Когда же мы говорим о функциях работ, то есть “как (метод) и зачем (какая функция) работают эту работу” — это обсуждается практика, это уже функциональное рассмотрение проекта
Работы — это экземпляры сервиса.
Как описывать работы:
Кто (в какой роли) ________
В какой срок ________
Что предоставляет (результат, критерии приемки / DoD) и по какой практике ______ / ______
____
#проект #практика #работы #сервиса #функция
Работы есть рассмотрение состава проекта или деятельности организации как модулей.
Функции работ как модулей не рассматриваются, интересует только кто (проектные роли) и когда какие работы (их названия) выполняет.
Когда же мы говорим о функциях работ, то есть “как (метод) и зачем (какая функция) работают эту работу” — это обсуждается практика, это уже функциональное рассмотрение проекта
Работы — это экземпляры сервиса.
Как описывать работы:
Кто (в какой роли) ________
В какой срок ________
Что предоставляет (результат, критерии приемки / DoD) и по какой практике ______ / ______
____
#проект #практика #работы #сервиса #функция
#инфоарх /// Информационная архитектура 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-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-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 #мероприятия #практика #менеджмент #исследования #роли
#систематика /// Интеллект, обучение и компетенции
Интеллект и навыки
Мозг нужен для "думания", но это "думание" может быть разным.
Верхнеуровнево это думание можно поделить (!!!очень условно!!!) на сложное и простое.
Сложное — это процесс мышления, при котором проблемы переводятся в задачи, клубки данных "распарсиваются", взятая "на разбор" часть мира перемалывается и выражается в объяснениях — и как результат упаковывается в модели с определенной степенью предсказательности.
Простое думание — процесс применения результатов-моделей из сложного мышления. Либо проверка гипотез-моделей, либо применение проверенных моделей уже как инструментов.
Интеллект занимается первым, сложным, процессом думания, исследованиями.
Навыки занимаются применением освоенных моделей, сборкой решений из готового материала.
Прокачивать интеллект — прокачивать умение решать неизвестные задачи, то есть превращать проблемы (задачи неизвестного класса) в задачи и подбирать к ним уже освоенные навыки.
Двухтактное обучение
Интеллект прокачивается обучением. Качественное обучение состоит из двух тактов — предобучение и прикладное обучение.
Предобучение — освоение практик мышления, развитие интеллекта; оно необходимо для более быстрого освоения прикладных навыков. Это большая и сложная часть обучения, но необходимая в современном мире, где не прожить с одним прикладным навыком (профессией).
Например, практиками предобучения являются логика, системное мышление, управление вниманием (собранность).
Прикладное обучение — освоение прикладных практик, "работ руками" (на самом деле и головой тоже, но чаще всего это простые вычисления, но не мышление в виде исследования).
Прикладными практиками являются, например, проектирование, инженерия, программирование; причем далее может следовать разделение на более узкие практики: UX-проектирование, инженерия загородных домов, backend-разработка.
Можно осваивать прикладные навыки и без предобучения, но это неэффективно: без предобучения прикладные навыки не получится освоить с полным пониманием, за рамками освоения останутся причинно-следственные связи, объяснения и понимание почему это так работает. С предобучением же освоение прикладных практик больше похоже на подстройку / тюнинг базовых умений, полученных из трансдисциплин.
Т-компетенции
Результат обучения выражается в компетенциях.
Компетенции необходимы для успешного встраивания в проекты — устройства на работу, ведения бизнеса, выполнения разовых заказов, построения личного бренда.
Компетенции бывают прикладные и базовые.
Прикладные — те, которые используются для выполнения конкретных рабочих задач, например, нарисовать иллюстрацию.
Базовые — переносимые не только из проекта в проект, но и из отрасли в отрасль: умение организовать (себя и команду), готовность агентно коммуницировать, работать в команде, etc.
Если представить, что прикладные компетенции выражены вертикальной чертой |, а базовые компетенции выражены горизонтальной --, то вместе их можно преставить как Т-образную характеристику. (Полагаю, что именно "Т" для удобства, по идее уместо было бы использовать и "__|__" и "-|-" и "+"; но обозначение неважно). Иногда две горизонтальных половинки разделяют на две части базовых навыков — коллективных (лидерство, организация, etc) и личных (этические установки, собранность, etc).
Самое важное — одно без другого не работает. Без базовых компетенций не встроиться в команду, не скоммуницировать, не построить стратегию для единоличных проектов. Без прикладных навыков просто нечего будет делать: встроиться в команду и системно мыслить мало, за это не платят зарплату и это нельзя продать клиентам.
Компетенции — базовые трансдисциплины и прикладные дисциплины — необходимы для успешного отыграывания ролей: на работе, в проектах, в бизнесе, etc.
___
#интеллект #мышление #навык #трансдисциплина #практика #роль #компетенция #дисциплина
Интеллект и навыки
Мозг нужен для "думания", но это "думание" может быть разным.
Верхнеуровнево это думание можно поделить (!!!очень условно!!!) на сложное и простое.
Сложное — это процесс мышления, при котором проблемы переводятся в задачи, клубки данных "распарсиваются", взятая "на разбор" часть мира перемалывается и выражается в объяснениях — и как результат упаковывается в модели с определенной степенью предсказательности.
Простое думание — процесс применения результатов-моделей из сложного мышления. Либо проверка гипотез-моделей, либо применение проверенных моделей уже как инструментов.
Интеллект занимается первым, сложным, процессом думания, исследованиями.
Навыки занимаются применением освоенных моделей, сборкой решений из готового материала.
Прокачивать интеллект — прокачивать умение решать неизвестные задачи, то есть превращать проблемы (задачи неизвестного класса) в задачи и подбирать к ним уже освоенные навыки.
Двухтактное обучение
Интеллект прокачивается обучением. Качественное обучение состоит из двух тактов — предобучение и прикладное обучение.
Предобучение — освоение практик мышления, развитие интеллекта; оно необходимо для более быстрого освоения прикладных навыков. Это большая и сложная часть обучения, но необходимая в современном мире, где не прожить с одним прикладным навыком (профессией).
Например, практиками предобучения являются логика, системное мышление, управление вниманием (собранность).
Прикладное обучение — освоение прикладных практик, "работ руками" (на самом деле и головой тоже, но чаще всего это простые вычисления, но не мышление в виде исследования).
Прикладными практиками являются, например, проектирование, инженерия, программирование; причем далее может следовать разделение на более узкие практики: UX-проектирование, инженерия загородных домов, backend-разработка.
Можно осваивать прикладные навыки и без предобучения, но это неэффективно: без предобучения прикладные навыки не получится освоить с полным пониманием, за рамками освоения останутся причинно-следственные связи, объяснения и понимание почему это так работает. С предобучением же освоение прикладных практик больше похоже на подстройку / тюнинг базовых умений, полученных из трансдисциплин.
Т-компетенции
Результат обучения выражается в компетенциях.
Компетенции необходимы для успешного встраивания в проекты — устройства на работу, ведения бизнеса, выполнения разовых заказов, построения личного бренда.
Компетенции бывают прикладные и базовые.
Прикладные — те, которые используются для выполнения конкретных рабочих задач, например, нарисовать иллюстрацию.
Базовые — переносимые не только из проекта в проект, но и из отрасли в отрасль: умение организовать (себя и команду), готовность агентно коммуницировать, работать в команде, etc.
Если представить, что прикладные компетенции выражены вертикальной чертой |, а базовые компетенции выражены горизонтальной --, то вместе их можно преставить как Т-образную характеристику. (Полагаю, что именно "Т" для удобства, по идее уместо было бы использовать и "__|__" и "-|-" и "+"; но обозначение неважно). Иногда две горизонтальных половинки разделяют на две части базовых навыков — коллективных (лидерство, организация, etc) и личных (этические установки, собранность, etc).
Самое важное — одно без другого не работает. Без базовых компетенций не встроиться в команду, не скоммуницировать, не построить стратегию для единоличных проектов. Без прикладных навыков просто нечего будет делать: встроиться в команду и системно мыслить мало, за это не платят зарплату и это нельзя продать клиентам.
Компетенции — базовые трансдисциплины и прикладные дисциплины — необходимы для успешного отыграывания ролей: на работе, в проектах, в бизнесе, etc.
___
#интеллект #мышление #навык #трансдисциплина #практика #роль #компетенция #дисциплина