Jak wybrać dobry software house

Od prawie trzech lat współpracujemy z różnymi software house’ami, małymi firmami i korporacjami. Zwykle outsourcujemy nasze usługi udostępniając innym firmom nasze umiejętności (co ma zarówno dużo plusów jak i minusów) – jesteśmy odpowiedzialni za strategię produktu, UX research i design, a druga strona odpowiada za wdrożenie, tego co tworzymy w czasie naszego procesu. Oczywiście mieliśmy takie współprace, z których byliśmy bardzo zadowoleni. Co jest w tym wszystkim najważniejsze? Pracując na wielu płaszczyznach z różnymi firmami zaobserwowaliśmy pewne wzorce, którymi chcemy się dziś z Wami podzielić. 

Development vs Design

Przede wszystkim odpowiednie wdrożenie zaprojektowanego designu jest niezwykle ważne dla doświadczeń użytkownika. Jeśli tworzysz produkt dla ludzi, musisz pamiętać o tym, że ich nie interesuje to, za pomocą jakiej technologii został on wdrożony. Nie mam na myśli tego, że nie jest to ważne, ale wybór technologii jest raczej decyzją strategiczną dla rozwoju danego produktu, a nie dla jego użytkowników. Zapytaj swojego “nietechnicznego” znajomego o to, w której technologii jest zaimplementowany Facebook, Instagram lub nawet Youtube. Naprawdę użytkowników to nie obchodzi. 

Następnie zapytaj ich czy pamiętają najnowszą aktualizację YouTube’a. Prawdopodobnie powiedzą, że zmienił się układ tagów pod wideo. Zapytaj o Facebooka, a oni powiedzą Ci o najnowszych aktualizacjach Messengera itd. Dlaczego o tym piszę? Ponieważ dla MVP ludzie zazwyczaj starają się zaoszczędzić pieniądze na designie i projektowaniu UX. Koniec końców ludzie mają wdrożoną aplikację, która jest perfekcyjna pod względem technicznym, ale w rezultacie użytkownicy zobaczą tylko aplikację, która nie odpowiada ich potrzebom, a co za tym idzie – nie będą wcale używali appki 🙂 

Jak więc wybrać software house, który będzie w stanie wykonać zarówno dobry backend, jak i świetny frontend?

Zapytaj o zespół

Z naszego doświadczenia wynika, że jeśli software house jest niewielki, nie oznacza to, że jest gorszy od innych. Nie chodzi o wielkość firmy, chodzi o ich strukturę. Na przykład: lepiej jest, jeśli powiedzą Ci wprost, że nie mają projektanta UX / UI, niż żeby dali Ci kogoś bez doświadczenia.

Spróbuj zrozumieć sposób, w jaki działają. Czy używają SCRUMa, czy ich działania są raczej spontaniczne, na zasadzie “jakoś to będzie”? Jeśli używają SCRUMa, to kto jest Product Ownerem? Czy mają oddzielnych Scrum Masterów? Czy używają innych metodologii? Jaki jest ich przepływ informacji? Jak współpracują między sobą?

Sam sprawdź, którą metodę zarządzania projektami preferujesz. Nie musisz się na nich znać, ale informacja o tym, jak i kiedy będziesz dostawał informacje o postępach, może być kluczowa. 

W dobrze zorganizowanych firmach ważne jest to, że nie ma różnicy, czy zespół pracuje razem w jednym biurze, czy w pełni zdalnie. Na przykład Netguru, jeden z największych software house’ów w Polsce,  działa całkowicie zdalnie i prawdopodobnie większość ich konkurencji byłaby pod wrażeniem tego, jak dobrze są zorganizowani. Chodzi bardziej o ich proces. Jak często mają między sobą aktualizacje statusów? Kto jest odpowiedzialny za zarządzanie projektem? 

Zapytaj także, od kiedy deweloperzy są zaangażowani w proces. Czy pracowali od samego początku (powinni być zaangażowani od pierwszego spotkania!)? Zapytaj kiedy projektant opuszcza projekt: czy po ostatnim ekranie, który zaprojektuje czy kończy pracę nieco później niż deweloperzy? Doświadczenie użytkownika związane jest z wdrożeniem, a projektanci powinni zadbać o interakcje i to jak wdrożone elementy działają! Przykładowo przy współpracy z Pragmatic Coders z Krakowa po oddaniu projektu do wdrożenia, co jakiś czas siadałem z Front-endem (pozdrowienia dla Jacka) i wspólnie sprawdzaliśmy, co nie działa tak, jak powinno dla użytkownika. 

Zapytaj o portfolio designera

Poproś o portfolio projektanta. Powinieneś otrzymać linki do Dribbble lub Behance. Wielu programistów pracuje z gotowymi bibliotekami (np. bootstrap, material design) co jest w porządku, jeśli wiesz, jak z niej korzystać . Niestety często widzimy, że firmy produkujące oprogramowanie używają bibliotek w sposób losowy. Na przykład użyją przycisku, który nie jest dedykowany do określonej akcji, bądź wprowadzą nieuzasadnione zmiany. W rezultacie cała aplikacja wygląda po prostu słabo. 

Dowiedz się, czy mają wewnętrznego projektanta graficznego czy współpracują z zewnętrznymi designerami. W takich przypadkach zapytaj również, kto będzie współpracował z Tobą i kto będzie odpowiedzialny za Twój projekt. Firma prawdopodobnie przedstawi Ci najpiękniejszy projekt wykonany przez kogoś, kto w rzeczywistości nie jest już dostępny pod Twoje zlecenie. Częstą praktyką jest przypisywanie do zadania młodszych projektantów.  Koniec końców Twój produkt może wyglądać zupełnie inaczej niż sobie to wyobrażałeś i będziesz rozczarowany ostatecznym rezultatem.

Narzędzia, których używają

Nie ma reguły, ale dobrze jest wiedzieć czy programiści i projektanci korzystają z najnowszej technologii. Aktualnie ludzie korzystający z systemu Mac prawdopodobnie będą używać takich narzędzi jak Sketch + Zepplin + Invision. Jest to częsta kombinacja wśród projektantów pracujących na wysokim poziomie. Integracja tych 3 narzędzi jest naprawdę imponująca. Designerzy jednocześnie mogą projektować, prototypować i dostarczyć plik dla front-endu z przygotowanym kodem. Narzędzia te znacznie ułatwiają współpracę, dzięki czemu otrzymasz dokładniejszy projekt szybciej niż się spodziewasz :), a i możliwości są po prostu większe.

Na Windowsie ludzie zwykle używają Figmy, co jest w porządku, ale większość projektantów poleca Sketcha (pamiętajcie, że aktualnie Figma błyskawicznie się rozwija, jej popularność rośnie każdego dnia i po kilku testach również stosunkowo często z niej korzystamy). Mieliśmy okazję wykonać kilka projektów w Adobe XD, ale zazwyczaj jest on używany przez firmy, które słyszały coś o nowych rozwiązaniach i zainstalowały ten program, ponieważ korzystały wcześniej z Photoshopa, a Adobe XD był dostępny w pakiecie za darmo.

Moim zdaniem: unikaj projektantów pracujących w Photoshopie. 3 lata temu pracowaliśmy także w Photoshopie, ale teraz trudno sobie wyobrazić jak można stworzyć skomplikowany projekt w starym i ciężkim programie.. To po prostu strata zasobów dla wszystkich zainteresowanych stron. Sumarycznie nie ma dla Ciebie różnicy, które narzędzia są używane, ale jeśli projektant użyje tych, o których wspomniałem powyżej, naprawdę zaoszczędzisz swoje pieniądze i czas bo wszystko będzie się działo po prostu szybciej i dokładniej.

Porównaj projekt z wynikiem końcowym

Software house’y zwykle przedstawiają swoje najlepsze projekty i nie powiedzą Ci, co poszło nie tak. Czasami implementacja wygląda świetnie, ale nie oznacza to, że software house wykonał całą pracę. Zapytaj o pierwotne wersje projektu, na którym się opierali. Porównaj je z wynikiem końcowym. Sprawdź przestrzeń między sekcjami, sprawdź rozmiary tytułów itp. Najłatwiej jest zrobić zrzut ekranu i umieścić go obok projektu wdrożonego.

Jak bardzo inne są ekrany? Jeśli zauważysz znaczącą różnicę, powinieneś zacząć zadawać pytanie: dlaczego nie wygląda jak projekt? Zazwyczaj powiedzą, że nie ma budżetu 🙂 Jest to powszechna wymówka, ale moim zdaniem dobrzy programiści mają bardzo dobrą precyzję już w implementacji i nie potrzebują na to dodatkowego czasu.

Dlaczego warto chwilę temu poświęcić? Zazwyczaj zajmie to trochę czasu, ale zaoszczędzisz pieniądze na nietrafionej współpracy. Często sprzedawcy obiecują gruszki na wierzbie, a ostateczny wynik nie jest już tak dobry.

Szczegóły są ważne

Ok, pierwsze wrażenie zostało zrobione. Ale co ze szczegółami? Czy projekt ma hovery? Animacje? Co z prędkością ładowania? Czy ma swój style guide? Jak zaimplementowali interakcje?

Na przykład w naszych projektach przygotowujemy niewielki style guide ze wszystkimi interakcjami. Pomaga to uniknąć „statycznego projektu”. Pamiętaj, że Twój użytkownik opuści witrynę, jeśli okaże się, że jest ona zbyt statyczna lub wygląda na ciężką. Wszystkie drobne szczegóły, takie jak np. interakcje po kliknięciu, powodują, że cała strona ożywa.

Spójrz tylko, jak może wyglądać prosta strona zaprojektowana na bazie style guide. Jest to prosta wersja style guide i przygotowanie jej przez projektanta nie trwało długo, za to jest bardzo pomocna dla programistów.

Implementacja RWD – różnych widoków

To częsty problem. Każdy software house ma inne praktyki, a ponadto każdy programista w jednym software house’ie może mieć inną metodę . Najlepsze software house’y nie potrzebuje projektów dla wszystkich ekranów i każdej rozdzielczości. Powinny one organizować swój kod w taki sposób, aby RWD (Responsive Web Design) zajęło kilka dodatkowych dni. Ważna jest również ich komunikacja z projektantami od samego początku.

Na przykład, naszą praktyką jest używanie własnej siatki i złotego systemu proporcji (Modular scale) – komunikujemy tą metodę od samego początku. Zwykle wybieramy 16 pikseli jako podstawowy rozmiar fontu, a wszystkie rozmiary są tylko wielkościami zależnymi od proporcji. Na przykład 16px to pierwszy poziom. potem trzeba mnożyć wartość przez 1,618 do drugiego poziomu i wychodzi nam 26px, trzeci poziom to 42px, a czwarty to 68px. Kiedy chcemy zrobić mobilną wersję, po prostu zmieniamy wielokrotność na 1.5, a to jest tylko jedna linia kodu w CSS, w wyniku czego mamy rozmiary telefonu na wszystkich ekranach :). Wszystko to trwa niewielką ilość czasu. Dla ciebie, jako właściciela, czy managera nie jest to takie ważne, ale powinieneś sprawdzić, czy mają jakąś wiedzę na temat takiej współpracy. Przykładowo programiście z Bejamas na bazie modular scale są w stanie przygotować widoki mobilne dosłownie w parę godzin. Podobnie ma się sytuacja w J-labs, Netguru, Cometarii czy Pragmatic Coders.

Czego unikać? Gdy programiści potrzebują wszystkich projektów RWD. Często oznacza to, że ludzie nie wiedzą, co robią lub chcą obciążyć Cię dodatkowymi kosztami. Oczywiście może się zdarzyć, że projektant zaprojektował coś konkretnego i potrzebuje osobnego widoku dla wersji mobilnej; ale naprawdę nie pamiętam projektu, w którym zaprojektowaliśmy wszystkie ekrany dla wszystkich rozdzielczości. Po raz kolejny podkreślę, dobra komunikacja z programistami i ustalanie zasad przed podjęciem współpracy powinna rozwiązać większość nieporozumień.

Wniosek

Rozumiem, że znaczna część projektów ma ograniczony budżet. Rozumiem, że koszty rozwoju są ogromne. Czasami nie powinno się oszczędzać, pracując z ludźmi, którzy nie wiedzą, co robią. Może naprawdę specjalizują się w jednym obszarze, ale jeśli nie wiedzą, co robić w innym, nie ryzykuj czasu i pieniędzy na współpracę.

A jeśli chciałbyś skonsultować swój nowy projekt, daj nam znać, a my zajmiemy się procesami UX i UI 🙂

Brzmi interesująco?

Chciałbyś zorganizować warsztaty dla Twojej firmy lub porozmawiać o procesie?

Kontakt
Tomasz Osowski
Pomaga firmom stworzyć doskonałe doświadczenie użytkownika zapewniając jednocześnie odpowiednią rentowność biznesu. Jego zdanie to stworzyć produkt i usługi, które są potrzebne i przynoszą satysfakcję zarówno odbiorcom jak i właścicielom biznesu.

Certyfikowany Trener Biznesu i rozwoju osobistego, Certyfikowany moderator Design Thinking. Przedsiębiorca od 6 lat szczerze zakochany w metodologii Lean. Zawsze stara się dostarczyć produkt jak najszybciej na rynek przy najmniejszym udziale kapitałowym.

Współpracował z firmami: T-mobile, Ecard, inPost, ING, Nationale Nederlanden, Brainly, Publicis, Netguru.

Znajdź nas

Czy chcesz nas lepiej poznać? Sprawdź nasze pozostałe portale społecznościowe

Newsletter

Zapisz się na nasz newsletter i otrzymuj co miesiąc: narzędzia, artykuły i najnowsze informacje o naszych warsztatach.