Source
iryna.ux | 5 ПОМИЛОК, ЧЕРЕЗ ЯКІ ПОРТФОЛІО НЕ ПОКАЗУЄ ВАШ РІВЕНЬВи набрали реакції...
317 Views/Reach
2026-07-29 13:49
Message №79
5 ПОМИЛОК, ЧЕРЕЗ ЯКІ ПОРТФОЛІО НЕ ПОКАЗУЄ ВАШ РІВЕНЬ
Ви набрали реакції 🔥 швидше, ніж я думала. Тримаю слово - розбираємо всі п’ять помилок (додала ще одну в процесі).❌ Помилка 1. Не видно проблеми, над якою ви працювали.
Часта помилка - формулювати задачу замість проблеми: наприклад “клієнт хотів редизайн”. Але клієнт майже ніколи не хоче редизайн просто так. Зазвичай за цим стоїть щось конкретне:→ низька конверсія;→ користувачі не розуміють, як виконати певну дію;→ багато звернень у підтримку;→ старий продукт не масштабується;→ змінилась аудиторія або бізнес-модель. Все починається з проблеми: як ви її зрозуміли → як приймали рішення → які були альтернативи → чому результат саме такий. Немає цього ланцюжка - немає product thinking.❌ Помилка 2. Research як перелік дій.
Класика behance-кейсів 😍: “Провела competitor research, зробила таблицю, зібрала скріни”. Але ❗️ дослідження не робиться заради дослідження. Усе має складатись у пазл:Клієнт каже “не приносить продажів” → інтерв'ю (у чому суть продукту, хто клієнти, що вони хочуть) → аналіз поточного рішення (де потреби клієнтів не закриваються чи ламаються) → аналіз конкурентів (як цю проблему вирішують інші) → відгуки (що болить користувачам) → формуємо сценарії використання → і лише тоді ідеї для рішення.Коли кожен крок логічно веде до наступного - ми бачимо дизайнера, який думає.
Коли це список галочок - ми бачимо виконавця.❌ Помилка 3. Wireframes заради wireframes.
Моє улюблене: спочатку роблять UI, потім перефарбовують у сірий і прибирають картинки - от тобі і ваєри. Зразу видно, що вони зроблені суто для кейсу. А мали б бути вашими першими сирими ідеями для кейсу, коли ви ще тільки продумуєте логіку.❌ Помилка 4. Галерея замість продуктових флоу.
Помилково вважають, що чим більше екранів додати в кейс - тим краще. Тому часто роблять полотно з фінальними екранами без будь-якої пріоритезації. В продуктових кейсах - нікого не хвилює екран з 2 полями реєстрації чи стандартний вигляд екрану налаштувань. Це, грубо кажучи, зробити найлегше. А от основний workflow вашого користувача і наскільки він зручний - хочеться побачити і зрозуміти. Бо це ж core продукту. Тому краще показувати екрани не статично переліком - а у вигляді логічного флоу (як би рухався користувач).❌ Помилка 5. Структура кейсу проти логіки процесу.
Коли етапи розкидані не по процесу.- Спочатку UI, потім clickable prototype. - Design system до wireframes. - Етапи йдуть не в тому порядку, в якому рішення приймаються насправді. Логіка процесу ламається. Підсумую. Проблема багатьох портфоліо не в тому, що роботи слабкі, а в тому що вони слабко показані і описані. Перевірте свій головний кейс за 5 пунктами: - видно проблему, а не задачу?- research веде до рішення, а не висить окремо?- wireframes - це ідеї, а не перефарбований UI?- екрани показані як флоу, а не галерея?- структура повторює логіку рішень?
👉 Якщо хоча б на 2 пунктах ви завагались - приходьте на консультацію (пишіть в дірект). Розберемо ваше портфоліо так само, як кейс Марії, і зробимо ваш рівень видимим.
Ви набрали реакції 🔥 швидше, ніж я думала. Тримаю слово - розбираємо всі п’ять помилок (додала ще одну в процесі).❌ Помилка 1. Не видно проблеми, над якою ви працювали.
Часта помилка - формулювати задачу замість проблеми: наприклад “клієнт хотів редизайн”. Але клієнт майже ніколи не хоче редизайн просто так. Зазвичай за цим стоїть щось конкретне:→ низька конверсія;→ користувачі не розуміють, як виконати певну дію;→ багато звернень у підтримку;→ старий продукт не масштабується;→ змінилась аудиторія або бізнес-модель. Все починається з проблеми: як ви її зрозуміли → як приймали рішення → які були альтернативи → чому результат саме такий. Немає цього ланцюжка - немає product thinking.❌ Помилка 2. Research як перелік дій.
Класика behance-кейсів 😍: “Провела competitor research, зробила таблицю, зібрала скріни”. Але ❗️ дослідження не робиться заради дослідження. Усе має складатись у пазл:Клієнт каже “не приносить продажів” → інтерв'ю (у чому суть продукту, хто клієнти, що вони хочуть) → аналіз поточного рішення (де потреби клієнтів не закриваються чи ламаються) → аналіз конкурентів (як цю проблему вирішують інші) → відгуки (що болить користувачам) → формуємо сценарії використання → і лише тоді ідеї для рішення.Коли кожен крок логічно веде до наступного - ми бачимо дизайнера, який думає.
Коли це список галочок - ми бачимо виконавця.❌ Помилка 3. Wireframes заради wireframes.
Моє улюблене: спочатку роблять UI, потім перефарбовують у сірий і прибирають картинки - от тобі і ваєри. Зразу видно, що вони зроблені суто для кейсу. А мали б бути вашими першими сирими ідеями для кейсу, коли ви ще тільки продумуєте логіку.❌ Помилка 4. Галерея замість продуктових флоу.
Помилково вважають, що чим більше екранів додати в кейс - тим краще. Тому часто роблять полотно з фінальними екранами без будь-якої пріоритезації. В продуктових кейсах - нікого не хвилює екран з 2 полями реєстрації чи стандартний вигляд екрану налаштувань. Це, грубо кажучи, зробити найлегше. А от основний workflow вашого користувача і наскільки він зручний - хочеться побачити і зрозуміти. Бо це ж core продукту. Тому краще показувати екрани не статично переліком - а у вигляді логічного флоу (як би рухався користувач).❌ Помилка 5. Структура кейсу проти логіки процесу.
Коли етапи розкидані не по процесу.- Спочатку UI, потім clickable prototype. - Design system до wireframes. - Етапи йдуть не в тому порядку, в якому рішення приймаються насправді. Логіка процесу ламається. Підсумую. Проблема багатьох портфоліо не в тому, що роботи слабкі, а в тому що вони слабко показані і описані. Перевірте свій головний кейс за 5 пунктами: - видно проблему, а не задачу?- research веде до рішення, а не висить окремо?- wireframes - це ідеї, а не перефарбований UI?- екрани показані як флоу, а не галерея?- структура повторює логіку рішень?
👉 Якщо хоча б на 2 пунктах ви завагались - приходьте на консультацію (пишіть в дірект). Розберемо ваше портфоліо так само, як кейс Марії, і зробимо ваш рівень видимим.