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

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

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

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

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

Кратко про решение

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

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

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

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

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

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

Но что делать с проблемами, которые не укажешь одной только точкой? Например, отсутствие тротуара на протяжении всей улицы, или область с повышенным трафиком пешеходов?

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

Контекст пользователя

Контекст пользователя

Меня часто подкалывают, что я постоянно топлю за фокус на задаче, когда проектирую интерфейс. "Надоел ты, Леха со своими задачами. Поняли уже!", - говорят мне. А я то и рад, что у народа это на подкорку записалось. Но...

Помимо задачи пользователя, важен еще и контекст, с которым он к вам приходит. Выдерживает ли интерфейс этот контекст? Способны ли мы правильно "встретить" человека и провести по сценарию?

Пример

- Собираем карточку товара. Кладем сюда фото, сюда описание, а сюда кнопку "Купить". - Представим, что запущена реклама с коммуникацей про скидку.
- Предусмотрели ли мы состояние карточки под это? Заложили ли состояние, когда на фотках появляется бейдж с жирным скидоном? Можем ли этим гибко управлять? Или каждый раз делаем релиз под очередную акцию?

Понимание полного контекста пользователя коммуникациидают крепкое решение на выходе.

Рекомендации

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

Увидел рекламу - считал сообщение/решение задачи - пришел с сообщением в интерфейс - решил задачу.

Практика

В своей работе мы часто используем сценарии пользователей. Вот реклама с такой коммуникацией, вот пользователь переходит на карточку товара, вот жмет кнопку "Купить". На первом этапе можно хоть из квадратов собрать, а потом уже дизайн под это рисовать.

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

Итого

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

О таланте

О таланте

О таланте. Таланте и стае. Знаю полсотни талантливых ребят, тех кому дано природой, космосом, родителями, средой, умение видеть в своем деле больше и глубже других. Все — сложные. Но видел я и как сложно бывает таким людям попадать в среду людей и задач не обремененных сложностью. Талантливый всегда в сомнении, в понимании промежуточности любого успеха и жестоком давлении на самого себя.

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

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

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

А пока я хочу обратить твоё внимание на парадокс

А пока я хочу обратить твоё внимание на парадокс

1. Ты часто делаешь работу не к сроку, я бы сказал систематически (ровно так же, как это делают 100% известных мне творческих специалистов).

2. Но всякий раз считаешь это случайностью и объясняешь внешними причинами.

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

Я читал об этом в книге Канемана.

Если коротко: «обычный» человек переоценивает потери и недооценивает выигрыш. Если «обычному человеку» предложить сыграть в игру с подбрасыванием монетки, где «орёл это получить 1200₽, а решка это отдать своих 1000₽», он не согласится, хотя математическое ожидание — положительное. Это «страх потери», который добавляет негативному сценарию дополнительный вес. У «обычного человека» равновесие достигается примерно в точке «выиграть 1500₽ или проиграть 1000₽».

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

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

Как же быть?

Понимать, с кем имеешь дело.

— Если имеешь дело с такими же предпринимателими, творцами и специалистами по неопределённости, то расслабиться, принять своё «несовершенство», делить с ними ответственность, давать больше обещаний про процесс и меньше про результат.

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

UX

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

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

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

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

⁃определиться с парадигмой навигации (гамбургер меню, либо таббар);
⁃найти основную работу на которую пользователи нанимают наше приложение, воспользовавшись фреймворком JTBD;
⁃составить карту экранов;
⁃составить информационную архитектуру;
⁃нарисовать вайрфреймы экранов и собрать из них прототип;
⁃протестировать прототип;
⁃подготовить отчет по тестированию и внести правки.

После чего, в идеале, с протестированным прототипом и вайрфреймами мы должны перейти к блоку UI и начать поиск своего визуального языка…
___________

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

Проблема в том, что главный ограничитель наших требований — мы сами. Довольно сложно не уйти в частности и вовремя остановиться, расставив ограничения самим себе.

Например, в нашем приложении есть карточка заказа — как, без реальных бизнес метрик, определить какая информация важна, а какая нет? Нужен просто адрес или подробная карта? Как подать информацию об авторе объявления? Что из этого важнее и должно располагаться выше?

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

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

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

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

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

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

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