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

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

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

Но это слишком очевидно и правильно, поэтому так никто не делает.

Главный враг раздолбайства — план.

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

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

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

Может показаться, что прототипировать — это вроде как не очень нужно. Херак-херак — и в продакшн. На самом деле, это чертовски важно в любом процессе; например, по заветам юзабелистов — это 70% работы. Вопрос только в том, как это можно делать.

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

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

Он сделал игру «Космические дальнобойщики», второй тираж которой почти не доехал до магазинов – разобрали на предзаказах. Третий тираж ждала вся Европа – я помню, в Праге продавец в магазине назвал мне точное количество дней до поставки. Они там считали каждый час и вели тетрадку учёта предзаказов. Толстую.

Этой игрой Влаада добавил новый атом в список механик настолок (что случается раз в пару лет) – механики реального времени для походовых игр. Так вот, я поговорил с ним о разработке, в особенности – о том, какие грабли были при переносе его игры в приложение.

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

Привет!

Я обещал рассказать эту историю, и я рассказываю.

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

^{В ситуации полной и беспросветной задницы власть в AI сразу забирали военные, и это иногда спасало партию.}

Для нашего AI Шакала пришлось написать целых 4 разных AI, каждый из которых отвечал за свою задачу. А затем они собирались вместе и голосовали за то, что же делать пиратам на поле в этом ходу.

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

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

Алгоритмизировать процесс гости так и не смогли. Так вот, разработка шла так: мы чертили дуги и хитро улыбались, а парни проигрывали нам в настольный Шакал. И мечтали, что за них отомстит AI.

В 1940-е вам нужна была специальная бабка, которая считает людей на входе в магазин. В 1950-е верхом прогресса была камера, плёнку с которой потом можно было анализировать. В конце 80-х в США и Европе (в т.ч. Германии) начали распространяться инфракрасные датчики или просто счётчики открывания-закрывания дверей на герконах. Сейчас технологии медленно дрейфуют к тому, чтобы засекать ваши широковещательные пакеты Wi-Fi и Bluetooth (рассылку поиска сетей), чтобы отслеживать перемещения телефона с точностью до 3 сантиметров. Плюс растёт значение распознавания потоков людей с видеосистем.

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


^{Самая простая реализация после геркона — пересечение ИК-луча}

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

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

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

Самый простой способ – задавать порядок вручную. В физических магазинах на полках делается именно так, и это называется «выкладка». У нас её делают продавцы по планограммам под каждую точку (это входит в обучение), а в тех же больших продуктовых – специальные чуваки-мерчендайзеры, которые следят, чтобы всё было ок. В Интернете, конечно, хочется сделать так же, но метод хорош до 50 позиций.

На другой стороне шкалы методы больших данных, когда все данные о вас начиная от сборки браузера, типа девайса (точнее, его цены) и разрешения экрана, плюс все данные профиля и оценка ваших действий на сайте ведут к оптимальному результату. Самый простой способ использования таких данных – за первые 20-30 секунд нахождения на сайте строить ваш профиль и сравнивать с профилями таких же людей. И предлагать вам в итоге не самые дешёвые квартиры и отели, например, а начинать с тех цен, которые для вас будут приемлемыми. Вы наверняка знаете эту сортировку, которую почему-то подают в прессе под соусом «самой удобной для клиента».

По моим ощущениям, самая удобная для нашего покупателя – это такая, которая понятна и поддаётся контролю.

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

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

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

• Интересной.
• С простым порогом входа.
• Реалистичной для задач погружения.

Ясное дело, создатели немного намухлевали — но это становится заметно только после детального разбора. Ясно, что логика сеттинга иногда спорит с механикой и геймплеем. Ясно, что недостатков куча, но всё в целом — очень крутое. Поэтому поехали докапываться до мелочей.

Внимание, ниже немного спойлеров и много скриншотов (трафик).

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



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

Нет, нифига, китайский UX подразумевает, что я сначала введу телефон и нажму оранжевую кнопку (цвета иконки — и да, это кнопка!). Получу пароль и введу его во второе поле, а потом нажму зелёную кнопку. Робот сравнит телефон с паролем и пустит меня дальше. Эту форму, скорее всего, рисовал китаец.


^{А это обычная такая телефонная будка раннего космического века}

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

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

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

И вообще вели себя вызывающе с точки зрения ИТ.

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

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

Вот, например, продавцы поняли, что не все выездные админы одинаково полезны. Старшие точек умеют чудовищно быстро меняться нужной информацией. Поэтому теперь на разные случаи просят разных инженеров. Стоит кому-то сделать работу хотя бы на 10% быстрее обычного или ещё как-то показать качество – и сразу же начнутся звонки в духе:
— Привет. Поддержка?
— Добрый день.
— А кто сегодня выездной?
— Миша.
— Ааааа… А Валера когда?
— Валера завтра до 15. Так что у вас сломалось-то?
— Да не, не, всё в порядке. Сегодня всё хорошо. Завтра сломается. В 11:30.

Почты вида noreply@domain.ru, no-reply@domain.ru и прочие — вызов здравому смыслу. Просто вдумайтесь: это действующие почтовые ящики, на которые можно отправить письмо, но делать этого не нужно. Я знаю такой же по логичности объект – это кнопка «не нажимать». Вот примерно такая:



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

Классические компьютерные игры начались ещё, собственно, до появления компьютеров в виде интерактивных книг. Скорее всего, в детстве у вас была одна такая либо Браславского, либо вообще из цикла про Стальную Крысу Гаррисона.



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

Базовый сюжет строился в виде системы узлов и переходов. За один проход вы задействовали примерно 25-35% страниц книги.



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

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

Механика базы работает чертовски просто:

1. В игре создаётся некое место, где игроку приятно и безопасно проводить время.
2. После периода напряжения игрок отправляется в это место.
3. Закончить в этот момент сложно. Кто будет отказываться от приятного «отдыха»? Нет, из игры не выходят перед приятной частью.
4. Далее мы стараемся без перехода выводить игрока в следующий цикл, требующий напряжения – так, чтобы игрок не успел понять, как там оказался.

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

Привет!

Вот пост с квестом, а вот сам архив с ним. Ниже – сюжет квеста (задачи по уровням) и ответы под спойлерами.

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

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

Привет!
Я сварганил на день сисадмина zip-квест. Вот здесь забирайте архив, и вперёд.

Что надо знать:

• Вы играете за космического админа, впервые ушедшего за пределы орбиты Земли. Он – это вы, только меньше и другой.
• Каждый уровень – это подархив, пароль от него можно достать, пользуясь информацией с предыдущих уровней.
• Поскольку у нас русский космос, пароли могут содержать русские символы, куски кода даже с комментариями, всякий треш и быть регистрозависимыми.

Вы когда-нибудь думали, что бывают игры, которые сами по себе являются языком программирования? Не обязательно Тьюринг-полным, но всё же языком. У меня есть отличный пример. Игровой процесс Нейрошимы-6 чудовищно похож на дебаг. Снаружи, конечно, смотрится как стратегия, но внутри – она, отладка, родная.

Посмотрите вот на эту картинку из жизни бойцов Пустошей.



Фишки с 20/20 – это командные центры, оставшиеся две — это фишки бойцов с ближней атакой по направлению треугольников по краям. Пока всё просто – синий робот с ножами бьёт желтого ковбоя, а ковбой бьёт по синему комцентру. Давайте усложним стек и запустим компиляцию.

Вот комикс «приключения одного пользователя в форме заказа»:



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

Привет! В посте блиц-обзор книг, которые будут полезны IT-специалистам, бизнесменам и тем, кто просто любит читать интересные технические вещи. Рядом с каждой – пояснения, чем оно может быть нужно. Этот обзор, в отличие от других ежегодных, более технически-прикладной.

Начнём со «Справочника по инженерной психологии» Вудсона и Коновера.

«Справочник по инженерной психологии» — Вудсон, Коновер

Книга о том, какие бывают кнопки и рычаги, как на них нажимают люди. И как проектировать так, чтобы люди работали с системой эффективно. Радует тем, что рассматривает пользователя как базовую систему ввода-вывода, замеряя его среднюю скорость передачи информации (около 20 бит в секунду на кнопочные интерфейсы), скорости ввода и вывода.

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

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

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