Photo by charlesdeluvio on Unsplash

Jak skutecznie przekazać projekt do feedbacku?

Drugim autorem artykułu jest Adam Karmiński. Dzięki wspólnej pracy, udało nam się stworzyć nie tylko gotowy framework, ale i poniższy artykuł, który, mamy nadzieję, będzie dla Ciebie cennym źródłem wiedzy.

Przed Tobą projekt. Pojedynczy feature, zbiór feature’ów, cała aplikacja, system. Niezależnie od tego, jak duży i skomplikowany jest to projekt, zawsze będzie wymagał ustalenia problemów do rozwiązania, założeń i rozwiązania.

Ile razy Twoje myśli krążyły wokół tego, w jaki sposób zaprezentować swój projekt? Czy tym razem wystarczy jeden, długi mail? Wiadomość na Slacku? Prezentacja multimedialna? A może board na MIRO?

Po raz kolejny zastanawiasz się — jak dużo przekazać? Jak bardzo wprowadzić w koncept, jak dużo przekazać informacji z fazy researchu, analizy konkurencji, jak dużo miejsca poświęcić na „oczywiste” założenia, o których „wiedzą wszyscy”?

Jeśli za każdym razem robisz to inaczej, oznacza to, że nie masz dobrej struktury, która pomogłaby Ci uporządkować odpowiednie informacje w odpowiedniej ilości i w odpowiednim miejscu.

W codziennej pracy w Bethink, mierzymy się głównie z wprowadzaniem zmian w istniejących modułach naszego systemu, lub z wprowadzaniem całkowicie nowych funkcji. Utrzymujemy produkt (będący kursem e-learningowym), którego fundamenty pozwalają uczyć się każdego dnia tysiącom kursantów. Nieważne, czy wprowadzamy „małe” czy „duże” zmiany — każda z nich jest tak samo ważna, bo realnie wpływa na poprawienie komfortu i efektywności procesu uczenia się naszych kursantów.

Po fazie discover i define, prezentujemy nasze pomysły na nowe rozwiązania. Wielokrotnie, dostawaliśmy mnóstwo pytań o dodatkowy kontekst, próśb o wytłumaczenie dlaczego akurat to zagadnienie rozwiązujemy w dany sposób, przypomnienie o problemach naszych kursantów. Intuicyjnie tworzyliśmy kolejne przestrzenie do przekazywania naszych propozycji i zostawiania feedbacku przez interesariuszy.

W pewnym momencie powiedzieliśmy sobie STOP. Przecież to za każdym razem wygląda tak samo. Proces składa się z powtarzalnych elementów. Zaczynamy od definiowania problemów, które chcemy rozwiązać. Skupiamy się na założeniach, które musimy spełnić. W końcu przygotowujemy rozwiązanie, które skupia się na radzeniu sobie z problemami i jest zgodne ze wszystkimi założeniami.

Na podstawie naszych doświadczeń i obserwacji, powstał szablon na MIRO, który wykorzystujemy za każdym razem, kiedy przygotowujemy koncept do feedbacku.

Szablon powstał we współpracy projektantów i Product Ownera, ale jego prostotę i użyteczność sprawdzili developerzy i interesariusze. Ostateczny framework, to wynik kilku iteracji, zebrania wiedzy na temat produktu, priorytetyzacji informacji i ich wizualnego przedstawienia. Ten board nie powstałaby gdyby nie realna potrzeba udoskonalania procesu wprowadzającego w nowy koncept i procesu feedbackowego.

Dzisiaj dzielę się tym frameworkiem z Tobą, żeby Twoja organizacja nie musiała tworzyć czegoś nowego. Nasz szablon MIRO to kompletny i sprawdzony framework opowiadania o projekcie. On po prostu działa. Niech działa dla Ciebie!

Jak używać frameworka?

Oto on: http://bit.ly/3OAhK41

Szablon na MIRO jest nieedytowalny. Udostępnianie linku w opcji "Can view" nie pozwala na jednoczesne edytowanie ani duplikowanie całego boarda. W związku z tym, możesz jedynie przeglądać szablon i stworzyć swój na podstawie naszego. Na MIRO znajduje się kontakt do autorów — daj nam znać, jeśli potrzebujesz edytowalny szablon!

Board na MIRO zawiera 3 stałe sekcje:

1. Wprowadzenie
2. Ogólny koncept
3. Podsumowanie

Każda z tych sekcji zawiera inne informacje. Najbardziej obszerną sekcją jest Wprowadzenie, i to jej poświęcamy najwięcej uwagi w tym artykule. Wprowadzenie (sekcja 1) w ogólny koncept (sekcja 2) jest najistotniejsze — to właśnie w tym miejscu będziesz opisywać problemy, założenia i rozwiązania. Podsumowanie (sekcja 3) jest zwieńczeniem wszystkiego, co opiszesz w pierwszych dwóch sekcjach.

Ogólny koncept to miejsce na wizualne pokazanie projektu — pamiętaj, że możesz zastosować dowolne narzędzia by to zrobić. U nas najczęściej sprawdzają się po prostu makiety, ale nic nie stoi na przeszkodzie, żeby pokazać w tym miejscu flowcharty, szkice czy nawet gotowe UI.

Na MIRO, w każdej z sekcji, jest esencja tego, co powinno się w niej znaleźć. Znajdziesz tam wskazówki, przypominajki i gotowe templatki. Wszystko jest wyraźne odróżnione pochylonym stylem tekstu (italic).

Mam nadzieję, że będzie Ci się dobrze korzystało z naszego frameworka! Poniżej znajdziesz nieco więcej szczegółowych informacji na temat tego, jak skutecznie przekazać projekt do feedbacku.

Sekcja 1: Wprowadzenie

Sekcja „Wstęp” jest niewidzialnie podzielona na dwa obszary — „Jak i dlaczego” oraz „Problemy, założenia, rozwiązania”.

„Jak i dlaczego” skupia się na wprowadzeniu w koncept i przekazaniu najważniejszych definicji, opisie, co znajdzie się na boardzie i jak będzie wyglądał proces feedbackowy.

„Problemy, założenia, rozwiązania” to core naszego frameworka. W tej sekcji budujemy całe zrozumienie projektu. Poświęcona jej zrozumieniu jest większość poniższego artykułu.

Zawsze zaczynaj od dlaczego, a potem opowiedz jak

Niezależnie od tego, czy wprowadzasz zupełnie nowy projekt, czy modyfikujesz obecne zachowanie części systemu, czy całkowicie zastępujesz część systemu inną — zawsze odpowiednio wprowadź interesariuszy w kontekst.

Nie wszyscy mogą mieć tę samą wiedzę. Zanim przejdziesz do szczegółowego omawiania zmian i propozycji, przypomnij najważniejsze fakty.

Dlaczego

Zdefiniuj cele, które ma spełnić projekt. Opowiedz o dlaczego. Zrobienie tego na samym początku pozwoli osadzić się w kontekście nie tylko Tobie, ale przede wszystkim osobom feedbackującym. Myśl o celach, nawet nieuświadomiona, będzie przez cały czas „obok”.

Jak

Samo wprowadzenie na boardzie może składać się z 3 sekcji, które dotyczą „Jak”:

1. Jak chcemy mówić w projekcie?
2. Jak wygląda framework i co się na nim znajduje?
3. Jak feedbackować?

Jak mówić o projekcie? Jeśli projekt wymaga wprowadzenia nowego rozwiązania do aplikacji, a nowe nazewnictwo jest konieczne do dalszego opowiadania o niej — warto na tym etapie wdrożyć podstawowe definicje. Przydatnym może być stworzenie specjalnego „Słowniczka”, do którego będzie można się odnosić również na dalszych etapach opowiadania o zmianie. Pamiętaj jednak, żeby słowniczek wprowadzał definicje niezbędne do zrozumienia celu projektu i najważniejszych funkcji. Jeśli możesz wytłumaczyć coś kontekstowo — zrób to kontekstowo. Nikt nie zapamięta kilkunastu definicji, które są oderwane od funkcji.

Jak wygląda framework? — to sekcja, która powinna opisać to, w jaki sposób chcesz przedstawić swój projekt. Opowiedz tutaj o tym, gdzie co się znajduje. Skróć najważniejsze ścieżki, zostaw ogólne informacje. Wspomnij o sekcjach, które czekają interesariuszy na końcu.

Jak feedbackować? — sekcja, w której opowiesz o Waszych zasadach feedbacku. Piszę o niej na końcu, ale na boardzie znajduje się na samym początku — po to, by oddzielić sekcję „praktyczną” od „merytorycznej”. W Bethink, w tej sekcji, zawsze przypominamy o tym, żeby komentarze zostawiać kontekstowo, obok feedbackowanego elementu. Przypominamy o tym, że kolor komentarza ma znaczenie. Uczulamy interesariuszy, by nie rozpoczynali nowego wątku, jeśli widzieli już podobną dyskusję.

Pamiętaj, że wprowadzenie zbuduje zrozumienie Twojego projektu. Jeśli powiesz w tej części za mało, interesariusze zaczną feedbackować Twoje rozwiązanie bez pełnego kontekstu. Jeśli powiesz za dużo — zwiększysz próg wejścia, a zmniejszysz zrozumienie.

Co jest pomocne dla mnie, kiedy staję przed napisaniem wprowadzenia do projektu? Na chwilę wyobrażam sobie, że nie wiem nic o tym, co chcę przekazać. Jakie informacje pomogą mi zbudować kontekst? Które z definicji są kluczowe, by ten kontekst rozbudować i odpowiednio wyjaśnić? Które ze ścieżek są najbardziej ogólne (od których zacząć), a które na tyle szczegółowe, że mogę o nich wspomnieć później?

Dobrą praktyką jest przechodzenie od ogółu do szczegółu. Tyczy się to budowy i informacji na całym boardzie i jego poszczególnych sekcji.

Precyzyjnie opisz problemy, założenia i rozwiązania

To najważniejsza sekcja naszego frameworka. Na samym boardzie znajdziesz tylko nagłówki i przypominające notatki (do zastąpienia Twoim docelowym tekstem), a w tej części artykułu wytłumaczę Ci dokładnie jak tworzyć i opisywać problemy, założenia i rozwiązania.

Problemy

Zanim je opiszesz, zastanów się: skąd wiemy o problemach? Jakie to problemy? Które z nich adresujemy w pierwszej kolejności?

To informacje, które są niezwykle ważne w tej sekcji. Nie można pominąć żadnej z nich.

Ogólne zasady:

1. Należy wspomnieć, skąd wiemy o problemach — czy są wynikiem wywiadów, badań, ankiet? Problemów zgłaszanych pomocy technicznej i działowi obsługi klienta? Źródło jest niezwykle ważne.
2. Opisywane problemy muszą dotyczyć projektu, o którym mówimy. Nawet jeśli mamy wiedzę, że użytkownicy mają problem z dodaniem elementu do ulubionych, nie wspominamy o tym problemie, jeśli wprowadzamy zmiany w logowaniu.
3. Nie musimy szczegółowo opisywać każdego problemu, o którym wiemy. Opisujemy najważniejsze z nich w taki sposób, by nie zostawiały wątpliwości.
4. Warto unikać generalizowania problemów i wspominania o tych, co do których nie jesteśmy pewni, że rzeczywiście problemem są. To bardzo ważny punkt.
5. Warto skupić się na takich problemach, które przeważały podczas budowania koncepcji i które rzeczywiście najmocniej zostały w nowej koncepcji zaadresowane.

Formułowanie problemów:

Potrzebujemy jakiejś opcji dodawania zadań do Ulubionych/Kolekcji, by można było sprawnie do nich wrócić. Z ankiet ewaluacyjnych wiemy, że obecnie brakuje kursantom takiego rozwiązania.

Powyższe zdanie jest opisem zidentyfikowanego problemu. Co je wyróżnia?

• precyzuje potrzebę,
• dokładnie opisuje kontekst potrzeby,
• zwraca uwagę na to, że obecnie tego czegoś nie ma (potrzeba nie jest zrealizowana).

Opisując problem, w zdecydowanej większości, będziemy się posługiwać potrzebami i „brakami”. W końcu na podstawie „braków” i potrzeb, zbudowaliśmy całą omawianą koncepcję.

Bardzo ważne jest to, żeby identyfikując problem, nie zaproponować rozwiązania, ani go nie sugerować. Nawet jeśli, w codziennej pracy projektowej, te 3 obszary naturalnie się między sobą przenikają. Ten framework to miejsce, w którym świadomie chcemy te obszary od siebie odseparować.

Przydatne zwroty:

Problem najczęściej będzie opisywany w czasie przeszłym i teraźniejszym.

Słowa i sformułowania, które pomogą Ci stworzyć opis problemu lub odpowiednio go zidentyfikować:

potrzebujemy, mamy potrzebę, jakieś, jakiejś, brakuje nam tego, nie ma takiego rozwiązania, jeśli coś zmienimy w jednym miejscu, będziemy musieli w drugim (jako opis przeszkody), problemem jest to, że, pojawia się problem

Założenia

Zastanów się: jakie nowe założenia chcemy wprowadzić? Które z dotychczasowych założeń chcemy i musimy utrzymać w ramach nowej koncepcji? Które założenia chcemy zmienić lub odrzucić?

Ogólne zasady:

1. Potraktuj tę sekcję jako wprowadzenie do sekcji kolejnej (tej, w której opowiesz o rozwiązaniach).
2. Napisz wprowadzenie do listy założeń. Możesz wspomnieć, które z założeń są nowe, aktualne lub nieaktualne (jeśli wprowadzasz zmiany w projekcie).
3. Pamiętaj o tym, by oddzielić założenia od rozwiązań. Założenia jednak, muszą nawiązywać do rozwiązań — w następnej sekcji będziesz opisywać to, jak rozwiązałeś problemy, w oparciu o bieżące założenia.
4. Założenie nie powinno zdradzać tego, w jaki sposób będzie rozwiązane — założenia powinny jedynie precyzować problem.

Formułowanie założeń:

Kolekcje powinny zawierać wszystkie zapisane przez kursantów pytania. Kolekcje powinny znajdować się w jednym miejscu w systemie, które będzie stałe i do którego będzie mógł bez problemu trafić kursant.

Co je wyróżnia?

• precyzuje problem, ale jednocześnie…
• … nie jest propozycją rozwiązania problemu,
• nie jest konkretne — pozwala ustalić, co jest ważne, żeby spełnić to założenie, ale nie mówi jak,
• skupia się na ograniczeniu pozytywnym.

Precyzując założenia nie powinniśmy myśleć o tym, jak je rozwiążemy. Jednocześnie, myśląc o rozwiązaniach, założenia pomagają nam wyznaczyć ich akceptowane granice. Jedno i drugie pozwala zachować potrzebny obiektywizm.

Pamiętajmy, że założenia mogą być różne: biznesowe, techniczne, związane z intuicyjnością działań użytkownika. To, w jaki sposób są formułowane, powinno jednak pozostać bez zmian.

Założenia powinniśmy definiować od najważniejszych, po te mniej ważne. Dodatkowo, założenia możemy pogrupować „domenowo”, czyli w jednej grupie umieścić wszystkie założenia dotyczące jednego zagadnienia.

Przydatne zwroty:

Założenia najczęściej będą opisywane z użyciem czasowników modalnych.

Słowa i sformułowania, które pomogą Ci stworzyć opis założenia lub odpowiednio go zidentyfikować:

powinien/ nie powinien, zachowujemy obecne podejście, skupiamy się na, chcemy zachować spójność, chcemy utrzymywać (coś), muszą, mogą

Rozwiązanie i esencja zmian

Zastanów się: co tak naprawdę jest esencją projektu?

Zanim przedstawimy konkretne, wizualne propozycje zmian, warto w kilku zdaniach podsumować pomysły na rozwiązania.

Ogólne zasady:

1. Opisując rozwiązania, warto wdrożyć w pełni nowe nazewnictwo. Wytłumaczyć (powtórzyć) nowe pojęcia, nie pozostawiając żadnych wątpliwości co do ich zrozumienia.
2. Schemat wprowadzania w rozwiązanie powinien zaczynać się od ogółu i przechodzić do bardziej szczegółowych informacji. Warto w tym miejscu zastanowić się, które z funkcji w koncepcji zawierają się w sobie i, w miarę możliwości, dokładnie w taki sposób opowiedzieć o nich.
3. Rozpocznij od najważniejszych rozwiązań, stopniowo przechodząc do “mniej ważnych”. Jeśli rozwiązań jest dużo, pogrupuj je ze względu na domenę, której dotyczą.
4. Należy pamiętać o związkach przyczynowo-skutkowych i kolejności opisywania problemów i założeń. Najważniejsze w opisywaniu rozwiązań jest to, aby zaadresować wszystkie założenia — bez tego, koncepcja będzie niekompletna.

Formułowanie rozwiązań:

Kursanci mogą oznaczyć każde zadanie gwiazdką, znajdującą się w prawym górnym rogu. Dodamy specjalną sekcję „Kolekcje” w głównym menu, żeby kursanci mogli odnaleźć tam swoje zapisane zadania.

Sformułowanie rozwiązań wydaje się najprostsze. Rozwiązania są bowiem:

• dokładne,
• precyzyjne,
• mówią o tym jak coś ma zostać rozwiązane,
• wyraźnie odnoszą się do założeń (wszystkich!),
• wyjaśniają pojęcia, wprowadzają w kontekst.

Przydatne zwroty:

W esencji zmian istotne jest, aby opowiedziały o najważniejszych elementach, które wcześniej zostały zidentyfikowane jako problemy, na bazie których powstały założenia.

Rozwiązania najczęściej będą opisywane z użyciem czasu przyszłego i trybu przypuszczającego.

Słowa i sformułowania, które pomogą Ci stworzyć opis rozwiązania lub odpowiednio go zidentyfikować:

zamierzamy, proponujemy, chcemy, sugerujemy, zalecamy + wszystkie słowa, które jasno wskazują na to, że to propozycja, a nie decyzja.

Tak opisane problemy, założenia i rozwiązania pomogą feedbackującym zapoznać się z całym konceptem projektu, zanim zobaczą gotowe rozwiązania.

Sekcja 2: Ogólny koncept

Cały koncept można doprecyzować za pomocą narzędzi — makiet, UI, animacji, schematów.

Opowieść o szczegółowych zmianach (np. z wykorzystaniem wstępnych makiet, flowchartów, czy inspiracji) powinna być nabudowana na wszystkim, co zostało wcześniej powiedziane we Wprowadzeniu. Opisując projekt, powinniśmy się skupiać na przekazaniu dlaczego dany element czy funkcja wygląda i działa w ten sposób. Na jaki realnie problem odpowiada i jakie założenia spełnia? Dzięki temu, pokazując jak coś wygląda, nie musimy opisywać szczegółów wizualnych, a możemy skupić się na działaniu. Bardzo ważne jest, by rozwiązanie odpowiadało na wszystkie wcześniej wspomniane założenia.

Warto również stosować porównania do obecnego rozwiązania (o ile nie jest to zupełnie nowa koncepcja) i każdorazowo wspominać o różnicach, podkreślając tym samym zalety zmiany. Podczas tych porównań, warto również przytoczyć szerszy kontekst zmian i wspomnieć, jak nowa koncepcja będzie się odzwierciedlała w innych modułach aplikacji, i jak wiele zmian w związku z tym musimy wprowadzić.

Omawiając projekt warto też używać konkretnych (najlepiej znanych) przykładów. Postarać się, aby prezentowane materiały miały jak najwięcej prawdziwych danych, aby nie budziły dodatkowych pytań czy wątpliwości.

Materiały, na których budowana jest opowieść o koncepcji (np. makiety) powinny na początku zawierać kilka najbardziej prawdopodobnych case’ów — tak, żeby zaspokoić niepewność odbiorcy, wskazać potencjalne różnice między nimi i dzięki temu przekazać, że koncepcja jest kompletna pod względem różnych sytuacji. Następnie warto opowiedzieć o tym jak dojść do tego miejsca, oraz co się wydarzy na końcu ścieżki. Pomocny schemat to opowieść od środka, przez początek, aż do końca ścieżki.

Poza tym, warto również, jako wprowadzenie do podsumowania, pokazać kilka pełnych ścieżek użytkownika, wybierając te najbardziej prawdopodobne.

Jeśli zmiana ma kilka rozwiązań (tak zwane warianty), a rolą feedbackujących jest wskazanie optymalnego rozwiązania, warto wskazać w konkretnym miejscu, że mamy do czynienia z wariantami. W opisie wariantów należy skupić się na różnicach między nimi. Pamiętajmy, że wszystkie warianty rozwiązań muszą odpowiadać na wszystkie założenia, dlatego też wspominamy o nich w tej sekcji. Można wskazać rekomendowany wariant i opisać dlaczego naszym zdaniem ma przewagę nad innymi.

Pamiętaj, że wszystko co opisałam, to ogólne rady, a wiele zależy od specyfiki projektu i tego, jak duży on jest. Najważniejsze, to skupić się na konkretach i dobrze poprowadzić przez proces osoby feeebackujące.

Sekcja 3: Podsumowanie

Podsumowanie projektu jest momentem, który jest niezwykle ważny dla ostatecznego domknięcia tematu. Warto powtórzyć kilka problemów, założeń i rozwiązań, ale zmienić język — posługiwać się już teraz definicjami użytymi podczas opisywania zmiany, aby odbiorca nie miał wątpliwości, czy dobrze tę zmianę zrozumiał.

Pomocne w tym może być użycie związków przyczynowo-skutkowych. Postaraj się opisać zdania podsumowujące z wykorzystaniem jednego z modeli:

• Opisujemy wprost, że wprowadzenie jakiegoś elementu, odpowie na konkretny problem, spełniając konkretne założenie. (Wprowadzenie X, odpowie na problem Y, spełniając założenie Z).
• Proponujemy wprowadzenie danego elementu, aby rozwiązać problem i spełnić założenie (Proponujemy X, aby Y+Z).

W podsumowaniu warto powtórzyć jeszcze raz esencję zmiany i w kilku słowach wskazać jak propozycja może pozytywnie wpłynąć na działanie systemu i doświadczenie użytkowników.

Jeśli koncepcja wymaga zebrania feedbacku — warto w tym miejscu wypunktować, które elementy są dla tej koncepcji krytyczne i o jakich działaniach trzeba pamiętać, by w przyszłości tę koncepcję wdrożyć (może to być osobna sekcja).

Jeśli cała zmiana zawiera aspekt, który wymaga szerszego, osobnego komentarza, warto poświęcić mu osobną sekcję. Niekoniecznie musi być to sekcja w Podsumowaniu, ale warto, by wątpliwość została przedstawiona już po zapoznaniu się ze wszystkimi problemami, założeniami i rozwiązaniem. Tylko wtedy feedbackujący może mieć pełny kontekst zmiany.

Podsumowanie powinno być możliwie krótkie, dopełniające wszystkie treści i wizualne propozycje, z którymi odbiorca zapoznał się przed chwilą.

Na koniec

Pamiętajmy, że framework jest jedynie pomocą w zbudowaniu odpowiedniej narracji w komunikowaniu projektu. Można go stosować w wypowiedziach synchronicznych, można go stosować budując specjalne miejsce do feedbacku asynchronicznego (np. board na MIRO).

Jego zastosowanie jest duże i pomimo tego, że skupiliśmy się w tym dokumencie na perspektywie zespołu produktowego (UX+IT), to z powodzeniem ogólny schemat konstruowania problemów, założeń i rozwiązań, może być stosowany w innych działach.

Sam framework może być odpowiednio rozszerzany, np. o sekcje z wariantami rozwiązań czy z wątpliwościami, które pojawiły się podczas projektowania zmiany.

Framework „Jak skutecznie przekazać projekt do feedbacku?” powstał by pomagać, a nie ograniczać. 🚀

Jeśli wykorzystasz go w swojej organizacji, daj nam o tym znać!