From a314897f1215148a40d3886228dd909ed90f954c Mon Sep 17 00:00:00 2001 From: Ruslan Sharipov Date: Sat, 23 Apr 2022 13:57:34 +0300 Subject: [PATCH] update --- .DS_Store | Bin 0 -> 8196 bytes .hugo_build.lock | 0 assets/indices/contentIndex.json | 602 +++++ assets/indices/linkIndex.json | 2205 +++++++++++++++++ content/.DS_Store | Bin 0 -> 6148 bytes notes/.DS_Store | Bin 0 -> 10244 bytes notes/page/.DS_Store | Bin 0 -> 6148 bytes resources/_gen/.DS_Store | Bin 0 -> 6148 bytes ...s_c25f88f67e8e33f20619c76cbf49f33c.content | 1 + ...scss_c25f88f67e8e33f20619c76cbf49f33c.json | 1 + ...s_c25f88f67e8e33f20619c76cbf49f33c.content | 1 + ...scss_c25f88f67e8e33f20619c76cbf49f33c.json | 1 + ...s_c25f88f67e8e33f20619c76cbf49f33c.content | 1 + ...scss_c25f88f67e8e33f20619c76cbf49f33c.json | 1 + ...s_c25f88f67e8e33f20619c76cbf49f33c.content | 1 + ...scss_c25f88f67e8e33f20619c76cbf49f33c.json | 1 + ...s_c25f88f67e8e33f20619c76cbf49f33c.content | 1 + ...scss_c25f88f67e8e33f20619c76cbf49f33c.json | 1 + ...s_c25f88f67e8e33f20619c76cbf49f33c.content | 1 + ...scss_c25f88f67e8e33f20619c76cbf49f33c.json | 1 + ...s_c25f88f67e8e33f20619c76cbf49f33c.content | 1 + ...scss_c25f88f67e8e33f20619c76cbf49f33c.json | 1 + ...s_c25f88f67e8e33f20619c76cbf49f33c.content | 1 + ...scss_c25f88f67e8e33f20619c76cbf49f33c.json | 1 + 24 files changed, 2823 insertions(+) create mode 100644 .DS_Store create mode 100644 .hugo_build.lock create mode 100644 assets/indices/contentIndex.json create mode 100644 assets/indices/linkIndex.json create mode 100644 content/.DS_Store create mode 100644 notes/.DS_Store create mode 100644 notes/page/.DS_Store create mode 100644 resources/_gen/.DS_Store create mode 100644 resources/_gen/assets/scss/iziodize/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.content create mode 100644 resources/_gen/assets/scss/iziodize/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.json create mode 100644 resources/_gen/assets/scss/iziodize/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.content create mode 100644 resources/_gen/assets/scss/iziodize/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.json create mode 100644 resources/_gen/assets/scss/iziodize/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.content create mode 100644 resources/_gen/assets/scss/iziodize/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.json create mode 100644 resources/_gen/assets/scss/iziodize/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.content create mode 100644 resources/_gen/assets/scss/iziodize/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.json create mode 100644 resources/_gen/assets/scss/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.content create mode 100644 resources/_gen/assets/scss/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.json create mode 100644 resources/_gen/assets/scss/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.content create mode 100644 resources/_gen/assets/scss/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.json create mode 100644 resources/_gen/assets/scss/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.content create mode 100644 resources/_gen/assets/scss/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.json create mode 100644 resources/_gen/assets/scss/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.content create mode 100644 resources/_gen/assets/scss/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.json diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..03b727c619cdf41bda84b3618c39fef62d72436c GIT binary patch literal 8196 zcmeHMJx?1!5S?`h{-Cj_T%_0<2`LomQd}%Ufkb2pB~2Qz9XTL7XMt&>D`-H9l>dNe zEhT~?b@ERl?-o1}d5h7*Q+I^>;nVqM1AA55qBGo<_Y!J1GsD{qiT)|M# z*v>uIDsDyt72=7ebUYev?DpgFBHA4h*IQ04`zLG#sN2FfrO;8ASn6Ag_SN)H3bUF@EoJ^?SAZD{CLeolb8Q_b^|( zc>VRJ*7*4!E z1;6`z1D^Dpc~-$QrjLdx#_)?riyufC51-rWyKi%DIj;q)a<7n&wtNo2W&pkVdBu{? zhEL$(^O=20wW?wTZyjHya<7oj7v@u;!|ZumKbz0{x!2Cq+$P4)n6-s@x}4`J*v958 zgjY#@`!uxrIqAjqTz@a#&s^*g1!uym7iW1H3vBZrAayMfF8 z&uT~$1s+d;KL2@BfcSP%?`GqQHYIpq4tjoi@_gtvR2MYi*6bht7@t5{o7T jgDJ;>{PxTC^bbQEYd04;Of15JCNBa;1{p+wzpB6;nh^>5 literal 0 HcmV?d00001 diff --git a/.hugo_build.lock b/.hugo_build.lock new file mode 100644 index 000000000..e69de29bb diff --git a/assets/indices/contentIndex.json b/assets/indices/contentIndex.json new file mode 100644 index 000000000..893cddfbe --- /dev/null +++ b/assets/indices/contentIndex.json @@ -0,0 +1,602 @@ +{ + "/": { + "title": "Home", + "content": "Это хранилище конспектов по продуктовому дизайну.\n\n[Product](Product/Product.md)\n[Design](Design/Design.md)", + "lastmodified": "2022-04-23T12:45:42.669230232+03:00", + "tags": null + }, + "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7": { + "title": "Анализ", + "content": "Здесь собраны ссылки по методам и артефактам фазы анализа в дизайне:\n\n### После исследования\n\n* [Persona](Persona.md)\n* [Informational Architecture](Informational%20Architecture.md)\n\n### Подготовить к разработке\n\n* [User Story](User%20Story.md)\n* [Use case](Use%20case.md)\n* [User Story Mapping](User%20Story%20Mapping.md)\n* [JTBD](JTBD.md)\n\n### Приоритезация\n\n* [RICE и ICE](RICE%20%D0%B8%20ICE.md)\n* [KANO](KANO.md)\n* [Severity analysis](Severity%20analysis.md)\n\n#### Понять ситуацию и найти боли/точки роста\n\n* [CJM](CJM.md)", + "lastmodified": "2022-04-23T12:45:42.663818987+03:00", + "tags": null + }, + "/Design/Analysis/CJM": { + "title": "CJM", + "content": "#### Что надо знать\n\n* Артефакт для виз. анализа всего пути клиента в продукте в точках контакта.\n* Точка контакта/канал - ситуации, места и интерфейсы, где клиент взаимодействует с сервисом. Например, сайт для десктопа или мобилки, моб. приложение, тв-приставка, смс, пуш-уведомления, почта, звонки, реклама по тв, гугл, офис компании, листовки, билборды и т.д.\n* Цель артефакта показать как клиент выполняет задачи и достигает цели в продукте, чтобы подумать над тем как улучшить этот путь.\n* Клиент тот, кто **покупает** продукт для юзеров. Юзер тот, кто **использует** продукт.\n* Выглядит как угодно. Имхо: лучше таблица.\n* Создается для понимания разницы между тем как клиенты решают задачи **сейчас (cjm as is)**, и тем как они это могут делать **в идеале (cjm to be)**.\n* Помогает рассмотреть нелинейность работы в продукте.\n* Делается регулярно. Хотя бы раз в полгода.\n* Делается на основе исследований.\n* USM описывает фичи продукта и как эти фичи разбить на релизы. CJM описывает как в действительности работает система со всеми косяками.\n\n#### Зачем использовать?\n\n* Понять как поместить клиента в цикл продукта.\n* Понять ситуацию, накинуть идеи для улучшения воронки продаж.\n* Понять как улучшить опыт клиента в каждой из точек контакта.\n* Понять как повысить Retention клиентов для повторных покупок.\n\n#### Как строить\n\n* Ставится цель. Зачем и почему нужна карта:\n * Для какой персоны, сегмента или jtbd? \n * Выбрать: делать карту текущего опыта со всеми косяками (cjm as is) или делать карту идеального пути со всеми исправлениями (cjm to be).\n* Провести исследование: интервью, cusdev, догфуддинг, данные из колл-центра, аналитики, службы поддержки, предыдущие исследования, привлекать коллег.\n* Расписать весь опыт клиента на карту: по воронке, по шагам как удобно.\n* Расписать действия клиента, точки контакта, мысли, метрики, время выполнения или степень критичности шага в общем исходить из целей карты и типа продукта. Данные по мыслям, метрикам, времени и т.д брать из исследований.\n* После карты выписываются проблемы на каждом шагу.\n* В финале делаются выводы и накидываются гипотезы.\n\n#### Советы\n\n* Не привязываться к картам. Переделывать и выкидывать - норма.\n* Занизить ожидания. Это артефакт, а не волшебная таблетка.\n* Каждый автор будет рисовать свой cjm, не парься.\n* Если сценарий и процесс очень сложные или вообще показать надо больше интерфейс, то используй userflow или service blueprint\n* service blueprint - это как cjm, но отражает дополнительно действия бизнеса, т.е все то, что происходит вне интерфейса. Пример: чтобы вернуть деньги за отмененный заказ, сотрудник службы поддержки оформляет заявку на отдел взаимодействия с продавцами. Отдел взаимодействия проверит заказ по статусу и связывается с продавцом, чтобы выяснить причину или просто скинет уведомление продавцу о возврате. Затем произойдет возврат, а затем уже будет уведомление клиенту о том, что поступили деньги от банка. Клиент же нажал 1 кнопку.\n* Первую точку для работы выбирать ту, где можно прогнозировать больший эффект от улучшения или ту, где есть большой отток клиентов, или же где быстрее всего проверить гипотезу.\n* Можно использовать маркетинговые воронки: aarrr, aida, acca, dibaba, dagmar, vips.\n\n**Ссылки:**\n[Отличная статья](https://copylove.medium.com/customer-journey-map-8a5ac61d6b5e)\n[30 ошибок в создании CJM](https://hardclient.com/customer-journey-map-pitfalls)\n[CJM и малый/средний бизнес](https://vc.ru/life/198273-kak-cjm-pomogaet-poluchat-insayty-dlya-malogo-i-srednego-biznesov)\n[Гайд по разработке](https://vc.ru/services/126126-gayd-po-razrabotke-karty-klientskogo-opyta-cjm-na-primere-servisa-dostavki)\n[Краткий гайд по CJM](https://dkapaev.medium.com/%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%B8%D0%B9-%D0%B3%D0%B0%D0%B9%D0%B4-%D0%BF%D0%BE-cjm-19667b50fd7a)\n[Еще мнение по CJM](https://iq-adv.ru/blog/customer-journey-map/)\n[Пример CJM 1](https://miro.com/app/board/o9J_ky1F_TM=/)\n[Пример CJM 2](https://miro.com/app/board/o9J_lebdKeA=/)\n[Пример CJM 3](https://miro.com/app/board/o9J_ktE_tjU=/)\n[Пример CJM 4](https://miro.com/app/board/o9J_kxBDJDQ=/)\n[Пример CJM 5](https://miro.com/app/board/o9J_ky1F_TM=/?moveToWidget=3074457346388827401)\n[История одной CJM: как собрать данные и что с ними делать, Алёна Егорова, UX-дизайнер QIWI](https://www.youtube.com/watch?feature=youtu.be\u0026v=OTiHLq9RhAA\u0026app=desktop)\n[MegaFon CJM meet up](https://www.youtube.com/watch?v=DupJ9JhmaW8) (первые 2 выступления норм)\n[Почему не надо использовать CJM](https://medium.com/@shahrsays/dont-make-a-journey-map-9-archetypes-of-good-bad-and-how-to-decide-what-to-use-d65abd30ec6f)\n[Связка cjm и service blueprint](https://medium.com/wonderfull-lab/%D0%BA%D0%B0%D0%BA-%D0%BF%D0%B5%D1%80%D0%B5%D0%B9%D1%82%D0%B8-%D0%BE%D1%82-cjm-%D0%BA-service-blueprint-5d7ab7bdc08e)", + "lastmodified": "2022-04-23T12:45:42.669438822+03:00", + "tags": null + }, + "/Design/Analysis/Empathy-map": { + "title": "Empathy map", + "content": "«У меня покупают или будут покупать мужчины от 20 до 40, которые живут в Москве». \n\nПотрясающе... мало. Пришло время подробнее изучить твою аудиторию. Мы рекомендуем для этой задачи использовать карту эмпатии. Она позволяет описать подробный портрет целевой аудитории: понять, что движет человеком, что его окружает, что является для него ключевыми болями и сложностями. \n\n**Как заполнять карту:**\n\n1. Соберитесь командой на мозговой штурм. Если собираться не с кем, сделай всё в одиночку, но не забудь показать команде, когда она появится.\n1. Возьмите один из ваших сегментов аудитории и кратко опишите его (составьте общий собирательный образ аудитории).\n1. Опишите, какое решение вы хотите предложить данному сегменту или какую потребность вы решаете.\n1. Накидайте ответы на все вопросы, описанные в карте. \n **Важно!** Отвечайте на вопросы применительно к вашему продукту.\n1. Изучите информацию из открытых источников и дополните карту.\n\n![empathy-map.png](img/empathy-map.png)\n\nhttps://mk.digital-dolina.ru/modul-sartan?utm_source=startuppack\u0026utm_medium=core\u0026utm_campaign=sartan", + "lastmodified": "2022-04-23T12:45:42.664165331+03:00", + "tags": null + }, + "/Design/Analysis/Informational-Architecture": { + "title": "Informational Architecture", + "content": "---\n\n#### Что надо знать\n\n* Это о том, как структурировать информацию так, чтобы она была понятной, полезной и давала возможность сделать то, зачем пришел пользователь быстро. \n\n* Все артефакты только для тебя и команды, чтобы понять структуру будущего или существующего продукта. Юзер не видит IA.\n* Плохая IA это когда в продукте слишком много шагов, чтобы выполнить простую задачу. Юзеры не понимают названий, плохие результаты в поиске или когда юзеры теряются в продукте. \n\n#### Что нужно сделать до рисования ИА?\n\n* Поговорить с заказчиком, командой и, очевидно, провести интервью с пользователями\n* Затем выделить и выписать список топ задач, самых часто используемых, повторяющихся или желаемых, если продукт еще не существует. Часто, если продукт уже есть или намечен редизайн существующего продукта, то нужно провести аудит контента и его инвентаризацию, то есть написать весь список компонентов проекта. В этот список обычно попадают: пункты меню, подкатегории, заголовки, подзаголовки, мета-информация, кто автор контента, если он есть, изображения, аудио, видео и другие форматы, которые уже используются в продукте и где это все находится, то есть ссылки. Этот список помогает определить основные компоненты, из которых состоит продукт, чтобы ты, как дизайнер, смог этот контент как-то расположить на макете, потому что это проще и быстрее, чем менять постоянно сам макет. Выглядит это как-то так. Есть табличка с колонками названия страницы, название страницы в меню, если есть то укажи подменю, также укажи в отдельной колонке куда ведет - дальше на твой сайт вглубь или на внешний ресурс, укажи ссылку, какие мета-данные есть на странице, тип контента, укажи автора если есть, когда последний раз обновляли страницу, какие компоненты дизайна используются и опционально можно указать комментарий, в общем, тут нет шаблона. Делай так, как считаешь правильным и вписывай то, что считаешь нужным\n* После попроси пользователей проголосовать за выделенные задачи, то есть что из всего списка самое важное, затем:\n* Проведи открытую карточную сортировку, это простой метод, если коротко, где ты заранее подготавливаешь список контента продукта, например, если это сервис по доставке продуктов, то ты можешь выписать слова банан, виноград, яблоки, и эти слова должны быть на каких-нибудь бумажных листочках или карточках,  ты даешь эти карточки и просишь пользователей сгруппировать их и назвать получившиеся группы на усмотрение пользователей, чтобы понять паттерны того как пользователи думают, группируют и ищут инфу, когда будут искать информацию в твоем продукте. С помощью открытой сортировки ты узнаешь новое.\n* Или же ты проверяешь эти же идеи с закрытой карточной сортировкой, опять же, если коротко, ты даешь те же карточки, но добавляешь к ним карточки с надписями заранее подготовленных категорий, которые юзеры соотносят друг с другом и думают как бы они расположили контент в эти категории, если бы искали инфу исходя из того что уже есть, выстраивая структуру продукта самостоятельно из заранее определенных терминов, категорий и в целом рамок. С помощью закрытой сортировки ты подтверждаешь предположения.\n* И в финале ты рисуешь ИА. С помощью чего и каким способом визуализировать, сейчас разберем.\n\n#### Что рисовать?\n\n* Самое простое - карта сайта. Это иерархическая схема, которая отражает все страницы сайта или экраны приложения, а также и то, как эти экраны связаны. \n* Flowcharts (блок-схемы) - разные способы визуализации информации в виде потока выборов, которые ведут к результату. Результат - выполнение любого процесса в продукте. Состоит из геом. фигур: овал (вход/выход из сценария), прямоугольник (шаг в процессе), параллелограмм (ввод/вывод данных), ромб (условие), стрелки (направления, связи).\n\n* User flow - это схемы о прохождении юзером от одного сценария к другому. Визуально либо схема, либо схема + экраны.\n* Task flow - схема показывающая что делает юзер на каждом шаге для выполнения задачи.\n* Wire flow - зарисовки интерфейсов на бумаге или низкая детализация макетов. Если макеты, то главное расположить основные элементы и контент. Тут главное навигация.\n* Screen flow - связка уже из готовых проработанных высокодетализированных макетов. Разница в детализации между предыдущим примером. \n ![ia-example.png](img/ia-example.png)\n\n#### Как начать?\n\n* Провести исследование\n* Дополнительно: можно провести обратный инжиниринг, то есть исследование структуры готового продукта с целью узнать то, как он устроен.\n* Понять список задач, целей и контент\n* Провести карточную сортировку\n\n* Выстраивать контент, действия и тд, учитывая запросы юзеров и бизнеса.\n\n#### 8 принципов IA от Дэна Брауна\n\n* Принцип объектов. Надо смотреть на контент как на развивающуюся сущность, которая имеет жизненный цикл. Контент будет иметь разные атрибуты и поведение, и это нужно учесть при проектировании. Например, контент на ютубе нужно загрузить, для этого есть разные сценарии для старта, затем нужно заполнить инфу для будущего ролика (описания, названия и тд).\n* Принцип выбора. У юзера должен быть выбор как действовать. На главной стр. ютуба я могу сразу загрузить видео, но также могу сделать это из творческой студии. Много вариантов может запутать юзера. Иногда инфу стоит подавать в виде иерархии: категорий и суб-категорий вместо длинных списокв.\n* Принцип раскрытия. Юзеру надо выдавать инфу исходя из контекста, т.е постепенно, от страницы к странице. Не пытаться вывалить все сразу. Иногда это подается в виде тултипов, а иногда по клику может раскрыться дополнительная инфа.\n* Принцип примеров. Например, когда заходишь в определенную категорию товаров на Amazon, на сайте выводятся карточки товаров с фото, которые попадают в эту категорию. Это помогает юзеру быстрее сориентироваться, если он не до конца понимает название категории.\n* Принцип открытых дверей. Допустим половина юзеров попадают на твой сайт не через главную страницу. Это значит, что любая страница должна содержать необходимый минимум инфы, чтобы юзеры поняли, где они находятся. Также это лишний раз подтверждает пункт 3, не нужно пытаться уместить всю инфу на домашней странице.\n* Принцип множественной классификации. Разные юзеры используют сайт по-разному. У них могут быть разные методы для нахождения одной и той же инфы. Например, одни используют поиск, а другие исследуют сайт. Контент нужно адаптировать к различным сценариям поведения.\n* Принцип фокусированной навигации. Не важно где находится меню, важно то, что на нем написано. Меню и панель навигации должны отражать то, где находится юзер сейчас и куда он может попасть с текущей страницы.\n* Принцип роста. На большинстве сайтов контент меняется. Организуй контент таким образом, чтобы позволять ему масштабироваться.\n\n#### Советы\n\n* Не запариваться на терминологии.", + "lastmodified": "2022-04-23T12:45:42.668739468+03:00", + "tags": null + }, + "/Design/Analysis/JTBD": { + "title": "JTBD", + "content": "#### Что надо знать\n\n* Фреймворк фокусирует на том, чего хочет достичь юзер в определенном контексте. У юзера всегда есть какие-то задачи (работы). Продукт не матчится с юзером и его атрибутами. Он матчится с проблемами, которые юзер решает и поэтому он \"нанимает на работу\" продукт, чтобы решить проблемы. Сам по себе продукт не имеет ценности, а приобретает ее в определенной ситуации. JTBD = задача + контекст.\n* Позволяет шире посмотреть на проблемы юзера и выявить конкурентов. Помогает перед разработкой нового сервиса и продуктовой стратегии.\n* When **situation** I want to **motivation** So I can **outcome**.\n* Пример: **When** у меня есть всего 2 минуты, чтобы перекусить между встречами, **I want to** съесть что-то, чтобы это было просто, быстро и подняло мой уровень сахара в крови, **so I can** продержаться до обеда и сохранить рабочее настроение.\n* Суть Job stories, которые изобрели Itercom, в том, что фокус на контексте, а не на характеристиках. \n* Чтобы провести исследование для job story, проводится интервью, в котором пытаемся понять когда и в каких условиях у клиента закралась первая мысль о покупке продукта (до начала использования). Очень важный момент: разговаривать надо не с пользователем, а с покупателем; человеком, который принял решение о покупке.\n* Юзеры не покупают продукт, а переключаются на него с чего-то другого. **Цена переключения на другой продукт** **=** (привычка + степень удовлетворенности) * страх перемен.\n\n#### 4 движущие силы в момент решения о покупке\n\n* Недовольство текущей ситуацией (“push”) — “В этом сервисе рассылки нельзя проводить A/B тесты”\n* Притягательность нового решения (“pull”) — “В другом сервисе есть эта фича”\n* Тревога, что что-то может пойти не так — “А что, если в новом сервисе моя рассылка попадет в спам?”\n* Привязанность к тому, что есть — “Я уже давно пользуюсь сервисом и все там знаю”.\n\n![720](img/4-forces.png)\n\n#### Пример контекста\n\n![720](img/jtbd-example.png)\n\n#### Когда «работа» продукта заканчивается:\n\n* у следующего шага в последовательности действий есть однозначные лидеры рынка, и вы не хотите с ними конкурировать\n* следующий шаг в контексте вашего продукта (вспоминаем приложение-будильник) может быть решен миллионом разных способов и миллионом разных типов пользователей\n* на следующем шагу у вас радикально меняется аудитория\n* следующий шаг не добавит никакой ценности продукту.\n\n#### Приоритезация JTBD\n\n* Насколько важна сама «работа» (по оценке от 1 до 10)\n* Насколько пользователи довольны текущим решением (по оценке от 1 до 10)\n* Какой есть потенциал для развития лучшего решения\n* Недообслуженные» JTBD - поле для инновационной стратегии роста (сделать существующие решения лучше)\n* Переобслуженные JTBD - возможности для инновации (переделать решение и привлечь новую аудиторию).\n\n![720](img/jtbd-prioritization.png)\n\n#### Ссылки:\n\n* [Что такое JTBD и Job stories](https://medium.com/no-flame-no-game/%D1%87%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-jobs-to-be-done-%D0%B8-job-stories-4c57c1dc84cf)\n* [Книжка по JTBD от Intercom](https://www.intercom.com/resources/books/intercom-jobs-to-be-done)", + "lastmodified": "2022-04-23T12:45:42.65723979+03:00", + "tags": null + }, + "/Design/Analysis/KANO": { + "title": "KANO", + "content": "# Метод KANO\n\nЧто делать например после составления lean canvas и конкурентного анализа? Как выбрать фичу и расставить приоритеты?\n\n## Что такое KANO?\n\nМетод за авторством японца Нориаки Кано для приоритизации новых фич или оптимизации существующих. KANO помогает оценить удовлетворенность пользователей продукта. И представляет из себя систему координат, где по вертикали измеряется удовлетворение той или иной функцией, а по горизонтали мы видим насколько эффективно реализована функция.\n\n![375](img/kano-1.png)\n\n## Из чего состоит\n\nМетод делит каждую фичу на несколько групп:\n\n### Must be (обязательные)\n\nЭто обязательные фичи без которых продукт, фича или процесс невозможен. Например для системы аренды авто это возможность аренды авто, гугл драйв должен сохранять и синхронизировать файлы, иначе этот продукт бесполезен, а сообщения в телеграме должны отправляться, и т.д.\n\n### Performance (конкурентные)\n\nЭто фичи одномерности или линейные, или конкурентные - в общем те фичи, которые можно реализовать одинаково как хорошо, так и плохо. То есть если реализовать хорошо, то юзер будет доволен и это можно посчитать конкурентным преимуществом, а если плохо, то нет. Такие фичи дают простую и понятную шкалу и соответственно обратную связь. Например емкость батареи нового макбука на чипе м1 - чем больше, тем лучше. Скорость синхронизации данных в телеграме чем быстрее, тем лучше. Скорость загрузки фотографий на сайте, процент сессий без ошибок или размер облака на Google Drive на бесплатном тарифе - все это лучше, если больше, быстрее и эффективнее.\n\n### Attractive (привлекательные)\n\nЭто фичи, которые вызовут дополнительный восторг, который повысит удовлетворенность юзеров, но в то же время, если таких фич не будет, то это никак не повлияет на удовлетворение и решение пользоваться продуктом. Например, максимально быстрое подключение AirPods к устройству, коллективное редактирование документа в гугл докс или тоже самое у фигмы, но про дизайн, прекрасный тачскрин самого первого айфона и т.д. Суть в том, что даже до первого айфона уже были тачскрины, но первый айфон с его жестами и точностью срабатывания всех поразил и вызвал восторг.\n\n### Indifferent (безразличные)\n\nЭто те фичи, которые важны только для какой-то части аудитории продукта, а для другой нет. То есть это фичи, которые насколько хорошо их не сделай, то по большому счёту юзеру все равно, а команда впустую тратит силы на реализацию. Например для системы аренды авто это может быть наличие выбора конкретной модели определенного года выпуска. Или же для заказа такси фича с выбором цвета машины под твой любимый или у утюга была бы функция тостера - это никому не нужно.\n\n## Как работает метод?\n\nДостаточно провести опрос, который будет состоять из 2х вопросов на одну фичу, где на каждый вопрос пользователю предлагается 5 вариантов ответа.\n\nПример: фича с авторизацией на сайте с помощью фейсбука. Вопросы юзерам:\n\n1. Как бы ты оценил наличие этой фичи в продукте?\n1. Как бы ты оценил если бы этой фичи не было в продукте?\n\nОтвечая на каждый вопрос, пользователь выбирает один из возможных ответов:\n\n1. Мне это нравится.\n1. Я ожидаю этого.\n1. Мне все равно.\n1. Я могу потерпеть, если этой фичи не будет.\n1. Мне это не нравится и я бы перестал использовать продукт.\n\nВсе ответы фиксируются в таблице, в которой появляются (сюрприз) еще 2 группы: группа Q - questionable - это сомнительные и противоречивые ответы, которые получаем от юзеров (их надо дополнительно изучать), потому что эти противоречивые ответы говорят о том, что юзер не понял вопроса или же смысл фичи. Например, когда человек отвечает на оба вопроса касательно фичи авторизации через фэйсбук \"Нравится\", то есть если фичи не будет в продукте ему это нравится, но также нравится если она будет. Это странно. И вторая группа R - Reverse - то есть это фичи, в которые ты вкладываешь усилия, но они понижают удовлетворенность юзера. Например, скрепка в ворде. Олды помнят и такие фичи под буквой R не надо делать вообще.\n![640](img/kano-table.jpeg)\n![640](img/kano-table-example.jpeg)\n\n## Нюансы метода\n\n* Для опросов нужно много людей(минимум 40-50).\n* Внимательно подбирай аудиторию для опроса, поскольку сам метод немного сеет сомнение относительно своей полезности, поскольку непонятно как выбираются приоритеты. По идее нужно же опрашивать пользователей, а еще при этом нужно их разбить на целевые группы и как каждая фича к какой целевой группе относится. Но здесь как раз таки и поможет заранее сделанный lean canvas, где уже определили сегменты и выделили ранних последователей/ранних пользователей.\n* Сам метод немного противоречит методике интервью, ведь мы по сути задаём прямые закрытые вопросы: понравилась бы фича если она была и наоборот. Но в этом случае если спрашиваем про будущую фичу, то надо показать прототип на видео или по ссылке если это онлайн опрос. Дополнительно можно спрашивать уже существующих пользователей, а не искать рандомных и новых. \n\n## Итоги\n\n* Собираешь список фичей (бэклог).\n* Затем подбираешь пользователей для опроса.\n* После создаешь опрос, например через гугл формы.\n* Затем собираешь ответы пользователей.\n* Потом по каждой фиче считаем ее тип по таблице.\n* В конце расставляем приоритеты в порядке: M - обязательные, P - конкурентные, A - привлекательные, I - безразличные.\n\n## Где еще почитать:\n\n* [Подробная статья о KANO (eng)](https://foldingburritos.com/kano-model/)\n* [Объяснение KANO по-русски](https://lpgenerator.ru/blog/2018/07/03/obyasnenie-modeli-kano-analiz-i-primery/)\n* [Виды приоритезации и KANO](http://outsourced.today/how-to-prioritize-a-backlog/)\n* [Еще одна статья о KANO по-русски](https://kachestvo.pro/kachestvo-upravleniya/instrumenty-menedzhmenta/top-5-metodov-prioritizatsii/)", + "lastmodified": "2022-04-23T12:45:42.670564231+03:00", + "tags": null + }, + "/Design/Analysis/Persona": { + "title": "Persona", + "content": "#### Что надо знать\n\n* Алан Купер автор метода (книга Интерфейс).\n* Артефакт строит эмпатию и документарует знания о юзерах в команде. Если команда знает кто юзеры, тогда обсуждения станут проще.\n* Персона - не конкретный человек, а модель из многих юзеров n-типа.\n* Без исследований можно создать прото-персону. Такие персоны создаются на основе текущих знаний и предположений о юзере с командой. \n* Правильно: создавать на основе данных из исследования.\n* Включает разные аттрибуты в выдуманном профиле юзера, т.е повторяющиеся черты n-сегмента аудитории продукта.\n* Используется для написания [User Story](User%20Story.md) и [User Story Mapping](User%20Story%20Mapping.md).\n* Главное в персонах: цели/задачи/проблемы.\n* Если у продукта несколько сегментов, то кто целевая аудитория? (Поищи)\n* Дизайн под сомнением? После исследования составь персон, чтобы показать то, что лежало в основе дизайн-решения. \n\n#### Почему персоны проваливаются?\n\n* Были созданы, но не использовались.\n* Руководство может не поддержать инициативу, поскольку времени и денег нет. \n* Продукт создается для функциональной роли, в которой действия предельно понятно расписаны и остается лишь написать юзер стори и создать карту, чтобы понять с командой путь юзера, найти пробелы, заполнить их, затем расставить приоритеты и раскидать на релизы.\n* Руководство не понимает пользы? Проведи исследование, например, интервью и на основе этих реальных данных иди к руководству снова. \n* В команде адепты: аб-тесты, веб-аналитика и методологии agile/lean.\n\n##### Адепты веб-аналитики\n\nС помощью веб-аналитики можно выделить сегменты юзеров, отслеживать их поведение опираясь на нужные критерии и посчитать деньги для каждого сегмента. \n\n* Но если продукта нет - не получится.\n* Это дорого: надо настроить бизнес-процесс и расставлять события на сайте.\n* Получая количественные данные, нет ответа на вопрос \"почему\".\n\n##### Адепты аб-тестов\n\n* АБ помогают понять только какое из решений лучше, но не объясняют то, каким должен быть будущий продукт и взаимодействие юзера с ним. \n* Это дорого. Нужен дизайн вариантов, а после их реализация.\n\n##### Адепты agile/lean\n\nИз-за отрезков не длиннее 30 дней дизайнеры не успевают подготовить персон достаточно хорошо. Но можно подстроить сам процесс создания персон так, чтобы вписываться во временные рамки, а также и то что этот процесс в действительности [не отнимает так много времени](https://www.nngroup.com/articles/persona-budgets/). \n\n#### Процесс создания\n\n* Получить инфу от стейкхолдеров. С этим можно примерно понять юзеров и создать прото-персону.\n* Провести исследование: чаще всего это интервью от 5 чел-к.\n* После анализ и поиск закономерностей в ответах/действиях юзеров. Эти закономерности включаются в персону. Из минусов это \"от 5 чел-к\" - небольшая выборка. Нет способа определить долю аудитории, которую представляет персона. То есть персона \"аналитик Джим\" не может составлять 60% аудитории. Также из-за маленькой выборки есть вероятность, что кого-то пропустили. Для большинства команд подходит именно этот подход, несмотря на его минус. Так как это какое-то надежное понимание юзеров и чего они хотят.\n* Хорошо, если можно провести интервью с юзерами в контексте бумажного или интерактивного прототипа, или конкурирующего продукта. Затем снова анализ и поиск закономерностей.\n* Дополнительно: гугл/вторичное исследование.\n\n#### Где еще можно получить инфу?\n\n* Если продукт есть, то провести интервью с юзерами.\n* Если продукт есть, то глянуть в аналитике откуда пришли юзеры, ключевые слова, время на сайте, куда ушли отвалившись от основного флоу и тд. Это поможет построить гипотезы о хотелках юзеров к продукту.\n* Если продукт есть, то можно пройтись по юзерам. Сделать выборку данных, которые интересны для персонажа. Если же есть доступ к почтам, то можно сделать опрос и попросить пройти. По этим же адресам можно найти ваших пользователей в соц. сетях и собрать доп. инфу.\n* Если продукта нет: прото-персоны или конкуретный анализ, чтение отзывов и/или поискать в соц. сетях юзеров, которые подходят под описанный профиль и предложить интервью. В общем вторичные исследования.\n\n#### Как строиться?\n\n* Демография: фото, имя, описание.\n* Опционально: пол, возраст, зп, образование, сем. положение, локация, хобби, реальные цитаты из интервью, откуда получают информацию.\n* Цели, потребности, ожидания, мотивы.\n* Боли, опасения, страхи.\n* Набор фичей: что хочет сделать?\n* Какой опыт у персоны в интернете/компьютерная грамотность.\n* Какой будет сценарий 1го использования, а затем через полгода? Например, мне не нужно искать продукты, если ранее добавил их в избранное.\n\n#### Советы\n\n* Прото-персоны - вариант для чрезвычайно бережливых команд, и они служат для согласования гипотез команды о юзерах.\n* Персоны должны быть приближены к реальному юзеру.\n* Фокус на 3К: Кто приносит деньги? Кого больше? Кто важнее для бизнеса?\n* Выбирать детали, которые помогают. Самопроверка: как эта деталь поможет разработке? Как эту деталь можно использовать? На что влияет эта деталь? Если ответов нет, то деталь не нужна.\n* Не плодить персон. Самопроверка: чем поведение, цели/задачи новой персоны будут отличаться?\n* Помнить что есть разные должности. Пример: медсестра интенсивной терапии и медсестра детского отделения имеют разные потребности, цели и мотивы.\n* **Ты не юзер**.", + "lastmodified": "2022-04-23T12:45:42.662200938+03:00", + "tags": null + }, + "/Design/Analysis/RICE-%D0%B8-ICE": { + "title": "RICE и ICE", + "content": "---\n\n### Метод RICE\n\n#### Что надо знать\n\n* Метод приоритизации тасок в бэклоге при разработке.\n* Самый главный плюс - скорость оценки фичей.\n* Самый главный минус - точность.\n* Формула: **R * I * C / E = RICE score**.\n* Самый высокий показатель реализуем в первую очередь и дальше по убыванию.\n\n#### Reach - охват\n\nЧтобы избежать предвзятости, нужно оценить какой охват будет у фичи? То есть какое кол-во чел-к и за какой период охватит данная фича? Взять эти данные из аналитики и оценить сколько юзеров за квартал можно получить, если сделать фичу. \n\n* Пример: на сайте каждый месяц 500 пользователей, достигают 2го шага в регистрации и 30% из них выбирают какую-то нужную бизнесу опцию, поэтому охват редизайна формы регистрации будет 500 * 30% * 3 = 450 юзеров каждый квартал.\n* Пример: ежемесячно у интернет-магазина 700 клиентов добавляют товары в корзину, но только 27% покупают. Охват 700 * 25% = 175 чел-к заметят изменение в дизайне корзины.\n* Пример: 10 тысяч чел-к в месяц посещает сайт, 50% из них это посетители с мобильных устройств, и если хотим сделать адаптив, то охват составит 10000 * 50% = 5000 чел-к в месяц.\n\n#### Impact - влияние\n\n* Всегда будет не совсем объективной оценкой\n* Трудно измерить точно воздействие\n\nМожно использовать шкалу:\n\n* 3 - макс. воздействие. Если уверен, что каждый юзер столкнется с изменением, то можно ставить 3 балла.\n* 2 - высокое воздействие.\n* 1 - среднее воздействие.\n* 0.5 - низкогое воздействие.\n* 0.25 - минимальное воздействие. \n\n#### Confidence - Уверенность в оценке\n\n* Тут важно задавать себе вопрос насколько ты уверен в своих оценках? \n* Указывается в процентах: 100% высокая уверенность, 80% средняя, 50% низкая, а все что ниже это выстрел в небо. \n* Совет: будьте честны с собой. Пример: для **фичи А** есть все количественные показатели для охвата и данные из интервью с юзерами, а также оценка разработчиков, поэтому в **фиче А** есть уверенность на 100%. Для **фичи Б** данные по охвату взяли из аналитики, влияние замерили на основании опроса на сайте, а усилия оценили как-то неуверенно, то можно указать уверенность 80%.\n\n#### Effort - Усилия для реализации\n\n* Надо оценить кол-во времени требуемое на создание фичи от всей команды.\n* Оценивается в человеко-месяцах.\n* Условно: если делается за меньше чем неделю можно взять значение 0.5. 1 для месячной загрузки, 2 для двух месяцев и т.д. Это всегда примерные значение. Например, на планирование уйдет 2 недели, на дизайн одна неделя, на разработку и тестирование 5 недель - итого примерно получается 2 месяца.\n* Можно также воспользоваться картинкой:\n\n![375](img/rice-ice-ease.jpeg)", + "lastmodified": "2022-04-23T12:45:42.669904753+03:00", + "tags": null + }, + "/Design/Analysis/Severity-analysis": { + "title": "Severity analysis", + "content": "* Какая-то метка о серьезности проблемы, которую нашли при оценке [Что такое Usability](../Base/%D0%A7%D1%82%D0%BE%20%D1%82%D0%B0%D0%BA%D0%BE%D0%B5%20Usability.md) может быть полезно для выделения ресурсов на ее решения.\n* При эврестическом анализе или во время юзабилити тесте можно поставить какой-то лейбл или просто рейтинг о серьезности проблемы.\n* Проблема серьезная, если состоит из 3 факторов: **частота** (редкая или частая), **влияние** на юзера (трудно или просто обойти проблему) и **постояноство** (беспокоит редко или постоянно).\n* Чтобы измерить **частоту** возникновения проблемы, нужно взять кол-во юзеров, которые столкнулись с проблемой и поделить на общее кол-во юзеров. Это объективно можно посчитать как и влияние и постояноство.\n* Как считать **частоту** проблемы: 1 юзер из 5 столкнулся с проблемой, значит 1/5 = 0.2 (или 20% юзеров сталкиваются с проблемой).\n* В целом же оценка**серьзности** проблемы менее объективна. Есть несколько способов посчитать, но в целом это разбивка на категории, которые отражают влияние проблем на юзера.\n* **Якоб Нильсен** предложил измерять следующую шкалу для оценки серьезности:\n * 0 = Не согласен, что это проблема юзабилити.\n * 1 = Косметическая проблема, т.е. можно исправить, если есть время.\n * 2 = Незначительная проблема, которая в низком приоритете.\n * 3 = Основная проблема, которую важно исправить, т.е. высокий приоритет.\n * 4 = Катастрофа, необходимо исправить до релиза или выпуска mvp.\n* **Джеф Рубин** предложил измерять следующую шкалу для оценки серьезности:\n * 4 = Юзер не может/хочет использовать часть продукта, из-за проблемы или реализации этой части.\n * 3 = Вероятно юзер будет использовать или пытаться использовать продукт, но юзер будет ограничен в своих возможностях сделать это.\n * 2 = Юзер может закрыть задачи в продукте в большинстве случаев, но ему придется приложить больше усилий, чтобы обойти проблемы.\n * 1 = Проблема возникает переодически, легко обходится, но раздражает.\n* Есть много других авторов, но в целом не надо зацикливаться на поиске правильного кол-ва категорий или вешания лейблов.", + "lastmodified": "2022-04-23T12:45:42.669947962+03:00", + "tags": null + }, + "/Design/Analysis/Use-case": { + "title": "Use case", + "content": "---\n\n#### Что надо знать\n\n* Юзкейс - это сценарий, показывающий взаимодействие юзера и системы, но участников может быть больше 2, а юзером может выступать как человек, так и др система. С помощью юзкейса может быть описано и юзер требование, и функциональное требование, и описание бизнес-процессов.\n* Клиентам это надо потому, что они могут подтвердить что \"это\" именно то, чего они ожидают от фичи, а в случае чего подправить.\n* Разработчикам юзкейсы нужны потому, что они видят поток событий, который приводит к успешному выполнению сценария или альтернативным событиям.\n* Тестировщики любят юзкейсы за то, что это считай готовый тест.\n* Юзкейсы удобно писать как дополнение к историям.\n* Каждый сценарий описывает то, как достигнуть какой-то цели или решить задачу в системе.\n* Юзкейсы могут иметь разный уровень детализации. \n* Юзкейс может быть связан с несколькими фичами, поэтому не стоит думать что юзкейсы это фичи. Это не так.  \n* Фичи это просто свойство системы. Например авторизация пользователя - это юзкейс. Но у такого юзкейса может быть сразу несколько фич: авторизация с помощью логина и пароля, через gmail или соц. сети, или через apple сервис и т.д - это все отдельные фичи.\n* Юзкейсы могут быть написаны абстрактно, то есть без тех. деталей, что помогает сосредоточиться на том, что система должна сделать, а не как это должно быть сделано и называется это бизнес юзкейс, который описывает ценный процесс для бизнеса, например, обработка оплаты.\n* Юзкейсы дизайнер может писать для пояснений скетчей, вайрфреймов или макетов дизайна, чтобы доносить идеи. \n\n#### Из чего состоит?\n\n* Название. Начинается с глагола чтобы объяснить сразу достижимую цель и смысл сценария. Пример: сделать видео-звонок др юзеру.\n* Описать цель. Пример: если нужно восстановить подписку на какой-то сервис, то цель - изменить статус на активный у аккаунта.\n* Действующие лица: юзер и система или система и система.\n* Предварительное условие. Условие, при котором сценарий имеет смысл. Пример: если ты отменил подписку на сервис, то у юзкейса возобновления подписки будет предусловие, что учетная запись юзера должна быть неактивна.\n* Успешный сценарий. Что должно произойти по шагам, чтобы сценарий удался. Пишут в виде пронумерованного списка.\n* Альтернативные пути. Каждый такой путь содержит название, в котором указывается причина. Затем идет пошаговое описание, совсем как в юзкейсе, а после результат этого альтернативного пути.\n\n#### Ссылки\n\n[Пример](https://vc.ru/flood/18197-trucker-path-design)\n\n````plantuml\n:Main Admin: as Admin\n(Use the application) as (Use)\n\nUser -\u003e (Start)\nUser --\u003e (Use)\n\nAdmin", + "lastmodified": "2022-04-23T12:45:42.669586451+03:00", + "tags": null + }, + "/Design/Analysis/User-Story": { + "title": "User Story", + "content": "#### Что надо знать\n\n* Придумал Кент Бек (экстремальное программирование)\n* Это способ описать требования в короткой форме.\n* Не описывает решение, только ценность.\n* Формула: Я, как (роль или тип юзера/персона), хочу (действие), так чтобы или просто чтобы (ценность).\n* Без критериев приемки легко интерпретировать как угодно, что усложняет использование как основу для соглашений между разработчиками и клиентом. \n* Это не надежный метод для документации, поскольку рассказываются и записываются максимально просто.\n\n* Пример: Я, как пользователь сайта, хочу сделать свою почту приватной, даже если остальная информация публична, чтобы никто не смог мне написать.\n* Пример: Я, как учитель, я хочу разместить ближайшие курсы со ссылкой на подробности на странице своего профиля, так чтобы потенциальные ученики могли найти курсы.\n* Пример: Я, как пользователь сайта, хочу просматривать профили других пользователей, чтобы найти с кем пообщаться.\n* Самая важная часть - ценность. Без нее - пишется ерунда.\n* [Use case](Use%20case.md) идут как дополнение (не замена) к юзер стори.\n\n#### Зачем нужна юзер сторя?\n\n* Для показа ценности (юзкейс не может): почему фича важна для юзера.\n* Для планирования: что должно быть реализовано.\n* Для формирования бэклога. Бэклог - фичи, что планируется разработать.\n* Для обсуждения требований с клиентом/командой.\n* Чтобы разбить продукт на релизы, поэтому подходят для проектов, где требования изменчивы или плохо понятны.\n* Для составления [User Story Mapping](User%20Story%20Mapping.md).\n\n#### Что нужно для написания\n\n* Нужен юзер - персона или роль в системе.\n* Пример: если это система учета товаров на складе, то здесь роли: кладовщик, грузчик и т.д.\n\n#### INVEST = хорошая история\n\n* INVEST - аббревиатура\n* I -Independent. Независимость. Это означает, что любая история может быть реализована в любом порядке. Одна история не влияет на другие истории. Это нужно, чтобы к концу итерации у вас была готовая фича. Итерация это термин из экстремального программирования, означающий период времени, в течение которого команда разработает и выпустит какую-то часть продукта. Спринт это тоже самое, только в терминологии скрама. Период времени обычно менее 30 дней.\n* N - Negotiable. История должна обсуждаться, и это обсуждение надо вести тогда, когда создается история. Главное отразить суть без деталей.\n* V - Valuable. История должна быть ценной для юзеров, клиента, стейкхолдеров.\n* E - Estimable. Историю необходимо оценить по времени и трудозатратам. Любая история может быть оценена, а если нет, то сформулирована неверно или слишком большая.\n* S - Small. История должна быть короткой, чтобы ее можно было реализовать за итерацию или спринт. Если она большая, то ее надо разбить на короткие истории.\n* T - Testable. История должна иметь критерии приемки.\n\n#### Критерии приемки\n\n* Это условия, которым продукт должен удовлетворять, чтобы быть принятым юзерами, клиентом и стейкхолдерами. В общем, это границы/параметры того когда история завершена. \n* Критерии говорят разработчикам то, что конечные юзеры хотят от функции или продукта в деталях, но это не документация. \n* Критерии пишутся до начала спринта, то есть фактической работы.\n* Критерии могут уточняться или меняться на основе бесед между владельцем продукта и стейкхолдерами.\n* Отсутсвие критериев перед выставлением приоритетов юзер сторям мешает процессу приоритизации и фактической работе.\n* Шаблона для критериев приемки - нет.\n* Пример: Как аналитик акустических сенсоров, я хочу получать уведомления, когда инспектор изменит статус задачи, чтобы я был в курсе была ли протечка или нет.\n* Критерии приемки: \n * Поскольку у меня есть активные задачи, когда нет открытого приложения, я должен получить уведомление в виде баннера.\n * Поскольку у меня открыто веб-приложение в браузере, когда я работаю с ним, значок колокольчика в шапке должен обновиться, чтобы показать непрочитанные уведомления с их количеством.\n* Хоть шаблона нет но иногда пишут так: Учитывая (вставляем контекст или начальное состояние), Когда (пишем конкретное действие, которое выполняется), тогда (пишем то, что должно произойти).\n* Та же история, но критерии уже записываем так:\n * Учитывая наличие активных задач.\n * Когда не открыто приложение.\n * Тогда получаю уведомление в виде баннера.\n * Учитывая открытое приложение.\n * Когда я с ним работаю.\n * Тогда  значок колокольчика в шапке и дальше как было.", + "lastmodified": "2022-04-23T12:45:42.670460811+03:00", + "tags": null + }, + "/Design/Analysis/User-Story-Mapping": { + "title": "User Story Mapping", + "content": "#### Что надо знать\n\n* Автор техники Джеф Паттон.\n\n* Показывает визуально весь бэклог продукта с приоритетами. \n* Показывает пробелы, которые надо обсудить\n* Держит фокус на пользователях и их опыте, \n* Структура карты:\n * Персона/роль\n * Эпик (большая активность юзера). Эпик это большой объем работы, который можно разбить на несколько историй поменьше. Например, найти товар или менеджмент заказов.\n * Шаги - юзер стори. Располагаются в хронологическом порядке.\n * Детали историй сверху вниз по приоритетам\n* Когда создаешь с командой надо думать про весь цикл работы юзера, записывая каждый шаг/действие. После этого обсуждать, приоритезировать, группировать в эпики.\n* Детали на карте - бэклог.\n* Можно провести горизонтальную линию и разметить то, что будет реализовано за спринт/итерацию, то есть разметить по релизам.\n* Можно применить к фиче, для целого проекта.\n* Можно делать карту в начале проекта или когда уже продукт есть и команда запуталась.\n* Истории должны быть связаны между собой. Для этого достаточно просто вставить фразу \"а потом\" в промежутке между двумя карточками, чтобы получить связанную историю, но без деталей.\n* Составляй детали к истории простыми глагольными фразами. Используй связку «или он может». Пример: Я, как участник диалога, хочу поделиться файлами с телефона, чтобы передать эмоции\". Используя связку будет так: «чтобы отправить медиа-файл, он может прикрепить аудио файл, или добавить видео, или добавить фото и т.д».\n\n![story-mapping-levels.png](img/story-mapping-levels.png)\n\n#### Как составлять?\n\n* Должен быть юзер и сформулированная проблема. Если нет, обсуждайте.\n* Записать все шаги подряд. Пример: в интернет-магазине это найти товар среди категорий, изучить детали товара, добавить в корзину, авторизоваться, сделать заказ, ввести платежную информацию, оплатить, отследить и др шаги, которые сформируют общую картину, каркас. \n* При написании шагов (историй) мыслить глобально, без детализации. Пример: регистрация для получения учетной записи, поиск домов, просмотр страницы дома, ввод платежной информации, оплата, оставить отзыв и т.д. В конце концов у вас будет много шагов, размещенных в хронологическом порядке слева направо.\n* Проанализировать шаги с командой, чтобы найти пробелы или объединить несколько шагов в активность (эпик) - выше шагов.\n* Истории должны быть связаны между собой, а для этого достаточно просто вставить фразу \"а потом\" в промежутке между двумя карточками, чтобы получить связанную историю, но пока что без деталей.\n* После эпиков, снова к первому шагу и начать прорабатывать детали. На каждом шаге можно задать себе вопросы:\n * В чем особенности действий юзеров на данном этапе?\n * Какие альтернативные вещи они могут сделать?\n * Как можно сделать это по-настоящему крутым?\n * Как исправить ситуацию, если что-то пойдёт не так?\n* После написания деталий, надо расположить их в столбик и снова заполнять пробелы. Пример: в интернет-магазине, помимо поиска, понадобится фильтр по цене, фильтр по рейтингу. На странице продукта еще понадобятся отзывы, сопутствующие товары и т.д.\n* В конце выставляются приоритеты путем перемещения вверх-вниз деталей. Часто для приоритезации используется MoSCOW аббревиатура.\n * Must (обязательно)\n * Should (высокий приоритет)\n * Could (желательно, но не обязательно)\n * Would (на будущее, т.е. никогда)\n* После нарисуй линию чтобы поделить на мвп и др релизы. \n\n#### Советы\n\n##### Постоянно обновляй карту\n\nКарта должна постоянно обновляться и быть живым документом.\n\n##### USM vs CJM\n\n* USM для совместной работы над требования и их обсуждением.\n* CJM для отображения пути клиента по продукту, для выявления проблемных зон. \n\n##### Эпики vs История vs Детали\n\nШаги это то, что можно сделать за спринт. Шаги - это уровень истории. Если они огромные, т.е 2-3 спринта, то это эпики.", + "lastmodified": "2022-04-23T12:45:42.671278336+03:00", + "tags": null + }, + "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9": { + "title": "Глоссарий", + "content": "Здесь собраны ссылки категории базовых знаний в дизайне:\n\n* [Что такое uxui дизайн](%D0%A7%D1%82%D0%BE%20%D1%82%D0%B0%D0%BA%D0%BE%D0%B5%20uxui%20%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD.md)\n* [Что такое Usability](%D0%A7%D1%82%D0%BE%20%D1%82%D0%B0%D0%BA%D0%BE%D0%B5%20Usability.md)\n* [Дизайн-процессы](%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B.md)\n* [Что такое MVP](%D0%A7%D1%82%D0%BE%20%D1%82%D0%B0%D0%BA%D0%BE%D0%B5%20MVP.md)\n* [Как понять задачу](%D0%9A%D0%B0%D0%BA%20%D0%BF%D0%BE%D0%BD%D1%8F%D1%82%D1%8C%20%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D1%83.md)", + "lastmodified": "2022-04-23T12:45:42.66870005+03:00", + "tags": null + }, + "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5": { + "title": "Дизайн-мышление", + "content": "## Что это?\n\nhttps://skillbox.ru/media/design/chto_takoe_dizayn_myshlenie/", + "lastmodified": "2022-04-23T12:45:42.655817372+03:00", + "tags": null + }, + "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B": { + "title": "Дизайн-процессы", + "content": "* Процессов, моделей и фреймворков много. К тому же люди адаптируют их под себя и свое мнение. Также любой процесс может быть подобран и адаптирован, исходя из сроков, клиента и его бюджета - это все нормально.\n\n## Видение\n\nПервым появляется клиент/инвестор с видением. Видение - это способность видеть куда твой бизнес пойдет. И это видение создаёт цели, чтобы понимать итоговый результат. Например: Моё видение дать возможность людям получать кофе тогда, когда это им нужно, используя доставку дронами. Исходя из этого видения, я строю цели. Цель. Это итоговый результат. Тут все просто. Например: Я хочу получать 50 доставок в день в N-городе. Достичь 20000 платящих юзеров. Запуститься в N кол-ве городов. Но как я узнаю что достиг целей? Ответ KPI, то есть метрики. Это то, как ты узнаешь что достиг результата (цели) и чем ты этот результат будешь измерять. Соответственно, kpi дают тебе понимание выполняются ли цели и насколько они близки к твоему видению. Например: Чтобы понимать, что цель выполняется я должен знать итоговое кол-во доставок в день. Итоговое кол-во платящих юзеров. Кол-во городов с активными юзерами и т.д.\n\nВажен порядок в такой очереди, потому что видение это про будущее, т.е. куда ты смотришь и направишь бизнес, себя и людей. Видение это что-то большое, поэтому нужны конкретные результаты (цели), чтобы дать тебе понимание, что ты находишься на пути к своему видению. KPIs(метрики) это данные, а данные это всегда про прошлое, т.е. они скажут лишь то, что случилось в прошлом. Теперь, зная это, мы получаем клиента/заказчика/инвестора с видением. Такой визионер и создаёт компанию, он также может привлечь инвесторов или использовав свои средства нанять людей - команду на зарплату, логично. И дальше, спускаясь на уровень ниже мы подходим к процессу.\n\nВезде есть этапы:\n\n* Исследование - анализ предметной области, бизнеса, юзеров и технических возможностей разработки. Дизайнер ищет проблемы и задачи.\n* Анализ - данные изучаются, создаются артефакты и документы, описывающие юзеров и архитектуру интерфейса.\n* Дизайн - на основе анализа создаются концепты и дизайн-идеи, отвечающие потребностям юзера и бизнеса. Макеты утверждаются с бизнесом и тестируются на пользователях.\n* Разработка - тут подключаются разработчики, дизайнер поддерживает их и проводит ревью готового интерфейса.\n* Поддержка и улучшения - собирается обратная связь от пользователей и бизнеса, проводятся исследования по КПИ, предлагаются улучшения.\n\nНо повторюсь бывает так что задача на какую-то функциональность или сам проект уже в готовом виде появляется из \"видения\" клиента, продакт-менеджера или другого сотрудника в виде какой-то идеи в продукте. Хотя по хорошему надо брать метрику продукта и уже от нее строить гипотезы, идеи и смотреть на рынок. Это если мы говорим про существующий продукт. Если это что-то новое, то в любом случае надо провести исследование. Это первый этап.\n\nСюда я бы отнес первым делом первоначальную встречу с клиентом и/или потенциальными пользователями для определения того, как проект будет продвигаться вперед. Именно на таких встречах ты будешь формировать с командой представление о проекте и о том, что от вас потребуется. Базово надо понять и разобраться в масштабе проекта, определить бизнес-цели, понять бизнес-процессы, понять кому это нужно, почему и зачем. Опять же, базово обсудить задачу с командой на её понимание. Об этом у меня есть отдельное видео. Также нужно обсудить критерии успешного решения задачи, т.е. какими метриками можно будет проверить успешность. Также учти, что проектом может быть не что-то большое, а какая-то задачка на новую функциональность в продукте или улучшение текущего положения дел. Главное помни про пользователей. И сразу приведу примеры того как тебе за пользователей ухватиться. Если это клиент или продукт, у которого есть существующие пользователи, то спроси к кому ты можешь обратиться, чтобы провести интервью ведь возможно есть какая-то тестовая группа. Если таких нет, ты можешь собрать группу людей для проведения интервью на выявление проблем и для раннего тестирования. Для этого банально можно спросить о демографических показателях компании клиента, посмотреть в аналитику или провести вторичное исследование, чтобы в общем понимать кто пользователь в данной нише или кого искать на тесты, а после этого можно даже воспользоваться онлайн-сервисами или банально поискать людей в соц. сетях, которые используют ваш продукт, если он есть. Про исследования есть отдельный ролик, поэтому двигаем дальше.\n\n## Анализ\n\n1\n\n## Дизайн\n\nСледующий этап, второй, это проектирование. Для меня этот этап включает анализ данных, полученных с исследований, а затем создание решения. Итак, собрав всю информацию с этапа исследование, ты начинаешь анализировать данные и формировать артефакты. Это может быть создание персонажей, формирование пользовательских сценариев и так далее. Про все основные методы и для чего они нужны будут отдельные видео, поэтому не стоит перечислять их все. Далее, ты создаешь решение. Для его создания ты можешь также использовать различные методы. Например, можно нарисовать активити диаграмму, user flow, информационную архитектуру, бумажные прототипы, интерактивные прототипы, а также сами макеты в разной степени их проработки. Этот этап итеративен, то есть ты циклично будешь проходить через него для проверки идей и гипотез, основываясь на обратной связи с пользователями, командой и бизнесом. На этом этапе, как ты уже догадался, нужно проверять первые макеты или лучше прототипы на пользователях. Если есть, как уже упомянул, тестовая группа пользователей, то идите к ним с прототипами, а если нет то можно провести коридорное тестирование. Это может быть любое место, где есть твой представитель аудитории, пользователь. Тут главное делать и тестировать быстро. Кстати, тестировать можно и в онлайне, то есть удаленно. Например по скайпу, или использовать специализированные сервисы. Опять же про тестирование поговорим отдельно, двигаем дальше.\n\n## Разработка\n\nПосле проектирования идет этап разработки. Это третий этап. На этом этапе ты по хорошему делаешь финальные штрихи в макетах, и готовишь ресурсы для передачи в разработку. И конечно же до всего этого твой дизайн уже должен быть проверен заинтересованными сторонами и конечными пользователями с помощью тестирования. А на этапе разработки мало что можно сказать. Твоя роль смещается от создания и проверки идей к сотрудничеству с разработчиками, чтобы направлять их, отстаивать свои решения, контролировать качество или искать компромиссы.\n\n## Поддержка и улучшение\n\nСледующий этап - запуск эксперимента и его оценка. После эксперимента у тебя будут первые отзывы, цифры и показатели по продукту. По факту это следующий раунд анализа, однако вместо того, чтобы смотреть на результаты проведенных тобой исследований, ты с командой будете смотреть на свой конечный продукт, mvp или функциональность, а затем, если эксперимент прошел успешно, весь процесс повторяется снова целиком. Без аналитики и замера метрик тут никак. Пилить что-то на авось и без подтверждения цифрами - опасно, тебе не кажется? Соответственно, до этого этапа спроси своего менеджера и разработчиков учтены ли те или иные метрики и события в коде, чтобы это точно отобразилось в системе.\n\n## Популярные фреймворки\n\n* [Дизайн-мышление](%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5.md)\n* [Lean](Lean.md)\n* [Double diamond](Double%20diamond.md)\n* [Дизайн-спринт](%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%BF%D1%80%D0%B8%D0%BD%D1%82.md)", + "lastmodified": "2022-04-23T12:45:42.665459119+03:00", + "tags": null + }, + "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%BF%D1%80%D0%B8%D0%BD%D1%82": { + "title": "Дизайн-спринт", + "content": "1\n\n* https://dtcenter.ru/blog/google-design-sprint-methods#:~:text=%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD%2D%D1%81%D0%BF%D1%80%D0%B8%D0%BD%D1%82%D1%8B%20%E2%80%93%20%D1%8D%D1%82%D0%BE%20%D1%84%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%20%D0%B4%D0%BB%D1%8F,school%20%D0%B2%20%D0%A1%D1%82%D1%8D%D0%BD%D1%84%D0%BE%D1%80%D0%B4%D0%B5.\n* https://academy.yandex.ru/posts/kak-organizovat-idealnyy-dizayn-sprint\n* https://leadstartup.ru/db/design-sprint\n* https://ux.pub/editorial/ofitsialnoie-rukovodstvo-po-google-design-sprint-mietodologhiia-dizain-sprintov-2392\n* https://standapp.pro/blog/design-sprint\n* https://sbermarketing.ru/news/design_sprint\n* шаблон джиры: https://www.atlassian.com/ru/software/confluence/templates/design-sprint", + "lastmodified": "2022-04-23T12:45:42.665743128+03:00", + "tags": null + }, + "/Design/Base/%D0%9A%D0%B0%D0%BA-%D0%BF%D0%BE%D0%BD%D1%8F%D1%82%D1%8C-%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D1%83": { + "title": "Как понять задачу", + "content": "## Что обсуждаем?\n\n### Базовые вопросы\n\n* Какую проблему или потребность пытаемся закрыть продуктом/фичей?\n* Что должен делать продукт/фича?\n* Какую цель для бизнеса преследуем? (повысить узнаваемость, продавать, активации, удержание и т.д)\n* Как будем считать результат? Какие будут (KPI)/Метрики?\n* Этот продукт/фича сам(-а) по себе или должен как-то вписываться в др. продукты компании?\n* Кто наши юзеры?\n* Почему для них это важно, т.е. чего они пытаются достичь в продукте?\n* Какие есть текущие известные проблемы с продуктом?\n* Какие есть ресурсы (время, деньги, люди)? Технические ограничения?\n* Кто наши прямые и косвенные конкуренты?\n\n### Интервью со стейкхолдерами\n\n* Какова ваша роль в проекте?\n* Что самое важное из того что нужно сделать хорошо, чтобы вообще это имел смысл разрабатывать(продукт/фичу)?\n* Есть какие-то проблемы юзеров, о которых вы знаете? Может предположения какие-то?\n* Что точно известно о них?\n* Какие самые распространенные проблемы у юзеров есть?\n\n### Исследование юзера\n\n* Опиши обычный рабочий день?\n* Какие повседневные обязанности?\n\n### О проблеме\n\n* Как вы в настоящее время решаете проблему/задачу?\n* А когда последний раз пытался решить проблему/задачу?\n* Что уже делаете чтобы облегчить эту проблему/задачу? \n* Пробовали искать обходные пути? Какой был результат? Почему не устроил?\n* Что самое неприятное в этой проблему/задачу?\n* Как часто сталкиваетесь с этой проблему/задачу?\n* Есть ли какая-то рабочая гипотеза?\n\n### Проектирование взаимодействий\n\n* Что пользователь пытается сделать на этом экране?\n* Какую проблему решает этот экран?\n* В чем может провалиться этот дизайн?\n* Как вы пришли к этому решению?\n* Как выглядит упрощенная версия этого экрана?\n* Мы что-то можем убрать?\n* Какие вы сделали гипотезы?\n* Почему это здесь?\n* Почему вы решили это показывать?\n* Стоит ли это показывать по умолчанию?\n* Почему на экране именно так все организовано?\n* Почему ваше решение лучше, чем общепринятый паттерн дизайна\n\n### Делая перерывы, отвечай на вопросы:\n\n* Зачем я это делаю (что пользователь будет делать на этом экране)?\n* Какую проблему решаю?\n* Как моё решение может сломаться, потерпеть неудачу или не сработать?\n* Как я пришёл к этому решению?\n* Действительно ли это полезно бизнесу и/или пользователям?\n* Есть ли более лёгкий способ решить проблему?\n* Можно ли что-то удалить отсюда?\n* Почему это тут, а это там?\n* Почему это вообще надо показывать?\n* Стоит ли что-то отображать, выбирать по умолчанию?\n* Почему моё решение лучше, чем любой стандартный паттерн, нативная функция или то, что не требует дизайна?\n* Всегда веди записи или список того, что нужно сделать по задаче даже когда не хочется. Так не забудешь то, что нужно сделать, что уже сделано, а что решил сделать потом.", + "lastmodified": "2022-04-23T12:45:42.666625154+03:00", + "tags": null + }, + "/Design/Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-MVP": { + "title": "Что такое MVP", + "content": "* Минимально жизнеспособный продукт – это продукт минимального объема, при выпуске которого успешно достигается желаемые результаты. Точно определите, кто ваши заказчики и пользователи и что им нужно для решения их задач. Что им минимально необходимо?\n* Минимально жизнеспособное решение – это самое простое решение, при воплощение которого в жизни успешно достигаются желаемые результаты.\n* Минимально жизнеспособный продукт – это также нечто наименьшее из того, что ты можешь сделать или создать, чтобы доказать или опровергнуть гипотезу. Мы должны ставить небольшие эксперименты, делать прототипы и проверять наши гипотезы о том, что минимально и жизнеспособно само по себе.", + "lastmodified": "2022-04-23T12:45:42.667852275+03:00", + "tags": null + }, + "/Design/Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Usability": { + "title": "Что такое Usability", + "content": "# Что это?\n\nЮзабилити это степень, которой продукт соответствует, чтобы юзеры пользовались им для достижения целей в каком-либо контексте.\n\nХорошие практики:\n\n* [Якоба Нильсена](https://www.nngroup.com/articles/ten-usability-heuristics/)\n* [Вайншенк и Баркер](https://cheatography.com/deleted-2754/cheat-sheets/weinschenk-and-barker-classification/)\n* Стандарты ISO/ГОСТы.\n\n## 5 принципов\n\n* **Обучаемость**. Легко ли юзеры решают задачу в 1й раз? Не мешает и не путает ли их навигация, модалки, реклама и т.д. Когда нарисовал интерфейс, стоит пересматривать его и подумать. Можно учитывать предыдущий опыт юзера с конкурентами, ведь интуитивно понятный интерфейс это про преемственность.\n* **Эффективность**. Как быстро юзер решает типовые задачи после обучения: закажет товар, прочитает статью, получит консультацию, активирует что-то или прослушает трек/подкаст. Пример не из цифровой среды: как быстро ты находишь нужный товар на полках в магазине где уже был много раз и в новом для тебя месте? А как быстро кассир пробивает тебе чек на кассе?\n* **Запоминаемость**. Насколько легко использовать интерфейс после перерыва? Например, воспользовавшись приложением 1-2 раза, разберешься ли ты в нем через месяц?\n* **Предотвращение ошибок**. Насколько хорошо продукт/система предотвращает ошибки пользователя? Предлагает ли она их исправить? Или предугадывает что хочет пользователь заранее так, как это делает поиск в браузере? И как много ошибок совершают юзеры? Разбираются ли они дальше в чем проблема? Пишут ли в поддержку? Куда уходят за ответом столкнувшись с ошибкой?\n* **Удовлетворенность**. Это про бренд, его историю, визуальный дизайн, навигацию, текст, обращение к пользователю и эстетику.\n\n## А дизайнеру что?\n\n* Сокращать кол-во кликов.\n* Убирать отвлекающие факторы.\n* Делать шаги до цели короче и проще.\n* Замерять кол-во кликов и время, которое юзер тратит на задачи.\n* Смотреть в аналитику на метрики, т.к легко измерить кол-во купивших или активировавших что-то, зарегистрированных или вернувшихся юзеров.\n* Проводить юзабилити-тестирования, корридорки/горила-тесты. \n* Если нет доступа к аналитике, то пользоваться принципами Нильсена.\n\n## Эвристики Нильсена\n\n* В идеале должны оцениваться командой.\n\n* В одиночку нельзя найти все проблемы, а люди находят их.\n\n* 1 чел-к может быть предвзят и повлиять на оценку. Например, n-кол-во кликов до цели может казаться проблемой, а для юзера это ОК. Потому что главное он достигает своих целей, используя продукт, а другой причиной этому может служить сложная предметная область.\n\n* **Отображение статуса системы.** Юзер должен всегда и вовремя понимать, что происходит с системой Например, загрузка файда в процессе или завершена? Юзер должен понимать, что система замечает его действия. Например, товар добавлен в корзину.\n\n* **Соответствие между системой и реальным миром.** Каждый элемент интерфейса должен говорить с юзером на его языке и быть интуитивно понятным. Например, иконка в виде конверта не может соответствовать действию «добавить в корзину».\n\n* **Свобода действий и контроль.** У юзеров всегда должна быть возможность отменить/повторить действие.\n\n* **Единообразие и стандарты.** Соблюдай единообразие во всем: в элементах дизайна, в обращении к пользователю в текстах. То есть, одни и те же элементы не должны относится к разным действиям в рамках одного дизайна.\n\n* Профилактика ошибок.\\*\\* Дизайн должен исключать возможность ошибки юзера. Любые неясные элементы интерфейса должны быть устранены или надо заранее показать подсказку, чтобы юзер не совершил ошибку.\n\n* **Узнавание превыше вспоминания.** Интерфейс сам показывает нужные элементы, не заставляя юзера использовать память.\n\n* **Гибкость и эффективность использования.** Навигация по интерфейсу должна быть простой и не требовать от пользователя многих усилий. Если есть часто повторяющиеся действия, то можно предложить решение как их ускорить или сделать проще.\n\n* **Эстетика и минимализм.** Не вставляй в интерфейс лишнюю и редкую инфу.\n\n* **Помощь юзерам распознавать, диагностировать и исправлять ошибки.** Сообщи об ошибке в простом тоне и подскажи пути ее решения.\n\n* **Помощь и документация.** Обеспечьте юзеру доступ к справке и списку частых вопросов и ответов (FAQ).\n\n### Ссылки\n\n* [Что такое юзабилити?](https://medium.com/@v.shliachkov/%D0%B8%D0%B7%D0%BC%D0%B5%D1%80%D0%B5%D0%BD%D0%B8%D0%B5-%D1%8E%D0%B7%D0%B0%D0%B1%D0%B8%D0%BB%D0%B8%D1%82%D0%B8-2-%D1%87%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-%D1%8E%D0%B7%D0%B0%D0%B1%D0%B8%D0%BB%D0%B8%D1%82%D0%B8-797954f55553)\n* [Гост](http://standard.gost.ru/wps/wcm/connect/d661e080413f5db8a4e9fe7ab9890bef/GOSTRISO_9241-210-2012.pdf?MOD=AJPERES)\n* [Как можно измерить юзабилити-показатели](https://usabilitygeek.com/usability-metrics-a-guide-to-quantify-system-usability/)", + "lastmodified": "2022-04-23T12:45:42.65780264+03:00", + "tags": null + }, + "/Design/Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-uxui-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD": { + "title": "Что такое uxui дизайн", + "content": "* Дизайн - это инструмент, который используется, чтобы повлиять на юзера твоего продукта, чтобы было хорошо и юзеру, и бизнесу\n* Ты проектируешь чтобы юзер использовал продукт определенным образом. Ты хочешь, чтобы пользователь покупал определенный продукт, чувствовал себя определенным образом, действовал определенным образом, что бы это ни было.\n* Например, у друга на кухне горячая вода может включаться поворотом влево, а в ванной вправо. А у тебя дома включается горячая вода везде справа и вот ты перепутал что-то и обжёгся. И это уже дает тебе определенный опыт и впечатления не правда ли. Вопрос: можно было сделать этот опыт и способ взаимодействия одинаковым в рамках одной квартиры, чтобы в будущем не обжигать себя и других? Ответ, разумеется да.\n\nИ второй пример, в спотифай есть удобная функция, которая позволяет слушать музыку с того же места, но переключившись на другое устройство. К примеру, я заканчиваю пробежку, и поднимаясь домой хочу продолжить слушать плейлист уже не с телефона, а с компьютера и спотифай дает мне такую возможность. Это удобно и это оставляет приятный опыт и впечатления от взаимодействия с продуктом.\n\nЭто одна из причин, по которой лично я считаю, что ты не сможешь отделить UX дизайн от UI дизайна или любого другого типа дизайна, если на то пошло. Если ты новичок, то не позволяй себе запутаться в терминах и шумихе. Сосредоточься на том, чтобы стать дизайнером, который уже включает в себя все обязанности как ux так и ui дизайнера. Термины и модные слова являются лишь частью развития и зрелости нашей с тобой профессии. Поэтому не пугайся и не грузи себя лишний раз когда будешь читать очередную новую дизайн-статью, но по факту о старых вещах. Итак, что же такое UX.\n\nЕсли коротко, то User Experience в переводе Пользовательский Опыт или сокращенно UX — это то, как понимает и как отвечает твой пользователь в результате использования твоего продукта, системы, функциональности или услуги. Как в Интернете, так и в реальном мире. Например, это может быть опыт использования чашкой кофе, микроволновки, смесителя, интернет-магазина, мобильного приложения и т.д.\n\nUX-дизайн — это непрерывный процесс проектирования пользовательского опыта. То есть ты будешь непрерывно проектировать пользовательский опыт, занимаясь UX. Это может казаться неочевидным. Поскольку действительно ли возможно спроектировать опыт, то есть впечатления? Возможно ли спроектировать приятные ощущения у пользователей, когда они будут использовать твой продукт?\n\nОтвет, опять-таки да и пару примеров я уже привел. Давай рассмотрим что делают в этом смысле другие дизайнеры. Графические дизайнеры используют различные шрифты, цвета, иллюстрации и фотографии для того, чтобы сформировать впечатления от плаката, брошюры и т.д. Дизайнеры мебели используют технологии и материалы, чтобы было приятно посидеть в кресле или полежать на кровати, а дизайнеры интерьеров планировку и освещение, чтобы, опять-таки, создать и передать опыт и впечатления.\n\nДалее, раз все вертится вокруг пользователя и его опыта использования того, что ты сделал, надо понять как сделать этот опыт максимально удобным и приятным из тех средств что у тебя есть. Думать об этом важно потому, что цели пользователей часто отличаются не только от твоих ожиданий как дизайнера, но и от ожиданий бизнеса, на который ты работаешь. Поэтому задавайся вопросами: для кого и почему?\n\nДля начала достаточно думать о людях, их потребностях, желаниях, мотивации, обстоятельствах и опыте, который они уже имеют или получат в результате использования того, что ты сделаешь. Также держи в голове возможности, требования и ограничения со стороны бизнеса, технологий и предметной области.\n\nЗадавай себе регулярно вопросы по типу: Кто будет пользоваться продуктом? Каких целей они хотят достичь используя продукт? Почему для них это важно? Имеет ли это смысл для пользователей? Почему им не все равно на этот продукт? Как они будут взаимодействовать с продуктом? А как продукт должен вести себя в ответ? Как пользователи познакомятся с продуктом? Решает ли продукт проблему пользователей? Как сделать работу пользователя твоего продукта более эффективной?\n\nОтветы на эти вопросы даёт большое количество методов, принципов и практика ux дизайна, но об этом я поведаю в следующий раз. Сейчас нужно двигаться дальше.\n\nДругая сторона дизайна интерфейсов - это UI-дизайн. UI-дизайнеры создают визуальный язык, консистентность, расставляют приоритеты и документируют это все для передачи в разработку. Другими словами решают проблемы эстетики и способа взаимодействия. И на способе взаимодействия я остановлюсь подробнее, потому что User Interface в переводе Пользовательский Интерфейс или сокращенно UI — это в первую очередь способ взаимодействия пользователя с продуктом, системой, функциональностью или услугой.\n\nИтого, ux и ui дисциплины образуют интерфейс, то есть способ взаимодействия с максимально удобным опытом использования какого-либо продукта, системы, функциональности или услуги, как в реальном мире, так и в цифровой среде. На базовом уровне, получившийся интерфейс должен отвечать трём критериям:\n\n•    Бизнес задачи (для чего компания делает продукт)\n•    Потребности пользователя (чего люди ожидают)\n•    Ограничения (деньги, время, люди, технологии)\n\nЯ не буду разбирать подробно каждый пункт, но что касается бизнес-задач, то важно держать в голове для чего компания делает продукт. Обычно, сюда входят пункты банально сделать деньги, повысить популярность бренда (услуги, продукта, функциональности) и привлечь новую аудиторию. Все очень сильно зависит от видения владельца продукта, инвесторов и ключевых лиц, которые принимают решения. Также все зависит от типа бизнеса и выбранных ключевых показателей (Kpi), то есть метрик, по которым вы будете замерять результат.\n\n Что же касается пользовательских целей и задач, то в этом пункте я лишь скажу, что все пользователи чего-то хотят, ведь они люди, а люди вечно чего-то хотят. В этом помогут исследования, тесты, гипотезы и предлагаемые тобой решения.\n\nС ограничениями же все проще, так как важно помнить то, что у тебя никогда не будет лишнего времени, денег, людей и технологий.", + "lastmodified": "2022-04-23T12:45:42.666004678+03:00", + "tags": null + }, + "/Design/Base/Double-diamond": { + "title": "Double diamond", + "content": "1\nhttps://ux.pub/editorial/obnovliennaia-modiel-double-diamond-3o9p", + "lastmodified": "2022-04-23T12:45:42.667699312+03:00", + "tags": null + }, + "/Design/Base/Lean": { + "title": "Lean", + "content": "## Что это?\n\nhttps://www.ux-ui.top/uncategorized/prostoe-vvedenie-v-lean-ux.html", + "lastmodified": "2022-04-23T12:45:42.66752314+03:00", + "tags": null + }, + "/Design/Design": { + "title": "Design", + "content": "# Содержание\n\n* *Базовые знания*\n* [Исследования](Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F.md)\n* [Анализ](Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7.md)\n* [Дизайн](Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5.md)\n* [Тестирование](Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5.md)", + "lastmodified": "2022-04-23T12:45:42.669268192+03:00", + "tags": null + }, + "/Design/Design/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0": { + "title": "Дизайн-система", + "content": "* Это не ui kit.\n* Это когда есть польза для всех бизнес-юнитов. Если нет ценности - пилишь ui kit либо забиваешь даже на него. Нет смысла делать дизайн-систему для лендосов, а иногда даже для лендоса не нужно ui kit, если клиенту он нужен через час - се ля ви.\n* Это когда все расписано: как и что использовать - текстом, как и что выглядит и двигается - графически, и реализация всего этого в коде. Без кода - это не дизайн-система.", + "lastmodified": "2022-04-23T12:45:42.668281287+03:00", + "tags": null + }, + "/Design/Design/%D0%9C%D0%B0%D0%BA%D0%B5%D1%82": { + "title": "Макет", + "content": "* Вайрфрейминг - этап из 2х вещей: скетчи от руки и низкодетализированные макеты. \n* На этапе вайрфрейминга важно показать грубое, статичное, без деталей и цвета представление интерфейса. Главное контент и его иерархия.\n* Макеты/мокапы = дизайн.\n* Макеты/мокапы могут быть как высокодетализированными, так и низкодетализированными.\n* Низкодетализированные макеты - без цвета, без проработки визуала, каркас.\n* высокодетализированные макеты - финальный дизайн.", + "lastmodified": "2022-04-23T12:45:42.669238191+03:00", + "tags": null + }, + "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5": { + "title": "Проектирование", + "content": "Здесь собраны ссылки по методам и артефактам самого проектирования:\n\n* [Userflow](Userflow.md)\n* [Макет](%D0%9C%D0%B0%D0%BA%D0%B5%D1%82.md)\n* [Прототип](%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF.md)\n* [UI Kit](UI%20Kit.md)\n* [Дизайн-система](%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0.md)\n* [Accessibility](Accessibility.md)", + "lastmodified": "2022-04-23T12:45:42.670518229+03:00", + "tags": null + }, + "/Design/Design/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF": { + "title": "Прототип", + "content": "* Интерактивное представление интерфейса, которое показывает какую-то фичу в действии.\n* Низкодетализированный прототип = не финальный макет, каркас или от руки + интерактив.\n* Высокодетализированный прототип = финальный макет + интерактив.\n* Максимально реалистичное поведение = лучше прототип.\n* Прототипы сокращают кол-во вопросов от разработчиков, клиентов и менеджеров.\n* Их не трудно и не дорого сделать.\n* Это прямая обязанность дизайнера: уметь делать прототипы на каком-то уровне.", + "lastmodified": "2022-04-23T12:45:42.668439+03:00", + "tags": null + }, + "/Design/Design/Accessibility": { + "title": "Accessibility", + "content": "* Доступность это для государственных учреждений или социально значимых компаний/продуктов, а поэтому не паришься вообще. Соблюдай только базу.\n* База это минималка по [wcag](https://www.w3.org/WAI/standards-guidelines/wcag/), в которой основное это размеры шрифта и контрастность цветов.\n* Web accessibility directive и European accessibility act о веб доступности ЕС.\n* В сша есть directive 508 compliance.\n* Контрастность цветов проверяй плагинами.\n* Не использовать мелкие кегли, но тут уже имхо эпл забивает на это, но практика говорит не ниже 11-12px. Больше кегль = лучше.", + "lastmodified": "2022-04-23T12:45:42.667950027+03:00", + "tags": null + }, + "/Design/Design/Design-Token": { + "title": "Design Token", + "content": "* Это переменная, которую можно многократно как-либо использовать повторно.\n* Дизайн-токеном может выступать: размер отступа, цвет, стиль типографики, объекта, анимация.\n* Представлены в виде какого-то значения. Например цвет, как hex код или значение RGB или в контексте типографики это размер кегля и интерлиньяж. Для анимации это могут быть координаты безье.\n* Токены используются в [UI Kit](UI%20Kit.md).\n* Как записываются: как угодно, но например colorText (название токена) со значением #131313 может выступать как основной черный цвет для текста, иконок и т.д, т.е. есть имя токена + значени + описание.\n* [Тут](https://medium.com/@nathanacurtis) классный автор на тему дизайн-систем и дизайн-токенов.\n* Токенам лучше давать название как у разработчиков в коде - обычно они используют [camelCase](../../Development/camelCase.md), [kebab-case](../../Development/kebab-case.md), [PascalCase](../../Development/PascalCase.md). Благодаря этому говоришь с командой разработчиков на одном языке.", + "lastmodified": "2022-04-23T12:45:42.667798148+03:00", + "tags": null + }, + "/Design/Design/UI-Kit": { + "title": "UI Kit", + "content": "* Набор элементов интерфейса: кнопки, инпуты, чекбоксы, радио-кнопки, карточки, типографика, цвета и прочее со всеми состояниями.\n* Нужен для создания и поддержания в дальнейшем консистентности.\n* Нужен для экономии времени и денег на дизайн и разработку.\n* Нужен для скорости разработки, так как сделав 1 раз компонент можно его переиспользовать.\n* Основное, что должно быть в ui kit:\n * стили для цветов\n * стили для заголовков и наборного текста\n * сетка \n * отступы в блоках\n * кнопки \n * инпуты\n* Стили = [дизайн-токены](Design%20Token.md). Они должны быть, чтобы снизить уровень неконсистентности в продукте.\n* UI kit должен быть простым = атомарным. Читать тут в [оригинале](https://bradfrost.com/blog/post/atomic-web-design/) и [переводе](https://habr.com/ru/post/249223/).\n* Элементам лучше давать название как у разработчиков в коде - обычно они используют [camelCase](../../Development/camelCase.md), [kebab-case](../../Development/kebab-case.md), [PascalCase](../../Development/PascalCase.md). Благодаря этому говоришь с командой разработчиков на одном языке.\n* UI kit должен содержать правила для адаптива - как ведет себя дизайн при разной ширине экрана или на разных устройствах, если того требует проект.\n* UI kit должен соблюдать базовые требования по [Accessibility](Accessibility.md).\n* UI kit должен быть задокументирован: название элемента, описание, где применяется, состояния и размеры элемента, отступы внутри/снаружи, поведение на разных ширинах экрана, пример анимации (если есть).\n* Жестоко относится к фронтендерам, которые не соблюдают даже ui-kit - главная задача и цель по жизни для дизайнера.\n\nhttps://www.youtube.com/watch?v=VFpJzig5B4k", + "lastmodified": "2022-04-23T12:45:42.668152825+03:00", + "tags": null + }, + "/Design/Design/Userflow": { + "title": "Userflow", + "content": "#### Что надо знать\n\n* User flow - это в целом схемы о юзере: как он идет от одного сценария к другому. Это либо часть, либо весь путь в приложении. Это либо схема, либо гибрид из схемы и экранов. Еще проще: серия шагов, которые проходит юзер, чтобы достичь какой-то цели на сайте или в приложении.\n* Создавать можно на любом этапе.\n* Сценарий узнаешь от стейкхолдеров, подглядеть у конкурентов или проведя исследование.\n* Неважно сколько времени (мало или много) - рисуй схемы (task flow, userflow)\n\n#### Для чего рисовать?\n\n* Чтобы придумать интерфейс, которого еще нет. То есть, решить, какие вообще будут скрины, и пр.\n* Чтобы создать определенный опыт/конверсию.\n* Чтобы разобраться в очень сложной бизнес-логике.\n* Чтобы разобраться в каких-то сложных взаимодействиях.\n* Чтобы понять, какие метрики мне надо измерять.\n\n#### Что знать до рисования?\n\n* Цель (любая: создать аккаунт, выложить фото, поделиться фото, купить акцию, заказать доставку, проанализировать данные и т.д.).\n* Юзера (проблемы, цель, боли и т.д.).\n* Что должен сделать? (сценарий)\n\n#### Что рисовать?\n\n* Точку выхода - каков финальный и ценный шаг?\n* Точка входа - куда приземлится юзер(экран, состояние юзера)?\n* Основной путь - от конца к началу (не отвлекаешься, не грузишь деталями), т.е все шаги без которых точках выхода невозможна (нужен самый короткий путь).\n* Метрику - как поймешь что работает сценарий и есть конверсия (клик, посещаемость, время, деньги, колбэк, посещение стр. \"успешно/спасибо\", отправление письма, открытие письма, клики в письмах, показ экрана со ссылкой)?\n* Альтернативные пути. Пример: в карточку товара можно попасть и с главной, и со страницы категории, и с результатов поиска.\n\n![720](img/userflow-example.png)\n\n#### Чем отличается Task flow от Userflow?\n\nTask flow - это схема, которая показывает что делает любой пользователь на каждом шаге для выполнения цели или отдельной задачи. То есть путь не зависит от юзера, типа устройства, статуса клиента, количества действий и так далее, то есть это верхнеуровневая схема того что нужно сделать юзеру, ну простой линейный путь чтобы достичь конечной точки, простой ввод ввывод без ответвлений на состояния экранов. Скорее всего мне нужно было это уточнить мой косяк. Грубо говоря, я хочу приготовить пирог - это моя цель то таск-флоу следующий: я на главной странице, в поиск ввожу пироги, вижу результаты, открываю страницу пирога, то есть независимо от типа юзера я просто ищу рецепт, если надо еще проще то на примере регистрации таск-флоу может быть типа открыл форму регистрации, ввел данные, зарегистрировался.\n\n#### Чем отличается USM от Userflow?\n\n* Юзер флоу про то, как по шагам продвигается юзер в приложении, чтобы достичь цели. Фокус больше на тех. аспекте того как юзер будет использовать приложение. \n* Карта историй нужна чтобы доступным и простым способом описать требования с точки зрения юзера и приоритезировать их, разбив на релизы.\n\n#### Чем отличается CJM от Userflow?\n\n* Userflow это часть какого-то процесса в продукте или какая-то отдельная его задача, а cjm охватывает весь опыт в продукте причем с косяками на разных точках контакта.", + "lastmodified": "2022-04-23T12:45:42.668900639+03:00", + "tags": null + }, + "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F": { + "title": "Исследования", + "content": "# Исследования\n\n* Ты не пользователь, а еще не можешь знать всего в мире. Никто не можем взять и стереть из головы все о продукте и поставить себя на место пользователей. \n* Исследования помогают понять почему проект, продукт, фича или услуга кому-то нужны, кто его пользователи, насколько хорошо продукт решает их задачи, а также как и о чем они думают и почему делают то, что собственно делают.\n* Без исследований ты не можешь объяснить свои решения и выдавать хорошее качество и стабильный результат.\n* У исследования должна быть цель.\n* Если ты работаешь над внешним проектом для клиента, то надо понять и найти кто целевая аудитория у продукта.\n* Если ты работаешь над внутренним продуктом, то тут проще: внутри компании юзеры это окружающие тебя люди, поэтому в этом случае все попроще.\n\n## Первичное исследование\n\n* Всегда касается клиента и пользователей и собирается из первых рук. \n* Проводит дизайнер собирая сырую информацию, которую надо потом понять и проанализировать.\n* Стоимость таких исследований высокая и отнимает много времени.\n\n### Качественные данные\n\nОтвечают на вопросы почему люди делают то, что делают. Например «почему он не увидел призыв к действию»?\n\n#### Методы:\n\n* [Interview](Interview.md)\n* Наблюдение\n* Дневниковые исследования\n* Юзабилити тестирование\n* [Lean canvas](Lean%20canvas.md)\n\n### Количественные данные\n\nЗатрагивают все, что касается измерений в числах. То есть отвечают в основном на вопросы типа «сколько сюда кликнуло людей», «сколько % пользователей нашли эту кнопку»? или «сколько людей полюбили эту фичу» и т.д.\n\n#### Методы:\n\n* [Опросы](%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B.md)\n* [Card sorting](Card%20sorting.md)\n* A/B тестирование\n* Фокус-группы\n\n## Вторичное исследование\n\n* Сделано кем-то до тебя.\n* Его можно получить у кого-то со стороны (отчеты, бенчмарки, лучшие практики индустрии, журналы, библиотеки - гугл).\n* Информация частично/полностью подходит для работы: результат за малые деньги и время, но не всегда полезная информация.\n\n#### Методы:\n\n* Гуглить\n * Историю индустрии\n * почитать/купить отчеты/бенчмарки.\n * Лучшие практики индустрии и тренды\n* [Competitive analysis](Competitive%20analysis.md)", + "lastmodified": "2022-04-23T12:45:42.667397469+03:00", + "tags": null + }, + "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B": { + "title": "Опросы", + "content": "Дизайнер может замерить какой-либо показетель, проведя сам или согласовав с менеджером один из следующих опросов:\n\n* [NPS](NPS.md) - лояльность.\n* [CSAT](CSAT.md) - лояльность, удовлетворение.\n* [CES](CES.md) - усилие юзера на задачу.\n* [SEQ](SEQ.md) - сложность сценария.\n* [UMUX](UMUX.md) - лояльность, функциональность и простота продукта.\n* [SUS](SUS.md) - лояльность, удовлетворение.", + "lastmodified": "2022-04-23T12:45:42.658447659+03:00", + "tags": null + }, + "/Design/Research/CES": { + "title": "CES", + "content": "#### Что надо знать про ces\n\n* Customer Effort Score - оценка усилий клиента.\n* Есть 2 версии CES, тут про CES 2.0, который обновленный, правильный, точный.\n* Опросник похож на CSAT, но вместо вопроса о том, насколько юзеру понравился сервис/продукт/фича/процесс, спрашиваем о том, насколько легко/просто было решить вопрос/проблему самому или с помощью чего-либо.\n* Оцениваются именно усилия клиента, поэтому чем проще выполнение задачи, тем лучше опыт юзера.\n* Опрос из 1 вопроса: Эпл (обязательно название компании) сделала все, чтобы решить вопрос было легко?\n* Юзер ставит оценку от 1 до 7:\n * 1 - категорически не согласен\n * 7 - полностью согласен.\n* Как считать: суммируются все ответы / общее кол-во юзеров.\n* Пример: в опросе было 12 юзеров, суммарная оценка которых 71 балл. 71 / 12 = 5.9 ces.\n* Если ces от 1 до 3 - плохо. Юзеры крайне не согласны, что компания сделала все, чтобы процесс чего-либо был простым.\n* Если ces от 5 до 7 - все хорошо.", + "lastmodified": "2022-04-23T12:45:42.656368722+03:00", + "tags": null + }, + "/Design/Research/CSAT": { + "title": "CSAT", + "content": "#### Что надо знать\n\n* Customer satisfaction score - индекс удовлетворенности клиентов.\n* Помогает оценить качество работы компании на уровне какого-то рабочего процесса, а не в общем.\n* Опрос из 1 вопроса: насколько вы удовлетворенны (название рабочего процесса, фичи или еще что-то)?\n* Пример: насколько вы удовлетворены последней консультацией? Насколько вы удовлетворены взаимодействием с (название фичи)?\n* Юзер ставит оценку от 1 до 5.\n * 1 - юзер очень не доволен.\n * 2 - недоволен.\n * 3 - нейтрален.\n * 4 - доволен.\n * 5 - очень доволен.\n* Как считать: сумма кол-ва ответов по 4 и 5 баллам / общее кол-во ответов * 100.\n* Пример: 25 юзеров поставили 4. 15 юзеров поставили 5. Итого 42 довольных. В опросе в общем было 117 юзеров. 42 / 117 * 100 = ~36% индекс удовлетворенности.\n* Отличие от nps, csat - это оценка конкретного рабочего процесса/фичи по недавнему взаимодействую, а nps - общая оценка.\n* CSAT часто используется для оценки службы поддержки.\n* Хорошее значение csat зависит от продукта, поэтому помогает гугл своей отрасли или acsi - американский индекс обслуживания клиентов, который показывает базовые показатели для различных отраслей, секторов, брендов и компаний.", + "lastmodified": "2022-04-23T12:45:42.666884079+03:00", + "tags": null + }, + "/Design/Research/Card-sorting": { + "title": "Card sorting", + "content": "#### Что надо знать\n\n* Это исследование, в котором юзер сортирует карточки с названиями объектов по группам.\n* Помогает понять иерархию и то как юзер связывает между собой контент, а результат исследования сразу хорошо подходит для этапа проектирования при составлении [Informational Architecture](../Analysis/Informational%20Architecture.md). \n\n#### Зачем это нужно?\n\nПри проектировании сайтов и приложений часто требуется объединить разнородные объекты в иерархическую структуру. Карточная сортировка позволяет узнать преставление пользователей о структуре объектов и дать группам понятные названия. Карточная сортировка полезна для создания каталогов, информационной архитектуры, меню и навигации веб‑сайтов.\n\n#### Как это делается?\n\nНазвания объектов записываются на карточках или стикерах, а затем респонденты сортируют карточки исходя из своих представлений о структуре объектов и связях между ними. Затем исследователи анализируют результаты и выявляют закономерности. В варианте **«открытой»** карточной сортировки участники теста придумывают свои названия для групп объектов.\n\nВ **«закрытой»** сортировке названия групп известны участникам заранее. Им надо определить, к какой из предложенных категорий относятся объекты. «Закрытая» сортировка обычно используется для проверки, походит ли определённый набор категорий для распределения объектов.\n\nПри **«обратной»** карточной сортировке (или «tree testing»), проверяется существующая иерархическая структура. Участникам дают задания и предлагают найти подходящую карточку, перемещаясь по дереву категорий от верхнего к нижнему уровню. Такой тест проверяет работоспособность предлагаемой структуры, например, навигации или разделов сайта, без искажений реализации (внешний вид, подсказки и прочие).\n\nhttps://usabilitylab.ru/usability/kartochnaya-sortirovka/", + "lastmodified": "2022-04-23T12:45:42.665499537+03:00", + "tags": null + }, + "/Design/Research/Competitive-analysis": { + "title": "Competitive analysis", + "content": "---\n\n# Конкурентный анализ\n\nЭто способ собрать и сравнить данные о продуктах или компаниях на рынке, чтобы посмотреть какие сильные и слабые стороны у них есть, чтобы принять обоснованное решение уже относительно своего продукта. То есть благодаря этому анализу можно в целом, с высоты птичьего полета, понять то, какие у них предложения на рынке, монетизация, сильные и слабые стороны, сравнить со своими возможностями, а также это помогает определить типы клиентов и как эти клиенты этих продуктов решают свои задачи.\n\n**Зачем это дизайнеру?**\n\nЕсли ты проведешь конкурентный анализ, то повысишь знания в предметной области, сгенерируешь больше идей, сможешь оценить ситуацию продукта на рынке, в котором работаешь, а также оценить дизайн конкурентов. Ты сможешь понять сильные и слабые стороны, преимущества и недостатки, а также подтвердить свои решения в дизайне какими-то доказательствами на основе такого анализа. Также это может помочь разрешить проблемы в юзабилити и спроектировать лучшее решение.\n\n**Когда проводить конкурентный анализ?**\n\nНа самой ранней стадии проекта, то есть это этап исследования. В идеале у тебя должно быть первое обсуждение проекта со стейкхолдерами, которое может быть в виде простого разговора или встречи с ними где вы заполняете lean канву, а затем, в идеале, поговорить с потенциальными пользователями, чтобы проводить анализ конкурентов, понимая проблемы пользователей, как бы смотреть через призму их проблем и то как их решают конкуренты. Но как только у вас появится четко сформулированная пользовательская проблема, которую надо решить, так сразу будет просто легче понять, что любая фича конкурента-это всего лишь одно из возможных решений. Но учти, что периодически  можно повторять такой анализ в течение всего проекта, поскольку это зависит от ситуации ведь может возникнуть новый игрок на рынке, новые рыночные условия или у тебя и команды появятся новые идеи, перед реализацией которых хорошо бы посмотреть а пытался ли их кто-то реализовать.\n\n**Как провести конкурентный анализ?**\n\nТвой первый шаг это постановка целей. Спроси себя зачем ты делаешь конкурентный анализ? Чего ты хочешь достичь и что узнать? Любое исследование делается по какой-то причине.\n\n**Как можно найти проблему?**\n\nЯ уже по сути озвучил как, ведь из ролика к ролику я повторяю про общение: когда приходит задача, то ты можешь поговорить с тем кто ее дал, можешь пообщаться с командой стейкхолдеров, воспользоваться lean канвой, можешь провести интервью или опрос, можешь  провести карточную сортировку, составить персонажей или можешь найти информацию в интернете - тут важно понять что без цели и исследования - никак, ты не можешь без этого этапа, я про исследование и изучение проблемы, но ты можешь пропустить некоторые из этих артефактов при работе, поскольку это лишь инструменты и конкурентный анализ один из них.\n\n**Затем составь список конкурентов**\n\nСоответственно, после целей, составь список прямых и косвенных конкурентов. Это будет таблица, в которую ты будешь вписывать фичи своего продукта, а также от 3 до 10 прямых и косвенных конкурентов.\n\nПрямые конкуренты это компании, которые предлагают такие же решения как у вас, в той же области, возможно, по тем же ценам, чтобы закрывать потребности той же аудитории. Например, если мы проектируем сервис по аренде авто, то прямые конкуренты это аналогичные сервисы.\n\nКосвенные конкуренты это компании, которые предлагают другие или схожие решения, но которые нацелены на ту же аудиторию как у тебя, но проблему этой аудитории решают как я уже сказал по другому. Например, вместо аренды машины можно заказать такси, воспользоваться городским транспортом или арендовать или купить электросамокат или саму машину.\n\n**Как найти таких конкурентов?**\n\nСпроси своего клиента, владельца продукта или менеджера. Ищи по ключевым запросам в гугле, используй сервисы по типу SimilarWeb. Если это мобильное приложение то ищи в гугл плей для андроид и эпстор на ios, читая отзывы. Читай отзывы на сайтах компаний, в их социальных сетях, форумах или блогах, то есть опять же если у тебя не возможности напрямую связаться с аудиторией, то проведи вторичное исследование - поищи в интернете информацию.\n\n**По каким критериям сравнивать мой продукт и конкурентов?**\n\n**Точного ответа нет, поскольку тебе нужно исходить из целей такого анализа. Может быть ты анализируешь как сделана навигация или онбординг у конкурентов или целиком продукт, поэтому тут нет однозначного ответа.**\n\nНо я уже сказал ранее что это таблица, где ты выписываешь фичи конкурентов, но в эту таблицу можно включить не только фичи, но и другие элементы, например: элементы пользовательского интерфейса, например есть ли у конкурентов фильтрация? Сортировка? Поиск? Рейтинговая система или система рекомендаций? Добавить в избранное? и прочее. Такие вещи можно пометить простыми словами да/нет\n\nМожно включить цену. Какие тарифные планы они предлагают? Подписка? Единоразовая оплата и так далее. Укажи конкретное значение.\n\nМожно указать ключевые разделы в навигации.\n\nМожно выписать одну две цитаты про то, что пользователи говорят о качестве продукта или услуги в отзывах?\n\nМожет быть тебе стоит еще описать клиентский сервис. Как они построили взаимодействие с клиентами? Через какие каналы? Чат на сайте, телеграм бот и так далее.\n\nМожно выписать часы работы. Например когда и как часто они отвечают своим клиентам в чатах, службе поддержки и вообще через какие каналы? Ведь они могут отвечать просто через email.\n\nМожно указать какие-то числа, например как много сотрудников? Как много пользователей? Сколько продаж? Если эти данные ты сможешь найти.\n\nМожно указать какие сильные стороны: например у конкурента номер один отличный и удобный сайт, у второго конкурента акцент на безопасности персональных данных, у третьего прекрасный онбординг, у четвертого прекрасная служба поддержки, а у нас например лучшая производительность потому что мы используем самые новые технологии. Ведь помни о том, что ты обязан выписывать что-то в каждый пункт и про свой сервис.\n\nТакже можно указать слабости, например у нас малое количество каналов в социальных сетях, а у конкурента номер один сложная документация и так далее.\n\nМожно указать какие платформы имеются у конкурентов, например только мобильные приложения или только веб, или и то и другое, а тогда где лучше проработано взаимодействие? Посмотри и попользуйся сервисами конкурентов. Также обрати внимание на адаптивную версию сайтов, может у них вообще это не проработано, тогда может нам сделать и выдать за сильную сторону, а может быть аудитории такой вовсе нет?\n\nТакже не забывай делать скриншоты, чтобы изучить и сделать комментарии что плохого или хорошего ты нашел в каком-нибудь блоке или фиче в контексте сценария, фичи или способа взаимодействия\n\n**После сравнение посмотри на результат анализа и выдели обязательные функции**\n\nЕсли ты обратишь внимание, то некоторые фичи есть у всех, это значит то, что есть фичи, которые по умолчанию должны присутствовать в твоем продукте иначе он уже будет не конкурентно способным и это звоночек, чтобы оценить возможность реализации своего продукта. Например представь что у телеграма не было бы возможности отправки личных сообщений, звучит дико и кто бы этим стал пользоваться. Но с другой стороны исторически во многих продуктах повторяются функции, которые не используются, но у всех есть, потому что кто-то когда-то сделал ее первой, а остальные повторили. В то же самое время обрати внимание на функциональность, которая есть только у твоего продукта, потому что это повод задуматься о том чтобы повторно оценить спрос и нужность таких фичей, ведь их либо ниукого нет, либо они мало у кого есть.\n\n**В конце не забудь подготовить отчёт по анализу**\nТут достаточно просто подготовить файл с кратким изложение целей и выводов — это должно включать проблему пользователя, которую ты ранее обговорил с клиентов, обнаружил в интервью с пользователями или же вписал в lean canvas. После этого укажи список из самых опасных конкурентов, затем список рекомендаций и дальнейших шагов. Приложи ссылку на саму таблицу и скриншоты, которые ранее собрал.", + "lastmodified": "2022-04-23T12:45:42.657049909+03:00", + "tags": null + }, + "/Design/Research/Interview": { + "title": "Interview", + "content": "Привет, сегодняшний выпуск про ответы, которые ты получаешь, когда задаешь вопросы потенциальным клиентам или пользователям во время интервью. Поэтому давай сразу проясним то, что не надо спрашивать насколько твоя идея хороша, по крайней мере не надо спрашивать используя эти слова. Вопрос \"как тебе моя идея\" неудачен сам по себе, поскольку подталкивает отвечающего ко лжи, потому что никто никого не хочет расстраивать. Самый простой пример это когда ты хочешь поделиться какой-то идеей с другом, например задав такой вопрос: у меня родилась идея нового бизнеса, могу я ее с тобой обсудить? Ты по сути открываешься другу а он не хочет расстраивать, он хочет подбодрить или похвалить тебя. То есть разумеется друг будет лгать, в хорошем смысле, но тебе надо уметь уклоняться от этого. Дело не в том, что это плохо или хорошо, а в том, что подобные вопросы не помогают тебе понять нужен ли продукт пользователям.\n\nДальше будет хуже будет если ты продолжишь задавать неправильные вопросы опять же пример, где ты только что попросил у друга выслушать твою идею и продолжаешь: Ты ведь пользуешься своим айфоном и он тебе нравится? Друг отвечает да, потому что ты подсказал ответ и он ответил. И так как у тебя есть бизнес-идея или гипотеза, в которой уже есть ответ, ты спрашиваешь: А купил бы ты для своего айфона приложение для бега? Друг: ну не знаю. А смысл его ответа в том, что твой друг задумался, ведь он профессиональный бегун, нужно ли ему приложение в принципе или зачем ему еще одно приложение для бега. Но ты продолжаешь рассказывать про свою идею, набор функциональности своего приложения. И смысл такого общения лишь в том чтобы выпытать у друга похвалу, чтобы убедиться в своей якобы правоте, что и делает друг, говоря тебе классная идея и, чтобы показаться заинтересованным, может предложить что-то, что первым делом приходит в голову по части функциональности из других приложений.\n\nЭто опасная дорожка, ведущая в пропасть, где продукт нравится тебе одному и тебе кажется, что он нравится вообще всем в мире. Это проблема эмоциональной привязанности, ведь по факту не важно, что ты думаешь о продукте. Если продукт нравится тебе, это не значит то, что он нравится всем, поэтому нельзя делать продукт сразу для всех, надо сегментировать аудиторию и задавать правильные вопросы. Есть исследование, подтверждающее мои слова, в котором опубликованы 20 причин провалов стартапов и если учитывать эту статистику, то зачастую стартап гибнет потому что продукт никому не нужен, а не потому что он был в каком-то виде плохой. Эту мысль сложно осознать всем и я не исключение. Всегда ведь хочется верить в успех своих идей, продуктов. Эта мысль закрепляется в голове до тех пор, пока мы не столкнётся с реальностью, то есть с первыми пользователями. Редко какой бизнес-план выдерживает удар этой встречи. Поэтому надо как можно раньше тестировать идеи с пользователями в реальности и получать отзывы. Для этого надо задавать правильные вопросы.\n\nПравильные вопросы это достаточно простые действия. Эти действия можно выделить в несколько пунктов, если точнее, то надо говорить с пользователями о жизни, а не о твоих продукте и идеях. Под жизнью надо понимать процессы пользователей. А также учитывать то, что важен их опыт, а это всегда прошлое, поэтому говорить надо о прошлом, а не о будущем, и конечно больше слушать. И это всего 3 пункта, о которых говорит нам Роб Фитцпатрик автор книги Спроси маму. Эта книга учит, как правильно задавать вопросы и получать ответы, а это видео своеобразный конспект книги и вольное рассуждение на тему. Сразу скажу, что книга не сделает из тебя гуру интервью, но это базис без которого никуда, если ты хочешь начать проверять гипотезы.\n\nСамый простой способ начать это интервью с пользователями. Для этого быстро пройдемся по главным мыслям книги, это: спрашивать о жизни (процессах), спрашивать о прошлом (опыт) и больше слушать (не подсказывать, не провоцировать, не убеждать).\n\nИтак, разговор о жизни, то есть о процессах это про то, какие боли были и есть у пользователя. Например, можно спросить как он пытался и пытается их решить сейчас? Пусть он покажет как и что делал для решения проблемы? А ты понаблюдаешь. Что, то есть какие продукты может уже были испробованы для решения проблемы? Какой бюджет был потрачен на это или сколько за решение платит сейчас? Какие расходы он понес? Самое прикольное то, что спросив например \"искал ли решение\", то если ответ искал, то проблема есть, а если не искал, то ее нет. ведь если он поныл о чем-то, но не принялся решать проблему хотя бы из говна и палок, или не платил кому-то, то проблемы то наверное и нет. А проверить это легко, ведь действительно принимал какие-то попытки, то можно спросить опять же сколько стоило решение, где именно купил, когда?\n\nГлавное не дави на пользователя убеждая в своих идеях, то есть не спрашивай \"как тебе кажется это хорошая идея?\", потому что только рынок ответит на этот вопрос. Все остальное это чьи-то мнения. Исключение только если человек, которого ты спрашиваешь это рыночный эксперт.\n\nЕсли ты был сейчас внимательным, то заметил что я приводил примеры вопросов о прошлом и настоящем, по типу пытался ли юзер решать проблему? А если пытался то как он решал ее в последний раз? Какие средства были потрачены? Сколько времени это занимает? Если проблему он до сих пор не решил, то почему? Пытался ли он хотя бы загуглить ее? Ведь если инфы о прошлом нет, то проблемы нет, а все вопросы \"купил бы ты фичу Х за Y денег\" это пустая болтовня, а ответ \"да\" от пользователя оптимистичная ложь, поскольку нам всем легко сказать что \"с понедельника я сяду на диету\". Поэтому спрашивай о реально происходящих вещах и процессах сейчас или о прошлом, потому что если человек не пытался уже решать проблему самостоятельно, то он и не обратит внимания и не купит твое решение. Даже если это запрос новой функциональности, то копай глубже, спрашивая зачем она нужна? какие действия ты сможешь выполнить, если мы ее внедрим? как справляешься без нее сейчас? Кому она еще нужна? То есть с кем тебе еще поговорить об этом?\n\nПо части вопросов думаю понятно теперь что да как. Вопросы в целом могут быть любые, важно понимать ответы на них. Например если после общения ты получаешь комплимент или у тебя не появляются дополнительные вопросы, или тебе не задают неудобные вопросы, то разговор зашел не туда, а все это была дружеская беседа без пользы для твоей цели. Поэтому избегай комплиментов, обобщений и разговоров о будущем. В целом, встреча прошла не очень, если ты после нее не знаешь что делать дальше.\n\nПосле общения, нужно интерпретировать и передать то что сказал собеседник команде. Донести тезисы, которые передал пользователь, учитывая даже эмоции. Для этого нужно делать пометки, записывать на аудио или видео интервью, если юзер не против. Если возможности поставить аудио- или видео связь нет, то надо хотя бы делать пометки.\n\nВ целом вот и все, теперь прочти книгу или послушай ее аудиоверсию и начни говорить с пользователями. Главное помни, что интервью надо делать постоянно и они должны быть дешевыми, то есть их цена это максимум твое время, но сам процесс не кончается после одного, двух, пяти или десятка интервью. Интервью это качественное исследование чтобы выявить паттерны, причины и инсайты. Чтобы это интервью провести, нужно подготовиться, а для этого надо понять есть ли проблема у пользователя, задавая вопросы о процессах и прошлом, поэтому подготовь вопросы или тезисы, а дальше только слушать, задавая открытые вопросы. Вспоминаем, что есть 2 типа вопросов: закрытые и открытые. Закрытые это про верно или неверно, да или нет, короче про ограниченное число ответов. Открытые вопросы это про качественные данные, про паттерны, причины, инсайты.\n\nПосле интервью, нужно понять дальнейшие действие и проанализировать результаты с командой. Например. можно заново на основе новых данных создать решение, допустим пересобрать лендинг или какую-то функциональность задизайнить по другому, чтобы повторить процесс и снова научиться чему-то новому\n\n**Итого**\n\nВообще, забавно то, что я сейчас рассказал про один единственный инструмент - интервью, а ведь их так много.\n\nJobs to be done, use case, cjm, юзабилити-тестирования (модерируемые, немодерируемые, очные и удаленные), опросы и прочее.\n\nвыбрал cjm? ну хорошо переноси все данные на путь клиента. любишь использовать сценарии, то есть use case, то окей прописывай их исходя из понимания пользователя. Нравится jobs to be done? Снова хороший инструмент и можешь использовать его, чтобы соединить всю информацию, чтобы в итоге у тебя появился список работы пользователя, на которые, собственно, он нанимает твой продукт.\n\nКасдев, раз уж я упомянул, это customer development, это такой подход, фреймворк про поговорить опять же до того как планировать и непосредственно реализовывать продукт. То есть способ для понимания своего рынка и потребностей пользователей для того, чтобы развивать продукт.\n\nКнига: ссылка\n\nПричины провалов стартапов: [https://www.cbinsights.com/research/startup-failure-reasons-top/](https://www.cbinsights.com/research/startup-failure-reasons-top/)\n\nКанва бизнес-модели Остревальдера и Пинье\n\n[https://vc.ru/flood/42281-gid-po-customer-development-dlya-produktovyh-menedzherov](https://vc.ru/flood/42281-gid-po-customer-development-dlya-produktovyh-menedzherov)\n\n[https://vc.ru/flood/44550-polzovatelskie-intervyu-kogda-oni-nuzhny-i-kak-sdelat-ih-effektivnymi](https://vc.ru/flood/44550-polzovatelskie-intervyu-kogda-oni-nuzhny-i-kak-sdelat-ih-effektivnymi)\n\n[http://s.muz.li/ZGRlMmE0ODVi](http://s.muz.li/ZGRlMmE0ODVi)\n\n[https://livesession.io/blog/post/guide-to-qualitative-ux-research/](https://livesession.io/blog/post/guide-to-qualitative-ux-research/)\n\n[https://uxdesign.cc/the-ultimate-notion-template-to-run-efficient-usability-tests-4a5ed9c29443](https://uxdesign.cc/the-ultimate-notion-template-to-run-efficient-usability-tests-4a5ed9c29443)", + "lastmodified": "2022-04-23T12:45:42.65802548+03:00", + "tags": null + }, + "/Design/Research/Lean-canvas": { + "title": "Lean canvas", + "content": "**Lean canvas**\n\nКакую проблему мы будем решать? Для какого сегмента аудитории? Что мы будем проектировать, то есть какое решение? Где мы будем находить пользователей, то есть через какие каналы мы будем доносить ценность продукта?  Как мы будем зарабатывать на этом? Сколько надо потратить для этого? Ответы на эти вопросы помогает получить бережливый шаблон бизнес модели или короче Lean Canvas, в котором можно отразить всю основную информацию или идею о новом продукте или даже функциональности.\n\n**Немного истории**\n\nСуществует вообще два шаблона, то есть две канвы для построения бизнес-модели: канва от Александра Остервальда и от Эша Маурья, о которой я буду говорить. Но почему вообще появились такие шаблоны - это просто, потому что никто не читает бизнес-планы. Люди тратят уйму часов, чтобы написать подробный бизнес план, который просто нужен, чтобы изложить идею нового продукта, а затем отправляют его прямиков в корзину, потому что никто его не прочитал или прочитал, но идея не зашла.\n\nЕсли поведать тебе немного об истории появления Lean Canvas, то в начале был и до сих пор есть шаблон бизнес модели от Александра Остервальда, но потом Эш Маурья адаптировал его под современные реалии и процессы.\n\nАдаптировать пришлось, потому что в шаблоне Остервальда не было пользы для стартапов, то есть для любого молодого бизнеса, который создаётся для реализации какой-либо идеи. Шаблон же Остервальда был разработан больше для офлайн-бизнеса и даже больше для устоявшегося бизнеса, чтобы помочь ему найти возможности для роста, а сейчас ни для кого не секрет и не новость, что все стремятся в онлайн, а это новые продукты или трансформация устоявшегося бизнеса, другие технологии и другие процессы при разработке. И при разработке новых продуктов есть много неопределенностей и рисков. По этой причине людям в некоторые ячейки шаблона Остервальда просто нечего было вписать, поскольку у стартапов нет ключевых партнеров и каналов сбыта в начале пути.\n\nНо это не значит то, что Lean канва подходит только для стартапов, поскольку сам автор, Эш Маурья заявляет что это рабочий метод и за пределами начальных стадий бизнеса, а также я не хочу сказать то, что шаблон Остервальда не актуален. Но в частности мне Lean canvas нравится больше, чем шаблон от Остервальда, поэтому я и хочу рассказать именно о Lean Canvas, но учти что любой шаблон можно подстроить под себя, ведь это лишь инструмент, чтобы продумать начальную идею продукта или донести ее до стейкхолдеров в простом формате. Это не готовый и не полноценный бизнес-план.\n\n**И соответственно от сюда вытекает вопрос что это за формат? Из чего состоит шаблон и как его заполнять?**\n\nВ общем, Lean Canvas состоит из 9 блоков, которые нужно заполнить одному или в кругу стейкхолдеров, а затем расставить приоритеты в каждом блоке.\n\nСразу хочется отметить, что это больше командный метод, но можно заполнять одному, чтобы зафиксировать свои идеи и в последствии презентовать. Что же касается заполнения шаблона командой, то есть трудности, ведь руководству, владельцу продукта и даже отдельным лидам будут потворствовать и не будут с ними спорить, но чтобы избежать это - нужно просто раздать каждому стикеры, на которые все запишут идеи,  молча и за определенное время по таймеру в каждый блок. Таймер тут нужен для того чтобы выжать максимум и не затягивать процесс генерации идей и их обсуждения после. Это поможет избавиться от описанной проблемы и сгенерировать как можно больше разных идей, думая о продукте, а не о том что скажет твой лид. Для каждого блока достаточно 5-7 или 10 минут.\n\n**Первый блок - Потребительские сегменты**\n\nВ первом блоке Эш Маурья предлагает нам определить целевую аудиторию продукта, то есть сегменты пользователей, то есть кто наш клиент, кто наш пользователь? Даже если у вас продукт \"который нужен всем\", хотя это ошибка, то все равно нужно с кого-то начинать. Это лучше, чем пытаться делать для всех и сделать неудобно для всех. Об этом надо думать, а еще нужно подумать о том кто будет пользоваться и кто платит за продукт, поскольку иногда это разные люди. Клиент может купить разработку, а пользоваться будут его сотрудники и такие вещи надо записать отдельно - это разные сегменты. Поэтому один или с командой подумай над сегментами потребителей и выпиши их в этот блок.\n\nЗатем чуть ниже в этом же блоке есть Early adopters, в переводе первые пользователи- это люди, которые будут первыми использовать продукт и таких людей надо определить сразу. Это особенно важно для определения функциональности, которая пойдет в MVP. Это аудитория, которая в первую очередь будет заинтересована в твоем продукте и которая будет первой давать обратную связь, а именно решает ли твой продукт или фича их проблему или нет. И вот как раз таки о проблеме ты уже можешь написать во втором блоке, который так и называется - Проблема.\n\n**То есть во втором блоке попробуй ответить на то: какую проблему мы решаем разрабатывая продукт для данного сегмента аудитории?**\n\nТо есть в чем есть проблема клиента? Достаточно записать 3 основные проблемы. Узнать это можно как раз таки у тех самых ранних пользователей, которых мы записали и приоритезировали с первого блока, потому что они будут первыми, то есть надо будет потом, когда будет готов прототип или до этого найти таких людей, пойти к ним и задать вопросы. Напоминаю, ролик с рекомендацией книги про интервью и о том как задавать вопросы на канале есть. Можно конечно строить и догадки, поскольку расписав все сегменты из первого блока, то можно сформулировать гипотезы о том, какую проблему для этих сегментов будет закрывать продукт. Таким образом провести вторичное исследование и понять предметную область, а также то как эту проблему решают другие? Потому что в этом блоке есть раздел, куда надо записать список компаний, которые решают твою проблему или косвенно связанны с ней. Любую проблему так или иначе уже кто-то пытался решить. Ещё поможет техника 5 почему, чтобы лучше докапываться до проблемы. Это элементарная техника, где ты задаешься вопросом почему от 3 до 5 раз, чтобы докопаться до первопричины проблемы. Условный пример проблемы: низкая удовлетворенность клиентов, а почему? Потому что процесс оформления на сайте долгий, а почему? Потому что в форме много полей, а почему? Потому что того требует установленная система crm, а почему? И так далее.\n\n**А далее по Lean canvas блок про Источники дохода**\n\nМы уже определили сегменты и проблему, но если эти проблемы нельзя монетизировать, то тут нельзя говорить о жизнеспособной бизнес-модели. Поэтому надо ответить на вопрос на чем бизнес будет зарабатывать? Бизнес не является стабильным без выручки, но также надо понимать что на старте в любом случае не будет резкого старта в доходах. Но подумать над тем, как бизнес будет зарабатывать - это важно. Поэтому подумай о том как продукт будет монетизироваться: а именно будет ли это подписка с пробным периодом, единоразовая оплата, или же размещение рекламы в продукте, или заработок на комиссиях или экономия средств компании за счет автоматизации и так далее. Опять же тут будет полезно определить сразу кто клиент? Вспомни что я говорил ранее о том, что клиент, который платит за продукт это не всегда пользователь продукта. И опять же, идеи по монетизации можно обсудить с ранними пользователями спросив их готовы ли они будут платить за то, что ты предлагаешь, и опять же можно посмотреть на конкурентов и их систему монетизации.\n\n**Следом идет блок под названием \"решение\"**\n\nВ общем-то здесь надо написать основные возможности продукта, с учетом записанных проблем, то есть как мы будем решать эти проблемы? Можно здесь полагаться на своё видение, а можно провести опять же интервью с ранними пользователями, чтобы показать прототип.\n\n**Следом идет блок про уникальную ценность**\nКогда будет список из возможных решений, тогда надо его как-то уникально упаковать. То есть в этом блоке надо написать конкретное, короткое сообщение для клиента о том, чем продукт лучше остальных? Это утп - уникальное торговое предложение, которое надо сформулировать в этом блоке. Но учти что это про маркетинг, это рекламная фраза или посыл, или обещание пользователям, а не про решение. Чуть ниже в этом блоке надо написать аналогию, то есть с чем ассоциируется твой продукт. Например, ютуб это фликр, но для видео. Или горячая пицца за 30 минут или пицца бесплатно. Или получи работу мечты за 30 дней. Или стань дизайнером за 3 дня пройдя мой платный марафон.\n\n**После этого надо заполнить блок каналы продаж**\nТут надо ответить на вопросы: Какие каналы мы можем использовать, чтобы донести продукт до пользователей, чтобы они могли решить свою проблему, используя наш продукт? Какими каналами коммуникации они пользуются? Как принимают решения? И тут две категории, чтобы достучаться до потребителей: первая, где наш продукт находят сами, а это ведение блога, seo оптимизация, проведение вебинаров или же наоборот, вторая категория, где мы сами находим потребителя через покупку рекламы, создание выставок, холодные звонки, интервью и прочее. Также стоит подумать о возрасте аудитории. Вот картинка, думаю из нее предельно понятно то, что реклама по телевизору для молодого поколения не актуальна в наши дни, а например в тик-токе, что и делают бренду вполне актуальный канал или можно сказать точка касания с аудиторией.\n\n**Затем идет следующий блок - метрики**\nТут важно ответить на вопрос: Какие метрики помогут замерить успех фичи или продукта? Подумай над тем, что будет минимальным критерием для успеха мвп? Какой минимальный результат можно считать успешным в ближайшие 3 года или меньше? Чтобы разобраться немножко в метриках посмотри видео про основы юнит-экономики и про фреймворк пиратских метрик на моем канале.\n\n**После этого надо определить следующий блок - Структура затрат**\nКакие затраты нужны для запуска данной бизнес возможности? Покупка хостинга и домена? Затраты на персонал? Стоимость привлечения клиента и другие траты, которые можно проанализировать параллельно с доходами, чтобы понять действительно ли при таких затратах и ожидаемых доходах мы выходим на какие-то выдающиеся показатели? Какое количество клиентов для этого нужно? Где будет точка хотя бы безубыточности?\n\n**Последний блок - это уникальное преимущество.**\nЭто то, что выделяет продукт, то есть смысл блока в том, чтобы написать почему его нельзя легко скопировать или купить. Например, нельзя скопировать команду, авторитет бренда, сообщество вокруг продукта, высокие позиции в поисковой выдаче, патенты, инсайдерскую информацию, поэтому это очень сложный блок, в который сходу трудно что-то записать и это нормально оставить его пустым и заполнить позже.\n\nКогда ты заполнишь сам или с командой шаблон, то надо проверить идею на потенциальные риски. Чтобы план был успешен, он должен балансировать между тремя типами рисков: продуктовым, пользовательским и рыночным.\n\nПродуктовый риск связан с переоценкой проблемы, то есть решаем проблему, которой нет или это связано с самим плохим решением. Если есть ощущения что риск может быть связан с продуктом, то надо строить MVP и тестировать.\n\nПользовательский риск это когда мы неправильно выбрали аудиторию и ранних пользователей, а также неправильно выбрали каналы, по которым они должны узнать о продукте. Если есть ощущения, что риск связан с пользователями, то достаточно прототипа и интервью с пользователями.\n\nРыночный риск это когда мы недооценили конкурентов и наш бизнес не может конкурировать, не устойчив и не масштабируемый. Если есть ощущения, что риск связан с рынком, то тут понятное дело что надо просто сделать что-то, выпустить это на рынок, то есть запуститься и смотреть куда идут метрики - вверх или вниз.\n\nТеперь давай рассмотрим пример заполнения.\n\nВот и всё, и помни, что порядок блоков и порядок заполнения ты можешь менять и для этого я оставил ссылки на эту тему в описании под видео, а еще ты можешь использовать и вовсе шаблон Остервальда - это лишь инструменты. Пользуйся, а на этом у меня всё - пока.\n\nПересказ книги о стартапах Эша Маурья: [https://habr.com/ru/post/243263/](https://habr.com/ru/post/243263/)\n\nСтатья о Lean Canvas: [https://nikolayzaostrovtsev.medium.com/lean-model-canvas-theory-224d18eaa640](https://nikolayzaostrovtsev.medium.com/lean-model-canvas-theory-224d18eaa640)\n\nLean canvas и санта-клаус: [https://ru.wiki.rademade.com/lean-canvas-santa](https://ru.wiki.rademade.com/lean-canvas-santa)\n\nОт автора Lean Canvas про сравнение и причину создания: [https://blog.leanstack.com/why-lean-canvas-vs-business-model-canvas/](https://blog.leanstack.com/why-lean-canvas-vs-business-model-canvas/)\n\nПро странный порядок заполнения Lean canvas от автора: [https://blog.leanstack.com/what-is-the-right-fill-order-for-a-lean-canvas/](https://blog.leanstack.com/what-is-the-right-fill-order-for-a-lean-canvas/)\n\nПро перестановку в заполнении от автора Lean canvas (eng): [https://blog.leanstack.com/reorder-your-chain-of-beliefs-with-a-leaner-lean-canvas/](https://blog.leanstack.com/reorder-your-chain-of-beliefs-with-a-leaner-lean-canvas/)\n\nИспользовать лучше канду Остервальда или Маурьи (eng): [https://www.emergn.com/blog/business-model-canvas-lean-canvas/](https://www.emergn.com/blog/business-model-canvas-lean-canvas/)\n\nПро риски (eng): [https://www.playinglean.com/blogs/playing-lean-blog/what-is-the-risk-iteration-path](https://www.playinglean.com/blogs/playing-lean-blog/what-is-the-risk-iteration-path)", + "lastmodified": "2022-04-23T12:45:42.665042024+03:00", + "tags": null + }, + "/Design/Research/NPS": { + "title": "NPS", + "content": "#### Что надо знать\n\n* Net promoter score - индекс потребительской лояльности.\n* Опрос из 1 вопроса: Насколько вероятно, что вы посоветуете нашу компанию друзьям или коллегам?\n* Это оценка степени удовлетворенности и лояльности.\n* Юзер ставит оценку от 0 до 10 - 11 бальная шкала.\n* Респондентов делят на три категории: критики, нейтралы, промоутеры.\n * Критики (ставят 0 до 6) - недовльные клиенты, замедляют рост компании, пишут плохие отзывы.\n * Нейтралы (ставят 7 и 8) - незаинтересованные, игнорируют акции, могут не вернуться 50 на 50, легко уходят к конкурентам.\n * Промоутеры (ставят 9 и 10) - лояльные и довольные клиенты, делают повторные покупки и рекомендуют продукт.\n* Как считать: NPS = % промоутеров - процент недовольных (нейтралов не считать).\n* Пример: в опросе 560 чел-к. 30% поставили от 1 до 6. 20% поставили 7 и 8 баллов, а остальные 50% 9 и 10 баллов. Итого 50% - 30% = 20% nps.\n* Если nps от -100% до 0% - все плохо.\n* Если nps от 0% до 30% - все хорошо.\n* Если nps от 30% до 70% - все отлично.\n* Если nps от 70% до 100% - все прекрасно.\n* % nps зависит от типа бизнеса продукта. Чтобы узнать - гуглить.", + "lastmodified": "2022-04-23T12:45:42.65615634+03:00", + "tags": null + }, + "/Design/Research/SEQ": { + "title": "SEQ", + "content": "#### Что надо знать\n\n* Single ease question - один вопрос о сложности сценария.\n* Опрос из 1 вопроса: оцените в целом было ли взаимодействие простым?\n* Опрос можно сделать внутри продукта, сразу после целевого действия или задания в тесте.\n* Юзер ставит оценку от 1 до 7.\n * 1 - очень сложно.\n * 7 - очень легко.\n* Пример: юзер изменил данные в аккаунте и настроил его. Сразу после этого можно спросить юзера: \"В целом насколько сложно было настроить аккаунт?\" И он выбирает балл от 1 до 7.\n* Как считать: также, как и CES - среднее арифметическое. Все ответы суммируются / общее кол-во ответов.\n* Нормальный показатель 5.5, а если выше - лучше.\n* [Доказана корреляция с sus](https://measuringu.com/single-item-sus/).\n* SEQ vs CES\n * SEQ - про конкретныый шаг на пути к выполнению чего-либо.\n * CES - про глобальную цель или рабочий процесс/фичу в целом\n * Можно использовать либо seq, либо ces.", + "lastmodified": "2022-04-23T12:45:42.65659927+03:00", + "tags": null + }, + "/Design/Research/SUS": { + "title": "SUS", + "content": "**SUS и SEQ**\n\n* System Usability Scale - опрос из 10 вопросов\n* Результатом опроса будет максимально объективная оценка юзабилити интерфейса от 0 до 100.\n* Это отличный метод, но долгий, поэтому тут юзеры чаще отваливаются и врут, потому что чаще всего надо вознаграждать юзеров за потраченное время, а юзеры побыстрее хотят получить награду.\n* Чаще всего избыточен, хотя это стандарт индустрии, который работает 30 лет\n* Полезен, чтобы повысить надежность данных юзабилити тестирования. Поэтому использовать если есть время и нужны весомые доказательства.\n* На каждый вопрос юзер ставит оценку от 1 до 5.\n * 1 - категорично не согласен.\n * 5 - полностью согласен.\n* Вопросы:\n 1. Я хотел бы постоянно использовать эту систему.\n 1. Я считаю систему излишне сложной.\n 1. Я полагаю, что система проста в использовании.\n 1. Мне понадобится помощь технического специалиста, чтобы использовать эту систему.\n 1. Функции в этой системе интегрированы качественно.\n 1. В этой системе слишком много непоследовательности.\n 1. Большинство людей научатся использовать эту систему очень быстро.\n 1. Я считаю систему очень неудобной в использовании.\n 1. Я чувствую себя очень уверенно, используя систему.\n 1. Мне нужно узнать много новой информации, прежде чем я смогу начать работать с этой системой.\n* Как считать:\n * Из нечетного ответа вычесть 1. Пример: юзер отвечает 5, то 5 - 1 = 4.\n * Для каждого четного ответа вычесть 5. Пример: юзер отвечает 4, то 5 - 4 = 1.\n * Все полученные значения сложить * 2.5.\n * В итоге полученный результат будет итоговой оценкой удобства вашего интерфейса на юзера.\n * Затем подсчитать среднее по всем юзерам.\n* Средний результат 68 баллов - все нормально.\n* Если ниже 68, то уже повод думать и улучшать интерфейс.\n* Все что выше 68 - хороший результат.\n* Измерять sus надо бы хотя бы 1 раз в квартал.\n* Помимо баллов, есть оценка буквами: a, b, c, d, f. A - 80+. B - 68-80. C - 68. D и F - все плохо, меняем интерфейс.\n* Применять после юзабилити тестирования.", + "lastmodified": "2022-04-23T12:45:42.663255012+03:00", + "tags": null + }, + "/Design/Research/UMUX": { + "title": "UMUX", + "content": "#### Что надо знать?\n\n* Usability Metric for User Experience или UMUX. \n* Опросник для измерения функциональности и простоты продукта.\n* Есть две версии: обычный UMUX (4 вопроса) и UMUX-Lite (2 вопроса).\n* Подходит для юзабилити тестов, т.е после теста пуляешь в юзера опрос и он отвечает. \n* Это альтернатива SUS. Поскольку можно внедрить сразу на сайт или в приложение, ведь это всего лишь 4 или 2 вопроса, а не десять.\n\n##### UMUX\n\n* 1 вопрос: возможности этого сайта, продукта, софта, прототипа полностью удовлетворяют моим потребностям.\n* 2 вопрос: использование сайта, продукта, софта, прототипа это разочаровывающий опыт.\n* 3 вопрос: Этот сайт, продукт, софт, прототип легко использовать. \n* 4 вопрос: мне пришлось потратить слишком много времени чтобы использование сайта, продукта, софта, прототипа стало удобным. \n* Юзер ставит оценку от 1 до 7 каждому вопросу.\n * Если 1 - совершенно не согласен.\n * Если 7 - полностью согласен.\n* Как считать: почти как SUS\n * Для нечетных вопросов: оценка - 1 (юзер поставил 3 - 1 = 2). \n * Для четных вопросов: 7 - оценка (7 - юзер поставил 4 = 3).\n * В итоге получаются значения от 0 до 6 по каждому вопросу.\n * Затем сложить все 4 значения / 24 (это макс. возможная сумма) * 100.\n * После посчитать так по каждому юзеру в опросе и выделить среднее значение.\n\n##### UMUX-Lite\n\n* Состоит из 2 вопросов.\n* 1 вопрос: возможности этого сайта, продукта, софта, прототипа полностью удовлетворяют моим потребностям.\n* 2 вопрос: этот сайт, продукт, софт, прототип легко использовать. \n* Lite может полностью заменить SUS не теряя ни в точности, ни в качестве оценок, поэтому ее чаще всего используют и чаще всего называют улучшенной версией обычного UMUX опросника. \n* Lite короче на 80% чем SUS, т.к тут всего 2 вопроса а не 10.\n* Lite короче на 50% чем обычный UMUX, т.к опять же 2 вопроса, вместо 4.\n* Lite версия исправляет недочеты обычной, т.к. обычный umux критикуют, потому что там 2 позитивных и 2 негативных утверждения, а в lite версии этой путаницы нет\n* После подсчетов итоговый результат ближе выравнивается к SUS и проще понять результат.\n* Как считать: почти также как SUS.\n * Из каждой оценки по каждому из 2 вопросов вычесть 1.\n * Затем сложить получившееся и разделить на 12 (хоть это 7 бальная шкала, но мы убрали по 1 баллу, поэтому 6 + 6 = 12)\n * После умножить на 100 и также подсчитать среднее арифметическое среди всех UMUX-lite показателей респондентов.\n* Можно сравнить результат Lite и привести к SUS: 0,65 * ( (Item 1 + Item 2 - 2) * (100/12) ) +22,9.\n* Пример сравнения к SUS: 0,65 * ((4 + 6 - 2) * (100/12)) +22,9 = 66 SUS score.", + "lastmodified": "2022-04-23T12:45:42.658823629+03:00", + "tags": null + }, + "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5": { + "title": "Тестирование", + "content": "Здесь собраны ссылки по методам и артефактам фазы тестирования макетов в дизайне:\n\n* [Task flow test](Task%20flow%20test.md)\n\n* [Usability Test](Usability%20Test.md)\n* [Fake door](Fake%20door.md)\n* [Prototyping](Prototyping.md)", + "lastmodified": "2022-04-23T12:45:42.664746598+03:00", + "tags": null + }, + "/Design/Test/Fake-door": { + "title": "Fake door", + "content": "# Fake door\n\nыфв\nhttps://vc.ru/semrush/335404-kak-uluchshat-produkt-metodom-fake-door", + "lastmodified": "2022-04-23T12:45:42.666551527+03:00", + "tags": null + }, + "/Design/Test/Prototyping": { + "title": "Prototyping", + "content": "* Вайрфрейм это грубое представление интерфейса, статичное, без деталей и это конкретный этап без которого не обойтись. \n* Прототип это интерактивное представление интерфейса, которое можно протестировать с командой, клиентом и или с пользователями. \n* Макеты/мокапы это дизайн, экраны.\n* Прототипы и макеты могут быть как низкодетализироваными, так и высокодетализированными.\n\n**Вайрфрейминг**\nВходят две вещи: скетчи и низкодетализированные макеты. Скетчи - это зарисовки интерфейсов на бумаге, то есть бумажное прототипирование. \n\nНизкодетализированные макеты это серые статичные макеты без проработки, на которых есть схематичное расположение основных элементов, содержания и в целом намечена структура продукта, но без всяких красивых визуальных штук. Делаются низкодетализированные макеты уже в графических редакторах и их уже можно обсуждать с клиентом и даже тестировать. Вайрфрейминг нацелен на 3 цели: показать контент, наметить общую структуру с навигацией по контенту и подумать над будущим визуалом. Главное на этом этапе количество идей.\n\n**Прототип**\nПрототип это интерактивное представление твоего интерфейса, которое должно показывать какую-то функциональность. Чтобы создать прототип у тебя есть два пути. Самый простой, дешевый и быстрый для теста идей это взять низкодетализированный макет и с помощью инструментов для прототипирования сделать его интерактивным, таким образом получив низкодетализированный прототип. Или ты прорабатываешь макет до финала, используя все свои знания по UI дизайну, а затем используя те же инструменты делаешь высокодетализированный прототип. Цель показать будущий опыт пользователя в продукте и то, как пользователь будет взаимодействовать с контентом, затем посмотреть и решить возможные проблемы с юзабилити, которые возникли по ходу тестирования прототипа.\n\nЯ это подчеркивают также потому, что хочу чтобы ты относился к своим работам как к прототипам, ведь вся наша работа в продукте не кончается тогда, когда мы нарисовали макеты и отдали их в разработку. Поэтому все это деление как я уже говорил условное. Напоминаю, что нам надо еще протестировать результат, посмотреть и проанализировать его, а затем повторить все сначала, но уже с учетом новых знаний о пользователях. Поэтому стоит сразу запомнить то, что это итерационный процесс и относится к своей работе чуть проще, тогда и твое эго не будет выдавать кринж по типу \"ну как же так, это я ж, я ж нарисовал\".\n\nВ действительности это все что тебе нужно знать. И твой процесс будет предельно линеен: ты рисуешь скетчи на бумаге, чтобы сгенерировать как можно больше идей и выбрать одну, а затем делаешь низкодетализированный макет. После этого ты создаешь прототип из низкодетализированного макета и тестируешь внутри команды, с клиентом или пользователями, а после валидации первоначальных идей, ты рисуешь финальные макеты и затем снова тестируешь, превратив его снова в прототип. Конечно, некоторые практикующие дизайнеры могут сказать что все не так, и да, каких-то этапов может и не быть. Например, все может остановиться на низкодетализированном прототипе, потому что идея стартапа провалилась или клиент ушел, а еще может быть и так, что в компании нет культуры создавать прототипы и тестировать их, а поэтому твой низкодетализированный макет сразу ушел в продакшен и провалился. Или же наоборот, все супер и черновой вариант сразу ушел в работу, затем в релиз и был успешен, а ты так и не поправил отступ на пару пикселей между какими-то блоками и тебе начали сниться кошмары. В общем причин может быть очень много. но главное это то, что прототипы должны быть и особенно важно то, чтобы они были на ранней стадии, так как они экономят время, деньги и силы команде. В общем-то это все и ты можешь перейти в плейлист бумажное прототипирование и пробовать рисовать первые скетчи интерфейсов. А я дальше расскажу про отговорки, которые часто встречаются.\n\n**Про отговорки**\n\nНапример, как часто ты слышал что-то подобное от клиента или руководства или даже от коллеги: у нас нет времени на прототипы, мы не можем позволить себе прототипы у нас нет бюджета на это. Даже если ты только учишься, поверь, это случается, я вот часто это слышу и по сей день, серьезно. Да, прототипирование это не бесплатно и оно имеет цену - твое время как специалиста, но результат от прототипирования намного перевешивает затраты на него. И причина тому банально рабочий процесс.\n\nВ типичном процессе проектирования и даже разработки как бывает обычно требования записываются и передаются дизайнеру или разработчику. Дизайнер или разработчик затем интерпретирует эти требования и строит что-то основываясь на своем представлении и понимании. Теоретически такой процесс проектирования, основанный на требованиях, должен сократить потерю времени. Цель такого процесса состоит в том, чтобы заставить всех работать по одной так сказать большой спецификации, работать как одно целое. То есть если мы все будем на одной волне и читать документ доходящий по содержанию до двухсот страниц или иногда даже больше, в конечном счете, у нас будет меньше издержек. Звучит фантастически. Теоретически, это очень здравая идея. Однако, как показывает опыт,\n\nтеория и реальность часто не сходятся, поскольку не просто так появилась гибкая методология ведения проектов - аджайл. Есть даже целый ряд причин почему такие процессы терпят крах и доказывают лишний раз то, что прототипирование это круто:\n\nТребования пишут не те люди. Дизайнеры и разработчики редко включаются в процесс написания требований. Хотя как я уже упомянул в пользовательских историях и карте историй - этим занимается вся команда по аджайлу. Вместо этого, требования часто пишутся бизнес-аналитиком или менеджером, или худо бедно формулируются клиентом. Иногда встречается даже такое, что человеку не хватает технических и дизайнерских знаний, что часто приводит к тому, что любое количество требований переписывается несколько раз.\n\nИз-за этого вытекает то, что тратится коллосальное время и усилия. Количество времени, которое тратится на написание документов, рассмотрение и пересмотр этих подробных требований выходит за рамки бюджета. Для сложных систем, я видел, что требуется несколько месяцев, месяцев карл, чтобы закончить что-то— а иногда даже больше. За это время может многое поменяться.\n\nОтсюда вытекает следующая причина, что нет конца у финальной документации. Теоретически требования являются окончательной документацией. На самом деле требования постоянно меняются, даже после того, как они будут “завершены.”\n\nИз-за такого объема информации появляется проблема неправильного понимания требований. Сам подумай, если в таком документе в среднем от шестидесяти до двухста страниц то недопонимание и путаница это дело привычное. А неверное понимание приводит к неделям или даже месяцам переделок, повторных обсуждений и запуск продукта откладывается. Я даже спойлерну будущий контент для примера, потихоньку и медленно я работаю над своей первой 2д игрой в жанре платформер и документация по моей игре уже выросла до 20 страниц, а написал я лишь одну треть игры и не потому что игра какая-то будет крутая, нет. Это мой первый опыт, но документация нужна для полного понимания работы: сюжет, какие враги, какие механики, боссы и так далее, а в игре будет всего 6 уровней. За сюжет, анимации и программирование я отвечаю один, а по части графики я нанял художника, отсюда необходимость по вопросам передачи идей и т.д.\n\nСледом идет причина отсутствия ценности. Требования обычно формируются функциями или юзкейсами, а это мало, если вообще говорит, о ценности. А дизайн и разработка тупо по требованиям отнимает кучу времени и усилий что в итоге может привести к созданию продукта, который мало или вообще не имеет ценности для пользователя.\n\nНу и наконец финалочка, используя такой подход вся команда будет отлавливать ошибки слишком поздно. Чем позже ты поймешь, что решение херовое, тем дороже будет его исправлять. Логично.\n\n**Как прототипирование решает эти проблемы?**\n\nИмея на руках даже низкодетализированный интерактивный прототип, оценки по времени и стоимости на проектирование сокращаются и становятся более точными. Прототип сокращает количество вопросов от разработчиков. Создав прототип, ты такаже сократишь количество исправлений и переделок, поскольку на руках уже будет какое-то решение, которое можно как-то пощупать и проверить минимальными усилиями. С помощью прототипирования ты также сможешь сгенерировать много идей, таким образом проверяя как можно больше идей при тестировании, а в релиз попадут только лучшие. И конечно же, команда сможет ловить ошибки на ранних стадиях. Прототипирование помогает поймать ошибки на ранней стадии процесса проектирования и разработки. Чем раньше найдете ошибку, чем ниже будет стоимость исправления.\n\n**Что учитывать при прототипировании?**\n\nКонечно же я буду повторяться, первое что нужно учитывать это пользователя и цели бизнеса. Учитывая это, ты будешь лучше понимать что нужно спрототипировать, лучше понять какого результата и ожиданий стоит достичь. Также это поможет тебе выбрать уровень детализации, помним что прототипы и макеты бывают с низкой и высокой детализацией. И наконец, ты подберешь правильный инструмент для реализации.\n\nДалее тебе нужно наметить план, но неполностью, потому что все невозможно спланировать. Старайся просто найти решение сперва на бумаге максимально подробно и генерируй как можно больше вариантов. Затем обсуди это внутри команды или самостоятельно и выбери подходящее решение.\n\nПосле этого тебе нужно обозначить ожидания от твоего прототипа. Как это сделать? Просто написать или рассказать, перед тем как показывать свои скетчи надо рассказывать о своей концепции. Например, я сейчас покажу скетчи или прототип своей концепции по нашему продукту о продаже программного обеспечения. Мой прототип покажет одну функцию, которая поможет продвигать дополнительные услуги и сервисы во время процесса оформления заказа. Эта функция может увеличить прибыль за счет дополнительных продаж. Заметил, как просто формулирование ожиданий работает тогда, когда я даже не собирался показывать тебе прототип, но ты уже ожидаешь что-то увидеть. Более того, я никогда в сименсе не работал над каким-то продуктом по продаже чего-либо, это не моя область. Но если я даже покажу тебе что-то, то ты будешь фокусироваться на процессе оформления заказа и предлагаемых дополнительных услугах, а не на том, что написано в шапке сайта и так далее.\n\nТакже учти что прототипы которые ты будешь создавать будут всегда не полными и не отражать все взаимодействия в продукте. И не нужно строить всю систему в прототипе. На самом деле, пытаясь сделать всё ты потеряешь главное преимущество прототипирования - скорость. Твоя задача использовать прототипы для тестирования и скорее всего нужно тестировать основные сценарии, а их всегда не много. Допустим их пять, то в этом случае надо сделать один большой прототип или несколько маленьких, которые показывают эти сценарии и то что нужно для их выполнения. Не забивай себе голову тем, что произойдет, если при тесте человек нажмет на ту часть прототипа, которая еще не сделана? Это прототип. Прототипы по своей сути это не весь продукт. Если человек все же нажимает на функцию или область, которая еще не готова в прототипе, то используйте это знание как возможность понять, что он ожидает от продукта. Почему он туда нажал, что ожидает увидеть и так далее. Теперь поговорим про инструменты.\n\n**Инструменты для прототипирования**\n\nЯ тут высказываю личное мнение, а поэтому расскажу лишь то, чем я пользуюсь и нахожу полезным и эффективным. Сразу скажу, инструментов дохрена. Все их учить не нужно. Для почти 90% задач тебе хватит одной лишь фигмы, в которой есть и рисование макетов, и инструменты для общения, и прототипирование. Вводный курс по фигме кстати у меня есть на канале и займет это у тебя 2 часа. Подойдет также любой другой современный и популярный редактор: Adobe XD или Sketch, если у тебя есть комп на операционной системе macos. Фотошоп и иллюстратор не берем в счет, потому что они сложные и не создавались для дизайна интерфейсов изначально. Да, кто-то поспорит, мол, а как же красивые промо сайты с кучей графики? Да, такой вид сайтов действительно есть, но ориентироваться на них сейчас уже не стоит, а еще вспоминаем фразу Стива Джобса про дизайн: дизайн - это не то, как предмет выглядит, а то, как он работает и если ты посмотришь на систему в своем телефоне, компьютере и на приложения, которые ты используешь, то ты заметишь что в этом всем нет красивой рисованной графики или ее мало.\n\nС редакторами для создания как низко так и высокодетализированных макетов и даже для базового прототипирования разобрались. Мой личный совет учите фигму. А что касается прототипирования то тут мои персональные предпочтения:\n\nЕсли стоит вопрос показать взаимодействие, анимацию или мобилку, то мне нравится protopie или Principle если у вас есть комп опять же с macos системой на борту. Но я больше за Protopie, потому что он мультиплатформенный и позволяет делать штуки помощнее.\n\nЕсли стоит вопрос показать какое-то сложное функциональное взаимодействие, то это Axure или верстка (html, css, еще круче, если шаришь за js, а еще круче будет знание фреймворка react). Кто-то закричит: а какже Фреймер, а нахер он нужен если ты уже знаешь верстку и js с react? Зачем говнокодить? А что если мы говорим о мобильном приложении? А что если фреймворк другой? Например Vue или Angular?\n\nЯ возможно груб, но поймите меня правильно, зачем тратить время и деньги на изучение технологии , если все можно сделать быстрее, используя инструменты проще или нативные технологии, то есть верстку и JS с реактом? Я не против фреймера, я не против фотошопа или иллюстратора, но объективно это занимает кучу времени, которого ни у кого нет. Поэтому снимайте розовые очки и начинайте работать над прототипами, доносить свои идеи с их помощью до стейкхолдеров и тестировать прототипы на них и с пользователями.\n\nОтдельно упомяну названия: Invision с их инструментом Studio, еще заслуживает внимания Origami Studio от фейсбука, а также такие инструменты как: Webflow, Тильда, Marvel. Как видишь, инструментов реально много и ты можешь придерживаться либо моих рекомендаций, либо попробовать каждый инструмент самостоятельно. Кстати возмонжо, только возможно, я сделаю на каждый из них мини-курс. А на сегодня все, спасибо за просмотр, пока.", + "lastmodified": "2022-04-23T12:45:42.669706997+03:00", + "tags": null + }, + "/Design/Test/Task-flow-test": { + "title": "Task flow test", + "content": "https://uxmag.medium.com/a-simple-method-to-analyze-task-flow-fc5127e1973c", + "lastmodified": "2022-04-23T12:45:42.667040458+03:00", + "tags": null + }, + "/Design/Test/Usability-Test": { + "title": "Usability Test", + "content": "---\n\nhttps://t.me/poyasnizaux/494 \nhttps://t.me/poyasnizaux/549\n\n**Основы юзабилити-тестирования**\n\nПривет. Наши идеи надо как-то тестировать и вообще понимать, что в них могут быть ошибки и их надо находить, а для этого мы создаем прототипы и после проводим юзабилити-тестирование с пользователями, выдавая им задания. Такое тестирование проводится с целью определить удобен и эффективен ли интерфейс, с привлечением целевой аудитории продукта.\n\nЮзабилити-тестирование всегда дешевле разработки, поэтому тесты нужны всегда, чтобы понять почему в продукте низкая конверсия, почему пользователи часто обращаются в службу поддержки или пишут плохие отзывы в app store и google play. Еще тестировать можно и нужно, если хочется сравнить твой продукт и продукт конкурента или узнать перед разработкой нового продукта то, какие потенциальные проблемы могут возникнуть у людей.\n\nВ общем юзабилити-тестирование помогает оценить навигацию, хватает ли человеку информации на странице. Также оно помогает оценить понимание текстов и то на сколько понятны элементы интерфейса. Помимо этого, с помощью тестирования можно сравнить качество старого и нового интерфейсов и тем самым убедиться что надо или не надо что-то менять. И в целом, тестирование также помогает оценить скорость выполнения задач и даже эмоции, которые возникают у людей. Это целая дисциплина и в рамках одного видоса такую тему не закрыть, однако я дам базу, чтобы ты понимал как сделать юзабилити-тест на коленке и ссылки в описании под видео также будут.\n\nПроводить юзабилити-тестирование можно в виде модерируемого теста, то есть когда ты сидишь рядом с пользователем, выдаешь им прототип и задачи, следишь за их выполнением и общаешься, задавая вопросы и все это происходит под запись аудио/видео с его экрана и вебки. Или немодерируемого теста, то есть когда ты даешь ссылку на прототип в специальном сервисе пользователям, в этом сервисе создаешь задачи, а пользователи пройдут по ним, при этом ты даже можешь очно наблюдать за тестом созвонившись с пользователем по видеосвязи или же удаленно, то есть после того как загрузил прототип в специальный сервис, дать задание и после получить сводку по тесту от сервиса. Отсюда логичный вывод, что модерируемые занимают больше времени, поскольку тебе надо поговорить и показать лично каждому прототип, а также найти место, где никто не будет мешать, а немодерируемые тестирования снижают затраты по времени и деньгам, но опять же, любое и какое-никакое тестирование даже на коленке полезно, чем его отсутствие и дешевле разработки продукта или какой-то функциональности в нем.\n\nУ всего есть плюсы и минусы. Я честно скажу, что не использовал сервисы по удаленному юзабилити-тестированию и не учувствовал в них сам наблюдая за процессом в подобных сервисах, поэтому не могу ручаться за их плюсы, минусы и достоверность, поэтому я могу советовать только то, что пробовал: а это просто проводить тесты очно и модерировать тест с пользователями находясь в офисе или созваниваться удаленно по видеосвязи, давая им доступ к прототипу и тд. Отсюда давай разбираться когда нужно проводить и что нужно для проведения юзабилити-теста.\n\nПроводить нужно тогда, когда ты с командой видите проблемы с текущим сайтом и тестировать в таком случае нужно сайт. Или тогда, когда ведется разработка новой функциональности или целого нового проекта, в таком случае тестировать нужно прототип. Тестирование не надо проводить, если ты с командой поняли что все плохо и ужасно и нужно срочно менять концепцию всего продукта.\n\nЕсли обзорно рассмотреть весь список этапов юзабилити тестирования, то нужно сперва определить проблему и сформировать гипотезу, затем сделать прототип, после этого нужно написать план тестирования, после найти пользователей, которые будут проходить тест, затем собственно провести его, наблюдая за действиями пользователей, а в конце задать вопросы и проанализировать результаты.\n\nТестировать всегда нужно, имея цель или гипотезу. Сформировать гипотезу и вообще найти проблему можно из данных системы аналитики, отзывов пользователей, результатов опросов или интервью с потенциальными пользователями и стейкхолдерами. Поэтому задавайся вопросами по типу: Что для тебя будет важным в этом тесте? Какие роли пользователей или задачи ты хочешь протестировать? Что надеешься узнать или зафиксировать? Возможно или даже наверняка тебе будет интересно как быстро пользователь прошел сценарий, как часто ошибался, сколько задач удалось ему выполнить и насколько он удовлетворен результатом? Видит или не видит кнопку, ссылку, заголовок, раздел? И сколько таких пользователей? Поскольку это лишь количественные показатели, чтобы понимать лучше ли это решение, чем текущее, поэтому в дополнение к этим параметрам у тебя должны быть заготовлены еще и вопросы после теста.\n\nДля всего этого нужен план теста, потому что тестировать всегда нужно по сценарию, а не думать о том \"какая кнопка нравится больше\". Для этого нужно моделировать ситуации и пример как надо и не надо давай сразу разберем: Не надо говорить что на экране есть кнопка и просить людей найти на экране кнопку. Надо сказать человеку что вот тебе страница товаров категории Планшеты, ты хочешь сделать подарок своему другу гику и для этого ты решил заказать планшет с памятью 128 гб. И там и там человеку как бы надо найти кнопку заказать, но я смоделировал конкретный план и ситуацию, чтобы участник теста был вовлечен. Если бы я хотел просто оценить информационную архитектуру сайта, то я дал задание на поиск или фокусировку, например явно указал бы на фильтрацию. В ролике про прототипирование я уже говорил про сценарии, но повторюсь еще раз что надо выбирать самые важные сценарии – и тестировать то, что наиболее приоритетно для продукта.\n\nИ вот мы записываем задание: выбор планшета. Ставим начальное состояние - страница товаров Планшеты, хотя можно начать с главной страницы сайта, если в прототипе это сделано или если тестируете с командой на настоящем сайте. Даете описание типа: вы собираетесь заказать планшет. Вам необходим планшет на 128 гигабайт. Подберите для друга планшет и положите в корзину тот, что понравится. Вообще цель всех заданий что ты будешь придумывать склоняется к трем вещам: изучению того насколько понятен или нет интерфейс, затем к проверке насколько просто найти что-то или выполнить в интерфейсе, а после сравнить или проанализировать, например сравнить товары, тарифные планы или данные с двух датчиков.\n\nДалее мы пишем что будет являться эффективным решением задачи, например: пользователь смог самостоятельно подобрать товар. Вторым пунктом можем записать: понял, каким образом работают фильтры товаров, а третьим пунктом можно записать что он понял каким образом положить этот товар в корзину.\n\nКак я ранее говорил, у тебя должна быть цель или гипотеза почему ты вообще хочешь провести тест, например можно записать что ты предполагаешь что у людей будут трудности с поиском раздела Планшеты, или ты предполагаешь что они не заметят фильтрацию товаров, или они не поймут как добавить товар в корзину. Можно даже выдвинуть гипотезу что какие-то полезные функции вообще не замечают люди. После составления плана теста нужно заранее заготовить вопросы, например, как вы считаете, удалось ли вам найти нужный раздел? На ваш взгляд название раздела является понятным и очевидным? Что было удобно или неудобно при выполнении задания? Все ли формулировки были понятны: в заголовках, текстах, меню? Много ли шагов понадобилось пройти, чтобы найти раздел? Удалось ли найти нужный товар, какие трудности были при подборе товара? Если были, то какие? Сложно ли было добавить товар в корзину? Если человек не справился с задачей, то можно спросить где бы вы хотели видеть этот раздел и доступ к нему?\n\nКак видишь, это не занимает много времени. Главное это наличие гипотезы или цели, так как важно формулировать четкий результат, который хочется получить от тестов. После нужен прототип и план тестирования, который состоит из заданий. В каждом задании тебе нужно написать сценарий и определить успешный критерий его выполнения и метрику, по которой ты будешь понимать результат. Например, если все тестируемые пользователи в упор не видят фильтрацию по объему памяти в категории планшетов, то это повод задуматься, так как метрика время на выполнение задачи тут явно возрастет. Измерять можно как я уже сказал по критерию сколько человек справилось или не справилось, сколько ошибок было, сколько времени понадобилось на выполнение задания, отклонился ли от идеального сценария, и если да то какая была последовательность действий или понятны ли были все надписи?\n\nПараллельно с написанием плана, надо начинать поиск респондентов. Обычно это от 5 до 8 или 12 человек на какой-то сегмент аудитории. Чтобы понять откуда это число я оставил ссылку в описании под видео прочитай статью пожалуйста, так будет эффективнее, а видео короче. Но если коротко, то чем больше людей, тем больше одинаковых ошибок они будут находить и меньше новых, поэтому тебе не нужно для поиска наиболее часто встречающихся ошибок или проблем в прототипе или на сайте куча народу.\n\nНайти людей поможет клиент, на которого ты работаешь и у которого могут быть потенциальные пользователи, а если такой возможности нет, то если продукт существует и у него есть пользователи надо сделать рассылку, поставить баннеры на сайте что можно поучаствовать в программе тестирования, можно найти людей на сайтах по поиску подработки или найти людей в соцсетях, или в конце концов провести коридорное тестирование. Коридорное тестирование это когда ты просишь ближайших людей пройти тест, чтобы просто убедиться в том что интерфейс понятен, такими людьми могут быть коллеги по работе, которые не втянуты в разработку данной функциональности или случайные люди, которых ты можешь встретить выйдя из офиса в столовку, кафе, на улицу или коридор. Это и есть коридорный тест. Подробно про этот вид теста есть ссылка в описании под видео.\n\nЧтобы отсеять не нужных людей, можно проверить их дав им заполнить анкету или провести опрос, в подобных анкетах и опросах надо составить вопросы о продуктовом опыте пользователя, чтобы отсеять сразу тех, кто вообще не сталкивался с вашим продуктом и тематикой сайта. Согласись, что странно звать на тестирование кассира, если твой проект связан с продажей автомобильных тормозных колодок. Также в анкете должны учитываться социальные и демографические показатели. Опять же, если продукт на целен на премиальную аудиторию, то охранника звать странно. И вполне нормально поставить вопрос в анкете про компьютерную грамотность, ведь если мы проектируем к примеру программу про менеджмент-задач, то нам не подойдут люди, который не умеют пользоваться схожим софтом и компьютером в целом.\n\nИ вот у тебя есть гипотеза и прототип, ты написал план тестирования и нашел 5 человек. На выбор у тебя есть варианты: позвать каждого по отдельности в офис компании и провести тестирование лично или созвониться по видео связи. Дальше не важно что ты выберешь, но собственно а что дальше? А дальше нужно рассказать пользователю что происходит, так сказать дать вводный инструктаж, в котором ты представишься, объяснишь задание, предупредишь что будет запись, попросишь на это разрешение и попросишь вслух комментировать происходящее, то есть что человек видит, что понимает из того что видит, что хочет сделать чтобы выполнить задачу?\n\nПо ходу интервью тебе нужно делать заметки прям как стенографист фокусируясь на том, что делает пользователь. Делать это нужно быстро и для каждого задания, поэтому учись сокращать слова, то есть ты можешь использовать буквы, например ставишь букву Н для негативных моментов во время выполнения задачи у пользователя, П для положительных, Р для рекомендаций от участника, Ю для проблем юзабилити, букву Э если были эмоции и так далее, придумать такую кодировку из букв не сложно и можно даже рисовать какие-нибудь символы тот же плюс или минус для положительных или отрицательных моментов. Главное чтобы запись сопровождалось временной меткой или проще тайм-кодом, чтобы при анализе записи было понятно на что смотреть. Важно не подсказывать, не перебивать, не спорить с пользователем во время тестирования. После интервью задать вопросы, собственно о них я уже говорил. В конце попрощаться и повторить с другим пользователем.\n\nПосле тестирования тебе нужно проанализировать и составить отчет по нему. Для этого нужно использовать свои заметки, видео/аудио записи интервью, то есть нарезать моменты которые важны для отчета, и после этого представить эти данные команде. При анализе обращай внимания на те моменты, когда пользователь понимал задачу, но не понимал как ее решить или когда он понял задачу, но пытался ее решать по разному и делал несколько попыток для ее решения, также когда не смог решить задачу и прекратил пытаться, когда выполнил задачу, но не ту, которая была поставлена, когда выражает удивление, удовольствие или разочарование и замешательство при взаимодействии с интерфейсом, и когда говорит что что-то не правильно или непонятно и предлагает внести изменения.\n\nИ вот такое вот оно юзабилити-тестирование, а я ведь затронул эту тему лишь в основах и на самом деле это целая дисциплина, для отдельной профессии, но это касается лишь больших компаний и корпораций. На начальном этапе тебе нужно лишь понимать что это такое и как быстро провести небольшой юзабилити тест на коленке, а для этого нужно сперва определить проблему и сформировать гипотезу, затем сделать прототип, после этого нужно написать план тестирования, после найти пользователей, затем собственно провести тест, а в конце задать вопросы и передать результаты команде.\n\nПро юзабилити-тестирование: [https://dou.ua/lenta/articles/usability-testing-guide/](https://dou.ua/lenta/articles/usability-testing-guide/) или [https://sales-generator.ru/blog/yuzabiliti-testirovanie/](https://sales-generator.ru/blog/yuzabiliti-testirovanie/)\n\nПро количество респондентов: [https://usabilitylab.ru/blog/usability-testing-respondents/](https://usabilitylab.ru/blog/usability-testing-respondents/)\n\nПро поиск респондентов: [https://usabilitylab.ru/blog/poisk-respondentov-dlya-yuzabiliti-testirovaniya-chast-1-kriterii-otbora/](https://usabilitylab.ru/blog/poisk-respondentov-dlya-yuzabiliti-testirovaniya-chast-1-kriterii-otbora/)\n\nПро коридорное тестирование: [https://vc.ru/marketing/100883-poydem-vyydem-podrobnyy-gayd-po-koridornym-testam](https://vc.ru/marketing/100883-poydem-vyydem-podrobnyy-gayd-po-koridornym-testam)\n\nКак составить отчет: [https://lpgenerator.ru/blog/2019/08/29/yuzabiliti-testirovanie-uchimsya-sostavlyat-otchet/](https://lpgenerator.ru/blog/2019/08/29/yuzabiliti-testirovanie-uchimsya-sostavlyat-otchet/)", + "lastmodified": "2022-04-23T12:45:42.665402118+03:00", + "tags": null + }, + "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0": { + "title": "Разработка", + "content": "Flutter\n*Dart*\n*Flutter*\n\nReact\n*React*\n\nНейминг\n\n* [camelCase](camelCase.md)\n* [PascalCase](PascalCase.md)\n* [kebab-case](kebab-case.md)", + "lastmodified": "2022-04-23T12:45:42.659609152+03:00", + "tags": null + }, + "/Development/PascalCase": { + "title": "PascalCase", + "content": "* Первая буква всегда заглавная, как и последующие слова.\n* Позволяет акцентировать внимание.\n* **Лучший для**: имен классов, enum, синглтонов и файлов с ними.", + "lastmodified": "2022-04-23T12:45:42.659773865+03:00", + "tags": null + }, + "/Development/camelCase": { + "title": "camelCase", + "content": "* Первая буква всегда маленькая, далее каждое слово начинается с большой буквы.\n* Пример: nodePackageManager.\n* **Лучший для**: имен переменных, свойств, модулей и файлов с ними.\n* Преимущества:\n * Легко выделяется двойным кликом;\n * Компактнее чем kebab-case, snake-case;\n * Практически универсален.\n* Недостатки:\n * Может вызывать проблемы в системах нечувствительных к регистру;", + "lastmodified": "2022-04-23T12:45:42.658303196+03:00", + "tags": null + }, + "/Development/kebab-case": { + "title": "kebab-case", + "content": "* Все буквы маленькие, слова разделяются дефисом.\n* Преимущества:\n * Подходит для систем невосприимчивых к регистру и пробелам;\n * Легко парсится;\n * Немного читабельней, чем camelCase и PascalCase.\n* Недостатки:\n * Не выделяется двойным кликом;\n * Большенство интерпритаторов не воспринимают как единой слово, поэтому не годится для имен переменных/функций/свойств/классов.\n* **Лучший для**: имен директорий, URI, имен свойств JSON.", + "lastmodified": "2022-04-23T12:45:42.658101607+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8": { + "title": "Метрики", + "content": "* Это качественный или количественный показатель.\n* Показывает ту или иную характеристику и уровень успешности продукта.\n* Подходы:\n * Data-driven подход - сначала цифры, а потом на их основе принимают решения. Команда выбирает метрики и считает показатели. Полученные числа - первое, на что они посмотрят, решая, куда двигаться дальше.\n * Data-informed подход - метрики частично влияют на принятые решения. Показатели - это важно, но не главное. На них можно ориентироваться в одном случае и не учитывать в другом.\n* Дизайнеру никто не будет платить бабки выше рынка, если ты не будешь позитивно влиять на бизнес своим дизайном, а для этого нужно хотя бы сперва понять о чем речь.\n* В большинстве случаев, если конверсия в покупателя меньше 1%, то точкой роста будет [конверсия](Conversion.md). В остальном надо считать юнит-экономику и смотреть что будет при изменении метрик: кол-во повторных покупок, ср. чек, c1 и т.д.\n* Список метрик:\n * [North star metric](North%20star%20metric.md) - отражение ценности продукта, понимание туда ли идет продукт\n * [Profit](Profit.md) - монетизация\n * [Gross profit](Gross%20profit.md) - монетизация\n * [Conversion](Conversion.md) - монетизация\n * [CAC](CAC.md) - монетизация\n * [LTV](LTV.md) - монетизация\n * [COGS](COGS.md)\n * [MRR](MRR.md) - монетизация\n * [ARPU](ARPU.md) - монетизация и ценность \n * [ARPPU](ARPPU.md) - монетизация, реакция на ценность\n * [Cumulative ARPU](Cumulative%20ARPU.md)\n * [Retention](Retention.md) - лояльность и монетизация\n * [Churn rate](Churn%20rate.md) - лояльность и монетизация\n * [DAU\u0026WAU\u0026MAU](DAU\u0026WAU\u0026MAU.md) - лояльность\n * [ROMI](ROMI.md)\n * [Cart abandonment rate](Cart%20abandonment%20rate.md)\n * [AOV](AOV.md)\n * [CPI](CPI.md)\n * [CTR](CTR.md)\n * [CPA](CPA.md)\n * [CPC](CPC.md)\n * [RPR](RPR.md)", + "lastmodified": "2022-04-23T12:45:42.667770022+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/AOV": { + "title": "AOV", + "content": "* Average order value - средн. стоимость заказа или средний чек.\n* AOV = общая сумма выручки / кол-во заказов.\n* Пример: за февраль продали на 250к рублей, а заказов было 286. AOV = 250000/286 = 874 руб.\n* Показывать юзерам товары из той же категории или в духе \"с этим товаром обычно покупают\".\n* Предлагать рассрочки и разные варианты оплаты - давать контроль над ситуацией.", + "lastmodified": "2022-04-23T12:45:42.65607813+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPPU": { + "title": "ARPPU", + "content": "* Average revenue per paid user — средняя прибыль от одного **платящего** пользователя за определённый срок. Без учета расходов на маркетинг.\n* ARPPU = доход за период / кол-во платящих юзеров (иногда кол-во повторных покупок) за период.\n* ARPPU показывает реакцию платящих юзеров на ценность продукта и их реакцию на изменение цен в продукте.\n* Paying share (доля платящих) связывает [ARPU](ARPU.md) и ARPPU. Paying Share = ARPU / ARPPU * 100. Как понять что значение хорошее: зависит от типа бизнеса. Например для мобилок неплохо 1-2%.\n* Пример: в этом месяце 1200 юзеров, но только 40 оплатили подписку. Доход 1000$. \n * ARPU = 1000 / 1200 = $0.8.\n * ARPPU = 1000 / 40 = $25.\n * Paying share = (0,8 / 25) * 100 = 3,2%.\n* Если ARPPU растет, но Paying Share падает, то это приведет к сокращению дохода. Прибыль от платящих не покроет сокращение их кол-ва.", + "lastmodified": "2022-04-23T12:45:42.659948537+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU": { + "title": "ARPU", + "content": "* Average Revenue Per User - средняя прибыль от одного активного юзера за период (день, неделя, месяц, год).\n* Считается по разному:\n * ARPU = Revenue (доход за период) / Users (MAU/DAU - платящие и не платящие юзеры за тот же период).\n * Доход за период = кол-во проданных товаров * цена.\n * Если в этом месяце сервисом пользовались 600 чел-к, а доход составил $3200, то ARPU = 3200 / 600 = $5,3.\n * Можно считать ARPU через конверсию = Конверсия * ARPPU.\n* ARPU не имеет оптимального значения, но если снижается, то надо привлекать больше клиентов.\n* ARPU - показывает только положение дел на текущий момент (сколько клиент в среднем тратит за период), поэтому надо учитывать, но не путать с [LTV](LTV.md) - общая ценность клиента для компании в течение всей жизни как покупателя.\n* Равный показатель ARPU у равных компаний с равным желаемым доходом не значит одно и то же. Например у **компании А** - ARPU 10000/700=15$ и **компания В** - ARPU = 4500/300 = 15$ - это не одно и то же, доходы разные за период.\n* Считается раз в месяц для сервисов по подписке, но если Lifetime юзеров невелико (актуально для мобилок), то считать можно чаще. Если сервис не по подписке, то обратить внимание надо на то, как часто клиентам нужен сервис/продукт.\n* Если продуктов несколько, то можно ARPU считать по каждому или по категории, если это магазин, чтобы увидеть что приносит бо́льшую прибыль.\n* Для повышения ARPU необходимо уменьшить кол-во юзеров или увеличить доход, повысив число платящих юзеров. Второй путь получше.\n* Если ARPU приближается к стоимости самого дешёвого тарифа по подписке, пора поработать над маркетингом.\n* Если ARPU высокий, то всё не зря и юзеры ценят продукт. Поэтому, когда показатель достигает стоимости среднего (по цене) тарифа по подписке, можно пробовать поднять цены.\n* Можно использовать ARPU для проверки реакции на изменение цены. Допустим, решили поднять стоимость подписки и посмотреть на ARPU по новым юзерам (тем, что с вами менее месяца).\n * В прошлом месяце - 810 новых юзеров. Доход 900$.\n * После новой цены - кол-во юзеров 700. Доход 800$.\n * ARPU до повышения = 900 / 810 = $1,11.\n * ARPU после повышения = 800 / 700 = $1,14.\n* Можно использовать для оценки ux/ui решений: если ARPU растет - механика работает.\n* ARPU - [CPA](CPA.md) - средний доход на юзера с учетом рекламы. Если ARPU \\\u003c CPA = плохо.\n* Чтобы улучшить ARPU:\n * Апселл/кросс-селл - допродажи и кросс-продажи. Если сервис по подписке, то работать над мотивацией перехода и ценностью.\n * Играть с тарифами.\n* Есть похожая метрика [ARPPU](ARPPU.md) - это Average Revenue Per **Paying** User, разница в том что берутся не все пользователи за период, а только те, что заплатили.\n\nhttps://www.carrotquest.io/blog/arpu/", + "lastmodified": "2022-04-23T12:45:42.662641118+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/CAC": { + "title": "CAC", + "content": "* Customer aquisition cost - стоимость привлечения клиента.\n* Это сумма, которую тратит бизнес на привлечение 1 покупателя.\n* Считается по разным маркетинговым каналам, чтобы понимать эффективность его работы.\n* Надо держать ниже, чем LTV.\n* Считается по разному, т.е. есть разные формулы.\n* Простой просчет, чтобы прикинуть средний показатель:\n * CAC = все расходы на маркетинг за период / кол-во привлеченных клиентов за период. \n * Например: 86 чел-к пришло на сайт в феврале. Бюджет рекламной кампании в инсте был 50к руб (+ с учетом зп маркетолога, дизайнера, оплату сервисов по рассылке и тд). 50к / 86 = 581 руб обошелся бизнесу каждый клиент. Если средний чек 500 руб, то экономика не сходится, надо что-то менять.\n* Чтобы сократить CAC надо сократить расходы (как-то) на привлечение без потери кол-ва платящих клиентов. Нет универсального способа, только рекомендации:\n * Работа над конверсией - тестировать и запускать а/в-тесты, лидогенерация, работать с брошенными просмотрами/корзинами.\n * Работа над лояльностью - улучшать продукт, открытость к диалогу, работа над позиционированием, удержание клиентов.\n * Автоматизация - crm.\n* Не путать с CPA, так как последний про стоимость действия, которое совершает юзер. CAC измеряет стоимость привлечения покупателя.\n * Действие 1й рекламной кампании - регистрация в сервисе. Стоимость привлеченного юзера - CPA, т.к. не получаем деньги с него.\n * Действие 2й рекламной кампании - покупка подписки. Стоимость привлеченного юзера - CAC, т.к. юзер оплатил подписку и стал клиентом/покупателем.\n* Интересно, что кол-во повторных покупок подписки не может повлиять на CAC приложения по подписке. Потому что метрика появляется уже после того, как человек стал клиентом. Значит эти действия не учитываются в оценке стоимости привлечения клиентов.", + "lastmodified": "2022-04-23T12:45:42.656480058+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/COGS": { + "title": "COGS", + "content": "* Cost of goods sold - себестоимость продажи, показывающая затраты, которые несет компания на каждой продаже.\n* COGS = Gross profit (валовая выручка/маржа) / revenue (выручка) * 100%.\n * Маржа 6 млн руб. Выручка 20 млн руб. COGS = 6 млн / 20 млн * 100% = 30% \n* COGS в деньга (издержки после продажи) = Revenue - Gross profit.\n * Выручка 11.9 млн руб. Маржа 3.57 млн руб. COGS = 11.9 млн - 3.57 млн = 8,33 млн издержки после продажи.\n* Важно отделять постоянные расходы, которые несет компания независимо от того есть продажи или нет (зарплаты, аренда офиса, сервера), от обязательных расходов, которые несет компания при каждой продаже.\n* 1sCOGS - доп. расходы, которые несем на самую первую продажу.", + "lastmodified": "2022-04-23T12:45:42.655788913+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/CPA": { + "title": "CPA", + "content": "* Cost per Acquisition - стоимость одного действия, как правило, целевого, но юзер ничего при этом не покупает. То есть это юзеры, которые не дают прибыль, но связаны с ней.\n* Путают с CAC, но вот разница:\n * Если юзер регается на Netflix, чтобы получить 1й месяц бесплатно, то его посчитают в CPA. \n * Когда этот юзер купит на следующий месяц подписку, то считать будут в CAC.\n* CPA = стоимость рекламной кампании / кол-во целевых действий (пример выше регистраций бесплатного периода на нетфликс).\n* Виды действий: покупки, посещение нескольких страниц или целевой, просмотр ролика, просмотр прайс-листа, загрузка файла, заполнение формы.\n* На каком-то этапе когда развился интернет-магазин к примеру можно опираться не на всю кампанию, а разбиваться по каналам.", + "lastmodified": "2022-04-23T12:45:42.666523943+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/CPC": { + "title": "CPC", + "content": "* Cost per click - показатель стоимости одного клика.\n* CPC = стоимость размещения рекламы / кол-во кликов по рекламе.\n* Используется небольшими интернет-магазинами для планирования рекламных кампаний.\n* Сравнивается предыдущий показатель с текущим.\n* Особенности:\n * Большой охват аудитории, которая кликнула - готовые лиды, либо очень заинтересованные в вашей тематике люди.\n * Вебмастер преимущественно имеет в итоге целевую аудиторию, поэтому довольно часто CPC используют для наращивания ЦА к ресурсу.\n * Чем больше показатель стоимости клика, тем больше показов имеет вебмастер в итоге - любой площадке выгоднее выводить такое объявление.\n * Оплата будет списываться только в случае клика на рекламу, независимо от количества показов рекламы.\n * Самое страшное, что может быть - конкуренты могут специально кликать для полноценного слива такой рекламы.", + "lastmodified": "2022-04-23T12:45:42.657138912+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/CPI": { + "title": "CPI", + "content": "* Cost per install - простой и прозрачный показатель в маркетинге мобильных приложений и игр.\n* Отвечает на вопрос о том, сколько необходимо потратить средств, чтобы юзер выполнил установку и открытие продвигаемого приложения.\n* Как считать: деньги на рекламу / кол-во юзеров скачавших приложение.\n* Если продукта не существует, то искать бенчмарки CPI можно в разных источниках: на [Emarketer](https://www.emarketer.com/forecasts/channel/5a05da82f45a9a0d20adb031/59f71fe3bfce890eb411fed5), [Business of Apps](https://www.businessofapps.com/ads/cpi/research/cost-per-install/#4) или [Geckoboard](https://www.geckoboard.com/best-practice/kpi-examples/cost-per-install/#:~:text=The%20benchmarks%20for%20CPI%20vary,specifics%2C%20see%20these%20CPI%20benchmarks.). Также бенчмарки для расчета юнит-экономики есть [в калькуляторе Adjust](https://app-benchmarks.adjust.com/?vertical=Health%20%26%20Fitness\u0026region=Northern%20America\u0026user_type=All\u0026platform=ios\u0026start=2019-10-01%2000%3A00%3A00%20%2B0000\u0026end=2019-12-31%2023%3A59%3A59%20%2B0000) — там собраны агрегированные данные по разным вертикалям. Всегда обращай внимание на географию. Стоимость установки в США и Индии будет сильно отличаться.\n * Важно уточнить: бенчмаркам нельзя доверять на 100%. Чаще всего они [отличаются](https://brianbalfour.com/essays/growth-benchmarks) от того, что происходит в реальности. В нашем случае мы используем их как отправную точку, чтобы уменьшить неопределенность когда продукта не существует.", + "lastmodified": "2022-04-23T12:45:42.662892126+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/CTR": { + "title": "CTR", + "content": "* Click Through Rate – отношение числа кликов на баннер к числу показов баннера.\n* Формула: клики на рекламу / кол-во показов * 100. \n* Пример:\n * первый баннер кликнули 20 000 раз (пользователь может кликнуть баннер лишь 1 раз), после поставили приложение 8 000 раз;\n * второй баннер кликнули 25 000 раз, после поставили приложение 6 000 раз.\n * CTR 1-го баннера равен 20000/1000000 = 2%.\n * CTR 2-го бавтннера равен 25000/1000000 = 2.5%.\n* Чтобы понять что CTR N-банера ниже на N-%, чем CTR другого:\n 1 - 2% / 2.5% = 0.2, то есть CTR первого баннера в примере выше на 20% ниже, чем второго баннера.", + "lastmodified": "2022-04-23T12:45:42.660579223+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Cart-abandonment-rate": { + "title": "Cart abandonment rate", + "content": "* Показатель брошенных корзин - дает понимание сколько юзеров было готово что-то купить в продукте или на сайте.\n* Метрика рассчитывается по формуле: кол-во заказов в корзине - кол-во оплаченных заказов / кол-во заказов в корзине * 100.\n* Чем выше показатель, тем большую работу по улучшению юзабилити интернет-магазина нужно провести.\n* Надо напоминать юзерам о товарах, лежащих в корзинах с помощью поп-апов или писем на почту, или предлагать скидку, если юзер долго не покупает.\n* Причины брошенных корзин:\n * Слишком высокие дополнительные расходы (например, доставка) — 61%;\n * Необходимость создавать аккаунт — 35%;\n * Слишком долгий процесс заполнения полей и верификации — 27%;\n * Не увидели или не смогли рассчитать общую стоимость заказа — 24%;\n * Ошибки на сайте — 22%;\n * Отказ заполнять данные своей кредитной карты на сайте — 18%;\n * Слишком долгий период доставки — 16%;\n * Не подошли условия возврата — 10%;\n * Не нашли предпочтительный способ оплаты — 8%;\n * Кредитная карта была отклонена — 5%.", + "lastmodified": "2022-04-23T12:45:42.664447464+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Churn-rate": { + "title": "Churn rate", + "content": "---\n\n* Отток юзеров - процент юзеров, которые отказались от услуг сервиса в течение определенного времени (удалили аккаунт, отменили подписку, не продлили контракт, не купили повторно).\n* Чем ниже отток, тем дольше юзеры остаются в продукте и несут деньги.\n* Считается по разному: среднее, процентное и денежные соотношения и даже по людям.\n* Элементарно churn rate = кол-во ушедших за период / все юзеры за этот же период * 100.\n* Для подписных churn rate = кол-во юзеров на начало месяца - кол-во юзеров на конец месяца / кол-во юзеров на начало месяца * 100.\n* Еще есть формула: Chrun rate = Av. Price / (LTV / 70%)\n * Пример по формуле\n * Если LTV (с учетом комиссии App Store) = $58.\n * Если подписка $9.99 в месяц (av. price).\n * $9.99 / ($58 / 70%) = 12% churn rate.\n* Чаще всего его считают за месяц. \n* Чаще всего рассматривать лучше на примере SaaS сервисов, потому что там работа шире, чем в других сферах.\n* Для продуктов, где оплата происходит поштучно можно сегментировать юзеров по частоте покупок, затем найти момент, когда данные скажут, если юзер не купил = ушел из продукта. Например в магазине сегментировали юзеров по частоте покупки и поняли, что 95% юзеров, которые ничего не покупают в течение года не возвращаются к покупке. На этом знании можно брать год как точку для расчета оттока.\n* Отток обратно пропорционален времени жизни юзера на сайте. Например:\n * Смотрим за год отток = 20% (0.2).\n * Тогда можно понять время жизни юзера на сайте взять 1 / 0.2 = 5 лет.\n * Похожим образом если 4% уходят каждый месяц, то 1 / 0,04 = 25 мес.\n* Также это один из вариантов считать LTV = ARPU / Отток.\n* Если продукта не существует? - Бенчмарки.\n* Над показателем надо работать, т.к. привлечение юзера стоит денег. Например,  стоимость привлечения юзера = 1500р, а подписка = 500р. Итого, на 3й мес компания выйдет в 0 (окупит затраты), а на 4й месяц начнет получать прибыль.\n* Чтобы уменьшить отток:\n * Работать над ценностью, привычкой использовать продукт, клиентоориентированностью,ux/ui и ценой.\n * Клиентоориентированность: чат, собирать отзывы, персонализировать подход к клиенту, смотреть как работают с сайтом, система бонусов и программа лояльности, решать проблемы юзеров, поддержка.\n * Онбординг и активация.\n* Существует еще MRR churn rate или регулярный месячный отток - деньги, которые теряем из-за того, что уходят клиенты или переходят на тариф дешевле. Может быть отрицательным, что хорошо (компания зарабатывает).\n * Очень важно для стартапов и подписочных сервисов.\n * MRR сhurn rate = (MRR за предыдущий период - MRR за текущий период) / MRR за предыдущий период.\n * Churn у плана за $2 = (60-50)/60 * 100 = 17%.\n * Churn у плана за $10 = (20-10)/20 * 100 = 50%.\n * Churn общий за 2 плана = (80-60)/80 * 100 = 25%.\n * MRR = (320-200)/320 * 100 = 38%\n \\| | 1й период | 2й период | Churn |\n \\|", + "lastmodified": "2022-04-23T12:45:42.658726334+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Conversion": { + "title": "Conversion", + "content": "* Это отношение числа юзеров, которые выполнили (например покупку) действие к общему числу юзеров, которые пришли на сайт.\n* CR = кол-во заказов / кол-во сессий * 100.\n* На сайт пришли 2000, а 200 из них сделали заказ. CR = 200 / 2000 * 100 = 20%.\n* Если продукта не существует, а хочется понять какая конверсия норм, то тут поможет опыт коллег или бенчмарки. Найти их на [Clevertap](https://clevertap.com/mobile-data-trends/), [Recurly](https://info.recurly.com/research), [Adjust](https://app-benchmarks.adjust.com/)\n* Есть еще термин C1 - это конверсия в первую покупку - это общее со всех шагов, но до C1 юзер проходит какие-то шаги (воронку), поэтому можно считать конверсию между шагами, т.е. процент юзеров перешедших от одного к другому.\n* Конверсию можно повысить:\n * Сделать проще сайт по навигации, поиску (юзабилити).\n * Простые процессы (регистрация, покупки и т.д.).\n * Повысить привлекательность: фото, иллюстрации, текста, соц. одобрение.\n * Посмотреть на задачу с конца.\n* Какой шаг воронки оптимизировать? Например, у компании конверсия в покупателя 0,55%. Запросили воронку переходов:\n\n````mermaid\ngraph TD\nA[Открыли сайт - 600к] --\u003e |7.7% - этот?| B[Ушли в корзину - 46 214] --\u003e |34% - этот?| C[Открыл стр заказа - 15 713] --\u003e |30% - этот?| D[Заказли - 4 714] --\u003e |70% - этот?| E[Оплатили - 3 300];\n````\n\n* Какой шаг будем оптимизировать?\n * Обычно говорят 1-2 шаги. Но если делаем так, то получается не выгодно, потому что каждый последующий шаг срезает 30-40% юзеров.\n * Надо посмотреть на конец, ведь туда уже дошли юзеры, несмотря на все проблемы и там покупают, поэтому дизайнеру лучше проектировать сценарии и интерфейсы с итогового результата - помогает отсесь лишние шаги, которые снижают конверсию.", + "lastmodified": "2022-04-23T12:45:42.663160259+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Cumulative-ARPU": { + "title": "Cumulative ARPU", + "content": "---\n\n* Накопительный ARPU - может помочь предсказать, когда клиенты начнут приносить денег больше, чем компания тратит на их привлечение.\n* Это метрика полезна для оценки трафика и срока его окупаемости, т.к важно знать, когда юзер начнет приносить больше денег, чем потратили на привлечение. Это будет момент, когда накопительный ARPU = [CPI](CPI.md).\n* В силу особенностей расчета накопительный ARPU позволяет сравнивать различные когорты, что удобно, когда вы сделали какие-либо изменения в продукте. В этом случае можно сравнить динамику накопительного ARPU для когорты, которая установила приложение до того, как в нем были сделаны изменения, с теми когортами пользователей, кто установил после. Это поможет вам  узнать, как внесенные изменения повлияли не на поведение пользователей, а именно на платежи.\n* Считается также как и [ARPU](ARPU.md) = доход когорты за период / юзеры в когорте за период.\n* Считается для определенной категории, а не для всех юзеров. Например, для тех, кто зашел в магазин в течение дня во время промоакции. Или юзеры установили приложение в определенный период.\n* Метрика увеличивается каждый день для 1й когорты - поэтому накопительный ARPU.\n* Допустим 1 января 2022 приложение установило 1000 юзеров. В первый день они совершали какие-то покупки, доход от которых составил 800$. APRU этой когорты дня установки (нулевого дня) 800 / 1000 = $0,8.\n* Теперь нужно считать дни с момента установки по табличке.\n\n||0|\n|--|-|\n|Доход|$800|\n|Дневной ARPU|$0.8.|\n|- На следующий день некоторые из этих же 1000 юзеров совершили еще покупки на общую сумму $500. Неважно сколько юзеров вернулось в продукт и сколько заплатили, размер когорты, на который делим доход всегда 1000 юзеров.||\n|- Поэтому считаем накопительный ARPU. ARPU 0го + 1го дней = $0.8 (800/100) + $0.5 (500/1000) = $1.3.||\n||0|\n|", + "lastmodified": "2022-04-23T12:45:42.666237559+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/DAUWAUMAU": { + "title": "DAU\u0026WAU\u0026MAU", + "content": "* Daily active users - n-кол-во уникальных юзеров в день, запустивших приложуху хотя бы 1 раз в течение дня.\n* Weekly active users - число уникальных юзеров в неделю.\n* Monthly active users - число уникальных юзеров в месяц. Метрика может совпадать со средней дневной аудиторией приложения в определенный месяц (в один и тот же).\n* Суть в уникальности юзера: например wau за какую-то неделю это не сумма dau за 7 дней. Юзер условно может зайти в приложуху в понедельник и в среду и будет защитан в dau понедельника и среды, но не вторника и т.д. Но в рамках wau - это будет 1 юзер, так как зашел в рамках 1 недели 1 раз. То же самое в MAU.\n* Средняя дневная аудитория – среднее арифметическое дневной аудитории за определенный период (считаем дневную аудиторию в каждый из дней периода, суммируем, делим на количество дней). \n* Cредняя дневная аудитория обычно меньше месячной. Но бывают крайние ситуации. Например в приложение каждый день на протяжении месяца заходили одни и те же 10 человек. Тогда месячная аудитория будет равна 10, так как есть всего 10 разных пользователей. Средняя дневная аудитория тоже будет равна 10, поскольку в каждый из дней выбранного периода в приложении было 10 уникальных пользователей - такое почти не встречается.\n* Чем ближе DAU(средняя)/MAU к единице, тем больше регулярность использования продукта. Если же отношение равно 1/30, то это значит, что в среднем пользователи заходят в продукт не чаще, чем раз в месяц.", + "lastmodified": "2022-04-23T12:45:42.655901083+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Gross-profit": { + "title": "Gross profit", + "content": "* Gross profit (Валовая прибыль) - разница между выручкой и всеми переменными затратами (COGS - cost of goods sold), которые напрямую связаны с реализованной услугой или продукцией.\n* По сути маржа с потока юзеров.\n* Gross profit = число платящих * доход на 1го платящего (ARPU или LTV). Например, Gross profit = 1700 платящих * 2100 руб. доход с одного = 3.57 млн руб.", + "lastmodified": "2022-04-23T12:45:42.658301905+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV": { + "title": "LTV", + "content": "* Lifetime value - средняя сумма выручки, которую принесет 1 юзер за все время использования продукта.\n* Вокруг этой метрики крутится маркетинг, работа над привлечением и удержанием клиентов, особенно в e-commerce.\n* Важно рассматривать его соотношение с другим показателем CAC. \n * Если соотношение 1:1 то это плохо и вы скоро разоритесь. \n * Если соотношение 2:1 - то это значит что почти нету прибыли. \n * Если 3:1 это оптимальное значение, при котором все хорошо, но можно расти дальше, а все что выше это просто супер.\n* Соотношение между ltv и cac покажет на сколько больше, допустим магазин, зарабатывает по сравнению с тем, сколько тратит на привлечение.\n* Понимая LTV, можно понять ценность клиента за какое-то время и то, что такие клиенты лояльны. Эти клиенты (с высоким ltv) дольше платят или же это клиенты с высоким средним чеком, а следовательно надо уделять им больше внимания и работать над их удержанием.\n* LTV помогает определить аудиторию для таргетинга в маркетинге и лучше понимать работу бизнеса.\n* Есть разные формулы как подсчитать ltv: чем сложнее формула, тем ближе отражает реальность.\n* LTV = [Lifetime](Lifetime.md) * [ARPPU](ARPPU.md). К примеру сервис с подпиской на месяц, где в среднем покупают подписку на 6 мес, а стоимость месяца 30 баксов. LTV = 30$ * 6 = 180$.\n * Берется показатель стоимости продукта/чека и lt, а поэтому будут погрешности.\n * Легко считать за любой период и для сегмента юзеров с любым средним чеком.\n* LTV = [AOV](AOV.md) * [RPR](RPR.md) * [Lifetime](Lifetime.md). К примеру интернет-магазин, в котором средний чек 600 рублей (aov\\_. Покупатели возвращаются два раза в год (rpr), а их средний litetime - 5 лет. Тогда LTV = 600 * 2 * 5 = 6000 рублей.\n* LTV связан с [CAC](CAC.md), ROI, [Churn rate](Churn%20rate.md), и [ARPPU](ARPPU.md) - надо анализировать все в комплексе, чтобы понимать текущую ситуацию с бизнесом.\n\nhttps://www.devtodev.com/education/articles/ru/174/main-metrics-ltv\nhttps://mindbox.ru/journal/tag/ltv/", + "lastmodified": "2022-04-23T12:45:42.661833011+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Lifetime": { + "title": "Lifetime", + "content": "* Это метрика, которая показывает, в течение какого времени человек остается активным пользователем продукта (цикл от первого до последнего запуска сервиса).\n* Прикидываем примерно или используя бенчмарки.", + "lastmodified": "2022-04-23T12:45:42.656074213+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/MRR": { + "title": "MRR", + "content": "* Monthly Recurring Revenue - регулярная месячная выручка.\n* Очень важно для сервисов по подписке.\n* MRR - просто цена, которую клиенты заплатили за месяц.\n* MRR = кол-во клиентов * средний доход с клиента.\n * 1000 * $1,59 = 1590.\n* Если клиенты платят больше чем за 1 месяц (например, 12 месяцев), просто разделите эту сумму на количество месяцев в периоде подписки.\n * MRR = $1590 / 12 = $132,5.\n* Умножив MRR на 12, получается годовой повторяющийся доход - ARR - annual recurring revenue, что позволяет строить прогнозы дохода на годы вперед.", + "lastmodified": "2022-04-23T12:45:42.656271927+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/North-star-metric": { + "title": "North star metric", + "content": "* **North Start Metric (NSM)** — это метрика, глядя на которую вы неминуемо придете к успеху.\n* Единый показатель, который отражает основную ценность продукта для клиентов.\n* NSM включает 3 параметра: доходность (видно что бабки получаем), ценность для юзера, измеримость (можно посчитать).\n* Пример: для фейсбука это ежедневная юзер активность. Для Airbnb - кол-во забронированных ночевок.\n* Эта метрика нужна, чтобы стратегия и планы компании не противоречили потребностям клиентов.\n* Для NSM нужна контрольная метрика, так как nsm это результат (то, что на выходе).\n * Пример nsm для медиа - кол-во активных юзеров в сутки, а проверочная метрика время юзера на сайте.\n * Пример nsm для ecommerce - кол-во заказов, а проверить это можно посмотрев на валовую прибыль.\n * Пример nsm для sass - кол-во юзеров, а проверка количество платящих клиентов.\n* На самом деле, несмотря на то, что NSM — отчасти утопия, **для конкретной фичи или задачи можно найти не просто хорошую, а очень хорошую метрику** (NSM, метрику Всевластия). У меня были такие кейсы в практике.\n* Если все круто, и вам однажды хорошо помогла одна метрика, NSM, главное не превратить работу всей компании **BDSM по росту NSM**. Что лично я и наблюдала, активно занимаясь консультациями по аналитике в некоторых ИТ-компаниях.\n* Чтобы найти метрику нужно понять для чего глобально продук: привлечение (время юзеров в продукте), транзакции (сколько бабок проходит через продукт), продуктивность (задачи, продуктивность в продукте).\n * У нетфликса цель привлечение юзеров и гипотетические nsm там время, проведенное в ленте, кол-во просмотров и кол-во просмотренного контента за месяц.\n * У амазона это транзакции, что ведет к таким nsm как кол-во покупок на одного юзера в amazon prime, кол-во покупок на одну сессию.\n * У adobe это продуктивность, где nsm будут кол-во данных, заносимых юзерами, кол-во подписчиков в аккаунте.\n * https://habr.com/ru/post/651875/", + "lastmodified": "2022-04-23T12:45:42.65691528+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit": { + "title": "Profit", + "content": "* Прибыль с потока юзеров = поток юзеров * (маржа на 1го привлеченного (AMPU или LTV - стоимость привлечения юзера CPI или CPU).\n * На сайт закинули 110 00 юзеров.\n * [CPA](CPA.md) допустим 13 руб.\n * [ARPPU](ARPPU.md) или [LTV](LTV.md) = 32,5 руб.\n * Profit = 110 000 * (32,5-13) = 2 145 000 руб.", + "lastmodified": "2022-04-23T12:45:42.65947844+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ROMI": { + "title": "ROMI", + "content": "* Return on Marketing Investments - коэфф. возврата маркетинговых инвестиций. \n* С ROMI можно оценить как расходы на маркетинг влияют на доходы компании: реклама, сайт, seo-продвижение, email-рассылки, блог и т.д.\n* Учитывается только маркетинг, без затрат на производство, зпшкм, аренды и т.д.\n* **ROMI = ([LTV](LTV.md) — [CAC](CAC.md)) / CAC x 100%**.\n * Если ROMI \u003e 0, то маркетинг канала прибыльный.\n * Если ROMI \\\u003c 0, то убыточный.\n * Пример по формуле для фитнес-приложения по подписке:\n * Если LTV = $35.75.\n * Если CAC = $149.\n * ROMI = (35,75 - 149) / 149 * 100 = -76%.\n * Юнит-экономика убыточна.\n * На каждый вложенный $1 мы заработаем $0.24.\n * Исходя из этого мы задаемся вопросами: почему так? какого хуя? где бабки? \n * Дальше думаем а \"что если...?\". Например, что если lifetime будет высокий? Что будет если снизится стоимость установки? И т.д.\n\n* **ROMI = Доход от рекламы / расход на маркетинг / расходы на маркетинг**.\n * Из инсты пришедшие купили 30 шт товара стоимостью 900 р. \n * Себестоимость товара - 400 р. \n * Доход от рекламы = (990-400) * 30 = 17700 р. \n * ROMI = (17 700 - 5000) / 5000 * 100 = 254% - реклама в инсте прибыльна, приносит 2,5 рубля на каждый потраченный 1 рубль. \n* ROMI равный 100% - точка безубыточности, т.е. инвестиции возвращаются без дохода.\n* ROMI меньше 100% - вложения не окупаются.\n* ROMI равный 0% - ушли в ноль.\n* ROMI с отрицательным значением - заработали меньше, чем вложили.\n* Часто путают с ROI, ROAS и наоборот.\n * ROI - коэфф. окупаемости возврата всех инвестиций, т.е. насколько выгоден весь проект с учетом **всех** вложений. ROI = доходы - затраты / затраты * 100.\n * ROMI - учитывает только маркетинговый бюджет: рекламный бюджет, полиграфию, билборды, но **не включает затраты на производство товара**.\n * ROAS - коэфф. окупаемости затрат на конкретную рекламную кампанию. Задача этой метрики показать получает ли прибыль компаний от n-инструмента рекламы. ROAS = доход от рекл. кампании / ее стоимость.\n* Подробнее ROI. \n * Потратили на рекламу 3530 р., продали 8 шт товара по 800 р. ROI = (8 * 800 - 3530) / 3540 * 100 = 81% - убыточна, отключаем рекламу.\n * По другому товару тоже была реклама, которая стоила 5280 р., продали 10 шт товара по 1500 руб. и ROI = (10 * 1500 - 5280) / 5280 * 100% = 184% - прибыльна, окупилась.\n * Но в отрыве от контекста - не показетльно. Можно получить большой roi при маленькой прибыли в целом. \n * Нужно продать максимум товара и получить максимум прибыли, чтобы настало время оптимизировать каналы и повышать показатель ROI.\n * Если максмум продать не получается, то надо достичь этой точки и расширять рынок сбыта: больше тратить на рекламу и снижать ROI.\n * ROI считают тогда, когда надо принять управленческое решение.", + "lastmodified": "2022-04-23T12:45:42.661903638+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/RPR": { + "title": "RPR", + "content": "* Repeat Purchase Rates - частота повторных покупок.\n* Очень полезен в ecommerce.\n* Индикатор лояльности.\n* RPR = кол-во клиентов, купивших более 1 раза за n-период / кол-во клиентов за этот период * 100.", + "lastmodified": "2022-04-23T12:45:42.65663748+03:00", + "tags": null + }, + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Retention": { + "title": "Retention", + "content": "* Коэффициент удержания клиентов - процент юзеров, которые все еще используют приложение после n-количества дней с момента первого взаимодействия. \n* Это одна из ключевых метрик любого продукта, но ключевые - CAC и LTV.\n* Retention определеяет потенциал роста бизнеса, а также влияет на монетизационные метрики. \n* Важно понимать какой именно метод расчета был использован. Выбор того, с какой гранулярностью считать Retention для конкретного продукта зависит от специфики использования.\n* **Retention Day N** = кол-во юзеров, которые открыли приложение N день после дня 0 / кол-во юзеров, которые впервые использовали приложение на день 0.\n * Пример: если retention 2го дня = 50%, то это значит, что 50% новых юзеров этого продукта возвращаются в него на 2й день. Обычный Retention работает намного лучше для задач анализа экспериментов или сравнения версий продуктов\n* Что показывает Retention N?\n * Retention 1го дня - интерес. В течение 1го дня с момента установки мобильного приложения большинство юзеров смогут оценить только основную функциональность и именно этот опыт определит продолжат ли они использование или нет.\n * Retention 7го дня - core loop (основной цикл) продукта. Также это дает первичное представление о вовлечении в продукт.\n * Retention 30го дня - качественный и глубокий продукт.\n* **Rolling ratention** = кол-во юзеров, которые были активны в N день или позже / кол-во юзеров, которые впервые использовали приложение на день 0.\n * Это % новых юзеров вернувшихся в конкретный день с момента прихода или любой день после него. Пример: если rolling retention 2го дня = 50%, то это значит, что 50% новых юзеров этого продукта возвращаются в него на 2й день или позже.\n * Минус в том, что она может постоянно меняться. Если юзер в первый раз вернется в приложение спустя 90 дней, то он увеличит Rolling Retention для всех предыдущих дней.\n * Использовать когда подразумевается достаточно редкое использование продукта. Например, если надо проанализировать возвращаемость в приложение для покупки авиабилетов или отелей.\n * Или когда надо ответить \"А какая часть юзеров хотя бы раз вернулась в приложение после 30 дня?\"\n* Расчет **Retention на основе 24-часовых окон** считается на основе индивидуальных временных интервалов. День 0 конкретного юзера начинается с момента 1го запуска и заканчивается через 24ч. День 1 начинается спустя 24 часа после первого запуска и заканчивается спустя 48ч и т.д.\n * Пример:\n * Retention 1 дня = ~10% для когорты из 1000 новых юзеров, которые пришли 1 окт.\n * Это значит, что 100 из этих юзеров зашли в приложение между 24 и 48 часов после 1го запуска.\n * Временной интервал 1 дня для разных пользователей в данном случае будет индивидуальным.\n* Расчет **Retention на основе календарных дней** - все юзеры, которые пришли в определенный день, окно первого дня при расчете Retention будет одинаковым. Это будет просто следующий календарный день. Если сравнивать с 24-часовыми окнами, то по календарным дням метрика будет выше, но в долгосроке сравняется. Потому что юзеры могут с бОльшей вероятностью посчитаться системой как вернувшиеся.\n * Пример\n * Retention 1 дня ~10% для когорты из 1000 новых юзеров, которые пришли 1 окт.\n * Это значит, что 100 юзеров из этой когорты запустили приложение 2 октября.\n * Среди них вполне могут быть пользователи, которые впервые открыли приложение 1 октября в 23:50, а потом еще раз в 2 октября в 00:10, то есть спустя 20 минут. При расчете на основе календарных дней такие пользователи засчитается как те, кто вернулся на 1 день.\n* Почему важно знать то, как именно посчитан Retention? Потому что метрика часто используется для сравнения продуктов между собой или для сравнения их с рыночными бенчмарками. Это нужно для понимания возвращаемости продукта: хорошо или плохо. Важно это потому что если ты смотришь в систему Amplitude на ретеншен 1го дня = 32%, то это ничего не дает, поэтому ты идешь сравнивать с бенчмарком например Appsflyer и понимаешь что недотягиваешь и закрываешь проект. Но это может быть ошибкой, поскольку твоя система считает метрику на основе 24-часовых оконон, а Appsflyer по умолчанию считает на основе календарных дней. Поэтому если пересчитаешь в своей на основе календарных дней, то метрика изменится и станет выше и ты не закроешь хороший проект.\n* Как лучше считать? Нет однозначного ответа:\n * Расчет Retention на основе 24-часовых окон дает более честный ответ на вопрос о том, как продукт возвращает юзеров, но требует больше времени. То есть данные по метрике получишь спустя 2 календарных дня (48 часов с момента прихода последнего юзера)\n * При расчете на основе календарных дней, значение Retention 1 дня будет доступно уже через 24 часа. Это хорошо, когда критична скорость получения данных, например, для маркетинговых компаний.\n* От чего зависит Retention? От 2 переменных: самого продукта и от юзеров, которые приходят. Если в продукт привлечь нерелевантных юзеров, то Retention будет низким. Если в плохой продукт привлечь релевантных юзеров - аналогично.\n* Долгосрочный Retention 30+ - основа роста. Если кривая Retention выходит на плато на адекватном уровне и продолжает идти параллельно оси Х — означает, что новых юзеров становятся регулярными лояльными клиентами. Если это так - есть фундамент для сильной монетизации и вывода продукта на широкую аудиторию через платные каналы привлечения юзеров.\n* Почему иногда НЕ следят за долгосрочным retention?\n * Требуется много времени, чтобы посчитать.\n * Для получения статистически значимых результатов на далеком горизонте нужно много юзеров, а большинство отваливаются не дожив до 30го дня.\n * Команды склонны фокусироваться на коротком горизонте, стремя улучшать продукт еженедельно или каждые 2 недели.\n* Почему долгосрочный retention важен? \n * Способность конвертировать новых юзеров в стабильную возвращающуюся активную аудиторию создает большое пространство для качественной монетизации.\n * LTV юзеров с долгосрочным Retention растет на протяжении очень длительного времени, обеспечивая уровень LTV, который позволит команде увеличить объем платного привлечения. В таких продуктах появление новых юзеров оказывает меньше влияния на доходы в моменте, т.к. формируется старыми юзерами. Добавление нового контента для старых юзеров в таких продуктах является одним из основных рычагов влияния на доходы.\n * В продуктах где плохой долгосрочный Retention приходится агрессивно монетизировать юзеров с самого старта, чтобы достичь LTV для продвижения через платные каналы. При этом все равно такие монетизации ограничены из-за плохого уровня долгосрочного Retention. Фокус на привлечении новых юзеров и оптимизацию онбординга и UX в первые 30 дней. Приток новых юзеров оказывает сильное влияние на доход. Легко понять такие продукты по недельной/месячной кривой.", + "lastmodified": "2022-04-23T12:45:42.663954699+03:00", + "tags": null + }, + "/Product/Analytics-system/Amplitude": { + "title": "Amplitude", + "content": "---\n\n# Amplitude\n\n## Как данные оказываются в системе аналитики\n\nВ приложение встраивается специальный SDK, который позволяет отправлять события в систему аналитики. После разработчик добавляет отправку событий в нужные места в приложении (например, при первом запуске приложения или при отправке сообщения).\n\nКогда пользователь взаимодействует с приложением, при совершении определенных действий от него на серверы системы аналитики отправляются события. А мы можем изучать эти данные и отвечать на интересующие нас вопросы.\n\nВ самой системе аналитики для получения событий ничего предварительно настраивать не нужно. Amplitude получает все события, которые приходят из приложения, и позволяет с ними работать с помощью разных инструментов.", + "lastmodified": "2022-04-23T12:45:42.660983568+03:00", + "tags": null + }, + "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8": { + "title": "Бизнес-модели", + "content": "В целом почти все одинаково: на входе юзеры, с которых получаем внимание, а зате на выходе получаем деньги деньги.\n\n* [SaaS](SaaS.md)\n* [Shop](Shop.md)\n* [Social media](Social%20media.md)\n* [Marketplace](Marketplace.md)\n* [Dropshipping](Dropshipping.md)", + "lastmodified": "2022-04-23T12:45:42.662436154+03:00", + "tags": null + }, + "/Product/Business-Models/Dropshipping": { + "title": "Dropshipping", + "content": "https://dodropshipping.com/google-analytics-for-ecommerce-beginners-guide/\nhttps://www.cloudways.com/blog/ecommerce-kpis/\nhttps://www.reddit.com/r/dropship/comments/ljwku1/what_are_the_key_metrics_i_should_look_at_when/\nhttps://brandafy.com/blog/key-ecommerce-metrics-make-money-online/\nhttps://blog.shift4shop.com/ecommerce-metrics-kpis-to-track\nhttps://www.quora.com/What-metrics-do-you-use-to-measure-whether-or-not-a-dropshipping-store-idea-is-going-to-be-successful\nhttps://www.modalyst.co/blog/five-unique-e-commerce-metrics-tracking/\nhttps://www.youtube.com/watch?v=nbnXzg7e3Dg\nhttps://www.youtube.com/watch?v=0BbDb7cfRzg\nhttps://www.youtube.com/watch?v=UQ6TtB1yZqo\nhttps://brandsgateway.com/blog/dropshipping-kpis/\nhttps://edi3.dicentral.com/five-critical-dropship-kpis-for-retail-edi-ecommerce-managers\nhttps://www.shopify.com/blog/7365564-32-key-performance-indicators-kpis-for-ecommerce\nhttps://www.oberlo.com/blog/key-performance-indicators-kpis\n\nhttps://alidropship.com/ecommerce-metrics-to-track-in-dropshipping/", + "lastmodified": "2022-04-23T12:45:42.662994171+03:00", + "tags": null + }, + "/Product/Business-Models/Marketplace": { + "title": "Marketplace", + "content": "", + "lastmodified": "2022-04-23T12:45:42.659976538+03:00", + "tags": null + }, + "/Product/Business-Models/SaaS": { + "title": "SaaS", + "content": "# SaaS\n\nhttps://baymard.com/blog/saas-benchmark", + "lastmodified": "2022-04-23T12:45:42.6631363+03:00", + "tags": null + }, + "/Product/Business-Models/Shop": { + "title": "Shop", + "content": "", + "lastmodified": "2022-04-23T12:45:42.660113167+03:00", + "tags": null + }, + "/Product/Business-Models/Social-media": { + "title": "Social media", + "content": "", + "lastmodified": "2022-04-23T12:45:42.660229879+03:00", + "tags": null + }, + "/Product/Frameworks/%D0%9F%D0%B8%D1%80%D0%B0%D0%BC%D0%B8%D0%B4%D0%B0-%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA": { + "title": "Пирамида метрик", + "content": "---\n\n#### Что надо знать\n\n* Есть иерархия и пирамида метрик - модели, которые помогают привести в порядок метрики, определить зависимости между ними и лучше следить за изменениями в продукте.\n* Иерархия метрик - древовидная структура, во главе которой основная метрика продукта.\n* Пирамида метрик - то же самое: инструмент для анализа показателей продукта, но с классификаций.\n\n#### Пирамида метрик\n\n##### Из чего состоит пирамида\n\n* Бизнес-метрики - про цель, которая может быть не связана с деньгами (profit).\n* Экономика - деньги и экономика (cac, mARPPU, AOV)\n* Продуктовые метрики\n * Лояльность - (ретеншен)\n * Ценность - решает проблему юзера\n * Качество - не обязательно ценит юзера. пример: айфон качественный, но я не ЦА продукта.\n* Маркетинговые источники (по источникам будет меняться все выше).\n\n![375](img/metrics-pyramid.png)\n\n##### Основное\n\n* Баланс между показателями бизнеса и продукта. Пример: фейсбук убирате рекламу и продуктовые метрики растут, а бизнесовые падают. \n* Продукт - это формула нахождения продуктовых метрик (product value и quality).\n* Иерархия - приоритезация метрик и бэклога.\n* Декомпозиция - провязка метрик разных уровнях.\n\n##### Бизнес\n\n* Зачем нужен этот бизнес? Как определить:\n * От чего зависит рост метрики бизнес-цели?\n * На какие метрики влияет конкретная команда людей/фича продукт?\n* Чтобы извлекать прибыль: Revenue, costs, mau, ltv, new, cac, opex\n* Чтобы получить инвестиции: MAU, ROI, Retention, LTV, CAC, Revenue\n\nProfit = Revenue (mau, ltv (efficiency, retention, avg. revenue)) - costs (new, cac)\n\n##### Экономика\n\nМогут быть деньги, польза, интерес, время, агенты (типы юзеров на примере барбершопа: барберы, клиенты, сервис)\n\n* Барбер (+средн. чек +загрузка -цена простоя -комиссия)\n* Клиенты (скидка на 1ю покупку +услуга -время ожидания -рост трат на повторные покупки)\n* Сервис (+доход, -расходы на оптимизацию)\n\n##### Продукт\n\n* Слой делится на:\n * Решение пробелмы - модель юзера (клики, переходы, время на сайте)\n * Лольяность - насколько нравится (возвращаемость, число сессий)\n * Качество - качество продукта (вероятность найти ответ)\n\n##### Интерфейс\n\n* Учитываются: Экраны, блоки и кнопки на экранах\n* Для экранов - конверсии в воронке\n* Для всех остальных: аудитория, время, ctr\n\n##### Как создать\n\n* брейнсторм - собрать то, что уже есть и на что смотрим, на что хотим смотреть и накинуть идеи о том, что важно считать.\n* ревью метрик и классификация по слоям для базовой иерархии.\n* раскидываем связи между метрик.\n* анализ метрик на основе опыта и методологии lean analytics.\n* изучить метрики.\n* проверить иерархию с помощью статистики и экспериментов.\n* построить дэшборд - кол-во метрик на дэшборде зависит от необходимой скорости реагирования на их изменения, команды заказчиков и стадии развития бизнеса.", + "lastmodified": "2022-04-23T12:45:42.665408743+03:00", + "tags": null + }, + "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8": { + "title": "Фреймворки", + "content": "Для работы с метриками есть фреймворки:\n\n* [AARRR](AARRR.md)\n* [HEART](HEART.md)\n* [Пирамида метрик](%D0%9F%D0%B8%D1%80%D0%B0%D0%BC%D0%B8%D0%B4%D0%B0%20%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA.md)", + "lastmodified": "2022-04-23T12:45:42.663273762+03:00", + "tags": null + }, + "/Product/Frameworks/AARRR": { + "title": "AARRR", + "content": "* Это воронка с 5 этапами: acquisition (привлечение), activation (активация), Retention, revenue, Referral.\n\n* Нужна, чтобы разделить работу с юзером на этапы и отслеживать метрики на каждом из них.\n\n* Активно используется в мобилках, saas и стартапах.\n\n* Acquisition - привлечение.\n \n * Это начало воронки.\n * Как юзеры узнают о продукте? Соцсети, email, поиск гугл, поис app store, блоги, сео, вебинары, контекстная и таргетированная реклама.\n * Из каких каналов приходят пользователи?\n * Пример метрик: если объявление в fb, то это cpc, ctr, cpm, frequency, cpr, roi, roas, registration/downloads.\n* Activation - активация.\n \n * Какое ключевое действие должен сделать пользователь чтобы стать клиентом? Активация? Подписка? Заказ? \n * Как получают 1й опыт взаимодействия с продуктом?\n* Retention - удержание. \n \n * Используют ли продукт повторно?\n * Что заставит пользователя вернуться завтра? через неделю? через месяц? \n * У продуктов разное удержание.\n * Пример метрики dau/mau, session time, глубина просмотра.\n* Revenue - доход.\n \n * За что пользователь платит деньги?\n * Как продукт монетизируется?\n * Примеры метрик: ARPU, ARPPU, LTV, CAC.\n* Referral - рекомендации. \n \n * Приводят ли юзеры друзей?\n * О чем клиент захочет рассказать своим друзьям?\n * Пример метрики это число людей, которое зарегистрировалось через рефералку, то есть реферала + конверсия в подписку или покупку после приглашения по реферальной программе, которую надо спроектировать и придумать совместно с командой. \n* [Полный гайд по AARRR](https://vc.ru/life/116967-samyy-polnyy-gayd-po-freymvorku-aarrr-s-keysami-prodakt-menedzherov-megadiska-i-storebox) \n\n* [AARRR на примере tinder](https://vc.ru/marketing/32256-privlech-polzovatelya-i-zarabotat-na-nem-effektivnost-marketingovoy-voronki-aarrr-na-primere-tinder)\n\n* [Startup Metrics for Pirates: AARRR! - Dave McClure](https://youtu.be/irjgfW0BIrw)", + "lastmodified": "2022-04-23T12:45:42.666750908+03:00", + "tags": null + }, + "/Product/Frameworks/HEART": { + "title": "HEART", + "content": "---\n\n* Это фреймворк, созданный Google.\n* Смысл в том, что метрики делятся на несколько категорий и каждая буква в названии - это категория. \n* Работает отлично совместно с командой.\n* H - Happiness (Счастье). E - Engagement (Вовлечение). A - Adoption (Принятие). R - Retention (Удержание). T - Task Success (Успех выполнения задач). \n\n#### Happiness - Счастье \n\n* Измеряется отношение юзера к продукту.\n* Через интервью/опросы\n* Примеры метрик: удовлетворение, легкость в использовании и NPS.\n* Еще CJM, чтобы понять общую удовлетворенность по клиентскому пути.\n\n#### Engagement — Вовлеченность \n\n* Зависит от продукта и типа активности, которая важна для трекинга.\n\n#### Adoption — Принятие \n\n* В рамках фреймворка тут суть в получении новых юзеров: конверсия из бесплатного на какие-либо платные тарифы. Это могут быть новые юзеры в продукте или же кол-во юзеров, которое стало использовать какую-то фичу.\n\n#### Retention — Удержание \n\n* Это про то, как много юзеров возвращаются и про повторные покупки.\n* В отличие от принятия, тут важно, чтобы каждый клиент приносил больше денег, а не на том чтобы получить больше клиентов.\n\n#### Task success — Успех выполнения задания \n\n* Поведенческие UX метрики: время на выполнение задания, чтобы понять оперативность. Процент выполненных заданий, чтобы проверить эффективность решения и процент ошибок. \n\n#### Цели-сигналы-метрики \n\nВ фреймворке для расставления приоритетов надо работать с целями, сигналами и метриками.\n\n##### Цели \n\n* Выбрать букву(-ы) и определить цель.\n* Не натягивать цели на текущие метрики. Фокус на опыте юзера. \n* Ставим цель на букве например: \n * **Удержание**: юзеры должны возвращаться в приложение и делать целевое действие.\n * **Вовлеченность**: юзеры должны быть довольны контентом и исследовать его больше.\n * **Принятие**: юзеры должны увидеть ценность в новой функции Икс.\n * **Успех выполнения задачи**: банально надо выполнять цель в продукте успешно и быстро. \n* Пример: цель \"вовлечения\" для ютуба это чтобы юзеры наслаждались просмотром и исследовали больше видосов. \n\n##### Сигналы \n\n* Любая цель дробится на сигналы.\n* Сигнал - это то, что говорит нам о достижении целей. \n* Чтобы выбрать сигнал, нужно выбирать то, что можно отследить и чтобы это было просто для измерения, а также чтобы это было заметно именно с точки зрения дизайна, т.е. если поменяли дизайн, то ощутили изменения в цифрах.\n* Примеры: это может быть скачивание приложения, регистрация аккаунта и использование каких-то функций продукта, что сразу отразится на категории принятия. Или же количество времени, которое юзер проводит, изучая контент в продукте, что отражается на вовлеченности. Или же еще проще: юзеры делают повторные покупки или обновляют подписку, что отражается на удержании. Даже еще проще, если мы говорим про успешность задач - это когда юзеры быстро находят нужный контент. \n* Пример с ютубом: сигналом \"вовлеченности\" будет кол-во времени, которое юзеры тратят на просмотр видосов.\n\n##### Метрики \n\n* Выбирать и приоритезировать метрики исходя из целей/сигналов.\n* Проверять на ab или юзабилити -тестах и даже корридорки.\n* Выбирая, задать себе вопрос: какая метрика будет для успеха и не успеха.\n* Пример с ютубом: метрикой будет средн. кол-во минут на просмотр видео юзером в день.\n\n||Goals.|Signals|Metrics|\n|--|", + "lastmodified": "2022-04-23T12:45:42.660660642+03:00", + "tags": null + }, + "/Product/Product": { + "title": "Product", + "content": "* *База*\n* [Фреймворки](Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8.md)\n* [Юнит-экономика](Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0.md)\n* [Бизнес-модели](Business%20Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8.md)", + "lastmodified": "2022-04-23T12:45:42.667364093+03:00", + "tags": null + }, + "/Product/Terms/%D0%92%D0%BE%D1%80%D0%BE%D0%BD%D0%BA%D0%B0": { + "title": "Воронка", + "content": "* Это путь, который проходит потенциальный клиент от момента привлечения до момента покупки.\n* Потенциальный клиент - это лид. Лидов надо конвертировать в платящих клиентов.\n* Путь клиента зависит от продукта, но в целом юзер сперва осознает наличие какой-то проблемы/задачи, затем у юзера возникает интерес и он ищет решение, затем у юзера появляется желание попробовать/купить решение, а затем он соверашет (или нет) действие (покупку и т.д.).\n* Дизайнеру важно понимать, что его макеты это не просто картинка.\n* Дизайнеру важно понимать как работает юзер с сайтом/продуктом, чтобы проектировать и придумывать решения, которые будут конвертировать на каждом этапе воронки юзера в платящего клиента.", + "lastmodified": "2022-04-23T12:45:42.660104334+03:00", + "tags": null + }, + "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9": { + "title": "Глоссарий", + "content": "* [Среднее арифметическое](%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5%20%D0%B0%D1%80%D0%B8%D1%84%D0%BC%D0%B5%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5.md)\n* [Медианна](%D0%9C%D0%B5%D0%B4%D0%B8%D0%B0%D0%BD%D0%BD%D0%B0.md)\n* [Причинно-следственная связь](%D0%9F%D1%80%D0%B8%D1%87%D0%B8%D0%BD%D0%BD%D0%BE-%D1%81%D0%BB%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F%20%D1%81%D0%B2%D1%8F%D0%B7%D1%8C.md)\n* [Корреляция](%D0%9A%D0%BE%D1%80%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D1%8F.md)\n* [Soft launch](Soft%20launch.md)\n* [Когортный анализ](%D0%9A%D0%BE%D0%B3%D0%BE%D1%80%D1%82%D0%BD%D1%8B%D0%B9%20%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7.md)\n* [Product market fit](PMF.md)\n* [Воронка](%D0%92%D0%BE%D1%80%D0%BE%D0%BD%D0%BA%D0%B0.md)\n* [Юнит-экономика](%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0.md)\n* [Продуктовая гипотеза](%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0.md)", + "lastmodified": "2022-04-23T12:45:42.659927912+03:00", + "tags": null + }, + "/Product/Terms/%D0%9A%D0%BE%D0%B3%D0%BE%D1%80%D1%82%D0%BD%D1%8B%D0%B9-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7": { + "title": "Когортный анализ", + "content": "* Когорта - это просто группа людей, объединённых из-за сходства или общей ценности.\n* Когортный анализ - это очень эффективный инструмент продуктовой и маркетинговой аналитики.\n* С его помощью вы можете определить, как ведет себя каждая когорта и с какой вероятностью доходит до целевого действия.\n\nhttps://www.carrotquest.io/blog/kak-zapustit-kogortnyj-analiz-v-google-analytics/", + "lastmodified": "2022-04-23T12:45:42.660824355+03:00", + "tags": null + }, + "/Product/Terms/%D0%9A%D0%BE%D1%80%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D1%8F": { + "title": "Корреляция", + "content": "**Корреляция** – связь 2 величин, где смена 1й сопутствует систематическому изменению 2й. При этом связь может как быть, так и не быть причинно-следственной (например, 2 величины зависят от 3ей, но не зависят друг от друга).\n\nНапример, мы проанализировали юзеров мобильной игры и заметили, что юзеры, которые подключают Facebook к приложению, чаще совершают внутренние покупки. Это значит что мы сделаем так, чтобы больше юзеров подрубали Facebook к приложухе, то увеличим число покупок? Ответ: нельзя ответить, потому что это корреляция. Наличие корреляции между подключением Facebook и покупкой в будущем не доказывает наличия причинно-следственной связи. При этом она вполне может существовать.\n\nВозможны следующие причины:\n\n1. Юзеры игры, подключающие Facebook, изначально лучше мотивированы. Поэтому они и подключают Facebook, и делают больше покупок. То есть существует иная причина, которая влияет на оба явления.\n1. При этом возможно, что само подключение Facebook через некие механизмы влияет на юзеров, и они с большей вероятностью покупают.\n\nНо только на основании этой корреляции мы не способны ни доказать, ни опровергнуть существование здесь причинно-следственной связи.\n\nВсегда надо очень четко различать корреляцию и причинно-следственную связь.\n\nЕсли между переменными есть причинно-следственная связь, то между ними точно будет корреляция.\n\nНо если между переменными наблюдается корреляция, то причинно-следственной связи может не существовать. Единственный способ доказать наличие причинно-следственной связи – провести эксперимент.\n\nСсылка: https://amplitude.com/blog/causation-correlation", + "lastmodified": "2022-04-23T12:45:42.663583938+03:00", + "tags": null + }, + "/Product/Terms/%D0%9C%D0%B5%D0%B4%D0%B8%D0%B0%D0%BD%D0%BD%D0%B0": { + "title": "Медианна", + "content": "**Медиана** – это такое число в выборке, что ровно половина из элементов выборки больше него, а другая половина меньше него. Медиану можно найти, упорядочив элементы выборки по возрастанию и взяв средний элемент. \n\nВ примере выше было 13 элементов. Если их упорядочить по возрастанию, то 7-й элемент будет равен 8. Это и есть медиана. Половина элементов выборки больше этого значения, а половина меньше.\n\nМедиана хорошо подходит для оценки параметров, когда число элементов в выборке невелико и среднее арифметическое может быть сильно смещено вверх или вниз из-за отдельных членов, которые выбиваются из ряда.\n\nНапример, вы хотите оценить время, которое юзеры тратят на прохождение обучения в приложении. Для этой задачи хорошо подойдет медиана. Среднее арифметическое, скорее всего, будет сильно завышенным. Всегда найдется несколько юзеров, которые очень долго проходили онбординг и теперь перекашивают общую картину.", + "lastmodified": "2022-04-23T12:45:42.663497394+03:00", + "tags": null + }, + "/Product/Terms/%D0%9F%D1%80%D0%B8%D1%87%D0%B8%D0%BD%D0%BD%D0%BE-%D1%81%D0%BB%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F-%D1%81%D0%B2%D1%8F%D0%B7%D1%8C": { + "title": "Причинно-следственная связь", + "content": "Это связь 2 величин, при которой изменение одной величины порождает (всегда) изменение другой.", + "lastmodified": "2022-04-23T12:45:42.655800121+03:00", + "tags": null + }, + "/Product/Terms/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0": { + "title": "Продуктовая гипотеза", + "content": "* Предположение об изменении состояния продукта в зависимости от действий.\n* Легко общаться с командой и стейкхолдерами.\n* По сути [mvp](../../Design/Base/%D0%A7%D1%82%D0%BE%20%D1%82%D0%B0%D0%BA%D0%BE%D0%B5%20MVP.md) это 1 большая гипотеза\n* Вопросы для указания границ гипотез:\n * Что мы хотим изменить в продукте? - Новый экран покупки.\n * Какая метрика изменится в результате? - Увеличит конверсию в покупку.\n * На ком мы будем измерять эффект? - Для юзеров из FB из США.\n * На сколько изменится нужная метрика? - На 12%.\n * За какой период мы получим результат? - В течение 2х недель.\n* Способы для проверки гипотез: а/в-тесты, опросы, cusdev (еще до mvp).\n* Продуктовая гипотеза может описываться по smart.", + "lastmodified": "2022-04-23T12:45:42.661175283+03:00", + "tags": null + }, + "/Product/Terms/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5-%D0%B0%D1%80%D0%B8%D1%84%D0%BC%D0%B5%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5": { + "title": "Среднее арифметическое", + "content": "Это сумма всех значений выборки, деленная на их количество. Например, приложением в декабре воспользовались 13 человек. Ниже показано, сколько раз каждый из них заходил в приложение за декабрь. Одно число соответствует числу запусков приложения за месяц одним пользователем.\n\n(1 + 1 + 2 + 5 + 6 + 7 + 8 + 12 + 20 + 25 + 57 + 118 + 333) / 13 = 45.7 (ср. ариф. кол-во использований приложения на юзера в декабре месяце)\n\nРаботая с данными, мы часто прибегаем к среднему арифметическому, чтобы узнать, как устроен изучаемый объект. В некоторых случаях этот подход может ввести в заблуждение. Чаще всего это случается, когда не очень много данных или разброс значений изучаемого параметра велик.\n\nНапример, зарплата у некоторых бывает заоблачной, поэтому для нее среднее арифметическое надо использовать аккуратно. А вот рост человека находится в предсказуемых рамках (не бывает людей ростом 10000 метров), и тут среднее арифметическое отлично характеризует описываемое множество элементов.\n\nПрежде чем считать среднее арифметическое или медиану, изучите структуру данных и поймите, какая метрика лучше ответит на ваш вопрос.", + "lastmodified": "2022-04-23T12:45:42.661322829+03:00", + "tags": null + }, + "/Product/Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0": { + "title": "Юнит-экономика", + "content": "* Это анализ экономики 1й продажи, 1го юнита.\n* Пример: подписка на спотифай, еда на доставку и т.д.\n* Помогает понять, будет ли проект приносить прибыль.\n* Юнит - это единица того, что покупается.\n* Надо знать сколько тратишь на привлечение одного пользователя (CAC), и сколько этот пользователь в среднем приносит денег (LTV). \n* Соотношение cac и ltv - это юнит-экономика.\n* Главная метрика в юнит-экономике — это ROMI.\n* Важно шарить за [метрики](../%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8.md).\n* Очень важно чтобы юнит-экономика сходилась с реальностью.\n* Критично: целеполагание компании.", + "lastmodified": "2022-04-23T12:45:42.660482387+03:00", + "tags": null + }, + "/Product/Terms/PMF": { + "title": "PMF", + "content": "Product Market Fit — это когда продукт соотвествует ожиданиям ЦА, находится на подходящем рынке и может его удовлетворить. Определений на самом деле много, но суть одна: PMF — показатель соответствия продукта ожиданиям потребителей. Если критерий не достигнут, продажи будут минимальными, успешность проекта низкая и наоборот. Product-market fit достигается из создания ценностного предложения и не может родиться из точечных поправок в продукте — например, изменения дизайна/цвета и т.д. **Product Market fit** – это доказательство существования спроса на продукт и способности идеи стать растущим бизнесом. Термин в основном применяется к стартапам, работающим в новых областях и с новыми бизнес-моделями. \n\n**Зачем нужен PMF?**\nПрежде чем компания разработает продукт, она должны подтвердить, что достаточное количество людей готовы платить за него, поэтому команды не могут позволить себе сосредоточиться на других важных стратегических задачах, таких как рост или повышение продаж существующим пользователям. Эти инициативы могут даже оказаться контрпродуктивными, если компания сначала не определила, что продукт достаточно соответствует рынку, чтобы существовать и приносить прибыль. Достижение product/market fit — фундамент успеха для любой компании и стартапа. Отсутствие же product/market fit — причина почти всех известных нам провалов.\n\n**Простой пример PMF**\nЕсли бизнес – продажа ж/д билетов через сайт, то Product Market fit был пройден давно и скорее всего не вами. Очевидно, что спрос на услугу существует, люди покупают билеты на поезда через интернет. Задача Growth Hacking'а в таком бизнесе - экспериментировать и находить новые точки роста. \n\nЕсли бизнес – продажа комбинированных железнодорожных маршрутов по России для иностранных путешественников, то требуется подтверждение Product Market fit. Прежде, чем взламывать рост, нужно доказать, что услуга имеет ценность для клиентов, их реально привлечь в необходимом количестве, а маржа от продажи услуги будет выше стоимости привлечения. То есть, доказать существование рынка и возможность зарабатывать на нем. \n\n**Сигналы о достижении product/market fit существуют во многих формах.**\n\n* Явный перелом в росте органического трафика;\n* Клиенты готовы заплатить за ваш продукт еще до того, как вы их просите;\n* Пользователи, которые раньше радовались тому, что у вас есть, теперь начинают злиться из-за того, чего у вас нет;\n* Клиенты жалуются, когда ваш сайт падает;\n* Люди пользуются продуктом, даже если он не до конца работает или сломан.\n\nТакже около половины из этих компаний нашли product/market fit сразу после запуска, но другая половина потратила на это месяцы или даже годы.\n\n**Как добиться PMF?**\n\n**Правильно**\n\n1. целевой клиент через сегментацию рынка и персонажей (все в команде понимают для кого они делают продукт)\n1. неудовлетворенные потребности клиента - понять через cusdev какие не удовлетворены и какие удовлетворены слабо;\n1. ценностное предложение через план того, как продукт сможет лучше удовлетворять потребности - value proposition canvas;\n1. набор функций определить что будет в mvp;\n1. Создать mvp.\n1. Продвигать продукт\n1. Замерять фидбек через опросник PMF или NPS\n\n**Самый дешевый способ**\n\nНет ничего зазорного в том, чтобы привлекать клиентов в несуществующий продукт. Если вы действительно имеете намерение его создать, конечно. Сформулировав ценность и подготовив минимальный набор презентационных материалов, можно приступать к поиску клиентов. Это самый адекватный и экономичный способ подтвердить или опровергнуть Product Market fit для нового продукта, не потратив лишних денег и ресурсов. Если же Product Market fit подтвердится, можно смело приступать к разработке первой версии. И не с голыми намерениями и светлой идеей, а имея на руках контакты 5000 клиентов, первые оплаты и огромную базу для сбора обратной связи. \n\n[https://medium.com/steelhead/how-i-grew-our-waitlist-to-5-000-people-in-10-weeks-and-how-you-can-too-part-1-fcff7b39d8aa](https://medium.com/steelhead/how-i-grew-our-waitlist-to-5-000-people-in-10-weeks-and-how-you-can-too-part-1-fcff7b39d8aa) \n\n[https://medium.com/steelhead/how-i-grew-our-waitlist-to-more-than-5-000-people-in-10-weeks-and-how-you-can-too-part-2-cc80fc8f5add](https://medium.com/steelhead/how-i-grew-our-waitlist-to-more-than-5-000-people-in-10-weeks-and-how-you-can-too-part-2-cc80fc8f5add) \n\n**Как измерить PMF?**\n\nPMF - не метрика. Нельзя померить в системе аналитики или по моменту времени как с Aha moment.\n\nPMF — это состояние продукта, когда клиенты им довольны и рекомендуют друзьям, а сам бизнес, в нашем случае — стартап — кратно растет. Разберемся, как понять, что вы достигли этого состояния.\n\nProduct-market fit нельзя также измерить по какому-то единому правилу, однако определенные подходы к измерению этого показателя все же имеются.\n\nМожно через: **опросник Шона Эллиса** (40% = PMF), **NPS**, **показатели дохода** (кратный рост доходов = PMF). Также через анализ **retention** (удержание) — этап, когда у клиента формируется привычка пользоваться товаром или услугой, на которых завязан ваш продукт. Еще через **рост базы постоянных клиентов** — важнейший индикатор того, что ваш продукт достиг PMF. Как же правильно использовать эту метрику? Если ваш продукт ориентирован на рынок b2c, то временной интервал для отслеживания retention будет меньше (от дня до недели), если на рынок b2b — больше (от нескольких недель до нескольких месяцев). **DAU/MAU (соотношение средней дневной аудитории к месячной аудитории).** С помощью этого критерия оценивают вовлеченность целевой аудитории. Показатель рассчитывают в процентах. Компании, у которых отношение DAU/MAU превышает 20%, считаются устойчивыми. Чем выше критерий, тем лучше. \n\n**Опросник product/market fit от Sean Ellis**\n\n«[PMFsurvey.com](https://gopractice.ru/goto/https://pmfsurvey.com/) был создан для того, чтобы дать вам объективную метрику, которая поможет без эмоций принять решение о том, готов ли продукт к масштабированию или нет. Ключевой вопрос в анкете это:\n\nКак вы будете себя чувствовать, если не сможете больше использовать продукт?\n\n* Очень разочарованным\n* Немного разочарованным\n* Все нормально (продукт для меня не очень полезен)\n* Я уже не использую продукт\n\nЕсли более 40% скажут, что они будут очень разочарованы, если у них забрать продукт, то велик шанс, что вы сможете управляемо его масштабировать. Бенчмарк в 40% был выведен на основе анализа подобных исследований для сотен стартапов. Те, у кого доля достигала 40%, в большинстве случаев успешно растили свои продукты. Те, кто были значительно ниже 40%, оказывались в сложной ситуации.»\n\n**Плюсы критерия:**\n\n* Рисует яркую картинку. Хорошо доносит ощущения команды, когда product/market fit есть, и когда его нет.\n\n**Минусы критерия:**\n\n* Смешивает вместе проблему дистрибуции и попадания продукта в потребности рынка. Вы можете создать полезный продукт, но не найти эффективных каналов дистрибуции. Вы также можете залить деньгами слабый продукт и искуственно обеспечить ему стремительный рост на коротком промежутке времени.\n* Бинарный, черно-белый. Из описания складывается впечатление, что продукт находится либо в состоянии, когда он достиг product/market fit, либо же в состоянии, когда не достиг. В реальности такой четкой границы нет.\n* Не помогает понять, что делать, если вы еще не достигли product/market fit.\n\n**Советы по опросу от Superhuman**\n\n* Измерять product/market fit каждой новой версии продукта, отправляя анкету новым пользователям, которые испытали ключевую ценность продукта.\n* Сегментировать пользователей, чтобы понять портрет наиболее заинтересованных (тех, кто будет очень разочарован, если продукт перестанет существовать) в продукте пользователей. Это нужно, чтобы выделить их потребности и понять, что их привлекает в продукте.\n* Работать с фидбеком пользователей, которых что-то сдерживает или ограничивает от получения максимум пользы от продукты. При этом важно, чтобы эти пользователи разделяли ценности и потребности целевых заинтересованных пользователей (см. прошлый пункт). Если вы уберете блокеры, которые останавливают их, то увеличите конверсию из новых в лояльных.\n* Не обращать внимания на фидбек пользователей, которые не расстроятся, если ваш продукт перестанет существовать. Также не обращать внимания на фидбек тех, кто будет немного разочарован, но ценят ваш продукт не за то, что является его отличительной особенностью и привлекает целевую лояльную аудиторию. Это не ваша аудитория, и на данном этапе нет смысла на них фокусироваться.\n* Строить роудмап вокруг инвестиций в то, что люди уже любят в вашем продукте, а также того, что ограничивает от получения максимальной пользы клиентов, которые разделяют ключевые ценности и потребности лояльных пользователей.\n\n**Какая метрика может быть опережающим индикатором достижения product/market fit**\n\nПросто опросите ваших пользователей, как они будут себя чувствовать, если не смогут больше пользоваться вашим продуктом, а затем измерьте процент тех, кто ответил, что будет крайне разочарован.\n\nПосле проведения [подобного опроса](https://gopractice.ru/goto/https://pmfsurvey.com/) для почти сотни стартапов Sean Ellis обнаружил магическое число — 40%. Компании, которые испытывали сложности с ростом, почти всегда получали в этом опросе менее 40% пользователей, которые будут очень разочарованы в случае закрытия продукта.\n\nОпрос стоит проводить на тех, кто пользовался продуктом по крайней мере дважды за последние две недели. Вы будете получать достаточно корректные результаты уже на базе 40 респондентов, что достижимо почти для любого продукта.\n\nМы отправили выбранным пользователям письма со ссылкой на опрос, сделанный в Typeform. В нем были следующие четыре вопроса:\n\n1) Как бы вы себя чувствовали, если бы больше не смогли пользоваться (наш продукт)?\n\na. Были бы очень разочарованы\n\nb. Были бы несколько разочарованы\n\nc. Не были бы разочарованы\n\n2) Какие люди, на ваш взгляд, получают больше всего пользы от \\[наш продукт\\]?\n\n3) В чем заключается главная польза от \\[наш продукт\\] для вас?\n\n4) Как мы можем сделать \\[наш продукт\\] лучше для вас?\n\n**Как оптимизировать product/market fit с помощью процесса из четырех шагов**\n\n**Сегментация юзеров, чтобы выделить и глубоко понять тех, кому продукт доставляет наибольшую ценность**\n\nДля начала мы сгруппировали респондентов по ответу на первый вопрос: «Как бы вы себя чувствовали, если бы больше не смогли пользоваться \\[наш продукт\\]?».\n\nЗатем мы присвоили каждому из респондентов «[персону](https://gopractice.ru/goto/https://medium.com/no-flame-no-game/%D1%87%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-jobs-to-be-done-%D0%B8-job-stories-4c57c1dc84cf)» на основе доступной нам информации. Фокусировка на «персонах» пользователей из группы «очень разочарованных» респондентов увеличила значение нашего product/market fit на 10%. Да, мы еще не достигли желаемых 40%, но с минимальными усилиями уже сократили расстояние до цели.\n\nДля большего погружения возьмите группу «очень разочарованных» респондентов и проанализировали их ответы на второй вопрос: «Какие люди, на ваш взгляд, получают больше всего пользы от \\[наш продукт\\]?». Это очень важный вопрос, поскольку довольные пользователи почти всегда описывают самих себя, а не других людей, а в процессе используют такие слова, которые описывают наиболее важные вещи для них самих. Затем детальнее собрать. HXC - [https://review.firstround.com/what-i-learned-from-developing-branding-for-airbnb-dropbox-and-thumbtack](https://review.firstround.com/what-i-learned-from-developing-branding-for-airbnb-dropbox-and-thumbtack) \n\nВ сухом остатке, лучше создать продукт, который очень нужен малому количеству людей, чем продукт, который нужен большому количеству людей, но чуть-чуть. На мой взгляд, использованный нами процесс сужения рынка с помощью механизма по поиску product/market fit как раз позволяет получить продукт, который очень нужен маленькой группе людей.\n\n**Анализируйте обратную связь, чтобы превратить неопределившихся пользователей в фанатов**\n\nЧтобы разобраться в том, как улучшать продукт и увеличивать его ценность, я сфокусировался на следующих вопросах:\n\n* Почему люди любят продукт?\n* Что мешает людям полюбить продукт?\n\nДля того, чтобы понять, почему пользователи любят \\[наш продукт\\], мы еще раз обратились к группе «очень разочарованных» респондентов. На этот раз мы изучили их ответы на третий вопрос: «В чем заключается главная польза от \\[наш продукт\\] для вас?».\n\nФидбек от пользователей, которые не были бы разочарованы в случае закрытия продукта, никак не должен влиять на вашу продуктовую стратегию. Они запрашивают отвлекающие фичи, делятся неподходящими юзкейсами и, наиболее вероятно, будут создавать очень много шума из ничего, прежде чем откажутся от использования вашего продукта и оставят вас с искаженным и запутанным роадмапом. Каким бы удивительным или болезненным вам бы это ни казалось, не реагируйте на их обратную связь — это уведет вас в сторону от пути к product/market fit.\n\nИз анализа третьего вопроса мы узнаем, что \\[x-фича\\] в \\[наш продукт\\] — главный источник добавочной ценности, поэтому использовали этот фактор как фильтр для группы «несколько разочарованных» респондентов. После того, как мы разделили группу «несколько разочарованных» респондентов на два новых сегмента через фильтр их отношения к фактору \\[x-фича\\], мы решили следующим образом отреагировать на их обратную связь. Те несколько разочарованные, что не сочли \\[x-фича\\] основным источником пользы - убрали. Те несколько разочарованные, что сочли \\[x-фича\\] основным источником пользы - оставили и спросили: Как мы можем сделать \\[наш продукт\\] лучше для вас?\n\nПосле анализа мы поняли, что главная причина, которая удерживала этих пользователей от того, чтобы полюбить наш продукт, была очень простой: отсутствие \\[y-фича\\].\n\n**Создавайте ваш роадмап так, чтобы усилить то, что люди уже любят в вашем продукте, и устранить то, что мешает другим испытать эту ценность**\n\nВ какой-то момент я понял: если вы будете только усилять то, что пользователи любят, то показатели product/market fit не вырастут. Если же вы будете только устранять то, что мешает другим пользователям полюбить ваш продукт, то конкуренты, скорее всего, обгонят вас. Этот инсайт лег в основу нашего процесса планирования и помог с проектированием роадмапа.\n\nЧтобы улучшить ваши показатели product/market fit, тратьте половину вашего времени на усиление того, что ваши пользователи уже любят, а другую половину — на то, что удерживает их от того, чтобы полюбить ваш продукт.\n\n**Повторяйте этот процесс и сделайте метрику силы product/market fit ключевой** \n\nС течением времени мы постоянно повторяли опрос среди наших новых когорт пользователей, чтобы отслеживать изменения в показателях силы product/market fit. Отмечу, что мы тщательно следили за тем, чтобы не опрашивать одного пользователя больше одного раза. \n\nРанние последователи готовы многое вам простить и наслаждаться основными преимуществами вашего продукта, несмотря на его неотвратимые недостатки. Но как только вы продвинетесь за пределы группы ранних последователей, пользователи станут куда более настойчивыми и требовательными к соответствию вашего продукта (и его фичей) тем альтернативам, которыми они пользуются в моменте. В результате ваш показатель product/market fit может значительно снизиться.\n\n**Максимизируйте влияние вашей работы на опыт пользователей продукта**\n\nВот что стало нашей методологией по улучшению силы product/market fit:\n\n* Опросы пользователей;\n* Выделение групп «разочарованных»;\n* Изучение того, что они любят в нашем продукте;\n* Изучение того, что мешает полюбить наш продукт «немного разочарованным»;\n* Разделение роадмапа пополам в соответствии с этими факторами.\n\n**Что важно помнить?**\n\nВажно понимать, что product/market fit – это лишь промежуточная точка на пути к построению бизнеса вокруг продукта. После достижения product/market fit вам предстоит искать каналы дистрибуции, чтобы дотянуться до сегмента рынка, где продукт генерирует ценность. А потом работать над сведением экономики в рамках найденных каналов.\n\nЧтобы понять что продукт кому-то нужен до запуска - cusdev. После cusdev можно оценить по заинтересованности покупного/рекламного трафика в версии MVP. До MVP можно делайть серию RAT (Riskiest Assumption Test).", + "lastmodified": "2022-04-23T12:45:42.660599599+03:00", + "tags": null + }, + "/Product/Terms/Soft-launch": { + "title": "Soft launch", + "content": "* Soft Launch – это пробный запуск на ограниченную аудиторию с целью протестировать продукт прежде, чем публично выходить на массового потребителя.\n* Мобильные приложения обычно сначала тестируют на одном небольшом рынке. Чаще всего выбирают Канаду или Австралию, так как они очень похожи на США. А разработчики обычно оптимизируют свои приложения именно под США, поскольку это один из главных рынков в мире.\n\nSoft Launch преследует несколько целей:\n\n* Собрать фидбек на новый продукт от реальных юзеров.\n* Получить данные о ключевых метриках продукта, чтобы понять, насколько он готов к релизу на весь мир (если у продукта будут плохие метрики, лучше сначала их улучшить, а потом уже запускаться повсюду).\n* Протестировать продукт в боевых условиях, найти все проблемы/баги и поправить их до того, как продукт станет доступен широкой аудитории.\n* Проверить и обкатать будущие маркетинговые каналы.", + "lastmodified": "2022-04-23T12:45:42.663336764+03:00", + "tags": null + } +} \ No newline at end of file diff --git a/assets/indices/linkIndex.json b/assets/indices/linkIndex.json new file mode 100644 index 000000000..32469ae3c --- /dev/null +++ b/assets/indices/linkIndex.json @@ -0,0 +1,2205 @@ +{ + "index": { + "links": { + "/": [ + { + "source": "/", + "target": "/Product/Product", + "text": "Product" + }, + { + "source": "/", + "target": "/Design/Design", + "text": "Design" + } + ], + "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7": [ + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Persona", + "text": "Persona" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Informational-Architecture", + "text": "Informational Architecture" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/User-Story", + "text": "User Story" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Use-case", + "text": "Use case" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/User-Story-Mapping", + "text": "User Story Mapping" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/JTBD", + "text": "JTBD" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/RICE-%D0%B8-ICE", + "text": "RICE и ICE" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/KANO", + "text": "KANO" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Severity-analysis", + "text": "Severity analysis" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/CJM", + "text": "CJM" + } + ], + "/Design/Analysis/Persona": [ + { + "source": "/Design/Analysis/Persona", + "target": "/User-Story", + "text": "User Story" + }, + { + "source": "/Design/Analysis/Persona", + "target": "/User-Story-Mapping", + "text": "User Story Mapping" + } + ], + "/Design/Analysis/Severity-analysis": [ + { + "source": "/Design/Analysis/Severity-analysis", + "target": "/../Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Usability", + "text": "Что такое Usability" + } + ], + "/Design/Analysis/User-Story": [ + { + "source": "/Design/Analysis/User-Story", + "target": "/Use-case", + "text": "Use case" + }, + { + "source": "/Design/Analysis/User-Story", + "target": "/User-Story-Mapping", + "text": "User Story Mapping" + } + ], + "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9": [ + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-uxui-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD", + "text": "Что такое uxui дизайн" + }, + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Usability", + "text": "Что такое Usability" + }, + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "text": "Дизайн-процессы" + }, + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-MVP", + "text": "Что такое MVP" + }, + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9A%D0%B0%D0%BA-%D0%BF%D0%BE%D0%BD%D1%8F%D1%82%D1%8C-%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D1%83", + "text": "Как понять задачу" + } + ], + "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B": [ + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5", + "text": "Дизайн-мышление" + }, + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/Lean", + "text": "Lean" + }, + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/Double-diamond", + "text": "Double diamond" + }, + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%BF%D1%80%D0%B8%D0%BD%D1%82", + "text": "Дизайн-спринт" + } + ], + "/Design/Design": [ + { + "source": "/Design/Design", + "target": "/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "text": "Исследования" + }, + { + "source": "/Design/Design", + "target": "/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "text": "Анализ" + }, + { + "source": "/Design/Design", + "target": "/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "text": "Дизайн" + }, + { + "source": "/Design/Design", + "target": "/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "text": "Тестирование" + } + ], + "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5": [ + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Userflow", + "text": "Userflow" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/%D0%9C%D0%B0%D0%BA%D0%B5%D1%82", + "text": "Макет" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF", + "text": "Прототип" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/UI-Kit", + "text": "UI Kit" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0", + "text": "Дизайн-система" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Accessibility", + "text": "Accessibility" + } + ], + "/Design/Design/Design-Token": [ + { + "source": "/Design/Design/Design-Token", + "target": "/UI-Kit", + "text": "UI Kit" + }, + { + "source": "/Design/Design/Design-Token", + "target": "/../../Development/camelCase", + "text": "camelCase" + }, + { + "source": "/Design/Design/Design-Token", + "target": "/../../Development/kebab-case", + "text": "kebab-case" + }, + { + "source": "/Design/Design/Design-Token", + "target": "/../../Development/PascalCase", + "text": "PascalCase" + } + ], + "/Design/Design/UI-Kit": [ + { + "source": "/Design/Design/UI-Kit", + "target": "/Design-Token", + "text": "дизайн-токены" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/../../Development/camelCase", + "text": "camelCase" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/../../Development/kebab-case", + "text": "kebab-case" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/../../Development/PascalCase", + "text": "PascalCase" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/Accessibility", + "text": "Accessibility" + } + ], + "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F": [ + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Interview", + "text": "Interview" + }, + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Lean-canvas", + "text": "Lean canvas" + }, + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "text": "Опросы" + }, + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Card-sorting", + "text": "Card sorting" + }, + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Competitive-analysis", + "text": "Competitive analysis" + } + ], + "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B": [ + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/NPS", + "text": "NPS" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/CSAT", + "text": "CSAT" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/CES", + "text": "CES" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/SEQ", + "text": "SEQ" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/UMUX", + "text": "UMUX" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/SUS", + "text": "SUS" + } + ], + "/Design/Research/Card-sorting": [ + { + "source": "/Design/Research/Card-sorting", + "target": "/../Analysis/Informational-Architecture", + "text": "Informational Architecture" + } + ], + "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5": [ + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Task-flow-test", + "text": "Task flow test" + }, + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Usability-Test", + "text": "Usability Test" + }, + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Fake-door", + "text": "Fake door" + }, + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Prototyping", + "text": "Prototyping" + } + ], + "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0": [ + { + "source": "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0", + "target": "/camelCase", + "text": "camelCase" + }, + { + "source": "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0", + "target": "/PascalCase", + "text": "PascalCase" + }, + { + "source": "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0", + "target": "/kebab-case", + "text": "kebab-case" + } + ], + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Conversion", + "text": "конверсия" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/North-star-metric", + "text": "North star metric" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Profit", + "text": "Profit" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Gross-profit", + "text": "Gross profit" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Conversion", + "text": "Conversion" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CAC", + "text": "CAC" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/COGS", + "text": "COGS" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/MRR", + "text": "MRR" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/ARPU", + "text": "ARPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Cumulative-ARPU", + "text": "Cumulative ARPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Retention", + "text": "Retention" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Churn-rate", + "text": "Churn rate" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/DAUWAUMAU", + "text": "DAU\u0026WAU\u0026MAU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/ROMI", + "text": "ROMI" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Cart-abandonment-rate", + "text": "Cart abandonment rate" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/AOV", + "text": "AOV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CPI", + "text": "CPI" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CTR", + "text": "CTR" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CPA", + "text": "CPA" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CPC", + "text": "CPC" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/RPR", + "text": "RPR" + } + ], + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPPU": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPPU", + "target": "/ARPU", + "text": "ARPU" + } + ], + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU", + "target": "/CPA", + "text": "CPA" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU", + "target": "/ARPPU", + "text": "ARPPU" + } + ], + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Cumulative-ARPU": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Cumulative-ARPU", + "target": "/CPI", + "text": "CPI" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Cumulative-ARPU", + "target": "/ARPU", + "text": "ARPU" + } + ], + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/Lifetime", + "text": "Lifetime" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/AOV", + "text": "AOV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/RPR", + "text": "RPR" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/Lifetime", + "text": "Lifetime" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/CAC", + "text": "CAC" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/Churn-rate", + "text": "Churn rate" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/ARPPU", + "text": "ARPPU" + } + ], + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit", + "target": "/CPA", + "text": "CPA" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit", + "target": "/LTV", + "text": "LTV" + } + ], + "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ROMI": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ROMI", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ROMI", + "target": "/CAC", + "text": "CAC" + } + ], + "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8": [ + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/SaaS", + "text": "SaaS" + }, + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Shop", + "text": "Shop" + }, + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Social-media", + "text": "Social media" + }, + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Marketplace", + "text": "Marketplace" + }, + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Dropshipping", + "text": "Dropshipping" + } + ], + "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8": [ + { + "source": "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "target": "/AARRR", + "text": "AARRR" + }, + { + "source": "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "target": "/HEART", + "text": "HEART" + }, + { + "source": "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "target": "/%D0%9F%D0%B8%D1%80%D0%B0%D0%BC%D0%B8%D0%B4%D0%B0-%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA", + "text": "Пирамида метрик" + } + ], + "/Product/Product": [ + { + "source": "/Product/Product", + "target": "/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "text": "Фреймворки" + }, + { + "source": "/Product/Product", + "target": "/Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0", + "text": "Юнит-экономика" + }, + { + "source": "/Product/Product", + "target": "/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "text": "Бизнес-модели" + } + ], + "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5-%D0%B0%D1%80%D0%B8%D1%84%D0%BC%D0%B5%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5", + "text": "Среднее арифметическое" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9C%D0%B5%D0%B4%D0%B8%D0%B0%D0%BD%D0%BD%D0%B0", + "text": "Медианна" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9F%D1%80%D0%B8%D1%87%D0%B8%D0%BD%D0%BD%D0%BE-%D1%81%D0%BB%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F-%D1%81%D0%B2%D1%8F%D0%B7%D1%8C", + "text": "Причинно-следственная связь" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9A%D0%BE%D1%80%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D1%8F", + "text": "Корреляция" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/Soft-launch", + "text": "Soft launch" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9A%D0%BE%D0%B3%D0%BE%D1%80%D1%82%D0%BD%D1%8B%D0%B9-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "text": "Когортный анализ" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/PMF", + "text": "Product market fit" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%92%D0%BE%D1%80%D0%BE%D0%BD%D0%BA%D0%B0", + "text": "Воронка" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0", + "text": "Юнит-экономика" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0", + "text": "Продуктовая гипотеза" + } + ], + "/Product/Terms/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0": [ + { + "source": "/Product/Terms/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0", + "target": "/../../Design/Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-MVP", + "text": "mvp" + } + ], + "/Product/Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0": [ + { + "source": "/Product/Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0", + "target": "/../%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "text": "метрики" + } + ] + }, + "backlinks": { + "/%D0%92%D0%BE%D1%80%D0%BE%D0%BD%D0%BA%D0%B0": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%92%D0%BE%D1%80%D0%BE%D0%BD%D0%BA%D0%B0", + "text": "Воронка" + } + ], + "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5": [ + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5", + "text": "Дизайн-мышление" + } + ], + "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B": [ + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "text": "Дизайн-процессы" + } + ], + "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0": [ + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0", + "text": "Дизайн-система" + } + ], + "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%BF%D1%80%D0%B8%D0%BD%D1%82": [ + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%BF%D1%80%D0%B8%D0%BD%D1%82", + "text": "Дизайн-спринт" + } + ], + "/%D0%9A%D0%B0%D0%BA-%D0%BF%D0%BE%D0%BD%D1%8F%D1%82%D1%8C-%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D1%83": [ + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9A%D0%B0%D0%BA-%D0%BF%D0%BE%D0%BD%D1%8F%D1%82%D1%8C-%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D1%83", + "text": "Как понять задачу" + } + ], + "/%D0%9A%D0%BE%D0%B3%D0%BE%D1%80%D1%82%D0%BD%D1%8B%D0%B9-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9A%D0%BE%D0%B3%D0%BE%D1%80%D1%82%D0%BD%D1%8B%D0%B9-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "text": "Когортный анализ" + } + ], + "/%D0%9A%D0%BE%D1%80%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D1%8F": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9A%D0%BE%D1%80%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D1%8F", + "text": "Корреляция" + } + ], + "/%D0%9C%D0%B0%D0%BA%D0%B5%D1%82": [ + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/%D0%9C%D0%B0%D0%BA%D0%B5%D1%82", + "text": "Макет" + } + ], + "/%D0%9C%D0%B5%D0%B4%D0%B8%D0%B0%D0%BD%D0%BD%D0%B0": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9C%D0%B5%D0%B4%D0%B8%D0%B0%D0%BD%D0%BD%D0%B0", + "text": "Медианна" + } + ], + "/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B": [ + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "text": "Опросы" + } + ], + "/%D0%9F%D0%B8%D1%80%D0%B0%D0%BC%D0%B8%D0%B4%D0%B0-%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA": [ + { + "source": "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "target": "/%D0%9F%D0%B8%D1%80%D0%B0%D0%BC%D0%B8%D0%B4%D0%B0-%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA", + "text": "Пирамида метрик" + } + ], + "/%D0%9F%D1%80%D0%B8%D1%87%D0%B8%D0%BD%D0%BD%D0%BE-%D1%81%D0%BB%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F-%D1%81%D0%B2%D1%8F%D0%B7%D1%8C": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9F%D1%80%D0%B8%D1%87%D0%B8%D0%BD%D0%BD%D0%BE-%D1%81%D0%BB%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F-%D1%81%D0%B2%D1%8F%D0%B7%D1%8C", + "text": "Причинно-следственная связь" + } + ], + "/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0", + "text": "Продуктовая гипотеза" + } + ], + "/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF": [ + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF", + "text": "Прототип" + } + ], + "/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5-%D0%B0%D1%80%D0%B8%D1%84%D0%BC%D0%B5%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5-%D0%B0%D1%80%D0%B8%D1%84%D0%BC%D0%B5%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5", + "text": "Среднее арифметическое" + } + ], + "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-MVP": [ + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-MVP", + "text": "Что такое MVP" + } + ], + "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Usability": [ + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Usability", + "text": "Что такое Usability" + } + ], + "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-uxui-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD": [ + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-uxui-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD", + "text": "Что такое uxui дизайн" + } + ], + "/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0", + "text": "Юнит-экономика" + } + ], + "/../%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8": [ + { + "source": "/Product/Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0", + "target": "/../%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "text": "метрики" + } + ], + "/../../Design/Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-MVP": [ + { + "source": "/Product/Terms/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0", + "target": "/../../Design/Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-MVP", + "text": "mvp" + } + ], + "/../../Development/PascalCase": [ + { + "source": "/Design/Design/Design-Token", + "target": "/../../Development/PascalCase", + "text": "PascalCase" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/../../Development/PascalCase", + "text": "PascalCase" + } + ], + "/../../Development/camelCase": [ + { + "source": "/Design/Design/Design-Token", + "target": "/../../Development/camelCase", + "text": "camelCase" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/../../Development/camelCase", + "text": "camelCase" + } + ], + "/../../Development/kebab-case": [ + { + "source": "/Design/Design/Design-Token", + "target": "/../../Development/kebab-case", + "text": "kebab-case" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/../../Development/kebab-case", + "text": "kebab-case" + } + ], + "/../Analysis/Informational-Architecture": [ + { + "source": "/Design/Research/Card-sorting", + "target": "/../Analysis/Informational-Architecture", + "text": "Informational Architecture" + } + ], + "/../Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Usability": [ + { + "source": "/Design/Analysis/Severity-analysis", + "target": "/../Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Usability", + "text": "Что такое Usability" + } + ], + "/AARRR": [ + { + "source": "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "target": "/AARRR", + "text": "AARRR" + } + ], + "/AOV": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/AOV", + "text": "AOV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/AOV", + "text": "AOV" + } + ], + "/ARPPU": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/ARPPU", + "text": "ARPPU" + } + ], + "/ARPU": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPPU", + "target": "/ARPU", + "text": "ARPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Cumulative-ARPU", + "target": "/ARPU", + "text": "ARPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/ARPU", + "text": "ARPU" + } + ], + "/Accessibility": [ + { + "source": "/Design/Design/UI-Kit", + "target": "/Accessibility", + "text": "Accessibility" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Accessibility", + "text": "Accessibility" + } + ], + "/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7": [ + { + "source": "/Design/Design", + "target": "/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "text": "Анализ" + } + ], + "/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8": [ + { + "source": "/Product/Product", + "target": "/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "text": "Бизнес-модели" + } + ], + "/CAC": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/CAC", + "text": "CAC" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ROMI", + "target": "/CAC", + "text": "CAC" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CAC", + "text": "CAC" + } + ], + "/CES": [ + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/CES", + "text": "CES" + } + ], + "/CJM": [ + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/CJM", + "text": "CJM" + } + ], + "/COGS": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/COGS", + "text": "COGS" + } + ], + "/CPA": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU", + "target": "/CPA", + "text": "CPA" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit", + "target": "/CPA", + "text": "CPA" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CPA", + "text": "CPA" + } + ], + "/CPC": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CPC", + "text": "CPC" + } + ], + "/CPI": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Cumulative-ARPU", + "target": "/CPI", + "text": "CPI" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CPI", + "text": "CPI" + } + ], + "/CSAT": [ + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/CSAT", + "text": "CSAT" + } + ], + "/CTR": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CTR", + "text": "CTR" + } + ], + "/Card-sorting": [ + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Card-sorting", + "text": "Card sorting" + } + ], + "/Cart-abandonment-rate": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Cart-abandonment-rate", + "text": "Cart abandonment rate" + } + ], + "/Churn-rate": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/Churn-rate", + "text": "Churn rate" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Churn-rate", + "text": "Churn rate" + } + ], + "/Competitive-analysis": [ + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Competitive-analysis", + "text": "Competitive analysis" + } + ], + "/Conversion": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Conversion", + "text": "конверсия" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Conversion", + "text": "Conversion" + } + ], + "/Cumulative-ARPU": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Cumulative-ARPU", + "text": "Cumulative ARPU" + } + ], + "/DAUWAUMAU": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/DAUWAUMAU", + "text": "DAU\u0026WAU\u0026MAU" + } + ], + "/Design-Token": [ + { + "source": "/Design/Design/UI-Kit", + "target": "/Design-Token", + "text": "дизайн-токены" + } + ], + "/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5": [ + { + "source": "/Design/Design", + "target": "/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "text": "Дизайн" + } + ], + "/Design/Design": [ + { + "source": "/", + "target": "/Design/Design", + "text": "Design" + } + ], + "/Double-diamond": [ + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/Double-diamond", + "text": "Double diamond" + } + ], + "/Dropshipping": [ + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Dropshipping", + "text": "Dropshipping" + } + ], + "/Fake-door": [ + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Fake-door", + "text": "Fake door" + } + ], + "/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8": [ + { + "source": "/Product/Product", + "target": "/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "text": "Фреймворки" + } + ], + "/Gross-profit": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Gross-profit", + "text": "Gross profit" + } + ], + "/HEART": [ + { + "source": "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "target": "/HEART", + "text": "HEART" + } + ], + "/Informational-Architecture": [ + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Informational-Architecture", + "text": "Informational Architecture" + } + ], + "/Interview": [ + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Interview", + "text": "Interview" + } + ], + "/JTBD": [ + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/JTBD", + "text": "JTBD" + } + ], + "/KANO": [ + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/KANO", + "text": "KANO" + } + ], + "/LTV": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ROMI", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/LTV", + "text": "LTV" + } + ], + "/Lean": [ + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/Lean", + "text": "Lean" + } + ], + "/Lean-canvas": [ + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Lean-canvas", + "text": "Lean canvas" + } + ], + "/Lifetime": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/Lifetime", + "text": "Lifetime" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/Lifetime", + "text": "Lifetime" + } + ], + "/MRR": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/MRR", + "text": "MRR" + } + ], + "/Marketplace": [ + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Marketplace", + "text": "Marketplace" + } + ], + "/NPS": [ + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/NPS", + "text": "NPS" + } + ], + "/North-star-metric": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/North-star-metric", + "text": "North star metric" + } + ], + "/PMF": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/PMF", + "text": "Product market fit" + } + ], + "/PascalCase": [ + { + "source": "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0", + "target": "/PascalCase", + "text": "PascalCase" + } + ], + "/Persona": [ + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Persona", + "text": "Persona" + } + ], + "/Product/Product": [ + { + "source": "/", + "target": "/Product/Product", + "text": "Product" + } + ], + "/Profit": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Profit", + "text": "Profit" + } + ], + "/Prototyping": [ + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Prototyping", + "text": "Prototyping" + } + ], + "/RICE-%D0%B8-ICE": [ + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/RICE-%D0%B8-ICE", + "text": "RICE и ICE" + } + ], + "/ROMI": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/ROMI", + "text": "ROMI" + } + ], + "/RPR": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/RPR", + "text": "RPR" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/RPR", + "text": "RPR" + } + ], + "/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F": [ + { + "source": "/Design/Design", + "target": "/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "text": "Исследования" + } + ], + "/Retention": [ + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Retention", + "text": "Retention" + } + ], + "/SEQ": [ + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/SEQ", + "text": "SEQ" + } + ], + "/SUS": [ + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/SUS", + "text": "SUS" + } + ], + "/SaaS": [ + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/SaaS", + "text": "SaaS" + } + ], + "/Severity-analysis": [ + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Severity-analysis", + "text": "Severity analysis" + } + ], + "/Shop": [ + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Shop", + "text": "Shop" + } + ], + "/Social-media": [ + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Social-media", + "text": "Social media" + } + ], + "/Soft-launch": [ + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/Soft-launch", + "text": "Soft launch" + } + ], + "/Task-flow-test": [ + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Task-flow-test", + "text": "Task flow test" + } + ], + "/Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0": [ + { + "source": "/Product/Product", + "target": "/Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0", + "text": "Юнит-экономика" + } + ], + "/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5": [ + { + "source": "/Design/Design", + "target": "/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "text": "Тестирование" + } + ], + "/UI-Kit": [ + { + "source": "/Design/Design/Design-Token", + "target": "/UI-Kit", + "text": "UI Kit" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/UI-Kit", + "text": "UI Kit" + } + ], + "/UMUX": [ + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/UMUX", + "text": "UMUX" + } + ], + "/Usability-Test": [ + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Usability-Test", + "text": "Usability Test" + } + ], + "/Use-case": [ + { + "source": "/Design/Analysis/User-Story", + "target": "/Use-case", + "text": "Use case" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Use-case", + "text": "Use case" + } + ], + "/User-Story": [ + { + "source": "/Design/Analysis/Persona", + "target": "/User-Story", + "text": "User Story" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/User-Story", + "text": "User Story" + } + ], + "/User-Story-Mapping": [ + { + "source": "/Design/Analysis/Persona", + "target": "/User-Story-Mapping", + "text": "User Story Mapping" + }, + { + "source": "/Design/Analysis/User-Story", + "target": "/User-Story-Mapping", + "text": "User Story Mapping" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/User-Story-Mapping", + "text": "User Story Mapping" + } + ], + "/Userflow": [ + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Userflow", + "text": "Userflow" + } + ], + "/camelCase": [ + { + "source": "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0", + "target": "/camelCase", + "text": "camelCase" + } + ], + "/kebab-case": [ + { + "source": "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0", + "target": "/kebab-case", + "text": "kebab-case" + } + ] + } + }, + "links": [ + { + "source": "/Design/Analysis/Persona", + "target": "/User-Story", + "text": "User Story" + }, + { + "source": "/Design/Analysis/Persona", + "target": "/User-Story-Mapping", + "text": "User Story Mapping" + }, + { + "source": "/Design/Analysis/Severity-analysis", + "target": "/../Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Usability", + "text": "Что такое Usability" + }, + { + "source": "/Design/Analysis/User-Story", + "target": "/Use-case", + "text": "Use case" + }, + { + "source": "/Design/Analysis/User-Story", + "target": "/User-Story-Mapping", + "text": "User Story Mapping" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Persona", + "text": "Persona" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Informational-Architecture", + "text": "Informational Architecture" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/User-Story", + "text": "User Story" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Use-case", + "text": "Use case" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/User-Story-Mapping", + "text": "User Story Mapping" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/JTBD", + "text": "JTBD" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/RICE-%D0%B8-ICE", + "text": "RICE и ICE" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/KANO", + "text": "KANO" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/Severity-analysis", + "text": "Severity analysis" + }, + { + "source": "/Design/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "target": "/CJM", + "text": "CJM" + }, + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-uxui-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD", + "text": "Что такое uxui дизайн" + }, + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-Usability", + "text": "Что такое Usability" + }, + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "text": "Дизайн-процессы" + }, + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-MVP", + "text": "Что такое MVP" + }, + { + "source": "/Design/Base/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9A%D0%B0%D0%BA-%D0%BF%D0%BE%D0%BD%D1%8F%D1%82%D1%8C-%D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D1%83", + "text": "Как понять задачу" + }, + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5", + "text": "Дизайн-мышление" + }, + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/Lean", + "text": "Lean" + }, + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/Double-diamond", + "text": "Double diamond" + }, + { + "source": "/Design/Base/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D1%8B", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%BF%D1%80%D0%B8%D0%BD%D1%82", + "text": "Дизайн-спринт" + }, + { + "source": "/Design/Design/Design-Token", + "target": "/UI-Kit", + "text": "UI Kit" + }, + { + "source": "/Design/Design/Design-Token", + "target": "/../../Development/camelCase", + "text": "camelCase" + }, + { + "source": "/Design/Design/Design-Token", + "target": "/../../Development/kebab-case", + "text": "kebab-case" + }, + { + "source": "/Design/Design/Design-Token", + "target": "/../../Development/PascalCase", + "text": "PascalCase" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/Design-Token", + "text": "дизайн-токены" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/../../Development/camelCase", + "text": "camelCase" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/../../Development/kebab-case", + "text": "kebab-case" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/../../Development/PascalCase", + "text": "PascalCase" + }, + { + "source": "/Design/Design/UI-Kit", + "target": "/Accessibility", + "text": "Accessibility" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Userflow", + "text": "Userflow" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/%D0%9C%D0%B0%D0%BA%D0%B5%D1%82", + "text": "Макет" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D1%82%D0%B8%D0%BF", + "text": "Прототип" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/UI-Kit", + "text": "UI Kit" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/%D0%94%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0", + "text": "Дизайн-система" + }, + { + "source": "/Design/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Accessibility", + "text": "Accessibility" + }, + { + "source": "/Design/Design", + "target": "/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "text": "Исследования" + }, + { + "source": "/Design/Design", + "target": "/Analysis/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "text": "Анализ" + }, + { + "source": "/Design/Design", + "target": "/Design/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "text": "Дизайн" + }, + { + "source": "/Design/Design", + "target": "/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "text": "Тестирование" + }, + { + "source": "/Design/Research/Card-sorting", + "target": "/../Analysis/Informational-Architecture", + "text": "Informational Architecture" + }, + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Interview", + "text": "Interview" + }, + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Lean-canvas", + "text": "Lean canvas" + }, + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "text": "Опросы" + }, + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Card-sorting", + "text": "Card sorting" + }, + { + "source": "/Design/Research/%D0%98%D1%81%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F", + "target": "/Competitive-analysis", + "text": "Competitive analysis" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/NPS", + "text": "NPS" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/CSAT", + "text": "CSAT" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/CES", + "text": "CES" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/SEQ", + "text": "SEQ" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/UMUX", + "text": "UMUX" + }, + { + "source": "/Design/Research/%D0%9E%D0%BF%D1%80%D0%BE%D1%81%D1%8B", + "target": "/SUS", + "text": "SUS" + }, + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Task-flow-test", + "text": "Task flow test" + }, + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Usability-Test", + "text": "Usability Test" + }, + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Fake-door", + "text": "Fake door" + }, + { + "source": "/Design/Test/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5", + "target": "/Prototyping", + "text": "Prototyping" + }, + { + "source": "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0", + "target": "/camelCase", + "text": "camelCase" + }, + { + "source": "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0", + "target": "/PascalCase", + "text": "PascalCase" + }, + { + "source": "/Development/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0", + "target": "/kebab-case", + "text": "kebab-case" + }, + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/SaaS", + "text": "SaaS" + }, + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Shop", + "text": "Shop" + }, + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Social-media", + "text": "Social media" + }, + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Marketplace", + "text": "Marketplace" + }, + { + "source": "/Product/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "target": "/Dropshipping", + "text": "Dropshipping" + }, + { + "source": "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "target": "/AARRR", + "text": "AARRR" + }, + { + "source": "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "target": "/HEART", + "text": "HEART" + }, + { + "source": "/Product/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "target": "/%D0%9F%D0%B8%D1%80%D0%B0%D0%BC%D0%B8%D0%B4%D0%B0-%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA", + "text": "Пирамида метрик" + }, + { + "source": "/Product/Product", + "target": "/Frameworks/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA%D0%B8", + "text": "Фреймворки" + }, + { + "source": "/Product/Product", + "target": "/Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0", + "text": "Юнит-экономика" + }, + { + "source": "/Product/Product", + "target": "/Business-Models/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8", + "text": "Бизнес-модели" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5-%D0%B0%D1%80%D0%B8%D1%84%D0%BC%D0%B5%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5", + "text": "Среднее арифметическое" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9C%D0%B5%D0%B4%D0%B8%D0%B0%D0%BD%D0%BD%D0%B0", + "text": "Медианна" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9F%D1%80%D0%B8%D1%87%D0%B8%D0%BD%D0%BD%D0%BE-%D1%81%D0%BB%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F-%D1%81%D0%B2%D1%8F%D0%B7%D1%8C", + "text": "Причинно-следственная связь" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9A%D0%BE%D1%80%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D1%8F", + "text": "Корреляция" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/Soft-launch", + "text": "Soft launch" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9A%D0%BE%D0%B3%D0%BE%D1%80%D1%82%D0%BD%D1%8B%D0%B9-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7", + "text": "Когортный анализ" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/PMF", + "text": "Product market fit" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%92%D0%BE%D1%80%D0%BE%D0%BD%D0%BA%D0%B0", + "text": "Воронка" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0", + "text": "Юнит-экономика" + }, + { + "source": "/Product/Terms/%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9", + "target": "/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0", + "text": "Продуктовая гипотеза" + }, + { + "source": "/Product/Terms/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2%D0%B0%D1%8F-%D0%B3%D0%B8%D0%BF%D0%BE%D1%82%D0%B5%D0%B7%D0%B0", + "target": "/../../Design/Base/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-MVP", + "text": "mvp" + }, + { + "source": "/Product/Terms/%D0%AE%D0%BD%D0%B8%D1%82-%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%B0", + "target": "/../%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "text": "метрики" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPPU", + "target": "/ARPU", + "text": "ARPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU", + "target": "/CPA", + "text": "CPA" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ARPU", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Cumulative-ARPU", + "target": "/CPI", + "text": "CPI" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Cumulative-ARPU", + "target": "/ARPU", + "text": "ARPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/Lifetime", + "text": "Lifetime" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/AOV", + "text": "AOV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/RPR", + "text": "RPR" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/Lifetime", + "text": "Lifetime" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/CAC", + "text": "CAC" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/Churn-rate", + "text": "Churn rate" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/LTV", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit", + "target": "/CPA", + "text": "CPA" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/Profit", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ROMI", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/ROMI", + "target": "/CAC", + "text": "CAC" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Conversion", + "text": "конверсия" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/North-star-metric", + "text": "North star metric" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Profit", + "text": "Profit" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Gross-profit", + "text": "Gross profit" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Conversion", + "text": "Conversion" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CAC", + "text": "CAC" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/LTV", + "text": "LTV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/COGS", + "text": "COGS" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/MRR", + "text": "MRR" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/ARPU", + "text": "ARPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/ARPPU", + "text": "ARPPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Cumulative-ARPU", + "text": "Cumulative ARPU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Retention", + "text": "Retention" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Churn-rate", + "text": "Churn rate" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/DAUWAUMAU", + "text": "DAU\u0026WAU\u0026MAU" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/ROMI", + "text": "ROMI" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/Cart-abandonment-rate", + "text": "Cart abandonment rate" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/AOV", + "text": "AOV" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CPI", + "text": "CPI" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CTR", + "text": "CTR" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CPA", + "text": "CPA" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/CPC", + "text": "CPC" + }, + { + "source": "/Product/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8", + "target": "/RPR", + "text": "RPR" + }, + { + "source": "/", + "target": "/Product/Product", + "text": "Product" + }, + { + "source": "/", + "target": "/Design/Design", + "text": "Design" + } + ] +} \ No newline at end of file diff --git a/content/.DS_Store b/content/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..541a51a3c4ad64afcc35bf4159f3176ba86349c1 GIT binary patch literal 6148 zcmeHK%}N6?5Kh`^TSVwVL2m)C1>5?A;$>ay3%H^Om3G%Hy13nx{@6n)>|LKmFA5%g z1~0yd7txs{m95pQip;>|OXg>@`8Fgwj4^Ka{4!$&##jy%F_nkr3qe2XgrtmR8j!1J zL|(ts@4nM&P+{bL1wZi&bjP6UANoo z*lzm>NBdHS-l*?-2SKA>E6nZ4sOtt%qpcDGzX2h~he71azAbx^-%+`acH}{7g~h?3 zyiu+cMWwPfEQ-NqrBoEFE9=8yJ~zL#ytP-m2%C|-(oAyLa!O_mj^G+Pi6w<+W#?2j zTgrWVb2sj7%4*eYSlr{!uldLA&k=qy;_YQ3qII5_;h_%c$@wpxb`;9!46LI!#t0H( zfEXYKevtul9OY(y@f~PtVt^Rp@0Kg2Gl|UbB3Cs}&ErYQ} z@PKfg3aC@LDKWTC2fHwFmcdw~PG{T{AKc8$O@+eM?C^Y{!Wp+TQcDaF1LF*&^{{~V z|L*to|9BFOhyh~YUopTlRi|phlFZ#Yu{gYI1!x@<1><6kA1TmLS24umRlESI1ndGk WfR@2nBUnJ_M?ld)4KeVe47>xv+GqFx literal 0 HcmV?d00001 diff --git a/notes/.DS_Store b/notes/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..05d886998b88d62a4feaac3af61073e0bfa4fd9e GIT binary patch literal 10244 zcmeI1L2DC16vy9cjG;y<2p)QIr67e;Y6L+9VO!(HiikOSF-c=nNV=tMtOb#r6%+*V zAQZ*3H~R_n;?aXA3xc0O`~?2r%s4xfo!w0lLCS2|ec7G&W`6UZnN8n>h=Rqza*Ze? zq6$v7r>eL(4ld_2bsSMoF2e?hCz_=>x=BsiqE5=&Kky281-t@Y0k42p;D1m6-`RXr zPDtyoUIDLwS3oPk?}rd4+eq1=wBpr)i%0=rOL!~}d`2E1VnSsjWrxy=P}C{2hd_k} zD#Zw7ILbqIhmDjSN-M)Dkl_@lmIIZc1fq4sg~FYJNLqjO3U~$53UKazhOW^KT0-t_ z=I;-2-=G1l<1eNSrKeweE44;D?yt+L!rnpS`*FSA>cuU@RhrK~{HjcRS~z$e z%YR+Rde`j71@2Cn+UV&T-KSMrvHN-T`)Ik@kC!iWKdd_Xal)D9V{=5zaS|K@+JxdU z^)U){VVj^@v#G*c`Q9eu=U19Br+$-oya=0L=y)8vKg*!qV&YLHYahWp;$d<=eyurE zUWuC7UN%pJ#?V?93bLLKo-5O750mHa8-vHH$J8p@%fV9x#|o6;Rn@`x@+aOg+q6gb z{1nJCeND!1?=)kMf1=(v{x-K-AFG&;O|Xx$miOO+wTyo0a+7bjy7yHkI8dqO7o=ZGDkJf&*CDXPYG{Ip^iO{XTN|)mzf+t z&S?&#Jki8e?r3)c?RKF?Pt5XI-0j#5;T{;AekM<6M)PF&CTvB%4$euC@r-`})(&lB z=C{F(@pH^5nz;z#f(VoS*{o(Sj7oYjew3p>$1n#wSh@I)wAG$}0(PU+tqy2bzi literal 0 HcmV?d00001 diff --git a/notes/page/.DS_Store b/notes/page/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..fed5d99bcd7d376c24c30f7f02cd1f42ec2b2c40 GIT binary patch literal 6148 zcmeHKOHKnZ47H()5p23-14P_ldV)|5C+G!GsRWCTrW^J-3umA==nc3DC*b)5OvJEY zgAlT%C}{ zL-qYkZ9jC~dONJKjppfc|Js}!uA!@E^NnZsFwP{rV*aAefAMVAasHR9QT|0geCDq` zb^avzLxO=|AQ%V+f`OkffSN7RoEk{tx-=s>4W0N@N}73hBF zr6dN7vtu!Y1;Q2zv{3dZ23t7n$>(LqVrb#Sx-#u{ytdke zZN&|t%8tCV@!A__62&nQ@%VW$A{r7=0Tt{GFzgXo7tN$+7Fp!9#}jQ<%hBYnsn?me z8~!5$^6XA&MjIUWls&)O&!6jcQ&sa-Gl#u+y?(#>8hl*lK8s&{)(@@sgafuf9*ol{counter-reset:section;margin-left:0em;padding-left:1.5em}#TableOfContents>ol>li{counter-increment:section}#TableOfContents>ol>li>ol{counter-reset:subsection}#TableOfContents>ol>li>ol>li{counter-increment:subsection}#TableOfContents>ol>li>ol>li::marker{content:counter(section) "." counter(subsection) " "}#TableOfContents>ol>li::marker{content:counter(section) " "}#TableOfContents>ol>li::marker,#TableOfContents>ol>li>ol>li::marker{font-family:Source Sans Pro;font-weight:700}table{width:100%}img{width:100%;border-radius:3px;margin:1em 0}p>img+em{display:block;transform:translateY(-1em)}sup{line-height:0}p,tbody,li{font-family:Source Sans Pro;color:var(--gray);line-height:1.5em}blockquote{margin-left:0em;border-left:3px solid var(--secondary);padding-left:1em;transition:border-color 0.2s ease}blockquote:hover{border-color:var(--tertiary)}table{padding:1.5em}td,th{padding:0.1em 0.5em}.footnotes p{margin:0.5em 0}.pagination{list-style:none;padding-left:0;display:flex;margin-top:2em;gap:1.5em;justify-content:center}.pagination .disabled{opacity:0.2}.pagination>li{text-align:center;display:inline-block}.pagination>li a{background-color:transparent !important}.pagination>li a[href$="#"]{opacity:0.2}.section h3>a{font-weight:700;font-family:Inter;margin:0}.section p{margin-top:0}article>.meta{margin:-1.5em 0 1em 0;opacity:0.7}article>.tags{list-style:none;padding-left:0}article>.tags .meta>h1{margin:0}article>.tags .meta>p{margin:0}article>.tags>li{display:inline-block}article>.tags>li>a{border-radius:8px;border:var(--outlinegray) 1px solid;padding:0.2em 0.5em}article>.tags>li>a::before{content:"#";margin-right:0.3em;color:var(--outlinegray)}article a{font-family:Source Sans Pro;font-weight:600}article a.internal-link{text-decoration:none;background-color:rgba(143,159,169,0.15);padding:0 0.1em;margin:auto -0.1em;border-radius:3px}article a.internal-link.broken{opacity:0.5;background-color:transparent}article p{overflow-wrap:anywhere}.backlinks a{font-weight:600;font-size:0.9rem}sup>a{text-decoration:none;padding:0 0.1em 0 0.2em}a{font-family:Inter, sans-serif;font-size:1em;font-weight:700;text-decoration:none;transition:all 0.2s ease;color:var(--secondary)}a:hover{color:var(--tertiary) !important}pre{font-family:'Fira Code';padding:0.75em;border-radius:3px;overflow-x:scroll}code{font-family:'Fira Code';font-size:0.85em;padding:0.15em 0.3em;border-radius:5px;background:var(--lightgray)}html{scroll-behavior:smooth}html:lang(ar) p,html:lang(ar) h1,html:lang(ar) h2,html:lang(ar) h3,html:lang(ar) article{direction:rtl;text-align:right}body{margin:0;height:100vh;width:100vw;max-width:100%;box-sizing:border-box;background-color:var(--light)}@keyframes fadeIn{0%{opacity:0}100%{opacity:1}}footer{margin-top:4em;text-align:center}footer ul{padding-left:0}hr{width:25%;margin:4em auto;height:2px;border-radius:1px;border-width:0;color:var(--dark);background-color:var(--dark)}.singlePage{padding:4em 30vw}@media all and (max-width: 1200px){.singlePage{padding:25px 5vw}}.page-end{display:flex;flex-direction:row;gap:2em}@media all and (max-width: 780px){.page-end{flex-direction:column}}.page-end>*{flex:1 0 0}.page-end>.backlinks-container>ul{list-style:none;padding-left:0}.page-end>.backlinks-container>ul>li{margin:0.5em 0;padding:0.25em 1em;border:var(--outlinegray) 1px solid;border-radius:5px}.page-end #graph-container{border:var(--outlinegray) 1px solid;border-radius:5px}.centered{margin-top:30vh}article>h1{font-size:2em}header{display:flex;flex-direction:row;align-items:center}header>h1{font-size:2em}@media all and (max-width: 600px){header>nav{display:none}}header>.spacer{flex:1 1 auto}header>svg{cursor:pointer;width:18px;min-width:18px;margin:0 1em}header>svg:hover .search-path{stroke:var(--tertiary)}header>svg .search-path{stroke:var(--gray);stroke-width:2px;transition:stroke 0.5s ease}#search-container{position:fixed;z-index:9999;left:0;top:0;width:100vw;height:100%;overflow:scroll;display:none;backdrop-filter:blur(4px);-webkit-backdrop-filter:blur(4px)}#search-container>div{width:50%;margin-top:15vh;margin-left:auto;margin-right:auto}@media all and (max-width: 1200px){#search-container>div{width:90%}}#search-container>div>*{width:100%;border-radius:4px;background:var(--light);box-shadow:0 14px 50px rgba(27,33,48,0.12),0 10px 30px rgba(27,33,48,0.16);margin-bottom:2em}#search-container>div>input{box-sizing:border-box;padding:0.5em 1em;font-family:Inter, sans-serif;color:var(--dark);font-size:1.1em;border:1px solid var(--outlinegray)}#search-container>div>input:focus{outline:none}#search-container>div>#results-container>.result-card{padding:1em;cursor:pointer;transition:background 0.2s ease;border:1px solid var(--outlinegray);border-bottom:none;width:100%;font-family:inherit;font-size:100%;line-height:1.15;margin:0;overflow:visible;text-transform:none;text-align:left;background:var(--light);outline:none}#search-container>div>#results-container>.result-card:hover,#search-container>div>#results-container>.result-card:focus{background:rgba(180,180,180,0.15)}#search-container>div>#results-container>.result-card:first-of-type{border-top-left-radius:5px;border-top-right-radius:5px}#search-container>div>#results-container>.result-card:last-of-type{border-bottom-left-radius:5px;border-bottom-right-radius:5px;border-bottom:1px solid var(--outlinegray)}#search-container>div>#results-container>.result-card>h3,#search-container>div>#results-container>.result-card>p{margin:0}#search-container>div>#results-container>.result-card .search-highlight{background-color:#afbfc966;padding:0.05em 0.2em;border-radius:3px}.section-ul{list-style:none;padding-left:0}.section-ul>li{border:1px solid var(--outlinegray);border-radius:5px;padding:0 1em;margin-bottom:1em}.section-ul>li h3{opacity:1;font-weight:700;margin-bottom:0em}.section-ul>li .meta{opacity:0.6}@keyframes dropin{0%{display:none;opacity:0;visibility:hidden}1%{display:inline-block;opacity:0;transform:translate(-50%, 40%)}100%{opacity:1;visibility:visible;transform:translate(-50%, 20%)}}.popover{z-index:999;position:absolute;width:20em;display:none;background-color:var(--light);padding:1em;border:1px solid var(--outlinegray);border-radius:5px;transform:translate(-50%, 40%);pointer-events:none;transition:opacity 0.2s ease, transform 0.2s ease;user-select:none;overflow-wrap:anywhere;box-shadow:6px 6px 36px 0px rgba(0,0,0,0.25)}@media all and (max-width: 600px){.popover{display:none}}.popover.visible{opacity:1;visibility:visible;transform:translate(-50%, 20%);display:inline-block;animation:dropin 0.2s ease}.popover>h3{font-size:1rem;margin:0.25em 0}.popover>.meta{margin-top:0.25em;opacity:0.5;font-family:"JetBrains Mono", monospace;font-size:0.8rem}.popover>p{margin:0;font-weight:400;user-select:none}#contact_buttons ul{list-style-type:none}#contact_buttons ul li{display:inline-block}#contact_buttons ul li a{padding:0 1em} diff --git a/resources/_gen/assets/scss/iziodize/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.json b/resources/_gen/assets/scss/iziodize/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.json new file mode 100644 index 000000000..861c019bb --- /dev/null +++ b/resources/_gen/assets/scss/iziodize/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.json @@ -0,0 +1 @@ +{"Target":"styles/base.css","MediaType":"text/css","Data":{}} \ No newline at end of file diff --git a/resources/_gen/assets/scss/iziodize/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.content b/resources/_gen/assets/scss/iziodize/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.content new file mode 100644 index 000000000..ee7bab693 --- /dev/null +++ b/resources/_gen/assets/scss/iziodize/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.content @@ -0,0 +1 @@ +:root{--light: #faf8f8;--dark: #141021;--secondary: #284b63;--tertiary: #84a59d;--visited: #afbfc9;--primary: #f28482;--gray: #4e4e4e;--lightgray: #f0f0f0;--outlinegray: #dadada}[saved-theme="dark"]{--light: #1e1e21 !important;--dark: #fbfffe !important;--secondary: #6b879a !important;--visited: #4a575e !important;--tertiary: #84a59d !important;--primary: #f58382 !important;--gray: #d4d4d4 !important;--lightgray: #292633 !important;--outlinegray: #343434 !important} diff --git a/resources/_gen/assets/scss/iziodize/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.json b/resources/_gen/assets/scss/iziodize/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.json new file mode 100644 index 000000000..962488ca5 --- /dev/null +++ b/resources/_gen/assets/scss/iziodize/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.json @@ -0,0 +1 @@ +{"Target":"styles/custom.css","MediaType":"text/css","Data":{}} \ No newline at end of file diff --git a/resources/_gen/assets/scss/iziodize/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.content b/resources/_gen/assets/scss/iziodize/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.content new file mode 100644 index 000000000..2e2451973 --- /dev/null +++ b/resources/_gen/assets/scss/iziodize/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.content @@ -0,0 +1 @@ +.darkmode{float:right;padding:1em;min-width:30px;position:relative}@media all and (max-width: 450px){.darkmode{padding:1em}}.darkmode>.toggle{display:none;box-sizing:border-box}.darkmode svg{opacity:0;position:absolute;width:20px;height:20px;top:calc(50% - 10px);margin:0 7px;fill:var(--gray);transition:opacity 0.1s ease}.toggle:checked~label>#dayIcon{opacity:0}.toggle:checked~label>#nightIcon{opacity:1}.toggle:not(:checked)~label>#dayIcon{opacity:1}.toggle:not(:checked)~label>#nightIcon{opacity:0} diff --git a/resources/_gen/assets/scss/iziodize/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.json b/resources/_gen/assets/scss/iziodize/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.json new file mode 100644 index 000000000..27506a71f --- /dev/null +++ b/resources/_gen/assets/scss/iziodize/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.json @@ -0,0 +1 @@ +{"Target":"styles/darkmode.css","MediaType":"text/css","Data":{}} \ No newline at end of file diff --git a/resources/_gen/assets/scss/iziodize/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.content b/resources/_gen/assets/scss/iziodize/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.content new file mode 100644 index 000000000..fcbf617db --- /dev/null +++ b/resources/_gen/assets/scss/iziodize/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.content @@ -0,0 +1 @@ +.chroma{color:#f8f8f2;background-color:#282a36;overflow:hidden}.chroma .lntd{vertical-align:top;padding:0;margin:0;border:0}.chroma .lntable{border-spacing:0;padding:0;margin:0;border:0;width:auto;overflow:auto;display:block}.chroma .hl{display:block;width:100%;background-color:#ffffcc}.chroma .lnt{margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f}.chroma .ln{margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f}.chroma .k{color:#ff79c6}.chroma .kc{color:#ff79c6}.chroma .kd{color:#8be9fd;font-style:italic}.chroma .kn{color:#ff79c6}.chroma .kp{color:#ff79c6}.chroma .kr{color:#ff79c6}.chroma .kt{color:#8be9fd}.chroma .na{color:#50fa7b}.chroma .nb{color:#8be9fd;font-style:italic}.chroma .nc{color:#50fa7b}.chroma .nf{color:#50fa7b}.chroma .nl{color:#8be9fd;font-style:italic}.chroma .nt{color:#ff79c6}.chroma .nv{color:#8be9fd;font-style:italic}.chroma .vc{color:#8be9fd;font-style:italic}.chroma .vg{color:#8be9fd;font-style:italic}.chroma .vi{color:#8be9fd;font-style:italic}.chroma .s{color:#f1fa8c}.chroma .sa{color:#f1fa8c}.chroma .sb{color:#f1fa8c}.chroma .sc{color:#f1fa8c}.chroma .dl{color:#f1fa8c}.chroma .sd{color:#f1fa8c}.chroma .s2{color:#f1fa8c}.chroma .se{color:#f1fa8c}.chroma .sh{color:#f1fa8c}.chroma .si{color:#f1fa8c}.chroma .sx{color:#f1fa8c}.chroma .sr{color:#f1fa8c}.chroma .s1{color:#f1fa8c}.chroma .ss{color:#f1fa8c}.chroma .m{color:#bd93f9}.chroma .mb{color:#bd93f9}.chroma .mf{color:#bd93f9}.chroma .mh{color:#bd93f9}.chroma .mi{color:#bd93f9}.chroma .il{color:#bd93f9}.chroma .mo{color:#bd93f9}.chroma .o{color:#ff79c6}.chroma .ow{color:#ff79c6}.chroma .c{color:#6272a4}.chroma .ch{color:#6272a4}.chroma .cm{color:#6272a4}.chroma .c1{color:#6272a4}.chroma .cs{color:#6272a4}.chroma .cp{color:#ff79c6}.chroma .cpf{color:#ff79c6}.chroma .gd{color:#8b080b}.chroma .ge{text-decoration:underline}.chroma .gh{font-weight:bold}.chroma .gi{font-weight:bold}.chroma .go{color:#44475a}.chroma .gu{font-weight:bold}.chroma .gl{text-decoration:underline}.lntd:first-of-type>.chroma{padding-right:0}.chroma code{font-family:'Fira Code' !important;font-size:0.85em;line-height:1em;background:none;padding:0}.chroma{border-radius:3px;margin:0} diff --git a/resources/_gen/assets/scss/iziodize/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.json b/resources/_gen/assets/scss/iziodize/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.json new file mode 100644 index 000000000..51f0c9c9a --- /dev/null +++ b/resources/_gen/assets/scss/iziodize/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.json @@ -0,0 +1 @@ +{"Target":"styles/syntax.css","MediaType":"text/css","Data":{}} \ No newline at end of file diff --git a/resources/_gen/assets/scss/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.content b/resources/_gen/assets/scss/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.content new file mode 100644 index 000000000..102a90978 --- /dev/null +++ b/resources/_gen/assets/scss/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.content @@ -0,0 +1 @@ +:root{--lt-colours-light: var(--light) !important;--lt-colours-lightgray: var(--lightgray) !important;--lt-colours-dark: var(--secondary) !important;--lt-colours-secondary: var(--tertiary) !important;--lt-colours-gray: var(--outlinegray) !important}h1,h2,h3,h4,h5,h6,ol,ul,thead{font-family:Inter;color:var(--dark);font-weight:revert;margin:revert;padding:revert}p,ul,text{font-family:'Source Sans Pro', sans-serif;color:var(--gray);fill:var(--gray);font-weight:revert;margin:revert;padding:revert}.mainTOC{background:var(--lightgray);border-radius:5px;padding:0.75em 1em}.mainTOC details summary{cursor:zoom-in;font-family:Inter;color:var(--dark);font-weight:700}.mainTOC details[open] summary{cursor:zoom-out}#TableOfContents>ol{counter-reset:section;margin-left:0em;padding-left:1.5em}#TableOfContents>ol>li{counter-increment:section}#TableOfContents>ol>li>ol{counter-reset:subsection}#TableOfContents>ol>li>ol>li{counter-increment:subsection}#TableOfContents>ol>li>ol>li::marker{content:counter(section) "." counter(subsection) " "}#TableOfContents>ol>li::marker{content:counter(section) " "}#TableOfContents>ol>li::marker,#TableOfContents>ol>li>ol>li::marker{font-family:Source Sans Pro;font-weight:700}table{width:100%}img{width:100%;border-radius:3px;margin:1em 0}p>img+em{display:block;transform:translateY(-1em)}sup{line-height:0}p,tbody,li{font-family:Source Sans Pro;color:var(--gray);line-height:1.5em}blockquote{margin-left:0em;border-left:3px solid var(--secondary);padding-left:1em;transition:border-color 0.2s ease}blockquote:hover{border-color:var(--tertiary)}table{padding:1.5em}td,th{padding:0.1em 0.5em}.footnotes p{margin:0.5em 0}.pagination{list-style:none;padding-left:0;display:flex;margin-top:2em;gap:1.5em;justify-content:center}.pagination .disabled{opacity:0.2}.pagination>li{text-align:center;display:inline-block}.pagination>li a{background-color:transparent !important}.pagination>li a[href$="#"]{opacity:0.2}.section h3>a{font-weight:700;font-family:Inter;margin:0}.section p{margin-top:0}article>.meta{margin:-1.5em 0 1em 0;opacity:0.7}article>.tags{list-style:none;padding-left:0}article>.tags .meta>h1{margin:0}article>.tags .meta>p{margin:0}article>.tags>li{display:inline-block}article>.tags>li>a{border-radius:8px;border:var(--outlinegray) 1px solid;padding:0.2em 0.5em}article>.tags>li>a::before{content:"#";margin-right:0.3em;color:var(--outlinegray)}article a{font-family:Source Sans Pro;font-weight:600}article a.internal-link{text-decoration:none;background-color:rgba(143,159,169,0.15);padding:0 0.1em;margin:auto -0.1em;border-radius:3px}article a.internal-link.broken{opacity:0.5;background-color:transparent}article p{overflow-wrap:anywhere}.backlinks a{font-weight:600;font-size:0.9rem}sup>a{text-decoration:none;padding:0 0.1em 0 0.2em}a{font-family:Inter, sans-serif;font-size:1em;font-weight:700;text-decoration:none;transition:all 0.2s ease;color:var(--secondary)}a:hover{color:var(--tertiary) !important}pre{font-family:'Fira Code';padding:0.75em;border-radius:3px;overflow-x:scroll}code{font-family:'Fira Code';font-size:0.85em;padding:0.15em 0.3em;border-radius:5px;background:var(--lightgray)}html{scroll-behavior:smooth}html:lang(ar) p,html:lang(ar) h1,html:lang(ar) h2,html:lang(ar) h3,html:lang(ar) article{direction:rtl;text-align:right}body{margin:0;height:100vh;width:100vw;max-width:100%;box-sizing:border-box;background-color:var(--light)}@keyframes fadeIn{0%{opacity:0}100%{opacity:1}}footer{margin-top:4em;text-align:center}footer ul{padding-left:0}hr{width:25%;margin:4em auto;height:2px;border-radius:1px;border-width:0;color:var(--dark);background-color:var(--dark)}.singlePage{padding:4em 30vw}@media all and (max-width: 1200px){.singlePage{padding:25px 5vw}}.page-end{display:flex;flex-direction:row;gap:2em}@media all and (max-width: 780px){.page-end{flex-direction:column}}.page-end>*{flex:1 0 0}.page-end>.backlinks-container>ul{list-style:none;padding-left:0}.page-end>.backlinks-container>ul>li{margin:0.5em 0;padding:0.25em 1em;border:var(--outlinegray) 1px solid;border-radius:5px}.page-end #graph-container{border:var(--outlinegray) 1px solid;border-radius:5px}.centered{margin-top:30vh}article>h1{font-size:2em}header{display:flex;flex-direction:row;align-items:center}header>h1{font-size:2em}@media all and (max-width: 600px){header>nav{display:none}}header>.spacer{flex:1 1 auto}header>svg{cursor:pointer;width:18px;min-width:18px;margin:0 1em}header>svg:hover .search-path{stroke:var(--tertiary)}header>svg .search-path{stroke:var(--gray);stroke-width:2px;transition:stroke 0.5s ease}#search-container{position:fixed;z-index:9999;left:0;top:0;width:100vw;height:100%;overflow:scroll;display:none;backdrop-filter:blur(4px);-webkit-backdrop-filter:blur(4px)}#search-container>div{width:50%;margin-top:15vh;margin-left:auto;margin-right:auto}@media all and (max-width: 1200px){#search-container>div{width:90%}}#search-container>div>*{width:100%;border-radius:4px;background:var(--light);box-shadow:0 14px 50px rgba(27,33,48,0.12),0 10px 30px rgba(27,33,48,0.16);margin-bottom:2em}#search-container>div>input{box-sizing:border-box;padding:0.5em 1em;font-family:Inter, sans-serif;color:var(--dark);font-size:1.1em;border:1px solid var(--outlinegray)}#search-container>div>input:focus{outline:none}#search-container>div>#results-container>.result-card{padding:1em;cursor:pointer;transition:background 0.2s ease;border:1px solid var(--outlinegray);border-bottom:none;width:100%;font-family:inherit;font-size:100%;line-height:1.15;margin:0;overflow:visible;text-transform:none;text-align:left;background:var(--light);outline:none}#search-container>div>#results-container>.result-card:hover,#search-container>div>#results-container>.result-card:focus{background:rgba(180,180,180,0.15)}#search-container>div>#results-container>.result-card:first-of-type{border-top-left-radius:5px;border-top-right-radius:5px}#search-container>div>#results-container>.result-card:last-of-type{border-bottom-left-radius:5px;border-bottom-right-radius:5px;border-bottom:1px solid var(--outlinegray)}#search-container>div>#results-container>.result-card>h3,#search-container>div>#results-container>.result-card>p{margin:0}#search-container>div>#results-container>.result-card .search-highlight{background-color:#afbfc966;padding:0.05em 0.2em;border-radius:3px}.section-ul{list-style:none;padding-left:0}.section-ul>li{border:1px solid var(--outlinegray);border-radius:5px;padding:0 1em;margin-bottom:1em}.section-ul>li h3{opacity:1;font-weight:700;margin-bottom:0em}.section-ul>li .meta{opacity:0.6}@keyframes dropin{0%{display:none;opacity:0;visibility:hidden}1%{display:inline-block;opacity:0;transform:translate(-50%, 40%)}100%{opacity:1;visibility:visible;transform:translate(-50%, 20%)}}.popover{z-index:999;position:absolute;width:20em;display:none;background-color:var(--light);padding:1em;border:1px solid var(--outlinegray);border-radius:5px;transform:translate(-50%, 40%);pointer-events:none;transition:opacity 0.2s ease, transform 0.2s ease;user-select:none;overflow-wrap:anywhere;box-shadow:6px 6px 36px 0px rgba(0,0,0,0.25)}@media all and (max-width: 600px){.popover{display:none}}.popover.visible{opacity:1;visibility:visible;transform:translate(-50%, 20%);display:inline-block;animation:dropin 0.2s ease}.popover>h3{font-size:1rem;margin:0.25em 0}.popover>.meta{margin-top:0.25em;opacity:0.5;font-family:"JetBrains Mono", monospace;font-size:0.8rem}.popover>p{margin:0;font-weight:400;user-select:none}#contact_buttons ul{list-style-type:none}#contact_buttons ul li{display:inline-block}#contact_buttons ul li a{padding:0 1em} diff --git a/resources/_gen/assets/scss/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.json b/resources/_gen/assets/scss/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.json new file mode 100644 index 000000000..861c019bb --- /dev/null +++ b/resources/_gen/assets/scss/styles/base.scss_c25f88f67e8e33f20619c76cbf49f33c.json @@ -0,0 +1 @@ +{"Target":"styles/base.css","MediaType":"text/css","Data":{}} \ No newline at end of file diff --git a/resources/_gen/assets/scss/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.content b/resources/_gen/assets/scss/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.content new file mode 100644 index 000000000..ee7bab693 --- /dev/null +++ b/resources/_gen/assets/scss/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.content @@ -0,0 +1 @@ +:root{--light: #faf8f8;--dark: #141021;--secondary: #284b63;--tertiary: #84a59d;--visited: #afbfc9;--primary: #f28482;--gray: #4e4e4e;--lightgray: #f0f0f0;--outlinegray: #dadada}[saved-theme="dark"]{--light: #1e1e21 !important;--dark: #fbfffe !important;--secondary: #6b879a !important;--visited: #4a575e !important;--tertiary: #84a59d !important;--primary: #f58382 !important;--gray: #d4d4d4 !important;--lightgray: #292633 !important;--outlinegray: #343434 !important} diff --git a/resources/_gen/assets/scss/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.json b/resources/_gen/assets/scss/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.json new file mode 100644 index 000000000..962488ca5 --- /dev/null +++ b/resources/_gen/assets/scss/styles/custom.scss_c25f88f67e8e33f20619c76cbf49f33c.json @@ -0,0 +1 @@ +{"Target":"styles/custom.css","MediaType":"text/css","Data":{}} \ No newline at end of file diff --git a/resources/_gen/assets/scss/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.content b/resources/_gen/assets/scss/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.content new file mode 100644 index 000000000..2e2451973 --- /dev/null +++ b/resources/_gen/assets/scss/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.content @@ -0,0 +1 @@ +.darkmode{float:right;padding:1em;min-width:30px;position:relative}@media all and (max-width: 450px){.darkmode{padding:1em}}.darkmode>.toggle{display:none;box-sizing:border-box}.darkmode svg{opacity:0;position:absolute;width:20px;height:20px;top:calc(50% - 10px);margin:0 7px;fill:var(--gray);transition:opacity 0.1s ease}.toggle:checked~label>#dayIcon{opacity:0}.toggle:checked~label>#nightIcon{opacity:1}.toggle:not(:checked)~label>#dayIcon{opacity:1}.toggle:not(:checked)~label>#nightIcon{opacity:0} diff --git a/resources/_gen/assets/scss/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.json b/resources/_gen/assets/scss/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.json new file mode 100644 index 000000000..27506a71f --- /dev/null +++ b/resources/_gen/assets/scss/styles/darkmode.scss_c25f88f67e8e33f20619c76cbf49f33c.json @@ -0,0 +1 @@ +{"Target":"styles/darkmode.css","MediaType":"text/css","Data":{}} \ No newline at end of file diff --git a/resources/_gen/assets/scss/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.content b/resources/_gen/assets/scss/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.content new file mode 100644 index 000000000..fcbf617db --- /dev/null +++ b/resources/_gen/assets/scss/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.content @@ -0,0 +1 @@ +.chroma{color:#f8f8f2;background-color:#282a36;overflow:hidden}.chroma .lntd{vertical-align:top;padding:0;margin:0;border:0}.chroma .lntable{border-spacing:0;padding:0;margin:0;border:0;width:auto;overflow:auto;display:block}.chroma .hl{display:block;width:100%;background-color:#ffffcc}.chroma .lnt{margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f}.chroma .ln{margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f}.chroma .k{color:#ff79c6}.chroma .kc{color:#ff79c6}.chroma .kd{color:#8be9fd;font-style:italic}.chroma .kn{color:#ff79c6}.chroma .kp{color:#ff79c6}.chroma .kr{color:#ff79c6}.chroma .kt{color:#8be9fd}.chroma .na{color:#50fa7b}.chroma .nb{color:#8be9fd;font-style:italic}.chroma .nc{color:#50fa7b}.chroma .nf{color:#50fa7b}.chroma .nl{color:#8be9fd;font-style:italic}.chroma .nt{color:#ff79c6}.chroma .nv{color:#8be9fd;font-style:italic}.chroma .vc{color:#8be9fd;font-style:italic}.chroma .vg{color:#8be9fd;font-style:italic}.chroma .vi{color:#8be9fd;font-style:italic}.chroma .s{color:#f1fa8c}.chroma .sa{color:#f1fa8c}.chroma .sb{color:#f1fa8c}.chroma .sc{color:#f1fa8c}.chroma .dl{color:#f1fa8c}.chroma .sd{color:#f1fa8c}.chroma .s2{color:#f1fa8c}.chroma .se{color:#f1fa8c}.chroma .sh{color:#f1fa8c}.chroma .si{color:#f1fa8c}.chroma .sx{color:#f1fa8c}.chroma .sr{color:#f1fa8c}.chroma .s1{color:#f1fa8c}.chroma .ss{color:#f1fa8c}.chroma .m{color:#bd93f9}.chroma .mb{color:#bd93f9}.chroma .mf{color:#bd93f9}.chroma .mh{color:#bd93f9}.chroma .mi{color:#bd93f9}.chroma .il{color:#bd93f9}.chroma .mo{color:#bd93f9}.chroma .o{color:#ff79c6}.chroma .ow{color:#ff79c6}.chroma .c{color:#6272a4}.chroma .ch{color:#6272a4}.chroma .cm{color:#6272a4}.chroma .c1{color:#6272a4}.chroma .cs{color:#6272a4}.chroma .cp{color:#ff79c6}.chroma .cpf{color:#ff79c6}.chroma .gd{color:#8b080b}.chroma .ge{text-decoration:underline}.chroma .gh{font-weight:bold}.chroma .gi{font-weight:bold}.chroma .go{color:#44475a}.chroma .gu{font-weight:bold}.chroma .gl{text-decoration:underline}.lntd:first-of-type>.chroma{padding-right:0}.chroma code{font-family:'Fira Code' !important;font-size:0.85em;line-height:1em;background:none;padding:0}.chroma{border-radius:3px;margin:0} diff --git a/resources/_gen/assets/scss/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.json b/resources/_gen/assets/scss/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.json new file mode 100644 index 000000000..51f0c9c9a --- /dev/null +++ b/resources/_gen/assets/scss/styles/syntax.scss_c25f88f67e8e33f20619c76cbf49f33c.json @@ -0,0 +1 @@ +{"Target":"styles/syntax.css","MediaType":"text/css","Data":{}} \ No newline at end of file