Wśród wielu użytkowników biznesowych i klientów istnieje ogólna koncepcja, że kiedy wygląda na kompletną, jest prawie kompletna. Jak zapewne wiesz, jest to dalekie od prawdy. Można go ładnie wyglądać, ale bez zaplecza, a niektórzy użytkownicy uważają, że poprawienie wyglądu to 80% pracy, a nie 20% ( lub inne 80% ).
Niezliczeni programiści mogą opowiedzieć o tym horrory - wykonanie makiety stron wykonanych w programie Microsoft Word przy użyciu zrzutów ekranu z innego narzędzia, a klient mówi „tak, prawie już to zrobiłeś?”
Musisz go przyspieszyć, aby wszystkie części zostały wykonane po zakończeniu. Próba wykonania najpierw całego backendu, a następnie całego frontonu spowoduje, że użytkownik końcowy pomyśli, że nic nie robisz, i zapyta, dlaczego otrzymujesz zapłatę, gdy nie ma nic do pokazania. Z drugiej strony, front-end pierwszy, a zobaczysz, że użytkownik końcowy wprowadza drobne zmiany i pochłania cały nasz czas.
Najgorszy przypadek z „pierwszym i drugim” jest, gdy przejdziesz do drugiej części, okaże się, że w ogóle nie pasuje do projektu.
Zatem zbuduj oba. Pokaż postępy w interfejsie, spraw, aby zaplecze działało z tym, co budujesz. W wielu przypadkach dobrym pomysłem jest dostarczanie przyrostowych kompilacji i upewnianie się, że robisz to, czego chce klient (staje się to zwinne). Zbyt długi czas bez „widocznych postępów” może zaszkodzić relacjom z klientem (dotyczy to zarówno przypadków „wszystko wygląda na zrobione wcześnie”, jak i „nic się nie robi do samego końca” - klientowi trudno jest napisać framework lub testy jednostkowe lub czyszczenie danych jako postęp).
Joel napisał o tym w The Iceberg Secret, Revealed :
Ważny wniosek drugi. Jeśli pokażesz programatorowi ekran z interfejsem użytkownika, który jest w 100% piękny, pomyślą, że program jest prawie gotowy.
Ludzie, którzy nie są programistami, patrzą tylko na ekran i widzą niektóre piksele. A jeśli piksele wyglądają tak, jakby tworzyły program, który coś robi, myślą „o rany, o ile trudniej byłoby sprawić, żeby faktycznie działało?”
Duże ryzyko polega na tym, że jeśli najpierw wyśmiejesz interfejs użytkownika, prawdopodobnie po to, aby porozmawiać z klientem, wszyscy będą myśleć, że prawie skończyłeś. A potem, kiedy spędzisz kolejny rok pracując „pod przykryciem”, że tak powiem, nikt tak naprawdę nie zobaczy tego, co robisz, i będą myśleć, że to nic.
Jest to powtórzone w poście na blogu. Nie zmieniaj wersji demonstracyjnej w Gotową, która ma ten pomocny wykres:
Zauważ tutaj, że dwie opcje ogólnie odzwierciedlają „załatwienie interfejsu użytkownika” (a następnie oczekuje się, że wkrótce skończysz) i „załatwienie zaplecza” (a wtedy klient martwi się, że nie dotrzymasz terminu).
Jak „zrobione” coś wygląda, powinno pasować do tego, jak „zrobione” jest coś.
Każdy programista doświadczył tego wiele razy w swojej karierze. Ale narzędzia do publikowania na komputerze powodują ten sam ból głowy dla pisarzy technicznych - jeśli pokażesz komuś szorstki szkic, który jest idealnie sformatowany i sformatowany, widzą, że jest to więcej zrobione niż chcesz. Potrzebujemy dopasowania między tym, gdzie jesteśmy, a tym, gdzie inni nas postrzegają.
W tym artykule poruszono także ważną kwestię na temat rodzaju informacji zwrotnych otrzymywanych przy różnych poziomach zaawansowania interfejsu użytkownika. Jeśli masz coś, co wygląda na ukończone, bardziej prawdopodobne jest uzyskanie opinii na temat „czy możesz zmienić czcionkę” niż „ten układ nie działa - istnieje zbyt wiele zakładek”.
Dla tych, którzy walczą z tym w świecie Java Swing, istnieje wygląd i styl nazywany Napkin, który sprawia, że interfejs użytkownika nie wygląda na kompletny (nawet jeśli tak jest).
Kluczem tutaj jest sprawienie, aby nie wyglądało na zrobione. Ukończenie interfejsu użytkownika jest sygnałem dla wielu użytkowników biznesowych, że aplikacja jest kompletna (nawet jeśli jest to tylko kilka statycznych stron bez logiki lub coś wbudowanego w narzędzie do tworzenia interfejsów).
Dalsza lektura (i linki z artykułu):
