menedżer produktu jest często opisywany jako „pomost między biznesem, designem i technologią”. Część „most między designem a technologią” jest szczególnie krytyczna, jeśli chodzi o wysyłkę produktu wysokiej jakości: bez błędów, bez pikseli i biorąc pod uwagę wszystkie możliwe scenariusze i przypadki brzegowe. Aby upewnić się, że most działa dobrze, oto kilka sposobów obsługi przez zespół projektowy:

• projektant dostarcza kompleksowy prototyp, który pokazuje wszystkie przepływy produktu. Niestety, często będzie to wymagało dużo czasu i nadal będzie brakować kilku skrajnych przypadków.
• projektant dostarczy tylko prototyp, który pokazuje główne przepływy funkcji i pozostaje dostępny na pytania od zespołu programistów. Niestety, te tam iz powrotem są wysoce nieefektywne (zwłaszcza w zdalnej Konfiguracji) i marnują dużo czasu zarówno od zespołu projektowego, jak i programistycznego.
• projektant, oprócz kompleksowego prototypu, pisze odpowiedni dokument specyfikacji, który wymienia wszystkie możliwe scenariusze i przypadki brzegowe. Problem polega na tym, że często jest to strata czasu, ponieważ (1) cenny czas projektantów będzie lepiej spędzony na projektowaniu innych funkcji, a nie pisaniu dokumentu specyfikacji, i (2) nie zawsze mają ten sam widok produktu 360°, co robią menedżerowie produktu, co spowoduje, że przeoczą niektóre scenariusze i przypadki krawędzi.

dlatego Dojrzałe zespoły produktowe zazwyczaj powierzają pisanie specyfikacji swoich produktów menedżerom produktowym.

ale jak napisać specyfikację produktu? Przez ostatnie 5 lat pisałem specyfikacje produktów i znalazłem format, który jest dobrze doceniany przez zespoły programistyczne, z którymi pracuję. W tym poście dzielę się więcej o mojej metodologii i narzędziach, których używam do pisania specyfikacji produktów. Opisuję również pewne ograniczenia, z którymi borykam się za pomocą narzędzi, których używam, i kilka pomysłów na poprawę, które mam na myśli.

oto 5 głównych tematów, które poruszam w specyfikacji produktu:

1. kontekst i cele
2. Mapa architektury
3. epiki i historie użytkowników
4. kryteria akceptacji
5. projektowanie, treść i tłumaczenia

kontekst i cele

nawet jeśli specyfikacja produktu jest skierowana głównie do zespołów programistycznych, nadal lubią wiedzieć, dlaczego pracują nad tym, nad czym pracują. Zrozumiałem, że jednym z głównych czynników motywujących programistów jest wpływ. Większość z nich marzy o pracy nad funkcjami, z których korzystają miliony użytkowników. Są podekscytowani, gdy słyszą, że nowy interfejs użytkownika, który wdrożyli, zwiększył retencję na przykład o 15%. Dlatego ważne jest, aby podać kontekst funkcji, którą będą implementować:

• o czym mówimy? Która część produktu? Możesz dodać dowolną historię funkcji, która jest przydatna do zrozumienia obecnej sytuacji.
• jaki jest obecny problem? Uwaga: do rozwiązania może być kilka problemów.
• czy jest jakaś jakościowa informacja zwrotna / dosłowna od użytkowników do cytowania?
• czy są jakieś dane (np. wykresy) do wyświetlenia? W tej sekcji możesz dołączyć dowolne wykresy lub wykresy, które sprawią, że dane będą bardziej zrozumiałe.
• jakie jest wybrane rozwiązanie? (opisz to po prostu, w kilku zdaniach)
• czy rozważano jakieś inne rozwiązanie? Jeśli tak, dlaczego został odłożony?
• czy jakieś inne rozwiązanie zostało już wdrożone? Jak to działa?
• jakie są cele ? Czy są jakieś KPI, na które próbujemy wpłynąć? Pomoże to w szczególności zespołowi programistycznemu zrozumieć, czy muszą wdrożyć nowe trackery / tagi / zdarzenia, aby prawidłowo zbierać dane. Widziałem, jak zespoły czują się tak napędzane projektem, że podjęły inicjatywę skonfigurowania pulpitów nawigacyjnych, aby śledzić metryki w czasie rzeczywistym, bez mnie ani nikogo innego o to nie pytającego.

Mapa architektury

zanim zagłębisz się zbytnio w szczegóły funkcji, ważne jest, aby dać ogólny przegląd tego, co zmienia się i co pozostaje takie samo w Twoim produkcie. Nawet jeśli pracujesz nad zupełnie nowym produktem, Mapa architektury nadal będzie niezwykle istotna, aby zrozumieć strukturę produktu.

„Mapa architektury” to sposób, w jaki nazywam diagram wysokiego poziomu przedstawiający cechy produktu (przepływy, ekrany i zawartość) oraz ich związek ze sobą. Niektórzy nazywają to „architekturą informacji”, „mapą przepływu”, „mapowaniem UX” itp.

nie ma oficjalnej metodologii rysowania mapy architektury. W aplikacji mobilnej zazwyczaj staram się różnicować przepływy, ekrany i ” części ekranu „(lub” zawartość strony”), używając innego kształtu dla każdego z nich, jak opisano w powyższej legendzie.

pomocna może być również gra na kodzie koloru. W powyższym przykładzie użyłem 3 kolorów, a także solid vs. linia przerywana, aby wyjaśnić, w jaki sposób aktualna architektura informacji zostanie zaktualizowana dzięki przebudowie UX aplikacji, nad którą pracowaliśmy. (zielony: pozostanie taki, jaki jest, pomarańczowy: zostanie zaktualizowany, czerwony: zostanie usunięty; solid: pozostanie w tym samym miejscu, kropkowany: zostanie przeniesiony gdzie indziej). W ten sposób inżynierowie mieli jasny obraz z lotu ptaka, która część aplikacji może ulec zmianie.

kolejną wskazówką, aby zbudować zrozumiałą mapę architektury, jest wyraźne rozróżnienie różnych części nawigacji, tak jak poniżej, z oddzielnymi obszarami dla każdej z nich.

posiadanie mapy architektury będzie niezwykle przydatne dla specyfikacji produktu; pozwoli Ci to podkreślić, o której części produktu mówisz w każdej z historii użytkownika.

jakiego narzędzia użyć do narysowania mapy architektury? Dostępnych jest ich mnóstwo, mój ulubiony jest kapryśny (ponieważ jest wizualnie przyjemny i bardzo prosty, nie zaśmiecony tak wieloma funkcjami), ale również użyłem Draw.io w przeszłości-co jest interesujące, ponieważ jest zintegrowany z Dyskiem Google, więc jeśli pracujesz z prezentacjami Google i dokumentami Google, to sprawia, że jest przyjemny w użyciu. Jest również zintegrowany z JIRA i Confluence.

Jeśli chcesz dowiedzieć się więcej o mapach architektury (polecenia i zakazy, jakich narzędzi użyć, kilka przykładów itp.).), Toptal wymyślił świetną lekturę: wszechstronny przewodnik po architekturze informacji.

epiki i historie użytkowników

rozbicie i Wyjaśnienie wszystkich części produktu może bardzo szybko stać się dość chaotyczne. Pisanie specyfikacji produktów w ciągu ostatnich 5 lat, najlepszym sposobem, jaki znalazłem, aby utrzymać specyfikacje uporządkowane i zrozumiałe, jest rozbicie ich zgodnie z „historiami użytkowników”.

Co to jest User story? Według Agile Modeling, User story jest ” bardzo wysokopoziomową definicją wymogu, zawierającą wystarczającą ilość informacji, aby programiści mogli przedstawić rozsądne oszacowanie wysiłku, aby go wdrożyć.”

ideą user stories jest stawianie użytkowników na pierwszym miejscu i unikanie używania wyłącznie niejasnych& słownictwa technicznego podczas omawiania funkcji. Jak mówi Atlassian: „po przeczytaniu historii użytkownika zespół wie, dlaczego buduje to, co buduje i jaką wartość tworzy.”

mają na celu zbudowanie lepszego produktu, w którym użytkownik jest w centrum dyskusji, w przeciwieństwie do starego dobrego rozwoju produktu waterfall.

oto jak powinna być sformułowana Historia użytkownika:

jako< typ użytkownika> chcę< jakiś cel> tak, że< jakiś powód>.

na przykład, oto jak możemy sformułować historie użytkowników dla następującej części mapy architektury, którą narysowałem dla jednego z moich klientów:

• historia użytkownika #1: jako pracownik w sekcji profilu chcę edytować swój profil, aby móc zaktualizować moje zdjęcie, imię i nazwisko.
• Historia użytkownika # 2: Jako pracownik w sekcji Profil chcę uzyskać dostęp do ustawień, aby móc zaktualizować hasło i preferencje powiadomień o aktualizacji.
• Historia użytkownika #3: jako pracownik w sekcji profilu chcę uzyskać dostęp do czatu, aby móc przekazać opinię twórcom aplikacji

to menedżer produktu decyduje, który poziom szczegółów chce uwzględnić w historii użytkownika. Gdybyśmy chcieli, moglibyśmy również pójść o jeden poziom głębiej w User Story # 2, na przykład:

• User Story #2.a: Jako pracownik w Ustawieniach chcę uzyskać dostęp do sekcji „Edytuj hasło”, aby móc zaktualizować hasło
• Historia użytkownika #2.b: jako pracownik w Ustawieniach chcę uzyskać dostęp do preferencji powiadomień, dzięki czemu mogę aktualizować częstotliwość otrzymywania każdego rodzaju powiadomień

, ale jak widzisz, jest to dość oczywiste i zbędne. Osobiście zdecydowałem się zawrzeć te scenariusze w „kryteriach akceptacji” (patrz następna sekcja) omawianych historii.

aby uporządkować historie użytkowników, często używamy „epiki”. Pod względem zwinności „epiki” to duża ilość pracy, którą można podzielić na mniejsze historie użytkowników. Osobiście używam Epic do grupowania opowieści, które są częścią tego samego tematu lub obszaru w produkcie. Na przykład, wybrałem grupowanie opowieści powyżej jako część epiki „profil”. Niektórzy decydują się na formułowanie Epik w taki sam sposób jak user stories, o prostszej strukturze (np. „Jako użytkownik chcę uzyskać dostęp do mojego profilu”)

kryteria akceptacji

aby upewnić się, że do historii użytkownika dodano wystarczająco dużo szczegółów, używamy” kryteriów akceptacji „(czasami nazywanych również”warunkami satysfakcji”).

według LeadingAgile.com „kryteria akceptacji” to ” warunki, które musi spełnić oprogramowanie, aby zostać zaakceptowane przez Użytkownika, Klienta lub w przypadku funkcjonalności na poziomie systemu, system zużywający.”

w kryteriach akceptacji powinieneś wymienić wszystkie cechy funkcjonalne, które nie są wyraźnie określone w historii użytkownika. Przykład:

Historia użytkownika

jako pracownik w sekcji Profil chcę edytować swój profil, aby móc zaktualizować zdjęcie, imię i nazwisko.

kryteria akceptacji

• biorąc pod uwagę, że jestem na ekranie edycji profilu po kliknięciu ikony edycji imienia, powinien przełączyć się w tryb edycji, skupić się na wejściu i otworzyć klawiaturę (to samo dla nazwiska)
• biorąc pod uwagę, że jestem na ekranie edycji profilu po kliknięciu ikony edycji zdjęcia, powinien poprosić mnie o wybranie między aparatem a biblioteką
• biorąc pod uwagę, że edytuję swoje imię, gdy klikam „Zapisz”, powinien przekierować mnie do trybu odczytu i powinienem zobaczyć powiadomienie o sukcesie

itd…

pomyśl o kryteriach akceptacji jako o Lista kontrolna, którą należy wypełnić, aby produkt został wysłany. Podany powyżej format / When / Then jest dobrym sposobem na sformułowanie kryteriów akceptacji, ale w niektórych przypadkach może być trudny w użyciu.

projektowanie, treść i tłumaczenia

mając aktualne projekty w specyfikacji produktu

do tej pory nie wspomniałem, którego narzędzia używam do pisania specyfikacji. W przeszłości przełączałem się między dokumentami Google, Prezentacjami Google i pojęciem. Bardzo podobało mi się korzystanie z Notion do wszystkich fajnych integracji, które oferuje (szczególnie tych z InVision i Figma). Ale teraz całkowicie przełączyłem się na Dokumenty Google: wolę mieć więcej swobody w formatowaniu specyfikacji produktu. Wygodniej jest również korzystać z produktów Google podczas pracy z partnerami zewnętrznymi lub klientami.

aby mieć pewność, że identyfikacja wizualna Twojego produktu zostanie dokładnie ożywiona przez zespół programistów, ważne jest, aby zapewnić im dostęp do najbardziej aktualnych ekranów dostarczanych przez projektantów. Ale ponieważ nie ma prawdziwej integracji między dokumentami Google i narzędziami projektowymi, takimi jak Figma, InVision lub Zeplin, kiedyś eksportowałem ekrany i kopiowałem/wklejałem je do moich specyfikacji produktów.

to bardzo szybko stałoby się problemem: projektanci iterują na swoich ekranach codziennie, a nawet jeśli wszystko zostało uzgodnione na ekranie, może się to zmienić kilka tygodni później, ponieważ jeden konkretny komponent jest aktualizowany w bibliotece projektów. Spowoduje to, że moje specyfikacje będą nieaktualne przez większość czasu.

dlatego dzisiaj używam tylko nazwy screenów. Na przykład, jeśli historia użytkownika o edycji profilu dotyczy 2 ekranów zaprojektowanych na Figma, napiszę tylko „Figma screen name: edit-profile-1 and edit-profile-2”.

oczywiście nie jest to idealne rozwiązanie i ogranicza programistów lub kogokolwiek innego czytającego moje specyfikacje do przełączania się między kilkoma narzędziami.

ale to pokazuje, że jest dziś coś nieefektywnego w sposobie pisania specyfikacji produktu. Korzystanie z kilku produktów rodzi pytania o integrację i synchronizację. Jak zapewnić, aby wszystkie informacje potrzebne do zbudowania produktu były widoczne w jednym miejscu, nie będąc przestarzałymi? (W rzeczywistości dotyczy to nie tylko projektów, ale także map architektury i treści).

→ Jeśli również doświadczasz tego problemu i znalazłeś rozwiązanie, byłbym zainteresowany otrzymaniem Twojej opinii!

dając łatwy dostęp do treści i tłumaczeń, aby uniknąć literówek

podczas projektowania ekranów z dużą ilością treści, miło jest dać programistom możliwość łatwego kopiowania/wklejania go zamiast konieczności ponownego wpisywania go samodzielnie. W przeciwnym razie możesz skończyć z (1) wieloma literówkami i (2) wkurzonymi programistami. Istnieje kilka sposobów, aby dać im dostęp do treści:

• , dając im dostęp do plików źródłowych prac projektowych na przykład Sketch, Figma lub Zeplin.
• kopiując / wklejając zawartość bezpośrednio w specyfikacji (może to spowodować trochę bałaganu).

Jeśli twój produkt istnieje w kilku językach, daj również dostęp do każdego tłumaczenia. Na przykład, możesz użyć tablicy, aby pokazać tłumaczenie oryginalnej treści w każdym języku. Kolejnym poziomem zarządzania tłumaczeniami jest użycie narzędzia lokalizacyjnego (takiego jak Phrase) i dodanie tylko „kluczy tłumaczeniowych” w specyfikacji produktu. Ale znowu oznacza to jeszcze jedną zmianę między specyfikacją produktu a innym narzędziem.