Are you interested?  <br />Call us!

Ti abbiamo interessato? <br />Contattaci!

Zainteresowaliśmy Cię?  <br />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.

<p class="text-26 lg:text-26 mb-7"><strong>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.</strong></p>
<p>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.</p>


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 <strong>Business Gazelles</strong>, 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> <br> <a href="mailto:hello@monogo.pl">hello@monogo.pl</a>

Monogo

Lublin (HQ)

Aleje Jerozolimskie 181, 4th floor <br> Poland

Warsaw

Parkland, 7527 NW 61st Ter, Florida<br> USA

Florida, USA

Parkland, 7527 NW 61st Ter, Florida<br> Usa

<a href="tel:+48531338668">+48 531 338 668</a><br><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

Monogo - umow bezplatną rozmowe - kontakt

Relacja z Adobe Summit 2023 – najważniejsze wnioski

Projektowanie makiet funkcjonalności&nbsp;

core/heading

<h2>Projektowanie makiet funkcjonalności&nbsp;</h2>

Obecnie scrum jest wykorzystywany w około 56% zespołów pracujących w sektorze IT. Ponad połowa zespołów prędzej czy później zmierzy się z wyzwaniem zaadoptowania procesów <a href="https://monogo.pl/customer-experience-user-experience-and-design" target="_blank" rel="noreferrer noopener">UX</a> do frameworku scrum. Dlaczego uważam to za wyzwanie? Pracując w branży ponad 10 lat, rozmawiając z innymi specjalistami z branży UX można jednoznacznie stwierdzić, że obecnie standardem jest funkcjonowanie osobnych procesów dla faz discovery i delivery. I jest w tym siła, ale jedynie w przypadku projektów powstających zupełnie od czystej karty, gdzie budujemy produkt od zera i to jedynie w jego w początkowej fazie.

core/paragraph

<p>Obecnie scrum jest wykorzystywany w około 56% zespołów pracujących w sektorze IT. Ponad połowa zespołów prędzej czy później zmierzy się z wyzwaniem zaadoptowania procesów <a href="https://monogo.pl/customer-experience-user-experience-and-design" target="_blank" rel="noreferrer noopener">UX</a> do frameworku scrum. Dlaczego uważam to za wyzwanie? Pracując w branży ponad 10 lat, rozmawiając z innymi specjalistami z branży UX można jednoznacznie stwierdzić, że obecnie standardem jest funkcjonowanie osobnych procesów dla faz discovery i delivery. I jest w tym siła, ale jedynie w przypadku projektów powstających zupełnie od czystej karty, gdzie budujemy produkt od zera i to jedynie w jego w początkowej fazie. </p>

W każdym innym przypadku podejście to generuje problemy. Makiety powstają w oderwaniu od technologii. Projektanci mogą nie być świadomi ograniczeń technologicznych lub czasu potrzebnego na development zaprojektowanych funkcjonalności, a deweloperzy są sfrustrowani. Często brakuje im w zespole osoby, która wytłumaczyłaby idee przyświecającą autorowi kiedy to projektował daną funkcjonalność. Nie mogą poprosić o wprowadzenie na makiety zmian wynikających z analizy technicznej, przez co finalnie makiety są bardziej inspiracją niż finalną wersją produktu.&nbsp;

<p>W każdym innym przypadku podejście to generuje problemy. Makiety powstają w oderwaniu od technologii. Projektanci mogą nie być świadomi ograniczeń technologicznych lub czasu potrzebnego na development zaprojektowanych funkcjonalności, a deweloperzy są sfrustrowani. Często brakuje im w zespole osoby, która wytłumaczyłaby idee przyświecającą autorowi kiedy to projektował daną funkcjonalność. Nie mogą poprosić o wprowadzenie na makiety zmian wynikających z analizy technicznej, przez co finalnie makiety są bardziej inspiracją niż finalną wersją produktu.&nbsp;</p>

<h2>Fazy tworzenia produktu w zgodzie z UX</h2>

Skąd wynika twarde i naturalne dzielenie p<a href="http://monogo.pl/blog/audyt-ux-pierwszy-krok-do-zwiekszonej-sprzedazy" target="_blank" rel="noreferrer noopener">rocesu tworzenia produktu</a> cyfrowego na fazy discovery i delivery? Nie mam na to badań, ale mogę posłużyć się moją refleksją. To pokłosie początków branży, gdzie IT mocno wspomagało się współpracą z agencjami digitalowymi w zakresie makiet. Agencja wykonywała fazę discovery - persony, user journey, badania i wreszcie makiety. Następnie cały ten zestaw przekazywany był do firmy obsługującej IT… w ten sposób naturalnie powstał powyższy podział. Model ten jest niestety kontynuowany również w organizacjach, które tworzą działy UX u siebie lub outsourcują usługi IT. Często Business Analyst pracuje z UX podczas fazy discovery, następnie po wykonaniu makiet, UX wyłączany jest z procesu delivery i scrum. Nie uczestniczy w ceremoniach, traci kontakt z produktem, którego jest autorem. To odwrotność tego co charakteryzuje liderów produktów cyfrowych.

<p>Skąd wynika twarde i naturalne dzielenie p<a href="http://monogo.pl/blog/audyt-ux-pierwszy-krok-do-zwiekszonej-sprzedazy" target="_blank" rel="noreferrer noopener">rocesu tworzenia produktu</a> cyfrowego na fazy discovery i delivery? Nie mam na to badań, ale mogę posłużyć się moją refleksją. To pokłosie początków branży, gdzie IT mocno wspomagało się współpracą z agencjami digitalowymi w zakresie makiet. Agencja wykonywała fazę discovery - persony, user journey, badania i wreszcie makiety. Następnie cały ten zestaw przekazywany był do firmy obsługującej IT… w ten sposób naturalnie powstał powyższy podział. Model ten jest niestety kontynuowany również w organizacjach, które tworzą działy UX u siebie lub outsourcują usługi IT. Często Business Analyst pracuje z UX podczas fazy discovery, następnie po wykonaniu makiet, UX wyłączany jest z procesu delivery i scrum. Nie uczestniczy w ceremoniach, traci kontakt z produktem, którego jest autorem. To odwrotność tego co charakteryzuje liderów produktów cyfrowych. </p>

Projektując topowy produkt dla marki będącej w top 3 firm farmaceutycznych na świecie mogłem doświadczyć potęgi adaptacji UX do procesu scrum. Po 2 latach od tego projektu nadal uważam, że takie podejście pozwala zmaksymalizować potencjał budżetu poświęcanego zarówno na UX jak i development. Idea ta przyświeca nam teraz wszystkim w Monogo podczas planowania projektów dla naszych klientów.

<p>Projektując topowy produkt dla marki będącej w top 3 firm farmaceutycznych na świecie mogłem doświadczyć potęgi adaptacji UX do procesu scrum. Po 2 latach od tego projektu nadal uważam, że takie podejście pozwala zmaksymalizować potencjał budżetu poświęcanego zarówno na UX jak i development. Idea ta przyświeca nam teraz wszystkim w Monogo podczas planowania projektów dla naszych klientów.</p>

Jak włączyć UX do procesu scrum w efektywny sposób?&nbsp;

<h2>Jak włączyć UX do procesu scrum w efektywny sposób?&nbsp;</h2>

Pierwszym sposobem jest stworzenie dwóch naprzemiennych sprintów - UX oraz Delivery. Prace UX poprzedzają prace developerskie o jeden sprint. Sprinty trwają dwa tygodnie, w połowie sprintu UX następuje weryfikacja makiet. Nanoszone są uwagi zespołu technicznego, product ownera lub dowolnego członka zespołu scrum, ważnego dla danego kontekstu tworzenia produktu. Na końcu sprintu powstaje makieta gotowej funkcjonalności, przekazywana jest ona do implementacji. Można pomyśleć, że przecież w podejściu tym niewiele się zmienia. Również mamy osobny zespół UX oraz dev. To fakt, lecz jest to zalążek podejścia, w którym istnieje część przecięcia się tych dwóch światów. Spotkania Dev + BA + Product Owner + dowolny członek zespołu, w połowie sprintu UX pozwala na zlikwidowanie wielu czynników, które destabilizują proces delivery. Mamy przestrzeń do wyrównania wiedzy o produkcie, poznania genezy oraz propozycji zmian wynikających z natury technicznej lub długiego czasu potrzebnego na implementacje.

<p>Pierwszym sposobem jest stworzenie dwóch naprzemiennych sprintów - UX oraz Delivery. Prace UX poprzedzają prace developerskie o jeden sprint. Sprinty trwają dwa tygodnie, w połowie sprintu UX następuje weryfikacja makiet. Nanoszone są uwagi zespołu technicznego, product ownera lub dowolnego członka zespołu scrum, ważnego dla danego kontekstu tworzenia produktu. Na końcu sprintu powstaje makieta gotowej funkcjonalności, przekazywana jest ona do implementacji. Można pomyśleć, że przecież w podejściu tym niewiele się zmienia. Również mamy osobny zespół UX oraz dev. To fakt, lecz jest to zalążek podejścia, w którym istnieje część przecięcia się tych dwóch światów. Spotkania Dev + BA + Product Owner + dowolny członek zespołu, w połowie sprintu UX pozwala na zlikwidowanie wielu czynników, które destabilizują proces delivery. Mamy przestrzeń do wyrównania wiedzy o produkcie, poznania genezy oraz propozycji zmian wynikających z natury technicznej lub długiego czasu potrzebnego na implementacje.</p>

Najlepszą jednak formą pokazującą&nbsp;najwyższą dojrzałość organizacji jest dodanie specjalisty UX jako członka zespołu scrum. W tym podejściu zadania UXowe, researchowe oraz developerskie trafiają do jednego backlogu. UX z BA pracują nad backlogiem nieustannie i w zasadzie są głównymi aktorami ceremonii Backlog Refinement. To oni dostarczają uzupełnione user stories zarówno jeśli chodzi o AC oraz makiety gotowych rozwiązań. Jeśli na backlog refinement pojawiają się zmiany/niejasności, to BA oraz UX są odpowiedzialni za dostarczenie tasków w takiej formie, aby mogły być one estymowane oraz następnie ‘brane’ na sprint. Wymiana wiedzy o produkcie oraz wszelka potrzeba zmiany koncepcji jest komunikowana na bieżąco.&nbsp;

<p>Najlepszą jednak formą pokazującą&nbsp;najwyższą dojrzałość organizacji jest dodanie specjalisty UX jako członka zespołu scrum. W tym podejściu zadania UXowe, researchowe oraz developerskie trafiają do jednego backlogu. UX z BA pracują nad backlogiem nieustannie i w zasadzie są głównymi aktorami ceremonii Backlog Refinement. To oni dostarczają uzupełnione user stories zarówno jeśli chodzi o AC oraz makiety gotowych rozwiązań. Jeśli na backlog refinement pojawiają się zmiany/niejasności, to BA oraz UX są odpowiedzialni za dostarczenie tasków w takiej formie, aby mogły być one estymowane oraz następnie ‘brane’ na sprint. Wymiana wiedzy o produkcie oraz wszelka potrzeba zmiany koncepcji jest komunikowana na bieżąco.&nbsp;</p>

Specjalista UX jest dostępny w każdym momencie i dba o zgodność makiety z finalną wersją produktu. W nomenklaturze scrum jest deweloperem, dbającym o increment. Zdecydowanie łatwiej w takim podejściu zagospodarować czas na badania i developować jedynie potwierdzone hipotezy.

<p>Specjalista UX jest dostępny w każdym momencie i dba o zgodność makiety z finalną wersją produktu. W nomenklaturze scrum jest deweloperem, dbającym o increment. Zdecydowanie łatwiej w takim podejściu zagospodarować czas na badania i developować jedynie potwierdzone hipotezy.</p>

Co zyskasz dodając specjalistę UX jako członka zespołu scrum?&nbsp;

<h2>Co zyskasz dodając specjalistę UX jako członka zespołu scrum?&nbsp;</h2>

Przede wszystkim kluczowa jest możliwość testowania rozwiązania z użytkownikami na różnych etapach projektu. Jednakowo od makiety przez klikalny prototyp po produkt na środowisku testowym. Wszelka potrzeba zmian wynikająca z wywiadów z użytkownikami czy change request przechodzą przez autora rozwiązania. W zasadzie UX jako jedyna osoba w całym zespole jest w stanie przewidzieć konsekwencje wprowadzanych zmian. A wszystko to w szerokim kontekście user journey produktu. Bez takiej osoby produkt weryfikowany jest dopiero w wersji go-live na podstawie badań ilościowych. To duże ryzyko biznesowe.&nbsp;

<p>Przede wszystkim kluczowa jest możliwość testowania rozwiązania z użytkownikami na różnych etapach projektu. Jednakowo od makiety przez klikalny prototyp po produkt na środowisku testowym. Wszelka potrzeba zmian wynikająca z wywiadów z użytkownikami czy change request przechodzą przez autora rozwiązania. W zasadzie UX jako jedyna osoba w całym zespole jest w stanie przewidzieć konsekwencje wprowadzanych zmian. A wszystko to w szerokim kontekście user journey produktu. Bez takiej osoby produkt weryfikowany jest dopiero w wersji go-live na podstawie badań ilościowych. To duże ryzyko biznesowe.&nbsp;</p>

Budżet przepalony, użytkownicy nie konwertują tak jak powinni. Zdecydowanie tańsze jest dodanie specjalisty UX jako członka zespołu scrum. Specjalista UX w tym modelu może rysować i weryfikować każdą hipotezę, jaką zespół uzna za wartą zweryfikowania. Przeprowadzi wywiady pogłębione, przeanalizuje dane, przygotuje testy A/B i narysuje tyle wersji rozwiązania ile potrzeba. A ostatecznie wybierze tą najlepszą, czy to z perspektywy technologii, czasu developmentu i wreszcie użytkownika.&nbsp;

<p>Budżet przepalony, użytkownicy nie konwertują tak jak powinni. Zdecydowanie tańsze jest dodanie specjalisty UX jako członka zespołu scrum. Specjalista UX w tym modelu może rysować i weryfikować każdą hipotezę, jaką zespół uzna za wartą zweryfikowania. Przeprowadzi wywiady pogłębione, przeanalizuje dane, przygotuje testy A/B i narysuje tyle wersji rozwiązania ile potrzeba. A ostatecznie wybierze tą najlepszą, czy to z perspektywy technologii, czasu developmentu i wreszcie użytkownika.&nbsp;</p>

Będzie prowadził spotkania dotykające tworzenia makiet funkcjonalności. Wyjaśni, dlaczego akurat tak zaprojektował daną funkcjonalność i czy zmiany proponowane przez zespół nie zaburzają procesu w jakimś innym miejscu, o którym zespół może jeszcze nie wiedzieć. Wszystko dlatego, że UX projektuje rozwiązanie do przodu. Może wiedzieć, że  ta konkretna funkcja będzie rozwijana w jakimś kierunku, dlatego świadomość wszystkich zaangażowanych w projekt, co do koncepcji autora rozwiązania, jest w tym wypadku niezwykle ważna.

<p>Będzie prowadził spotkania dotykające tworzenia makiet funkcjonalności. Wyjaśni, dlaczego akurat tak zaprojektował daną funkcjonalność i czy zmiany proponowane przez zespół nie zaburzają procesu w jakimś innym miejscu, o którym zespół może jeszcze nie wiedzieć. Wszystko dlatego, że UX projektuje rozwiązanie do przodu. Może wiedzieć, że  ta konkretna funkcja będzie rozwijana w jakimś kierunku, dlatego świadomość wszystkich zaangażowanych w projekt, co do koncepcji autora rozwiązania, jest w tym wypadku niezwykle ważna.</p>

I wreszcie - UX może skupić się na jakości dostarczania coraz lepszej jakości makiet z perspektywy zespołu. Co więcej, określić jakość dostarczanego tzw. incrementu.

<p>I wreszcie - UX może skupić się na jakości dostarczania coraz lepszej jakości makiet z perspektywy zespołu. Co więcej, określić jakość dostarczanego tzw. incrementu.</p>

<h2>Podsumowanie roli UX w procesie Scrum</h2>

Dobrze zaprojektowana strona to strona stworzona z myślą o kliencie. Znasz powiedzenie: „Raz, a dobrze”?&nbsp; Bez specjalisty UX i regularnych badań nie jesteś w stanie określić zasadności kierunku, w jakim zmierza projekt. Dodając UX na stałe do procesu scrum oszczędzasz czas zespołu i pieniądze, mając pewność, że realizujesz założone cele. Nie bez powodu liderzy produktów cyfrowych realizują filozofię <a href="http://monogo.pl/blog/moc-design-thinking-w-projektowaniu-dla-it" target="_blank" rel="noreferrer noopener">design thinking it </a>w swoich projektach.&nbsp;

<p>Dobrze zaprojektowana strona to strona stworzona z myślą o kliencie. Znasz powiedzenie: „Raz, a dobrze”?&nbsp; Bez specjalisty UX i regularnych badań nie jesteś w stanie określić zasadności kierunku, w jakim zmierza projekt. Dodając UX na stałe do procesu scrum oszczędzasz czas zespołu i pieniądze, mając pewność, że realizujesz założone cele. Nie bez powodu liderzy produktów cyfrowych realizują filozofię <a href="http://monogo.pl/blog/moc-design-thinking-w-projektowaniu-dla-it" target="_blank" rel="noreferrer noopener">design thinking it </a>w swoich projektach.&nbsp;</p>

Chcesz zaimplementować <a href="https://monogo.pl/customer-experience-user-experience-and-design" target="_blank" rel="noreferrer noopener">UX</a> do swojego procesu scrum w organizacji?

<p>Chcesz zaimplementować <a href="https://monogo.pl/customer-experience-user-experience-and-design" target="_blank" rel="noreferrer noopener">UX</a> do swojego procesu scrum w organizacji?</p>

Umów się na niezobowiązującą rozmowę. <a href="http://monogo.pl/kontakt" target="_blank" rel="noreferrer noopener">Zachęcam do kontaktu.</a>&nbsp;

<p>Umów się na niezobowiązującą rozmowę. <a href="http://monogo.pl/kontakt" target="_blank" rel="noreferrer noopener">Zachęcam do kontaktu.</a>&nbsp;</p>

core/html

<p class="text-justify">W Monogo obserwujemy wzrost zainteresowania tematami związanymi z User Experience. Większość klientów chce inwestować w kreację idealnych doświadczeń użytkownika. Bardzo często okazuje się jednak, że jedynie liderzy mają świadomość tego, jak powinien funkcjonować zespół projektowy, aby wykorzystać pełen potencjał specjalistów UX. Co różni liderów branż od firm aspirujących do tego miana jeśli chodzi o proces dostarczania produktu? W jaki sposób dołączyć UX do procesu scrum w Twojej organizacji? I wreszcie  - co zyskam dodając UX na stałe do procesu scrum? Na te pytania odpowiem w treści poniższego artykułu.</p>

Rola UX w procesie SCRUM