Я впевнений, що ви чули про смуги або використовували програму з ними. Але ви коли-небудь замислювалися, чому смуги такі популярні та потужні? Що ж, очевидно, що додатки хочуть якомога більше вашої уваги, але крім цього, чи знаєте ви, що коли популярний навчальний додаток Duolingo представив віджети iOS для відображення смуг, прихильність користувачів зросла на 60%. Шістдесят відсотків — це значні зміни в поведінці та демонстрація того, як шаблони «смуг» можна використовувати для підвищення залученості та стимулювання використання. По суті, серія — це кількість послідовних днів, протягом яких користувач виконує певну дію. Деякі люди також визначають це як «гейміфіковану» звичку або показник, призначений для заохочення постійного використання. Але смуги виходять за межі метрики чи запису в програмі; це більше психологічно, ніж це. На людські інстинкти легко вплинути за допомогою правильних факторів. Подивіться на ці три чинники: прогрес, гордість і страх втратити (зазвичай називається FOMO). Що спільного між усіма цими? зусилля. Чим більше зусиль ви докладаєте до чогось, тим більше це формує вашу ідентичність, і саме так смуги перетинаються у світі поведінкової психології. Тепер із великою владою приходить велика відповідальність, і через це є темна сторона смуг. У цій статті ми розглянемо психологію, UX і принципи дизайну, що лежать в основі побудови ефективної системи ліній. Ми розглянемо (1) чому наш мозок майже інстинктивно реагує на смугову активність, (2) як створити смуги таким чином, щоб справді допомогти користувачам, і (3) технічну роботу, пов’язану зі створенням смужкового шаблону. Психологія за смугами Щоб розробити та побудувати ефективну систему смуг, нам потрібно зрозуміти, як вона узгоджується з тим, як влаштований наш мозок. Наприклад, що робить його настільки ефективним, що ми відчуваємо таку велику відданість захисту своїх смуг? Є три цікаві, добре задокументовані психологічні принципи, які підтверджують те, що робить смуги такими потужними та викликають звикання. Відраза до втрат Це, мабуть, найсильніша сила, що стоїть за смугами. Я кажу це тому, що в більшості випадків ви майже не можете уникнути цього в житті. Подумайте про це так: якщо друг дасть вам 100 доларів, ви будете щасливі. Але якби ви втратили 100 доларів зі свого гаманця, це було б набагато більше. Емоційна вага цих ситуацій неоднакова. Втрата болить набагато більше, ніж приємне отримання. Давайте підемо далі і скажемо, що я даю вам 100 доларів і прошу вас зіграти в азартну гру. Існує 50% шансів, що ви виграєте ще 100 доларів, і 50% шансів, що ви втратите початкові 100 доларів. Ви б це взяли? Я б не став. Більшість людей цього не зробили б. Це відраза до втрат. Якщо подумати, це логічно, це зрозуміло, це по-людськи. Концепція неприйняття втрат полягає в тому, що ми відчуваємо біль від втрати чогось удвічі сильніше, ніж задоволення від отримання чогось рівноцінного. З точки зору психології, втрата затримується більше, ніж здобуток. Ви, мабуть, бачите, як це стосується смуг. Щоб створити помітну смугу, потрібно докласти зусиль; у міру зростання смуги мотивація, що стоїть за нею, починає зникати; точніше, починає відходити на другий план. Ось приклад: припустімо, що у вашого друга три дні закриваються «кільця руху» на Apple Watch. Їм майже нічого втрачати, крім бажання досягти своєї мети та бути послідовними. У той же час у вас є вражаюча 219-денна смуга. Швидше за все, ви потрапили в пастку через страх втратити його. Швидше за все, ви зараз не думаєте про досягнення; це більше стосується захисту ваших вкладених зусиль, і це несприйняття втрат. Duolingo пояснює, як несприйнятливість до втрат сприяє небажанню користувача перервати довгу смугу навіть у найлінивіші дні. У певному сенсі смуга може перетворитися на звичку, коли з’являється огида до втрат. Модель поведінки Фогга (B = MAP) Тепер, коли ми розуміємо страх втратити зусилля, вкладені в більш довгі смуги, виникає інше питання: що змушує нас робити це в першу чергу, день за днем, навіть до того, як смуга стане великою? Саме про це йдеться в моделі поведінки Фогга. Це відносно просто. Поведінка (B) виникає лише тоді, коли три фактори — Мотивація (M), Здібності (A) і Підказка (P) — збігаються одночасно. Таким чином, рівняння B=MAP. Якщо будь-який із цих факторів, навіть один, відсутній у цей момент, поведінка не відбудеться. Таким чином, щоб смугова система була ефективною та повторюваною, мають бути присутні всі три фактори: Мотивація – це крихка мотивація, яка не є постійною. Бувають дні, коли тинатхненний вивченням іспанської мови, і дні, коли ви навіть не відчуваєте йоти сили волі вивчити мову. Сама по собі мотивація вироблення звички є ненадійною та програшною битвою з першого дня. Здатність компенсувати обмеження мотивації має вирішальне значення. У цьому контексті здатність означає легкість дій, тобто зусилля настільки легкі, що нереально сказати, що це неможливо. Більшість програм навмисно використовують це. Apple Fitness просто вимагає, щоб ви стояли одну хвилину протягом години, щоб заробити позначку для досягнення вашої цілі «Стояти». Duolingo потрібен лише один завершений урок. Ці завдання не потребують великих зусиль. Бар'єр настільки низький, що навіть у найгірші дні ви можете це зробити. Але спільні зусилля триваючої серії – це те, де виникає ідея програти цю серію. Ось що завершує рівняння. Люди від природи забудькуваті, тож так, здібності можуть досягти цього на 90%. Але підказка нагадує нам діяти. Смуги є стійкими, тому користувачам потрібно постійно нагадувати про необхідність діяти. Щоб побачити, наскільки потужним може бути підказка, Duolingo провів A/B-тест, щоб побачити, чи маленький червоний значок на піктограмі додатка збільшує стабільність використання. Це призвело до збільшення щоденних активних користувачів на 6%. Просто червоний значок. Обмеження моделі Зважаючи на все це, у моделі Фогга є обмеження, згідно з якими критики та сучасні дослідники помітили, що дизайн, який занадто сильно покладається на підказки, як-от агресивні сповіщення, ризикує спричинити розумову втому. Постійні сповіщення та понаднормова робота можуть призвести до відтоку користувачів. Отже, стежте за цим. Ефект Зейгарника Що ви відчуваєте, коли залишаєте завдання проекту наполовину виконаним? Це дратує багатьох людей, оскільки незавершені завдання займають більше розумового простору, ніж те, що ми завершуємо. Коли щось зроблено і зникло, ми схильні забути це. Коли щось залишається незробленим, це, як правило, обтяжує наш розум. Саме тому цифрові продукти використовують штучні індикатори прогресу, як-от панель заповнення профілю Upwork, щоб повідомити користувачеві, що його профіль заповнено лише на «60%». Це спонукає користувача завершити розпочате.
Давайте розглянемо інший приклад. У вас є п’ять завдань у додатку зі списком справ, і в кінці дня ви перевіряєте лише чотири з них як виконані. Багато з нас почуватимуться недосконалими через одне незавершене завдання. Ось тут і є ефект Зейгарніка. Ефект Зейгарніка продемонструвала психолог Блюма Зейгарнік, яка описала, що ми схильні зберігати в пам’яті невиконані завдання довше, ніж виконані. В UX-дизайні це природно входить у смуговий візерунок. Скажімо, у вас 63-й день серії навчання. У цей момент ви перебуваєте в постійній картині незавершених справ. Ваш мозок рідко забуває про це, оскільки воно сидить у глибині вашої свідомості. У цей момент ваш мозок стає тим, хто надсилає вам сповіщення. Коли ви об’єднуєте ці психологічні сили, ви починаєте справді розуміти, чому смуги — це не просто звичайна функція програми; вони здатні змінювати людську поведінку. Але десь уздовж лінії — я не можу точно сказати, коли, оскільки це для кожного різне — все досягає точки, коли смуга зміщується з «веселощів» на те, що ви не можете дозволити собі втратити. Ви ж не хочете, щоб 58 днів зусиль пропали даремно? Саме це робить смугову систему ефективною. Якщо все зроблено правильно, смуги допомагають користувачам виробити приголомшливі звички для досягнення мети. Це може бути щоденне читання або постійне відвідування тренажерного залу. Ці повторювані дії (іноді незначні) поєднуються з часом і стають очевидними в нашому повсякденному житті. Але кожна медаль має дві сторони. Тонка грань між звичкою та примусом Якщо ви слідкували за цим, ви вже можете сказати, що є темна сторона смугових систем. Формування звички — це послідовність із повторюваною метою. Проте примус — це постійна робота над досягненням мети, яка більше не потрібна, але якої тримаються через страх чи тиск. Це тонка, як бритва, лінія. Ви чистите зуби щоранку, не замислюючись; це автоматично та інстинктивно, з чіткою метою мати гарне дихання. Це смуга, яка формує хорошу звичку. Система етичної смуги дає користувачам простір для дихання. Якщо з якоїсь причини ви не чистите зуби вранці, можете почистити зуби опівдні. Недосконалість допускається, не боячись втратити тривале зусилля. Примус розвивається протилежним шляхом, коли смуга викликає у вас тривогу, почуття провини або навіть виснаження, а іноді здається, що ви нічого не досягли, незважаючи на всі своїпрацювати. Ви дієте не тому, що хочете, а тому, що підсвідомо боїтеся побачити, як ваш прогрес скидається на нуль. Хтось навіть чудово описав це: "Я відчував, що обманюю, але це просто не хвилювало. Я ніщо без своєї смуги". Це показує, яку смугу сильного утримання можуть мати особи. У тій мірі, в якій користувачі починають прив’язувати свою самооцінку до довільного показника, а не до початкової мети чи причини, з якої вони почали цю серію. Смуга стає тим, ким вони є, а не лише тим, що вони роблять. Добре продумана система етичних правил повинна сприйматися користувачем як заохочення, а не як тиск чи зобов’язання. Це стосується балансу внутрішньої та зовнішньої мотивації. Зовнішня мотивація (зовнішні винагороди, уникнення покарань) може спонукати користувачів почати роботу, але внутрішня мотивація (виконання завдання заради особистої мети, як-от вивчення іспанської, тому що ви щиро хочете спілкуватися з коханою людиною) є сильнішою для довгострокової взаємодії. Хороша система має тяжіти до внутрішньої мотивації з обережним використанням зовнішніх елементів, тобто нагадувати користувачам про те, як далеко вони зайшли, а не погрожувати їм тим, що вони можуть втратити. Знову ж таки, це тонка грань. Простий тест під час розробки серійної системи полягає в тому, щоб приділити трохи часу й подумати, чи заробляють ваші продукти гроші, продаючи рішення для подолання тривоги, створені вашим продуктом. Якщо так, є висока ймовірність, що ви експлуатуєте користувачів. Тож постає наступне запитання: якщо я вирішу використовувати streak, як мені створити його таким чином, щоб справді допомогти користувачам досягти їхніх цілей? UX хорошого дизайну системи Streak Я вважаю, що саме тут більшість проектів або створюють ефективну систему смуг, або повністю її псують. Давайте розглянемо деякі принципи UX для гарного дизайну смуг. Зберігайте це без зусиль Ви, мабуть, чули це раніше, можливо, з таких книжок, як Atomic Habits, але варто згадати, що один із найпростіших способів вироблення звичок — це зробити дію крихітною та легкою. Це схоже на фактор здібностей, який ми обговорювали в моделі поведінки Фогга. Першим правилом будь-якої серії планів має бути якомога менша кількість необхідних дій, але при цьому досягається прогрес. Якщо для виконання щоденної дії потрібна сила волі, ця дія не витримає й п’яти днів. чому Ви не можете бути мотивованими п’ять днів поспіль. Приклад: якщо ви запускаєте програму для медитації, вам не потрібно змушувати користувачів проходити 20-хвилинний сеанс, щоб зберегти серію. Натомість спробуйте одну хвилину, можливо, навіть щось невелике, як тридцять секунд. Як кажуть, з маленьких крапельок води могутній океан). Маленькі зусилля з часом перетворюються на великі досягнення. Це має бути мета: усунути тертя, особливо коли момент може бути важким. Коли користувачі перебувають у стані стресу або перевтоми, дайте їм знати, що проста поява, навіть на кілька секунд, вважається зусиллям. Забезпечте чіткий візуальний зворотний зв'язок Люди за своєю природою візуальні. У більшості випадків нам потрібно щось побачити, щоб повірити; є така потреба візуалізувати речі, щоб краще їх зрозуміти та поставити речі в перспективу. Ось чому шаблони смуг часто використовують візуальні елементи, такі як графіки, галочки, кільця прогресу та сітки, щоб візуалізувати зусилля. Подивіться на графік внесків GitHub. Це проста візуалізація послідовності. Але розробники вдихають його як кисень.
Головне — не робити систему смуг абстрактною. Це повинно відчуватися справжнім і заслуженим. Наприклад, у фітнес-кільцях Duolingo та Apple використовується чистий анімаційний дизайн після завершення серії, а GitHub показує історичні дані про послідовність користувача протягом певного часу.
Використовуйте правильний час Раніше я згадував, що люди за своєю природою забудькуваті, і що підказки можуть допомогти зберегти рух вперед. Без підказок більшість нових користувачів забувають продовжувати. Життя може зайнятися, мотивація зникає, і все трапляється. Навіть давні користувачі отримують користь від підказок, хоча в більшості випадків вони вже заблоковані в циклі звички. Тим не менш, навіть найбільш віддана людина може випадково пропустити день. Ваша система серії точно потребує нагадувань. Найчастіше використовувані нагадування – це push-повідомлення. Час справді має значення під час роботи з push-повідомленнями. Тип програми також має значення. Надсилати сповіщення о 9:00 із повідомленням «Ви сьогодні не тренувалися» — це просто дивно для навчального додатка, оскільки багато хто має чим зайнятися протягом дня, перш ніж вони навіть подумають про завершення уроку. Однак, якщо ми говоримо про фітнес-додаток, цеє розумним і, можливо, навіть очікується, що про нього нагадують раніше цього дня. Push-сповіщення значно відрізняються залежно від категорії програми. Додатки для фітнесу, наприклад, бачать більшу взаємодію з ранковими сповіщеннями (7–8 ранку), тоді як додатки для підвищення продуктивності можуть працювати краще рано в обід. Головне — тестувати A/B час вашої програми на основі поведінки ваших користувачів, а не припускати, що все одно для всіх. Те, що працює в додатку для медитації, може не працювати в трекері кодування. Інші методи сповіщення – це червоні точки на піктограмі програми та навіть віджети програми. Дослідження відрізняються, але середня людина розблоковує свій пристрій 50-150 разів на день (PDF). Якщо користувач бачить червону крапку на програмі чи віджеті, яка вказує на поточну серію кожного разу, коли він розблоковує свій телефон, це збільшує зобов’язання. Тільки не перестарайтеся; підказка має служити нагадуванням, а не пристрітом. Святкуйте віхи Система серії повинна намагатися відзначати віхи, щоб відновити емоції, особливо для користувачів, які глибоко в серії. Коли користувач досягає Дня 7, Дня 30, Дня 50, Дня 100, Дня 365, ви повинні зробити з цього велику справу. Визнайте досягнення — особливо для давніх користувачів.
Як ми бачили раніше, Duolingo це зрозумів і реалізував анімовану графіку, яка відзначає віхи за допомогою конфетті. Деякі платформи навіть надають значні бонуси, які підтверджують зусилля користувачів. І це може бути корисним для програм, тому що користувачі, як правило, публічно діляться своїми віхами в соціальних мережах. Ще однією перевагою є очікування, яке виникає перед досягненням основних етапів. Це не просто нескінченне збереження серії; користувачам є на що сподіватися. Використовуйте механізми благодаті Життя непередбачуване. Люди відволікаються. Будь-яка хороша система смуг повинна очікувати недосконалості. Однією з найбільших психологічних загроз системі серії є жорстке скидання до нуля лише після одного пропущеного дня. «Етична» система смуг повинна забезпечувати користувачеві деяку слабину. Припустімо, у вас 90-денна смуга вивчення шахів. Ви були послідовні протягом трьох хороших місяців, і одного разу ваш телефон вимикається під час подорожі, і 90 перетворюється на 0 — усе, усі зусилля стираються, а прогрес зникає. Користувач може бути повністю спустошений. Думка відновити його з нуля настільки деморалізує, що зусилля не варті того. У гіршому випадку користувач може відмовитися від програми, відчувши її невдачу. Подумайте про додавання механізму «пільги» до вашої системи смуг:
Streak FreezeДозволяє користувачам навмисно пропускати день без штрафів. Додатковий час Дозволяє кілька годин (2–3) після звичайного кінцевого терміну, перш ніж ініціювати скидання. Моделі затухання. Замість апаратного скидання серія зменшується на невелику величину, наприклад, 10 днів віднімається з серії за кожен пропущений день.
Використовуйте підбадьорливий тон Давайте порівняємо два повідомлення, які відображаються користувачам, коли серія переривається:
"Ви втратили свою 42-денну серію. Почніть спочатку". "Ви з'являлися 42 дні поспіль. Це неймовірний прогрес! Хочете спробувати ще раз?"
Обидва передають однакову інформацію, але емоційний вплив різний. Перше повідомлення, швидше за все, змусить користувача відчути себе деморалізованим і змусить його вийти. Друге повідомлення відзначає те, що вже було досягнуто, і м’яко заохочує користувача спробувати ще раз. Проблеми проектування Streak Systems Перш ніж ми перейдемо до технічних особливостей побудови смугової системи, вам слід знати про труднощі, з якими ви можете зіткнутися. Усе може ускладнитися, як і можна було очікувати. Обробка часових поясів Існує причина, чому робота з часом і датою є однією з найскладніших концепцій, з якими мають справу розробники. Потрібно враховувати форматування, інтернаціоналізацію та багато іншого. Дозвольте запитати вас: що вважається днем? Ми знаємо, що світ працює в різних часових поясах, і ніби цього недостатньо, деякі регіони мають літній час (DST), який відбувається двічі на рік. З чого взагалі почати розглядати ці крайні випадки? Що вважається «початком» завтрашнього дня? Деякі розробники намагаються уникнути цього, використовуючи один центральний часовий пояс, наприклад UTC. Для деяких користувачів це дасть правильні результати, але для деяких це може бути відключено на годину, дві години або більше. Ця невідповідність руйнує досвід користувача. Користувачів менше хвилює, як ви проводите час за кадром; усе, на що вони очікують, це те, що якщо вони виконають рядову дію о 23:40, то вона має бути зареєстрована саме в цей час у їхньому контексті. Вам слід визначити «один день» на основі місцевого часового поясу користувача, а не часу сервера. Звичайно, ви можете легкомаршрутизувати та скидати смуги глобально для всіх користувачів опівночі за UTC, але ви створюєте несправедливість. Хтось у Каліфорнії завжди має вісім додаткових годин, щоб виконати своє завдання, ніж той, хто живе в Лондоні. Це несправедливий недолік дизайну, який карає певних користувачів через їх місцезнаходження. А що, якщо ця людина в Лондоні лише в гостях, виконує завдання, а потім повертається в інший часовий пояс? Одне з ефективних рішень для всіх цих — попросити користувачів явно встановити свій часовий пояс під час реєстрації (бажано після першої автентифікації). Варто включити тонку примітку про те, що надання інформації про часовий пояс використовується лише для того, щоб програма точно відстежувала прогрес, а не використовується як ідентифікаційна інформація. І ще одна хороша ідея – зробити це налаштування змінним. Я пропоную всім уникати безпосередньої обробки логіки часового поясу в програмі. Використовуйте перевірені бібліотеки дат, такі як Moment.js або pytz (Python) тощо. Немає потреби винаходити колесо для чогось такого складного, як це. Пропущені дні та крайні випадки Ще одна проблема, про яку вам слід хвилюватися, — це неконтрольовані крайні випадки, як-от засипання користувачів, простої сервера, затримки, збої мережі тощо. Використання ідеї механізмів пільг, подібних до тих, які ми обговорювали раніше, може допомогти. Пільговий період у дві години може допомогти як користувачеві, так і розробнику в тому сенсі, що користувачів не каратимуть жорстко за неконтрольовані життєві обставини. Для розробників пільгові вікна корисні в ті неконтрольовані моменти, коли сервер перестає працювати посеред ночі. Перш за все, ніколи не довіряйте клієнту. Завжди перевіряйте на стороні сервера. Сервер має бути єдиним джерелом правди. Запобігання шахрайству Знову ж таки, я не можу підкреслити це достатньо: переконайтеся, що перевіряєте все на стороні сервера. Користувачі — люди, і люди можуть обманювати, якщо їм нададуть можливість. Це неминуче. Ви можете спробувати:
Зберігання всіх дій із часовими мітками UTC. Клієнт може надіслати свій місцевий час, але сервер може негайно перетворити його на UTC і перевірити час на сервері. Таким чином, якщо часова позначка клієнта підозріло далека, система може відхилити це як помилку, а інтерфейс користувача зможе відповісти відповідним чином. Використання відстеження на основі подій. Іншими словами, зберігайте записи про кожну дію з метаданими, включаючи таку інформацію, як ідентифікатор користувача, тип виконаної дії, позначку часу та часовий пояс. Це допомагає під час перевірки.
Створення двигуна Streak System Це не підручник з коду, тому я не буду скидати вам купу коду. Я зберігаю це практичним і опишу, як загалом працює движок системи streak щодо архітектури, потоку та надійності. Основна архітектура Як я вже казав кілька разів, зробіть сервер єдиним джерелом правдивих даних для серії. Архітектура на сервері може виглядати приблизно так:
Зберігайте дані кожного користувача в базі даних. Зберігати поточне сховище смуг (за замовчуванням як 0) як ціле число. Зберігайте налаштування часового поясу, тобто рядок часового поясу IANA (неявно з локальної позначки часу або явно, попросивши користувача вибрати свій часовий пояс). Наприклад, «Америка/Нью-Йорк». Обробляйте всю логіку, щоб визначити, чи триває смуга чи переривається, перевіряючи часовий пояс, який відповідає місцевому часовому поясу користувача.
Тим часом на стороні клієнта:
Відображати поточну серію, яку зазвичай отримують із сервера. Надішліть дію, виконану у формі метаданих, на сервер, щоб перевірити, чи дійсно користувач виконав кваліфікаційну дію серії. Надайте візуальний зворотний зв’язок на основі відповідей сервера.
Коротше кажучи, мозок знаходиться на сервері, а клієнт призначений для відображення та надсилання подій. Це позбавить вас від багатьох несправностей і крайніх випадків, а також спростить оновлення та виправлення. Логічний потік Давайте змоделюємо покрокове керівництво щодо того, як працюватиме мінімально ефективний механізм системи посмуг, коли користувач виконує дію:
Користувач виконує кваліфікаційну дію серії. Клієнт надсилає подію на сервер як метадані. Це може бути «Користувач X виконав дію Y о мітці часу Z». Сервер отримує цю подію та виконує базову перевірку. Це справжній користувач? Вони автентифіковані? Чи діє акція? Чи відповідає часовий пояс? Якщо це пройде, сервер отримує дані про серії користувача з бази даних. Потім конвертуйте отриману мітку часу дії в місцевий часовий пояс користувача. Нехай сервер порівнює календарні дати (не позначки часу) у локальному часовому поясі користувача: Якщо це той самий день, тоді дія є зайвою, і немає змін усмуга. Якщо наступного дня, то смуга продовжується і збільшується на 1. Якщо розрив перевищує один день, смуга переривається. Однак саме тут ви можете застосувати механіку витонченості. Якщо механізм пільги пропущено, скиньте смугу до 1.
Якщо ви вирішите зберігати історичні дані для ключових досягнень, оновіть такі змінні, як «найдовша серія» або «загальна кількість активних днів». Потім сервер оновлює базу даних і відповідає клієнту. Щось на зразок цього:
{ "current_streak": 48, "longest_streak": 50, "total_active_days": 120, "streak_extended": true, }
Як подальший захід, сервер повинен або повторити спробу, або відхилити та сповістити клієнта, коли щось не вдається під час процесу. Будівництво для стійкості Як згадувалося раніше, користувачі, які втрачають серію через помилки або простої сервера, є жахливим для UX, і користувачі не очікують, що це зазнає падіння. Таким чином, ваша система серії повинна мати гарантії для таких сценаріїв. Якщо сервер не працює через технічне обслуговування (або з будь-якої іншої причини), подумайте про те, щоб дозволити тимчасове вікно додаткових годин, щоб виправити це, щоб дії могли надсилатися із запізненням і все ще враховуватися. Ви також можете вибрати сповіщення користувачів, особливо якщо ситуація може вплинути на поточну серію. Примітка. Створіть бекдор адміністратора, де дані можна буде відновити вручну. Помилки неминучі, і деякі користувачі зателефонують у ваш додаток або звернуться за підтримкою, якщо їхня серія перервалася з причини, яку вони не можуть контролювати. Ви повинні мати можливість вручну відновити смуги, якщо після дослідження користувач має рацію. Висновок Одне залишається ясним: смуги дійсно потужні через те, як працює людська психологія на фундаментальному рівні. Найкраща система поспіль – це та, про яку користувачі не думають свідомо. Це стало рутиною негайних результатів або видимого прогресу, як чищення зубів, яке стає звичайною звичкою. І я просто скажу це: не всі продукти потребують системи смуг. Should you really force consistency just because you want daily active users? Відповідь цілком може бути «ні».
