Сила комментария

Сила комментария

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

— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге

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

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

Например, на «Дадате» мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?

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

Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:

— точно ли нужны именно эти поля?
— действительно ли они нужны?

Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.

Комментарий — элемент хаоса. Но с ним система устойчивее.

Как спрашивать «зачем»?

Как вы помните из заметки про фичреквесты, которые не стоит выполнять (https://t.me/pmdaily/98), вопрос «зачем?» — самый важный вопрос, который нужно задавать любому представителю бизнеса, который пришел к вам с задачей.

Однако задавать постоянно этот вопрос не так уж и просто: если в лоб спрашивать у каждого постановщика, зачем ему эта задача, он может и обидеться — к вам же пришли, оторвались от важных дел, подумали головой, а вы тут сидите с умным видом и объясняете, что делать ничего не нужно.

Вот пара трюков, чтобы процесс задавания вопросов пошел легче:

  • Объясните, чем вы можете помочь, имея это знание. К примеру, только вы знаете все уголки системы настолько, чтобы не пилить новую фичу, а предложить уже существующую похожую.
  • Поговорите про цифры: «Подскажи, какие показатели мы прогнозируем в результате?». Когда вы говорите про цифры и гипотезы, то вы находитесь максимально далеко от личности постановщика задачи, а значит ему будет спокойнее отвечать на ваши вопросы.
  • Расскажите, что понимая конечный результат, вы забираете на себя больше ответственности — если в конце спринта будет говно, то виноваты будете вы сами, а не тот, кто плохо поставил вам задачу. Для постановщика это выглядит как делегирование, а делегирование любят все менеджеры

Итеративный процесс в дизайне и инженерном творчестве

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

Итеративный процесс работы в проекте может быть сложным если не учитывать нескольких факторов:
— Желаемый результат, финальная функциональность и потребности людей должны изначально описываться в четырех группах. Обязательные, измеряемые показатели, устанавливаются заказчиком.
— Возможные, измеряемые показатели, параметры успешности и критерии заказчика ограниченные максимальными возможностями разработчиков.
— Конкурентные, зависимые от возникающих обстоятельств в процессе разработки и прогнозируемые как потенциальные, измеряемые.
— Коллаборативные результаты, факторы синергического влияния на результат возможных в процессе разработки объединений компетенций, реакция на контекст изменений в потребностях людей и возникновений новых условий и инструментов разработки.
— Необходимо оберегать и сохранять промежуточные проектные разработки. Итеративный процесс не исключает возврат к прошлым шагам, решениям и условиям и пересмотру «проектной истории»
— Важно сохранять единый список критериев и стандартов требований ко всем этапам итераций в разработке, не меняя критерии, или при изменениях стараться заново проверить прошлые версии решений на соответствие новым стандартам и критериям.
— Надо понимать, что итеративный этап разработки может при перспективной идее показать неудовлетворительный результат, но по возможной причине качества реализации замысла. Стоит уметь оценивать идею отдельно от этапа реализации и видеть как измерять и сравнивать разные характеристики. Два прототипа, один ориентирован на проверку самой идеи и ее барьеров и ограничений. Второй прототип проверяет качество реализации выводов после активного тестирования первого прототипа, но используя технологии близкие реальному производству.
— Команда разработчиков привычно проверяет и выносит независимые суждения по эффективности решения, если есть желание пойти на компромисс, пожертвовать функциональностью в целях материальной экономии, то для этого нужны веские аргументы целесообразности и компенсации недостатков опорными действиями. Ограничиваем функциональность, значит увеличиваем режим обучения, возможно объединяем отдельные действия в функциональные блоки.
Итеративный процесс разработки чувствителен к данным и наблюдениям. Сама разработка может повлиять на сам внутренний процесс работ и на методы, как и на трансформацию первичных требований и технических заданий, основываясь на возникающем постепенно понимании потребностей и инструментов реализации этих потребностей, как и возникающих рисках и вызовах.

Например, «ОКБ Сухого» Информационно-управляющее поле кабины самолета СУ-35 / Т-50 было разработано в нескольких вариантах в виде тренажера, прототипа геометрии кабины и интерфейса управления с обратной связью в среде купола виртуальной реальности, через который пропустили несколько сотен курсантов с летных училищ с типичными заданиями.

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

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

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

Про адаптацию стажеров и младших специалистов

Наш руководитель веб-направления Таня Аладина интересно написала про адаптацию стажеров и младших специалистов:

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

Но вот в ситуации, когда младший целиком сдает свой этап работы сам, даже если предполагается ревью — есть сильный риск упасть в качестве. Самостоятельно – младшим должна доставаться работа начального уровня сложности. Младшие менеджеры, ответственные за проект целиком — довольно опасная ситуация. Пока не придумала, как можно продюсеров соединять в пары.

А тем временем, уже прошло 3 занятия

На второй лекции нам рассказали про дорожную карту, по которой будет проходить наша работа над проектом. Построена она по принципам дизайн мышления (ДМ).

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

По сути ДМ — это решение проблемы, запрос на которую указал пользовать. Есть мнение, что проводить ДМ нужно в первую очередь для бизнеса (заказчика), чтобы обосновать ему, почему нужно делать удобно, решая проблемы пользователей, а не только бизнеса.

В любом случае, ДМ, это самый настоящий инструмент, позволяющий путем набора определенных методов выявить сначала проблему, а затем сгенерировать обоснованное решение.

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

Надеюсь, после прохождения этих этапов в рамках нашего проекта, и мне и вам станет яснее, что из себя представляет процесс ДМ.

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

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

Брови заголовков

Исследования (https://www.nngroup.com/articles/first-2-words-a-signal-for-scanning/) показывают, что пользователи не читают заголовок полностью, а лишь первые несколько слов.

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

Как же тогда решать эту проблему? Используйте брови заголовков.

Брови заголовков — это описательное ключевое слово или фраза, расположенная над основным заголовком.

К примеру: у вас на главной странице банка есть слайдер, а в слайдере предложение с пониженной процентной ставкой по кредиту — добавьте к заголовку бровь «Кредиты». Время, которое пользователь потратит на принятие решения о том, интересна ему эта статья или нет, максимально сокращается.

Как сделать брови заголовков?
Сделайте их меньше основного заголовка, но все же читаемыми. Что бы их выделить, можно сделать жирнее, написать капсом или изменить цвет.

Когда нужно использовать брови заголовков?
Не каждый заголовок нуждается в бровях. Излишне добавлять брови, если ваш заголовок короткий и содержит много ключевых слов. Помните о правиле двух первых слов.

Брови заголовков
— достаточно короткие для сканирования
— используют понятные ключевые слова
— дают пользователю контекст
— легки для восприятия