Джерело
interfaces.prjctr | vnotchenko week | Два приклади з моєї роботи, щоб було трохи конкретніше. В одному з har...
1 120 Охват/переглядів
2026-09-22 16:43
Повідомлення №3104
Два приклади з моєї роботи, щоб було трохи конкретніше.
В одному з hardware-продуктів, над яким я працював, у нас був досить великий drop-off на checkout. Ми якийсь час намагались покращити сам флоу: спрощували його, міняли блоки місцями, пробували різні способи оплати. А потім виявилось, що проблема взагалі не в checkout. Люди просто не хотіли щомісячну підписку - вони хотіли купити hardware і володіти ним без підписки. Коли ми її прибрали, метрики одразу значно покращились. Тобто весь цей час ми оптимізували місце, де проблема проявлялась, а не де вона насправді виникала. Для мене це хороший приклад того, чому системне мислення важливе: можна було ще довго покращувати checkout, а можна було відзумити і запитати себе - а чи правильну проблему ми взагалі вирішуємо?
Інший приклад вже з AI. У своїй поточній команді я будую сетап, який має сам покращувати нашу дизайн-систему по мірі того, як дизайнери нею користуються. Ідея досить проста: сесії дизайнерів, і хороший і поганий output від AI та фідбек на нього не мають просто зникати після кожної взаємодії. Все це аналізується, зберігається в узагальненому вигляді і поступово впливає на те, як система еволюціонує далі. Feedback loops тут вбудовані в сам процес користування дизайн-системою. Це дозволяє думати про неї не як про статичний Figma-файл чи репозиторій, а як про живий організм, який постійно вчиться і змінюється.
Загалом майже в кожному своєму проєкті я намагаюсь час від часу зупинятись, відзумлювати і дивитись на проблему трохи ширше. Є кілька простих інструментів системного мислення, до яких я сам постійно повертаюсь:
• декомпозиція - розкласти складну проблему на частини
• композиція - зібрати її назад і подивитись, як все працює разом
• межі системи - перевірити, чи не дивлюсь я на проблему занадто вузько
• feedback loops - зрозуміти, який сигнал система отримує назад і як він впливає на те, що відбувається далі
Останнє зараз особливо цікаве через AI. Ми все менше думаємо в парадигмі «один запит → один результат» і все більше будуємо цикли: дія → результат → оцінка → сигнал → корекція → наступна дія.
✨
Це все, звісно, дуже по верхах. Не хочу перетворювати цей пост на лекцію про systems thinking - скоріше хотів звернути увагу на саму навичку і показати на парі прикладів, чому я вважаю її настільки корисною.
Якщо захочете копнути глибше, я б почав з Donella Meadows - Thinking in Systems.
В одному з hardware-продуктів, над яким я працював, у нас був досить великий drop-off на checkout. Ми якийсь час намагались покращити сам флоу: спрощували його, міняли блоки місцями, пробували різні способи оплати. А потім виявилось, що проблема взагалі не в checkout. Люди просто не хотіли щомісячну підписку - вони хотіли купити hardware і володіти ним без підписки. Коли ми її прибрали, метрики одразу значно покращились. Тобто весь цей час ми оптимізували місце, де проблема проявлялась, а не де вона насправді виникала. Для мене це хороший приклад того, чому системне мислення важливе: можна було ще довго покращувати checkout, а можна було відзумити і запитати себе - а чи правильну проблему ми взагалі вирішуємо?
Інший приклад вже з AI. У своїй поточній команді я будую сетап, який має сам покращувати нашу дизайн-систему по мірі того, як дизайнери нею користуються. Ідея досить проста: сесії дизайнерів, і хороший і поганий output від AI та фідбек на нього не мають просто зникати після кожної взаємодії. Все це аналізується, зберігається в узагальненому вигляді і поступово впливає на те, як система еволюціонує далі. Feedback loops тут вбудовані в сам процес користування дизайн-системою. Це дозволяє думати про неї не як про статичний Figma-файл чи репозиторій, а як про живий організм, який постійно вчиться і змінюється.
Загалом майже в кожному своєму проєкті я намагаюсь час від часу зупинятись, відзумлювати і дивитись на проблему трохи ширше. Є кілька простих інструментів системного мислення, до яких я сам постійно повертаюсь:
• декомпозиція - розкласти складну проблему на частини
• композиція - зібрати її назад і подивитись, як все працює разом
• межі системи - перевірити, чи не дивлюсь я на проблему занадто вузько
• feedback loops - зрозуміти, який сигнал система отримує назад і як він впливає на те, що відбувається далі
Останнє зараз особливо цікаве через AI. Ми все менше думаємо в парадигмі «один запит → один результат» і все більше будуємо цикли: дія → результат → оцінка → сигнал → корекція → наступна дія.
✨
Це все, звісно, дуже по верхах. Не хочу перетворювати цей пост на лекцію про systems thinking - скоріше хотів звернути увагу на саму навичку і показати на парі прикладів, чому я вважаю її настільки корисною.
Якщо захочете копнути глибше, я б почав з Donella Meadows - Thinking in Systems.