4.2. Проектная гипотеза мобильного приложения

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

Идея — начало разговора, а не его результат.

«Приложение для медитации» — идея; «приложение, которое с помощью тактильной обратной связи встраивает дыхательный ритм в городскую прогулку» — уже ближе к гипотезе. Разница — в степени проверяемости: первое можно только обсуждать, второе можно тестировать.

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

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

Проектная гипотеза — это краткое, проверяемое предположение о том, что:

1. Существует определённая задача, ситуация или напряжение — пользовательская, поведенческая, исследовательская или опытная.
2. Мобильное приложение является адекватной формой её решения или исследования.
3. Предложенный сценарий взаимодействия создаёт наблюдаемый эффект для пользователя.

Это определение зафиксировано в описании модуля. Давайте разберём его по частям.

Первая ошибка большинства студенческих проектов — гипотеза без субъекта и без напряжения. «Было бы здорово, если бы существовало приложение для…» — это не задача. Задача начинается с реальной ситуации: кому-то что-то мешает, чего-то не хватает, что-то работает плохо, что-то не осмыслено.

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

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

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

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

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

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

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

Для прикладных проектов эффект ближе к первым трём пунктам. Для исследовательских — к последним двум. Но в обоих случаях вы должны уметь сказать: «если моя гипотеза верна, я увижу вот это».

Формат: FigJam, индивидуально → групповое обсуждение. 15 минут.

Задание (7 минут):

Вот вам пять «идей», намеренно размытых:

1. Приложение для здорового сна.
2. Приложение для поиска интересных мест в городе.
3. Приложение для борьбы с прокрастинацией.
4. Приложение для изучения иностранных слов.
5. Приложение для заботы о комнатных растениях.

Выберите одну. Переформулируйте её в проектную гипотезу, заполнив три поля:

● Задача / напряжение: что конкретно не так? для кого? в какой ситуации?

● Почему телефон: какое свойство мобильного устройства делает его адекватной формой?

● Наблюдаемый эффект: что изменится, если гипотеза верна? как это увидеть?

Групповое обсуждение (8 минут):

Разбираю 2–3 особенно показательных переформулировки:

● одну, где задача слишком общая (и как сузить),

● одну, где мобильность хорошо обоснована,

● одну, где эффект конкретен и проверяем.

Что это проверяет:

Умеете ли вы превратить «было бы здорово» в конструкцию с тремя опорами?

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

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

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

Что здесь хорошего: задача конкретна (первые две недели, новый город), мобильность обоснована (геолокация + срочность), эффект наблюдаем (время поиска, отменённые записи).

Логика: существует явление, режим опыта или проблема восприятия, которые стоит исследовать или переорганизовать — и мобильное приложение может стать инструментом такого исследования.

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

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

В обоих случаях обязательны:

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

Различие — в акценте, а не в строгости. Исследовательский проект не означает «можно делать что хочешь». Он означает: «вы отвечаете на другой вопрос, но с той же дисциплиной».

Здесь нужно сказать важную вещь.

Figma-прототип сам по себе не является результатом вашего проекта.

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

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

Тестирование — это процедура, в которой ваш прототип сталкивается с реальностью. Не обязательно масштабная: это не релиз на рынок и не А/Б-тестирование с тысячей пользователей. Это может быть:

● пользовательский тест: человек проходит ключевой путь в вашем прототипе, вы наблюдаете и фиксируете; ● think-aloud-сессия: человек проговаривает вслух, что он видит, что понимает, где спотыкается; ● короткое интервью до и после взаимодействия с прототипом; ● дневник наблюдений: человек пользуется прототипом в контексте (или его имитации) и записывает, что замечает; ● сравнение версий: вы показываете два варианта сценария и фиксируете, где различие в реакции.

Для прикладного проекта тестирование отвечает на вопрос: понял ли пользователь ценность, прошёл ли ключевой путь, где споткнулся? Для исследовательского: переорганизовал ли интерфейс восприятие? Заметил ли человек то, чего раньше не замечал? Описывает ли опыт иначе?

В этом модуле единица успеха — не «готовое приложение» и не «почти MVP». У вас нет кода, нет инфраструктуры, нет реального распространения. И не надо притворяться, что это почти есть.

Единица успеха — проверенная гипотеза через прототип и пробу:

1. Гипотеза — что именно вы предполагаете.
2. Прототип — через что вы это проверяете.
3. Тестирование — как именно вы это проверяете.
4. Вывод — что вы поняли: что подтвердилось, что нет, что удивило.

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

Подробнее о том, как именно устроена проба, какие форматы проверки существуют и как оформить выводы, мы разберём на последнем занятии модуля — в лекции [[4.8. ИИ-пайплайн и презентация мобильного продукта|4.8]]. Сейчас достаточно запомнить формулу: гипотеза + прототип + проба + вывод = проект.

Формат: FigJam, работа в парах. 12 минут.

Задание:

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

1. «А почему не сайт?» — Если вы не можете за 30 секунд объяснить, зачем тут телефон, — мобильность не обоснована.
2. «А это не [название существующего приложения]?» — Если вашу гипотезу можно закрыть установкой чужого приложения, — задача не уникальна или сформулирована слишком широко.
3. «Как ты поймёшь, что это работает?» — Если ответ звучит как «ну, людям понравится» — эффект не наблюдаем.

После трёх ударов запишите рядом с карточкой:

● 🟢 прошла (все три ответа есть)

● 🟡 шатается (один ответ слабый — какой?)

● 🔴 не держится (нет ответа на два и более вопроса)

Что я буду разбирать:

2–3 карточки с разным статусом: что именно их ослабляет и как починить.

Что это проверяет:

Гипотеза — не декларация намерений. Она должна выдерживать простейшую критику.

Банальность — идея, которую не додумали.

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

Вот признаки того, что гипотеза банальна:

Вы можете описать её одним существительным: «трекер», «планировщик», «гид»; вы не знаете, чем она отличается от того, что уже есть в App Store; вы не можете назвать конкретную ситуацию, в которой она нужна; она звучит одинаково для любого пользователя в любом контексте.

Если ваша гипотеза звучит банально, попробуйте её углубить.

Поверхность: «Приложение для поиска кафе поблизости».

● Почему? — «Потому что человек хочет есть».

● Почему именно сейчас, именно здесь? — «Потому что он в незнакомом районе, голоден, мало времени».

● Почему существующие решения не работают? — «Google Maps показывает 80 результатов, но не учитывает, что он торопится, что ему нужно сесть на 10 минут, что он не ест острое».

● Почему это важно решить в телефоне? — «Потому что решение нужно прямо сейчас, на ходу, в момент голода и дезориентации».

● Что изменится, если решение сработает? — «Человек за 30 секунд получит одно подходящее место, а не список из 80».

Видите? Пять слоёв «почему» превратили банальность в операциональную гипотезу. Задача стала конкретной (голодный человек в незнакомом районе с дефицитом времени), мобильность — обоснованной (здесь и сейчас, на ходу), эффект — наблюдаемым (одно место за 30 секунд вместо скроллинга списка).

«Мы хотим, чтобы люди были здоровее / счастливее / осознаннее». Это ценность, а не гипотеза. Ценность говорит, чего вы хотите. Гипотеза говорит, что именно вы сделаете и как проверите.

«Как Uber, только для выгула собак». Если ваш проект описывается формулой «X для Y», значит, вы ещё не нашли собственную задачу. Вы заимствовали чужую механику и надеетесь, что она сработает в другом контексте. Иногда это работает — но для учебного проекта этого мало. Нам нужно ваше мышление, а не пересадка чужого.

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

«Интерфейс, который визуализирует данные о загрязнении воздуха». Для кого? В какой ситуации? Зачем ему это в телефоне? Если пользователь — абстракция, то и сценарий будет абстракцией, и экраны будут витриной без покупателя.

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

В христианском богословии существует апофатическая традиция, особенно ясно сформулированная Псевдо-Дионисием Ареопагитом в трактате «О мистическом богословии» рубежа V–VI веков. Катафатический язык называет Бога благим, сущим, мудрым; апофатический снимает эти имена, поскольку никакое человеческое понятие не вмещает того, к кому обращено. В конце этого движения отрицаются даже собственные отрицания: апофатика не выдаёт пустой список запретов за портрет Бога и не превращает неизвестное в удобный объект. Она охраняет несоизмеримость предмета с нашим языком.

Перенесите это на проектную гипотезу.

Вы только что прошли четыре ловушки. Каждая из них — это катафатическое утверждение, которое нужно снять: «Мы хотим сделать трекер» — нет. «Мы хотим как Uber» — нет. «Мы хотим ИИ-рекомендации» — нет. «Мы хотим визуализировать данные» — нет.

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

Скульптор отсекает мрамор, пока не освободит форму. Но в нигредо-версии этого метода есть важное отличие: вы не знаете, есть ли внутри ангел. Вы отсекаете — и смотрите. Может быть, внутри пустота. И это тоже результат.

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

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

Вопрос к проекту: какое готовое название — «трекер», «маркетплейс», «социальная сеть», «ИИ-помощник» — подменяет вашу задачу знакомой формой?

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

Джанни Ваттимо называет слабой мыслью (pensiero debole) герменевтическую позицию, отказывающуюся от мечты о последнем прочном основании истории и истины. Джон Капуто в «Слабости Бога» (2006) развивает собственную слабую теологию: имя Бога звучит как зов и обещание без суверенной силы, которая гарантировала бы исход. Формулу «зов без Зовущего» следует понимать внутри этой теологии события, а не как общее определение всякой религии.

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

Применим это к гипотезе.

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

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

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

Слабая гипотеза — та, что знает свои границы:

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

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

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

Вопрос к проекту: какой наблюдаемый результат заставит вас признать, что гипотеза неверна?

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

Грэм Харман развивает идею изъятости сначала в книге «Tool-Being» (2002), перечитывая хайдеггеровский анализ инструмента, а затем в объектно-ориентированной онтологии. Объект не исчерпывается текущими отношениями, функциями и доступными качествами. Огонь встречает хлопок как горючее, пользователь — как ткань, микроскоп — как структуру волокон; ни одна встреча не раскрывает хлопок целиком. Изъятость у Хармана не означает тайный сундук со спрятанными свойствами. Это структурный избыток вещи над всяким конкретным доступом к ней.

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

Что это значит для гипотезы?

Гипотеза — это не чертёж будущего продукта. Это зонд, который вы отправляете в тёмную территорию. Вы формулируете предположение — и пробиваете им стенку пузыря (если вспомнить модель чёрной пены, где мир состоит из непрозрачных пузырей-объектов, разделённых стенками изъятости). В момент прокола вы видите что-то — но не всё. И никогда не всё. Гипотеза — это не претензия на полное знание. Это прокол, через который вы заглядываете в изъятую реальность будущего проекта.

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

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

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

Вопрос к проекту: какой способ использования вы пока принципиаль

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

Формат: FigJam, индивидуально → мини-группы по 3–4 человека. 15 минут.

Задание (8 минут):

Возьмите тему (свою или из списка ниже) и сформулируйте две гипотезы — прикладную и исследовательскую:

Темы на выбор:

● Городской шум

● Одиночество в большом городе

● Очереди

● Физическая усталость после работы

● Утренняя рутина

Для каждой гипотезы заполните карточку:

Обсуждение в мини-группах (7 минут):

Каждый показывает свои две карточки. Группа голосует: какая из двух гипотез сильнее — и почему. Записать одно предложение с обоснованием.

Что я буду разбирать:

2–3 пары, где:

● прикладная версия очень конкретна,

● исследовательская — неожиданна,

● разница между двумя версиями ясно видна.

Что это проверяет:

Видите ли вы, что одна тема порождает принципиально разные проектные траектории в зависимости от типа вопроса?

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

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

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

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

Формат: FigJam, индивидуально. 10 минут.

Это главное упражнение занятия и основа домашнего задания.

Сформулируйте три версии гипотезы вашего проекта. Не три разные темы — а три формулировки одной и той же территории.

Версия 1 — самая широкая. Как вы бы описали свою идею другу за ужином. Версия 2 — сфокусированная. Заполните все три поля (задача, мобильность, эффект). Версия 3 — максимально острая. Одно предложение, в котором видны: кто, что, зачем, как проверить.

Напишите все три на доске. Под третьей версией — одна строка: «Я выбираю эту формулировку, потому что…»

Что я проверю:

● Есть ли движение от общего к конкретному.

● Дошли ли вы до третьей версии или застряли на первой.

● Есть ли в обосновании выбора хотя бы один аргумент, а не просто «мне нравится».

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

Финализация проектной гипотезы.

1. Доработайте три версии гипотезы из интерактива 4 — если не успели на занятии, допишите дома.
2. Выберите одну и оформите её как карточку:

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

Проектная гипотеза — рамка честного эксперимента, а не предсказание успеха.

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

На следующем занятии мы займёмся тем, что стоит за гипотезой: исследованием контекста, пользовательскими ситуациями и Job Stories. Гипотеза задаёт направление — исследование наполняет его плотью.