# База промтов Все промты ниже предполагают работу с UX-базой в `docs/ux`. Для папки `docs/ux/pains` действует режим **только чтение**: агент может искать, читать и анализировать карточки, но не должен создавать, редактировать или удалять боли. Если хочется дополнительно застраховаться, к любому запросу можно добавлять: ``` Работай с docs/ux/pains только на чтение. Ничего в базе болей не создавай, не редактируй и не удаляй. Не додумывай отсутствующие данные. Для выводов показывай, на каких исследованиях и болях они основаны. ```
## Быстро разобраться в базе ### Что вообще есть ``` Изучи docs/ux и объясни, какие знания уже накоплены в базе. Покажи: — основные темы исследований; — основные группы пользователей; — наиболее часто встречающиеся продуктовые области; — какие типы исследований представлены; — какие крупные группы болей можно выделить. Не пересказывай каждый файл отдельно — дай карту базы. ``` ### Краткий онбординг нового человека ``` Представь, что я впервые работаю с Элли. По материалам docs/ux подготовь мне 10-минутный онбординг: — кто основные пользователи; — в каких контекстах они работают; — какие ключевые сценарии исследовались; — какие пользовательские проблемы уже известны; — какие термины мне обязательно понимать. Все утверждения основывай только на базе. ``` ### Что команда уже знает ``` Собери краткое резюме того, что исследовательская команда уже знает о пользовательском опыте Элли. Не перечисляй исследования по очереди. Синтезируй знания поперёк исследований. ```
# Поиск информации по теме ### Что уже знаем по теме ``` Найди всё, что база знает про [ТЕМА]. Собери: — связанные исследования; — связанные боли; — роли; — платформы; — типы торговых точек; — основные выводы; — открытые вопросы. Отдельно отметь, что подтверждено хорошо, а где данных мало. ``` ### Все боли по теме ``` Найди все боли, связанные с [ТЕМА]. Для каждой покажи: — ID; — краткую формулировку; — роль; — платформу; — тип ТТ; — подтверждение; — источник; — текущий статус. Не объединяй разные боли только потому, что у них похожие формулировки. ``` ### Всё про конкретный сценарий ``` Что мы уже знаем про сценарий [СЦЕНАРИЙ]? Найди связанные исследования, боли, роли и наблюдения. Опиши сценарий глазами пользователя: — задача; — контекст; — основные шаги; — затруднения; — известные потребности; — связанные продуктовые изменения. ``` ### Поиск конкретного знания ``` Проверь, есть ли в базе подтверждение утверждения: "[УТВЕРЖДЕНИЕ]" Найди аргументы за и против. Если данных недостаточно — так и скажи. Не интерпретируй отсутствие данных как опровержение. ``` # Работа с болями ### Самые подтверждённые проблемы ``` Найди боли, которые подтверждаются несколькими независимыми источниками или исследованиями. Для каждой покажи: — сколько разных источников её подтверждают; — какие это источники; — насколько разнообразны роли и контексты; — есть ли количественное подтверждение. Не делай вывод о распространённости только по числу файлов. ``` ### Слабые боли ``` Найди боли, у которых самая слабая доказательная база. Например: — единственный источник; — единичная цитата; — нет исследования; — неизвестна выборка; — давно не обновлялись; — нет подтверждения распространённости. Объясни, чего именно не хватает для более уверенного вывода. ``` ### Старые открытые боли ``` Найди самые давно не обновлявшиеся боли со статусом open или in-progress. Не делай вывод, что они неактуальны. Покажи, какие из них стоит перепроверить на актуальность и почему. ``` ### Похожие боли ``` Найди пары или группы болей, которые потенциально описывают одну и ту же пользовательскую проблему разными словами. Для каждой группы сравни: — пользователя; — контекст; — причину; — проявление; — источники. Не объединяй их автоматически. Покажи только кандидатов на ручную проверку. ``` ### Боль целиком ``` Разбери боль [ID]. Покажи: — что именно является проблемой; — у кого она возникает; — в каком контексте; — чем подтверждается; — что неизвестно; — какие решения уже предпринимались; — связанные исследования; — возможные риски неправильной интерпретации. ``` ### Проверить распространённость ``` Что база позволяет сказать о распространённости проблемы [БОЛЬ/ТЕМА]? Отдельно покажи: — качественные свидетельства; — количество участников, если известно; — количественные данные; — ограничения выборки. Не превращай количество упоминаний в процент пользователей. ``` ### ### Старые и новые данные ``` Сравни более старые и более новые исследования по теме [ТЕМА]. Что изменилось со временем? Какие старые проблемы сохраняются? Какие исчезли? Какие появились позже? Не считай изменение автоматически результатом продуктовых доработок, если это не подтверждено. ``` # Роли, подразделения и типы ТТ ### Всё про роль ``` Собери UX-профиль роли [РОЛЬ]. Используй roles, pains и researches. Покажи: — рабочий контекст; — платформы; — права и ограничения; — основные сценарии; — ключевые боли; — связанные исследования; — темы, по которым знаний мало. ``` ### Сравнить две роли ``` Сравни пользовательский опыт ролей [РОЛЬ 1] и [РОЛЬ 2]. Покажи: — общие сценарии; — различия; — общие боли; — боли, характерные только для одной роли; — различия в правах и контексте; — где данных недостаточно. Не переноси результаты одной роли на другую. ``` ### Что характерно именно для роли ``` Какие проблемы подтверждены именно для роли [РОЛЬ], а не для пользователей Элли вообще? Исключи боли, где связь с этой ролью только предполагается. ``` ### Срез по подразделению ``` Собери срез пользовательских проблем для подразделения [ПОДРАЗДЕЛЕНИЕ]. Раздели результат по ролям. Не распространяй боль одной роли на всё подразделение. ``` ### Вайтстор против даркстора ``` Сравни подтверждённые боли Вайтсторов и Дарксторов. Раздели: — общие проблемы; — специфичные для Вайтстора; — специфичные для Даркстора; — проблемы, где тип ТТ неизвестен. Не переносись с одного типа ТТ на другой без явных данных. ``` ### Специфика конкретного контекста ``` Какие пользовательские проблемы появляются только в контексте [ТИП ТТ / ПОДРАЗДЕЛЕНИЕ]? Покажи доказательства специфичности этого контекста. ``` --- # Web и mobile ### Сравнение платформ ``` Сравни боли пользователей web и mobile. Покажи: — проблемы, подтверждённые на обеих платформах; — только web; — только mobile; — случаи, где платформа не определена. Не считай наличие похожей функции доказательством одинаковой боли. ``` ### Один сценарий на разных платформах ``` Сравни пользовательский опыт сценария [СЦЕНАРИЙ] в web и mobile. Покажи только подтверждённые различия. Если по одной платформе нет данных — отметь пробел. ``` # Работа над продуктовой задачей ### Контекст перед проектированием ``` Мы собираемся менять [ФУНКЦИЮ / СЦЕНАРИЙ]. Собери для продуктовой команды существующий UX-контекст: — роли; — боли; — предыдущие исследования; — известные ограничения; — предыдущие попытки решения; — риски, которые уже обнаруживались. ``` ### Какие боли затрагивает фича ``` По описанию продуктовой задачи: [ОПИСАНИЕ] найди существующие боли, которые она потенциально затрагивает. Не создавай новые связи в базе. Покажи кандидатов и объясни, почему они могут быть связаны. ``` ### Проверить решение против известных болей ``` Вот предлагаемое решение: [ОПИСАНИЕ] Сравни его с накопленными исследованиями. Покажи: — какие боли оно потенциально закрывает; — какие не затрагивает; — какие известные пользовательские риски может создать; — какие утверждения требуют проверки с пользователями. ``` ### Какие пользователи могут пострадать ``` Для изменения [ОПИСАНИЕ] найди роли и сценарии, на которые оно потенциально может повлиять по данным базы. Не придумывай технические зависимости. Используй только связи пользовательского контекста. ``` # Подготовка материалов ### Подготовка к встрече ``` Мне предстоит встреча по теме [ТЕМА]. Собери шпаргалку на одну страницу: — что мы точно знаем; — где есть спорные моменты; — какие боли связаны; — какие решения уже предпринимались; — какие вопросы стоит задать команде. ``` ### Ответ на вопрос ``` Коллега спрашивает: "[ВОПРОС]" Подготовь ответ исключительно на основании UX-базы. Сначала дай краткий ответ. Затем покажи исследования и боли, на которых он основан. Отдельно обозначь ограничения данных. ```