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

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

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

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

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

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

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

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

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

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

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

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

Полезная привычка: всегда обьяснять правки

Нет ничего хуже редакторских правок без объяснений.

Лучше всегда рассказывать, что вы там натворили в макетах (или где вы там работаете). Устно или письменно на полях — без разницы. Вот почему это в ваших же интересах:

— Меньше рассинхрона. Конечно, если дизайнер норм, он задаст вопросы, когда что-то покажется странным. Но может понять причину правки по-своему и не задать.

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

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

Короче, объяснения — часть товара, который продаёт редактор.

Алан Купер написал, почему сейчас трудно делать удобные продукты.

Чтобы сделать удобный продукт, нужно много времени, денег, знаний и ресурсов. Бизнес ищет способ делать всё быстрее, проще и силами наименее квалифицированных людей.

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

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

Ничем не ограниченный бизнес грабит рынок, а кроме этого грабит и более ответственные компании, уничтожает сообщества и разграбляет их активы.

Специалисты, будучи ответственными гражданами, пытаются примирить непримиримое. Они спрашивают: «Хотите, чтобы это работало быстрее?», «Хотите, чтобы я рассчитал окупаемость инвестиций?», «Хотите, чтобы я сделал это более джазовым, сексуальным, привлекательным?», «Стоит ли мне быть более гибким?», «Стоит ли мне использовать дизайн-системы, дизайн-мышление, дизайн-методы?».

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

Мы ищем ответы не в том месте.

https://vc.ru/design/97289

Денис Невожай о доме будущего и дизайне интерфейсов для часов.

Старший UX-дизайнер в Essential
http://dnevozhai.com/

— Привет Денис. Чем ты занимаешься в Essential?

UX Design для Home продукта. Если точнее, то работаю над архитектурой и логикой для таких систем как домашняя безопасность, управление IoT устройствами в доме и т.д.

— Почему ты решил заниматься только UX? У тебя же и UI отлично получается)

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

— Как будет работать дом будущего?

Волшебно) Люди не будут думать о том, как включить свет и открыть дверь, когда возвращаются домой. Дом будущего будет достаточно умным, чтобы помогать людям выполнять ежедневные рутины, но при этом не будет назойливым. Взаимодействие между всевозможными объектами будет целостным, работать как единая система, а не как набор из 10 приложений одно из которых IFFFT (если это, тогда то).

— Ты занимался интерфейсами для Alcatel One Touch и Amazfit. Что нужно в первую очередь учитывать, рисуя дизайн для часов?

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

— Как ты проверял свои решения?

На телефоне с маленьким, кругленьким экраном внутри )

— Как делать UI для круглых экранов?

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

— Что смогут делать носимые устройства через 5 лет?

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

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

— Какие устройства станут популярными через 5 лет?

Штука, которая взорвет мир — дополненная реальность. Но это произойдет только когда эти устройства смогут быть достаточно незаметными и не «странными» как Google Glass. Был слух от знакомого, который работает в Magic Leap, о том, что люди на закрытом демо не могли отличить искусственные объекты от реальных. Это впечатляет, обнадеживает и пугает.

— Ты много путешествуешь. Какое место нужно посетить каждому дизайнеру?

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

Есть смысл посетить Китай, но не как турист. Прикол в том, что это тоже очень другое общество и другой дизайн. Я пользовался некоторыми китайскими приложениями и сайтами и был в шоке от того, как все отличается от западного. Такой опыт помогает выработать эмпатию и понять, что не все то, что ты считаешь правильным, относится к каждому человеку.

— Apple или Google?

Apple. Он очень грамотно строит экосистему, где все продукты работают слаженно и дополняют друг друга. Он делает самое крутое и красивое железо. Apple перевернул многие индустрии, поднял планку качества. Заботится о приватности пользователей и делает много хороших вещей, параллельно подсаживая все больше и больше людей на свои продукты ;)

Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта User Story Mapping

Часть 1. Пользовательская история: https://medium.com/xraizor/b0b0d724d77e

Карта историй создаётся для нового продукта или когда существующий продукт надо частично или полностью переделать, и требуется описать объём имеющейся функциональности.

На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Хорошо, если есть картирование процессов в форматах Customer Journey Map или Service Blueprint.

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

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

Любая пользовательская истории записывается для действующего лица: персоны или функциональной роли в системе. Близкая методика Use Cases лишена эмпатии к человеку, для которого создаётся программа.

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

Часть 2. Алгоритм проведения и рекомендации для ведущего: https://medium.com/xraizor/9a90beb2ff57

Часть 3. Чистка историй от ложных требований. Критика метода: https://medium.com/xraizor/2f7bd967a54a