Można łatwo opisać nową funkcję. Jest ona dostępna na mapie drogowej, otrzymuje nazwę i może być wyświetlana w prezentacji. Wartość pominiętej funkcji jest trudniejsza do wyświetlenia. Nikt nie widzi na pierwszy rzut oka, jakie dodatkowe menu, pola danych, stany błędów i przypadki wsparcia nie powstały świadomie.
Dlatego oprogramowanie często rozwija się w kierunku, który wydaje się wiarygodny: jeśli aplikacja może być bardziej przydatna, powinna być bardziej wartościowa. W praktyce nie jest to automatyczne. Aplikacja jest w stanie zaoferować dwadzieścia funkcji, a mimo to nie spełnia jednego z zadań, dla których została otwarta. Z drugiej strony, małe narzędzie może stać się niezbędne, jeśli jego podstawowy przebieg działa szybko, zrozumiale i niezawodnie.
Skupianie się na produkcie nie oznacza powstrzymywania pomysłów ani sztucznego utrzymywania aplikacji na małą skalę. Oznacza to pomiar każdego rozszerzenia na wyraźnej korzyści, łącznie z kosztami poniesionymi po wyświetleniu ekranu.
Jakość jest widoczna w rozwiązanej sprawie
Ludzie rzadko ściągają aplikację, ponieważ posiada określoną liczbę funkcji. Chcesz pokazać bilet, przechwycić wyjście, znaleźć dokument, zaplanować spotkanie lub znaleźć informacje. Dlatego też najważniejszą miarą nie jest lista funkcji, lecz pełna droga do rozsądnego rezultatu.
Przyjrzyjmy się prostej aplikacji alarmowej. Do jej rdzenia wystarczy zrozumiały tytuł, termin płatności, status i niezawodne powiadomienie. Matryca priorytetowa, role zespołu, czaty, rejestrowanie czasu i automatyczne sugestie tekstowe mogą być użyteczne, ale tylko dla innych lub rozszerzonych zadań. Jeżeli są one uzupełniane bez jasnego scenariusza użytkowania, konkurują one na tej samej powierzchni z rzeczywistym celem.
W związku z tym skoncentrowany produkt rozpoczyna się od trzech pytań: kto go używa? W jakiej sytuacji? Jaki wynik powinien być lepszy niż wcześniej? nie odpowiada na żadne z tych pytań dla tych, którzy chcą być bardziej produktywni?
Każda funkcja rozszerza cały system
Nowy przycisk rzadko jest tylko nowym przyciskiem. Za nim powstają dane, stany, uprawnienia i zależności. Na przykład funkcja eksportu wymaga wyboru, formatu plików, przetwarzania błędów, dialogów pamięci lub udostępniania danych, decyzji dotyczących ochrony danych i testów na wielu wersjach systemu operacyjnego. Musi ona obejść się z kolejnymi zmianami w modelu danych i być opisana w sposób zrozumiały w pomocy.
Podobnie jest w przypadku kont i synchronizacji. Widoczne logowanie jest tylko początkiem. Do tego należy dodawać zarządzanie tożsamością, przywracanie, rozwiązywanie konfliktów, działanie serwera, środki bezpieczeństwa, procesy usuwania i wsparcie dla zagubionych wejść. Wszystko to może być konieczne dla produktu współpracy. Ta sama architektura bez międzyobsługowej pracy może być bardzo uciążliwa.
Przewodnik Android do architektury aplikacji zaleca jasne ograniczenia odpowiedzialności, jasne źródło danych i możliwie najniższą integrację. Zasady te mają na celu utrzymanie trwałości, ale jednocześnie pokazują prawdę o produkcie: im więcej współzależnych umiejętności zawiera system, tym więcej związków trzeba zrozumieć i utrzymywać na stałe.
Przejrzystość rodzi się również dzięki uniknięciu
Zrozumiała powierzchnia daje ludziom wskazówki bez konieczności myślenia o ich obsłudze. Wizualna hierarchia, spójność i znane wzory platformy pomagają w tym. Wytyczne Apple Interface Human podkreślają dokładnie te aspekty. Łatwiej je wdrożyć, gdy widzialne zadanie jest widoczne.
Przeciążenie funkcji często nie jest widoczne jako oczywisty chaos. Zaczyna się od małych decyzji: jeszcze jeden symbol na pasku nawigacyjnym, jeden filtr za menu, jeszcze jeden status na liście. Każdy dodatek może wyglądać rozsądnie indywidualnie, ale razem zwiększają liczbę decyzji, które muszą zostać podjęte przed właściwym uchwytem.
Na smartfonie efekt ten jest szczególnie widoczny. Miejsce jest ograniczone, często przerywane, a uwaga nie zawsze jest niepodzielna. Kto stoi w piwnicy przed licznikiem lub szuka informacji o rezerwacji, potrzebuje solidnego działania, a nie demonstracji całego produktu. Dobra powierzchnia mobilna priorytetuje następny sensowny krok, przesuwając rzadko potrzebne opcje bez ich ukrycia.
Ściślejszy rozmiar nie zmniejsza błędów automatycznie w zależności od celu
Małe oprogramowanie nie jest samo w sobie niezawodne. Nawet jedna funkcja może być źle zaprojektowana lub niedostatecznie przetestowana. Ograniczony zakres funkcji stwarza jednak lepsze warunki do dokładnego rozpatrywania ważnych spraw.
Kompletny proces to nie tylko idealny start i udany koniec. Co się dzieje w przypadku braku uprawnień? Zachowaj wpisy, jeśli ktoś się przerwie? Czy wynik po ponownym uruchomieniu jest wciąż dostępny? Czy można poprawić błędny wpis? Co widzi osoba na pustej liście? Jak aplikacja zachowuje się w przypadku większej czcionki lub bez sieci?
Te pytania kosztują trochę czasu. Jeśli zespół rozdzieli ten sam czas na coraz więcej funkcji, to zanika głębia, dzięki której poszczególne procesy mogą być przemyślane. Skupia się to również na decyzji w sprawie budżetu na jakość: jakie nieliczne sposoby zasługują na szczególnie czyste leczenie błędów, dobre opinie zwrotne i testy z realistycznymi danymi?
Granice produktu muszą być zrozumiałe
Granica pomaga tylko wtedy, gdy nie działa jak ukryty brak. Osobiste narzędzie powinno wyraźnie powiedzieć, że nie zapewnia współpracy w zespole. Aplikacja offline powinna wyjaśniać, jak działa bezpiecznik i wymiana urządzeń. Schowek dokumentów nie może tworzyć wrażenia, że archiwum jest zabezpieczone przed wizją. Uczciwe rozgraniczenie chroni przed niewłaściwymi oczekiwaniami i prowadzi raczej do osób, których sytuacja naprawdę pasuje.
Nie jest to funkcja niekompletna. Aplikacja jest zaprojektowana dla jednej osoby na urządzeniu i opisuje decyzję o produkcie i jego konsekwencję. Granica pozostaje taka sama, ale staje się zrozumiała w oparciu o scenariusz użytkowania.
Dobry zakres ma również zdolność do łączenia się. Nie każda możliwa funkcja musi być włączona, ale istniejące dane powinny dobrze łączyć się z danym produktem. Funkcja zadań jest bardziej pomocna, jeśli zna przedmiot zadania. Dokument wygrywa poprzez jego przypisanie. Skupianie się nie oznacza tworzenia oddzielnych miniaturek, ale niewielkiego, kompletnego związku.
Kiedy rozszerzenie naprawdę ma sens
Nie każdy nowy pomysł to przeciążenie funkcji. Produkty muszą się uczyć i ewoluować. Pomocne są kryteria, które sprawiają, że rozszerzenie jest sprawdzalne:
- Rozwiązuje ona powtarzający się problem jasno określonej grupy docelowej.
- Wzmacnia on istniejący proces podstawowy, zamiast otwierać niezależny sektor produktów.
- Twój sukces można opisać jako lepszy wynik, nie tylko jako użycie nowego przycisku.
- Wymogi w zakresie danych, uprawnienia i zachowania w przypadku awarii są uzasadnione.
- Funkcja ta może być dostępna, zrozumiała i stosowana na odpowiednich urządzeniach.
- Rozwój, testowanie, eksploatacja i późniejsze zmiany są trwałe.
Szczególnie sensowne jest pytanie, co się dzieje bez rozszerzenia. Czy ludzie muszą improwizować centralny krok poza aplikacją? Wtedy może być luka. Jeśli nowa funkcja jest tylko wygodna, podczas gdy proces jądra jest już w pełni sprawny, należy rozważyć inne ulepszenia jakości.
Węzeł czekający na pomysły jest często lepszy niż tak lub nie. Pozwala zbierać obserwacje, łączyć podobne potrzeby i najpierw zrozumieć prawdziwy powód. Za pragnieniem większej ilości filtrów wiêcej może być zła nazwa; za poszukiwaniem jK może być tylko potrzeba dobrze zorganizowanego lokalnego wyszukiwania tekstu.
Skupianie się nie jest jednorazową decyzją MVP
Tak zwany “minimalny produkt Viable Product” jest czasem błędnie rozumiany jako możliwie najmniejsza pierwsza wersja, która później nieuchronnie staje się kompleksowym systemem.
Może to oznaczać ujednolicenie rzadko używanych wariantów, usunięcie niejasnych ustawień lub niekontynuowanie złożonej integracji. Takie decyzje wymagają solidnych obserwacji i szacunku dla istniejących użytkowników. Są one trudniejsze niż dodatkowa karta na mapie drogowej, ale mogą znacznie poprawić produkt.
Istotną rolę w tym zakresie odgrywa możliwość oczekiwania. Jasne moduły i odpowiedzialność ułatwiają testy i zmiany. Co ważniejsze, jasna struktura techniczna: terminy powinny być spójne, dane nie powinny być prowadzone w wielu miejscach w sposób sprzeczny i nie zależą od przypadkowych skutków ubocznych. Architektura techniczna nie może uratować niejasnego zakresu produktu, ale może sprawić, że wyraźny zakres będzie trwały.
Dostępność korzysta z wcześniejszych decyzji
Dostępność jest dobrym przykładem tego, dlaczego jakość nie powinna być traktowana jako dodatkowa funkcja późniejsza. W3C WAI zaleca, aby dostępność była włączana wcześnie i wielokrotnie w projektowanie, wdrażanie i ocenę. Wystarczające kontrasty, zrozumiałe oznaczenia, większa czcionka, czytnik klawiatury lub ekranu dotyczy podstawowej formy produktu.
Na przeciążonej powierzchni wymagania te stają się droższe. Więcej interakcji oznacza więcej sekwencji ostrości, napisów, stanów i kombinacji, które należy sprawdzić. Jasna konstrukcja nie sprawia, że dostępność jest kompletna automatycznie, ale tworzy przestrzeń do traktowania jej jako części każdego procesu jądrowego.
To samo odnosi się do ochrony danych i bezpieczeństwa. Każdy, kto patrzy na funkcję dopiero po jej powierzchni, odkrywa niezbędne uprawnienia, przepływy danych lub zasady usuwania. Kto sprawdza je jako pełną decyzję o produkcie, może stwierdzić, że prostsze klasyczne rozwiązanie przynosi te same korzyści z mniejszym ryzykiem.
Najlepsza lista funkcji jest uzasadniona
Nie ma idealnej liczby funkcji. Aplikacja kamerowa, aplikacja bankowa i narzędzie do przekazywania informacji o nieruchomościach mają różne zadania i profile ryzyka. Decydujące jest, czy każdy element odgrywa wyraźną rolę w produkcie oraz czy wspólny zakres pozostaje zrozumiały, możliwy do sprawdzenia i możliwy do zastosowania.
Jeśli chodzi o Zappapps, ta idea jest wytyczna: produkty mają rozwiązać konkretne zadanie z jasnymi granicami, nie jest to obietnica, że każda wersja pozostanie mała, ale obowiązek nie mylić wzrostu z postępem.
W związku z tym dobra aplikacja nie musi być w stanie wszystkiego. Musi być niezawodna, aby pokazać, do czego jest przeznaczona, aby w pełni wspierać właściwą ścieżkę i być szczerym we wszystkim innym. W ten sposób jakość produktu jest często większa niż w najdłuższej tabeli porównawczej.
Źródła i dalsze informacje
- Apple Human Interface Guidelines – zasady hierarchii, spójności i projektowania odpowiedniego dla platformy.
- Android Developers: Guide to app architecture – granice odpowiedzialności, modele danych, testowalność i łatwość utrzymania.
- W3C WAI: Planning and Managing Web Accessibility – dostępność jako stały element pracy nad produktem.
