01 — Короткий план / Інтро
Як перетворити досвід спільноти на частину вибору товару?
Kinpick — дослідницький iOS-прототип маркетплейсу, у якому каталог, порівняння й структурований досвід спільноти працюють як один сценарій. Ця сторінка описує не тільки фінальний інтерфейс, а й шлях до нього: питання, припущення, рішення та компроміси.
- Моя роль
- Product designer · Research · Prototype
- Формат
- Тестове завдання / самостійна робота
- Платформа
- iPhone · SwiftUI · локальні дані
- Фокус
- Вибір об’єктива для камери
- Результат
- Нативний наскрізний прототип
- Статус
- Готовий до обговорення й тестування
Короткий маршрут
- Побачити результат: як виглядає продуктова модель і що вже працює.
- Пройти сценарій: подивитися ключові екрани та живий прототип.
- Повернутися до задачі: зрозуміти проблему, контекст і обмеження.
- Розібрати мислення: пройти від спостережень до гіпотез і рішень.
Текст у цьому шаблоні — стартова рамка. Додайте фактичні методи, цитати, посилання та висновки зі своєї роботи.
04 — Завдання
Не знайти «найкращий» товар, а допомогти зробити усвідомлений вибір.
Формулювання проблеми
У категоріях зі складними характеристиками рішення рідко приймається всередині одного магазину. Людина дивиться каталог, відкриває огляди, читає форуми, порівнює чужі сценарії зі своїм і намагається зрозуміти, які компроміси будуть прийнятними саме для неї.
Я сформулював завдання так: як дати людині достатньо контексту для рішення, не змушуючи її самостійно збирати цей контекст із десятків джерел?
«Мені не потрібен найкращий об’єктив узагалі. Мені потрібен той, про недоліки якого я не пошкодую».
Робоче формулювання користувацької напруги
Критерії успіху
- Людина розуміє, чому конкретний товар потрапив до рекомендації.
- Сумісність і важливі обмеження видно до переходу в деталі.
- Досвід спільноти допомагає рішенню, а не створює ще більше шуму.
- Основний сценарій працює без реєстрації та зовнішнього бекенду.
Обмеження та межі прототипу
У фокусі
- Одна вертикаль: фото
- Об’єктиви трьох систем
- Підбір, порівняння, пояснення
- Локальна взаємодія
Поза фокусом
- Авторизація й профілі
- Оплата та checkout
- Реальний UGC і модерація
- Аналітика та push
05 — Дослідження та контекст
Спочатку — зрозуміти, де саме виникає невпевненість.
Дослідження мало відокремити інформаційну проблему від інтерфейсної: чи бракує людям даних, чи бракує способу зіставити дані зі своїм контекстом.
Методи й матеріали
Огляд категорії
Структура каталогів, фільтрів і карток товару в чинних маркетплейсах.
Контент-аналіз
Питання, порівняння й повторювані аргументи на тематичних форумах.
Карта рішення
Послідовність дій від першого запиту до короткого списку й купівлі.
Прототипування
Перевірка структури на реальному каталозі з сумісністю та цінами.
Додайте схему шляху вибору, affinity map або інший ключовий дослідницький артефакт.
Відкрити оригінал ↗Що я спостерігав
Інформація про товар поділена на два нерівні шари. Каталог добре відповідає на питання «що це?», «скільки коштує?» і «чи сумісне?», але слабко пояснює наслідки вибору. Спільнота дає багатший контекст, проте він неструктурований і часто прив’язаний до невідомого сценарію автора.
| Спостереження | Що це означає | Наслідок для продукту |
|---|---|---|
| Люди відкривають кілька джерел | Одного каталогу недостатньо | Звести факти й досвід в один контекст |
| Однакова оцінка приховує різний досвід | Рейтинг втрачає сценарій | Показувати тип досвіду й умови вибору |
| Сумісність перевіряють вручну | Помилка має високу ціну | Зробити mount частиною базової моделі |
| Порада без пояснення викликає сумнів | Рекомендації потребують довіри | Показувати збіги та компроміси |
Синтез: три ключові інсайти
- 01
Контекст важливіший за середню оцінку
Думка корисна тоді, коли зрозуміло, для якого сценарію, досвіду та обладнання вона сформована.
- 02
Компроміс — це частина відповіді
У складній категорії немає вибору без втрат. Їх краще назвати до покупки, а не приховувати.
- 03
Знання мають повертатися в систему
Історія «чому я це обрав» може бути кориснішою за загальний відгук після покупки.
06 — Гіпотези й процес
Перекласти інсайти у твердження, які можна перевірити.
Я не намагався одразу спроєктувати весь маркетплейс. Спочатку визначив, які зміни у структурі інформації можуть найбільше вплинути на якість рішення.
Формат гіпотези
Якщо ми покажемо релевантний досвід поруч із товаром, то людина швидше сформує короткий список, тому що їй не доведеться відновлювати контекст по різних джерелах.
Пріоритизація
| Гіпотеза | Цінність | Ризик | Що перевіряю |
|---|---|---|---|
| Контекстні типи дописів корисніші за спільну стрічку | Висока | Високий | Чи зрозуміла структура |
| Сумісність має передувати фільтрам | Висока | Середній | Чи зменшується помилка |
| Рекомендація потребує явних trade-offs | Висока | Високий | Чи зростає довіра |
| Після покупки люди готові пояснювати вибір | Середня | Високий | Мотивація до внеску |
Як змінювалась модель
Покажіть не тільки фінальний варіант: додайте 2–4 ітерації та коротко поясніть, що змінилося.
Журнал ключових рішень
Звузив категорію до об’єктивів
Сумісність і сценарії використання роблять категорію достатньо складною, але керованою для прототипу.
Розділив дописи за наміром
Питання, порівняння, досвід власника й історія вибору несуть різний тип доказу.
Відмовився від «магічного» score
Замість одного числа результат показує причини збігу, переваги та компроміси.
Зібрав нативний прототип
Реальна навігація й локальний стан дозволяють перевірити сценарій, а не набір екранів.
Демонстраційний контент підтверджує роботу моделі, але не відповідає на питання cold start, якості UGC і мотивації експертів.
02 — Готовий результат
Каталог, спільнота й рекомендація як одна система.
Фінальна концепція не додає форум до магазину. Вона розміщує різні типи досвіду в тих точках сценарію, де вони допомагають прийняти конкретне рішення.
Принципи рішення
Релевантність раніше популярності
Спочатку сумісність і сценарій, потім рейтинг та загальна популярність.
Доказ поруч із твердженням
Порада пов’язана з досвідом людей, товарами й умовами, що її сформували.
Компроміси не приховані
Кожна рекомендація пояснює, що людина виграє і чим поступається.
Інформаційна архітектура
Що реалізовано в прототипі
Прототип зібраний у SwiftUI та працює без зовнішнього бекенду. Локальний стан зберігає онбординг, запити, дописи, вибрані товари й порівняння. Каталог містить дев’ять об’єктивів для Canon RF, Sony E та L-Mount.
Категорія, сумісність, фільтри за сценарієм, типом і бюджетом.
Шість типів структурованих дописів, прив’язаних до категорії або товару.
Порівняння двох або трьох товарів за характеристиками й trade-offs.
Детермінована рекомендація з поясненням збігів і обмежень.
03 — Демонстрація / UI / візуалізація
Наскрізний сценарій замість набору статичних екранів.
Нижче — місце для основних сценаріїв, коротких пояснень і відео. Кожен візуал має відповідати на конкретне питання, а не лише демонструвати polish.
Основні сценарії
Загальна карта інтерфейсу або 4–6 ключових екранів із короткими анотаціями.
Сумісність, фільтри та короткий список.
Причини збігу, переваги й компроміси.
Відео прототипу
Рекомендована тривалість: 60–120 секунд. Покажіть задачу, дію та реакцію системи; звук необов’язковий.