Przetwarzanie myśli w energię

Od dostarczenia briefu do dowiezienia projektu myśl ewoluuje na wielu płaszczyznach. Rodzi się z potrzeby Klienta: by sprzedać produkt X, by poprawić swój serwis lub w jakikolwiek inny sposób przeznaczyć swój budżet na działania reklamowe. Potrzeba w ten lub inny sposób doprowadza klienta w czułe objęcia agencji. Nieoszlifowana myśl zostaje przekazana specjalistom w nadziei otrzymania spełniającego wszelkie swe założenia diamentu.

…Luźny obraz procesu projektowego okiem UX’a

(Żródło grafiki: http://www.gfktechtalk.com/wp-content/uploads/2012/01/Digital-eye.jpg)

Przekuć myśl w ideę

Myśl przelewana jest na papier. Powstaje brief, który po kolei trafia do wszystkich zainteresowanych działów. Lecz po kolei. Załóżmy, że nasza myśl wymaga doprecyzowania. Najpierw trzeba ją przekuć w ideę – zarządzamy tzw. (fanfary) burzę mózgów. Do tego celu potrzebujemy wstępnego założenia, osoby prowadzącej projekt, stratega i kogoś kreatywnego. Należy ich zamknąć na kilka godzin w szczelnym pomieszczeniu, dostarczać płyny i nie wypuszczać do czasu wykrystalizowania się pełnowartościowej idei.

Po zaliczeniu tego etapu przetworzona myśl przechodzi do rąk stratega. Idea ma zostać ubrana w mechanizmy mające na celu dotarcie do jak największej liczby odbiorców i zakorzenienie się w ich umysłach na tyle, by klient osiągnął cel projektu X. Strateg zbiera dane, bada, analizuje i przyporządkowuje metody osiągnięcia sukcesu przez naszą ideę. Idea zyskuje założenia oraz wytyczne.

Uczynić ideę lekkostrawną

Powstaje jednak pytanie – jak przełożyć ideę i wytyczne na język obrazu? Mamy zarekomendowane mechanizmy, konkretnie określoną grupę odbiorców oraz spajającą to wszystko myśl przewodnią, być może nawet linię kreatywną.

Architekt informacji, user experience designer, usability ninja (*wiemy, że istnieje, ale nikt go nie widział), czy jak tam nazwiemy naszego specjalistę od użyteczności, otrzymuje zadanie nadania idei wstępnej formy. Ponownie, zależnie od wielu zmiennych, takich jak czas czy budżet, UX (potoczna nazwa) czyni wstępne przygotowania. Polegają one na analizie dotychczasowej ewolucji myśli w ideę oraz przyporządkowanych jej wytycznych. W najlepszym przypadku ma możliwość przeprowadzenia badań na grupie docelowej, w optymalnym zaś używa „Mocy” i korzysta ze swojej bogatej wiedzy dotyczącej mechanizmów poznawczych konkretnych grup użytkowników (określonych wcześniej przez stratega, a zwanej user experience), ich przyzwyczajeń, zachowań oraz ograniczeń. Inaczej przecież będziemy mówić do nastolatka, inaczej do osoby dorosłej, a jeszcze inaczej do seniora. Być może projekt wymaga konkretnej architektury informacji czy wprowadzenia ułatwień dostępu (accessibility), lub polega na wskazaniu luk w użyteczności danego serwisu?

Nasz projektant zatem tworzy zależnie od wymagań:

1.     Makiety (zwane też siatkami funkcjonalnymi, schematami lub pieszczotliwie siatuniami) – schematyczne szkice wstępne serwisu lub aplikacji. Dzięki nim klient, ale także w późniejszych etapach osoba dokumentująca projekt, grafik czy programista są w stanie wyobrazić sobie układ elementów i zasady ich działania. Schematy muszą być przejrzyste i zawierać taki obraz funkcjonalności, by już na tym etapie osoba mająca w nie wgląd była w stanie swobodnie orientować się, jak co powinno działać.

                (Źródło grafiki: http://vip.cs.utsa.edu/classes/cs4393f2005/images/MediaConsoleMockupSmall.gif)

2.     Schemat przepływu – pokazuje logiczne zależności między funkcjonalnościami, przepływ danych lub scenariusz poruszania się użytkownika, od rozpoczęcia przygody z serwisem do osiągnięcia wyznaczonego celu (zakupu, kontaktu, dostępu do konkretnych informacji etc.)

               (Źródło grafiki: http://www.breezetree.com/flow-charts/basic-flowchart.png)

3.     Prototyp – inna forma prezentacji założeń funkcjonalnych, w których łączymy element schematyczny ze scenariuszem. Dzięki temu jesteśmy w stanie przedstawić klientowi bliższy obraz projektu X, gdzie konkretne przyciski kierują nas do konkretnych podstron/funkcjonalności. Prototyp umożliwia poruszanie się w widmie naszej strony, nie umożliwia jednak realizacji założeń bardziej skomplikowanych funkcjonalności.

4.     Dokumentację funkcjonalną – o ile projektant jest także osobą dokumentującą, jest to masywny plik tekstowy, w którym na podstawie schematów opisane jest co i jak działa.

Pogodzić jedynie słuszne obrazy

Wynik pracy projektanta na ogół przedstawiany jest klientowi. Akceptacja powoduje przejście w ręce grafików szkieletu naszego projektu X w formie myśli przeistoczonej w ideę, z zastosowaniem konkretnych mechanizmów, których założenia przedstawione są w formie przejrzystych schematów (jest to przykład zdania, które w żadnym wypadku nie powinno pojawić się w dokumentacji funkcjonalnej). Brak akceptacji powoduje dyskusje mające na celu pogodzenie (często bardzo sztywnych) ram funkcjonalnych z wyobrażeniem klienta o projekcie oraz realiami (budżetem). Dyskusje tego typu mogą występować praktycznie na każdym etapie przekuwania myśli w energię, gdyż każda ze stron ma swój jedynie słuszny obraz finalnej wersji projektu. Z jednej strony klient wali pięścią w stół i mówi, że białe ma być czarne a czarne różowe, projektant łapie się za głowę i każe słuchać specjalisty, a psychoanalityk account managera zaciera chciwie rączki w oczekiwaniu na kolejne spotkanie ze swoim pacjentem.

Po osiągnięciu konsensusu wszyscy są szczęśliwi, deadline jest coraz bliżej, a myśl może zostać obleczona w obraz i słowa. Jakkolwiek copywriter jest nieco spokojniejszy przy doborze słów wypełniających przestrzeń na ekranie, tak grafik interpretuje schematy i obleka je w formę i kolory.

Po ponownej akceptacji klienta całość jest zbierana i trafia w ręce magików, którzy dzięki magii kodów nadają naszemu projektowi życie i ostatecznie przetwarzają naszą myśl w energię. Projekt X tworzy całość i jest gotowy pomknąć po światłowodach do umysłów naszych odbiorców.