{
    "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:\/\/www.ivanzviahin.by\/blog\/user\/userpic-square@2x.jpg?1711411913",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/www.ivanzviahin.by\/blog\/tags\/ya\/",
    "feed_url": "https:\/\/www.ivanzviahin.by\/blog\/tags\/ya\/json\/",
    "icon": "https:\/\/www.ivanzviahin.by\/blog\/user\/userpic@2x.jpg?1711411913",
    "author": {
        "name": "Ivan Zviahin",
        "url": "https:\/\/www.ivanzviahin.by\/blog\/",
        "avatar": "https:\/\/www.ivanzviahin.by\/blog\/user\/userpic@2x.jpg?1711411913"
    },
    "items": [
        {
            "id": "182",
            "url": "https:\/\/www.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:\/\/www.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:\/\/www.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:\/\/www.ivanzviahin.by\/blog\/pictures\/Frame-8-3.png",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/proprocess-w-2.jpg",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/proprocess-3.jpg",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/Proprocess-3.jpg",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/remote\/youtube-TaMLUf3gISo-cover.jpg"
                ]
            }
        },
        {
            "id": "175",
            "url": "https:\/\/www.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:\/\/www.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:\/\/www.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:\/\/www.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:\/\/www.ivanzviahin.by\/blog\/pictures\/david-travis-WC6MJ0kRzGw-unsplash-2.jpg",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/Screenshot-2021-12-21-at-00.57.17-3.jpg"
                ]
            }
        },
        {
            "id": "173",
            "url": "https:\/\/www.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:\/\/www.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:\/\/www.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:\/\/www.ivanzviahin.by\/blog\/pictures\/compit.jpg"
                ]
            }
        },
        {
            "id": "172",
            "url": "https:\/\/www.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:\/\/www.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:\/\/www.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:\/\/www.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:\/\/www.ivanzviahin.by\/blog\/pictures\/audiiience.png",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/ps_1.jpg"
                ]
            }
        },
        {
            "id": "171",
            "url": "https:\/\/www.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:\/\/www.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:\/\/www.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:\/\/www.ivanzviahin.by\/blog\/pictures\/gomi-1.jpg"
                ]
            }
        },
        {
            "id": "151",
            "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/missia\/",
            "title": "Транслирую системное мышление и простоту через призму дизайна",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/drafts\/mission\/\">in english<\/a><\/p>\n<p>Это не просто что-то для красивого словца. Это вымученные и важные вещи, которые отражают меня через множественные попытки попробовать разное.<\/p>\n<h2>— Мам, а кто включает фонари на улице каждый день?<\/h2>\n<p>С детства я увлечен исследованием разных предметов, ищу систему в каждом решении, пытаюсь найти паттерны и думаю о всех вариантах исхода события. Это как-то вшито в моё ДНК. Я ценю людей, которые ищут систему в каждом шаге, думают как ее сделать отказоустойчивой и масштабируемой.<\/p>\n<p>Я иногда даже ловил себя на мысли, что транслировать системное мышление — мое предназначение, после спускался с небес и осознавал, что это не только мой плюс, но и минус. В простых задачах системный подход мешает мне принимать решения быстро. Для этого, я придумал <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/urovenprorabotki\/\">уровни проработки<\/a> задач и пользуюсь ими каждый день. Уверен, что словосочетание «системное мышление» точно заслуживает быть тут.<\/p>\n<h2>— Ах, вот почему иногда красивые вещи лучше работают<\/h2>\n<p>Для меня безумно важно как вещи выглядят и что люди чувствуют, когда ими пользуются. Эмоции, эмоции и еще раз эмоции. Я из тех людей, у которых резко меняется настроение в лучшую сторону, когда я нахожусь в красивом месте или окружен красивыми предметами. Я стараюсь транслировать <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/krasota\/\">красоту и эстетику<\/a> в своей работе настолько, насколько могу.<\/p>\n<h2>— Вань, ну не усложняй!<\/h2>\n<p>Эту фразу я слышал часто от своего менеджера в начале карьеры. Умение сделать сложную штуку просто — дорогого стоит. И самое страшное, этому нигде не учат. Стараюсь найти золотую середину между «я тут сейчас все объясню и подпишу» и «давайте уберем всё лишнее и сделаем просто». Бесконечно важно снижать когнитивное сопративление и дать человеку столько информации, сколько ему необходимо в данный момент, не капли более.<\/p>\n<h2>Ценности<\/h2>\n<p>Простота · красота · коллаборация · уважение · правда · обучение. Если их нет, я чувствую себя дискомфортно. Направления, которые меня увлекают: коммуникация, автомобили, путешествия, музыка, вино.<\/p>\n<h2><a href=\"https:\/\/ivanzviahin.by\/blog\/all\/principi\/\">Принципы<\/a><\/h2>\n<p>Предприниматель · бумажки в урну · фокус · как есть · айсберг · эмпатия · инициатива · открытость · ответственность · идеальный мир · не усложнять.<\/p>\n<h2><a href=\"http:\/\/ivanzviahin.by\/cv-zviahin.pdf\">CV,PDF ↓<\/a><\/h2>\n<h2>Публикации и упоминания<\/h2>\n<p>Дизайн-комьюнити · <a href=\"https:\/\/youtu.be\/Brz_XeX-wAQ?si=XVf8eEeGTN63QwEO\">Повысили CTR на 32% почти без новой разработки.<\/a><\/p>\n<p>habr.com · <a href=\"https:\/\/habr.com\/ru\/companies\/tinkoff\/articles\/743534\/\">Как сформировать правильное понимание задачи в продуктовом дизайне.<\/a><\/p>\n<p>whydesign.io · <a href=\"https:\/\/www.instagram.com\/p\/CmTbKpqthe6\/?igshid=NWQ4MGE5ZTk=\">Дизайн это возможность популизировать системное мышление и простоту.<\/a><\/p>\n<p>#FFDD2D design conf · <a href=\"https:\/\/www.youtube.com\/embed\/KafkVtiT1-w\">Как внедрить дизайн-процесс и заметно улучшить результаты.<\/a><\/p>\n<p>Design Spot <a href=\"https:\/\/medium.com\/p\/8ac4d9add363\">Не проводил интервью с пользователем — не дизайнер.<\/a><\/p>\n<p>Натив <a href=\"https:\/\/www.youtube.com\/watch?v=rzm8GxdZETc\">Про UX\/UI и не только. Интервью с Иваном и Алексеем.<\/a><\/p>\n<p>Независимый журнал Бюро «Кто студент» <a href=\"https:\/\/ktostudent.ru\/vanja-zvjagin\/\">Иван Звягин. Просто делай максимум.<\/a><\/p>\n<p>Transit Maps <a href=\"http:\/\/transitmap.net\/post\/163696560175\/minsk-birman\">Absolutely beautiful map.<\/a><\/p>\n<p>vc.ru <a href=\"https:\/\/vc.ru\/flood\/34836-vse-deystviya-v-biznese-dolzhny-byt-krasivymi\">Все действия в бизнесе должны быть красивыми.<\/a><\/p>\n<p>vc.ru <a href=\"https:\/\/vc.ru\/marketing\/75253-50-materialov-chtoby-delat-internet-marketing-samostoyatelno?\">50 материалов, чтобы делать интернет-маркетинг самостоятельно.<\/a><\/p>\n<p>Skillbox <a href=\"https:\/\/skillbox.ru\/media\/design\/vybiraem-respondentov-dlya-uxissledovaniya\/\">«Кого спросить?»: выбираем респондентов для UX-исследования.<\/a><\/p>\n<p>Skillbox <a href=\"https:\/\/skillbox.ru\/media\/design\/ask-expert-text-tube-map\/\">Спроси эксперта: как на схеме метро сделать читаемые подписи?<\/a><\/p>\n<p>RAUX 2020 <a href=\"https:\/\/youtu.be\/8Eek--ZCBuI?t=944\">Вёрстка веб-страниц может быть компетенцией дизайн-команды.<\/a><\/p>\n<p>Marketing.by <a href=\"https:\/\/marketing.by\/keysy\/ramamba-kharu-avebay-poyushchiy-kokos-v-reklame-av-by-zastavit-vas-krutit-rolik-na-povtore\/\">A singing coconut in an av ad.by will make you turn the video on repeat<\/a><\/p>\n<p>Marketing.by <a href=\"https:\/\/marketing.by\/keysy\/aida-pioneer-prodolzhila-istoriyu-s-karpom-v-novoy-reklamnoy-kampanii-dlya-av-by\/?fbclid=IwAR3W1lycXuCdjk9Tpd60DU0z-lzAWhP_oWL7s3m3NiZcZ8v1d0I-1j-aMLQ\">AIDA Pioneer continued the story with carp in a new advertising campaign for av.by.<\/a><\/p>\n<p>Marketing.by <a href=\"http:\/\/marketing.by\/keysy\/av-by-pokazal-kak-mashina-prevrashchaetsya-v-dengi-\/\">av.by showed how the car turns into money.<\/a><\/p>\n<p>Marketing.by <a href=\"https:\/\/marketing.by\/keysy\/dazhe-karp-znaet-novaya-reklamnaya-kampaniya-av-by-gde-rybu-ozvuchil-izvestnyy-akter-dublyazha\/\">Even fish knows: the new av.by advertising campaign.<\/a><\/p>\n<p>Marketing.by <a href=\"http:\/\/marketing.by\/keysy\/istoriyu-zhizni-belarusov-cherez-ikh-avtomobili-pokazali-v-reklamnoy-kampanii-av-by\/\">The history of the life of Belarus through their cars.<\/a><\/p>\n<p>BTW <a href=\"https:\/\/btw.by\/kejsy\/33606-kejs-aida-pioneer-av-by-prevrashhaet-mashinu-v-dengi.html\">Кейс AIDA Pioneer: av.by превращает машину в деньги.<\/a><\/p>\n<p>BTW <a href=\"https:\/\/btw.by\/kejsy\/27043-garazh-zhizni-v-reklamnoj-kampanii-av-by-ot-aida-pioneer.html?fbclid=IwAR1BQo65D6MbIxZeHPEQ2_NsmnXgpC_AqkqvV0M01YM1TvipsSBTAa0Qavk\">Гараж жизни в рекламной кампании av.by от AIDA Pioneer.<\/a><\/p>\n<p>BTW <a href=\"http:\/\/btw.by\/kejsy\/733-skhema-minskogo-metro-takaya-chto-drugie-goroda-zaviduyut.html\">Схема минского метро, такая, что другие города завидуют.<\/a><\/p>\n<p>Probusiness.io <a href=\"https:\/\/probusiness.io\/marketing\/6730-uniki-vyrosli-pochti-vtroe-auditoriya-prilozheniy-v-8-raz-keys-o-reklamnoy-kampanii-av-by.html\">Аудитория приложений выросла в 8 раз. Кейс о рекламной кампании av.by.<\/a><\/p>\n<p>Onliner <a href=\"https:\/\/realt.onliner.by\/2017\/07\/31\/metro-128\">Белорусские дизайнеры разработали новую схему минского метро.<\/a><\/p>\n<p>Canva.com <a href=\"https:\/\/www.canva.com\/ru_ru\/obuchenie\/50-sovetov-po-sozdaniyu-portfolio-dizajnera\/\">Портфолио дизайнера – советы, шаблоны и примеры.<\/a><\/p>\n<p>Realt.by <a href=\"https:\/\/realt.by\/news\/article\/24146\/?fbclid=IwAR0FOHFb18YL0hAiMX8DyqPO6mYStXocvJFlFvnLx6AvzhtYCVnnQ1TNPEs\">Дизайнер разработал новую схему метро в Минске.<\/a><\/p>\n<p>ТR <a href=\"https:\/\/tr.ru\/news\/2471-shema-minskogo-metro-ot-ili-birmana-stala-predmetom-sporov-rossiyan-i-belorusov\">Схема минского метро от Ильи Бирмана стала предметом споров россиян и белорусов.<\/a><\/p>\n<p>Village <a href=\"http:\/\/www.the-village.me\/village\/city\/news-city\/262187-birman-metro\">Илья Бирман разработал схему минского метро с ошибками.<\/a><\/p>\n<p>Village <a href=\"http:\/\/www.the-village.me\/village\/city\/situation-city\/262193-birman-explain\">Илья Бирман исправит ошибки в схеме минского метро.<\/a><\/p>\n<p>Citydog <a href=\"https:\/\/citydog.by\/post\/zaden-shema-metro\/\">Designers have developed an alternative scheme of the Minsk metro.<\/a><\/p>\n<p>International Science Forum. <a href=\"http:\/\/www.conf.art-gzhel.ru\">Эффективный способ классификации экома.<\/a><\/p>\n<p>Communication in Social Human Knowledge, Economics, & Education. <a href=\"http:\/\/elib.bsu.by\/handle\/123456789\/151651\">Материалы IV Международной научно-практической конференции. Инфографика, как эффективный инструмент контент-маркетинга.<\/a><\/p>\n<p>KYKY <a href=\"https:\/\/kyky.org\/special-project\/proveryaem-teoriyu-sapozhnik-bez-sapog-na-chyom-ezdyat-lyudi-kotorye-delayut-avtomobilnyy-sayt\">What do people who make a car site drive.<\/a><\/p>\n<p>KYKY <a href=\"http:\/\/kyky.org\/news\/dizaynery-narisovali-alternativnyy-variant-shemy-minskogo-metro\">Designers have drawn an alternative version of the Minsk metro scheme.<\/a><\/p>\n",
            "date_published": "2021-08-14T15:14:06+00:00",
            "date_modified": "2023-11-27T18:44:22+00:00",
            "_date_published_rfc2822": "Sat, 14 Aug 2021 15:14:06 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "151",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "149",
            "url": "https:\/\/www.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:\/\/www.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:\/\/www.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:\/\/www.ivanzviahin.by\/blog\/pictures\/Frame-5.png",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/Frame-5-1.png"
                ]
            }
        },
        {
            "id": "145",
            "url": "https:\/\/www.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:\/\/www.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:\/\/www.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:\/\/www.ivanzviahin.by\/blog\/pictures\/checklist.png"
                ]
            }
        },
        {
            "id": "134",
            "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/situacionnoe-liderstvo\/",
            "title": "Ситуационное лидерство",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/drafts\/situational-leadership\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.ivanzviahin.by\/blog\/pictures\/leadership-1.png\" width=\"1590\" height=\"628\" alt=\"\" \/>\n<\/div>\n<p>Cитуационное лидерство — это стиль управления людьми, предполагающий использование одного из четырех стилей управления в зависимости от ситуации и уровня развития сотрудников по отношению к задаче. Согласно данной модели существуют 4 стиля лидерства и 4 степени развития сотрудника.<\/p>\n<h2>4 стиля управления<\/h2>\n<p>Первый — директивный стиль, или лидерство путём приказа. Высокая ориентация на задачу и низкая на людей. Лидер дает конкретные указания и следит за выполнением заданий.<\/p>\n<p>Второй — наставнический стиль, или лидерство путём продажи идей. Совмещение высокой ориентации на задачу и на людей. Руководитель продолжает давать указания и следить за выполнением заданий, но при этом объясняет принятые решения сотруднику, предлагает высказывать свои идеи и предложения.<\/p>\n<p>Третий — поддерживающий стиль, или лидерство путём участия в организации процесса работы. Высокая ориентация на людей и низкая на задачу. Лидер поддерживает и помогает своим сотрудникам в их работе. Лидер участвует в процессе принятия решений, но решения принимаются в большей степени подчиненными.<\/p>\n<p>Четвертый — делегирующий стиль. Низкая ориентация и на людей, и на задачу. Лидер передает полномочия, права и ответственность другим членам команды.<\/p>\n<h2>4 степени развития сотрудника<\/h2>\n<p>Первый — не способен, но настроен. Сотрудник, находящийся на этом уровне, высоко мотивирован, демонстрирует много энтузиазма, но владеет только базовыми знаниями и навыками.<\/p>\n<p>Второй — не способен и не настроен. У сотрудника, находящегося на этом уровне, обычно уже есть определенные знания и навыки, однако такой сотрудник по какой-то причине демотивирован.<\/p>\n<p>Третий — способен, но не настроен. Сотрудник на этом уровне имеет знания и хорошо развитые навыки для выполнения задачи, однако его уверенность в себе и своих силах неустойчива, что может влиять на мотивацию.<\/p>\n<p>Четвертый — способен и настроен. Сотрудник на этом уровне демонстрирует мастерское владение навыками, необходимыми для выполнения данного задания. Помимо этого он мотивирован и уверен в себе.<\/p>\n<h2>Итого<\/h2>\n<p>10% знаний, 100% мотивация — директивный стиль.<br \/>\n30% знаний, 10% мотивации — наставнический стиль.<br \/>\n70% знаний, 40% мотивации — поддерживающий стиль.<br \/>\n100% знаний, 100% мотивации — делегирующий стиль.<\/p>\n",
            "date_published": "2020-01-23T20:30:53+00:00",
            "date_modified": "2022-04-27T19:58:12+00:00",
            "image": "https:\/\/www.ivanzviahin.by\/blog\/pictures\/leadership-1.png",
            "_date_published_rfc2822": "Thu, 23 Jan 2020 20:30:53 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "134",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/leadership-1.png"
                ]
            }
        },
        {
            "id": "120",
            "url": "https:\/\/www.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:\/\/www.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:\/\/www.ivanzviahin.by\/blog\/pictures\/interview.jpg"
                ]
            }
        },
        {
            "id": "115",
            "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/urovenprorabotki\/",
            "title": "Уровень проработки",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/drafts\/development-levels\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.ivanzviahin.by\/blog\/pictures\/devlevels-1.png\" width=\"1590\" height=\"628\" alt=\"\" \/>\n<\/div>\n<p>Я бы хотел рассказать о решении одной важной проблемы в продуктовой команде. Проблема — мы делаем задачи слишком долго. Одна из причин — слишком глубокий уровень проработки каждой. Как бы времени у нас совсем нет, а функциональность урезать нельзя. Остается только снизить уровень проработки. Мы решили понижать его не для всех задач, а только для некоторых.<\/p>\n<p>Пользовательские сценарии в любом продукте можно разделить на три уровня. Уровень первый — сценарии, которыми люди пользуются чуть ли не каждый день. Мы такие сценарии назвали магистральными. Второй — важные, но нужные не часто. Эти сценарии назвали промежуточными. Третий — скорее исключения, это как раз те сценарии про которые обычно совсем забывают.<\/p>\n<h2>Уровень 1<\/h2>\n<p>Это самые важные сценарии, которые пользователь использует каждый день. Например, поиск товаров в магазине или чтение новостей в журнале. Проработка таких сценариев должна быть на высочайшем уровне. Тут необходимо потратить время на проверки и тестирование. Продумать все исключения, сделать анимации и хоткеи. Таких сценариев обычно не много.<\/p>\n<h2>Уровень 2<\/h2>\n<p>Это сценарии важные, но при этом ими пользуются не так часто. Например, настройки профиля. В таких сценариях нужно не меньше времени уделить проектированию и проверкам, но можно более хладнокровно относиться к ошибкам. Тут учитывать хоткеи уже нет смысла и если какой-то сценарий приведет к ошибке — это не так страшно, как в первом случае. Говорят, что именно поэтому в автомобиле салон сделан максимально комфортным, по сравнению с моторным отсеком. Таких сценариев обычно намного больше, чем первых.<\/p>\n<h2>Уровень 3<\/h2>\n<p>А вот эти сценарии самые популярные обычно у программистов. Есть четкое ощущение, что ими можно пренебречь в проектировании. Это не значит, что про них можно просто забыть и все. Их нужно обрабатывать, но делать это — максимально грубо. Например, представьте, вы открываете одну страницу в двух вкладках браузера и в одной из них делаете какое-то действие, которое меняет статус чего-то. А потом идёте в другую и делаете это же действие, как должна повести себя система? От способности обрабатывать исключения зависит лишь качество кода, а вот успех продукта находится в первую двух уровнях.<\/p>\n<h2>Вывод<\/h2>\n<p>Никому не нужен магазин с идеально продуманным сценарием добавления товара в «Избранное» в двух вкладках браузера, когда поиск товаров работает плохо и непонятно.<\/p>\n",
            "date_published": "2019-09-24T17:22:15+00:00",
            "date_modified": "2022-04-27T19:57:23+00:00",
            "image": "https:\/\/www.ivanzviahin.by\/blog\/pictures\/devlevels.png",
            "_date_published_rfc2822": "Tue, 24 Sep 2019 17:22:15 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "115",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/devlevels.png",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/devlevels-1.png"
                ]
            }
        },
        {
            "id": "103",
            "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/principi\/",
            "title": "Принципы",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/drafts\/principles\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.ivanzviahin.by\/blog\/pictures\/Frame-2.png\" width=\"2386\" height=\"1085\" alt=\"\" \/>\n<\/div>\n<p>Принципы помогают принимать решения. Какие-то я подсмотрел, некоторые придумал сам.<\/p>\n<h2>Предприниматель<\/h2>\n<p>Сравниваю затраченное время с получаемой пользой. Делаю выводы, анализирую. Не занимаюсь самовыражением, а ищу решение, которое стремиться быть дешёвым, но при этом несёт максимальную пользу. Дорожу ресурсами компании.<\/p>\n<h2>Бумажки в урну<\/h2>\n<p>Чем больше времени дизайнер уделяет макету или прототипу, тем тяжелее ему от него отказаться. Я делаю дешевые прототипы и маленькие итерации в макетах, чтобы легче отказываться от своих решений, если они не работают.<\/p>\n<h2>Фокус<\/h2>\n<p>Лучше потратить больше времени на разбор задачи и предложить крепкое решение, чем решать непонятно что. В среднем около половины времени на задачу занимает её разбор.<\/p>\n<h2>Как есть<\/h2>\n<p>Простой способ как снизить свой уровень тревоги или важности чего-то — представить, что всё вокруг происходящее это компьютерная игра и у меня есть какой-то определенный ресурс на день. Первое, я не могу сделать больше, чем могу сделать. Второе, я так намного проще отношусь к неудачам, это помогает двигаться вперед. Впереди ещё будет много разных возможностей.<\/p>\n<h2>Айсберг<\/h2>\n<p>Обычно когда даёшь оценку, прикидываешь время только на те задачи, которые понятны и видны сразу. Но примерно столько же задач появляются по ходу решения, которые, так сказать, под водой. Простой способ — умножай видимое время на два, тогда оно будет более правдивое. Но видимая зона зависит от опыта, поэтому у каждого дизайнера свой коэффициент.<\/p>\n<h2>Эмпатия<\/h2>\n<p>Беда, если дизайнер решает свою проблему, а не <a href=\"https:\/\/ivanzviahin.by\/blog\/all\/goal\/\">проблему пользователя или бизнеса.<\/a> Я стараюсь вселиться в голову человека, задачу которого решаю.<\/p>\n<h2>Инициатива<\/h2>\n<p>Банально, но важно. Никто не запланирует мою неделю лучше меня. Никто не заставляет и не напоминает мне про задачи. Никто не разжёвывает требования к задаче. Никто не расскажет о технических ограничениях в подробностях сам.<\/p>\n<h2>Открытость<\/h2>\n<p>Не держу в себе и не умалчиваю. Говорю, если чувствую, что моё виденье помогает достигнуть цель.<\/p>\n<h2>Ответственность<\/h2>\n<p>Если пообещал, значит должен сделать, поставить в приоритет. Если не успеваю, обязан предупредить как можно раньше того, кто ждет.<\/p>\n<h2>Идеальный мир<\/h2>\n<p>Сначала пробую откинуть все ограничения и сгенерировать идеальных решений. Чтобы увидеть пару финальных точек в будущем, чтобы к ним потом стремиться. Часто бывает, что эти «идеальные решения» могут быть просты в реализации.<\/p>\n<h2>Не усложнять<\/h2>\n<p>Стремлюсь решить задачу просто, а потом подумать как можно добавить функциональности. «Идеальный мир» нашел, далее задумался, как можно сделать это прямо сейчас, но без потери в качестве. Если полное идеальное решение — это торт, то в первой версии надо сделать кекс с вишенкой.<\/p>\n",
            "date_published": "2019-03-20T12:12:24+00:00",
            "date_modified": "2022-04-11T21:21:10+00:00",
            "image": "https:\/\/www.ivanzviahin.by\/blog\/pictures\/principles.png",
            "_date_published_rfc2822": "Wed, 20 Mar 2019 12:12:24 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "103",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/principles.png",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/Frame-2.png"
                ]
            }
        }
    ],
    "_e2_version": 3849,
    "_e2_ua_string": "E2 (v3849; Aegea)"
}