2020-03-11: World Information Architecture Day (WIAD) - теперь в Москве

Материал из MaksWiki
Перейти к: навигация, поиск
WIAD2020-logo.png

В конце февраля был на площадке WIAD-2020 в Москве. WIAD - это World Information Architecture Day, который проходит по всему миру на 60+ площадках в третью субботу февраля. И любая инициативная группа может к нему присоединиться, организовать площадку у себя в городе, а связавшись с организаторами получить от них спонсорские призы для розыгрыша участникам, обычно это подписки на те или иные продукты. В Москве его проводили в пятницу, а в субботу он проходил в Питере, где сообщество UX СПб его проводит с 2016 года. В Питере я был на всех, очень интересное и содержательное мероприятие, интересующиеся могут почитать мои отчеты WIAD-2016, WIAD-2017, WIAD-2018, WIAD-2019, а в Москве первый раз, хотя в прошлом году московская площадка тоже была.

В этом году я выступал с докладом Domain-driven design: от справочников и документов до отчетов, собрал для выступления новую версию доклада из этой серии, обогатив новым опытом и пониманием.

Организаторы уже выложили презентации и  видео

А здесь - заметки с других докладов.

Пост на FB Konstantin Valeev. Модель предметной области в проектировании интерфейсов: нотации и подходы. Рассказ про спектр инструментов для описания онтологий. Начиная классификация Аристотеля и базовой онтологии BORO, которая, кончено, все описывает, но выходит на столь философские понятия, о которых договориться почти невозможно. И формальных языков RDF и OWL, которые описывают сложные онтологии с громадным количеством объектов и связей, и позволяют строить запросы, однако описание - совершенно нечитаемо. Впрочем, есть инструменты, такие как Protege, для работы с этим из интерфейса. И плавно переходя к легким инструментам - графовому представлению онтологий, для которого есть простой инструмент grakn.ai, легкому представлению в виде словаря или словаря со связями, по которому можно нарисовать MindMap.

Дальше выделен важный переход от онтологий, связывающих термины, к классам, когда мы определяем, что из терминов класс, что - атрибут, а что - экземпляр сущности или ее состояние. Тут визуализация понятна - диаграммы классов и объектов и диаграмма состояний. Сущности проявляются на интерфейсах и есть интересный недооцененный инструмент - диаграмма надежности, которая совместно показывает действия пользователей и объекты, над которыми они совершаются. И в конце - немного про деление предметной области на контексты и связь между ними.

Пост на FB Анна Желтова. Разбор ошибок информ-архитектуры: что не сделали и к чему это привело. Это взгляд на дизайн сайтов как на канал передачи информации между системой и человеком. Информация - она структурирована, а не просто состоит из кусочков текста. И потому правильно думать о структуре. И там было много примеров, о чем в конкретных местах не подумали, а о чем, наоборот, подумали хорошо. Было не очень структурировано, и далеко не всегда примеры были однозначными, но в целом фокус внимания, который выделяет на сайте именно их назначение быть эффективным каналом передачи информации, а не красивую дизайнерскую картинку, или исторически складывающуюся свалку, в которой невозможно разобраться.


Пост на FB Как стать и быть информационным архитектором. Лара Симонова и Айгуль Ашрафуллина. Доклад был из двух частей, Лара рассказывала свой многолетний путь информационного архитектора, потом Айгуль - о том, как она стала ИА в Ростелекоме. В коментах - заметки.

Лара начала с того, что ее путь в ИА начинался с классификации книг в своей библиотеке, когда автор научпопа вдруг пишет худлит или наоборот, а у вас это в совсем разных шкафах, но книги одного автора вместе. Или когда формат книги не помещается на соответствующую полку, надо отдельно.

Ветвистый сценарий разбора дома - в жизни. И ее позвали применить это в проекте для одного заказчика. Там был формально простой, но сильно юридически зарегулированный блок, в котором надо было разобраться и сделать понятный для пользователя сценарий с учетом юридических особенностей и ветвей.

И дальше было много других проектов, с разными особенностями работы ИА. Вплоть до реорганизации бизнеса в Почты России.

И кейс Кристи, где есть много различно структурированных данных из разных источников, их надо было совместить, и сделать новые данные. Доклад на WIAD-2017 (я его слышал, мой конспект http://mtsepkov.org/WIAD-2017). И там ей пришлось поучиться программированию - python, ML - чтобы оптимизировать свою работу. ML используется для анализа и очистки данных. Дальше очень много разных артефактов и инструментов.

Определение ИА каждый ИА дает сам и несколько раз в жизни. И это - нормально. ИА создает единое логически консистентное поле, в котором идет работа. Mindset ИА

  • уметь видеть объекты и связи
  • уметь анализировать и искать данные и информацию
  • уметь видеть дыры в области и знаниях о ней
  • уметь упаковывать результаты в артефакты, референсную базу знаний об области,
  • делать релевантные срезы из упакованной информации, выдавая
  • их тем членам команды, которым они нужны, в нужный момент.

Айгуль. Начинающие ИА. Чтобы составить представления - пошла на HH и сайты США чтобы сформировать представление по вакансиям. В России рынок маленький, менее 500 вакансий, слабо структурированный. В России хотят от 5 лет и техническое или математическое образование. При этом задачи - UX и потребности пользователя, моделирование данных, навыки бизнес-аналитика, да еще выдающего начальные решения. В Штатах - рынок более развитый, и при этом гораздо больше специализаций и они строже выделены. ИА, архитектор данных, UX-архитектор, Enterprise architect.

В Ростелекоме ИА - один из слоев: БА - ИА - АП - ТА. И там для ИА своя ниша. При этом ИА в Ростелекоме появился пару лет назад, а IT в Ростелекоме - исторически сложившийся после слияния 7 компаний в центре, не считая регионов. И там все сложно и в IT-ландшафте, и много команд разработки. И первые месяцы она со всем этим разбиралась. Исследовать можно бесконечно, поэтому она поставила бизнес-задачу: ускорить процесс проектирования, и она дает фокус исследований и разработки модели.

В заключении Лара давала список книг. И вызовы ИА

  • Уровни детализаций. Не закопаться, а периодически подниматься и смотреть взглядом сверху
  • Сложные системы, там заложены естественные неформальные системы - не надо увлекаться формализацией
  • Мотивация ИА. С ИА начинается работа над продуктом, но профит проявляется на длинных временных горизонтов. И влияние ИА не слишком видно - оно ведь в том, насколько легко или сложно делаются новые изменения.
  • Самоидентификация: технарь, но не кодишь, не менеджер, но много работаешь с людьми, не креативная, но много визуальных инструментов
  • Сообщество. ИА-практики в профессию вписаны, но именно архитекторов реально немного. И многое сваливается в UX, а с данными не слишком. А хочется побить свои кейсы о специалистов.

Пост на FB Владимир Посвянский. Как Tinkoff.ru подстраивается под пользователя. Рассказ о том, как устроена непрерывная проверка гипотез на неавторизованном сегменте сайта Тинькофф. Бизнес выдает гипотезы о разных вариантах привлечения трафика, и у них работает непрерывное A/B-тестирование этих гипотез. Например, будет ли разница конверсии, если в блоке страхового полиса на кнопке написать "Купить" или "Оформить", или по-разному назвать продукт. Или если кредитный лимит вывести на первое место и заменить ползунком - оказывается, конверсия увеличивается на 5% Или кастомизация надписи на странице продажи страховки путешественника в зависимости от источника - банера про Италию или про Шенген.

В докладе было не только много примеров, но и технологии, которые позволяют запустить такое тестирование непрерывно и еще вести мониторинг в реальном времени. Там свои трудности. Начинали они с монолитной библиотеки - и выяснили, что та в некоторых каналах грузится недопустимо долго - и тогда поставили ограничение по таймингу. Все бы банки так делали, потому что ждать, пока загрузится их рекламный контекст на вдруг случившимся медленном канале мобильного инета. А потом сделали следующий шаг реорганизации сайта, чтобы делать тестирование без правок в коде, что сильно сократило цикл тестирования.

Для обработки используют алгоритмы ML, например, многорукого бандита, который пытается в каждый момент показывать лучшую вариацию, и эти алгоритмы сходятся. Работает хорошо, если есть вариации текстовок. Редизайн страницы - нельзя. А еще он требует хорошей онлайн-аналитики.Но он не умеет учитывать контекст, работает на трафик целиком. Над контекстно-зависимым многоруким бандитом они работают. Как пример - при выдаче сайта они используют модели сортировки, которые учитывают историю человека на сайте, которая идет на предиктора, и он тасует карточки. Конверсия на 10%

Артём Авладеев из Росбанка. Влияние User Story на изменение информационной архитектуры продукта. Рассказ о правильной практике работы с User Story с несколькими основными тезисами.

  • Необходимо не сразу порождать решение по прилетевшей user story, а выяснять, его назначение. Обязательно различая боли клиента от гипотез бизнеса о развитии продукта.
  • Породив решение, надо посмотреть, как оно повлияет на ИА, проверить сохранение целостности и логичной навигации в стректуре контента.
  • А после проектирования - проверить у клиента, что решение решает его проблемы. Если нужно - на прототипе.

Это было иллюстрировано рядом примеров, в том числе когда клиент на прототипе указывал на проблемы, например, когда реализуя счет по печатной форме они не предусмотрели ситуации, когда у клиента несколько счетов в банке. И любопытная история про оптимизацию карточек, которые исторически оказались перегруженны данными - это не тривиальная задача, когда надо в исторических наслоениях и практике использования выяснить, что действительно важно клиенту, а что - нет.

Михаил Галушко из ЦФТ. Информационная архитектура как инструмент коммуникации в команде. Михаил - руководитель UX направления по Золотой короне, которую разрабатывают несколько команд. Есть продуктовые, которые плотно работают над продуктом. А есть те, где нет постоянного проектировщика, и видения продукта. Или заказная разработка под разных клиентов со своими методологиями и подходами. И доклад был как раз о том, как ИА используется как инструмент межкомандной коммуникации и удержания целостности, и проявления смыслов конкретных решений.

  • Основа представление с помощью mindmap или аналогичное структурное описание.
  • Внедряются дополнительные смыслы: комментарии от коллег, этапы разработки для каждого элемента - они навешиваются на пункты архитектуры.
  • Легенда всегда доступна для новых участников команды.
  • Начинаем всегда с небольшого документа, а по мере развития и усложнения структуры документа - появляется легенда инфографики по типам уровней.
  • ИА - один документ, над которым идет совместная работа разными командами, а не по куче каналов коммуникации с правками.
  • Живет до запуска и далее на сопровождении - всегда актуален.
  • Стадии - относительно отдельных страниц, потому что они живут своей жизнью.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.