Прибуток:
- Здатність створювати швидкі прототипи скелетів, зразки вмісту та ідеї мікровзаємодії зі штучним інтелектом
- Можливість створити реалістичний текст і дані для прототипу та перевірити дизайн у реальному використанні
- Можливість підтримувати послідовність і логіку компонентів під час переміщення результатів ШІ в інструмент проектування (Figma тощо)
Прототип — це навігаційна імітація дизайну, яку можна натиснути; Це симуляція, яку користувач може відчути як у реальному продукті. З іншого боку, високоточний дизайн — це дизайн, який став ближчим до кінцевого продукту за допомогою кольору, типографіки, реального вмісту та мікровзаємодії. Мета на цьому етапі полягає в тому, щоб зробити ідею придатною для перевірки «так, ніби вона справжня». Штучний інтелект сильний тут у трьох аспектах: швидке створення скелетів і варіацій, надання реалістичного вмісту заповнювачів і даних і пропозиція ідей мікровзаємодії. Але підтримувати узгодженість і логіку компонентів під час переміщення результату в інструмент проектування, тобто вписувати систему в систему, не захаращуючи її, є людською роботою.
Призначення прототипу: дешево перевірити правильне запитання
Прототипування має одну мету: дешево перевірити припущення без написання коду. «Чи розуміє користувач цей потік?», «Чи прискорює цей макет його завдання?» Ось чому прототип не повинен бути таким же ідеальним, як реальний продукт; він просто має бути достатньо реальним, щоб переконливо відобразити питання, яке потрібно перевірити.
Штучний інтелект прискорює цю довіру. Але є небезпека: висока роздільна здатність здається «готовою». Коли зацікавлені сторони бачать відшліфований прототип, вони можуть прийняти це за остаточне рішення; Однак це поки що гіпотеза. Завжди чітко кажіть, що прототип тестує, а що ще відкрито.
Застереження: полірований прототип перебільшує зрілість. Якщо під час показу зацікавленій стороні ви не сформулюєте це як «це інструмент для тестування, а не остаточний дизайн; ми тестуємо це питання», виникне неправильне очікування.
Реалістичний зміст: порятунок прототипу від брехні
Найбільша брехня прототипу - це ідеальні заповнювачі, такі як "Lorem ipsum" і "Ім'я Прізвище". У реальному світі імена довгі, списки іноді порожні, числа іноді негативні, дати іноді застарілі. Коли прототип наповнений ідеальним змістом, він приховує реальні проблеми.
Саме тут ШІ є цінним: він створює реалістичний вміст заповнювачів і дані різної довжини та різного стану. Ви можете наблизити прототип до реального використання за допомогою таких запитів, як «Дайте мені 20 реалістичних назв продуктів, деякі з них дуже довгі», «Напишіть 5 різних порожніх сценаріїв», «Створіть зразки даних облікового запису, включаючи негативний баланс». Таким чином, тест перевіряє реальність, а не ідеал.
Тип вмісту
підробка (вводить в оману)
Реалістичний (зі штучним інтелектом)
Ім'я
"Ім'я Прізвище"
Приклади з короткими, довгими, одиночними назвами, спеціальними символами
Список
завжди повний
Бланк, варіанти з 1 елемента, 100 елементів
Номер
завжди позитивний
Нульові, негативні, дуже великі значення
текст
ідеальна довжина
Надмірна назва, дуже короткий опис
дата
сьогодні
Минуле, майбутнє, «щойно», «3 роки тому»
Мікровзаємодії: невеликі, але вирішальні
Мікровзаємодії — це невеликі окремі моменти взаємодії, такі як зворотний зв’язок, коли ви натискаєте кнопку, зелене поле після заповнення, анімація завантаження тощо. Це створює у користувача відчуття, що «система мене почула». ШІ є хорошим партнером для мозкового штурму для створення ідей мікровзаємодії (коли, який зворотній зв’язок, яка зміна стану). Але кожну мікровзаємодію необхідно зважити з точки зору ефективності, доступності та відволікання; химерна, але непотрібна анімація сповільнює процес.
три міні-чохла
Випадок 1 — згортання замовлення з реальними даними. Команда заповнила прототип 30 реалістичними (деякі дуже довгими) назвами продуктів, згенерованими ШІ. Два макети карт переповнені; Проблему було виявлено та виправлено перед тестуванням. Урок: реалістичний вміст рано виявляє приховані помилки.
Випадок 2 — відшліфований прототип викликав помилкові очікування. Дизайнер підготував прототип із високою роздільною здатністю для «тільки поточного тестування», але продемонстрував його зацікавленим сторонам без рамок. Зацікавлена сторона сказала «чудово, давайте опублікуємо»; тоді як доступності та контенту ще не існувало. Урок: чітко вкажіть, що тестує прототип.
Випадок 3 — узгодженість компонента порушена. Ескіз екрана від ШІ містив інший стиль кнопки, ніж кнопка в системі дизайну. Переносячи це на Figma, дизайнер забув прив’язати його до системного компонента; На виробі є дві різні кнопки. Урок: переміщуючи вихідні дані в інструмент, підключити його до наявних компонентів є обов’язковим.
Копіювані підказки
Створіть реалістичний вміст-заповнювач для цього екрана:- 20 імен <<типів елементів>>: деякі надто короткі, деякі надто довгі, один зі спеціальним символом.- 4 порожніх сценарію.- 3 екстремальних приклади даних (нульові, негативні, надмірні). Мета: перевірити прототип у реальному, а не ідеальному використанні. Контекст: <<екран/продукт>>
Запропонуйте скелет прототипу для цього потоку (список екранів + основні елементи на кожному екрані): Завдання: "<<завдання>>". Питання, яке я хочу перевірити: "<<гіпотеза>>". Запропонуйте стільки екранів, щоб перевірити це запитання; не додавайте більше.
Запропонуйте 4 ідеї мікровзаємодії для цієї взаємодії (натискання кнопки, перевірка поля, завантаження, успіх). Для кожного: ініціатор, відгук, пропозиція щодо тривалості та примітка щодо доступності (чутливість до руху, повідомлення програми зчитування з екрана). Контекст: <<взаємодія>>
Перевірте цей ескіз екрана на сумісність із моєю системою дизайну: чи відповідають кнопка, типографіка, інтервали та колір моїм існуючим правилам компонентів («<<резюме>>»). Перелічіть кожен несумісний елемент і до якого системного компонента його слід підключити. Чернетка: <<текст>>
Слабка підказка / Сильна підказка
Слабкий: «Надайте зразок вмісту для цього прототипу».
Результат: ідеальна довжина, однорідний, фейковий контент, який приховує справжні проблеми.
Сильно: «Створіть 20 назв продуктів; деякі надто довгі, одна зі спеціальним символом; додайте 4 порожні випадки та 3 приклади крайових даних; спробуйте перевірити прототип у реальному використанні».
Результат: вміст, який дійсно покращує макет, рано відкриваючи помилки.
Різниця: сильна підказка вимагає різноманітності + переваги + мети.
Поширені помилки
- Тестування з ідеальним контентом. Чудові заповнювачі приховують реальні проблеми.
- Помилково приймаючи відшліфований прототип як остаточне рішення. Якщо кадрування не зроблено, виникають помилкові очікування.
- Додавання непотрібного екрана. Прототип повинен бути достатнім для перевірки гіпотези; занадто багато - це марна трата часу.
- Порушення логіки компонентів. Якщо забути підключити компоненти системи під час транспортування їх до автомобіля, це призведе до невідповідності.
- Вигадлива, але непотрібна мікровзаємодія. Додавання анімації без урахування продуктивності та доступності.
Підсумовуючи
Прототипування — це спосіб дешево перевірити гіпотезу без написання коду; Висока роздільна здатність робить його правдоподібним, але також створює ілюзію «завершеності». AI забезпечує цей етап швидким скелетом, реалістичним вмістом-заповнювачем та ідеями мікровзаємодії. Його найціннішим внеском є різноманітні та екстремальні дані, які дозволяють перевірити прототип у реальному, а не ідеальному контексті. Людина зобов’язана чітко сформулювати те, що тестує прототип, зберігаючи узгодженість компонентів і стилів під час перенесення результату в інструмент проектування.
Аплікаційне завдання
- Напишіть одне речення гіпотези, яке ви хочете перевірити на наявність потоку.
- За допомогою другої підказки створіть прототип скелета, достатній для перевірки цієї гіпотези.
- За допомогою першої підказки створіть реалістичний вміст-заповнювач у крайньому регістрі та заповніть прототип.
- За допомогою третьої підказки створіть 2-3 ідеї мікровзаємодії та оцініть примітки щодо доступності.
- За допомогою четвертої підказки перевірте та виправте проект на узгодженість системи дизайну.
контрольний список
- [ ] Я чітко написав гіпотезу, яку тестує прототип.
- [ ] Я тестував із реалістичним вмістом у регістрі.
- [ ] Я створив прототип як «інструмент тестування» для зацікавлених сторін.
- [ ] Я зберіг кількість екранів, достатню для перевірки гіпотези.
- [ ] Я зважив мікровзаємодії з доступністю та продуктивністю.
- [ ] Я підтримував послідовність, прив’язуючи вихідні дані до компонентів системи.