Wydajny proces projektowania responsywnego

Jak wygląda Twój responsywny proces projektowania? Czy czujesz, że to jest skuteczne? Poniższy artykuł jest fragmentem rozdziału Bena Callahana „Responsive Process”, opublikowanym po raz pierwszy w wersji eBook Smashing Book 5 (spis treści). — wyd.

„Wybrany respondent tego zapytania ofertowego zapewni naszemu zespołowi trzy statyczne opcje projektowe do oceny”. Nigdy nie byłem wielkim fanem podejścia do projektowania z wieloma opcjami, ale rozumiem – czasami klient tego potrzebuje.

„Każda z tych opcji zapewni projekt dla trzech unikalnych układów: strony głównej, strony aukcji, strony szczegółów”. W porządku. Teraz mamy do dziewięciu statycznych plików projektowych. To trochę wymyka się spod kontroli.

„Każdy z tych unikalnych projektów stron powinien uwzględniać rozmiary urządzeń mobilnych, tabletów i komputerów stacjonarnych”. Nigdy nie byłem świetny z matematyki, ale umiem to wyliczyć. Dwadzieścia siedem statycznych plików projektowych?! Nie wydarzy się.

To jest prawdziwe zapytanie ofertowe, które otrzymałem nie tak dawno temu. Okazuje się, że klient był bardzo skłonny do bardziej efektywnego podejścia. Ale to doświadczenie naprawdę dało mi do myślenia… Najtrudniejszą rzeczą w robieniu tego wszystkiego nie jest robienie tego. Pracuje z ludźmi, kiedy robisz te rzeczy.

Widzisz, prawie każdy potencjalny klient ma już stronę internetową . Dla nas oznacza to, że większość klientów przychodzi do tego z zestawem oczekiwań, wraz z własnym bagażem z poprzednich projektów internetowych. Ten bagaż może mieć drastyczny wpływ na podejście klienta do projektu — i na Ciebie. Aby zmniejszyć negatywne skutki tych oczekiwań, odkryłem, że najlepszym sposobem radzenia sobie z nimi jest bycie tym, który je ustala.

Moim celem w tym rozdziale jest pomóc Ci odnieść większy sukces w projektach internetowych, zaczynając od początku ; pracując od pierwszego dnia, aby pomóc klientowi określić oczekiwania dotyczące tego, co ma się wydarzyć, oraz pracując przez cały cykl życia projektu, aby robić to samo.

Kluczowe różnice w procesie projektowania responsywnych stron internetowych

Zanim otworzysz swój ulubiony edytor tekstu, zanim otworzysz Macaw, zanim wyciągniesz szkicownik lub zaczniesz rzeźbić z tekstem, musisz pomóc klientowi zrozumieć ten proces. Jest na to wiele sposobów, a moim najmniej ulubionym jest po prostu sprzedawanie ich w nowym procesie. Z mojego doświadczenia wynika, że ​​wczesne wykazanie wartości w swoim sposobie myślenia — nawet przed podpisaniem umowy — jest najlepszym podejściem. Daje to Twojemu klientowi pewność, że wiesz, o czym mówisz, ale oznacza to również, że musisz zdobyć jego zaufanie, aby wypróbować nowy sposób.

Aby to zachęcić, mój zespół ma cztery ideały , o których staram się pamiętać podczas interakcji: współpraca, iteracja, adaptacja i ustalanie priorytetów. Pokrótce wyjaśnię, dlaczego te konkretne pomysły będą trzymać Cię na prostej i wąskiej.

Współpracować

Wiem wiem. Wszyscy na całym świecie mówią o współpracy io tym, jak jest ona potrzebna do wykonania wspaniałej pracy. Wiesz co? To prawda. Oczywiście musisz współpracować w swoim zespole, ale w dzisiejszych czasach potrzebny jest inny rodzaj współpracy — współpraca z klientem . Mam dla Ciebie ważne przypomnienie: klienci to też ludzie. Mogą nie mieć Twojej wiedzy, jeśli chodzi o projektowanie i tworzenie stron internetowych, ale wiedzą o wiele więcej o swojej działalności niż ty kiedykolwiek będziesz.

Znowu zaczyna się od początku. W Sparkbox szukałem sposobu na większą współpracę w pozyskiwaniu nowych klientów. W ramach tego przyjęliśmy nowe podejście do pisania szacunków. Zamiast klienta przychodzącego do nas i wyjaśniającego swój projekt, abyśmy mogli zniknąć na tydzień i wrócić z idealnym rozwiązaniem, zaprosiliśmy go do pomocy w oszacowaniu. To bardzo proste — nazywamy to szacowaniem opartym na współpracy , a klienci to uwielbiają.

Zaczynamy od podstawowego arkusza kalkulacyjnego Google, który ma kilka regulowanych pól i oblicza, ile według nas będzie kosztować wykonanie pracy. Zaczynamy od szerokich zakresów, ponieważ robimy to na bardzo wczesnym etapie — zazwyczaj po zaledwie 30-minutowej rozmowie telefonicznej. Następnie dzielimy się nim z klientem i wspólnie nad tym pracujemy.

Oto dlaczego jest to ważne: współpracujemy od pierwszej rzeczy, którą robimy z naszymi klientami. Chcemy, aby wiedzieli, że dodajemy więcej wartości, gdy z nimi pracujemy, a nie dla nich. To tylko jeden sposób, w jaki wkładamy pieniądze tam, gdzie są nasze usta.

Zapraszamy również naszych klientów do kanałów komunikacji naszego zespołu z nami. Jesteśmy wielkimi fanami Slacka i Basecamp. Narzędzia te zapewniają doskonałe połączenie formalnej dokumentacji i nieformalnej rozmowy, które są potrzebne do ułatwienia wysokiej jakości współpracy.

Podczas otwartego przeprojektowania strony internetowej Reading Is Fundamental Daniela Mall wszyscy ujrzeliśmy, w jaki sposób Dan angażuje swoich klientów w projekt. Brad Frost poszedł o krok dalej, tworząc projekt GitHub o nazwie „Project Hub”, który jest narzędziem do śledzenia postępów w Twoim projekcie.

Pamiętaj, to wszystko to tylko narzędzia. Narzędzia mogą pomóc, ale tak naprawdę potrzebna jest zmiana sposobu myślenia. Mój przyjaciel Kevin Sharon powiedział mi kiedyś coś bardzo przejmującego. Powiedział: „Jeśli nie możesz powiedzieć „Nie”, to nie jest to współpraca”. Nie wiem jak ty, ale miałem wiele relacji z klientami, w których nie miałem prawa się odeprzeć — nawet gdybym wiedział z doświadczenia, że ​​to, o co proszą, nie zadziała. Ci klienci przychodzą do Ciebie z rozwiązaniami, a nie problemami, które należy rozwiązać.

Wstyd się przyznać, ale miałem też relacje z klientami, w których było odwrotnie. Czasami moja frustracja bierze górę i zapominam, że potrzebuję, aby mój klient był częścią projektu. Kiedy słyszymy pomysł od naszych klientów i natychmiast się z nim nie zgadzamy, jesteśmy tak samo winni, jak oni zaprzeczają procesowi współpracy. Wiele studiów internetowych nie chce pozwolić na tego rodzaju współpracę w swoim procesie, często dlatego, że nie wierzą, że ich klienci są wystarczająco kreatywni lub techniczni, aby wnieść znaczący wkład.

Współpraca to droga dwukierunkowa. Przeniesienie swojego spojrzenia na swoich klientów, aby stali się prawdziwymi współpracownikami w swojej pracy, zaowocuje wszelkiego rodzaju nowymi sposobami uwzględniania ich i pomoże ci stworzyć lepszy produkt.

Powtarzać

Regularnie poszukujemy możliwości dostarczenia niewielkiego, wysokiej jakości podzbioru funkcji z niesamowitą szybkością. Podejście takie jak to pokazuje postęp na wczesnym etapie i zapewnia realne możliwości, aby to, czego się nauczyłeś, nadało Ci rozpędu w realizacji projektu.

Jeśli czujesz, że zmiana sposobu działania Twojego klienta może wiązać się z politycznymi wyzwaniami, oto wskazówka dla profesjonalistów (i wyczuwam to w każdym realizowanym przez nas projekcie): praca iteracyjna może pomóc zmienić sceptyków w zwolenników. Większość ludzi jest znacznie bardziej skłonna pozwolić ci wypróbować nowy sposób pracy na małej fazie niż na całym projekcie. Ponownie, głównym celem jest wczesne zademonstrowanie swojej wartości, aby zdobyć zaufanie klienta.

Jednym ze sposobów przejawiania się iteracji jest tworzenie prototypów. Nieustannie poszukujemy możliwości zidentyfikowania znaczącego wyzwania, zaproponowania możliwego rozwiązania, udowodnienia lub obalenia jego słuszności poprzez prototypowanie, rewizję i powtarzanie.

Często szukamy szansy na rozpoczęcie płatnej fazy odkrywania przed rozpoczęciem dużego projektu; pomyśl o tym jak o randkowaniu przed ślubem. Daje to możliwość dowiedzenia się znacznie więcej o projekcie i pracy z tym klientem. Obie strony są w stanie określić, czy stosunek pracy jest odpowiedni.

Początkowe zaangażowanie może przybierać różne formy, ale głównymi celami są:

1. Lepiej zrozum zakres projektu
2. Zidentyfikuj i udowodnij możliwe rozwiązania największych wyzwań
3. Dowiedz się, czy dopasowanie klienta/dostawcy jest właściwe
4. Udowodnij, że jesteś zdolny
5. Zarabiaj za powyższe

Twoi klienci docenią to podejście, a Ty zbudujesz świetny fundament pod przyszłą pracę. A jeśli nauczysz się czegoś, co radykalnie zmieni twoje rozumienie projektu, będziesz zaangażowany tylko w małą fazę. Ta nauka w znacznym stopniu poinformuje Cię o kolejnym kroku w procesie i popchnie Cię w kierunku lepszego rozwiązania.

Mamy klienta, z którym współpracujemy od wielu lat; w rzeczywistości niedawno rozpoczęliśmy z nimi nasz trzydziesty projekt. Dla mnie to znak, że znaleźliśmy korzystny dla obu stron sposób współpracy — oni dostrzegają wartość w tym, co oferujemy, a my jesteśmy z nich twórczo i technicznie zadowoleni. Próbując wskazać, co sprawiło, że ta relacja odniosła sukces, wciąż wracam do naszego podejścia iteracyjnego. Niejednokrotnie przychodzili do nas z problemem i pomysłem jak go rozwiązać. Zamiast po prostu odgryzać coś, co może być 12-tygodniowym projektem, regularnie sugerowaliśmy mniejsze, iteracyjne fazy, które testują możliwe rozwiązania i mają znacznie niższą początkową inwestycję. Takie podejście pozwoliło nam zdobyć ich zaufanie. To zaufanie jest niezbędne do tworzenia trwałych relacji, a iteracja jest podstawą tego wszystkiego.

Przystosować się

Kiedy na scenie pojawiło się responsywne projektowanie stron internetowych, pamiętam, że uderzyła mnie idea, że ​​elastyczność nieodłącznie związana z produktem, który tworzyliśmy, wkraczała w nasz proces. Samantha Warren ujęła to najlepiej: „Twój proces powinien być tak samo responsywny, jak produkty, które projektujesz”.

Prawda jest taka, że ​​nie ma idealnego procesu dla tego rodzaju pracy. Ty i ja musimy pogodzić się z ograniczeniami, które nam stawiają. Każdy projekt, klient, zakres, harmonogram, budżet, zespół, stos technologiczny, macierz wsparcia są inne. Organizacje, które odnoszą sukcesy w tym biznesie, to te, które mogą działać w ramach projektu i nadal wykonywać pracę ponadczasową.

Moje poglądy na temat procesu są zdecydowanie trudne do wytłumaczenia klientowi. Mając taką możliwość, prawdopodobnie zamknąłbym kilka kluczowych osób (w tym klientów) zaangażowanych w projekt w pokoju na kilka tygodni i dałbym im mandat, aby to rozpracowali. Weź to ode mnie, klienci nie lubią być zamykani w pokoju na całe tygodnie.

Zamiast tego musimy znaleźć równowagę między bardzo sztywnym procesem (w którym każdy krok jest ułożony i udokumentowany) a improwizacją (gdzie ufamy zespołowi, że znajdzie najlepsze podejście na bieżąco). Istnieje wiele czynników, które należy wziąć pod uwagę, aby znaleźć tę równowagę. Oto trzy na początek: wielkość zespołu; doświadczenie zespołu; oraz krytyczność projektu.

Wielkość zespołu

Dużo łatwiej jest pozwolić na dużą elastyczność w procesie, gdy masz bardzo mały zespół. Dwie lub trzy osoby siedzące w tym samym pomieszczeniu będą mogły śledzić to, co się dzieje, bez zbytniej struktury. Jeśli liczebność zespołu wynosi sześć lub siedem, zaczyna być trudno zrozumieć wpływ każdego gracza na postęp całego projektu. Zwiększ swój zespół do dziesięciu, piętnastu lub więcej, a stanie się to prawie niemożliwe.

To dla mnie bardzo osobiste. Kiedy po raz pierwszy założyłem Sparkbox z moimi partnerami, było nas tylko czterech. Każdy z nas miał dość dobrze zdefiniowaną rolę i byliśmy w stanie działać dość skutecznie bez dużego procesu. Ponieważ wszyscy siedzieliśmy razem w jednym dużym pokoju, stale komunikowaliśmy się o wszystkich aspektach naszej działalności.

Teraz mamy 23 pełnoetatowych pracowników plus trzech praktykantów. Z pewnością nie rozwijaliśmy się tak szybko, jak w niektórych miejscach — jesteśmy bardzo świadomi naszego rozwoju — ale wyrażenie „bóle wzrostu” nadal brzmi prawdziwie. Musieliśmy ciągle eksperymentować, kiedy, co i jak się komunikować. Tylko poprzez te eksperymenty możemy znaleźć odpowiednią dla nas równowagę.

Lekcja z tego jest taka, że ​​wielkość Twojego zespołu wpływa na rodzaj procesu, który możesz zastosować w danym projekcie. Ogólnie rzecz biorąc, im więcej osób masz w projekcie, tym większej sztywności potrzebujesz. W miarę zmniejszania się rozmiaru Twojego zespołu możesz ujść na sucho z mniej formalnym procesem. Obowiązkiem kierownika projektu jest monitorowanie pulsu zespołu i dostosowywanie procesu, aby wszystko przebiegało płynnie.

Doświadczenie zespołu

Kiedy pracujesz z niedoświadczonym zespołem, bardziej rygorystyczny proces pomoże utrzymać wszystkich na tej samej stronie. W rzeczywistości uważam, że niedoświadczony zespół potrzebuje konkretnego procesu jako kontekstu zdobywania doświadczenia. Dopiero po wykazaniu sukcesu w bardziej sztywnym środowisku możesz zacząć odrywać warstwy procesu, pozwalając zespołowi na większą swobodę w jego działaniu.

To znowu jest dla mnie dość osobista koncepcja, głównie ze względu na sposób, w jaki organizujemy zespoły do ​​projektu. Do każdego realizowanego przez nas projektu tworzymy unikalny zespół; nawet w trakcie projektu możliwe jest, że będziemy rotować ludzi w zespole i poza nim. Może to stwarzać wyzwania, zwłaszcza jeśli doświadczenia tych osób są bardzo różne. Przede wszystkim oznacza to, że musimy być świadomi faktu, że różni ludzie potrzebują różnych poziomów procesu, aby odnieść sukces. Nasi kierownicy projektów uważnie to monitorują i dostosowują w razie potrzeby.

Mamy wielu doświadczonych projektantów i programistów, więc ta równowaga polega głównie na rozproszeniu mniej doświadczonych ludzi. Dodanie jednego lub dwóch nowszych programistów do wysoko wykwalifikowanego zespołu podniesie poprzeczkę dla wszystkich. Nowi deweloperzy będą uczyć się od bardziej doświadczonych, a bardziej doświadczeni będą uczyć się, ucząc nowych deweloperów. To daje wygraną!

Krytyczność projektu

Pomysł, jak krytyczny jest projekt, pochodzi od dżentelmena o nazwisku Alistair Cockburn, jednego z pierwotnych sygnatariuszy Manifestu Agile. W swoich pismach o „Metodach kryształowych” Cockburn opisuje zakres krytyczności, uzupełniając to stwierdzenie.

Wady powodują utratę:

1. Komfort (nie krytyczny)
2. Pieniądze uznaniowe (nieco krytyczne)
3. Niezbędne pieniądze (krytyczne)
4. Życie (bardzo krytyczne)

Im bardziej krytyczny jest nasz produkt, tym sztywniejszy powinien być nasz proces. Mogłeś tego doświadczyć, jeśli pracowałeś zarówno dla małych, jak i dużych firm. Małe, lokalne firmy mają tendencję do zapewniania większej swobody w sposobie pracy, ponieważ mają mniejszą stawkę (mniejsza krytyczność); duże firmy mają znacznie więcej do stracenia (większa istotność), jeśli Twój proces nie przynosi dobrych wyników.

Kiedy dopiero zaczynałem pracę w tej branży, pracowałem prawie wyłącznie z małymi, lokalnymi firmami. Zarządzałem projektami za pomocą karteczek samoprzylepnych, e-maili i rozmów telefonicznych co dwa tygodnie. Teraz jestem związany ze znacznie większymi organizacjami. Zarządzanie tymi projektami wymaga od nas udziału w codziennych stand-upach, retrospekcjach i spotkaniach dotyczących planowania sprintów. Budujemy wypalenia, pracujemy w JIRA (oprogramowanie do śledzenia problemów) i obliczamy naszą prędkość bardziej, niż chciałbym przyznać. Wszystko to z powodu krytyczności pracy — mały procent wystarczająco dużej liczby to wciąż ogromna liczba. Te większe firmy rozumieją to i mają proces, który chroni je przed tymi ogromnymi stratami.

Priorytet

W miarę zmniejszania się rozmiaru ekranów, które projektujemy, zmniejszają się również nasze opcje priorytetu komunikacji. Pomyśl o tym: zazwyczaj używamy takich rzeczy, jak rozmiar, pozycja, kolejność i kontrast, aby pomóc użytkownikom zrozumieć, na czym powinni się skupić. Na małym ekranie niewiele można zrobić z rozmiarem obiektu lub pozycją nagłówka. Po prostu nie mamy takich samych swobód, jakie mamy, gdy skupiamy się na doświadczeniach na większym ekranie.

Z tego powodu bardzo ważne jest zrozumienie priorytetu treści i funkcjonalności w całym systemie. Łukasz Wróblewski znakomicie zachęcił nas do zastanowienia się najpierw nad urządzeniami mobilnymi, aby pomóc naszym klientom w dojściu do tego, co naprawdę ważne. Prawda jest taka, że ​​bez solidnego zrozumienia priorytetu responsywne projektowanie stron internetowych to tylko zgadywanie.

Zachęcamy do tego naszych klientów, zmuszając ich do liniowego myślenia na bardzo wczesnym etapie procesu. (W poniższej sekcji „Załatwienie sprawy” podzielę się rodzajami narzędzi, których używamy do tego.) Myślenie linearne ma tę zaletę, że wymaga od ludzi wybrania tego, co jest najważniejsze, i to jest ten priorytet, co do którego potrzebujesz porozumienia. Ustanowienie tego od razu w projekcie stworzy akceptowany fundament, na którym można będzie budować, i dostarczy odpowiedzi na wiele pytań, które będziesz zadawać w dalszej części projektu.

Niedawno mieliśmy projekt, w którym nasz klient przyszedł do nas ze złożonymi już makietami panoramicznymi. Zrobili to, aby zaoszczędzić trochę pieniędzy i byliśmy szczęśliwi, mogąc z nimi współpracować w ten sposób. Gdy zaczynaliśmy projektować, klient nie był zadowolony z naszej pracy. Dopiero w połowie projektu zdaliśmy sobie sprawę, że makiety szerokoekranowe nie określały odpowiednio priorytetu treści i funkcjonalności. To było sedno problemów, które mieliśmy. Skończyło się na tym, że wróciliśmy, aby przeprowadzić analizę treści i ustalić priorytety, aby odzyskać impet projektu. Gdybyśmy zrobili to wcześniej, moglibyśmy pracować wydajniej przez cały projekt. Niestety, aby pomóc im zaoszczędzić pieniądze, musieliśmy dokonać pewnych przeróbek, których można było uniknąć, gdybyśmy najpierw położyli odpowiednie fundamenty! Wyciągnięta lekcja — ustal priorytet wcześnie.

Cztery ideały

Przechodząc do następnego projektu, pamiętaj, że musisz włączyć do projektu swojego klienta. Szukaj okazji do współpracy z nimi, zamiast tylko dla nich pracować. Pamiętaj, że im więcej wcześnie zademonstrujesz wartość, tym większe zaufanie zdobędziesz. Iteracja pomoże Ci to zrobić — nie bój się zaczynać od małych rzeczy! Pamiętaj też, że z pewnością będziesz musiał dostosować swój sposób pracy, aby lepiej odpowiadał potrzebom konkretnego projektu lub klienta. Wreszcie, mocno naciskaj na ustalenie priorytetu treści i funkcjonalności na wczesnym etapie projektu. Przyniesie to korzyści w dalszej części projektu, gdy pojawią się pytania o znaczenie niektórych rodzajów treści.

Poza tymi czterema ideałami, chciałbym przedstawić trochę ram dla ciebie, gdy zastanawiasz się, jaki proces będzie działał w twoim codziennym życiu.

Ramy dla procesu rozważania

Nasz proces zawsze walczy o swoje życie

Jedną z rzeczy, która mnie zadziwia w przypadku większości prezentacji lub procesu pisania, jest to, jak pewni siebie wydają się ludzie, którzy się dzielą. Może jesteśmy odstający, ale nasz proces zawsze walczy o życie. Jeśli pojawi się nowy sposób pracy, wypróbujemy go. Jeśli uważamy, że istnieje nawet wskazówka lepszego sposobu na zrobienie czegoś, będziemy kopać, próbując to odkryć. Tak właśnie jesteśmy okablowani. Odnoszę wrażenie, że wielu z was też jest w ten sposób.

Zgódźmy się, że nasz proces nigdy się nie kończy.

Odejdź od liniowych przejęć

Większość w branży zgadza się, że musimy przestać wyrzucać wyniki przez mur. Zamiast tego wiele osób myśli o tym, jak zreorganizować swoje zespoły w nadziei, że zaangażowanie odpowiednich osób na czas trwania projektu zwiększy empatię członków zespołu i podniesie poprzeczkę dla wszystkich. Trent Walton opisuje to wymownie w swoim poście zatytułowanym „Reorganizacja”. Relacjonuje w nim, że struktura Twojego zespołu często ogranicza rodzaj procesu, z którego możesz skorzystać, i zachęca nas do rozważenia mniejszych zespołów interdyscyplinarnych. Widzieliśmy, że to prawda i przyjęliśmy bardzo podobne podejście. Prawdę mówiąc, nasze wcześniejsze procesy liniowe prawdopodobnie zawsze były nieco nieefektywne. Uważam, że responsywne projektowanie stron internetowych sprawiło, że ta nieefektywność stała się o wiele bardziej oczywista; radzenie sobie z responsywną pracą doprowadziło mnie do rozmów z naszymi klientami na temat ich struktury organizacyjnej — więcej dowodów na to, że RWD naprawdę jest katalizatorem zmian organizacyjnych.

Musimy zaangażować więcej dyscyplin dla większej części projektu. Lubię myśleć o tym jako o wirowaniu przez projekt z oczami mocno skupionymi na produkcie końcowym, na tym, który jest dostarczany. Z każdą spiralą angażujemy wszystkie dyscypliny i zyskujemy większą jasność we wszystkich punktach decyzyjnych. Koncepcja jest prosta: pozwól całemu zespołowi odgrywać rolę przez cały czas trwania projektu. Innymi słowy, rozpoznaj i zaakceptuj wpływ, jaki wprowadzanie zmian w jednym obszarze projektu ma na inne.

Mój zespół i ja wpadliśmy na ten pomysł (spiral przez projekt) dzięki naszym interakcjom z moim mentorem biznesowym. Nazywa się Geoff i jest bardzo bystrym facetem. Był dyrektorem finansowym kilku całkiem dużych organizacji i zrobił karierę pomagając wizjonerskim liderom w zrozumieniu finansów firmy.

Kiedy po raz pierwszy spotkaliśmy się z Geoffem, byliśmy w trybie kryzysowym. Mieliśmy przed sobą duże wyzwanie, z którym ani moi partnerzy, ani ja nie wiedzieliśmy, jak sobie poradzić. Geoff posadził nas wszystkich i poprosił, żebyśmy „zaczęli z myślą o końcu”. Chciał, abyśmy wyjaśnili, jak to będzie wyglądać, gdy przejdziemy przez nadchodzące trudne czasy. Chciał, abyśmy zdefiniowali sukces na ten czas w życiu naszej firmy. Gdy nadal spotykaliśmy się z Geoffem, zacząłem się denerwować. Za każdym razem, gdy siadaliśmy, miałem nadzieję, że udzieli nam rady, której potrzebowaliśmy, aby zacząć rozwiązywać napotkany problem. Zamiast tego ciągle zadawał coraz więcej pytań. Trwało to kilka tygodni i był to dla mnie trudny czas.

Nigdy nie zapomnę spotkania, które odbyłem z Geoffem i moimi partnerami, gdzie wszystko zaczęło nabierać sensu. Nasze spotkanie rozpoczęło się jak wszystkie inne; przeszliśmy przez nasze obecne zrozumienie problemu przed nami i poświęciliśmy trochę czasu na dzielenie się wszelkimi nowymi spostrzeżeniami, które uzyskaliśmy. Dopiero tym razem każdy z nas zaczął dostrzegać pojawiające się rozwiązanie. Nie było to całkowicie jasne, ale zaczęło się wyostrzać. Z trzech rozważanych przez nas opcji, jedna zaczęła wyglądać znacznie bardziej atrakcyjnie niż pozostałe. To, czego nauczyliśmy się w ciągu ostatnich miesięcy, bez wątpienia doprowadziło nas do najlepszej opcji rozwiązania problemu, z którym się borykaliśmy.

Ta lekcja była dla mnie bezcenna. Nauczył mnie, że liniowy proces wymaga od nas podejmowania decyzji, zanim otrzymamy wszystkie informacje. Skąd moglibyśmy wiedzieć wszystko, co musimy wiedzieć, aby stworzyć zestaw makiet, nie biorąc pod uwagę projektu wizualnego? Jak moglibyśmy udoskonalić projekt interfejsu bez eksperymentowania z kodem front-endowym? Kiedy zachowujemy się tak, jakby można było zacząć od treści, potem zaprojektować trochę doświadczenia użytkownika, potem trochę zaprojektować interfejs użytkownika itd., ignorujemy wpływ, jaki każdy z tych elementów ma na inne. Zamiast tego musimy pozwolić im na wzajemne informowanie się. Musimy dać im przestrzeń do oddychania, przystosowania się i wykorzystania tego, czego nauczyliśmy się podczas projektu, aby posuwać się do przodu.

To jest dokładnie ten spiralny proces, przez który popychał nas Geoff. Te tygodnie zadawania pytań pomagały nam zrozumieć problem. Zamiast podejmować decyzję (zatwierdzać projekt interfejsu użytkownika) i iść dalej tak, jakby nigdy się nie zmienił (OK, front-end dev, idź zakodować ten projekt), Geoff zmusił nas do uznania, że ​​nie mamy wszystkich potrzebnych nam informacji podjąć najlepszą decyzję. Geoff chciał, żebyśmy poczekali z decyzją do „ostatniej odpowiedzialnej chwili”.

Próbowałem przełożyć tę ideę spirali na to, co robimy na co dzień, i wylądowałem na takiej wizualizacji:

Proszę umieścić własne dyscypliny w powyższych kawałkach ciasta — obraz jest uproszczony, aby zilustrować podejście. Należy zauważyć, że te kropki nie są produktami dostarczanymi w tradycyjnym sensie. Stanowią one okazję, aby usiąść z klientem i przyjrzeć się swoim postępom w kierunku „jednego rezultatu”. Oznacza to: przestań ulepszać rezultaty, bojąc się, że zawiedziesz klienta. Sprawianie, że makiety wyglądają pięknie w programie Illustrator, jest strasznie nieefektywne, gdy wystarczy szkic na tablicy. Przestaliśmy nawet nazywać je produktami dostarczalnymi i zaczęliśmy nazywać je aktualizacjami .

Ten rodzaj przepływu pracy jest wystarczająco elastyczny, aby można go było używać w dowolnym projekcie, ponieważ można po prostu zamienić rodzaje dyscyplin, które są potrzebne w projekcie. Ceremonia wokół procesu może być bardziej sztywna lub bardziej improwizowana, w zależności od doświadczenia zaangażowanych osób. Kluczem jest upewnienie się, że wszyscy ludzie są zaangażowani.

Takie podejście opóźnia decyzje, dopóki nie uzyskasz właściwych informacji. Uznaje, że decyzje podjęte przez jedną dyscyplinę niewątpliwie wpłyną na inne. To otwiera rozmowę dla zespołu i wymaga udziału wszystkich zaangażowanych. Jest mniej formalny, ale bardziej wydajny. Jest mniej przewidywalny, ale wierzę, że ma potencjał, aby dostarczyć znacznie lepszy produkt.

Zgódźmy się, że musimy szukać wkładu multidyscyplinarnego.

Wydajność jest kluczowa

Gdybyśmy mieli cały czas na świecie, nie musielibyśmy się martwić o nasz proces — moglibyśmy po prostu wypróbowywać różne rzeczy, dopóki nie wpadniemy na świetny pomysł. Ty i ja wiemy, że tak nie jest.

Wiele zmian, które wprowadzamy do naszego procesu w Sparkbox, wynika z tego, że szukamy szybszego sposobu na osiągnięcie czegoś. Obietnica zwiększonej szybkości to także sposób, w jaki zdobywamy możliwości pracy z bardzo utalentowanymi zespołami wewnętrznymi u większych klientów. Każdy szuka wzrostu wydajności.

Zgódźmy się, że dobry proces jest również skutecznym procesem.

Ciągle ewoluuje. Wielodyscyplinarny. Wydajny. Kiedy wskakujemy w te rzeczy, chcę, żebyśmy pamiętali o tych trzech rzeczach. Możemy wykorzystać te pomysły jako filtr, przez który rozważamy nowe podejścia.

Dość teorii

Tyle teorii. Przejdźmy do nakrętek i śrub tej pracy. W naszych projektach internetowych ciągle zadaję sobie trzy pytania:

1. Dla kogo budujemy?
2. Co chcemy, żeby wydobyli z tego doświadczenia?
3. Jak powinniśmy zaprezentować doświadczenie?

Celem jest znalezienie sposobu na powiedzenie właściwych rzeczy (co) we właściwy sposób (jak) właściwym ludziom (kogo). Sekret doskonałej komunikacji wszelkiego rodzaju tkwi w odpowiedzi na te pytania. Oczywiście w całym projekcie będziesz zadawał wiele innych pytań. Pytania typu, jakiego rodzaju wzorców nawigacji należy używać w tej witrynie lub czy naprawdę potrzebujemy reklamy u góry każdej strony? Sugeruję, że posiadanie odpowiedzi kto, co i jak poprowadzi Cię we właściwym kierunku, gdy będziesz odpowiadać na wszystkie inne pytania, które się pojawią.

Mam nadzieję, że przeczytałeś już rozdział Dana Malla (tuż przed tym). W tym wykonuje świetną robotę, zapewniając kontekst dotyczący zrozumienia, z kim się komunikujesz. Jego wyjaśnienia dotyczące rozmów kwalifikacyjnych i spotkań inauguracyjnych poprowadzą cię we właściwym kierunku.

Podobnie następny rozdział autorstwa Eileen Webb dotyczy strategii treści dla twojego responsywnego projektu. To dokładny rozdział, a ona odpowiada na pytania dotyczące tego, co staramy się komunikować lepiej niż ja.

Tak więc pozostała część tego rozdziału poświęcona jest odpowiedzi na trzecie pytanie: „Jak?” Podzielę się z Wami rodzajami narzędzi, które były najbardziej przydatne dla mnie i mojego zespołu w Sparkbox i ufam, że one również pomogą Tobie!

Robienie tego

Jak wspomniałem wcześniej, zrozumienie priorytetu prezentowanych treści i funkcji ma kluczowe znaczenie dla efektywnej komunikacji. Oto kilka sposobów, w jakie ta prawda przejawia się w naszej pracy.

Przewodnik po priorytetach treści

Przewodnik po priorytetach zawartości to „modelowanie zawartości części, częściowy model szkieletowy” (patrz „Przewodnik po priorytetach treści” Emily Gray.); jak model mini treści, w kolejności priorytetów i przy współpracy z klientem. (Zobacz https://bit.ly/content-priority-guide, aby zapoznać się z roboczym przykładem przewodnika po priorytetach treści.)

Przewodnik po priorytetach treści informuje, jakie rodzaje treści powinny znajdować się na każdej stronie. Mogą to być proste rzeczy, takie jak tytuł, główny obraz i treść w poście na blogu, lub znacznie bardziej złożone: weź pod uwagę wszystkie rodzaje treści, których możesz potrzebować na stronie szczegółów produktu w witrynie e-commerce.

Pozwala również na wyjaśnienie każdego rodzaju treści. Jeśli masz krótki opis produktu, przewodnik priorytetowy może powiedzieć: „Jedno zdanie opisujące produkt i co czyni go wyjątkowym”. W przypadku przedmiotu, takiego jak obraz bohatera, możesz podać szczegółowe informacje o kierunku artystycznym zdjęcia, jeśli było to istotne w konkretnym przypadku.

Przewodniki po priorytetach zawartości pomagają również szybko zidentyfikować komponenty wielokrotnego użytku. Jest to bardzo pomocne podczas planowania zarządzania treścią — rozpoznawanie wzorców wielokrotnego użytku oznacza, że ​​możesz zbudować wydajniejszy system do zarządzania treścią.

Co najważniejsze, przewodnik po priorytetach jest uporządkowany według ważności . Prowokuje dyskusję o tym, co jest naprawdę ważne na danej stronie. To ogromnie pomaga, gdy zastanowisz się, jak witryna będzie reagować na różne szerokości widocznego obszaru. A ponieważ nie zawiera rzeczywistej treści, ułatwia świetną rozmowę na temat tego, co i dlaczego jest rodzajem treści, co można łatwo przeoczyć, jeśli natychmiast zaczniesz pisać kopię.

Jeśli Twoi klienci mają trudności z ustalaniem priorytetów (i prawdopodobnie będą), możesz umieścić te decyzje wokół tego, co najważniejsze w arkuszu kalkulacyjnym i dać im opcje do sprawdzenia — podstawowe, średnie, wyższe itp. Wynik jest taki sam: masz lista typów treści z priorytetami dla każdej strony, ale proces dotarcia do niej może wydawać się nieco bardziej przyjazny dla klienta, jeśli ma on pewne opcje.

Architektura informacji

Gdy już dobrze zrozumiesz typy i priorytety treści, które muszą istnieć w systemie, bardzo ważne jest rozważenie, w jaki sposób ta treść powinna być pogrupowana i jakie ścieżki mają przebyć użytkownicy. Takie myślenie ma kluczowe znaczenie dla stworzenia użytecznej witryny.

Niedawno widziałem Aarona Quinna mówiącego o architekturze informacji i powiedział coś, co naprawdę mnie utkwiło. Zasugerował, że możemy zbytnio polegać na naszym zdrowym rozsądku, jeśli chodzi o grupowanie informacji. Zamiast tego poparł nas, abyśmy rozważyli konsensus w sprawie zdrowego rozsądku podczas planowania interakcji naszych użytkowników z tym, co tworzymy. Pozwólcie, że wyjaśnię dlaczego w krótkiej historii.

Mamy klienta, z którym współpracujemy od ponad roku. Uruchomiła bardzo udany produkt SAAS, który pomogliśmy jej zbudować. Ta kobieta jest niesamowicie inteligentna; codziennie pracuje w sieci — z tego żyje. Nie tak dawno rozmawiałem z nią o tym, co będzie dalej z jej produktem i powiedziała mi: „Myślę, że musimy wprowadzić pewne zmiany w zakładkach na naszej stronie”. Przerwałem, ponieważ desperacko próbowałem przypomnieć sobie, gdzie zaimplementowaliśmy karty na jej stronie. Wyczuwając moje zmieszanie, zaczęła wyjaśniać, na co miała nadzieję. Po kilku chwilach zorientowałem się, że mówi o nawigacji. It was eye-opening that this savvy web entrepreneur referred to her navigation as “tabs.”

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

Let's agree that a good process is also an efficient process.

Ever-Evolving. Multidisciplinary. Efficient. As we jump into the nuts and bolts of this stuff, I want us to keep these three things in mind. We can use these ideas as a filter through which we consider new approaches.

Enough Theory

That's enough theory. Let's get into the nuts and bolts of this work. I find myself constantly asking three questions throughout our web projects:

1. Who are we building for?
2. What do we want them to gain from the experience?
3. How should we present the experience?

The goal is to find a way to say the right things (what) in the right way (how) to the right people (who). The secret to great communication of any kind is answering these questions. You will, of course, ask many other questions throughout your project. Questions like what kind of navigation patterns should I use on this site, or do we really need an ad at the top of every page? I'm suggesting that having the answers to who, what and how will lead you in the right direction as you answer all the other questions that come up.

Hopefully, you have already read Dan Mall's chapter (just before this one). In it, he does a great job providing some context around understanding who you're communicating with. His explanations of interviewing and kick-off meetings will move you solidly in the right direction.

Similarly, the next chapter by Eileen Webb is all about content strategy for your responsive project. It's a thorough chapter, and she answers the questions around what it is we're trying to communicate better than I ever could.

So, the rest of this chapter is dedicated to answering that third question, “How?” I'll share with you the kinds of tools that have been the most helpful for me and my team at Sparkbox and trust that they will also help you!

Getting It Done

As I mentioned earlier, understanding the priority of the content and functionality we're presenting is critical to communicating effectively. Here are a few ways this truth manifests itself in the work we do.

Content Priority Guide

A content priority guide is “part content modeling, part stripped-down wireframe” (see “Content Priority Guide” by Emily Gray.); like a mini content model, in priority order, and with client collaboration. (See https://bit.ly/content-priority-guide for a working example of a content priority guide.)

The content priority guide tells you what types of content should exist on each page. These could be simple things like the title, primary image and body copy on a blog post, or they could be much more complex: consider all the content types you might need on the product detail page of an e-commerce site.

It also allows for explanation of each content type. If you have a short description of a product, the priority guide may say, “One sentence describing the product and what makes it unique.” For an item like a hero image, you could provide some details about the art direction of the photo if that was relevant for a specific case.

Content priority guides also help you quickly identify reusable components. This is very helpful as you plan out the management of that content — recognizing reusable patterns means you can build a more efficient system to manage the content.

Most importantly, a priority guide is in priority order . It provokes a discussion about what's truly important on any specific page. This helps tremendously as you consider how a site will respond across viewport widths. And because it doesn't contain actual content it facilitates great conversation about the what and why of types of content, which can easily be overlooked if you start writing the copy immediately.

If your clients have difficulty prioritizing (and they probably will), you could place these decisions around what is most important into a spreadsheet and give them options to check — primary, secondary, tertiary, etc. The result is the same: you have a prioritized list of content types for each page, but the process to get there may feel a bit more friendly to the client if they're given some options.

Information Architecture

Once you have a good understanding of the types and priority of content that needs to exist in the system, it's critical to consider how that content should be grouped and the paths through the content you want your users to take. This kind of thinking is crucial to the creation of a usable site.

I recently saw Aaron Quinn speak about information architecture and he said something that really stuck with me. He suggested that we might be relying too much on our common sense when it comes to grouping information. Instead, he made the case for us to consider consensus over common sense when planning how our users will interact with what we build. Let me explain why with a quick story.

We have a client we've been working with for over a year now. She has bootstrapped a very successful SAAS product which we helped her build. This woman is incredibly smart; she works on the web every day — it's how she makes a living. Not too long ago, I was having a conversation with her about what was next for her product and she said this to me: “I think we need to make some changes to the tabs on our site.” I paused because I was desperately trying to remember where we had implemented tabs on her site. Sensing my confusion, she went on to explain more about what she was hoping for. After a few moments, I realized she was talking about the navigation. It was eye-opening that this savvy web entrepreneur referred to her navigation as “tabs.”

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

During some recent usability tests, I noticed that on small screens many users never attempted to locate or use navigation. These days, most of our small-screen navigation experiences are hidden behind obscure icons (hamburger, anyone?). I believe our expectation that users will properly identify, trigger and use our navigation is unfounded.

In an effort to combat this, we've begun considering a simple question — can someone use this site without the navigation?

Literally, remove the navigation from your site and see if your users can reach the content they want. In other words, plan out the content in such a way that your users can feel their way through the experience. Chances are, a good number of them will browse this way. We'd better be ready for them.

Style Comparisons

I learned about style comparisons when I had the opportunity to present with Dan Mall and Yesenia Perez-Cruz at Artifact Conference in Austin, Texas. Dan shared a story about how he was working to build a new office. Here's the relevant excerpt from his blog post:

“I could create an illustration or a 3D rendering of what I want my new office to look like, but that doesn't take advantage of his [the contractor's] great ideas. It's dictation, not collaboration. Instead, I show him a Pinterest board my wife and I created. I tell him that I love these beams or this mix of materials, and we can have a conversation. I revise my ideas through his expertise, and vice versa. This is how building a website should go.”

Not only is this a brilliant approach to building a new space, it can be applied directly to what we do each day. Our creative director, Jeremy Loyd, has been creating super-simple PDFs for our clients that ask them whether they think their brand would best be represented online with:

• A dark or a light site
• A flat or a textured site
• An illustrated or photographic site
• Whatever other style comparisons are relevant

You get the idea. The point is that it only takes a few minutes to put this together, because it doesn't really require any design. You can use screenshots of existing sites that embody the qualities you have questions about.

An approach like this is very useful when there isn't much clarity about the design direction up front. It helps us make sure we're in agreement about the direction we're headed. Truthfully, this is really just a simple tool to facilitate a conversation, to get people thinking and conversing about design.

One other trick from my friend Dan Mall which you can use to really drive this home is to quickly edit your client's logo into a screen capture of someone else's site. There is something about seeing their brand associated with a specific style which provokes a reaction. This makes for very fruitful conversations.

User Experience Design

No title in our industry is more overloaded and misunderstood than “user experience designer.” It means so many different things to so many different people. Recently, I've even noticed a trend toward expecting all designers and developers to do this work. And while I believe the best organizations have teams full of people who care about user experience, I also believe it has a deeper role to play.

I think about user experience as the glue that binds our design and our development together. It's what separates web design from other kinds of design — that our work is intended not only to be observed, but also to be interacted with. That interaction is so important. In my mind, a great user experience designer has an instinct for what will be easy for a user to understand. However, this must be balanced with the idea that design without testing is guesswork . For this reason, a great user experience designer knows how to research their users, how to collaborate with UI designers, how to prototype possible solutions, and how to select and execute usability studies to capture and analyze data which properly informs design and development.

To dużo. And since I'm not formally trained in user experience or human factors, I'm probably not qualified to write about each of those things. Instead, I want to focus on one lesson I've learned (see “Test the Aggregate”) and then share the kinds of updates we do with our customers to help us all agree on usability decisions across screen sizes and input methods.

Test The Aggregate

I work with internal user experience teams at larger clients, and one challenge I'm continually presented with is the desire to test the experience they are building at individual breakpoints. In other words, I've seen teams create three (or more) separate prototypes — for mobile, tablet and desktop — and then proceed to test each one independently. When this happens, each of these separate experiences will evolve on its own, usually resulting in three unique experiences which will be very difficult (if not impossible) to build in a responsive way.

To combat this, lately I've shared how critical it is to test the aggregate experience. Instead of building three separate prototypes for usability studies, build a single prototype with HTML and CSS that actually responds. We usually do this statically with an evolving set of front-end build tools (you can learn more about our front-end stack in the article “We Heart Good Tools: An Update on Our Build Process”) which means we can work quickly with fake data.

This concept is about letting go of the control you think you have. It's about making decisions which benefit the whole (the aggregate) even though they may require compromises in certain contexts. It recognizes that changes made at one of the breakpoints in your system will inevitably affect the experience at other breakpoints. It's about embracing the benefits you get with a single code line and adjusting our usability studies to account for this.

Jeśli tworzymy responsywnie, musimy skupić się na testowaniu rozwiązania z jedną witryną na różnych szerokościach widocznego obszaru. Musimy zmierzyć użyteczność całości, a nie tylko punktów przerwania. Pomoże nam to stworzyć najbardziej użyteczne doświadczenie dla większości ludzi.

A teraz kilka aktualizacji, z których korzystamy z naszymi klientami, aby pomóc osiągnąć te cele.

Prototyp treści

Słyszeliście, że projektant stron internetowych powinien nauczyć się trochę CSS, prawda? Cóż, zgadzam się i myślę, że strateg treści powinien nauczyć się trochę HTML. Z tego powodu i wielu innych tworzymy prototypy treści na dość wczesnym etapie naszego procesu tworzenia stron internetowych. Gdy tylko zaczniemy uzyskiwać wyraźny obraz rzeczywistej treści, zaczynamy oznaczać tę treść za pomocą hipertekstu . To właśnie robimy z HTML, prawda? Kto lepiej zapakuje treść w tagi semantyczne niż ludzie, którzy najlepiej rozumieją treść? Chociaż narzędzia takie jak Markdown również mogą działać, myślę, że najlepiej jest nauczyć się podstaw HTML, zanim przejdziesz od razu do Markdown. Zrozumienie, dlaczego piszesz treść w ten sposób, jest tak samo ważne, jak samo pisanie kodu HTML. Narzędzia takie jak Markdown dodają warstwę abstrakcji między twoimi działaniami a wynikiem tych działań — abstrakcja, która jest w porządku, gdy zrozumiesz, co ci daje.

Kiedy tworzymy prototyp treści, celowo pomijamy prawie wszystkie style. Zostawiamy je dość brzydkie, więc jasne jest, że niczego nie zaprojektowaliśmy. Dzięki temu rozmowa koncentruje się na treści i priorytecie tej treści. Wiedz, że kiedy pokażesz to klientowi, natychmiast zajmą się kolejnością rzeczy — dokładnie tego, czego od nich oczekujesz: zadbaj o właściwy priorytet! Ponadto zwykle zawieramy tylko tyle CSS, aby pokazać grupowania, jak na przykład:

Mówiłem ci, że to brzydkie.

Zalewamy również nasze prototypy treści linkami. Jednym z powodów, dla których je tworzymy, jest umożliwienie ludziom nawigowania od strony do strony, aby sprawdzić, czy przepływ treści działa.

Pamiętaj, że musisz przygotować swoich klientów na zobaczenie tego rodzaju brzydkiej aktualizacji. W przeciwnym razie z pewnością będą mieli wątpliwości co do zaangażowania Cię w ich projekt. Jest jednak coś potężnego w wyświetlaniu surowych treści oznaczonych w przeglądarce.

Jedna ważna uwaga: zdajemy sobie sprawę, że czysto semantyczne znaczniki prawdopodobnie nie trafią do produkcji. Chociaż byłoby to idealne, w rzeczywistości praca w sieci jest obecnie taka, że ​​musi być możliwa do utrzymania i rozszerzania przez osoby i zespoły o bardzo zróżnicowanych zestawach umiejętności. Jednak rozpoczęcie od tej czystej wersji znaczników to fantastyczny sposób na przypomnienie nam naszych ideałów. Następnie, gdy dostosowujemy znaczniki, aby umożliwić stylizację, ponowne użycie, rozszerzalność itd., jesteśmy bardzo świadomi, że każda wprowadzana przez nas zmiana oddala nas od ideału. Każda zmiana jest kompromisem i powinna być głęboko rozważona przed jej wprowadzeniem.

Szkielety statyczne

W ciągu ostatnich kilku lat pojawiło się sporo niechęci do bardziej tradycyjnych, statycznych modeli szkieletowych. Uważam, że nadal mogą wnieść dużo wartości. Uważam też, że mogą nie być potrzebne w każdym projekcie. Kiedy ich używamy, zwykle robimy je na wąskich szerokościach — tak niewygodnych, jak to jest — aby pomóc nam skupić się na priorytetach. Ograniczenie naszej wizualnej nieruchomości wymusza to skupienie. Użyliśmy do tego wielu narzędzi, od Keynote po Balsamiq. Szczerze mówiąc, każde z tych narzędzi wykona zadanie. Znajdź taki, który Ci odpowiada i zabierz się do pracy.

Dużo też szkicujemy. Tablice, ołówek i papier, różne aplikacje do szkicowania. Robimy zdjęcia tych rzeczy i dzielimy się nimi z naszymi klientami, celowo zachowując wszystko w stanie surowym. Surowość jest ważną częścią tego, co robimy. Dzięki temu nasi klienci wiedzą, że nie marnujemy czasu na polerowanie dokumentów, które nie skorzystają z polerowania, i zapewnia skupienie opinii. Ostatnią rzeczą, jakiej pragniemy, jest ktoś, kto komentuje kolory naszych masek.

Interaktywne modele szkieletowe

Częścią odejścia od bardziej tradycyjnych modeli szkieletowych było przejście na bardziej interaktywne podejście. Podobnie jak Manifest Agile promuje działające oprogramowanie zamiast dokumentacji, wielu w naszej branży wierzy, że zademonstrowanie zamiaru interakcji za pomocą prototypu jest znacznie skuteczniejsze niż próba opisania tego statycznie. Obecnie narzędzia dostępne do szybkiego prototypowania są niezwykle wydajne: frameworki, takie jak Bootstrap i Foundation; zestawy narzędzi CSS (lub Sass i LESS), takie jak Bourbon i Pure CSS; wizualne narzędzia do prototypowania, takie jak InVision i Marvel. Nawet wizualne narzędzia do projektowania i programowania stron internetowych, takie jak Macaw lub narzędzia do prezentacji, takie jak Keynote, mogą być używane do tworzenia bardzo interaktywnych modeli szkieletowych.

Zaletą tego podejścia jest to, że możesz pokazać ludziom pomysł zamiast próbować im go wyjaśniać. Jeśli obraz jest wart tysiąca słów, prototyp jest wart tysiąca obrazów.

Współpracujemy teraz z organizacją, która to rozumie. Jednym z ich celów jest wcześniejsze wprowadzenie szybkiego prototypowania do procesu, aby mogli wykorzystać prototypy do badań użyteczności, a także kodu produkcyjnego. Nasza praca z nimi koncentruje się na stworzeniu systemu komponentów, które mogą być używane we wszystkich ich właściwościach internetowych. Ten system zostanie również ostatecznie wykorzystany, aby umożliwić ich zespołowi bardzo szybkie tworzenie interaktywnych modeli szkieletowych. Ponieważ zbudowaliśmy go z myślą o ich markach, interaktywne makiety będą wyglądać bardzo podobnie do ich wersji produkcyjnych, co będzie niezwykle pomocne w testowaniu UX.

Tego rodzaju podejście koncentruje się na długoterminowym sukcesie usługi internetowej. Uosabia przepływ pracy „jeden produkt do dostarczenia”, o którym mówiliśmy wcześniej, angażując wszystkie dyscypliny w tworzenie prototypu i pozwalając, aby to, czego nauczyliśmy się podczas jego projektowania i rozwoju, wpływało na dalsze decyzje. Uważam, że widzimy przesunięcie w kierunku organizacji budujących dojrzałe systemy front-endowe zamiast hakowania razem CSS po namyśle. Zapewnienie organizacji możliwości testowania statycznej wersji swojej pracy w sieci z prawdziwymi użytkownikami jest ważnym krokiem w kierunku ugruntowania tego jako normy w najbliższej przyszłości.

Projektowanie i rozwój interfejsu użytkownika

„Dobry projekt to rozwiązywanie problemów”.

— Sztuka i nauka projektowania stron internetowych, Jeffrey Veen (2000) .

Dla tych z Was, którzy są projektantami, ten cytat brzmi bardzo prawdziwie. Wiele osób postrzega to, co robimy, jako dekorację, ale to o wiele więcej. W ciągu ostatnich kilku lat z całego serca zgadzam się z sentymentem wypowiedzi Jeffa, ale też jestem bardzo świadoma skłonności projektantów do przesterowania swoich rozwiązań. To prowadzi mnie do tego, co nazywam „punktem zwrotnym”.

Jeśli podzielisz czynność projektowania na trzy fazy — ustalanie estetyki, rozwiązywanie problemu i dopracowywanie rozwiązania (jak wskazano powyżej) — przejście od rozwiązywania problemów do udoskonalania rozwiązania jest punktem zwrotnym. To ostatni odpowiedzialny moment na wejście w medium sieci. Jeśli tego nie zrobisz, wykonasz tę fazę dopracowywania wiele razy — a to jest wysoce nieefektywne.

Jeśli kiedykolwiek spędziłeś godziny na poprawianiu PSD, przekazałeś go programiście do zbudowania, a następnie sprawdziłeś ponownie za tydzień lub dwa, doświadczyłeś tego bólu. Cały wysiłek włożony w udoskonalanie i udoskonalanie poprzez przesuwanie statycznych pikseli jest zmarnowany. Jak tylko projekt zmieni media (od statycznego projektu w Photoshopie lub innym narzędziu do HTML i CSS w przeglądarce), potrzebna jest kolejna faza dopracowania. Ideą stojącą za punktem przełączania jest rozpoznanie, jak nieefektywne jest to. Zamiast dopracowywania za pomocą statycznych narzędzi, zakoduj podstawowy projekt tak szybko, jak to możliwe i zajmij się dopracowywaniem w końcowym medium — w sieci.

To często wymaga parowania projektów, dosłownie wspólnego siedzenia, aby te udoskonalenia ożyły. Chociaż czasami może to wydawać się powolne i bolesne, w rzeczywistości jest to niezwykle korzystne dla wszystkich zaangażowanych. Gdy projektant dzieli się z deweloperem front-endu rodzajem zmian stylu, które chciałby zobaczyć, programista front-end dowiaduje się, co jest ważne w dopracowanym projekcie. Podczas gdy programista front-end wprowadza żądane zmiany, projektant widzi, jak te zmiany są wprowadzane, być może ucząc się trochę CSS. Ten proces sprawia, że ​​wszyscy są mądrzejsi. Oznacza to również, że następnym razem, gdy te dwie pary będą działać znacznie szybciej.

W dzisiejszych czasach musimy być zaznajomieni z wieloma narzędziami, aby rozpocząć konwersacje dotyczące interfejsu użytkownika i musimy przesunąć kodowanie tych projektów na wcześniejszym etapie procesu. Przyjrzyjmy się kilku sposobom na zrobienie tego.

Płytki stylu

Samantha Warren dokonała przełomu, wprowadzając kafelki stylu jako sposób na „definiowanie języka wizualnego” w Internecie. Ci z nas, którzy mają tła brandingowe, od razu przekonali się, jak wartościowe mogą być stylowe płytki.

Płytki Style są dość proste. Na ogół obejmują one palety kolorów, wybory typografii, tekstury oraz style ikonografii lub ilustracji. Celowo nie są to całostronicowe kompozycje. Zamiast tego reprezentują wystarczająco dużo projektu, aby określić, czy zmierzamy we właściwym kierunku. Z tego powodu działają najlepiej, gdy klient wyraził to, czego chce, ale nie jesteś w pełni przekonany, że jesteś na tej samej stronie.

Doceniłem stylowe kafelki, głównie ze względu na ich szybkość. Tam, gdzie kiedyś spędzaliśmy tydzień projektując stronę główną i podstronę w Photoshopie, teraz możemy stworzyć prosty kafelek stylu w ciągu kilku godzin. Pozwala to zaoszczędzić czas i pieniądze oraz daje pewność, że zmierzasz we właściwym kierunku.

Samantha ma garść przykładów na stronie z kafelkami stylów, a poniżej wymieniono kilka świetnych zasobów, które obejmują ich zastosowanie w rzeczywistych procesach:

• „Włącz swój (wizualny) styl”: Yesenia Perez-Cruz, Dan Mall i moja prezentacja na Artifact Conference w Austin w Teksasie (13 maja 2013 r.).
• „Szybsze decyzje projektowe dzięki stylowym płytkom”: Samantha Warren podczas imprezy An Event Apart w Austin w Teksasie (luty 2015).
• Podcast The Style Guide z Samanthą Warren

Ze względu na ich statyczny charakter nie używamy ich zbyt często. Nasz początkowy kierunek projektowania jest zwykle ustalany za pomocą kolażu elementów lub prototypu stylu, oba omówione później.

Kolaże elementów

Dan Mall przedstawił nam kolaże elementów jako „zespół różnych elementów bez określonej logiki i porządku”. Ich różnorodny charakter sprawia, że ​​jest oczywiste, że to, na co patrzysz, nie jest sfinalizowanym projektem; raczej kolaże elementów dostarczają klientom kontekst różnorodnych komponentów, które mogą żyć razem w systemie. Pomagają nam położyć trochę mięsa na kościach szkieletu; pomagają nam wyobrazić sobie kierunek, w którym się poruszamy; pozwalają nam rozpocząć wizualizację elementów składowych naszej strony, ale zachęcają nas, abyśmy nie tracili z oczu całości.

Jedną z zalet kolaży elementów jest to, że możesz wybrać, które składniki chcesz pokazać. Czy Twojemu klientowi naprawdę zależy na tym, jak wyszukiwanie jest prezentowane jego użytkownikom? Świetnie! Może powinieneś poświęcić trochę czasu na rozwiązanie tego problemu — umieść go w kolażu elementów. Czy Twój klient ma obsesję na punkcie przycisków wezwania do działania? Umieść je w kolażu elementów. Ta mentalność „wybierz i wybierz” ułatwia dostosowanie każdego kolażu do tego, co najważniejsze w Twoim projekcie. Twoi klienci ogromnie to docenią.

W ostatnim projekcie musieliśmy ustalić kierunek projektowania dla przeprojektowania jednej z usług internetowych naszego klienta. Katie Kovalcin (jedna z naszych projektantek) kierowała pracami projektowymi naszego zespołu i zdecydowała się na stworzenie dwuelementowych kolaży zamiast komponowania strony głównej.

Całkowity czas, jaki zainwestowaliśmy w stworzenie tych dwóch koncepcji projektowych, wyniósł około 16 godzin. Kiedy zapytałem Katie, jak długo by to zajęło, gdyby poproszono ją o zrobienie dwóch kompozycji na stronie głównej, odpowiedziała:

„Na tym etapie, próbując rozgryźć ich nową estetykę, trudno byłoby żonglować znalezieniem tej estetyki, próbując ułożyć hierarchię strony i określić interakcje. Tak więc rozplanowanie całej strony głównej jako sposobu na określenie estetyki może czasami zająć nawet tydzień, w zależności od tego, nad czym musieliśmy pracować. Powiedziałbym, że prawdopodobnie blisko 25-30 godzin każdy.

Ale wychodząc z kolażu elementów, dość łatwo było przejść do przodu z układem strony i wszystkimi innymi rzeczami, ponieważ nie ma zbyt wiele wysiłku, aby dowiedzieć się, jakich stylów przycisków użyjemy, czcionek lub kolorów ”.

Oznacza to, że stosując kolaż elementów ograniczyliśmy ilość czasu, jaką poświęciliśmy na stworzenie estetyki.

W powyższym cytacie Katie jest jeszcze jedno naprawdę interesujące wyrażenie; powiedziała, że ​​„trudno byłoby żonglować znalezieniem tej estetyki, próbując ułożyć hierarchię strony i rozgryźć również interakcje”. Innymi słowy, zaczynanie od kompozycji na stronie głównej próbuje osiągnąć zbyt wiele i zbyt wcześnie. Kiedy najpierw zrobimy mniejszy krok (używając kolaży elementów lub kafelków stylów), jesteśmy w stanie podzielić i pokonać stojące przed nami wyzwania projektowe. Dzięki temu nasi klienci częściej biorą udział w rozmowie i możemy się uczyć na bieżąco, co przekłada się na lepszą pracę.

Prototypy stylu

Możesz myśleć o prototypach stylów jako o interaktywnych kafelkach stylów. Prototyp stylu zawiera te same elementy, które można uwzględnić w kafelku stylu — znak marki, nagłówki, style akapitów, style przycisków, traktowanie łączy, zalecenia dotyczące kolorów. Jedyna różnica polega na tym, że idziemy o krok dalej i kodujemy.

Ich piękno polega na tym, że możemy pokazać prawdziwy typ strony internetowej, prawdziwe kolory, rzeczywiste stany najechania kursorem, styl ilustracji za pomocą wektorów internetowych oraz sposób, w jaki może odpowiadać tekst i podstawowy układ. Prosimy naszych klientów o przejrzenie ich w wybranej przez siebie przeglądarce. To otwiera rozmowy o tym, co to znaczy obsługiwać przeglądarkę. Na przykład, jeśli używają przeglądarki, która nie obsługuje border-radius , nie zobaczą zaokrąglonych rogów.

Możemy również zbudować prototypy stylu w ciągu około jednego dnia, co daje nam takie same korzyści w zakresie wydajności, jakie daje nam kafelek stylu. Klienci je kochają, ponieważ mogą z nimi wchodzić w interakcje. Widzą je na swoich telefonach i tabletach. Mogą zacząć się z nimi bawić.

Wreszcie, w świecie, w którym większość z nas uważa, że ​​projektanci stron internetowych powinni nauczyć się kodować, prototypy stylów są fantastycznym wprowadzeniem do pisania HTML i CSS. Ze względu na ich prostotę, nawet niekodujący projektant może dowiedzieć się, jak je zbudować. Zanim się zorientują, będą mieli pewność, że udoskonalą produkcyjne CSS, zamiast statycznie wyśmiewać zmiany, które chcą zobaczyć.

Kiedy projektowaliśmy oryginalną witrynę Sparkbox, a ostatnio przeprojektowaliśmy, użyliśmy prototypów stylu, aby ustalić kierunek projektowania.

Projekt atomowy

Jeremy Keith po raz pierwszy przedstawił mi ideę rozpoczęcia projektowania od „atomów witryny” w swoim przemówieniu na temat Breaking Development zatytułowanym „There is No Mobile Web”. Brad Frost sformalizował ten termin w czerwcu 2013 r., kiedy nakreślił mentalny model podejścia do projektowania „systemu komponentów” dla sieci.

Podstawowym założeniem jest rozważenie pięciu poziomów szczegółowości w naszej pracy, aby stworzyć systemy komponentów wielokrotnego użytku. Najmniejszy poziom nazywa się atomem; pomyśl o prostym wejściu HTML lub etykiecie dla wejścia. Atomy te można łączyć w cząsteczki; być może cząsteczka wyszukiwania składa się z przycisku, etykiety i danych wejściowych. Te cząsteczki można łączyć, tworząc organizmy; być może nagłówek strony internetowej zawierałby molekuły wyszukiwania, marki i nawigacji. Organizmy te są łączone w szablony i strony. Szablony są pełne danych ogólnych; strony to szablony, do których wstrzykiwane są prawdziwe dane. Cała ta teoria może pomóc nam stworzyć bardziej modułowy, wielokrotnego użytku i rozszerzalny kod.

Jedną z rzeczy, których się nauczyłem, kiedy podchodziliśmy do naszych projektów zgodnie z tym tokiem myślenia, jest to, że projektowanie atomowe jest znacznie łatwiejsze, gdy pozwolisz mu wyewoluować z refaktoryzacji. Częstym sposobem, w jaki pracujemy, jest zbudowanie małego komponentu w HTML i CSS bez zbytniego martwienia się o atomy, molekuły czy organizmy. Następnie, gdy już rozwiążemy problem UX i UI z interfejsem, możemy zrefaktoryzować ten kod w strukturę atomową. To odwrotne podejście oznacza, że ​​nie tracimy czasu na próby przemyślenia, czym powinna być cząsteczka, a co organizm. Zamiast tego pozwalamy, aby różne poziomy ewoluowały wraz z ewolucją samego systemu.

Wynikiem podejścia atomowego jest biblioteka wzorców, które można zintegrować z systemem.

Biblioteki wzorów

Biblioteka wzorców to dokładnie to, na co wygląda — biblioteka wzorców, które istnieją w twoim systemie. Obecnie wiele osób pracuje nad rozwiązaniami dla bibliotek wzorców; ludzie tacy jak Brad Frost, Anna Debenham, Jina Bolton i Bermon Painter mówili i pisali na ten temat. W rzeczywistości Brad i Dave Olson stworzyli jedno z bardziej znanych obecnie dostępnych narzędzi, Pattern Lab. Pattern Lab jest świetne, ponieważ pozwala oddzielić konkretną zawartość od modułów HTML i zapewnia atomową strukturę, która ułatwia budowanie systemu wzorców. Dodali także kilka świetnych funkcji do testowania, gdy jesteś w fazie rozwoju. Całość jest bardzo łatwa do uruchomienia lokalnie i ma prosty interfejs, który można łatwo pokazać klientowi. Jeśli chcesz zająć się projektowaniem opartym na wzorach, jest to fantastyczne miejsce na rozpoczęcie.

Wiele się teraz dzieje w tej przestrzeni i istnieje wiele innych zasobów dla tych z nas, którzy chcą dowiedzieć się więcej. Brad współpracował z Anną Debenham i Brendanem Falkowskim (wraz z kilkoma innymi osobami) przy tworzeniu zasobów przewodnika po stylach witryn internetowych. Jest to ogromny zbiór wielu przykładów, artykułów, rozmów, podcastów i nie tylko, które obejmują projektowanie i rozwój oparte na wzorcach.

Jak dotąd największym wyzwaniem jest znalezienie sposobu na aktualizowanie biblioteki wzorców po zintegrowaniu wzorców z systemem zaplecza. Nie widziałem jeszcze idealnego rozwiązania tego problemu, ale pracuje nad tym wiele bystrych umysłów. Sprawdź Rizzo by Lonely Planet jako świetny przykład organizacji pilnie pracującej nad rozwiązaniem tego problemu. Nawet jeśli nie mamy idealnego długoterminowego rozwiązania, widzę ogromne korzyści z projektowania w ten sposób. Sprawia, że ​​myślisz modułowo, a to sprawia, że ​​praca front-endowa, którą wykonujemy, jest znacznie łatwiejsza do zintegrowania i utrzymania.

A co z punktami przerwania?

Ilekroć mówię lub piszę o procesie, zawsze jestem pytany o wybór punktów przerwania. O dziwo, ta rozmowa prawie nigdy nie pojawia się w naszej responsywnej pracy z dnia na dzień. Z pewnością niektórzy klienci przychodzą do nas z ogromną ilością pracy, sprawdzając narzędzia analityczne i ustalając priorytety — wszystko w imię udokumentowania punktów przerwania systemu. Ten sposób myślenia nigdy nie miał dla mnie większego sensu.

Myślę, że to Stephen Hay powiedział to jako pierwszy: „Zacznij od małych rzeczy i dodaj punkt przerwania, gdy witryna się zepsuje”. Nasze witryny często mają dziesiątki punktów przerwania — większość z nich nie pasuje do typowych rozmiarów urządzeń. Gdy zauważysz, że treść i projekt nie współgrają ze sobą, napraw to.

Teraz jest różnica między tym, co Stephanie Rieger nazywa głównymi punktami przerwania i mniejszymi punktami przerwania. (Słyszałem też, że nazywają się one punktami przerwania i punktami podkręcania). Pozwólcie, że wyjaśnię każdy z nich.

Główne punkty przerwania

W przypadku zmian w układzie, które wymagają współpracy osobnych modułów przy zmianie projektu, używamy wspólnego punktu przerwania (głównego punktu przerwania). Być może masz korektę układu, która przenosi ułożoną listę produktów przy małych szerokościach okienka ekranu do układu dwukolumnowego przy większych szerokościach okien. W takim przypadku warto śledzić, gdzie następuje zmiana układu, ponieważ prawdopodobnie istnieje wiele innych zmian, które muszą wystąpić przy tej samej szerokości widocznego obszaru.

Większość pracy, którą wykonujemy, ma od trzech do sześciu głównych punktów przerwania. Są one często ustawiane jako zmienne Sass w naszym przepływie pracy, dzięki czemu możemy później wprowadzać w nich zmiany w jednym miejscu. Często zdarza się również, że mamy zestaw głównych punktów przerwania dla głównych sekcji witryny. Na przykład możemy mieć trzy główne punkty przerwania w nagłówku naszej witryny i trzy zupełnie różne punkty przerwania w stopce. Dzięki temu nasza praca jest modułowa i pozwala na niezależną ewolucję tych sekcji, zachowując jednocześnie spójność z systemem jako całością.

Drobne punkty przerwania

Gdy potrzebne są bardziej subtelne zmiany typu lub odstępów, nadal możemy użyć zapytania o media, aby wprowadzić te poprawki (drobny punkt przerwania). Są to zazwyczaj jednorazowe modyfikacje stylu, takie jak rozmiar czcionki (aby utrzymać długość linii pod kontrolą) lub zwiększenie odstępów wraz ze wzrostem szerokości widocznego obszaru. Te drobne poprawki pokazują głęboką dbałość o szczegóły, które mogą naprawdę wyróżnić twoją pracę.

Zamiast używać do tego zmiennych preprocesora, zwykle używamy po prostu liczb zakodowanych na sztywno. Czasami używaliśmy również obliczeń preprocesora, aby zachować je względem głównego punktu przerwania. Na przykład, jeśli mamy główny punkt przerwania w 30em o nazwie $bp_header-show-nav , mogę chcieć dostosować rozmiar czcionki nagłówka w 5em nad punktem przerwania $bp_header-show-nav . W tym przypadku stałoby się to o 35em. Jeśli przesuniemy ten główny punkt przerwania na 32em w pewnym momencie w przyszłości, niewielka zmiana nastąpi wtedy w 37em. Myślenie względnie z mniejszymi punktami przerwania może pomóc, jeśli podejrzewasz, że główne punkty przerwania mogą się zmienić. Będziesz musiał wykorzystać swój osąd w każdym przypadku z osobna, aby podjąć najlepsze decyzje.

Dalsza lektura

Więcej informacji o punktach przerwania znajdziesz w tych artykułach:

• „Nie ma punktu przerwania”
• „Pomiędzy” Marka Boultona
• „Pragmatic Responsive Design” autorstwa Stephanie Rieger

Przejście na zewnątrz

W dzisiejszych czasach budowanie świetnych witryn nie wystarczy. Musimy również wziąć pod uwagę długowieczność tego, co budujemy. Chociaż podejścia takie jak projektowanie atomowe mogą pomóc, musimy zrobić więcej. W tej chwili większość naszych projektów zawiera jakiś element szkoleniowy — i nie mówię tu o nauczeniu klienta obsługi CMS. Gdy organizacje zaczynają naprawdę rozumieć wartość, jaką oferuje im sieć, decydują się na tworzenie własnych zespołów, aby posiadać i utrzymywać swoje usługi internetowe. Jeśli chcemy zbudować coś trwałego, musimy zadbać o to, by zespół podejmujący naszą pracę był w stanie ją odpowiednio utrzymać. Z tego powodu prowadzimy znacznie bardziej szczegółowe szkolenia dotyczące technik, których używamy do tworzenia sieci.

Na szczęście istnieje obecnie wiele powszechnych sposobów podejścia do przejścia. Każde repozytorium, które tworzymy w kontroli źródła, ma przydatny plik readme; dostarczamy automatyczne testy wspierające nasz kod; i pracujemy nad pewnymi sposobami przeniesienia budżetu wydajności projektu, aby nasi klienci nadal utrzymywali szybkość swoich witryn. Wraz z atomowym myśleniem dostarczamy również działające przykłady budowanych przez nas podsystemów. Na przykład często zastanawiamy się, jak typografia działa we wszystkich usługach internetowych w kontekście marki klienta, więc możemy również dostarczyć szczegółową dokumentację dotyczącą tego systemu typograficznego, a także stronę z przykładami pokazującymi, jak z niego korzystać. Tego typu dodatki do naszej pracy znacznie ułatwiają czas, ponieważ przekazujemy kod z naszego zespołu do zespołu naszego klienta.

Wszystko to ma też głębsze konsekwencje. Zrozumienie, kto będzie dbał o budowany system, powinno również wpływać na decyzje, które podejmujesz dotyczące wyboru technologii i techniki rozwoju. Innymi słowy, jeśli zespół webowy Twojego klienta nie jest gotowy do używania Grunta z Assemble i lokalnego serwera z wiersza poleceń, musisz znaleźć sposób pracy, który lepiej pasuje do ich możliwości. Pamiętaj, budujesz to dla nich.

Niezwykle korzystne było również zaproszenie zespołów projektowych i programistycznych naszego klienta do udziału w projekcie. Wykorzystanie projektu jako okazji do przeszkolenia zespołu klienta ma niesamowitą wartość i ułatwia wybór spośród konkurencji.

Ludzie nad procesem

Ostatnią rzeczą, której nauczyłem się stale rozwijając nasz przepływ pracy, jest to, że proces, który wybierzesz, jest znacznie mniej ważny niż ludzie, którzy z niego korzystają. Jeśli chcesz tworzyć lepsze produkty internetowe, zacznij od rozwoju swoich ludzi. To zaprowadzi Cię dalej niż jakiekolwiek poprawki w procesie lub przepływie pracy.

Utrzymanie szczęścia zespołu

W tym samym duchu polecam lekturę Flow autorstwa Mihaly Csikszentmihalyi. W tej książce wyjaśnia badania, które przeprowadził, aby lepiej zrozumieć indywidualne szczęście. Opisuje to, co nazywa „kanałem przepływu”, przedstawiając poziom umiejętności na osi x w porównaniu z poziomem wyzwania na osi y . Kanał przepływu to obszar, w którym Twoje umiejętności stają przed odpowiednim wyzwaniem. Zbyt duże wyzwanie dla twoich umiejętności powoduje niepokój, a zbyt małe wyzwanie dla twoich umiejętności powoduje nudę.

Można to przełożyć na to, co robimy, rozważając, jakie wyzwania stawiamy sobie w naszej codziennej pracy. W Sparkbox mówimy o kulturze uczenia się. To (miejmy nadzieję) oznacza, że ​​umiejętności mojego zespołu stale rosną. Wynika z tego, że aby być szczęśliwym, musimy znajdować coraz większe wyzwania, które pasują do naszych stale rosnących umiejętności. Naszym obowiązkiem jest zrównoważenie tej potrzeby innowacji z odpowiedzialnością finansową w budżetach naszych klientów.

To jest trudne. Dla nas oznacza to, że musieliśmy przestać wymyślać koło na nowo; skłoniło nas to do rozważenia bibliotek dobrze przetestowanych elementów interfejsu w przeciwieństwie do wielokrotnego rozwiązywania tych samych problemów w każdym projekcie. Oznacza to, że musimy zrozumieć, na co każdy z naszych klientów powinien wydawać pieniądze na innowacje. Wymagało to również pewnej przejrzystości między tymi klientami a naszym zespołem, abyśmy wszyscy byli na tej samej stronie.

W końcu tworzy to bardziej treściwy zespół — taki, który uwielbia swoją pracę, ponieważ rzuca im wyzwanie we właściwy sposób. Dzięki temu klient jest bardziej zadowolony — taki, który szanuje Twoje zalecenia dotyczące tego, gdzie i dlaczego powinien inwestować. To jest doskonałe dla wszystkich zaangażowanych.

Naprzód

To jest część, w której głęboko Cię inspiruję i zachęcam do odważnego nowego świata projektowania stron internetowych. Ale szczerze mówiąc, starałem się podsumować sentyment końcowy do tego rozdziału.

Po pewnej kontemplacji wierzę, że dzieje się tak dlatego, że pisanie o procesie nigdy się nie kończy.

Mam nadzieję, że czytając te słowa, poczułeś się bardziej zainspirowany do inwestowania we własne zrozumienie działania sieci i bardziej skłonny do inwestowania w zrozumienie swoich kolegów z zespołu. Mam nadzieję, że poczułeś się podekscytowany wypróbowaniem nowego podejścia, ale mam też nadzieję, że poczułeś się upoważniony do rozerwania tych stron, jeśli nie działają dla Ciebie. Tylko Ty, Twój zespół i Twój klient możecie wymyślić najlepszy sposób podejścia do projektu. Taka jest natura tego, co robimy.

Nadszedł czas — więc do dzieła!