Ciekawy plik. Fajnie zobaczyć jak ktoś inny pracuje. U mnie proces wygląda inaczej, bo nierzadko jest tak że pracuję nadal nad projektem równolegle z developmentem. W samym projekcie ekrany układam w siatce, w pionie są ułożone osobne ekrany, a w poziomie ich warianty co też czasami jest równoznaczne z flow. Starałam się żeby niczego nie trzeba było opisywać, albo naprawdę mało, żeby nikt tego nie musiał czytać ;) dodatkowo tego typu handoff działa głównie przy nowych produktach lub bardzo wydzielonej części systemu która wymaga poprawy. Jako ux zawsze naciskam żeby być podczas developmentu dlatego że nieraz trzeba projektować pośrednie iteracje, bo nagle wyskoczą jakieś problemy techniczne itp. Z doświadczenia wiem, że pozostawienie tego programistom czy pmowi kończy się często bardzo źle dla usera, bo podejmują oni decyzje które są wygodne przede wszystkim dla nich i bez wiedzy o ux a czasami też bez perspektywy całości aplikacji, bo w kodzie jest to inaczej rozdzielone niż w kontekście architektury dla użytkownika albo domenowej. Przedwczoraj np miałam dyskusję z programistą czemu nie można wrzucić ustawień podobnych do siebie (nadawanie roli) do tej samej grupy menu. Dla niego to było jedno i to samo, a od strony użytkownika i jego flow, dotyczyły one kompletnie innych obszarów (pierwsze zarządzania profilem w aplikacji, a drugie ustawianiem już parametrów domenowych które muszą być oddzielone na wyłączność bo później będą bazą dla wizarda - gdyby było tak jak chciał to w samouczku/wizardzie dotyczącym wpisywania celów biznesowych user dostawałby opcję nadania admina userom w aplikacji 😅 co i tak w ogóle będzie edge casem żeby było więcej niż on sam). On tego nie przeskoczył i twierdzi że to "zły ux" żeby to rozdzielić 😅 Ja rozumiem jego perspektywę ale on mojej niestety nie, bo nie myśli kategoriami użytkowania aplikacji, tylko porządkowania i etykietowania podobnych do siebie elementów. Gdyby mu to zostawić to w pierwszej iteracji po prostu by zrobił te ustawienia tak jak mu pasuje. Dlatego wolę to wszystko narysować po kolei jak ma być wdrażane. Zresztą pomaga to też w estymacjach i robieniu taskow. Minusem jest to że trzeba rozumieć jak wygląda programowanie w danej technologii albo mieć jednego programistę do stałego kontaktu.
Z wersjami ekranów i feedbackiem też są dobre historie. Bardzo często ekran ktory miał wyglądać jak w figme, po implementacji oraz wczesnego feedbacku od użytkowników wyglada zupełnie inaczej 🤷🏻♀️
Bardzo fajny plik!
Ciekawy plik. Fajnie zobaczyć jak ktoś inny pracuje.
U mnie proces wygląda inaczej, bo nierzadko jest tak że pracuję nadal nad projektem równolegle z developmentem. W samym projekcie ekrany układam w siatce, w pionie są ułożone osobne ekrany, a w poziomie ich warianty co też czasami jest równoznaczne z flow. Starałam się żeby niczego nie trzeba było opisywać, albo naprawdę mało, żeby nikt tego nie musiał czytać ;) dodatkowo tego typu handoff działa głównie przy nowych produktach lub bardzo wydzielonej części systemu która wymaga poprawy.
Jako ux zawsze naciskam żeby być podczas developmentu dlatego że nieraz trzeba projektować pośrednie iteracje, bo nagle wyskoczą jakieś problemy techniczne itp. Z doświadczenia wiem, że pozostawienie tego programistom czy pmowi kończy się często bardzo źle dla usera, bo podejmują oni decyzje które są wygodne przede wszystkim dla nich i bez wiedzy o ux a czasami też bez perspektywy całości aplikacji, bo w kodzie jest to inaczej rozdzielone niż w kontekście architektury dla użytkownika albo domenowej. Przedwczoraj np miałam dyskusję z programistą czemu nie można wrzucić ustawień podobnych do siebie (nadawanie roli) do tej samej grupy menu. Dla niego to było jedno i to samo, a od strony użytkownika i jego flow, dotyczyły one kompletnie innych obszarów (pierwsze zarządzania profilem w aplikacji, a drugie ustawianiem już parametrów domenowych które muszą być oddzielone na wyłączność bo później będą bazą dla wizarda - gdyby było tak jak chciał to w samouczku/wizardzie dotyczącym wpisywania celów biznesowych user dostawałby opcję nadania admina userom w aplikacji 😅 co i tak w ogóle będzie edge casem żeby było więcej niż on sam). On tego nie przeskoczył i twierdzi że to "zły ux" żeby to rozdzielić 😅 Ja rozumiem jego perspektywę ale on mojej niestety nie, bo nie myśli kategoriami użytkowania aplikacji, tylko porządkowania i etykietowania podobnych do siebie elementów. Gdyby mu to zostawić to w pierwszej iteracji po prostu by zrobił te ustawienia tak jak mu pasuje.
Dlatego wolę to wszystko narysować po kolei jak ma być wdrażane. Zresztą pomaga to też w estymacjach i robieniu taskow. Minusem jest to że trzeba rozumieć jak wygląda programowanie w danej technologii albo mieć jednego programistę do stałego kontaktu.
Z wersjami ekranów i feedbackiem też są dobre historie. Bardzo często ekran ktory miał wyglądać jak w figme, po implementacji oraz wczesnego feedbacku od użytkowników wyglada zupełnie inaczej 🤷🏻♀️
Nie udaje mi się pobrać z kodem 😥
Spróbuj odświeżyć i kod jest z małych liter 😉
Jak to powinno być płatne choć te 5$. Coś ci tam rzucę :)