Are you interested? Call us!

Ti abbiamo interessato? Contattaci!

Zainteresowaliśmy Cię? Odezwij się!

Check what we have been living lately

Scoprite con cosa abbiamo vissuto di recente

Sprawdź, czym ostatnio żyjemy

Do you want to know our offer and talk about the needs of your business? Write to us, we will surely find the best solution.

Leave a number. We will call you back within 30 minutes.

Chcesz poznać nasza ofertę i porozmawiać na temat potrzeb Twojego biznesu? Napisz do nas, na pewno znajdziemy najlepsze rozwiązanie.

Zostaw numer. Oddzwonimy w przeciągu 30 minut.

We bring value by using the best, the most reliable technologies available on the eCommerce market. Our team makes sure that our clients have the ability to achieve their business goals in a way that is safe, predictable and at the highest level.
We have been operating since 2011, and our team consists of 80 people whose competences and knowledge are certified. Our goal is to always achieve the goal, and our know-how is the selection, implementation and development of the best and the most reliable eCommerce technologies. The success in Europe, Asia and North America, along with our experience in numerous industries and in various business models have established our position in the eCommerce world. However, as we believe that the only constant is change, we remain one step ahead at all times, following global trends in the online sales market.

This website uses cookies. By staying on this website, you consent to the use of cookies. Find out more on the <a href="/en/privacy-policy"> website </a>.

Monogo has joined the elite club of Business Gazelles, a group of the most dynamically developing polish companies.

Business Gazelle 2022 for Monogo

Featured products:

<a href="tel:+48531338668">+48 531 338 668</a> <a href="mailto:hello@monogo.pl">hello@monogo.pl</a>

Monogo

Lublin (HQ)

Aleje Jerozolimskie 181, 4th floor Poland

Warsaw

Parkland, 7527 NW 61st Ter, Florida USA

Florida, USA

Parkland, 7527 NW 61st Ter, Florida Usa

<a href="tel:+48531338668">+48 531 338 668</a> <a href="mailto:hello@monogo.pl">hello@monogo.pl</a>

About Monogo

E-Commerce

AI AND AUTOMATION

CLOUD INFRASTRUCTURE

KNOWLEDGE BASE

KONWLEDGE BASE

Questo sito web utilizza i cookie. Restando su questo sito acconsenti all'utilizzo dei cookie. Scopri di più sul sito web <a href="/en/privacy-policy"> </a>.

Prodotti sponsorizzati:

AI E AUTOMAZIONE

Adobe x Monogo, Adobe Partner Day in Warsaw (31st of August 2022)

Projektuję interfejsy dla użytkowników w oparciu od design thinking  już ponad 10 lat. Widziałem wielkie idee, które pomimo olbrzymich budżetów, zaangażowania zespołu i teoretycznie dobrego produktu nie osiągały sukcesów. Zastanawiałem się, z czego to wynikało i obiecałem sobie, że kiedy ja będę miał większą siłę sprawczą nie dopuszczę do porażki. Zacząłem analizować produkty, które upadły lub nie zostały nawet wprowadzone na rynek, gdyż pierwsze opinie użytkowników wskazywały, że produkt nie rozwiązuje żadnych problemów, z którymi się oni borykają. Często były one czymś "fancy", ale w zasadzie nie zmieniały doświadczeń klientów w znaczny sposób. Innym razem opierały się na jakimś niemal dogmacie- nasz klient wszystko przyjmie i niezależnie od tego jak "fikuśny" proces wymyślimy to on i tak z pokorą będzie przez niego przechodził. Oczywiście na końcu następowała weryfikacja i zderzenie się z rzeczywistością.

core/paragraph

Projektuję interfejsy dla użytkowników w oparciu od design thinking już ponad 10 lat. Widziałem wielkie idee, które pomimo olbrzymich budżetów, zaangażowania zespołu i teoretycznie dobrego produktu nie osiągały sukcesów. Zastanawiałem się, z czego to wynikało i obiecałem sobie, że kiedy ja będę miał większą siłę sprawczą nie dopuszczę do porażki. Zacząłem analizować produkty, które upadły lub nie zostały nawet wprowadzone na rynek, gdyż pierwsze opinie użytkowników wskazywały, że produkt nie rozwiązuje żadnych problemów, z którymi się oni borykają. Często były one czymś "fancy", ale w zasadzie nie zmieniały doświadczeń klientów w znaczny sposób. Innym razem opierały się na jakimś niemal dogmacie- nasz klient wszystko przyjmie i niezależnie od tego jak "fikuśny" proces wymyślimy to on i tak z pokorą będzie przez niego przechodził. Oczywiście na końcu następowała weryfikacja i zderzenie się z rzeczywistością.

core/heading

Co łączyło te wszystkie produkty, które odniosły porażkę? Miały one jeden, wspólny mianownik- realizowały jedynie cele biznesowe, bez zaangażowania użytkownika w proces. To na pewno. Kolejne cechy wyróżniające produkty niezyskujące poklasku to skupienie się w fazie analizy jedynie na funkcjonalnościach, które dostarczył klient. Często odbywa się to w ten sposób, że klient dostarcza dokument opisujący produkt, który chce stworzyć. Następnie zespół developerów wycenia "zakodowanie" tychże funkcjonalności, określany jest czas, gdzieś tam powstają makiety i… zaczyna się. Nagle okazuje się, że funkcjonalności opisane w zapytaniu nie zawierały niektórych aspektów, które pojawiły się kiedy projektant zaczął rysować makiety i z empatią pomyślał o użytkowniku końcowym lub niektórych funkcjonalności brakowało, aby w ogóle z powodzeniem móc przejść przez cały proces jako użytkownik.

Co łączyło te wszystkie produkty, które odniosły porażkę? Miały one jeden, wspólny mianownik- realizowały jedynie cele biznesowe, bez zaangażowania użytkownika w proces. To na pewno. Kolejne cechy wyróżniające produkty niezyskujące poklasku to skupienie się w fazie analizy jedynie na funkcjonalnościach, które dostarczył klient. Często odbywa się to w ten sposób, że klient dostarcza dokument opisujący produkt, który chce stworzyć. Następnie zespół developerów wycenia "zakodowanie" tychże funkcjonalności, określany jest czas, gdzieś tam powstają makiety i… zaczyna się. Nagle okazuje się, że funkcjonalności opisane w zapytaniu nie zawierały niektórych aspektów, które pojawiły się kiedy projektant zaczął rysować makiety i z empatią pomyślał o użytkowniku końcowym lub niektórych funkcjonalności brakowało, aby w ogóle z powodzeniem móc przejść przez cały proces jako użytkownik.

Co to powoduje? Ma to kosmiczne konsekwencje- dlatego, że zmienia się czas projektu, zmienia się też cena projektu i zaczynamy tracić kontrolę nad finalną formą produktu. W dodatku nigdy nie mamy pewności, że wszyscy rozumieją produkt w ten sam sposób oraz to jaki jest główny cel tego przedsięwzięcia. I finalnie- czy w ogóle nasz cel jest właściwy? Aby odpowiedzieć na to pytanie- wystarczy w fazie analizy/discovery znaleźć przestrzeń dla warsztatów w metodologii design thinking. Ale o co w tym wszystkim naprawdę chodzi?

Co to powoduje? Ma to kosmiczne konsekwencje- dlatego, że zmienia się czas projektu, zmienia się też cena projektu i zaczynamy tracić kontrolę nad finalną formą produktu. W dodatku nigdy nie mamy pewności, że wszyscy rozumieją produkt w ten sam sposób oraz to jaki jest główny cel tego przedsięwzięcia. I finalnie- czy w ogóle nasz cel jest właściwy? Aby odpowiedzieć na to pytanie- wystarczy w fazie analizy/discovery znaleźć przestrzeń dla warsztatów w metodologii design thinking. Ale o co w tym wszystkim naprawdę chodzi?

Design thinking opiera się w pierwszej kolejności na empatii. Empatia to najważniejsza cecha, która pomaga zrozumieć potrzeby innych. <a href="http://monogo.pl/customer-experience-user-experience-and-design" target="_blank" rel="noreferrer noopener">Chcemy zrozumieć użytkownika końcowego- to dla niego tworzymy produkt.</a> Staramy się zmapować potrzeby użytkownika oraz cele biznesowe i połączyć je ze sobą w harmonii.

Design thinking opiera się w pierwszej kolejności na empatii. Empatia to najważniejsza cecha, która pomaga zrozumieć potrzeby innych. <a href="http://monogo.pl/customer-experience-user-experience-and-design" target="_blank" rel="noreferrer noopener">Chcemy zrozumieć użytkownika końcowego- to dla niego tworzymy produkt.</a> Staramy się zmapować potrzeby użytkownika oraz cele biznesowe i połączyć je ze sobą w harmonii.

Aby zrozumieć użytkownika korzystamy z map empatii. To prosta mapa skupiająca się na kilku aspektach. Tym, co użytkownik myśli, słyszy, mówi i robi. Wypełnienie tej planszy pozwala umiejscowić użytkownika oraz produkt w konkretnym kontekście- sytuacji, w której musimy się poruszać jako dostawcy. Ma to jeden ważny aspekt- jesteśmy pewni co do tego, iż zarówno klient jak i zespół projektowy postrzega użytkownika w ten sam sposób. Wyobraź sobie zespół piłkarski, gdzie obrona i atak analizują zespół przeciwnika osobno- w dwóch różnych pokojach. Ciężko w takiej sytuacji o zrozumienie podczas meczu. To, co udaje się zniwelować podczas warsztatów design thinking to różnica w wieży pomiędzy klientem a dostawcą. Tworzymy jeden zespół grający do jednej bramki.

Aby zrozumieć użytkownika korzystamy z map empatii. To prosta mapa skupiająca się na kilku aspektach. Tym, co użytkownik myśli, słyszy, mówi i robi. Wypełnienie tej planszy pozwala umiejscowić użytkownika oraz produkt w konkretnym kontekście- sytuacji, w której musimy się poruszać jako dostawcy. Ma to jeden ważny aspekt- jesteśmy pewni co do tego, iż zarówno klient jak i zespół projektowy postrzega użytkownika w ten sam sposób. Wyobraź sobie zespół piłkarski, gdzie obrona i atak analizują zespół przeciwnika osobno- w dwóch różnych pokojach. Ciężko w takiej sytuacji o zrozumienie podczas meczu. To, co udaje się zniwelować podczas warsztatów design thinking to różnica w wieży pomiędzy klientem a dostawcą. Tworzymy jeden zespół grający do jednej bramki.

Kiedy rozumiemy użytkownika, mamy wypełnione mapy empatii powoli zaczynamy <a href="http://monogo.pl/blog/jak-projektowac-interfejsy-w-dobie-m-commerce" target="_blank" rel="noreferrer noopener">definiować cel produktu</a>. Żeby określić cel należy zdefiniować wszystkie problemy, z jakimi boryka się użytkownik oraz biznes. Metod na określenie tych bolączek jest kilka- dobierane są one adekwatnie do grupy obecnej na warsztatach. Możemy korzystać z prostej burzy mózgów, metody "róż, cierni i pączków" czy szeregu innych metodologii, które opiszę w kolejnym artykule. Konsekwencją tego etapu jest mapa czy też tablica wszystkich bolączek, jakie chcemy zniwelować.

Kiedy rozumiemy użytkownika, mamy wypełnione mapy empatii powoli zaczynamy <a href="http://monogo.pl/blog/jak-projektowac-interfejsy-w-dobie-m-commerce" target="_blank" rel="noreferrer noopener">definiować cel produktu</a>. Żeby określić cel należy zdefiniować wszystkie problemy, z jakimi boryka się użytkownik oraz biznes. Metod na określenie tych bolączek jest kilka- dobierane są one adekwatnie do grupy obecnej na warsztatach. Możemy korzystać z prostej burzy mózgów, metody "róż, cierni i pączków" czy szeregu innych metodologii, które opiszę w kolejnym artykule. Konsekwencją tego etapu jest mapa czy też tablica wszystkich bolączek, jakie chcemy zniwelować.

Na problemy trzeba patrzeć szeroko. Zastanowić się nad każdym kontaktem użytkownika z marką i zmapować wszystkie bolączki. Następnie wybieramy te, które chcemy rozwiązać w pierwszej kolejności- z największą korzyścią dla naszego biznesu oraz użytkownika.

Na problemy trzeba patrzeć szeroko. Zastanowić się nad każdym kontaktem użytkownika z marką i zmapować wszystkie bolączki. Następnie wybieramy te, które chcemy rozwiązać w pierwszej kolejności- z największą korzyścią dla naszego biznesu oraz użytkownika.

Etap trzeci to etap najprzyjemniejszy, gdyż tutaj zaczynamy skupiać się na rozwiązaniach wcześniej wyszczególnionych problemów. To tutaj zaczyna się rysować obraz naszego produktu. Wielokrotnie w projektach zapomina się o etapach pierwszym i drugim, rozpoczynając od razu od pomysłów. Klienci możliwe, że przeprowadzają wewnętrznie analizę problemów oraz klientów, lecz bez uczestnictwa dostawców jest dysonans poznawczy. Dostawca nie rozumie, po co tworzy produkt- co prowadzi do częstych nieporozumień. Mając jednak pomysły rozwiązujące problemy, możemy określić cel. Kiedy wszyscy rozumieją cel, możemy przejść do kolejnego etapu- Makiet i prototypu.

Etap trzeci to etap najprzyjemniejszy, gdyż tutaj zaczynamy skupiać się na rozwiązaniach wcześniej wyszczególnionych problemów. To tutaj zaczyna się rysować obraz naszego produktu. Wielokrotnie w projektach zapomina się o etapach pierwszym i drugim, rozpoczynając od razu od pomysłów. Klienci możliwe, że przeprowadzają wewnętrznie analizę problemów oraz klientów, lecz bez uczestnictwa dostawców jest dysonans poznawczy. Dostawca nie rozumie, po co tworzy produkt- co prowadzi do częstych nieporozumień. Mając jednak pomysły rozwiązujące problemy, możemy określić cel. Kiedy wszyscy rozumieją cel, możemy przejść do kolejnego etapu- Makiet i prototypu.

O ile każdy rozumie czym są makiety oraz prototypy to nie każdy docenia ich przygotowanie w ramach analizy czy fazy discovery. Często makiety pojawiają się już po analizie funkcjonalności i estymacji kosztów. Podejście to generuje kilka problemów, o których wspominałem we wstępie tego artykułu. Nie jesteśmy w stanie określić dokładnie wszystkich funkcjonalności bez makiet oraz finalnego kosztu developmentu, kiedy nie widzimy jak wygląda produkt. Jeśli chcesz zapanować dokładnie nad kosztami oraz czasem to powinieneś poprosić dostawcę, aby przygotował makiety (mogą być wireframe głównych funkcjonalności i ścieżek) w ramach analizy. Poza możliwością określenia kosztu- widzisz zarys swojego produktu oraz to czy odpowiada on na wcześniej zdefiniowane potrzeby. Największym skarbem jednak jaki stanowią makiety jest możliwość przeprowadzenia kolejnego etapu- testów.

O ile każdy rozumie czym są makiety oraz prototypy to nie każdy docenia ich przygotowanie w ramach analizy czy fazy discovery. Często makiety pojawiają się już po analizie funkcjonalności i estymacji kosztów. Podejście to generuje kilka problemów, o których wspominałem we wstępie tego artykułu. Nie jesteśmy w stanie określić dokładnie wszystkich funkcjonalności bez makiet oraz finalnego kosztu developmentu, kiedy nie widzimy jak wygląda produkt. Jeśli chcesz zapanować dokładnie nad kosztami oraz czasem to powinieneś poprosić dostawcę, aby przygotował makiety (mogą być wireframe głównych funkcjonalności i ścieżek) w ramach analizy. Poza możliwością określenia kosztu- widzisz zarys swojego produktu oraz to czy odpowiada on na wcześniej zdefiniowane potrzeby. Największym skarbem jednak jaki stanowią makiety jest możliwość przeprowadzenia kolejnego etapu- testów.

Etap testów makiet czy prototypu umożliwia ocenę rozwiązania przez grupę fokusową- a więc realnych użytkowników. To tutaj wykorzystując np. Maze lub inne narzędzia masz możliwość sprawdzenia całej koncepcji, lub głównych nurtów i ścieżek jeszcze przed uwolnieniem budżetu na development. To tutaj dowiesz się, czy Twój produkt spełnia oczekiwania biznesowe oraz oczekiwania użytkowników. To dobry moment, aby wycofać się z niepotrzebnych funkcjonalności lub dodać to co może stanowić o sukcesie. Otrzymujesz raport, dane, liczby i na tej podstawie możesz decydować o finalnym kształcie produktu.

Etap testów makiet czy prototypu umożliwia ocenę rozwiązania przez grupę fokusową- a więc realnych użytkowników. To tutaj wykorzystując np. Maze lub inne narzędzia masz możliwość sprawdzenia całej koncepcji, lub głównych nurtów i ścieżek jeszcze przed uwolnieniem budżetu na development. To tutaj dowiesz się, czy Twój produkt spełnia oczekiwania biznesowe oraz oczekiwania użytkowników. To dobry moment, aby wycofać się z niepotrzebnych funkcjonalności lub dodać to co może stanowić o sukcesie. Otrzymujesz raport, dane, liczby i na tej podstawie możesz decydować o finalnym kształcie produktu.

Wiesz już czym jest design thinking i jak może pomóc podczas planowania budżetu oraz określania finalnej formy produktu. Jak natomiast zaimplementować tę metodologię w taki sposób, aby móc stosować w projektach agile? To stosunkowo proste. Wiele zespołów, z którymi miałem okazję pracować postępuje w ten sposób:

Wiesz już czym jest design thinking i jak może pomóc podczas planowania budżetu oraz określania finalnej formy produktu. Jak natomiast zaimplementować tę metodologię w taki sposób, aby móc stosować w projektach agile? To stosunkowo proste. Wiele zespołów, z którymi miałem okazję pracować postępuje w ten sposób:

Analityk definiuje problem -&gt; Zadanie trafia do backlog -&gt; tworzone są makiety -&gt; development -&gt; testy rozwiązania

Analityk definiuje problem -&gt; Zadanie trafia do backlog -&gt; tworzone są makiety -&gt; development -&gt; testy rozwiązania

core/image

core/column

core/columns

proponowany przeze mnie proces w duchu design thinking:

proponowany przeze mnie proces w duchu design thinking:

Analityk definiuje problem -&gt; tworzone są makiety -&gt; testy rozwiązania -&gt; zadanie trafia do backlog -&gt; development.

Analityk definiuje problem -&gt; tworzone są makiety -&gt; testy rozwiązania -&gt; zadanie trafia do backlog -&gt; development.

Różnica jest widoczna. Do backlog trafiają już przetestowane rozwiązania na etapie makiet. Oczywiście rekomendowane jest przeprowadzenie analizy po go-live, lecz zmniejszamy ryzyko do wprowadzenia na rynek nieadekwatnego produktu do minimum. Zmniejszamy też ilość iteracji i zmian w kodzie do minimum. I wreszcie ostatni punkt- możemy wprowadzać na rynek absolutne minimum, rozwiązujące największe bolączki, a nie podchodzić do produktu w sposób niemal "waterfall" - wszystkie funkcjonalności naraz. O ile trafiliśmy z potrzebami użytkowników to podejście "waterfall" nie jest złe. Gorzej jeśli spędziliśmy rok czy więcej na tworzeniu rozwiązania, które nie adresuje potrzeb rynku, a przez brak testów na etapie makiet nie zauważyliśmy tego problemu.

Różnica jest widoczna. Do backlog trafiają już przetestowane rozwiązania na etapie makiet. Oczywiście rekomendowane jest przeprowadzenie analizy po go-live, lecz zmniejszamy ryzyko do wprowadzenia na rynek nieadekwatnego produktu do minimum. Zmniejszamy też ilość iteracji i zmian w kodzie do minimum. I wreszcie ostatni punkt- możemy wprowadzać na rynek absolutne minimum, rozwiązujące największe bolączki, a nie podchodzić do produktu w sposób niemal "waterfall" - wszystkie funkcjonalności naraz. O ile trafiliśmy z potrzebami użytkowników to podejście "waterfall" nie jest złe. Gorzej jeśli spędziliśmy rok czy więcej na tworzeniu rozwiązania, które nie adresuje potrzeb rynku, a przez brak testów na etapie makiet nie zauważyliśmy tego problemu.

Podejście design thinking pomaga nie tylko dostarczać produkty pięknie i użyteczne, ale również umożliwia optymalizację budżetu. Jeżeli jesteś zainteresowany implementacją design thinking w Twojej organizacji lub w proces tworzenia Twojego produktu- <a href="http://monogo.pl/kontakt" target="_blank" rel="noreferrer noopener">skontaktuj się </a>ze mną w ramach bezpłatnej i niezobowiązującej konsultacji:

Podejście design thinking pomaga nie tylko dostarczać produkty pięknie i użyteczne, ale również umożliwia optymalizację budżetu. Jeżeli jesteś zainteresowany implementacją design thinking w Twojej organizacji lub w proces tworzenia Twojego produktu- <a href="http://monogo.pl/kontakt" target="_blank" rel="noreferrer noopener">skontaktuj się </a>ze mną w ramach bezpłatnej i niezobowiązującej konsultacji:

core/button

<div class="wp-block-button"><a class="wp-block-button__link" href="https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ31GSepTin1DcRcuj3E8j_fOUqB8KFDjx2UrZDgZoqRW6iw78ZDxTJ0_mi7vj6j2TU2CByHuVlP" target="_blank" rel="noreferrer noopener">Zarezerwuj termin konsultacji</a></div>

core/buttons

Projekty IT powstają w oparciu o wymagania zbierane wewnętrznie przez klienta oraz warsztaty uszczegóławiające zakres przedsięwzięcia. Dostawca przygotowuje wycenę, jeśli jest zgoda co do budżetu i oczekiwań to zespół projektowy przystępuje do tworzenia produktu. Potem zostaje już tylko uruchomienie produkcyjne. Dalej mamy zmiany wynikające z potrzeb użytkownika. Uznajemy to za normalny stan rzeczy ale czy to jest dobre podejście? Czy możemy ograniczyć ilość zmian po wdrożeniu tak, aby maksymalnie wykorzystać budżet na rozwój jedynie potrzebnych funkcjonalności, stworzenie produktu idealnego? Okazuje się, że tak - odpowiedzią jest Design Thinking oraz User Centered Design.

Moc design thinking w projektowaniu dla IT