Как Сиракьюса переезжал на Айфон 18 Про В последнем выпуске АТП Джон Сиракьюса жалуется на то, как переезжал на Айфон 18 Про. Это в начале, где-то на восьмой минуте уже: https://atp.fm/710 Проблема в том, что процесс переезда с телефона на телефон предельно хрупкий. На телефоны нельзя дышать, и малейшая неаккуратность приводит к тому, что весь многочасовой процесс отменяется. После этого новый телефон нужно сбрасывать до заводского состояния и начинать всё с начала. Джон уже жаловался на этот процесс в прошлом или позапрошлом году. Тогда Джону удалось завершить переезд с третьего или четвёртого раза. Одна из «ошибок» была такой. Новый телефон предложил настроить Сири, и в ходе этого процесса надо было произнести «Hey, Siri». Джон так и поступил. Старый телефон среагировал и перешёл в режим Сири, что отменило весь процесс. Такую ошибку проектирования можно допустить только если буквально ни разу не попробовать воспользоваться этой фичей. Как устроен процесс тестирования у Эпла остаётся только гадать. В этом году ситуация не стала лучше, но у Джона-то опыт. Поэтому можно было бы предположить, что в этот раз всё получится. Но нет: он снова переехал с четвёртого раза. Вот одна из «ошибок»: Джону нужно было воткнуть в телефон зарядник, и он случайно нажал на кнопку камеры. А вот другая. Сначала оба телефона что-то напряжённо делали, а потом на старом загорелась надпись «Finish on the new iPhone» в шторке с крестиком. Джон, разумеется, воспринял это так, что всё, от этого телефона ничего больше не нужно, дальше уже новый сам что-то доделывает. Как только он закрыл шторку, весь процесс снова отменился. Я не представляю, как это может с первого раза пройти обычный пользователь, если даже Джон запинается несколько раз. И это ведь не какая-то экзотическая ситуация, а самая обычная, причём на пути получения первого впечатления! Что происходит в Эпле, что они это выпускают? Отдельно хочу обратить внимание проектировщиков на значение текста в интерфейсе. В последнем случае всё сломала именно неудачная формулировка. В некоторых компаниях бывает, что дизайнеры дизайнят как-то приблизительно, без текста, а текст пишут какие-то текстовые люди потом отдельно. Это очевидный бред: что это за дизайнер, если он не умеет писать текст? Это же главный инструмент ясной мысли. Если человек не может написать текст, как он может что-то задизайнить? И что за дизайн без текста? Это же главный инструмент коммуникации. Если вы дизайнер и не считаете текст предметом своей работы, стоит задуматься.

Как проектировать продукты для мышления Самая частая причина провала продуктов для запоминания/обучения чему-либо не плохой движок/интерфейс, а то, что пользователь продакт не смог ответить, ЗАЧЕМ именно ЭТО нужно помнить. Решить, ЧТО достойно быть запомненным – вот главная работа, которая а) не автоматизируется; б) не решается никаким механизмом удержания и вовлечения и она первичнее того, как это запоминать. Правильный продукт для мышления открывает мысли, которые без него не могли бы случиться, поэтому правильный вопрос такого любого продукта не «что должен делать продукт», а «какие мысли он позволит подумать». Забавная игра слов и смыслов в пятницу, ага. Модель продукта для мышления ≠ Продукт Модель продукта, в которой развитие мышления строится на интервальном повторении крива и нестабильна, потому что интервальное повторение всего лишь один один из десятков механизмов для развития мышления. Строишь продукт вокруг одной модели и он станет её потолком и блоком. 10 механизмов удержания в памяти: множественность форм одного вопроса, атомарность вопроса, dual-coding (текст+образ), вариации контекста, обогащение связей, сторителлинг смысла(ов), чанкинг (укрупнение единиц восприятия), калибровка внимания. 10 механизмов мышления как такового: расконцентрация/уединение, задержка первого ответа, наблюдение ощущений до, петля инсайт↔создание, сеть связей, а не изолированные факты, смена уровня абстракций, воплощение абстракции в предмет, поиск контрпримеров и опровержений, эмоциональная включённость, вопрос без заранее заданной цели. Проектируй Сети, а не точки Единица ценности – в Сети ты знаешь сам чего Структура связей делает забывание сложным. 1) Давай знание минимум в двух кодах одновременно. Текст + образ вспоминается устойчивее вместе с параллельным каналом кодирования той же единицы смысла. Экспериментируй с ними. 2) Варьируй контекст(ы), а не только содержание. Одно и то же место, время, фон снижает удержание на 40% относительно вариативного контекста. Продукт, который всегда выглядит и ощущается одинаково при повторном касании, недоиспользует потенциал памяти сам по себе. Вариативность интерфейса это новый механизм. Плотность чанков важнее объёма знаний, а значит, что продукт должен ускорять именно сборку чанков у пользователя через укрупнение единиц восприятия форм. Чанки – это небольшие квадратные участки, на которые игры (например, Minecraft) делят свои большие миры для экономии памяти и быстрой прорисовки 🍌Но и здесь скрыта очередная ловушка мозга: так, пользователь обучается узнавать форму вопроса раньше, чем осмыслять его, и начинает отвечать на паттерн, а не на суть. Поэтому снова упаковывай один и тот же смысл, но в 2+ разных формы, иначе ты тренируешь узнавание интерфейса, а не мышление. Эмоция – несущая конструкция в продуктах, а эмоциональная связь пользователя с материалом первичней материала как объекта. Великая цель-петля таких продуктов – изменение знаний всего человечества, которое возвращается и меняет тебя, твой продукт и мир. Они рождаются только тогда, когда их создатель решает свою собственную реальную задачу и делится этим процессом с окружающими миром через свой продукт. Они растут только вместе с пользователем, расширяющееся понимание и мышление которого должно менять как пользователя, так и сам продукт, порождая у обоих новое понимание предмета мышления. Всё есть петля, пространство, круг и цикл. Ты начнёшь строишь благо, не осознавая это.

Сегодня поделюсь одной простой идеей для e-com, которую я пока почему-то нигде не встречал Замечали, что почти во всех iOS-аппах при вводе адреса такие поля, как квартира, подъезд, этаж и домофон, по умолчанию открывают обычную буквенную клавиатуру? Логика понятна: разработчики перестраховываются, ведь изредка адрес содержит буквы (например, квартира И-214). Но стандартный нумпад в iOS не даёт переключиться на буквы, поэтому всем нам открывают полноразмерную клавиатуру Проблема в том, что буквы в этих полях — редкое исключение. В итоге абсолютное большинство пользователей каждый раз вынуждены: 1⃣ Вручную тапать «123» для смены раскладки 2⃣ Набирать цифры на менее удобных мелких кнопках верхнего ряда Как это решить нативно и красиво? 1⃣ Оставляем нумпад по умолчанию, но даём быстрый свитч на буквы прямо над клавиатурой. Вешаем тулбар в inputAccessoryView: слева кнопка «Abc», по центру flexibleSpace, справа — «Готово». 2⃣ Ставим нумпад по дефолту: textField.keyboardType = .numberPad 3⃣ По тапу на «Abc» переключаем тип клавиатуры: textField.keyboardType = .default textField.reloadInputViews() В случае с тем же Ozon 😊 (драфт решения прикрепил) мы экономим пользователю до 4 лишних тапов при оформлении заказа (по одному переключению на квартиру, подъезд, этаж и домофон) и делаем сам ввод удобнее Мобильные разработчики, вопрос к вам: почему так до сих пор массово не делают? В чём подвох или дело просто в приоритетах бэклога? 👇🏻

Об уважении к клиенту Одна из утилит, которой часто пользуюсь – скриншотер. Нажал горячую клавишу, выделил часть экрана, где какая-то фигня случилась, подрисовал стрелочку к проблемному элементу и пару слов комментария, отправил разработчику. Полезно, удобно. Нужно не только мне. Существует целый класс продуктов с такой функцией. Предыдущий выбор мне надоел, я пошел искать новый. Узнал, что на моем компьютере он уже есть: Microsoft с 2002 года разрабатывает и держит в составе Windows ровно такую программулину – #стартапдня Snipping Tool. И это не что-то заброшенное, команда там работает, буквально прошлой осенью вышло большое обновление. Тем не менее, приложение плохое. К интерфейсу можно привыкнуть, дело вкуса. И с отсутствием выбора горячей клавиши можно смириться. Стив Джобс и Генри Форд стиль: цвет может быть любой, если он черный. Но, блин, Snipping Tool не позволяет сам подпись на картинке нарисовать – предлагает в Paint, полноценный редактор, для этого переключиться. И даже в Paint стрелки только горизонтальные и вертикальные, произвольных нет. Я могу объяснить, почему для корпорации скриншотилка – стотысячный приоритет. Я могу понять, что начальство у продакта и сам продакт сидят на Mac, и в жизни никогда не сталкиваются со своей поделкой. Но принять такое отношение к миллиарду [реально миллиарду!] пользователей я не могу. Эх. #корпоративный

Замкнутость интерфейса Замкнутость интерфейса — это полнота и непротиворечивость правил, определяющих его состояния и переходы между ними при всех допустимых сочетаниях данных, условий и событий. Для любого допустимого сочетания данных и условий ясно, как выглядит и ведёт себя интерфейс. Например, список может быть пустым, содержать одно значение или тысячу, и мы понимаем, как они выглядят. Это состояния. В каждом состоянии определён перечень допустимых событий, включая действия пользователя, которые влияют на интерфейс, например, значения можно добавлять и удалять, и нам тоже ясно, как это всё работает. Это переходы. Самое интересное и сложное — это то, что переход должен полностью определяться состоянием и событием. Он не может зависеть от истории предыдущих состояний (если только это не буквально переход по истории состояний типа «Назад» или «Анду»). Если переход из некоторого состояния S при событии E зависит от того, попали мы в S из Q или R, то это значит, что нет никакого состояния S, а есть состояния S1 (S после Q) и S2 (S после R), и важно это осознать. Может показаться, что это какая-то заумь и вообще, какая разница. Но если не обращать внимания на это, то в интерфейсе возникают неявные состояния, в которых вид и переходы не определены. Дизайнер-то думает, что рассмотрел состояние S, да вот только это мифическое состояние, а настоящие состояния S1 и S2 он не рассмотрел. При проектировании сложного интерфейса иногда непреднамеренно возникают состояния, из которых невозможно выбраться, или до которых невозможно добраться, или до которых можно добраться только, если сразу пойти по правильному пути. Для дизайнера важно научиться видеть это. Часто бывает, что я спрашиваю, например, «А в этом случае что будет?», и дизайнер только в этот момент понимает, что такой случай вообще существует. Внимательно разбираться с замкнутостью — кропотливая работа. Обычно мы рассматривает разные состояния и переходы в контексте некоторого флоу, то есть пути пользователя. Мы рисуем экраны друг за другом и представляем, как человек проходит между ними. Нам кажется логичным, что после такого-то экрана при таком-то действии появляется сякой-то, и мы не замечаем, что в другом флоу на таком же экране при таком же действии появляется другой экран. Когда мы думаем про этот флоу и смотрим на это глазами пользователя, мы почти всегда думаем о любом состоянии в контексте предыдущих состояний, и не отдаём себе в этом отчёт. В моём примере с автодополнением отдельные решения сначала кажутся нормальным, пока не начинаешь смотреть, какие запутанные состояния и переходы они порождают. Исправление каждой возникающей неприятности создаёт исключение, усложняя систему и добавляя неприятностей: https://ilyabirman.ru/meanwhile/all/ui-completeness-example/ Я приводил примеры вопросов, которые помогают проверить интерфейс, но понятно, что ответы даже на все вопросы сами по себе не гарантируют замкнутость: https://ilyabirman.ru/meanwhile/all/completeness-questions/ О замкнутости следует думать как о математическом качестве. Возьмём такую теорему: «Число 60 делится на все числа». Это легко проверить: на 1 делится, на 2 делится, на 3 делится, на 4 делится. Мне продолжать? Ну на 5 делится, на 6 делится, сколько ещё примеров надо? Какое число ни возьми — на всё делится: 10, 15, 20... Так ведь? Но нет, это ничего не доказывает. Чтобы доказать теорему, нужно искать не удачные примеры в большом количестве, а саму фундаментальную причину, по которой она неизбежно верна. В данном случае такой причины нет. При проектировании интерфейса сложно требовать от дизайнеров рисования полного графа состояний и переходов. Не уверен, что делал такое хоть раз в жизни. Но всё же полезно хотя бы понять, что это такое. Полезен и опыт программирования — оно развивает интуицию на такие вещи. Смотришь на проект интерфейса, и чутьё подсказывает: что-то не то, сейчас найду дыры. И дыры находятся. Вообще, чем больше для описания интерфейса приходится придумывать частных исключений, тем больше возникает подозрений в том, что общее правило плохое или вообще не придумано.

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

Список как способ организации интерфейса Совет о списке как элементе графического интерфейса хочется дополнить ещё другим списком, который можно также назвать вертикальным стеком или даже бутербродом, хотя этот термин скорее из мира вёрстки: https://bureau.ru/soviet/20141020/ Или как бы вы это назвали? Поток?.. Давайте придумаем термин! Список — способ вёрстки графического интерфейса, когда элементы располагают друг за другом сверху вниз. Структура задаётся делением на секции с помощью отступов, разделителей, плашек, залипающих заголовков. На этих примерах с Айфона друг за другом идут тумблеры, элементы навигации, кнопки, заголовки и просто блоки текста.

Продуктовые наблюдения: почему скидки могут пугать Хочу поделиться своим опытом похода вчера вечером в КуулКлевер. Заходил по пути домой взять фруктов (кстати, они дешевле, чем в других магазинах у меня на районе). Набрал три пакета, понимаю, что надо взвесить их самостоятельно. Подхожу к весам, кладу товар, жду интерфейс с огромным каталогом из 500 похожих позиций. Нет, весы сами определили, что именно я положил, и предложили выбрать товар. Для меня это было прямо что-то новенькое. Не потому, что это какая-то космическая технология. А потому, что мне не пришлось гадать как именно записан/выглядит мой товар в их каталоге. Система просто сняла с меня маленькое, но раздражающее действие. Взвесил три пакетика, подошел к кассе. В Кууклевер, кто не знает, используется система с бейджем: прикладываешь его к кассе, и покупки подтягиваются автоматически. Можно отсканить куар код из приложения, что я и сделал, тогда он авторизует твой личный кабинет. Отсканировал фрукты. Перехожу на чекаут, смотрю система предлагает списать 4К КеГлей и оплатить ими заказ - сумма покупки 300 рублей. Я такой, вау, Беру! Оплатил, вышел из магазина и подумал, а я точно сейчас выиграл? Или только что обменял 4 000 каких-то виртуальных единиц на 300 рублей? Не сильно ли это много за 300 рублей? И дело тут не в скидке! КеГЛи - это бонусная валюта программы лояльности КуулКлевер. Их можно копить за покупки и использовать для оплаты продуктов и напитков. При этом сам магазин отдельно подчёркивает: КеГЛи не имеют фиксированного курса к рублю, а стоимость товара в КеГЛях указана на ценнике или в карточке продукта. То есть формально всё работает как задумано. Но пользовательский вопрос всё равно возникает:

Почему 4 000 баллов вдруг превратились в покупку на 300 рублей?

Скидка может быть очень выгодной, но при этом вызывать недоверие. Давайте разбираться: Почему чрезмерная выгода пугает Если у вас накопились баллы/выгоды и вы их обмениваете на небольшую скидку, то все хорошо, но когда вы можете оплатить всю покупку и если механизмы обмена не обозначены и не понятны - возникает недоверие. В какой-то момент большая скидка перестаёт восприниматься как подарок и начинает восприниматься как ошибка в системе/подвох/обман. Вывод из наблюдений Если вы проектируете продукт и хотите поощрить пользователя скидкой, через баллы / возможности, то вам нужно добиться прозрачности, объяснять за что начисляете, как пользователь управляет и как он должен вовлекаться в накопление и использование этих баллов. поделитесь, вашим опытом взаимодействия с ритейлом, что стоит подсмотреть как мехники для продуктов ? @blackproduct

Мои новые друзья на первом экране. Часть 2 Продолжаю рассказывать о тяжёлой жизни продакта на Филиппинах 😉 До этого писал про приложения GCash, Grab и Foodpanda. Вот ещё три приложения из новеньких, но уже занявших своё место на моем айфоне. 📌 Bistro BFF. Экономия на вкусной еде Клубное приложение от сети ресторанов The Bistro Group — цифровая скидочная карта, которая позволяет применить купоны на скидку в оффлайн ресторанах. Так как это крупнейшая сеть в стране, выбор очень большой. А получить минус 20% от счета за вкусный ужин всегда приятно! Своё приложение для доставки они почему-то сделали доступным только в филиппинском сторе, пользуюсь иногда веб-версией. Это, кажется, первый раз, когда я создал иконку сайта на экране айфона. Оказалось что удобно. Частота: несколько раз в месяц Мой рейтинг: ⭐️⭐️⭐️⭐️⭐️ 📌 Lazada. Каким не должен быть маркетплейс Самый негативный опыт с задачей «хочу этот робот пылесос, возьмите мои деньги» у меня был с Lazada. Все способы оплаты, которые доступны для меня чужака, не сработали при заказе на относительно большую сумму (25000 пессо). Поддержка не помогла. Дополните это регулярными попапами на весь экран в процессе оформления заказа, ошибками формы оформления корзины, навязчивым добавлением страховки и классическим азиатским интерфейсом. Получается хороший пример как не надо делать маркетплейс. Частота: один раз и больше не хочу Мой рейтинг: ⭐️ 📌 JoyRide. Такси с ветерком Если я налегке, то доехать быстро и с ветерком можно на мототакси от JoyRide. Само приложение выглядит отлично и заметно меняется со временем. Появился заказ машины, аренда авто, трансферы из аэропорта. Обычно мне попадаются очень дружелюбные и разговорчивые водители. Провел несколько интервью о покупке и продаже мотоциклов в процессе таких поездок. Шлем для пассажира и специальная одноразовая шапочка идут в комплекте. А как-то наблюдал за посадкой пассажира на мототакси когда на улице шел сильный дождь. Водитель просто одел его целиком в непромокаемый костюм и они помчались куда-то сквозь потоки воды 🙂 Частота: редко Мой рейтинг: ⭐️⭐️⭐️⭐️ #philippines

**Главный сценарий использования ИИ — не код и не письма. Это терапия** Свежее исследование HBR (12 637 реальных сценариев) выдало цифру, которая ломает традиционные представления о продуктах. Топ-1 кейс применения генеративного ИИ - это эмоциональная поддержка, терапия и компаньонство. На это приходится 11% всех запросов, и показатель вырос вдвое за последний год. Прикольно, что. Пока все строят ИИ как швейцарский нож для продуктивности, пользователи сами достраивают его до собеседника. Выигрывают те продукты, где честно признают эмоциональную работу и проектируют UX под нее. А вы знаете, на какую эмоциональную работу нанимают ваш продукт? Источник: https://hbr.org/2026/06/how-people-are-really-using-ai-in-2026 @productgames

AI не просто ускоряет разработку. Он меняет саму работу продакта Сегодня посмотрел доклад Андрея Попова про AI-продуктивность в Яндексе. Зашел он тем, что был не разговор в сотый раз о том, как «нейросети помогают писать код», а то, как вместе с AI меняется сама организация работы. «Нам нужно двигаться из DX в AgentX. То есть в первую очередь смотреть, как мы автоматизируем, как мы упрощаем жизнь для агентов, а потом уже жизнь для людей». Это важный сдвиг и для продактов. Сегодня мы проектируем продукт под человека: интерфейсы, кнопки, сценарии, навигацию. Но если часть работы начинает выполнять агент, ему нужны уже не красивые экраны, а доступ к данным, API, понятные действия, права, контекст и возможность самостоятельно пройти сценарий. Поэтому к UX постепенно добавляется AX — Agent Experience. Например, вместо «открой аналитику → найди сегмент → сравни показатели» можно будет поставить агенту задачу: «найди причину падения конверсии и подготовь гипотезы». Продукту придётся быть готовым именно к такому взаимодействию. В компании, по словам спикера, уже около 60% инженеров фактически перестали писать код руками, а активные пользователи AI получают кратный прирост продуктивности — в отдельных измерениях 3–5 раз и больше. При этом к концу 2026 года Яндекс планирует, что не менее 75% разработчиков будут регулярно использовать AI, он будет участвовать как минимум в 75% изменений, а в каждом из них генерировать не менее 75% кода. Но самое интересное здесь не в экономии времени. Если код становится условным «новым ассемблером», то ценность человека смещается выше: декомпозировать задачу, разобраться в новом контексте, поставить правильные ограничения, проверить результат и понять, решает ли он продуктовую задачу. То есть именно туда, где продакт работает каждый день. Есть ещё более показательная цифра: 30–40% кодовых задач — это рутина, а около 70% такой рутины, по оценке компании, потенциально можно полностью автоматизировать. Это означает, что AI постепенно убирает не только отдельные операции, но и целые куски workflow. И здесь продактам стоит перестать спрашивать «какую нашу задачу можно отдать AI?» и начать спрашивать «какой процесс меньше всего требует включения человека». Это уже другой уровень автоматизации. А дальше возникает интересный переход: человек задаёт требования → агент решает задачу целиком → система проверяет результат → следующий агент улучшает процесс. В такой модели продакт становится не просто заказчиком фичей, а проектировщиком системы, которая сама умеет исследовать, анализировать, создавать и проверять решения. Поэтому один из главных навыков продакта в ближайшие годы — не prompt engineering, а умение хорошо формализовать проблему и критерий успеха, после чего делегировать исполнение агентам. И здесь, пожалуй, главный вывод из доклада: AI будет сильнее всего усиливать не тех, кто быстрее всех научится пользоваться конкретным инструментом, а тех, у кого хорошо устроена сама работа. Если процесс хаотичный, данные недоступны, метрики не определены, задачи плохо декомпозированы — AI просто масштабирует хаос. Поэтому для продакта сейчас важнее не добавить ещё один AI-инструмент в свой стек, а пересобрать собственный workflow: что я делаю сам, что делегирую агенту, что должен проверять лично и какие решения вообще не должны проходить через меня.

Проектирование витрин и карточек Одна из задач, которую нужно решать почти любому продакту и его команде - проектирование витрины товаров или услуг. Если у вас больше 1 варианта для пользователя, вам нужно это как-то показать и дать критерии выбора. Вот мне предстоит в рамках нового направления увеличения выручки с Self Service в компании - изменить как внешний, так и внутренний путь пользователя. Какими правилами я руководствуюсь: 1. social proof: бейджи вроде «Хит», «Топ вариант», «Более 10 000 купили» или «Часто покупают вместе». Простое и понятное 2. Сигналы выгоды и срочности: «−30%», «Акция до конца дня», «Осталось 3 шт.», «Бесплатная доставка от X». При этом важно, чтобы скидки и акционные лейблы были честными и валидными - фейковые «распродажи» быстро размывают доверие и начинают восприниматься как шум. 3. Прозрачность ключевых условий прямо в карточке: сроки и стоимость, возможность возврата, гарантия, основные характеристики (размер, совместимость, комплектация). Отсюда вывод - если вы сами не понимаете, ваши тарифы - то как сможет клиент? У нас в компании больше 100 вариаций тарифов, одна из задач совместно с коммерцией пересмотреть все и сделать 3 тарифа. (Наверное, самая полезная часть этой задачи) Можно придумать еще достаточно много законов и правил для навигации - например, закон Фиттса, но об этом лучше вот тут На что вы обращаете внимание ? делитесь в комментариях и ставьте ваши лайки👍 @blackproduct

Как это сейчас работает? Раз в квартал я делаю одну тупую, но очень полезную вещь. Удаляю свой продукт и прохожу путь как будто я новый юзер. Не "открыл админку и потыкал", а по-честному: – ловлю свой креатив в ленте – перехожу на посадку – онборжусь – сомневаюсь и закрываю – читаю дожимы – плачу своей картой – и дальше реально пользуюсь Каждый раз нахожу херню. Вообще каждый. То креатив обещает одно, а лендос рассказывает про другое. То кнопка оплаты уехала за экран на маленьком айфоне. То прогрев зовет успеть на скидку которая действует только 12 часов, а эти 12 часов случаются раз в сутки. То онбординг просит заполнить семь полей, из которых дальше используется одно. Почему никто этого не видит? Потому что вся команда живет внутри продукта. У всех флаг админа и тестовая карта, триал проходили раз видели в день релиза. А новый пользователь видит только этот путь, и в этом пути спрятан весь твой рост.

«Я всегда не любил Duolingo всей душой. Но когда в моём приложении оказалось 70% новичков, то кое‑что сделал так же» Автор строил VibeLing вокруг одной идеи. Пользователь встречает слова в фильмах и статьях, сам решает, что учить, и собирает личный словарь. Duolingo раздражал именно тем, что ведёт по готовой дорожке и всё решает за пользователя. Взрослому человеку можно дать нормальный инструмент, а дальше он сам разберётся, что учить. Так это выглядело, пока в аналитику не пришли реальные цифры. Около 70% аудитории оказались новичками уровня A1. Такой пользователь ещё не смотрит фильмы на английском и не читает статьи без перевода, потока контента для собственного словаря у него просто нет. Даже пустая строка поиска работает против него. Продвинутый открывает её с готовым словом, а новичок должен сначала придумать, что искать. Оказалось, что всё это время приложение проектировалось под сценарий его создателя.

Возник еще вопрос, почему не подписать поле ввода внутри, а когда на него нажимаешь, подпись уезжает наверх. Действительно, почему? И место, вроде, сэкономим, и поле без подписи не оставим. Первая причина это нестабильность. Интерфейс переходит из одного состояния в другое, потому что может. Как собачка из анекдота. Представьте наполовину заполненную форму. У первой половины полей подпись сверху, а значение внутри. У второй — подпись внутри. Как отличить? Один и тот же объект (текст), одинаково расположенный (внутри), одинаково выглядящий, но в одном случае это подпись, а в другом — значение. Опять надо какие-то улики по всему интерфейсу собирать и до чего-то догадываться. Я НЕ ХОЧУ ДОГАДЫВАТЬСЯ. Очевидность — добро! Должно быть — смотришь на страницу — сразу все понятно, что, где, куда и чего от тебя хотят. Как удар поленом по голове. А не вот эта вот работа следователя. Тут серый на 5% бледнее, значит... А вторая причина попроще. Мне в принципе не нравится, что в поле, куда тебя просят что-то написать, уже что-то написано. Сама концепция странная. Представьте, заходите в бар, а там все стулья заняты. Ну или вам так кажется. Оказывается, они все свободны, нужно только подойти к нужному, человек встанет и сразу уступит вам место. Он его для вас караулил, оказывается. Вот так и с полями ввода. Если вы хотите, чтобы я что-то куда-то ввел, ну так и покажите мне всем своим видом, что вы к этому готовы. Что там место для меня есть. А то опять догадываться надо, что когда я начну писать, что-то там куда-то удете и освободится. А Я НЕ ХОЧУ ДОГАДЫВАТЬСЯ! И про экономию места. Смотрите, если у вас подпись уезжает наверх, значит место под нее там уже зарезервировано. Значит можно сразу туда ее поставить и форма никак в размере не разрастется. Так что, текстовые поля, у которых подпись уезжает наверх, это верх тупости. Ну а что еще вы ожидали от дизайна, придуманного в Гугле?