User stories – co to jest, jak pisać i przykłady z praktyki

User stories są jednym z najbardziej przydatnych narzędzi w rękach UX designerów, bo pozwalają w bardzo prosty sposób zobrazować, jakich funkcji w produkcie cyfrowym naprawdę potrzebuje użytkownik. Podpowiadamy, jak je pisać.

Czym są user stories?

User story (czyli z angielskiego historyjka użytkownika) to krótki, przedstawiony z perspektywy użytkownika opis tego, co dana osoba chce osiągnąć podczas korzystania z produktu lub usługi. 

„Klasycznie” wymagania projektowe skupiają się raczej na cechach produktu, w stylu: „System musi umożliwiać edycję produktów przez administratora e-sklepu”. Natomiast user stories odwracają perspektywę i koncentrują się na potrzebach użytkownika, na zasadzie „Jako administrator chcę móc łatwo edytować produkty w moim e-sklepie, aby być w stanie na bieżąco aktualizować informacje o ich dostępności”. 

Jak pisać user stories? Złota formuła i zasada INVEST

Główne założenie jest takie, aby każdą historyjkę dało się zmieścić na… karteczce samoprzylepnej. Dlatego też user stories najczęściej formułujemy według schematu:

Jako <użytkownik> chcę <potrzeba>, żeby <cel do osiągnięcia>

Użytkownik to po prostu rola, jaką osoba pełni wobec projektowanego produktu. Może nim być administrator, redaktor treści, potencjalny klient, użytkownik mobilny itd. Potrzeba opisuje, jakich możliwości (funkcji) osoba oczekuje od produktu. Co bardzo ważne, nie skupiamy się tu na samym rozwiązaniu technicznym, tylko na działaniu, które chce podjąć użytkownik. Wracając do przykładu z początku tekstu, dobrze sformułowaną potrzebą byłoby „chcę móc łatwo edytować produkty w moim e-sklepie”, a nie na przykład „chcę prostego edytora produktów”. Natomiast cel do osiągnięcia wyjaśnia, dlaczego użytkownik chce podjąć daną akcję albo jaką będzie miał z tego korzyść.

Ale to nie wszystko. Bill Wake – konsultant pracujący od ponad 20 lat z zespołami Agile – zaproponował sześć konkretnych kryteriów, które dobrze napisana „historyjka” powinna spełnić, jeśli faktycznie ma być przydatna przy realizacji projektu; znane są one jako model INVEST:

• Independent – każda user story powinna być możliwa do zrealizowania niezależnie od pozostałych, żeby zespół miał swobodę w ustalaniu priorytetów.
• Negotiable – user story nie powinno narzucać rozwiązań, tylko być punktem wyjścia do pracy.
• Valuable – każda historia musi dostarczać konkretną wartość użytkownikowi. Jeśli nie potrafisz wyjaśnić, po co dana funkcja, prawdopodobnie nie jest ona potrzebna.
• Estimable – zespół powinien być w stanie określić, ile czasu zajmie realizacja danej user story.
• Small – dobrą user story da się zrealizować w jednym sprincie (czyli zazwyczaj do miesiąca). Jeśli jest za duża, należy ją podzielić na mniejsze
• Testable – user story powinno mieć jasno określone kryteria akceptacji, według których da się określić, czy zostało zrealizowane, czy nie. 

Przykłady dobrych (i złych) user stories

Najlepiej pokazać to na przykładach. 

Jako klient sklepu internetowego chcę móc filtrować produkty według rozmiaru i koloru, aby szybko znaleźć to, czego szukam. 

Prosta historyjka, która mogłaby się przydać przy pracy nad projektem e-sklepu odzieżowego; najlepsze w niej jest to, że jasno opisuje, po co w zasadzie użytkownicy potrzebują intuicyjnego systemu filtrów. 

Jako redaktor treści chcę widzieć podpowiedzi SEO podczas pisania artykułu, aby móc optymalizować teksty pod kątem wyszukiwarek od A do Z przy pomocy tylko jednego narzędzia.

To z kolei świetny przykład historyjki, którą można byłoby wykorzystać przy projekcie edytora treści pod pozycjonowanie, w stylu NEURONwriter albo Surfer SEO.

A jak mogłaby wyglądać źle napisana user story? Wyobraźmy sobie projekt nowej aplikacji fitness i taką historyjkę:

Jako użytkownik chcę, aby aplikacja była natywnie zintegrowana z Apple Health.

Problemy z nią są dwa. Po pierwsze, nie wiemy, po co użytkownik potrzebuje tej integracji, a po drugie – opis potrzeby odnosi się bardziej do rozwiązania problemu, niż rzeczywistej potrzeby użytkownika. Lepiej byłoby napisać ją w ten sposób: 

Jako użytkownik aplikacji fitness chcę móc zsynchronizować swoje treningi z Apple Health, tak aby mieć wszystkie dane w jednym miejscu.

Od razu widać różnicę. Historyjka opisuje konkretny cel, a do tego czuć, że mógłby za nią stać użytkownik, a nie np. developer, który na co dzień myśli o produkcie z bardziej technicznej perspektywy. A o to właśnie chodzi w user stories – aby uprościć wymagania projektowe do jednego zdania i ubrać je w język, który stawia użytkownika w centrum uwagi.