{
    "version": "https:\/\/jsonfeed.org\/version\/1",
    "title": "ivan's blog: posts tagged процесс",
    "_rss_description": "It is my diary. I’m ivan zviahin, an designer, manager, car enthusiast.",
    "_rss_language": "en",
    "_itunes_email": "ivanzviahin@gmail.com",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/ivanzviahin.by\/blog\/user\/userpic-square@2x.jpg?1711411913",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/ivanzviahin.by\/blog\/tags\/process-2\/",
    "feed_url": "https:\/\/ivanzviahin.by\/blog\/tags\/process-2\/json\/",
    "icon": "https:\/\/ivanzviahin.by\/blog\/user\/userpic@2x.jpg?1711411913",
    "author": {
        "name": "Ivan Zviahin",
        "url": "https:\/\/ivanzviahin.by\/blog\/",
        "avatar": "https:\/\/ivanzviahin.by\/blog\/user\/userpic@2x.jpg?1711411913"
    },
    "items": [
        {
            "id": "182",
            "url": "https:\/\/ivanzviahin.by\/blog\/all\/proces\/",
            "title": "Дизайн-процесс",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/process\/\">in english<\/a><\/p>\n<p>Глобально дизайнер сталкивается с тремя типами задач в своей повседневной жизни. Первый тип — просто что-то поправить. Второй решить какую-то маленькую задачу. Третий — сделать большой проект. В зависимости от типа задачи зависит и подход к ней.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ivanzviahin.by\/blog\/pictures\/Proprocess-3.jpg\" width=\"2434\" height=\"2560\" alt=\"\" \/>\n<\/div>\n<ol start=\"1\">\n<li>«Что-то поправить» — самый простой. Тут не нужно что-то выдумывать, нужно пойти и поправить. Будет сложно с точки зрения процесса что-то тут сделать не так.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>«Решить маленькую задачу» в рамках большого проекта. Например, мы хотим добавить возможность лайкать публикации в ленте новостей или добавить возможность добавлять QR-коды в свой профиль. Чтобы почитать <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/proces-istorii\/\">процесс для маленькой задачи<\/a> переходи сразу в пункт номер пять.<\/li>\n<\/ol>\n<ol start=\"3\">\n<li>«Сделать большой проект». Это что-то более крупное, что состоит из десятка, сотен, тысяч задач второго типа. И самое главное в этом подходе разбить большой проект на более мелкие задачи. Итак, если речь идет о третьем типе, то сначала нужно ↓<\/li>\n<\/ol>\n<h2>1. Понять цели<\/h2>\n<p>Как правило, это встреча со всеми заинтересованными сторонами. Вместе мы описываем <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/goal\/\">цель и миссию.<\/a> Определяем <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/audience\/\">аудиторию<\/a> для которой мы делаем продукт. Выписываем основные гипотезы, которые имеют прямую связь с целью и миссией. Для каждой гипотезы описываем критерии успеха — набор высокоуровневых метрик и индикаторов.<\/p>\n<ul>\n<li><a href=\"https:\/\/telegra.ph\/Kak-sformirovat-pravilnoe-ponimanie-zadachi-v-produktovom-dizajne-podrobnyj-gajd-04-22\">Подробнее о понимании задачи<\/a> Миша Наер и Иван Звягин<\/li>\n<\/ul>\n<h2>2. Посмотреть на продукт с высоты<\/h2>\n<p>Нам нужно как-то понять объёмы продукта и какие другие системы продукт потенциально может зацепить. Для этого есть несколько простых способов, которые я использую. Важно отметить, что чаще всего лучше использовать все, чтобы расширить кругозор.<\/p>\n<ol start=\"1\">\n<li>Системные карты. Искушение для многих дизайнеров состоит в том, чтобы сразу перейти к разработке интерфейса. Но проектирование конкретных взаимодействий на таком раннем этапе может помешать разработке основ вашего продукта. В рамках воркшопа со всеми заинтересованными сторонами нужно описать проект через системные карты.<\/li>\n<\/ol>\n<ul>\n<li><a href=\"https:\/\/www.intercom.com\/blog\/applying-systems-thinking-in-product-design\/\">Applying systems thinking in product design<\/a> Shekman  Tang<\/li>\n<li><a href=\"https:\/\/www.intercom.com\/blog\/design-futures-1-creating-systems-not-products\/\">Creating systems not destinations<\/a> Paul Adams<\/li>\n<\/ul>\n<ol start=\"2\">\n<li>Карта пользовательских сценариев. Помогает посмотреть на продукт под другим углом и чуть шире, мы как бы выходим за грани продукта и пытаемся понять как пользователь найдет продукт, как поймет специфику работы и так далее. Какие есть роли, какие этапы, какие на этих этапах есть цели и действия. В рамках воркшопа со всеми заинтересованными сторонами нужно описать продукт через карту пользовательских сценариев.  Важно отметить, что это всего лишь наше представление и представление заинтересованных сторон. В реальности все может быть иначе и нужно эту карту отвалидировать с потенциальными пользователями на этапе исследования.<\/li>\n<\/ol>\n<ul>\n<li><a href=\"https:\/\/katesyuma.com\/miroverse\/\">Miroverse Step – 2 – CJM<\/a> Kate Syuma<\/li>\n<\/ul>\n<p>Хорошая практика прямо на этой встрече, в виде воркшопа, набросать потенциальный план исследования.<\/p>\n<h2>3. Убедиться, что мы на правильном пути<\/h2>\n<p>Настало время валидации концепции и поиска точек роста. На это у меня есть несколько простых способов.<\/p>\n<ol start=\"1\">\n<li><a href=\"https:\/\/ivanzviahin.by\/blog\/all\/research-interview\/\">Глубинные интервью.<\/a> Отличный способ найти новые инсайты, точечно. Но не стоит сразу их брать в работу, лучше всего их отвалидировать пунктами 2 и 3.<\/li>\n<li>Опросы. Количественное исследование, которое может подтвердить инсайты из пункта 1 и дать поводы для размышления в отрыве от качественных исследований.<\/li>\n<li>Анализ данных. Количественное исследование, которое может подтвердить инсайты из пункта 1 и дать поводы для размышления в отрыве от качественных исследований.<\/li>\n<li>Анализ конкурентов. Верхнеуровнево посмотреть набор функций ваших прямых и косвенных конкурентов. Это поможет вам найти что-то новое и проверить то, что у вас уже есть.<\/li>\n<li>Анализ метрики, которую бустим. Кабинетное исследование. Как правило мы делаем это не первые в мире и про многие практики написано достаточно много статей с исследованиями и лучшими решениями. Нельзя сказать, что они подойдут нам, но изучить стоит.<\/li>\n<li>Анализ пользовательского фидбэка. Работа с отзывами в сторах и с тем, что прилетает в службу поддержки. Там часто есть алмазы, которые могут подтвердить вашу идею или гипотезу.<\/li>\n<\/ol>\n<p>Все эти способы могут изменить вашу модель из пункта номер два.<\/p>\n<h2>4. Приоритезировать и разбить на версии<\/h2>\n<p>Далее нам нужно всю нашу концепцию разделить на маленькие пользовательские истории, приоритизировать их и разделить на версии.<\/p>\n<p>Итак, в комнату входит карта пользовательских историй. Это такая визуализация скоупа решения. Помогает нам определить минимальный жизнеспособный продукт и его эволюции. Ниже есть хорошее видео, которое объясняет как это работает за три минуты.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/TaMLUf3gISo?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p>Для приоритезации историй по важности можно использовать <a href=\"https:\/\/www.productplan.com\/glossary\/moscow-prioritization\/\">фреймворк moscow,<\/a> а для технической сложности <a href=\"https:\/\/medium.com\/radius-engineering\/project-estimation-through-t-shirt-size-ea496c631428\">фреймворк t-shirt size.<\/a><\/p>\n<p>В итоге мы имеем десятки, сотни, тысячи пользовательских историй, которые приоритезированы и разбиты на версии.<\/p>\n<h2>5. Индивидуально подойти к каждой истории<\/h2>\n<p>Далее работаем с каждой историей (маленькой задачей) по похожему процессу, но всё же, немного другому.<\/p>\n<ol start=\"1\">\n<li>Понимание задачи<\/li>\n<li>Дискавери<\/li>\n<li>Формулирование гипотез и низкоуровневые прототипы<\/li>\n<li>Скоупинг и высокоуровневые макеты<\/li>\n<li>Ревью результата и запуск!<\/li>\n<li>Анализ результата и новые итерации<\/li>\n<\/ol>\n<p><b><a href=\"https:\/\/ivanzviahin.by\/blog\/all\/proces-istorii\/\">Подробнее про дизайн-процесс маленькой задачи →<\/a><\/b><br \/>\n<b><a href=\"https:\/\/drive.google.com\/file\/d\/1npBBtwRmWbiGo038QA97r0Iq0h5LJzgh\/view?usp=sharing\">Постер, ПДФ 2.3 МБ<\/a><\/b><\/p>\n",
            "date_published": "2022-04-14T22:39:28+00:00",
            "date_modified": "2023-11-21T20:51:08+00:00",
            "image": "https:\/\/ivanzviahin.by\/blog\/pictures\/Frame-8-3.png",
            "_date_published_rfc2822": "Thu, 14 Apr 2022 22:39:28 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "182",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/Frame-8-3.png",
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/proprocess-w-2.jpg",
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/proprocess-3.jpg",
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/Proprocess-3.jpg",
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/remote\/youtube-TaMLUf3gISo-cover.jpg"
                ]
            }
        },
        {
            "id": "175",
            "url": "https:\/\/ivanzviahin.by\/blog\/all\/koridornye-testy\/",
            "title": "Коридорные тесты",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/drafts\/corridor-tests\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ivanzviahin.by\/blog\/pictures\/david-travis-WC6MJ0kRzGw-unsplash-2.jpg\" width=\"2560\" height=\"1295\" alt=\"\" \/>\n<\/div>\n<h2>Для чего нужны эти ваши тесты<\/h2>\n<p>Так, на этом этапе у вас уже есть прототипы и сформулированные гипотезы. Теперь осталось потрясти этот мешочек и убедиться, что все работает так, как задумывалось. А точнее проверить интерфейс, иконки, подписи, акценты и так далее.<\/p>\n<h2>Это просто, расскажу тезисно<\/h2>\n<p>Гипотезы у нас уже сформулированы, поэтому просто выписываем их. Формулируем задания для пользователей, обязательно письменно.<\/p>\n<p>Готовим кликабельны прототип, если он нужен. Фиксируем «створы ворот», другими словами конверсионные отметки интерфейса. Например: открытие формы, успешное заполнение, отправка и так далее.<\/p>\n<p>Ищем участников для тестирования. Проводим тестирование и помечаем всё самое важное. Делаем выводы, анализируем их. Иии бинго, 100% процентов вы измените своё отношение к своим идеальным прототипам.<\/p>\n<h2>1 шаг. Определить гипотезы<\/h2>\n<p>Гипотезы — это предположения, которые мы собираемся проверить в ходе исследования. Её лучше формулировать по шаблону: «Если мы сделаем (сама идея), то он сможет положительно повлиять на (критерий успеха), так как (почему это идея хорошая)».<\/p>\n<h2>2 шаг. Выбрать метод тестирования<\/h2>\n<p>Все методологии тестирования делятся на немодерируемые и модерируемые по степени самостоятельности выполнения задания респондентами, а также по месту нахождения респондента и интервьюера в момент прохождения тестирования.<\/p>\n<p><b>Первый клик.<\/b> Участник исследования переходит по ссылке и получает очень простое задание. Например: «Куда бы вы нажали, чтобы найти информацию о лизинговых программах?», «Выберите лизинг для покупки выбранного автомобиля». Фиксируется только первый клик. Если большинство респондентов нажмут «не туда», это сигнализирует о том, что на экране есть юзабилити-проблемы.<\/p>\n<p><b>Бок-о-бок.<\/b> Суть метода заключается в сравнении двух вариантов и выбора одного по принципу лучшей видимости или узнаваемости целевого объекта. Респондентам предлагается сравнить две картинки интерфейса или выбрать в определенный элемент на двух вариантах изображения. Например: «Найдите и выберите способ оплаты A1», «Какой из вариантов баннера более узнаваем для материала “Машины в лизинг на авэ”».<\/p>\n<p><b>На проходимость.<\/b> Метод более всего приближен к модерируемому тестированию. Он предполагает присутствие интервьюера рядом с респондентом в момент проведения теста. Мы выбираем конверсионные точки и даём задание респонденту, которое, предположительно, должно его повести по нужному вам пути. В итоге фиксируются факты прохождения точек и делаются пометки о трудностях, возникших у пользователя.<\/p>\n<p><b>Модерируемое тестирование.<\/b> При такой проверке пользователь выполняет поставленные задачи в отношении продукта или услуги, в то время как исследователь или модератор наблюдает за ним в режиме реального времени. Каждый из вышеперечисленных методов может быть модерируемым. Достоверность результатов и глубина получаемых инсайтов в ходе такого тестирования считается лучшей, чем при применении методов без модерации.<\/p>\n<h2>3 шаг. Выбор респондентов<\/h2>\n<p>Для тестировнаия желательны представители целевой аудитории, сталкивающиеся в реальной жизни с задачами, которые описаны в заданиях тестирования. Однако, коридорный тест делает поблажки в этом вопросе, и респондентами могу стать абсолютно все прямые или косвенные пользователи интернета.<\/p>\n<p>От пяти до восьми респондентов достаточно, чтобы выявить самые грубые проблемы интерфейса. Если все респонденты сталкиваются с одной и той же трудностью — это повод остановить тестирование, внести правки в прототип и начать тестирование новой версии.<\/p>\n<p>Если ресурсы и время на работу над сайтом сильно ограничены, руководствуемся принципом: «лучше меньше, чем ничего». Три респондента лучше, чем ни одного. Коридорный тест, не привязанный к целевым респондентам, лучше чем никакого.<\/p>\n<h2>4 шаг. Формирование задания<\/h2>\n<p>Качество результатов и их объективность напрямую зависит от формулировки вопросов и заданий в тестировании. Чек-лист для формулировки задания:<\/p>\n<ol start=\"1\">\n<li>Трактуется однозначно.<\/li>\n<li>Озвучено в полном объёме.<\/li>\n<li>Релевантно опыту респондента.<\/li>\n<li>Возможно выполнить без подсказок. <\/li>\n<\/ol>\n<h2>5 шаг. Подготовка прототипа<\/h2>\n<p>Тестовый прототип может быть:<\/p>\n<ol start=\"1\">\n<li>Интерактивный кликабельный прототип.<\/li>\n<li>Тестовая версия или работающий сайт.<\/li>\n<li>Просто картинка.<\/li>\n<\/ol>\n<p>Чек-лист для проверки прототипа:<\/p>\n<ol start=\"1\">\n<li>Сценарии, заложенные в задании, выполняются.<\/li>\n<li>Предусмотрены разные варианты выполнения сценария.<\/li>\n<li>Тексты, цифры и визуальный контент похожи на настоящие.<\/li>\n<li>Нет ошибок и опечаток в текстах и цифрах.<\/li>\n<li>Нет подсказок.<\/li>\n<li>Заложена возможность быстро вернуться к началу сценария.<\/li>\n<\/ol>\n<h2>6 шаг. Процесс тестирования<\/h2>\n<p>Правильно проведённое тестирование будет менее стрессовым для респондента, будет более простым в модерировании и, следовательно, даст более релевантные результаты. Проще говоря — заткнись, слушай респондента и не мешай ему ничего не понимать.<\/p>\n<p>Большую часть времени в ходе тестирования говорит респондент. Модератор говорит только в случае крайней необходимости. Любое вмешательство модератора влияет на ход эксперимента и искажает данные.<\/p>\n<p>Если респондент перестал «мыслить вслух» – напомнить ему об этом: «Итак… Так, вы думаете, что... Что вы видите здесь? Скажите мне, что случилось».<\/p>\n<p>Вопросы часто заставляют респондента занимать оборонительную позицию. Можно заменить вопросы побудительными фразами типа: «Расскажите мне немного об этом... Опишите более подробно... Поделитесь своими ощущениями... Давайте поговорим об этом... Помогите мне понять...».<\/p>\n<p>В каких случаях помогать:<\/p>\n<ol start=\"1\">\n<li>Респондент должен чувствовать, что вы подбадриваете его, а не продукт.<\/li>\n<li>Если респондент испробовал несколько способов действий и просит о помощи.<\/li>\n<li>Респондент думает, что задание выполнено, но это не так.<\/li>\n<\/ol>\n<p>Как это делать:<\/p>\n<ol start=\"1\">\n<li>Сфокусировать на задании, напомнить цель задания.<\/li>\n<li>Сделать общий намек: «Вспомните, как вы начали выполнять задание», «Вы уже видели это».<\/li>\n<li>Сказать прямо, что делать дальше.<\/li>\n<\/ol>\n<p>Важно зафиксировать моменты, где респондент столкнулся с трудностями. После тестирования задаем респонденту несколько вопросов. Вам необязательно следовать прямым рекомендациям по изменению сайта, которые респондент выскажет в ходе беседы. Выводы и рекомендации обычно делаем из наблюдения за поведением, а не из беседы.<\/p>\n<h2>7 шаг. Фиксирование результатов и выводы<\/h2>\n<p>Еще на этапе формулирования гипотез рекомендуем создать таблицу, содержащую декомпозированные гипотезы и задания для тестирования с содержанием шагов пользователя или отбитыми конверсионными точками.<\/p>\n<p>После каждой встречи фиксируйте в таблице результат тестирования: подтвердилась ли гипотеза, справился ли респондент с заданием без ошибок. Также вносим туда инсайты и прочие пометки, описывающие поведения пользователя на том или ином шаге задания.<\/p>\n<p>На основе этого документа делаем выводы о подтверждении или неподтверждении гипотез, а также формулируем новые, если это нужно.<\/p>\n<h2>Таблица для фиксирования результатов<\/h2>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ivanzviahin.by\/blog\/pictures\/Screenshot-2021-12-21-at-00.57.17-3.jpg\" width=\"2560\" height=\"569\" alt=\"\" \/>\n<div class=\"e2-text-caption\"><a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/1jUvKw8LC8IRR54LL9nPpM__AIBPysdwt8xXmK4RDAR4\/edit?usp=sharing\">Шаблон таблицы в Google Docs<\/a><\/div>\n<\/div>\n",
            "date_published": "2021-12-20T22:07:27+00:00",
            "date_modified": "2022-08-19T09:53:47+00:00",
            "image": "https:\/\/ivanzviahin.by\/blog\/pictures\/david-travis-WC6MJ0kRzGw-unsplash-2.jpg",
            "_date_published_rfc2822": "Mon, 20 Dec 2021 22:07:27 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "175",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/david-travis-WC6MJ0kRzGw-unsplash-2.jpg",
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/Screenshot-2021-12-21-at-00.57.17-3.jpg"
                ]
            }
        },
        {
            "id": "173",
            "url": "https:\/\/ivanzviahin.by\/blog\/all\/analiz-konkurentov\/",
            "title": "Анализ конкурентов",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/competitor-analysis\/\">in english<\/a><\/p>\n<p>Я рассматриваю анализ конкурентов в рамках какой-то конкретной фичи, как один из способов анализа и поиска идей. Это не про создание чего-то большого и не про общую оценку рынка.<\/p>\n<p>Важно отметить, что нам уже известна проблема и цель. У нас есть критерий успеха и определена аудитория. Что дальше?<\/p>\n<h2>Описываем критерии оценки<\/h2>\n<p>Для каждой фичи критерии будут разные. Описываем кратко, но как можно конкретнее:<\/p>\n<ol start=\"1\">\n<li>Насколько хорошо решена проблема или задача. Решений может быть несколько. Например, добавления фото на форме подачи или что-то другое.<\/li>\n<li>Первое взаимодействие с интерфейсом.<\/li>\n<li>Горячие клавиши и интерактивность.<\/li>\n<li>Еще всякое, что является важным в контексте конкретной фичи...<\/li>\n<\/ol>\n<h2>Ищем конкурентов<\/h2>\n<p>Как правило, 3—4 прямых конкурента уже известны. Включаем в список и разбиваем на платформы, если необходимо. Каждая платформа — отдельный анализ.<\/p>\n<p>Не забываем про косвенных конкурентов. Газета, радио, сервис продажи квартиры, форма подачи на визу. Они помогают найти «новое», но к ним надо относиться скептически. Фича, которая у них работает круто, может совсем не нужна нашей аудитории.<\/p>\n<h2>Записываем в таблицу или на дашборд со скриншотами<\/h2>\n<p>Записываем критерии и возле каждого добавляем поле «оценка» и «комментарий».<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ivanzviahin.by\/blog\/pictures\/compit.jpg\" width=\"2277\" height=\"755\" alt=\"\" \/>\n<div class=\"e2-text-caption\"><a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/1YJtrJd9_mGNQn9eiK1YKRmKXCIP-uDqGGXtjqMa-rZ4\/edit?usp=sharing\">Шаблон в Google Docs<\/a><\/div>\n<\/div>\n<p>«Оценка» — от 0 до 5. Чем лучше реализован критерий у конкурента, тем выше оценка. Она нужна для того, чтобы мнение не трансформировалось на фоне других конкурентов.<\/p>\n<p>«Комментарий» — Что повлияло на оценку? Почему не 5? Опционально можно добавлять еще скриншоты для наглядности.<\/p>\n<h2>Делаем выводы<\/h2>\n<p>В процессе заполнения таблицы появятся идеи, что решает проблему хорошо, а что не очень и как это можно улучшить. На основе полученной информации составляем гипотезы.<\/p>\n",
            "date_published": "2021-11-23T21:15:27+00:00",
            "date_modified": "2022-08-24T20:26:21+00:00",
            "image": "https:\/\/ivanzviahin.by\/blog\/pictures\/compit.jpg",
            "_date_published_rfc2822": "Tue, 23 Nov 2021 21:15:27 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "173",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/compit.jpg"
                ]
            }
        },
        {
            "id": "172",
            "url": "https:\/\/ivanzviahin.by\/blog\/all\/audience\/",
            "title": "Аудитория",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/portret\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ivanzviahin.by\/blog\/pictures\/audiiience.png\" width=\"1590\" height=\"628\" alt=\"\" \/>\n<\/div>\n<p>Для чего нужно понимать аудиторию? Чтобы поймать правильную ментальную модель при проектировании интерфейса, проявить эмпатию, сделать максимально понятный продукт. И часто это не очень просто сделать.<\/p>\n<p>Есть, например, такой инструмент — персоны или портреты аудиторий. Я не сильно верю в эти способы. Почему? Первое, чаще всего, они собираются на основании сомнительной информации. Второе, аудитория динамична и часто сильно разнообразна. Вчерашние персоны могут не отражать реальность сегодня.<\/p>\n<p>И вот если всё так плохо, то что же делать? У меня есть пару мыслей на этот счет.<\/p>\n<h2>1. Используйте данные<\/h2>\n<p>Идем в аналитику и пытаемся выявить там нашу аудиторию на основании банальных характеристик:<\/p>\n<ul>\n<li>пол,<\/li>\n<li>возраст,<\/li>\n<li>место проживания,<\/li>\n<li>доход.<\/li>\n<\/ul>\n<p>Если данные не работают, сделайте опрос или посмотрите статистику ваших соцсетей.<\/p>\n<p>Возможно вы заметите, что только на основании данных уже можно разбить аудиторию на несколько портретов. Теперь мы представляем очень грубо кто эти люди и на какие примерно сегменты они делятся. Давайте возьмем статистическую середину каждого сегмента и попробуем про них что-то узнать больше.<\/p>\n<h2>2. Еженедельно общайтесь с пользователями<\/h2>\n<p>В теории звучит очень страшно и сложно, на практике очень интерсено и полезно. И да, я про еженедельные интервью. У нас уже есть представление о среднестатистическом представителе нашей аудитории. Осталось их найти и поговорить.<\/p>\n<p>О чем так часто говорить? Оказывается, что тем всегда много: проверить прототипы текущих задач, поговорить за жизнь, про будущее, про проблемы, обсудить функции из дальнего бэклога. Через пару месяцев вы будете хорошо понимать кто ваша аудитория. Какие у нее есть сегменты, какие у сегментов есть:<\/p>\n<ul>\n<li>проблемы,<\/li>\n<li>мотивации,<\/li>\n<li>контекст,<\/li>\n<li>ожидания.<\/li>\n<\/ul>\n<p>Где взять пользователей? Хороший вопрос. Выгрузка базы данных и отправка писем с приглашением поговорить. Тут уже ваша фантазия как это позиционировать. Возможно это какой-то закрытый клуб приблеженных к продукту пользователей или просто возможность получить футболку с логотипом компании.<\/p>\n<p>Альтернативой интервью или дополнительным источником информации могут быть всякого рода сообщества или комментаторы в сторах и соцсетях.<\/p>\n<h2>3. Дополняйте портреты в процессе общения<\/h2>\n<p>Наверное вам нужно как-то фиксировать новую информацию. Поэтому кажется логичным взять портреты из первого пункта и дополнять их в процессе.<\/p>\n<h2>⌘⌘⌘<\/h2>\n<p>Пример портретов доски объявлений о покупке и продаже машин av.by спустя годы работы.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ivanzviahin.by\/blog\/pictures\/ps_1.jpg\" width=\"2560\" height=\"2524\" alt=\"\" \/>\n<\/div>\n",
            "date_published": "2021-11-13T17:14:07+00:00",
            "date_modified": "2022-04-27T20:06:11+00:00",
            "image": "https:\/\/ivanzviahin.by\/blog\/pictures\/audiiience.png",
            "_date_published_rfc2822": "Sat, 13 Nov 2021 17:14:07 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "172",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/audiiience.png",
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/ps_1.jpg"
                ]
            }
        },
        {
            "id": "171",
            "url": "https:\/\/ivanzviahin.by\/blog\/all\/goal\/",
            "title": "Цель и миссия",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/goal-mission\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ivanzviahin.by\/blog\/pictures\/gomi-1.jpg\" width=\"2386\" height=\"943\" alt=\"\" \/>\n<\/div>\n<p>Или как я формулирую цель и миссию при работе с задачей.<\/p>\n<h2>Цель<\/h2>\n<p>Цель — итоговая точка <b>в мире бизнеса,<\/b> которую мы хотим достигнуть, делая что-то. Например, мы хотим повысит выручку на 33% за третий квартал увеличив количество сервисных платежей.<\/p>\n<ol start=\"1\">\n<li>Цель должна быть конкретной. Что именно мы хотим повысить? Можно ли это сегментировать более подробно?<\/li>\n<li>Измеримой. Здесь нужно обозначить число. Числовое определение, количество в абсолютном или процентном виде.<\/li>\n<li>С дедлайном. Сколько времени нам нужно для того, чтобы прийти к успеху? Когда должен быть получен запланированный результат?<\/li>\n<\/ol>\n<h2>Миссия<\/h2>\n<p>Миссия — это то, чем мы <b>поможем пользователю,<\/b> если что-то сделаем. Например, мы хотим помочь пользователю быстро узнавать о появлении новых объявлений по интересным ему поискам. Если через месяц 25% процентов пользователей будет это использовать, то это будет считаться успехом.<\/p>\n<h2>Могут ли они быть вместе?<\/h2>\n<p>Да. Круче всего когда удается делать решения в поле пересечений миссии и цели, но иногда бывает так, что решение лежит только в поле миссии или цели. И это нормально.<\/p>\n<h2>Как сформулировать?<\/h2>\n<p>Обсудите проблему с вашим менеджером по продукту. Обсудите, как это влияет на наших конечных пользователей и наш бизнес. Обсудите, как выглядит успех, определив показатели успеха. Запишите свои открытые вопросы и подумайте, как вы на них ответите. Посмотрите на прошлые исследования. Бросьте вызов формулировке — правильная ли это проблема, правильно ли она сформулирована?<\/p>\n",
            "date_published": "2021-11-10T10:25:07+00:00",
            "date_modified": "2022-11-05T17:29:18+00:00",
            "image": "https:\/\/ivanzviahin.by\/blog\/pictures\/gomi-1.jpg",
            "_date_published_rfc2822": "Wed, 10 Nov 2021 10:25:07 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "171",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/gomi-1.jpg"
                ]
            }
        },
        {
            "id": "149",
            "url": "https:\/\/ivanzviahin.by\/blog\/all\/proces-istorii\/",
            "title": "Дизайн-процесс · задача",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/process-story\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ivanzviahin.by\/blog\/pictures\/Frame-5-1.png\" width=\"2386\" height=\"1085\" alt=\"\" \/>\n<\/div>\n<p>На входе всегда есть высокоуровневые требования от продакт менеджера или от проектной документации. Обычно это выглядит просто как запрос, реже более детально с уже выдвинутыми гипотезами. Например, мы хотим добавить возможность лайкать публикации в ленте новостей или добавить возможность добавлять QR-коды в свой профиль.<\/p>\n<h2>1. Понимание<\/h2>\n<p>Знакомство с верхнеуровневыми требованиями. Обозначение <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/goal\/\">цели и миссии.<\/a> Сразу отмечаю как мы поймём, что результат будет достигнут — критерий успеха. Чаще всего это какой-то показатель в цифрах. Отмечаю кто является целевой <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/audience\/\">аудиторией.<\/a><\/p>\n<ul>\n<li><a href=\"https:\/\/telegra.ph\/Kak-sformirovat-pravilnoe-ponimanie-zadachi-v-produktovom-dizajne-podrobnyj-gajd-04-22\">Подробнее о понимании задачи<\/a> Миша Наер и Иван Звягин<\/li>\n<\/ul>\n<p><i>Хорошая практика:<\/i><\/p>\n<ul>\n<li><i>нарисовать системную диаграмму этой задачи,<\/i><\/li>\n<li><i>синхронизировать это понимание с членами команды.<\/i><\/li>\n<\/ul>\n<h2>2. Дискавери<\/h2>\n<p>Анализ нужен для того, чтобы сформулировать как можно больше валидных гипотез. У меня есть несколько рабочих способов:<\/p>\n<ol start=\"1\">\n<li>Анализ текущего решения, если оно есть, или личное представление о решении проблемы. Мы же опытные дизайнеры, мы можем сразу сказать что можно улучшить.<\/li>\n<li><a href=\"https:\/\/ivanzviahin.by\/blog\/all\/analiz-konkurentov\/\">Анализ конкурентов.<\/a><\/li>\n<li>Анализ пользовательского фидбэка. Работа с отзывами в сторах и с тем, что прилетает в службу поддержки.<\/li>\n<li>Анализ фидбэка от других отделов, если это уместно. Например, коммерческий отдел или маркетинг.<\/li>\n<li><a href=\"https:\/\/ivanzviahin.by\/blog\/all\/research-interview\/\">Глубинные интервью<\/a> с потенциальной аудиторией.<\/li>\n<li>Анализ метрики, которую бустим. Кабинетное исследование. Как правило мы делаем это не первые в мире и про многие практики написано достаточно много статей с исследованиями и лучшими решениями. Нельзя сказать, что они подойдут нам, но изучить стоит.<\/li>\n<li>Анализ данных.<\/li>\n<\/ol>\n<h2>3. Формулирование гипотез и низкоуровневые прототипы<\/h2>\n<p>После анализа у меня есть куча идей и я их пытаюсь формализовывать по маске:<\/p>\n<ul>\n<li>«Если мы сделаем <i>(сама идея)<\/i>, то он сможет положительно повлиять на <i>(критерий успеха)<\/i>, так как <i>(почему это идея хорошая)<\/i>».<\/li>\n<\/ul>\n<p>Для каждой гипотезы обычно я делаю простые и дешевые прототипы. Это помогает пожить с идеей и объяснить ее другим. Иногда это помогает найти новые гипотезы.<\/p>\n<p><i>Хорошая практика:<\/i><\/p>\n<ul>\n<li><i>провести дизайн-сессию, показать прототипы другим дизайнерам в команде, аналитикам, подакт менеджеру. Там мы принимаем решение с какими идеями едем дальше,<\/i><\/li>\n<li><i>лучшие идеи проверяю <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/koridornye-testy\/\">коридорными тестами.<\/a> Это помогает найти слабые места в интерфейсе.<\/i><\/li>\n<\/ul>\n<p>Далее выставляем приоритет каждой гипотезе. Приоритет оценивается по двум параметрам:<\/p>\n<ul>\n<li>насколько гипотеза помогает достигнуть цель или миссию (от 0 до 10) вместе с продуктовым менеджером,<\/li>\n<li>насколько она технически сложная в реализации (тоже от 0 до 10) вместе с разработчиками.<\/li>\n<\/ul>\n<p>По каждой гипотезе делю одно на другое и получаю коэффициент. Сортируем и получаем то, что нужно брать в работу в первую очередь.<\/p>\n<h2>4. Скоупинг и высокоуровневые макеты<\/h2>\n<p>Мы начали с понимания проблемы. Далее мы мыслили масштабно, когда генерировали гипотезы. Мы берем это масштабное видение, этот долгосрочный план или мечту, а затем начинаем с малого, разбиваем ее на мельчайшие кусочки. И продолжаем  убирать функциональность, пока не получим наименьшее ценное решение. Мы обычно делаем это вместе с продакт менеджером.<\/p>\n<p>Для лучшего решения я делаю макеты. Обрисовываю все состоянии. Работаю с синтаксисом элементов интерфейса и текстом. Пишу пояснительные заметки для разработчиков. Анимирую экраны и элементы интерфейса.<\/p>\n<p><i>Хорошая практика:<\/i><\/p>\n<ul>\n<li><i>смотрю на каждый пользовательский сценарий через <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/urovenprorabotki\/\">уровни проработки,<\/a><\/i><\/li>\n<li><i>проверяю каждый экран <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/check-list-to-verify-the-interface\/\">чек-листом,<\/a><\/i><\/li>\n<li><i>итог проверяю <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/koridornye-testy\/\">коридорными тестами.<\/a> Это помогает найти слабые места в интерфейсе,<\/i><\/li>\n<li><i>помечаю, что к этой задаче нужно будет вернуться через какое-то время и сверить результат с первичными ожиданиями,<\/i><\/li>\n<li><i>отдаю макеты другому дизайнеру на дизайн-ревью, чтобы он их просмотрел и постарался найти там ошибки,<\/i><\/li>\n<li><i>отдаю макеты на продакт-ревью, чтобы аналитик или продакт менеджер сопоставил макеты с критериями приемки описанными в задаче.<\/i><\/li>\n<\/ul>\n<h2>5. Ревью результата и запуск!<\/h2>\n<p>После тестов тоже стоит посмотреть что получилось в итоге, чтобы сверить задуманное с реализацией. Далее запуск.<\/p>\n<h2>6. Анализ результата<\/h2>\n<p>Через какое-то время, зависит от задачи, возвращаюсь к задаче и анализирую результат вместе с продакт менеджером.  Насколько наши ожидания совпали с реальными результатами, делаем выводы. Для удобства я фиксирую задачи с датами и выводами в Гугл Таблице, без всяких супер-заморочек.<\/p>\n<p>Далее итерации, итерации и итерации. Если все плохо возвращаемся к пункту один, если хорошо — тоже, но уже с новыми целями.<\/p>\n<h2>— Это очень долго!<\/h2>\n<p>Весь этот процесс, звучит сложным и долгим, да. Но важно отметить, что в реальности это не так долго, как кажется. Первых 6 пунктов средней по сложности задачи делаются за 1—2 рабочих дня. Тем более тут описан идеальный процесс, в реальной жизни некоторые пункты пропускаются или автоматизируются.<\/p>\n<p><b><a href=\"https:\/\/ivanzviahin.by\/blog\/all\/proces\/\">Дизайн-процесс большого проекта →<\/a><\/b><\/p>\n",
            "date_published": "2021-08-03T11:09:13+00:00",
            "date_modified": "2023-05-10T21:11:56+00:00",
            "image": "https:\/\/ivanzviahin.by\/blog\/pictures\/Frame-5.png",
            "_date_published_rfc2822": "Tue, 03 Aug 2021 11:09:13 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "149",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/Frame-5.png",
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/Frame-5-1.png"
                ]
            }
        },
        {
            "id": "145",
            "url": "https:\/\/ivanzviahin.by\/blog\/all\/check-list-to-verify-the-interface\/",
            "title": "Самостоятельная проверка интерфейса",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/drafts\/self-checking-the-interface\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ivanzviahin.by\/blog\/pictures\/checklist.png\" width=\"1590\" height=\"628\" alt=\"\" \/>\n<\/div>\n<p>Перед каждым экраном интерфейса я задаю себе вопросы:<\/p>\n<ol start=\"1\">\n<li>А есть ли в этом случае у человека какая-то привычка? Есть ли в мире какие-то привычные паттерны такого интерфейса? Могу ли я сделать максимально приближённый интерфейс к этой привычке?<\/li>\n<li>Не заставляю ли я делать что-то пользователя, что может сделать компьютер? Например, поле сразу в фокусе.<\/li>\n<li>Не потерял ли я данные, которые дал мне пользователь?<\/li>\n<li>Убрал ли я все лишнее с этого экрана? Есть ли возможность соединить какую-то функциональность? Могу ли я добавить какую-то полезность?<\/li>\n<li>Я стараюсь представить, что я не видел ничего до попадания на конкретный экран. А понятно ли мне на этом экране всё, с учётом всего вышесказанного?<\/li>\n<li>Сделал ли я всё, чтобы не использовать модальный интерфейс? Могу ли я показать все функции сразу? Могу ли я использовать квазирежим? Хорошо ли я продумал навигацию стеков?<\/li>\n<li>Легко ли мне попасть в каждый элемент? Показал ли я области клика?<\/li>\n<li>Подумал ли я об обратной связи каждого действия? Она должна быть быстрой, постоянной и ненавязчивой. Местами эмоциональный, где то нужно. Подготовил ли я анимацию важных элементов интерфейса? Нужна ли тактильная обратная связь и звуковая?<\/li>\n<li>А действительно ли мой интерфейс находится в границах ментальной модели пользователя? Могу ли я снизить сопротивление, если выхожу за границы этой модели?<\/li>\n<li>Систематизирован ли мой интерфейс? Могу ли я что-то переиспользовать? Соответствуют ли все элементы дизайн-системе?<\/li>\n<li>Выглядит ли мой интерфейс просто, понятно и <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/krasota\/\">красиво?<\/a> Не потерял ли я простоту, пытаясь объяснить что это за экран?<\/li>\n<li>Не забыл ли я про даркмод?<\/li>\n<li>Не забыл ли я про планшеты? Про маленькие смартфоны?<\/li>\n<li>Не забыл ли я учесть, как будет выглядеть интерфейс с увеличенным шрифтом?<\/li>\n<li>Описал ли я все крайние состояния? Сколько строк текста? Как позиционировать картинки и так далее. Как выглядит экран без данных?<\/li>\n<li>Нет ли лишних лоудеров? В идеале не должно быть лоудеров вообще. Нужны ли скелетоны?<\/li>\n<li>Если есть пуши, то не забыл ли я показать куда они ведут?<\/li>\n<li>Обсудил ли я синтаксис с редактором?<\/li>\n<li>Добавил ли я вишенку на торт? Сделал ли я что-то мелкое, но важное, что удивит пользователя?<\/li>\n<\/ol>\n",
            "date_published": "2020-05-23T17:38:25+00:00",
            "date_modified": "2023-08-23T13:35:34+00:00",
            "image": "https:\/\/ivanzviahin.by\/blog\/pictures\/checklist.png",
            "_date_published_rfc2822": "Sat, 23 May 2020 17:38:25 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "145",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/checklist.png"
                ]
            }
        },
        {
            "id": "120",
            "url": "https:\/\/ivanzviahin.by\/blog\/all\/research-interview\/",
            "title": "Глубинное интервью",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/in-depth-interview\/\">in english<\/a><\/p>\n<p>Глубинное интервью — это целенаправленное общение в форме вопросов и ответов, целью которого является получение нужной исследователю информации. Ключевая задача — не просто расспросить, а увидеть мир глазами других и почувствовать то, что чувствуют они. Ниже я расскажу про преимущества и недостатки открытых и закрытых вопросов, про популярные техники, про стадии интервью и решение сложных ситуаций.<\/p>\n<h2>Закрытые вопросы<\/h2>\n<p>Почти всегда задавать закрытые вопросы — это плохо. Они предполагают бинарный или однозначный ответ: да или нет.<\/p>\n<p>Преимущества:<\/p>\n<ul>\n<li>позволяют получить конкретную информацию<\/li>\n<li>подтвердить или опровергнуть гипотезы, проверить, правильно ли вы поняли<\/li>\n<li>хорошая смена темы<\/li>\n<\/ul>\n<p>Недостатки:<\/p>\n<ul>\n<li>получаем мало информации<\/li>\n<li>нет деталей и подробностей<\/li>\n<li>можем навязать свое мнение<\/li>\n<\/ul>\n<h2>Открытые вопросы<\/h2>\n<p>Эти обычно начинаются со слов: «почему, зачем, как, опишите, расскажите, что вы думаете и прочее».<\/p>\n<p>Преимущества:<\/p>\n<ul>\n<li>позволяют собеседнику отвечать вне ограничений<\/li>\n<li>дают собеседнику возможность свободно говорить о своих чувствах и комментировать события<\/li>\n<li>провоцируют человека на размышления, анализ своих поступков и мыслей, которые ранее, может быть, и не приходили в голову<\/li>\n<\/ul>\n<p>Недостатки:<\/p>\n<ul>\n<li>могут спровоцировать длинный сумбурный ответ<\/li>\n<li>собеседник может увлечься и уйти «не туда»<\/li>\n<\/ul>\n<p>Грязный приём, как превратить закрытый вопрос в открытый. Закрытый вопрос + «Расскажите...» = Открытый вопрос.<\/p>\n<h2>Техника «Пять почему»<\/h2>\n<p>Для того, чтобы найти причину поведения, проблемы, несоответствия необходимо последовательно задавать один и тот же вопрос — «Почему?», и искать ответы на этот вопрос. Каждый последующий вопрос задается к ответам на предыдущий вопрос.<\/p>\n<p>Часто повтор одного и того же вопроса вызывает дискомфорт. Как сгладить его:<\/p>\n<ol start=\"1\">\n<li>Переформулировать, например «Что является причиной?» или «Из-за чего ... происходит?» или «А чего так?».<\/li>\n<li>Сказать, что будете спрашивать «Почему?», потому что хотите докопаться до первопричины.<\/li>\n<\/ol>\n<h2>Техника «Что? Кто? · Где? Когда? · Как? Почему?»<\/h2>\n<p>Техника хорошо работает, если вам нужно понять, кто те люди, что будут пользователями вашего продукта. Выяснить, что они делают, с какими проблемами сталкиваются.<\/p>\n<ul>\n<li>Что произошло? Что было самое сложное? Что делает человек? Кто ещё вовлечён? Что не устраивает в текущем решении?<\/li>\n<\/ul>\n<p>Узнать контекст. Где это происходит и когда.<\/p>\n<ul>\n<li>Где это происходило? Когда это происходило в последний раз?<\/li>\n<\/ul>\n<p>Как они это делают. Как решают задачи уже. Почему так.<\/p>\n<ul>\n<li>Как именно это произошло? Почему это было сложно? Как вы справились? Как часто повторяется? Поменялась ли решение проблемы со временем и почему?<\/li>\n<\/ul>\n<h2>Стадия: подготовка<\/h2>\n<p>Подготовка заключается в шести шагах:<\/p>\n<ol start=\"1\">\n<li>Понять цель интервью.<\/li>\n<li>Сделать кабинетное исследование по теме.<\/li>\n<li>Составить план: вопросы, ситуации, особенности.<\/li>\n<li>Сформулировать гипотезы.<\/li>\n<li>Задуматься, что ещё может пригодиться на интервью.<\/li>\n<li>Иметь 3 главных вопроса.<\/li>\n<\/ol>\n<h2>Стадия: интервью<\/h2>\n<p><b>Начало<\/b><\/p>\n<ul>\n<li>Расскажите, кто вы и зачем это интервью проводите.<\/li>\n<li>Обозначьте продолжительность.<\/li>\n<li>Скажите, что нет неправильных ответов. Вы здесь для того, чтобы узнать реальный опыт человека.<\/li>\n<li>Первые вопросы стоит делать вводными, чтобы расположить респондента к себе.<\/li>\n<\/ul>\n<p><b>Основная часть<\/b><\/p>\n<ul>\n<li>Говорите о жизни собеседника, а не о вашей идее.<\/li>\n<li>Спрашивайте о конкретных вещах, которые происходили в прошлом, а не о взглядах или мнениях на перспективу.<\/li>\n<li>Меньше говорите, больше слушайте.<\/li>\n<li>Используйте техники «Пять почему» и «Что? Кто? · Где? Когда? · Как? Почему?», чтобы копать глубже.<\/li>\n<li>Проявляйте дружелюбие и интерес. Будьте проще.<\/li>\n<li>Разговаривайте на одном языке<\/li>\n<li>Сохраняйте нейтральность вопроса. Не высказывайте своё мнение. Не оценивайте.<\/li>\n<li>Просите сравнивать.<\/li>\n<\/ul>\n<p><b>Окончание<\/b><br \/>\nПоблагодарите собеседника. Узнайте, не хочет ли человек что-то добавить или спросить у вас. Спросите контакты других людей, с которыми можно поговорить. Договоритесь о потенциальном продолжении.<\/p>\n<h2>Сложные ситуации: молчаливый респондент<\/h2>\n<p>Иногда респондент попадается совсем неразговорчивый. Тут следует рассказать о ценности этого разговора. Рассказать, кто вы и зачем это всё сейчас происходит. Так сказать, заинтересовать респондента. Отодвинуть цель в сторону и наладить личный контакт.<\/p>\n<h2>Сложные ситуации: неуверенный<\/h2>\n<p>Бывает респондент на каждый вопрос даёт размытые ответы. И да и нет, и так и сяк. Возможно, это даже очень хорошо. У респондента может быть разный опыт и тут стоит покапать глубже. Расспросите про каждый вариант в отдельности, почему да, почему нет. Попросите привести примеры всех ситуаций.<\/p>\n<h2>Сложные ситуации: говорливый<\/h2>\n<p>Респондент после вопроса уходит в сторону и дает совсем бесполезную информацию. Иногда таких даже невозможно остановить, а время интервью тикает. Тут важно умело останавливать респондента. Например, предлагать обсудить это позже. Прерывать нужно тоже аккуратно, старайтесь это делать «на вдохе».<\/p>\n",
            "date_published": "2019-10-07T14:58:15+00:00",
            "date_modified": "2022-01-11T08:46:56+00:00",
            "image": "https:\/\/ivanzviahin.by\/blog\/pictures\/interview.jpg",
            "_date_published_rfc2822": "Mon, 07 Oct 2019 14:58:15 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "120",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ivanzviahin.by\/blog\/pictures\/interview.jpg"
                ]
            }
        }
    ],
    "_e2_version": 3849,
    "_e2_ua_string": "E2 (v3849; Aegea)"
}