„Jak traktować konkretne sugestie użytkowników dotyczące rozwoju funkcjonalności interfejsu?” – to pytanie powraca jak mantra. Specjaliści od UX zastanawiają się, jak traktować np. prośbę o dodanie do interfejsu nowej funkcji, która umożliwia sortowanie bądź przeszukiwanie danych w sposób niemożliwy wcześniej lub np. funkcjonalności umożliwiającej wsparcie dla wysyłek międzynarodowych w sklepie internetowym.
To właśnie są tzw. feature requests – z ang. sugestie od użytkowników. W wielu firmach traktowane są one tak poważnie, że zespół odpowiedzialny za rozwój aplikacji traci kontrolę nad priorytetami.
Zamiast budować użyteczny, wygodny, intuicyjny interfejs – w przemyślany i spójny sposób – specjaliści są wiecznie narażeni na to, że wpadające znienacka zgłoszenie od użytkowników otrzyma mocne poparcie zarządu, który po prostu zleci jego realizację.
Jak zaczęliśmy używać Basecamp’a?
Nietrudno znaleźć blog, na którym rozczarowany programista czy specjalista UX porusza ten temat – zwykle jednak brakuje im przekonującego business case’u, aby polemizować z menadżerami napalonymi na realizację danej funkcjonalności.
W tym miejscu właśnie zaczyna się historia Basecamp’a – jednego z najpopularniejszych na świecie systemów do zarządzania projektami, używanego przez małe firmy, instytucje i korporacje. Zanim zaczęliśmy z niego korzystać w Usability LAB, staraliśmy się porządkować pracę i zarządzać zadaniami, używając kilku innych aplikacji.
Dekadę temu używaliśmy do tworzenia harmonogramów projektów i budowania generalnej listy zadań MS Project.. Później zastąpiliśmy go Fasttrackiem, który spełniał podobną funkcję, ale dawał się również zintegrować z Mindjet Mindmanagerem – oprogramowaniem do tworzenia map funkcjonalności witryn.
To środowisko nie dawało nam jednak możliwości szybkiego przydzielania zadań i reakcji na ciągle zmieniające się priorytety. Dlatego zamiast starać się tworzyć globalny harmonogram i szczegółowo planować projekty, przeszliśmy na bardziej elastyczny model, w którym ważniejsze są istotne daty (milestones). Jednocześnie zamiast zlecać sobie nawzajem zadania za pomocą e-maila i pilnować ich dat w wiecznie niezsynchronizowanym kalendarzu Outlook’a, zaczęliśmy budować listy zadań (ang. to-do’s).
Pierwszą aplikacją, która nam w tym pomogła, był dość toporny bugtracker – FlySpray (podobny do nieco bardziej popularnej Bugzilli). Mimo wielu ograniczeń FlySpray umożliwił nam wreszcie uporządkowanie pracy i pilnowanie realizacji poszczególnych zgłoszeń.
Minęło kilka lat, technologia poszła do przodu i postanowiliśmy poszukać alternatywy dla FlySpraya, która pozwoliłaby nie tylko nam, ale także naszym klientom, z którymi tworzymy łączone zespoły, tak samo sprawnie pracować.
Basecamp się rozprzestrzenia
I tak oto trafiliśmy na Basecampa – aplikację o bardzo wygodnym, przejrzystym interfejsie, którego sercem są listy zadań z możliwością ich skreślania po ukończeniu. Silną stroną „bejza”, jak niektórzy go pieszczotliwie nazywają, jest też przechowywanie historii konwersacji do poszczególnych zadań. Na uwagę zasługuje także funkcjonalność odpowiadania na wątki bezpośrednio z e-maila (bez konieczności wchodzenia do systemu przez przeglądarkę).
Zdaje się, że nie my jedni doceniliśmy jego prostotę – dzisiaj korzysta z niego kilkaset tysięcy firm z całego świata. Basecamp jest tworzony i utrzymywany przez rozproszony zespół – część osób pracuje w Europie, część w USA, jeszcze inni na paru innych kontynentach.
Słuchać użytkowników czy nie słuchać?
Nie pamiętam już dokładnie, jak trafiłem na książkę, którą napisali autorzy tej niezwykle popularnej aplikacji – ale czytając ReWork, o której mowa, trafiłem na opis ich doświadczeń i podejścia do feature requests.
Oczywiście, na całym świecie firmy, które pozwalają użytkownikom przesyłać sugestie zmian, zawsze stają przed problemem: czy traktować zgłoszenie jako sugestię dodania nowej funkcjonalności, zmiany istniejącej, czy zgłoszenie błędu?
Feature requests przesyłane są dzisiaj za pomocą popularnych widgetów, „wszywanych” w bok ekranu podobnie do widgetów umożliwiających przejście do social mediów czy otwarcie chatu z konsultantem. Są wszechobecne – znajdziemy je nie tylko w systemach IT dostępnych z chmury, ale także na stronach internetowych.
Im mniej opcji, tym bardziej użyteczny interfejs?
Ze względu na popularność Basecampa jego twórcy otrzymują co miesiąc ogromną ilość propozycji i sugestii ulepszeń. Pochodzą one od użytkowników wywodzących się z różnych krajów i kultur, pracujących nad różnymi typami projektów.
Według autorów ReWork najważniejsze jest ostrożne nastawienie do tego tematu. Piszą oni między innymi (tłumaczenie własne):
- […] Jeżeli dopasowujesz ciągle swoją aplikację do wymagań obecnych klientów, wcale nie musi ona być bardziej atrakcyjna dla nowych klientów. Pamiętaj, że obecni klienci mogą odwrócić się od Ciebie – a jeżeli odejdą, zostaniesz z produktem, który dopasowałeś do kogoś, kto go już nie potrzebuje […]
- […]Wielu klientów wytyka nam, że nasze oprogramowanie jest mniej funkcjonalne niż konkurencji. Irytuje ich, że nie chcemy dopasować go do ich wymagań. Ale dla nas to, że oprogramowanie czegoś nie robi to taki sam powód do dumy, że robi coś innego. Projektujemy oprogramowanie, aby było jak najprostsze, bo wierzymy, że większość oprogramowania jest zbyt skomplikowana: za dużo funkcji, za dużo przycisków […].
- Ludzie wierzą, że aby pokonać konkurencję trzeba oferować więcej. Jeśli konkurent oferuje 4 funkcje, powinieneś mieć 5 (lub piętnaście, lub dwadzieścia pięć). […] Kiedy dasz się wciągnąć w wyścig zbrojeń […], jesteś cały czas w defensywie. Zamiast przewodzić, podążasz {za rynkiem i konkurencją}. […] Aby pokonać konkurencję, oferuj mniej niż konkurenci. Rozwiązuj proste problemy, a trudne zostaw do rozwiązania konkurencji[…].
Jednocześnie, liderzy 37signals wdrażają do produktu tylko te sugestie, które spełniają łącznie poniższe dwa kryteria:
- Powtarzają się regularnie i duża liczba użytkowników prosi o ich dodanie;
- Ewidentnie pasują do strategii i niszy rynkowej produktu.
Proste? Proste. Szokujące? Na pewno. Łatwo pisać o tym na blogu, trudniej wdrożyć w codziennej praktyce projektowej. 🙂
Autorzy książki nie wspominają, jakich dokładnie używają metod do testowania i oceny usability swoich produktów. Ale pomóc może fakt, że odnieśli ogromny sukces rynkowy, a ich firma wyceniana jest na setki milionów dolarów, co ciekawe, zdobyła tę pozycję dzięki ergonomicznemu, intuicyjnemu oprogramowaniu – bez pomocy w postaci zewnętrznego finansowania lub funduszy kapitałowych.
Czytaj również:
„Nowy PORTAL PACJENTA LUX MED już działa”
„Optymalizacja usability strony internetowej dla DM BOŚ S.A.”
Sprawdź też:
User Experience Design, makiety UX i projekty UI dla sieci hoteli PURO