Мы учили продукт, продукт учил нас

Хорошо, когда ты пишешь с рождения продукта и можешь придумывать всё с нуля. Но чаще будет не так. Будут продукты, в которых кто-то уже годами писал до твоего прихода. Будет наследие, с которым придётся что-то делать. И если дать слабину, наследие победит. Чем больше продукт, тем сильнее его влияние.

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

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

Подсчёт потоков

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

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

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

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

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

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

HTML-разметка — это просто текст, который делит страницу на смысловые (и не очень) блоки

Когда браузер получает HTML-документ, он на его основе создаёт древовидную структуру блоков, вложенных друг в друга. Каждый объект при этом называется узлом.

Потом к узлам применяются CSS-стили и получается та страница, которую мы видим в браузере.

К любому из узлов можно обратиться через JS как к объекту, чтобы узнать и изменить их свойства или содержимое, создать новые узлы или удалить старые. Структура этих объектов и называется DOM — Document Object Model. Она нужна для того, чтобы вы могли динамически менять содержимое документа после его загрузки в браузер.

Подробнее в видео: https://youtu.be/TKxR2tNxTcA
И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO

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

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

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

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

Пример

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

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

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

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

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

Практика

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

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

Итого

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

Культ своего бизнеса

Сейчас со всех экранов льется: «не работай на дядю», «работай на себя», «будь независим». Этими идеями пропитано все вокруг. 

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

Нищих и грустных фаундеров не меньше, чем румяных и счастливых наемников. 

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

Так называемая свобода хранится в голове, а не в правовой форме организации работы. 

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

Перефраз в интерфейсе

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

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

Это простой дидактический приём, которым можно пользоваться и для микротекста. Например:

Выбор категории
Выберите категорию расхода

Выбор категории
Какого типа был расход?

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

Повторять другими словами полезно, но лучше без фанатизма.