Ещё момент про юристов и договоры. Я поражаюсь насколько невнятно юристы порой формулируют. Мне кажется, многих юристов надо на пару лет отправлять учиться программировать, чтобы просто мозги на место поставить.

Сколько внутренних противоречий и нестыковок я встречаю в чужих договорах — это кошмар. Иногда прям хочется сказать: ребят, ну вам не стыдно? Вы юристы, у вас работа чётко и недвусмысленно писать. Я дизайнер, и я вижу весь ваш тупняк, даже когда читаю текст по диагонали! Но если прямо так сказать, то клиент, вероятно, обидится.

Вот формулировка, которая часто встречается во всяких пунктах про ответственность: «в таком-то случае Заказчик вправе требовать с Исполнителя возмещения того-то». Что это значит, зачем это писать? Я безо всякого договора вправе выйти на улицу и требовать, чтобы все прохожие сдали мне по тыще рублей. А прохожие вправе посылать меня с этим требованием подальше!

Удивительно, но большинство юристов не в состоянии написать: «В таком-то случае Исполнитель возмещает Заказчику то-то» безо всяких абстрактных прав требовать.

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

Это фрагмент № 115 онлайн-курса «Пользовательский интерфейс и представление информации». Записано на курсе 28 апреля 2023 года.

До 6 октября идёт запись на курс, который пройдёт с 7 октября по 5 ноября.

Почитать о курсе

Программа, отзывы, запись

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

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

Ещё часто в договоры вставляют раздел про конфиденциальность, и в нём тоже много про ответственность. Этот раздел я предпочитаю убрать целиком. В большинстве случаев это просто не нужно. Не передавайте мне конфиденциальные данные, да и всё. Понимаю, бывают случаи, когда надо, но если вы меня приглашаете прочитать лекцию в вашей компании, то зачем нам это?

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

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

Это черновик, который я решил опубликовать.

Поток данных — один из моих методов проектирования интерфейса. Он помогает избавиться от ненужных экранов и шагов.

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

Простой пример

Человек собирается в поездку и хочет узнать погоду в городе назначения. В идеале должно быть так: человек только подумал об этом, и хоп — уже знает погоду. Но пока что это недостижимо, нужен интерфейс.

Интерфейс помогает данным о запросе человека попасть в машину; данным ответа попасть к человеку. Не прозевайте: предыдущее предложение — ключевое, ведь в нём написано, зачем нам вообще этот интерфейс! Так данные на входе — это город, а на выходе — погода. Отсюда получаем интерфейс: поле ввода города, и рядом — погода в нём.

Дальше уже его улучшаем автодополнением, обновлением по мере ввода, историей; помним город или даже несколько с прошлого раза, чтобы даже не вводить. Это просто применение базовых принципов.

А как было бы неправильно? Ну, например, начать анализировать предметную область, из каких параметров складывается погода и как их сгруппировать, или там как города объединяются в страны, а страны в континенты, проектировать навигацию по этой базе. Это всё «логично», но не должно быть основой интерфейса, так как не помогает потоку данных.

Сложный пример

Я делал интерфейс «Секьюриджа», программы для мониторинга объектов пультовой охраны. В магазинах, банках, квартирах установлены сенсоры и передатчики. По городу дежурят группы быстрого реагирования — «бойцы». Оператор следит за событиями и руководит перемещением бойцов с помощью программы.

В версии, которая была до меня, да и у конкурентов, были «модули»: в одном отображались сигналы, в другом — карта города с расположением бойцов, в третьем — картотека самих охраняемых объектов с поиском, в четвёртом — какой-то журнал, куда оператор должен записывать свои действия. Снова, всё «логично», но не помогает потоку данных.

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

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

Ну и всё, исходя из этого и строим интерфейс:

Нет никакой причины оператору по крупицам собирать информацию по разным модулям и потом заносить результат в ещё один модуль «журнал». Вся информация должна сразу быть перед глазами, как и кнопки записи итогов в журнал. Оператор видит всю картину и как с кем связаться; разбирается в ситуации; здесь же жмёт на итоговую кнопку.

Применимость

Такой способ думать об интерфейсе подойдёт, когда речь о конвейерном, транзакционном взаимодействии. На этом сложно построить интерфейс Гугль-дока или программы 3д-моделирования, ведь там процесс работы слишком творческий, нелинейный. Но всё же всегда полезно думать не модулями и не «бизнес-сущностями», а сценарием и ролью интерфейса в нём.

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

Недавно я показывал проект — информационное сопровождение Челябинской транспортной реформы. В мае рассказывал о нём на «Просмотре», и вот выложили видео:

Видно, что монтировал не я: слишком много крупного плана и не видно слайды, когда надо.

А ещё во второй половине кажется, что у меня вылезли красные трусы, но на самом деле это водолазка. Вообще эта чёрная кофта не была запланирована, но на площадке был адский дубак, и в свободное от доклада время я тупо стоял перед тепловой пушкой.

Задизайнить спинку кресла в самолёте — отдельное искусство. В большинстве самолётов они фиговые: один карман для всего, неудобный столик. Но на днях мне попалась довольно клёвая.

Исходное положение. Сразу чувствуется, что много про что подумали:

Сверху есть карман для «прессы», причём из него ничего не вываливается внизу, как иногда бывает. Он достаточно просторный, чтобы в него переложить никому не нужный журнал «Аэрофлот» из нижнего кармана. Есть отдельная мини-штуковина для геджетов и отдельный столик. На крышке столика ещё и приятные пиктограммы напоминают про безопасность.

Открываем верхнюю штуку:

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

Снизу — ещё один карман:

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

Прочитал в сентябре в Москве доклад-лекцию «Как эффективно презентовать работу»:

Это доклад для дизайнеров, менеджеров, программистов, маркетологов, редакторов — для всех, кто защищает свою работу.

Приходите на наш онлайн-курс о презентациях с семинарами и практикой.

Спасибо организаторам iSpring Days — конференции о корпоративном обучении — за приглашение и запись выступления.

См. также киевскую лекцию о понимании задачи.