Печалби:
- Възможност за създаване на бързи прототипни скелети, примерно съдържание и идеи за микро взаимодействие с изкуствен интелект
- Възможност за създаване на реалистичен текст и данни за прототипа и тестване на дизайна в реална употреба
- Възможност за поддържане на последователност и логика на компонентите при преместване на AI изход към инструмент за проектиране (Figma и др.)
Прототипът е имитация на дизайн с възможност за щракване и навигация; Това е симулация, която потребителят може да изпита като в истинския продукт. Високопрецизният дизайн, от друга страна, е дизайн, който се е доближил до крайния продукт с цвят, типография, реално съдържание и микро взаимодействия. Целта на този етап е идеята да бъде тествана „като че ли е истинска“. AI е силен тук по три начина: бързо създаване на скелети и вариации, предоставяне на реалистично съдържание и данни за контейнери и предлагане на идеи за микровзаимодействие. Но поддържането на последователност и логиката на компонентите при преместване на изхода в инструмента за проектиране – тоест поставянето на системата в системата, без да я претрупвате – е човешка работа.
Целта на прототипа: евтино да се тества правилният въпрос
Създаването на прототипи има една цел: да тества евтино предположение, без да пише код. „Потребителят разбира ли този поток?“, „Това оформление ускорява ли задачата му?“ Ето защо прототипът не трябва да бъде толкова перфектен, колкото реалния продукт; просто трябва да е достатъчно истинско, за да изобрази убедително въпроса, който ще се тества.
Изкуственият интелект ускорява тази достоверност. Но има опасност: високата разделителна способност се чувства „готова“. Когато заинтересованите страни видят полиран прототип, те могат да го объркат с окончателното решение; Все още обаче е хипотеза. Винаги казвайте ясно какво тества прототипът и какво все още е отворено.
Внимание: Полираният прототип преувеличава зрелостта. Ако не го формулирате като „това е тестов инструмент, а не окончателният дизайн; ние тестваме този въпрос“, когато го показвате на заинтересованата страна, ще се създаде погрешно очакване.
Реалистично съдържание: спасяване на прототипа от лъжата
Най-голямата лъжа на прототипа са перфектните контейнери като „Lorem ipsum“ и „Име Фамилия“. В реалния свят имената са дълги, списъците понякога са празни, числата понякога са отрицателни, датите понякога са остарели. Когато прототипът е изпълнен с идеално съдържание, той крие реални проблеми.
Това е мястото, където AI е ценен: той създава реалистично съдържание и данни с различна дължина, различни състояния. Можете да доближите прототипа до реалната употреба с искания като „Дайте ми 20 реалистични имена на продукти, някои от тях много дълги“, „Напишете 5 различни сценария за празни случаи“, „Създайте примерни данни за акаунта, включително отрицателен баланс“. Така тестът тества реалността, а не идеала.
Тип съдържание
фалшив (подвеждащ)
Реалистичен (с изкуствен интелект)
Име
"Име Фамилия"
Примери с кратки, дълги, единични имена, специални знаци
списък
винаги пълен
Празни, варианти от 1 елемент, 100 елемента
Номер
винаги положителен
Нула, отрицателни, много големи стойности
текст
идеална дължина
Преливащо заглавие, много кратко описание
дата
днес
Минало, бъдеще, "току-що", "преди 3 години"
Микро взаимодействия: малки, но решаващи
Микровзаимодействията са малки, единични моменти на взаимодействие, като например обратна връзка, когато натиснете бутон, поле, което става зелено, когато е запълнено, анимация за зареждане и т.н. Те създават усещането на потребителя, че „системата ме чу“. AI е добър партньор за мозъчна атака за генериране на идеи за микровзаимодействие (кога, каква обратна връзка, каква промяна на състоянието). Но всяко микровзаимодействие трябва да бъде претеглено по отношение на производителност, достъпност и разсейване; фантастичната, но ненужна анимация забавя изживяването.
три мини калъфа
Случай 1 — Свиване на поръчка с реални данни. Екип запълни прототипа с 30 реалистични (някои много дълги) имена на продукти, генерирани от AI. Две оформления на карти са препълнени; Проблемът беше уловен и отстранен преди тестването. Поука: реалистичното съдържание разкрива скритите грешки рано.
Случай 2 — Полираният прототип създаде фалшиви очаквания. Дизайнер подготви прототип с висока разделителна способност за „само тестване на потока“, но го показа на заинтересованите страни без рамка. Заинтересованата страна каза „супер, нека го публикуваме“; като има предвид, че достъпността и съдържанието все още не съществуват. Урок: ясно посочете какво тества прототипът.
Случай 3 — Консистенцията на компонента е нарушена. Екранната скица от AI съдържаше различен стил на бутон от бутона в системата за проектиране. Когато пренася това към Figma, дизайнерът е забравил да го свърже със системния компонент; На продукта има два различни бутона. Урок: когато премествате изхода в инструмента, свързването му със съществуващи компоненти е задължително.
Копируеми подкани
Генерирайте реалистично заместващо съдържание за този екран:- 20 имена на <<типове елементи>>: някои твърде къси, някои твърде дълги, едно със специален знак.- 4 празни сценария.- 3 крайни примера за данни (нула, отрицателни, прекалено големи).Цел: да се тества прототипа с реална, а не идеална употреба.Контекст: <<екран/продукт>>
Предложете прототип на скелет за този поток (списък с екрани + основни елементи във всеки екран): Задача: "<<задача>>". Въпросът, който искам да тествам, е: "<<хипотеза>>". Предложете достатъчно екрани, за да тествате този въпрос; не добавяйте повече.
Предложете 4 идеи за микровзаимодействие за това взаимодействие (натискане на бутон, проверка на полето, зареждане, успех). За всеки: тригер, обратна връзка, предложение за продължителност и бележка за достъпност (чувствителност към движение, съобщение за екранен четец). Контекст: <<взаимодействие>>
Проверете тази екранна скица за съвместимост с моята система за проектиране: отговарят ли бутонът, типографията, разстоянието и цветът на моите съществуващи правила за компоненти („<<резюме>>“). Избройте всеки елемент, който е несъвместим и към кой системен компонент трябва да бъде свързан. Чернова: <<текст>>
Слаба подкана / Силна подкана
Слаб: „Дайте примерно съдържание за този прототип.“
Резултатът: идеална дължина, еднообразно, фалшиво съдържание, което крие истински проблеми.
Силно: „Генерирайте 20 имена на продукти; някои са твърде дълги, едно със специален знак; добавете 4 празни случая и 3 примера за крайни данни; целта е да тествате прототипа с реална употреба.“
Резултатът: Съдържание, което наистина подобрява оформлението, отваряйки бъгове рано.
Разликата: силното подканяне изисква разнообразие + краен случай + цел.
Често срещани грешки
- Тестване с идеално съдържание. Страхотните заместители крият истински проблеми.
- Сбъркайки полирания прототип като крайно решение. Ако рамкирането не е направено, възникват фалшиви очаквания.
- Добавяне на ненужен екран. Прототипът трябва да е достатъчен за проверка на хипотезата; твърде много е загуба на време.
- Нарушаване на логиката на компонента. Ако забравите да свържете компонентите на системата, когато ги транспортирате до превозното средство, това ще доведе до несъответствие.
- Изискано, но ненужно микровзаимодействие. Добавяне на анимация без отчитане на производителността и достъпността.
В обобщение
Прототипирането е начин за евтино тестване на хипотеза без писане на код; Високата разделителна способност го прави правдоподобен, но също така създава илюзията за "завършен". AI захранва този етап с бърз скелет, реалистично съдържание и идеи за микровзаимодействие. Неговият най-ценен принос са разнообразните и екстремни данни, които ви позволяват да тествате прототипа с реален, а не идеален контекст. Човешка отговорност е ясно да рамкира това, което прототипът тества, като поддържа последователност на компонентите и стила, когато премества изхода в инструмента за проектиране.
Задача за приложение
- Напишете едно изречение с хипотеза, което искате да тествате за поток.
- С втората подкана създайте прототип на скелет, достатъчен за тестване на тази хипотеза.
- С първото подканяне създайте реалистично съдържание за контейнер за крайни букви и попълнете прототипа.
- С третата подкана генерирайте 2-3 идеи за микро взаимодействие и оценете бележките за достъпност.
- С четвъртата подкана проверете и коригирайте черновата за последователност на проектната система.
контролен списък
- [ ] Написах ясно хипотезата, която прототипът тества.
- [ ] Тествах с реалистично и крайно съдържание.
- [ ] Очертах прототипа като „инструмент за тестване“ за заинтересованите страни.
- [ ] Запазих броя на екраните достатъчно, за да тествам хипотезата.
- [ ] Претеглих микровзаимодействията спрямо достъпността и производителността.
- [ ] Поддържах последователност, като обвързвах изхода към системните компоненти.