Czego życzyłbym samemu sobie jako projektant(owi) i całej branży w nowym roku?

1) Samych dobrych briefów od klientów 🙂

Chciałbym dostawać zapytania, które jasno określają cele i kontekst projektu, grupę odbiorców - czyli definiują problem biznesowy, a nie przechodzą od razu do szczegółów rozwiązania. Niestety cały czas spory procent zapytań, to listy funkcji serwisu albo wręcz opisy interfejsu bez jasno opisanych celów, modelu biznesowego, opisu funkcjonowania usługi na poziomie organizacyjnym (procesy obsługi, systemy wspierające, możliwości pozyskania treści), a nie na poziomie makiety. Czyli bez tego, co naprawdę istotne.

Wydaje mi się, że ciągle wiele zapytań powstaje w ten sposób, że rozsyła się po firmie maile z prośbą do pracowników o wypisanie wszystkich potencjalnych funkcji serwisu, co prowadzi do wyprodukowania długiej listy feature-ów, które w żaden sposób nie wiążą się ze sobą i często nie mają sensu (np. nieśmiertelne forum dyskusyjne w serwisie korporacyjnym, newsy PAP w serwisie transakcyjnym itp.). Taka lista życzeń bez żadnej obróbki ląduje w briefie jako wymagania projektu - co jest najgorszym możliwym podejściem!

Niektórzy klienci próbują w briefie słowami projektować wygląd serwisu. Oto fragment z pewnego nowego zapytania, które jest dla mnie dobrym anty-przykładem (cytuję, bo to przetarg publiczny):

Wszystkie strony portalu będą wyposażone w 2 niezależne menu - poziome i pionowe:
- menu główne (poziome) - stałe zakładki, zawierające treści informacyjne zmieniane za pomocą panelu zarządzania portalem (CMS),
- menu dodatkowe (pionowe) - w pełni zmieniane z poziomu panelu zarządzania portalem (CMS).
Wszystkie podstrony portalu będą oparte na strukturze dającej możliwość dostosowania sposobu wyświetlania informacji do aktualnych potrzeb.

5.1. Nagłówek – będzie elementem wspólnym dla wszystkich podstron portalu. Będzie to obszar wizerunkowy zawierający grafikę związaną z projektem, logo oraz pole wyszukiwarki. Nagłówek będzie stałych rozmiarów, jego szerokość zajmie całą szerokość strony. Będzie zawierał delikatne elementy animacji wykonanych np. w technologii flash. Panel zarządzania portalem będzie umożliwiał zmianę nagłówka zarówno dla strony głównej, jak i dla pozostałych podstron głównych utworzonych działów. Dla stron poszczególnych działów portalu stworzone zostaną nagłówki odpowiadające tematyce tych działów. Będą one zawierały dodatkowo:
- nazwę działu,
- zdjęcie związane z tematyką działu,
- drobne szczegóły wyróżniające je od podstawowego nagłówka.

5.2. Menu główne – będą tworzyć przyciski, których nazwa oraz adres docelowy będą edytowalne z poziomu panelu zarządzania portalem. Efekty najazdu i zjazdu z przycisków będą animowane np. za pomocą wykorzystania technologii uniwersalnej , która zapewni tą samą funkcjonalność dla komputerów PC i platform mobilnych.. Kliknięcie któregoś z przycisków przeniesie użytkownika do odpowiedniego działu portalu.

5.3. Menu dodatkowe – w tej części będzie się znajdować menu nawigacyjne po podstronie portalu, czyli wszystkie przyciski prowadzące do poszczególnych działów portalu. Na stronie głównej menu dodatkowe będzie zawierało pierwsze i drugie zagnieżdżenie poziomu przycisków. We wszystkich działach portalu (z wyjątkiem strony głównej), poniżej elementów menu dodatkowego, będą się znajdować dodatkowe pola:
- Najnowsze artykuły – zawierające domyślnie 10 nagłówków z krótką treścią wstępną ostatnio napisanych artykułów wypisanych zgodnie z porządkiem chronologicznym wg żądanego kryterium sortowania (możliwość zmiany ilości artykułów, a także kryteriów ich sortowania w widoku, np. wg kolejności alfabetycznej tytułów, wg kolejności pojawiania się, wg ilości odwiedzin itp., z poziomu zarządzania stroną w panelu zarządzania portalem),
- Najczęściej czytane artykuły – zawierające domyślnie 10 nagłówków z krótką treścią wstępną ostatnio napisanych artykułów wypisanych zgodnie z porządkiem chronologicznym według żądanego kryterium sortowania (możliwość zmiany ilości artykułów),
- Banery – zawierający banery reklamowe o sprecyzowanych parametrach oraz formacie.

(...) itp. itd.

Uff, nie ma w tym nic przydatnego. Drogi Kliencie jeśli potrzebujesz zatrudnić projektanta, to nie próbuj wykonywać za niego jego pracy. To czego projektant potrzebuje to cel i kontekst biznesowy. Z wymyśleniem funkcjonalności i zaprojektowaniem szczegółów interfejsu sam sobie wtedy poradzi - za to mu przecież płacisz. Nie da się przygotować sensownego rozwiązania jeśli cały czas operujemy na poziomie obrazków bez osadzenia w biznesie i potrzebach użytkowników.

Jeśli nie jesteś pewny czego potrzebuje dostawca albo nie wiesz jak to opisać, to żadna ujma - zawsze możemy się spotkać, porozmawiać, pomóc spisać wymagania.

Service design - czyli coś co niektórzy mogą postrzegać jako kolejny modny buzzword - jest dla mnie m.in. sposobem na przeniesienie rozmowy o projektach z poziomu szczegółów konkretnych rozwiązań na szerszy poziom biznesowy.

2) Większej liczby projektów aplikacji mobilnych

Patrząc na swój plan prac na sam styczeń 2012 wierzę, że to życzenie ma akurat duże szanse się spełnić 🙂 Użytkownicy smartfonów stanowią już całkiem pokaźną i atrakcyjną grupę konsumentów, rynek tabletów na pewno będzie rosnąć. Wersja mobilna serwisu WWW jest już standardem każdego prawie zapytania. Wygląda na to, że w 2012 aplikacje mobilne przestaną być wisienką na torcie, a staną się kolejnym istotnym kanałem obsługowym, sprzedażowym, marketingowym.

3) Zaangażowania projektantów interakcji w projektowanie interfejsów urządzeń

Na świecie to normalne - w Polsce ciągle ewenement. Oczywiście pewnie w naszym kraju po prostu nie powstaje wiele tego typu projektów, ale można powiedzieć że nie ma współpracy między projektantami wzornictwa przemysłowego, a projektantami UX. Będąc jurorem w konkursie Dobry Wzór 2011 zwróciłem uwagę na raczej kiepskie wykonanie interfejsów produktów elektroniki użytkowej, które zostały nominowane.

A na przykład ubiegłoroczny case termostatu Nest (startup byłych pracowników Apple) pokazuje, że dobry interfejs może zmienić pozornie nieciekawe urządzenie w rewolucyjny produkt.

Bardzo chciałbym pracować nad tego typu projektami w nowym roku.

(O projektowaniu interfejsów urządzeń pisałem w zeszłym roku tutajtu.)

4) Śmierci eksperckiego "audytu usability"

Bo to jakiś relikt z początków branży około 2005 roku 🙂 Nie chodzi mi tutaj o samą metodę, ale o sens takich projektów. Powiedzmy sobie szczerze: klient tak naprawdę nie potrzebuje audytu, ale przeprojektowania swojej aplikacji. Dlaczego więc nie zaangażować specjalisty od razu do projektowania zamiast audytu? Po co komu kilkusetstronicowy dokument z opisem błędów, jeśli można je od razu poprawić? I tak będzie do tego później potrzebny projektant. A dla projektanta taki dokument jest generalnie mało przydatny, bo sam dostrzeże opisane problemy.

Wszystkiego dobrego 🙂