навеяно обсуждением в одном чате 🙂 про то, как лучше понимать пользователей и их потребности бывает такое, что смотришь на фичу — видишь баги, эндпоинт, критерии приёмки, edge-кейсы. пользователь смотрит — и хочет, чтобы просто работало. всё. чтобы не застревать в техподробностях и не забывать, зачем всё это вообще делается, набросала набор приёмов. пригодится тестировщикам, аналитикам, разработчикам и не только. 1. вопрос “зачем” как ключ к пониманию не "что мы делаем", а "зачем это кому-то нужно". если ответа нет — задача подвисает в воздухе. пример: "добавим вход по номеру телефона" — это реализация. а цель — "дать возможность войти без пароля, если пользователь забыл его или не помнит email". если ты тестируешь, проектируешь или разрабатываешь, тебе нужно сначала понять смысл. иначе можно сделать "как работает", но не то, что нужно. любое прояснение требований, начатое с вопроса “зачем это надо”, становится более эффективным. 2. проверяй сценарии, не элементы интерфейса/эндпоинты на бэке работоспособная функциональность — это хорошо, но если сценарий в целом не работает, то будет ой. пример: цель — оформить подписку. сценарий — пользователь переходит по ссылке, выбирает тариф, оплачивает. важные моменты: – работает ли сценарий от инициации до получения результата пользователем – можно ли пройти его на мобилке одной рукой – что происходит, если соединение обрывается в какой-то момент проверяй поведение на границах сценария. не сработала оплата — что увидит пользователь? можно ли повторить? здест хорошо пригодятся ux-эвристики нильсена. 3. помни про реальный контекст часто мы тестируем в идеальных условиях. но в жизни пользователь: – заходит на ходу – с неидеальным интернетом и с маленьким экраном – под давлением (спешит, нервничает, отвлекается) протестируй фичу в таких условиях или как минимум спроектируй разные помехи в тестах. 4. думай через цель похоже на первое, но это про мышление в процессе: когда ты действуешь, принимаешь решения, тестируешь. не забывать переводить фокус с реализации на результат. механика простая: – что хочет сделать пользователь? – как он поймёт, что всё получилось? – что ему мешает по пути? пример: форма оформления заказа. есть шаг с подтверждением email — а зачем он, если пользователь уже авторизован? проверь: если убрать этот шаг, всё сломается? если нет — он просто мешает. в системном мышлении это называется "двигаться от желаемого результата". в продуктовом — "валидировать гипотезу". в обоих случаях это фокус на конечном эффекте, а не на подробностях реализации. 5. фидбек — это данные, а не мнение если хочется понять, как реально работает фича, надо идти к тем, кто слушает пользователей каждый день. у саппорта точно есть список болей, у продакта концептуальное видение и приоритеты. что можно делать, чтобы получить данные: – спроси у поддержки: "на что чаще всего жалуются на этом экране?" – попроси продакта показать, какие сценарии сейчас приоритет – проверь в аналитике: где пользователи чаще всего отваливаются многие продуктовые инсайты приходят именно так, а не из логов и документации. итого: если ты смотришь только на реализацию, архитектуру и технические подробности, ты работаешь только с половиной информации. а пользователь видит результат целиком. приложение должно помогать делать то, что человек задумал, всё остальное — опционально. держи в фокусе цель, проверяй сценарий, не игнорируй контекст. тогда меньше бессмысленных фич и больше работающих решений.