Виктор Теплов рассказал, как дизайнеру работать с ИИ.

— Тест Патрика: чаще вы соглашаетесь с ИИ или он с вами? Если вы, то готовьтесь потерять работу;
— Опасные сценарии: профи-скептик не разбирается в ИИ, использует его на удачу и сразу видит некачественный результат; энтузиаст-профан лезет в незнакомую область и полностью доверяет ИИ; дофаминовый наркоман радуется быстрому результату и делает 5 проектов (и ещё 7 в уме);
— ИИ — не партнёр, а инструмент. Человек становится автором продукта и берёт ответственность, когда нажимает на «Принять изменения»;
— По умолчанию ИИ выдаёт массово-приятный результат, похожий на музыку в лифте, которая не бесит, но и не цепляет. Это хорошо для интерфейсов, так как привычные паттерны удобны. Но плохо для творчества, бренда и голоса продукта, где нужна узнаваемость;
— Дизайнеры, которые не хотели разбираться в функциях программ, но хотели «сделать красиво», раньше использовали плагины. Не понимаешь, как работает свет, — плагин Cinematic LUT;
— ИИ может сгенерировать артефакты по фреймворкам вроде JTBD, CJM, Personas, но не может взять на себя ответственность за принятое решение;
— Не получится найти ИИ-инструмент, который просто сделает то, что нужно. Придётся разбираться, как добиться в нём нужного результата;
— План: опишите образ результата, критерии качества и ограничения (что делаем, для кого, в каких условиях). Итерации: делите задачу на шаги, фиксируйте изменения и промежуточные артефакты. Проверка: просите ссылки на первоисточники, объяснить сделанный выбор, дать альтернативы и подсветить риски;
— Рутину надо делать быстро, одинаково и без ошибок. Дизайнер дизайн-системы либо автоматизирует, либо тонет. Раньше для автоматизации надо было стать немного разработчиком, сейчас порог входа снизился. Но ИИ не должен быть автором архитектуры;
— Например, плагин для сбора типографских variables в JSON-стили и построения витрины стилей, плагин для создания шрифта из иконок дизайн-системы;
— Работа с цветовыми токенами. Опишите контракт: структура токенов, устройство имён, запреты, эталонные примеры. Попросите выполнить операцию: добавь новый токен в core-палитру и создай семантический токен bg.main.primary на его основе, добавь во все тематические и брендовые палитры;
— Сначала в режиме Plan, когда ИИ ничего не делает с файлами. Затем просите не только изменить файлы, но и показать изменения, объяснить, почему они соответствуют правилам, подсветить риски, поискать дубли, проверить ссылки;
— В Figma Make можно быстро сделать прототип, проверить поведение компонента в корнер-кейсах и принять решения по вопросам, которые часто всплывают уже во время реализации в коде;
— Доступность инструмента лишь подчёркивает искусность мастера. Кто-то может порубить топором дрова, а кто-то построить дом. Важен опыт, вкус и логика. ИИ не заменяет мастерство, а позволяет делать быстро, много и предсказуемо.

Копия в ВК Видео. #ai #design_system

Лев Брук, дизайнер, отвечающий за Сбол, рассказал о том, как сохраняет интерес к работе.

— Мотивация бывает внешняя (заработать денег на жизнь) и внутренняя (у каждого своя);
— Дизайнеры могут делать мир вокруг удобнее или хотя бы поднимать другим людям настроение;
— Просто скажите себе спасибо;
— Есть желание двигать человечество вперёд, расширять домен знаний, но как это делать?
— Чтобы что-то узнать, надо начать делать что-то по-новому;
— Со временем, попробовав разные варианты, в том числе неудачные, мы научаемся приходить к решению задачи самым коротким путём. В итоге исследовать варианты уже не надо, продуктивность зашкаливает, но пропадает интерес;
— Кейс: надо исправить текст сообщений, все сообщения выгружены в JSON-формате, прочитать его можно с помощью плагина для Сафари, но у них всех некрасивые иконки. В процесс добавляется задача по созданию иконки и, возможно, созданию своего плагина для чтения JSONа (плюс придумать название и промо-текст, пройти ревью в App Store и так далее);
— В итоге: решил задачу, узнал новое, помог людям, получил социальное признание благодаря плагину (позитивные отзывы, 2-е место в рейтинге по количеству скачиваний);
— Редактура — скилл дизайнера;
— Кейс: надо переписать текст, все онлайновые словари синонимов неудобны и завалены рекламой. В итоге: свой онлайн-словарь синонимов;
— Зачем терпеть, если можно сделать себе удобно, оптимизировать часть своей работы на будущее?
— Плагин для Фигмы Scripter позволяет делать простые инструменты для решения небольших задач без заморочек с UI и публикацией плагинов;
— Оставайтесь любопытными, меняйте всё, что бесит;
— Больших и сложных инструментов полно, но легко можно собирать свои версии их отдельных фич.

#process #ai

Таня Титоренко написала о дизайне диалогов и его отличии от UX-редактуры.

— Дизайнер диалогов (conversation designer) так же, как UX-редактор пишет текст, прорабатывает редполитику и Tone of voice, но работает при этом не с графическим интерфейсом, а с разговорным;
— В разговорном интерфейсе намного меньше способов взаимодействия (в случае голосового робота — это только реплики);
— Важно понимать, как пользователи формулируют вопросы, на каком этапе чаще зовут сотрудников, поэтому дизайнер часто читает пользовательские чаты и слушает записи звонков;
— Вопрос пользователю — один из основных инструментов продвижения по сценарию. Он приглашает к диалогу. В голосовом интерфейсе им должна заканчиваться каждая реплика робота;
— В качестве обратной связи также доступны только реплики. Чтобы не повести диалог не туда, неправильно поняв пользователя, робот частично повторяет запрос клиента в начале сценария;
— Также робот проговаривает состояние системы. Например, пользователь интересовался услугой, но на вопрос о подключении ответил «Не сейчас». Робот проговаривает, что услуга не подключена;
— Все заголовки и подписи — реплики сервиса, все кликабельные элементы — реплики пользователя;
— Формулировки — более разговорные, уместные в диалоге и не всегда подходящие для графического интерфейса. Но всё зависит от вашей сферы деятельности. Например, не все фразы может сказать сотрудник банка.

#conversation_design

Назар Завьялов и Дима Шилович написали о дизайн-ревью и поделились чеклистом, что проверить кроме статичного отображения макетов.

— Дизайн-ревью — этап, на котором дизайнер проверяет, насколько разработанная фича соответствует дизайну;
— На практике оценивают не только статичные макеты, но и взаимодействие;
— Например, с какой анимацией открывается целевой экран и какими жестами его можно закрыть;
— Блокировка свайпа вниз на модальном экране должна быть обоснована и использоваться только в крайних случаях;
— Как загружается контент: отображается только один индикатор загрузки (либо лоадер, либо скелетон), скелетон не отображается, если загрузка занимает меньше 300 мс, скелетон отображается не менее 500 мс, чтобы избежать «промигивания»;
— Как работает скрол: отображается только если необходим, и имеет корректную зону перемещения (обычно от навбара до таббара или Home indicator), не отображается внутри элементов дополнительно;
— Скрол не останавливается при тапе на интерактивные элементы (кнопки, поля), есть анимация при достижении края экрана;
— Реакция на нажатие: интерактивные элементы реагируют на нажатие, есть Pressed state, не смешиваются анимации (при нажатии кнопки не продавливается карточка, и наоборот), зоны нажатия соответствуют ожиданиям пользователя и увеличены у мелких элементов (иконки, крестики);
— На что можно обратить внимание в статике: реализация Corner smoothing, обрезание текста (через fade или троеточие), наличие корректной графики для тёмной темы, а также стоп-кадра для видео (заглушка на случай проблем с интернетом).

#review

Павел Шерер написал, почему JTBD и Personas — не конкурирующие, как некоторые считают, а дополняющие друг друга фреймворки проектирования.

— Personas: опишите тип пользователя, его контекст, задачи, особенности поведения, ограничения и потребности;
— JTBD: смотрите на работу, которую продукт пытается выполнить, и на прогресс, которого пользователь хочет достигнуть;
— JTBD не отменяет персон, а мешает подменять реальную мотивацию человека набором внешних признаков;
— Хорошая персона помогает понять, в каком контуре ответственности человек действует, с какими ограничениями, какие решения может принимать сам, чем рискует, какие механики для него вообще применимы, и какие метрики результата имеют смысл;
— JTBD позволяет с уровня конкретной механики подняться на уровень причины;
— Купить дрель → сделать дырку в стене → повесить полку → купить больше книг → читать больше и чувствовать себя умнее. Возможно, задачу решит электронная книга?
— Иерархия целей по Уильяму Пауэрсу: на уровне принципов — цели типа «быть» (быть готовым к пиковым нагрузкам), на уровне программ — «делать» (быстро управлять ресурсами), на уровне последовательностей — цели моторного контроля (запустить ещё 10 vCPU за 60 секунд);
— JTBD работает с верхними уровнями и помогает понять, зачем нужна работа. Job stories описывают контекст и потребности;
— Personas работают с нижними уровнями: кто и как именно будет действовать. User stories описывают механики и результат разработки;
— Одну работу могут выполнять разные люди, и если дата-саентист, чтобы быстро получить дополнительную вычислительную мощность, запустит из интерфейса типовой GPU-кластер без тонких настроек, то девопс будет думать об инфраструктурных политиках, лимитах, безопасности и мониторинге;
— Механика — это способ, которым продукт пытается реализовать потребность. Лайкать посты — механика соцсети, за которой стоит потребность получать и проявлять социальное одобрение, принадлежать к группе и так далее;
— Формат User story «как пользователь, я хочу действие, чтобы результат» смещает фокус на механики;
— Сначала Job stories фиксируют контекст, мотивацию и результат. Затем Personas добавляют исполнителей (персона должна объяснить, почему одна и та же джоба превращается в разные механики для разных ролей);
— Потом User stories фиксируют механики, которые можно проектировать, оценивать, класть в беклог и проверять метриками.

#user_story #job_story

Продолжаю ворчать, что раньше было лучше: трава зеленее, солнце ярче и дизайнеры дизайнеристее.

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

Тогда многое приходилось изобретать заново. Не потому что так было правильно, а потому что готового ещё не существовало.

Сейчас ситуация другая.

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

И индустрия начала выращивать дизайнеров именно под такие задачи.

Людей, которые умеют не изобретать кнопку заново, а поддерживать консистентность. Не устраивать визуальную революцию в каждом релизе, а сохранять устойчивость продукта. Не делать «вау ради вау», а спокойно собирать работающие системы.

А мы, дизайнеры старой школы, которые выросли в другой среде и не до конца переключились на этот поворот, начинаем ворчать:

— «Да они вообще не умеют в дизайн».

Конечно не умеют так, как умели мы. Потому что профессия изменилась. И задачи изменились тоже.

Раньше ценностью было придумать новое.
Сейчас ценностью часто становится умение не сломать уже работающее.

Это не делает новое поколение хуже. Оно делает его другим.

Да и если честно, индустрии нужны все:
и те, кто ломает правила,
и те, кто умеет удерживать систему,
и те, кто двигает стиль,
и те, кто двигает продукт.

Все профессии важны, все профессии нужны.

Как искать респондентов в новой реальности?

Кажется, что сейчас про это собенно важно говорить не в формате «доклада», а в формате живой дискуссии между людьми, которые реально этим занимаются каждый день.

Поэтому ребята из UX Feedback проводят круглый стол без официоза и красивых слайдов. Чтобы вместе порассуждать, где-то поспорить, где-то сравнить опыт и посмотреть, как команды вообще адаптируются к новой реальности рекрутинга респондентов.

О чем будет разговор:
— что вообще сейчас происходит с рекрутом и качеством респондентов
— можно ли доверять агентствам и панелям так же, как раньше
— насколько рынок реально столкнулся с «ходоками» и профессиональными респондентами
— почему для одних команд рекрут становится всё сложнее и дороже, а другие почти не чувствуют изменений
— работают ли сегодня внутренние базы, комьюнити и собственный рекрут

Спикеры: Арслан Разыков (сооснователь UX Feedback), Регина Насибулина (специалист по рекруту респондентов в hh.ru), Кирилл Малык (Head of CS в федеральных госуслугах (РТЛабс)), Дмитрий Храпов (дивижн лид в вертикали Авито Авто)

Когда: 1 июня в 19:00 (по московскому времени)

▶️▶️ Регистрация здесь

Реклама ООО "ФИДБЕК" ИНН 5030094661, erid:CQH36pWzJqEgzwpVrHAjHh7SWoJ6kcrSbVQ5PnRTqxQiJu

Роман Черных написал, как усложнить использование вашего продукта мошенниками. И почему важно об этом подумать при проектировании.

— Не спрашивайте лишнего. Чем меньше храните пользовательских данных, тем меньше могут узнать и использовать мошенники;
— С фишингом помогает бороться персонализация (на фишинговом сайте сложнее показать пользователю его имя и аватар) и поведение динамических элементов (это поведение и анимацию сложнее воспроизвести);
— Предупреждайте о мошеннических сценариях: «Мошенники часто звонят и просят перевести деньги. Никогда не переводите по требованию из звонка»;
— Добавьте подтверждение для чувствительных действий (перевод денег, смена пароля, удаление профиля) через биометрию или аппаратный ключ, не через смс — мошенники могут перевыпустить симкарту;
— Для крупных операций можно добавить «период охлаждения» с дополнительным подтверждением через некоторое время;
— Добавьте мониторинг аномалий. Профиль начал массово отправлять ссылки — блокируйте его, подключайте человека для проверки. Пользователь указал нового получателя — предупредите;
— Не прячьте важную информацию за мелким шрифтом;
— Дайте возможность заморозить профиль (пользователям или представителям сервиса);
— Проработайте процедуру на случай взлома профиля пользователя, включающую замородку профиля и сохранение следов преступления;
— Тестируйте. Попросите специалистов по безопасности найти способ обмануть пользователей через ваш интерфейс: заставить перейти по вредоносной ссылке, подменить форму оплаты или сообщение от имени системы;
— KPI: количество жалоб на мошенничество, время реакции на жалобы, процент пользователей, прошедших обучение безопасности, уровень доверия в опросах.

#security

Хабр подвёл итоги конкурса «Технотекст 8», и моя статья оказалась одной из трёх победительниц в категории «Дизайн». Поэтому сегодня — повторная публикация её анонса в UX Notes.

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

— Когда человек заводит электронную почту, его имя пользователя и домен почтового сервиса становятся уникальным адресом;
— Но его не обязательно указывать в точности, чтобы получать письма;
— Все почтовые сервисы игнорируют регистр букв. Gmail — точки в имени пользователя. Почти все игнорируют то, что в имени пользователя указано после «+»;
— Фишка с «+» описана в одном из стандартов работы электронной почты и может использоваться для борьбы со спамом и сортировки почты;
— Плюс тестировщики могут так зарегистрировать несколько аккаунтов в тестируемых продуктах, не заводя множества почтовых ящиков;
— Некоторые почтовики работают на нескольких доменах. Например, gmail.com и googlemail.com, yandex.ru и ya.ru;
— По хорошему, сделав исключение для тестировщиков, всё это стоит учитывать при регистрации, входе и восстановлении пароля (в статье в общих чертах описан механизм), чтобы пользователи не создавали несколько аккаунтов, фактически связанных с одним ящиком;
— Пользователь может забыть, с каким адресом регистрировался ранее, и по ошибке завести ещё один аккаунт;
— Если посмотреть на крупные и популярные сервисы вроде ChatGPT, Notion, Amazon, они отрабатывают только кейс с регистром букв.

#login #signup

Ольга Петроченко написала, как уменьшить вероятность расхождения макетов и их реализации в мобильном приложении.

— Вёрстка — финальный макет, передаваемый в разработку, и его реализация в коде, которую разработчик передаёт дизайнеру на проверку;
— iOS, Android, WebView, десктопный и мобильный веб (плюс горизонтальная ориентация и планшеты) имеют особенности и технические ограничения, которые надо учитывать;
— Есть платформенные паттерны, но их могут игнорировать, пытаясь сформировать общий паттерн использования приложения, не зависящий от платформы;
— Технически на макете не всё собирается через таблицу или стек. Применять только Auto layout невозможно, так как элементы могут настраиваться через констрейнты, закрепляться на экране поверх остального контента, оставаясь его частью;
— Изображение не должно искажаться при изменении ширины контейнера. Как оно должно вести себя при увеличении ширины вьюпорта?
— Учитывайте это, и один макет будет работать с любой вёрсткой: широкой и узкой, горизонтальной и вертикальной;
— Паттерны навигации в iOS: Push (линейная со стрелочкой «Назад») и Present (модальная с крестиком). Можно комбинировать: внутри модальной использовать линейную (но пользователь может ошибочно закрыть весь флоу, по которому двигался в модальности);
— Чтобы не путаться, заведите под эти паттерны шаблоны в дизайн-системе. И вообще фиксируйте все правила, о которых договорились с разработчиками;
— Определяйте типы элементов в макете. От типа зависят их свойства: какие есть состояния, могут ли отображать загрузку и ошибку, нативные или кастомные это элементы, должны ли нажиматься;
— Передать информацию о типе можно, использовав определённые компоненты дизайн-системы (по крайней мере так реализовано в Альфа-Банке);
— Если этого не делать, разработчики будут возвращаться с вопросами или даже делать так, как сами (неправильно) поняли;
— Экран может быть реализован с помощью разных технологий: фронтовая вёрстка, серверная (например, BDUI), комбинированная;
— Технология определяет допустимый набор элементов и возможности их кастомизации. Например, весь экран — это модуль, и его можно только переиспользовать;
— Макеты — это техническое задание. Качественное ТЗ — залог лёгкого последующего дизайн-ревью. Но чтобы делать качественно, надо общаться с разработчиками (не стесняясь задавать глупые вопросы) и понимать технические нюансы.

#mobile #handoff

🎬 Люди говорили о важном и было хорошо (с)

23 мая в Москве прошла третья конференция «Просто Сложно» про дизайн и исследования инженерных продуктов. Записи, материалы и дискуссии доступны в канале конференции.

Спикеры — из Сбера, NAVIO, Бюро Горбунова, AVITO, YADRO, Бюро 1440 — поделились опытом о том, как делать сложные инженерные продукты простыми и удобными.

Доклады были практичными и вдохновляющими:

✔️ Илья Бирман из Бюро Горбунова посадил зал в машину времени и отправил на 20 лет назад, чтобы задать неудобный вопрос: почему мы до сих пор не научились делать адаптивный дизайн правильно? Один из самых дискуссионных докладов конференции.
✔️ Команда NAVIO показала на реальном кейсе, с какими задачами сталкивается дизайнер беспилотных тягачей.
✔️ Мария Копачевская из компании YADRO увлекла историей про исследования в hardware-разработке: как изучать пользователя там, где продукт буквально железный.
✔️ Отдельное удовольствие было слушать доклады про AI-агентов и то, как они меняют UX в инженерных продуктах.

Смотрите записи выступлений, задавайте вопросы спикерам в комментариях и узнайте первыми о следующей конференции в канале ПРОСТО СЛОЖНО

Никита написал об особенностях создания транспортных схем на иностранных языках (тоже победитель «Технотекста 8» в категории «Дизайн»).

— Их никогда не переводят полностью. Перевод топологических имён вроде «Красносельская» навигацию только усложняет;
— Названия большинства объектов транслитерируют или транскрибируют, чтобы передать звучание, не передавая смысл;
— Полная транслитерация со всеми составными частями (Ленинградский вокзал → Leningradskiy Vokzal) основана на идее, что главная задача схемы — навигация в пределах транспортной системы;
— Чтобы понять, где он и куда ему идти, пассажир может сопоставить голосовое объявление остановки с надписью или спросить у местного жителя;
— Альтернатива: переводить слова «вокзал», «улица», «площадь». Упрощает навигацию за пределами транспортной системы: можно увидеть объект в окно и сопоставить место со схемой. Но усложняет восприятие аудиосообщений;
— Такой подход зафиксирован, например, в правилах оформления Народной карты Яндекса;
— Компромисс: транскрибировать всё, а важным для навигации объектам добавлять перевод. Минус: больше надписей, хуже читаемость;
— На китайском звуки передаются иероглифами (одному звуку могут соответствовать разные). Но так как каждый иероглиф — слово, может появляться дополнительный смысл;
— Имя «Юлия» можно написать: а) 朱莉娅 (Zhū​lì​yà) — красный, жасмин, шурин; б) 猪厉亚 (Zhū​lì​yà) — свинья, злой, ущербный;
— Переводчик отвечает за уместность возникающих ассоциаций. Обычно используют словари официальных транскрипций, а если нужного топонима там нет — правила китайско-русской практической транскрипции;
— В схеме Московского метро на китайском и арабском совмещены 3 подхода;
— В арабской версии в названии станции «Аэропорт Внуково» перевели «аэропорт», так как станция находится в аэропорту. А название станции «Аэропорт» транскрибировали, так как там аэропорта нет;
— Вместо китайских и восточных арабских цифр на схемах используют привычные цифры, так как они служат обычно идентификаторами. Они должны совпадать с тем, что встречается на указателях и табло;
— Если цифры должны передать именно числа (например, время работы), то можно использовать восточные арабские цифры. Для китайской версии сойдут обычные, так как в Китае их тоже используют;
— Станция «Улица 1905 года» записана с цифрами. Сложнее распознать по звучанию, зато надпись занимает меньше места и её легче заметить на табличках, экранах и бегущих строках.

#localization #writing #transport

Напоминание:
Сегодня в 19:00 (по московскому времени) — круглый стол от UX Feedback. Зарегистрироваться можно тут.

Опубликован отрывок из книги Юрия Ветрова «Паттерны дизайн-менеджмента», посвящённый Т-образным специалистам.

— У них глубокая экспертиза в ключевых навыках и поверхностная — в широком наборе смежных;
— Если не вовлекаться в формирование требований, могут приходить задачи, которые сложно сделать хорошо;
— При разработке выявляются технические ограничения, мешающие сделать как задумано. При эксплуатации появляется пользовательская обратная связь;
— Сейчас все делают неплохие интерфейсы. Чтобы выделиться, надо прорабатывать вовлечение пользователя, строить кросс-канальное взаимодействие, проектировать всю цепочку оказания услуги;
— Объём нужных знаний ведёт к узкой специализации, что усложняет коммуникацию (каждый создаёт и передаёт дальше свои артефакты), удлиняет производственный цикл, размывает ответственность;
— Это подходит дизайн-студиям и аутсорсерам, которым важна формализация и предсказуемость, так как их клиенты покупают заранее оговоренный результат;
— Но не подходит стартапам (дорого нанимать столько специалистов) и продуктовым компаниям (важна скорость);
— Главный навык продуктового дизайнера — брать на себя ответственность за продукт. Чем именно он поможет команде — вопрос её специфики;
— Лучшие практики и здравый смысл — хорошо, но что если пользователям в конкретном продукте удобно по-другому?
— Важно применять эмпатию и к пользователям, и к коллегам, чтобы принимать дизайн-решения с учётом их болей и задач;
— Дизайнер работает в связке с продактом: помогает формировать продуктовое решение, снабжать продакта знаниями о пользователях, нужными для успешного запуска;
— Собираются ситуативные рабочие группы, где каждый дизайнер силён в своей теме и помогает в ней остальным. Автор дизайна в этом случае — ответственный, кто всё свёл воедино и довёл до результата;
— Лучшая спецификация продукта — работающий продукт. Лучше потратить время на его полировку, чем на эстетичные сопроводительные документы. Артефакты быстро устаревают;
— Важно не просто обрабатывать входящие запросы, а систематизировать наработки, переиспользовать паттерны, автоматизировать часть работы, не пытаться решить все проблемы одним рывком;
— Уровень владения смежными навыками: от осведомлённости (понимание того, как работает специалист в этой области) до умения (способность решать базовые задачи в области, доделывать за специалистом работу, вносить осмысленные правки);
— Есть разница между ролью и специалистом. В разных проектах один специалист может выполнять несколько ролей. Либо одну роль могут закрывать несколько человек;
— Уровни зрелости компании: возникла потребность в Т-образных дизайнерах → часть команды → все дизайнеры Т-образные.

#management