Protraktor

Пост без выводов. Для своих яхтенных и прочих поделок запарился с личной дизайн-системой, в которой будет около пяти цветовых палитр. Заодно хочу в этом эксперименте («моя селедка — хочу покрашу») попробовать поиграться с концептуальными подходами, на которые никогда не хватает времени в коммерческой части. Один из них — это что хочется, чтобы система хорошо дружила с зонированием заливками (то, что сейчас мягко говоря не модно, и это плохо — см. ниже), а элементы на различных зонах интерфейса выглядели плюс-минус одинаково (а значит зависели от фонового цвета — иначе сильно начинает изменяться контраст элемента в зависимости от фона). Думаю, это одна из причин почему сейчас все всё делают плюс-минус одного фона — слишком запарно заморачиваться с позиций токенов. Обратная медаль — когда всё на одинаково белом или темном фоне — это повышает визуальный шум, а не снижает его (нет группирующих признаков разнообразных элементов). И я их понимаю — на глаз подобрать сложно, а попытки алгоритмически (учитывая воспринимаемую разницу относительных яркостей, контраста и т.п.) мне не понравились, хотя я так и не дошел до цветового пространства HCL. И это я еще семантическими цветами (все эти светофоры) не играюсь, да и с палитрами “день”, “ночь”, “инвертированный день” и “полная ночь” (красная) не стал еще заморачиваться. Впрочем, ни один дизайнерский продукт пока не даже близко не подошел к такой степени задротства и работает исключительно на вкусовщину, никак не помогая подходам на перцепцию. Но всё же интересно попытаться построить не просто на глаз, а с какой-то логикой цветовую систему. Я, конечно, не верю в чистую математику тут, но поглядим.

Вот интересно, кто может объяснить разнобразие этих элементов? Особенно отличие верхнего от нижнего

Про концепции. (Микро)заметка №3 События последних дней убедительно показывают — любая концепция, какой бы последовательной, цельной, выстраданной и проч она ни была, требует внешней валидации. Иначе может получиться, что она устарела, не адекватна бизнес-контексту, не будет продана аудитории и стейкхолдерам. Не редко бывает, что очень многие решения из прошлого заметно лучше по функционалу, эргономике и ряду других аспектов относительно более новых решений; но при этом они морально устарели — например, я как-то общался с авиадиспетчерами (“подглядывал за соседями”) и они делились именно таким опытом — в новой системе им просто не хватало базовых вещей, а UI был откровенно захламлен. Но увы, накопившиеся третьи проблемы привели к тому, что предыдущая система серьезно устарела и была сложна в сопровождении, а новую версию уже невозможно было делать (да и некому) по старым принципам. Так что валидируем. Но не впадаем в популярную ловушку UX — часто мы обсуждаем то что есть, а не то что может быть — легко пропустить потенциально интересные и перспективные истории. Правильно сфокусировав на восприятие концепт (“это мысли вслух, гипотезы, хотим узнать ваше мнение” и т.п.), даже глупые на первый взгляд идеи могут заискрить у внешних валидаторов такие предложения, что мама не горюй. Ну а потом уже доходя до конкретики можно использовать и весь арсенал исследований по детализации решения вглубь, а не вширь.

Не люблю я всякие «менеджерские» истории, но вот эта статья может быть полезной (тем кто не сталкивался), ибо в тему концептуализаций — самый базовый фундамент по итерациям этапов дивергенции (я называю «расширить сознание») и конвергенции (сделать нечто конкретное). Лично для меня это не что-то абстрактное, а как я работаю и размышляю уже с десяток лет. https://medium.com/zendesk-creative-blog/the-zendesk-triple-diamond-process-fd857a11c179

Про концепции. Заметка №2 Добавлю сразу пару слов что такое концепции в том смысле, как я их делаю. Итак, концепты легко попутать с макетами интерфейса. Но фрейминг и задачи у них принципиально иные (поэтому, в частности, концепты категорически нельзя показывать без комментариев, либо передавать разработчикам на оценивание/валидацию). Я бы сформулировал концепцию так: концепция — это коммуникативный инструмент, визуализирующий продуктовые гипотезы и варианты их решения для последующего обсуждения. Когда продукта еще нет, но есть много рассуждений, возникает проблема в том, что люди не понимают друг друга — особенно представители бизнеса, которые способны мыслить на разных уровнях абстракции, причём больше с позиций целей и задач, чем реализации. И даже если используются общие термины, каждый вкладывает в них своё. Именно поэтому часто нужен концепт — для облегчения обсуждений будущего продукта. Причём независимо от того, есть ли конкурентные аналоги (ибо нам нужно отстраиваться от них, а не думать аналогиями), или это инновационный продукт. Концепция — далеко не всегда ваерфрейм (если только участники продуктовой команды уже не знакомы с подобными подходами). Она обладает дизайном, а контент в ней реалистичен — ибо стейкхолдеры могут легко отвлекаться на заглушки или же видеть что-то своё за квадратами. При этом там нет никаких ветвистых сценариев, а многие функциональности замылены — ибо их ещё никто не определял. На мой взгляд лучший способ подачи концепта — презентация. Ибо обязательным составом концепции являются: * Схемы основных воркфлоу * Ключевые идеи и принципы продукта * Ну и сами мокапы Как следует из определения, концепция — не совсем предложение, как делать продукт. Визуализация макетов нужна лишь для облегчения коммуникции, но при этом любой автор и пользователь концепции должен исходить, что это в высокой степени материал на выброс, это в первую очередь для обсуждения проблемы, и только потом её решения. Разумеется, в условиях ограниченных ресурсов нужно постараться, чтобы концепт был максимально полезным и с позиций решения проблем. Но first things first. Именно поэтому в концепт обязательно включение принципов/идей — почему мы считаем что наше понимание проблемы таково, а виденье её решений — вот такое. Просто картинки, ввиду размытости их интерпретаций на ранних этапах — не облегчат понимание, а испортят его ровно в тот момент, когда концепт «пойдёт по рукам». Если концепт всем понравился — это должно настораживать, мигом идём валидировать с внешним миром. Также концепт не должен содержать никакого маркетинга — это не инструмент продажи (хотя, честно уж скажу, что этот элемент есть — но не стоит рисовать космос и звездолеты, ибо это внутренний инструмент, и любой программный архитектор быстро поставит на место). Если концепт вызвал бурную и подробную критику, обозначил противоречия во взглядах стейкхолдеров, сгенерировал кучу предложений — это очень хорошо. Выбрасываем его, делаем следующую итерацию. В каком-то смысле концепт — это визуализация тех саымх «правильных вопросов, содержащих большую часть ответа» (см. историю выше и рассказ Роберта Шекли). Но бывает что он не вызывает никакого отклика. Это значит что концептуализатор и стейкхолдеры не синхронизированы в плане ожиданий. Об этом потом.

Про концепции. Заметка №1 Хоть я и очень сильно занят новой работой, попробую немного накидывать про то, чем я в последние годы занимаюсь больше всего (и за что, в общем-то, получаю деньги) — про концептуализацию новых или «реконцептуализацию» существующих продуктов — некий аналог problem-solving, когда ты из своей головы и куч других источников в условиях нечетких постановок, условий и знаний пытаешься сформировать достаточно конкретное и подробное (для дальнейшей проработки) виденье нового продукта. Никакой системности не будет, будут скорее заметки на полях. Но системно и не смог бы — в общем-то, сейчас и пытаюсь понять, как я сам это делаю. Ибо иногда уж больно это непрогнозируемо, хочется хоть как-то оптимизировать-рутинизировать этот мутный творческий процесс. * * * Итак, любое концептуальное проектирвоание завязано на изучение предметной области и контекста и формулирование гипотез. И одни из важнейших гипотез — цели продукта. И это не решаемые им задачи — они скорее следствие целей, либо их детализация. Хотя к целям можно прийти от задач. Но это не одно и то же. Далее — муть из предсознательного. Цели бывают хорошие и не очень. Те, что не очень, можно генерировать сотнями, это легко: — Например, подменяют цели продукта с целями бизнеса («Стать первыми на деревне и заработать бабло»). — Либо апеллируют к фичам, возможностям («Показывать погоду», «Планировать операции флота», «Заказывать карты») — хотя это одни из самых частых — Либо апеллируют к требованиям («Сделать конвенциональный продукт» — то бишь, удовлетворяющий каким-нибудь стандартам) Не очень, потому что они мало говорят про то, чем же продукт исключителен (а если продукт не исключителен — то концепт ему не нужен, можно сразу нормально делать). Вообще, скорее всего цель будет не очень. Ибо сформулировать хорошую продуктовую цель — и при этом понятную для внутренних и внешних потребителей — это значит уже заметно снизить энтропию нового продукта. Копать вглубь проще, чем ползать в темном непаханном поле. Но неплохо, когда продуктовая цель помогает понять ценность продукта. Например, затрагивает проблему, которую продукт снимает с потребителя/пользователя. Хорошего примера сейчас не приведу, но, например, это может быть «Цель — уменьшить коммуникативные разрывы и сопутствующие им беды между пациентом и доктором». А теперь главное (удивительно, как часто плохие цели формулируются даже собственниками). Пользователямпродукта плевать на то, что бизнес хочет стать первым. Также пользователям не нужно заказывать карты — им нужно осуществить мероприятие, сэкономив деньги и поддержав необходимый уровень безопасности (то бишь, опять же, снижение рисков издержек — финансовых, репутационных, да и уголовных тоже). И мало каким пользователям интересна цель по показыванию погоды (модель данных) — как минимум, потому что она уже достигается бесконечностью способов. А вот если вместо данных мы напомним, что… ну да не будем уходить в детали. Хороший концепт очерчивает, формулирует и выражает эту цель, по возможности наглядно, чтобы синхронизировать ожидания и представления. И начать обсуждать как это делать и стоит ли вообще (за свою карьеру я пару раз точно наглядно демонстрировал концептом, что не стоит вкладываться в продукт). Лучший способ выйти к целям — задавать хорошие вопросы. Например, «с чего вы взяли что это плохо?», «почему мы считаем озвученную проблему проблемой?» или «а разве не бывает обратных ситуаций?». Иногда хорошие вопросы приносят больше пользы, чем работа над целью продукта — и абсолютно точно, с них ценность концептуального проектирования и начинается. Ибо хороший вопрос не оскорбляет, не укзаывает, но заставляет задуматься, переосмыслить очевидное, ну и узнать что-то новое — не только вопрошающему, но и отвечающему (да-да, не просто я так часто вспоминаю методы психоанализа). По теме очень советую прочитать рассказ фантаста Роберта Шекли «Верный вопрос» — https://mipt.ru/dcam/students/books/fiction/otvet.php. Там на 20 минут всего.

На эту тему уже много кто выражался, но всё же. Вот явный пример, когда сталкивается масс-маркетный подход и подход профсистем. Ни в каком адском сне я бы не стал делать метки диаграмм такими блеклыми — они совершенно нечитаемы из-за низкого конраста. Accessibility к черту, как и людей с плохим зрением. Первая интерпретация внизу была — что это за дни, когда я не сидел за компом (единый таймлайн не считывается из-за разбивки на два графика, да и осмысленность представления за день не очень высока), а табы вверху выпали из восприятия опять же потому, что не воспринимаются за элемент, связанный с нижележащим контентом. Это «интерфейс моментальной работы», пользователь не будет вглядываться в него и всё должно максимально быстро считываться, что не сделано. Зато, видимо, красиво. #оценочные_суждения

На всякий случай — список книжек, которые я считаю полезными и важными, я веду тут — https://protraktor.design/ru/reference/recommended-literature/

Меж тем, на днях, 13 января, была круглая дата — прошло 10 лет как Коста Конкордия наткнулась на скалы близ острова Джилио и частично затонула, убив 32 человека. Про эту историю есть превосходная книжка, написанная Антоние Ди Льето, старшим инструктором крупнейшего в мире тренажерного центра по подготовке мореплавателей CSMART (руку к которому я немного тоже приложил в своё время). В ней он описывает подробно как катастрофу и самые разные её причины на разных уровнях абстракции, так и что стоило бы поменять для повышения безопасности мореплавания. Я прямо очень её рекомендую всем, кто интересуется профсистемами и контекстами их применения — никаких упрощений, и при этом без формализма, а выводы впоолны применимы не только к транспорту, но и к системам управлением электростанциями, производством, медоборудованию и т.п. https://www.amazon.com/Bridge-Resource-Management-Concordia-Navigation/dp/0994267207

В довесок к этому — почему сохранять полезно. Где-то пару лет назад какая-то дизайн-контора из Турции, работавшая, видимо, на турецких военных, выложила аж на Дриббле кучу модных скринов систем по планированию и управлению беспилотниками и, видимо, постами войск (battle или combat management, что-то такое, я не очень в теме). Я прифигел, наткнувшись на них (впрочем, не скажу что там было что-то очень уникальное), ну и побыстрому сохранил. Где-то в течение месяца им, видимо, надавали подзатыльников, и они быстро скрыли процентов 80% скриншотов, оставив совсем унылые типовые таблички и т.п. То же самое часто с результатами всяких нетипичных исследований. Была какая-то контора, которая очень подробно освещала процесс переосмысления дизайна кокпита Боинга, кажется. С зонированием органов управления и т.п. Контора быстро обанкротилась и всё пропало, а я не сохранил, о чем до сих пор жалею — идеи там были хорошие.