Post #89

Хочу всё уметь. Необходимые знания и навыки UX-дизайнера профсистем. Часть 1. Пока у меня накапливаются мысли про онбординги и т.п., давайте ещё затронем такую тему, что должен уметь UX-дизайнер сложных систем. Помню, меня еще год назад мой друг и бывший коллега помучил и предложил написать пост. Пост я так и не написал, ибо как всегда замахнулся написать много и подробно, поэтому буду кусочками отписывать — тем более сегодня накидывал некоторые пункты в план развития коллеги. Начнём с «простых» вещей — у меня нет цели и возможности сейчас расскрывать подробно эти темы, но я хочу наметить опорные точки, вывести неосознанное незнание в осознанное. 1. Информационная архитектура — вроде бы, все представляют, что есть такое. Но на практике мы часто делаем решения по наитию, повторяя те или иные общие практики или подходы продуктов, которые мы хорошо знаем. Меж тем создать гибкую модель «здания» системы с дверями и окнами, которая подойдет для самых разных сценариев взаимодействия, а ещё будет гибкой, масштабируемой и расширяемой — это довольно серьезная работа, требующая глубокой концентрации и навыков абстрагирования. Условно говоря, если вы хотите в вашей системе сделать запись на приём врача, архитектура Ui должна позволять как начать с идентификации или регистрации пациента (если его еще не было), а потом выбрать доступный талон (слот) для конкретного врача, либо же вначале проверить наличие слотов у врача и перейти к идентификации/регистрации — и это не тривиальные моменты. Модели архитектуры от данных, модели от сценариев, умение сочетать их друг с другом, достигая необходимой и достаточной близости, вопросы работы поиска и поисковой выдачи — все это важные вопросы, которые часто проходят мимо. 2. Микровзаимодействия и микросостояния — есть сценарии работы, а есть мелкие колючки и шероховатости, которые могут приводить к серьезным последствиям (как ошибка в грошовом индикаторе скорости снижения однажды привела к авиакатастрофе). На мой взгляд, к сожалению, на это тоже стали подзабивать — но нужно разбираться, когда можно состояние нажатия на кнопку объединить с состоянием селекшна, а когда не стоит (ибо вносит путаницу и не дает возомжности исправить ошибку до триггера действия), почему стоит жертвовать красотой, чтобы недоступные поля не походили на доступные (или наоборот), либо же уметь расписать поведение от выбора инструмента и нажатия ЛКМ (левой кнопки мыши) до завершения работы со всеми ветвлениями на панорамирование, исправление ошибок и т.п. для какого-нибудь набора тулов на холсте (типа линейки измерения расстояний) с минимизацией действий/состояний выбора и т. п. 3. Визуальная иерархия и соответствие с логикой/содержимым — это отдельная большая тема, на которую завязываются задачи снижения визуального шума, подчеркивания акцентов на важном или новом, а также учёта того, что выводы о связах/важности мы часто делаем еще на бессознательном уровне при интерпретации пятен, а не после распознавания текста, иконок и иных “сознательных” процессах. Когда причины стоит держать перед следствиями (слева или выше), а когда можно пожертвовать, как и какими средствами (фоном, разделительными и соединительными линиями, пустотой и т.п.) правильно соединить или разделить блоки, чтобы была понятна смысловая вложенность/принадлежность или, наоборот, параллельность, или даже бессвязность семантических элементов — особенно в условиях профсистем, когда мы имеем дело с большой плотностью данных (и, кстати, почему часто мы не должны жертоввать ей ради красоты и пресловутого «white space»).