Zyski:
- Możliwość tworzenia szybkich prototypowych szkieletów, przykładowych treści i pomysłów na mikrointerakcje ze sztuczną inteligencją
- Możliwość tworzenia realistycznego tekstu zastępczego i danych dla prototypu oraz testowania projektu w rzeczywistym użyciu
- Możliwość zachowania spójności i logiki komponentów podczas przenoszenia wyników AI do narzędzia projektowego (Figma itp.)
Prototyp to klikalna imitacja projektu, po której można nawigować; Jest to symulacja, której użytkownik może doświadczyć tak, jak w prawdziwym produkcie. Z kolei projektowanie wysokiej jakości to projektowanie, które zbliżyło się do produktu końcowego pod względem koloru, typografii, prawdziwej treści i mikrointerakcji. Celem na tym etapie jest umożliwienie testowania pomysłu „tak, jakby był prawdziwy”. Sztuczna inteligencja jest tutaj silna na trzy sposoby: szybkie tworzenie szkieletów i odmian, dostarczanie realistycznych treści i danych zastępczych oraz sugerowanie pomysłów na mikrointerakcję. Jednak utrzymanie spójności i logiki komponentów podczas przenoszenia wyników do narzędzia projektowego — czyli dopasowywanie systemu do systemu bez zaśmiecania go — jest zadaniem człowieka.
Cel prototypu: tanie przetestowanie właściwego pytania
Prototypowanie ma jeden cel: tanie przetestowanie założeń, bez pisania kodu. „Czy użytkownik rozumie ten przepływ?”, „Czy taki układ przyspiesza jego zadanie?” Dlatego prototyp nie musi być tak doskonały jak prawdziwy produkt; musi być po prostu na tyle realny, aby w przekonujący sposób przedstawić pytanie, które ma zostać przetestowane.
Sztuczna inteligencja przyspiesza tę wiarygodność. Istnieje jednak niebezpieczeństwo: wysoka rozdzielczość wydaje się „skończona”. Kiedy interesariusze zobaczą dopracowany prototyp, mogą pomylić go z ostateczną decyzją; Jest to jednak nadal hipoteza. Zawsze jasno mów, co prototyp testuje, a co jest jeszcze otwarte.
Uwaga: Wypolerowany prototyp przesadnie dojrzały. Jeśli nie ująsz tego w sformułowanie „to narzędzie testowe, a nie ostateczny projekt; testujemy to pytanie”, pokazując je interesariuszowi, wzbudzą błędne oczekiwania.
Realistyczna treść: uratowanie prototypu przed kłamstwem
Największym kłamstwem prototypu są idealne symbole zastępcze, takie jak „Lorem ipsum” i „Imię Nazwisko”. W prawdziwym świecie nazwy są długie, listy czasami puste, liczby czasami ujemne, a daty czasami nieaktualne. Kiedy prototyp jest wypełniony idealną treścią, kryje w sobie prawdziwe problemy.
W tym miejscu cenna jest sztuczna inteligencja: tworzy realistyczne treści zastępcze i dane o różnej długości i różnych stanach. Możesz przybliżyć prototyp do rzeczywistego użycia, prosząc o prośby typu „Podaj 20 realistycznych nazw produktów, niektóre z nich bardzo długie”, „Napisz 5 różnych scenariuszy pustych przypadków”, „Wygeneruj przykładowe dane konta, w tym saldo ujemne”. Test sprawdza zatem rzeczywistość, a nie ideał.
Typ treści
fake (misleading)
Realistyczny (ze sztuczną inteligencją)
Imię
„Imię Nazwisko”
Przykłady z krótkimi, długimi, pojedynczymi nazwami, znakami specjalnymi
Lista
zawsze pełny
Puste, 1 element, 100 elementów
Numer
zawsze pozytywne
Zero, negative, very large values
tekst
idealna długość
Przesadny tytuł, bardzo krótki opis
data
dzisiaj
Przeszłość, przyszłość, „właśnie teraz”, „3 lata temu”
Mikrointerakcje: małe, ale zdecydowane
Mikrointerakcje to małe, pojedyncze momenty interakcji, takie jak informacja zwrotna po naciśnięciu przycisku, zielone pole po wypełnieniu, animacja ładowania itp. Tworzą one odczucie użytkownika, że „system mnie usłyszał”. Sztuczna inteligencja jest dobrym partnerem do burzy mózgów przy generowaniu pomysłów na mikrointerakcję (kiedy, jakie informacje zwrotne, jaka zmiana stanu). Jednak każdą mikrointerakcję należy rozważyć pod kątem wydajności, dostępności i rozpraszania; fantazyjne, ale niepotrzebne animacje spowalniają doświadczenie.
trzy mini etui
Przypadek 1 — Załamanie zamówienia przy danych rzeczywistych. Zespół wypełnił prototyp 30 realistycznymi (niektóre bardzo długimi) nazwami produktów wygenerowanymi przez sztuczną inteligencję. Przepełnione dwa układy kart; Problem został wykryty i naprawiony przed testowaniem. Lekcja: realistyczna treść wcześnie odkrywa ukryte błędy.
Przypadek 2 — Dopracowany prototyp wywołał fałszywe oczekiwania. Projektant przygotował prototyp w wysokiej rozdzielczości „tylko do testowania przepływu”, ale pokazał go zainteresowanym stronom bez kadrowania. Zainteresowana osoba powiedziała „świetnie, opublikujmy to”; mając na uwadze, że dostępność i treść jeszcze nie istniały. Lekcja: jasno określ, co testuje prototyp.
Przypadek 3 — Zerwana jest spójność komponentów. Szkic ekranu z AI zawierał inny styl przycisku niż przycisk w systemie projektowania. Podczas przenoszenia tego do Figmy projektant zapomniał połączyć to z komponentem systemu; Na produkcie znajdują się dwa różne przyciski. Lekcja: podczas przenoszenia danych wyjściowych do narzędzia konieczne jest podłączenie ich do istniejących komponentów.
Monity, które można kopiować
Wygeneruj realistyczną zawartość zastępczą dla tego ekranu: - 20 nazw <<typ elementu>>: niektóre za krótkie, niektóre za długie, jedna ze znakiem specjalnym. - 4 scenariusze pustych przypadków. - 3 skrajne przykłady danych (zero, ujemne, przewymiarowane). Cel: przetestowanie prototypu w rzeczywistym, a nie idealnym użytkowaniu. Kontekst: <<ekran/produkt>>
Propose prototype skeleton for this flow (screen list + main elements in each screen):Task: "<<task>>". Pytanie, które chcę przetestować, brzmi: „<<hipoteza>>”. Zaproponuj wystarczającą liczbę ekranów, aby przetestować to pytanie; nie dodawaj więcej.
Zaproponuj 4 pomysły na mikrointerakcję dla tej interakcji (naciśnięcie przycisku, weryfikacja w terenie, ładowanie, sukces). Dla każdego: wyzwalacz, informacja zwrotna, sugestia czasu trwania i informacja o dostępności (czułość ruchu, komunikat czytnika ekranu). Kontekst: <<interakcja>>
Sprawdź ten szkic ekranu pod kątem zgodności z moim systemem projektowania: czy przycisk, typografia, odstępy i kolor są zgodne z moimi istniejącymi zasadami dotyczącymi komponentów („<<podsumowanie>>”). Wypisz każdy element, który jest niezgodny i do którego komponentu systemu powinien być podłączony. Wersja robocza: <<tekst>>
Słaba zachęta/silna zachęta
Słabe: „Podaj przykładową treść tego prototypu”.
Rezultat: idealna długość, jednolita, fałszywa treść, która ukrywa prawdziwe problemy.
Strong: „Wygeneruj 20 nazw produktów; niektóre za długie, jedną ze znakiem specjalnym; dodaj 4 puste skrzynki i 3 przykłady danych brzegowych; staraj się przetestować prototyp w rzeczywistym użyciu.”
Rezultat: treść, która naprawdę popycha układ i wcześnie wykrywa błędy.
Różnica: silna zachęta wymaga różnorodności + przypadku + celu.
Typowe błędy
- Testowanie z idealną treścią. Świetne symbole zastępcze ukrywają prawdziwe problemy.
- Uznanie dopracowanego prototypu za ostateczną decyzję. Jeśli nie zostanie dokonane kadrowanie, pojawią się fałszywe oczekiwania.
- Dodanie niepotrzebnego ekranu. Prototyp powinien wystarczyć do sprawdzenia hipotezy; za dużo to strata czasu.
- Łamanie logiki komponentów. Zapomnienie o podłączeniu elementów systemu podczas transportu ich do pojazdu spowoduje niespójność.
- Fantazyjna, ale niepotrzebna mikrointerakcja. Dodawanie animacji bez uwzględnienia wydajności i dostępności.
Podsumowując
Prototypowanie to sposób na tanie przetestowanie hipotezy bez pisania kodu; Wysoka rozdzielczość uwiarygodnia obraz, ale jednocześnie stwarza iluzję „skończenia”. Sztuczna inteligencja napędza ten etap dzięki szybkiemu szkieletowi, realistycznym treściom zastępczym i pomysłom na mikrointerakcję. Jego najcenniejszym wkładem są różnorodne i ekstremalne dane, które pozwalają przetestować prototyp w rzeczywistym, a nie idealnym kontekście. Obowiązkiem człowieka jest jasne określenie tego, co testuje prototyp, utrzymanie spójności komponentów i stylu podczas przenoszenia wyników do narzędzia projektowego.
Zadanie aplikacji
- Napisz jedno zdanie z hipotezą, które chcesz przetestować pod kątem przepływu.
- Za pomocą drugiego monitu utwórz szkielet prototypu wystarczający do przetestowania tej hipotezy.
- Po wyświetleniu pierwszego monitu utwórz realistyczną zawartość zastępczą typu Edge i wypełnij prototyp.
- Po wyświetleniu trzeciego monitu wygeneruj 2–3 pomysły na mikrointerakcje i oceń uwagi dotyczące dostępności.
- Po czwartym pytaniu sprawdź i popraw wersję roboczą pod kątem spójności systemu projektowego.
lista kontrolna
- [ ] Napisałem jasno hipotezę, że prototyp testuje.
- [ ] Testowałem z realistyczną i ekstremalną zawartością obudowy.
- [ ] Stworzyłem prototyp jako „narzędzie testowe” dla interesariusza.
- [ ] Zachowałem wystarczającą liczbę ekranów, aby przetestować hipotezę.
- [ ] Porównałem mikrointerakcje z dostępnością i wydajnością.
- [ ] I maintained consistency by binding the output to system components.