Od 15 lat pracuję dla banków (Pekao, ING, Citi Handlowy), retailu (Carrefour) i międzynarodowych klientów (Beckett Collectibles, USA). Ostatni projekt w Pekao S.A. obejmował PeoPay oraz obszar ID & Authentication.
For 15 years, I have worked with banks (Pekao, ING, Citi Handlowy), retail (Carrefour) and international clients (Beckett Collectibles, USA). My latest Pekao S.A. project covered PeoPay and the ID & Authentication domain.
Systemy wewnętrzne, ecommerce i aplikacje mobilne. Praca w zespołach produktowych i zarządzanie nimi. Internal systems, ecommerce, and mobile apps. Working in product teams and leading them.
Interfejs do budowania zapytań, filtrowania i pracy na rekordach w bazie liczącej około 60 milionów pozycji.
Interface for building queries, filtering, and working with records in a database of around 60 million items.
Prowadzę pełny proces projektowy — od założeń po wdrożenie, utrzymanie i rozwój. Projektuję i wdrażam zarówno całe aplikacje, jak i pojedyncze funkcje w istniejących produktach.
I lead the full design process — from assumptions to implementation, maintenance, and further development. I design and deliver both full applications and individual features within existing products.
Chętnie porozmawiam o tym, jak mogę pomóc. I’d be happy to talk about how I can help.
Od ponad 15 lat projektuję produkty dla bankowości, retailu i firm technologicznych.
For over 15 years I have designed products for banking, retail, and technology companies.
Pracuję na styku biznesu, technologii i użytkowników — od zrozumienia problemu, przez strategię i projektowanie, aż do wdrożenia.
I work at the intersection of business, technology, and users — from understanding the problem, through strategy and design, to implementation.
Interesują mnie nie tylko ekrany. Interesuje mnie to, dlaczego produkt działa albo dlaczego przestaje działać.
I am interested not only in screens, but in why a product works, or why it stops working.
Agencja, zespół, produkt. Każdy etap nauczył mnie patrzeć szerzej i łączyć potrzeby użytkowników z celami biznesowymi.
Agency, team, product. Each stage taught me to look wider and connect user needs with business goals.
Dobry produkt powstaje wtedy, gdy decyzje projektowe uwzględniają ograniczenia technologiczne, cele biznesowe i sposób pracy zespołu. To właśnie na styku tych obszarów czuję się najlepiej.
A good product is shaped when design decisions take technical constraints, business goals, and team workflows into account. This is where I work best.
Poznałem projektowanie od strony realizacji, klientów i codziennej pracy z biznesem.
I learned design through delivery, client work, and everyday collaboration with business teams.
Projektowałem złożone systemy dla banków i dużych organizacji, gdzie każda decyzja wpływała na tysiące użytkowników.
I designed complex systems for banks and large organizations, where every decision affected thousands of users.
Budowałem zespół, prowadziłem projekty i odpowiadałem za jakość procesu projektowego — od rekrutacji po delivery.
I built a team, led projects, and was responsible for the quality of the design process — from hiring to delivery.
Wspieram organizacje jako partner projektowy, pomagając porządkować złożone produkty i procesy.
I support organizations as a design partner, helping structure complex products and processes.
Interfejs to tylko fragment produktu. Równie ważne są procesy, dane, technologia i sposób pracy zespołu. Dobre decyzje projektowe zaczynają się od zrozumienia całego kontekstu.
The interface is only one part of a product. Processes, data, technology, and team workflows matter just as much. Good design decisions start with understanding the full context.
Każdy projekt ma ograniczenia: czas, budżet, technologię czy wymagania regulacyjne. Nie traktuję ich jako przeszkód, ale jako element projektowania.
Every project has constraints: time, budget, technology, or regulatory requirements. I do not treat them as obstacles, but as part of the design process.
Najlepsze rozwiązania często nie polegają na dodawaniu kolejnych funkcji. Polegają na usunięciu niepotrzebnej złożoności.
The best solutions are often not about adding more features. They are about removing unnecessary complexity.
AI jest dla mnie narzędziem, nie celem. Wykorzystuję AI tam, gdzie pozwala szybciej przejść od problemu do decyzji projektowej. Pomaga mi analizować dane, porządkować wiedzę, eksplorować rozwiązania i przyspieszać prototypowanie.
AI is a tool for me, not the goal. I use it where it helps move faster from a problem to a design decision. It helps me analyze data, organize knowledge, explore solutions, and speed up prototyping.
Nie zastępuje doświadczenia projektowego. Pozwala lepiej je wykorzystać.
It does not replace design experience. It helps use it better.
Szybsza analiza informacji, synteza materiałów i eksploracja problemu.
Faster information analysis, material synthesis, and problem exploration.
Generowanie kierunków, wariantów i prototypów na wczesnym etapie.
Generating directions, variants, and prototypes at an early stage.
Budowa prostych komponentów, Proof of Concept i prototypów wysokiej wierności.
Building simple components, Proof of Concept work, and high-fidelity prototypes.
Analiza feedbacku, dokumentacji i procesów wspierających rozwój produktu.
Analysis of feedback, documentation, and processes that support product development.
Projektowanie to proces porządkowania złożoności — nie jej ukrywania.
Design is the process of organizing complexity — not hiding it.
Od systemów enterprise i aplikacji używanych przez miliony klientów, po budowę zespołu UX od podstaw. To tylko kilka ostatnich projektów w których brałem udział w ostatnich latach.
From enterprise systems and apps used by millions of customers to building a UX team from the ground up.
Zastąpienie zewnętrznego systemu za ~$2M rocznie systemem wewnętrznym. Wykrywanie duplikatów skrócone z 2–3 godzin dziennie do kilku minut, a pracę wcześniej wymagającą 20 osób obsługuje 6.
Replaced an external system costing ~$2M annually with an internal system. Duplicate detection shortened from 2–3 hours a day to a few minutes, while work that previously required 20 people is now handled by 6.
Zobacz case study View case study →Projekt i rozwój aplikacji Mój Carrefour oraz zintegrowanych z nią usług: PAYBACK, Scan&Go, Tank&Go. Produkt dla 1M+ MAU i 5M+ pobrań.
Design and development of the Mój Carrefour app and services integrated with it: PAYBACK, Scan&Go, and Tank&Go. Product with 1M+ MAU and 5M+ downloads.
Zobacz case study View case study →Redesign platformy łączącej cztery serwisy gradingowe. Największym wyzwaniem było zaprojektowanie wspólnego procesu zakupowego dla różnych kategorii, usług i modeli rozliczeń.
Redesigning a platform that brought four grading services together. The main challenge was creating a shared checkout experience for different categories, services, and pricing models.
Zobacz case study View case study →System do generowania i zarządzania kampaniami marketingowymi banku. Pozwolił ING obsłużyć tę samą skalę kampanii zespołem 3 osób zamiast 14 i wyeliminować potrzebę zlecania kreacji agencjom.
A system for generating and managing the bank's marketing campaigns. It enabled ING to manage the same campaign volume with a team of 3 instead of 14 and removed the need to outsource creative work to agencies.
Zobacz case study View case study →Od UX Designera do Head of UX. Dziewięć lat budowania i rozwijania zespołu.
From UX Designer to Head of UX. Nine years building and developing the team.
Zobacz case study View case study →Mam na koncie dużo więcej projektów — dla bankowości, fintechów, retailu i firm technologicznych. Pozostałe case studies pokażę na rozmowie lub na życzenie.
I have many more projects across banking, fintech, retail, and technology companies. I can show the remaining case studies during a conversation or on request.
Szukasz przykładu z konkretnej branży lub o określonym wyzwaniu?
Looking for an example from a specific industry or challenge?
Napisz do mnie Write to me →Zastąpienie zewnętrznego systemu kosztującego ~$2M rocznie rozwiązaniem wewnętrznym. Wykrywanie duplikatów skrócono z 2–3 godzin dziennie do kilku minut, a pracę wcześniej wymagającą 20 osób obsługuje obecnie 6.
Replaced an external system costing ~$2M annually with an internal solution. Duplicate detection was reduced from 2–3 hours a day to a few minutes, while work previously requiring 20 people is now handled by 6.
Beckett zarządza bazą ponad 60 milionów rekordów dotyczących kart i innych przedmiotów kolekcjonerskich. Dane były wykorzystywane między innymi w procesach gradingu, e-commerce i aukcji.
Firma korzystała z zewnętrznego systemu, którego licencje, wsparcie, infrastruktura i przechowywanie danych kosztowały łącznie około 2 mln USD rocznie.
20-osobowy zespół analityków codziennie pracował z tym systemem. Typowy dzień:
Łączny obraz: drogi system, bolesny dla użytkowników, blokujący jednego analityka na kilka godzin dziennie tylko na operacjach które powinny być natychmiastowe.
Ten projekt zaczął się od briefa typu "ogarnij to jakoś". Dostałem 4 godziny nagrań video (każde po godzinie) i miałem na ich podstawie zrozumieć jak działa cały produkt. Brief musiałem zbudować sam.
Zorganizowałem serię nagrywanych warsztatów z trzema głównymi analitykami — ludźmi którzy pracowali z systemem od kilku do kilkunastu lat. Moduł po module, ich frustracje, edge case'y, blockery, marzenia.
W międzyczasie musiałem już projektować pierwsze rozwiązanie. Research, projektowanie i development odbywały się równolegle, dlatego zakres porządkowaliśmy i wdrażaliśmy etapami.
Po warsztatach uderzyło mnie coś, co potem przewinęło się przez cały projekt:
Wystarczyło zrobić najprostsze rzeczy bez komplikacji żeby podnieść doświadczenie userów w ogromnym stopniu.
Ten projekt nie wymagał przełomowych innowacji. Kluczowe było trafne rozpoznanie najważniejszych problemów i konsekwentne wdrożenie prostych rozwiązań.
Drugą rzeczą, która mnie zaskoczyła, było to, że analitycy przez lata godzili się z ograniczeniami narzędzia, a firma ponosiła wysokie koszty utrzymania systemu, który blokował ich pracę. Pokazało to, jak długo kosztowne i nieefektywne rozwiązania mogą funkcjonować w dużej organizacji bez ponownej oceny.
Zwinność wymusiła dyscyplinę. Oddawaliśmy system w kawałkach, równolegle z developmentem i infrastrukturą.
Sposób komunikacji z klientem: najpierw hi-fi UI (praktycznie gotowy projekt), potem klikalne prototypy w Figmie. Przy tak złożonym systemie nie można było zaprezentować "wireframe'ów" i liczyć że stakeholderzy zrozumieją flow.
Każda istotna decyzja projektowa wymagała uzasadnienia. Większość funkcji projektowaliśmy od nowa, co oznaczało odejście od utrwalonych sposobów pracy. Użytkownicy i zarząd początkowo oczekiwali przede wszystkim szybszej wersji starego systemu, zachowującej dotychczasowy model działania.
Same argumenty nie wystarczały, aby zbudować zaufanie do nowego sposobu pracy. Najskuteczniejsze okazały się klikalne prototypy. Dopiero gdy użytkownicy mogli samodzielnie przejść przez czynności wykonywane wielokrotnie w ciągu dnia, przekonali się, że nowe rozwiązanie rzeczywiście upraszcza ich pracę.
Jednym z kluczowych usprawnień było automatyczne wykrywanie potencjalnych duplikatów w bazie ponad 60 milionów rekordów. Wspólnie z zespołem zmapowaliśmy kilkanaście najczęściej wykorzystywanych szablonów rekordów i przygotowaliśmy wzorcowe przykłady. Na ich podstawie algorytmy przeszukiwały bazę, porównywały atrybuty i wskazywały potencjalne duplikaty do weryfikacji. Proces, który wcześniej wymagał 2–3 godzin pracy analityka dziennie, został skrócony do kilku minut.
System obejmował również kreator zapytań z podpowiedziami, mechanizmy parsowania danych z serwisów aukcyjnych i automatycznego mapowania atrybutów do schematu Beckett oraz narzędzia do porównywania wersji.
Największy efekt nie zawsze wymaga złożonych rozwiązań. W tym przypadku kluczowe było rozpoznanie najważniejszych problemów użytkowników i konsekwentne uproszczenie procesów wykonywanych każdego dnia.
Klikalny prototyp nie był jedynie formą prezentacji. Stał się narzędziem podejmowania decyzji, ponieważ pozwolił użytkownikom i zarządowi ocenić nowy sposób pracy na konkretnych przykładach.
Jeżeli ten projekt Cię zainteresował, daj znać. Chętnie opowiem więcej o procesie, decyzjach projektowych i szczegółach rozwiązania.
Beckett manages a database of more than 60 million records covering cards and other collectibles. The data was used across grading, e-commerce and auction processes, among others.
The company relied on an external system whose licenses, support, infrastructure and data storage cost approximately USD 2 million annually.
A 20-person team of analysts worked with the system daily. A typical day:
Overall: expensive system, painful for users, blocking analysts for hours daily on operations that should be instant.
This project started with a brief like "figure it out somehow". I got 4 hours of video recordings (one hour each) and had to understand how the whole product works based on those. I had to build the brief myself.
I organized a series of recorded workshops with three main analysts — people who'd worked with the system for years. Module by module: their frustrations, edge cases, blockers, dreams.
Meanwhile, I had to start designing the first solution. Research, design and development ran in parallel, so we structured and implemented the scope in stages.
After the workshops, something hit me that ran through the whole project:
It turned out you just had to do the simplest things without complication to drastically improve user experience.
This project did not require breakthrough innovation. The key was identifying the most important problems and consistently implementing simple solutions.
The second thing that surprised me was that analysts had accepted the limitations of the tool for years while the company continued to bear the high cost of maintaining a system that obstructed their work. It showed how long costly and inefficient solutions can remain in place in a large organization without being reassessed.
Agility forced discipline. We delivered the system in pieces, in parallel with development and infrastructure.
Client communication: hi-fi UI first (practically final design), then clickable Figma prototypes. With this kind of system complexity, you couldn't show "wireframes" and hope stakeholders understood the flow.
Every significant design decision had to be justified. We redesigned most functions, which meant moving away from established ways of working. Users and management initially expected a faster version of the old system that preserved the existing operating model.
Arguments alone were not enough to build confidence in the new way of working. Clickable prototypes proved most effective. Once users could step through tasks they performed repeatedly throughout the day, they saw that the new solution genuinely simplified their work.
One of the key improvements was automated detection of potential duplicates across more than 60 million records. Together with the team, we mapped more than a dozen of the most frequently used record templates and prepared reference examples. Based on these patterns, the algorithms searched the database, compared attributes and flagged potential duplicates for review. A process that previously required 2–3 hours of analyst work each day was reduced to a few minutes.
The system also included a guided query builder, mechanisms for parsing auction-site data and automatically mapping attributes to the Beckett schema, and version comparison tools.
The greatest impact does not always require complex solutions. In this case, the key was identifying the most important user problems and consistently simplifying the processes they performed every day.
A clickable prototype was not merely a presentation format. It became a decision-making tool, allowing users and management to evaluate the new way of working through concrete examples.
If this project caught your interest, get in touch. I would be happy to share more about the process, design decisions and details of the solution.
Redesign platformy łączącej cztery serwisy gradingowe. Największym wyzwaniem było zaprojektowanie wspólnego procesu zakupowego dla różnych kategorii, usług i modeli rozliczeń.
Redesigning a platform that brought four grading services together. The main challenge was creating a shared checkout experience for different categories, services, and pricing models.
Beckett miał cztery serwisy gradingu, każdy dla innej kategorii: karty sportowe, manga, komiksy i przedmioty kolekcjonerskie. Wszystkie były sister brands przejęte wcześniej i przebrandowane pod Beckett, ale technicznie i UX-owo pozostały oddzielnymi światami.
Klient, który chciał zlecić grading w kilku kategoriach, musiał przejść przez kilka serwisów, kilka kont, kilka koszyków i kilka ścieżek wysyłki. Do tego dochodziła subskrypcja do bazy danych 60M+ rekordów, czyli zupełnie inny model biznesowy niż grading.
Cel: połączyć rozproszone serwisy i usługi Beckett w jedną platformę z jednym kontem, wspólnym koszykiem dla usług, które można było łączyć w jednym zamówieniu, i spójnym procesem zakupowym. Subskrypcja do bazy danych pozostawała osobną ścieżką zakupu, ale miała być wizualnie i funkcjonalnie spójna z resztą platformy.
Po projekcie PGS Beckett rozszerzył współpracę i włączył mnie do zespołu odpowiedzialnego za redesign platformy. Z czasem przejąłem prowadzenie trzyosobowego zespołu projektantów oraz odpowiedzialność za badania UX i analizę danych z Google Analytics.
Projekt realizował ponad dwudziestoosobowy zespół łączący kompetencje projektowe, produktowe, analityczne, technologiczne i domenowe. Koordynowałem decyzje projektowe między tymi obszarami i odpowiadałem za spójność doświadczenia na całej platformie.
W standardowym e-commerce można oprzeć się na sprawdzonych wzorcach. Tutaj nie było jednego modelu, który można było po prostu zastosować. Platforma łączyła różne usługi, kategorie przedmiotów, zasady wyceny, ubezpieczenia i modele oceny.
Nie mogliśmy powiedzieć: „Amazon, eBay czy Walmart rozwiązują to w taki sposób, więc to sprawdzony wzorzec”. Każdy element trzeba było projektować dla konkretnego kontekstu i grupy użytkowników, a następnie weryfikować w badaniach z grupą docelową.
Nie istniał gotowy model dla platformy łączącej różne usługi dla przedmiotów kolekcjonerskich z subskrypcją bazy danych. Koszyk musiał obsłużyć różne kategorie, stawki podatkowe, ubezpieczenia, czas realizacji usług i modele oceny przedmiotów.
Dlatego projekt wymagał projektowania od podstaw, a nie kopiowania rozwiązań z innych sklepów.
Sam proces zakupowy projektowaliśmy praktycznie od zera. Prace projektowe i badania nad nim trwały około 6 miesięcy.
Najtrudniejsze kompromisy nie były między designerem a klientem. Były między różnymi działami klienta, które musiały zmieścić swoje wymagania w jednym flow.
Zaprojektowanie całej nawigacji było jednym z najbardziej złożonych elementów projektu. Struktura musiała uwzględniać potrzeby różnych domen biznesowych, a jednocześnie pozostać zrozumiała dla użytkowników szukających konkretnej usługi. Subskrypcja do bazy danych była spójna wizualnie z platformą, ale zachowywała odrębną ścieżkę zakupu.
Warianty struktury weryfikowaliśmy z użytkownikami w tree testingu i zadaniach wykonywanych na czas. Badania pozwalały sprawdzić, czy w tak złożonej strukturze potrafią odnaleźć najważniejsze informacje i właściwe ścieżki zakupu.
Phase 1, czyli karty i manga, została wdrożona w produkcji. Po pierwszym kwartale klient zaraportował:
Phase 2, czyli komiksy i przedmioty kolekcjonerskie, pozostaje osobnym etapem wdrożenia.
Gotowe wzorce nie zastępują rozumienia domeny. W tym projekcie każda kluczowa ścieżka wymagała zaprojektowania pod konkretne usługi i zweryfikowania z użytkownikami.
Najtrudniejsze kompromisy powstawały między obszarami biznesowymi. Jedna ścieżka musiała pogodzić różne procesy, wymagania i sposoby pracy.
Badania i dane pozwalały podejmować bardziej konkretne decyzje. Tree testing, zadania wykonywane na czas i analiza zachowań użytkowników pomagały oceniać rozwiązania na podstawie tego, jak użytkownicy faktycznie poruszali się po produkcie, a nie intuicji.
Jeżeli ten projekt Cię zainteresował, daj znać. Chętnie opowiem więcej o procesie, decyzjach projektowych i szczegółach rozwiązania.
Beckett had four grading sites, each serving a different category: sports cards, manga, comics, and collectibles. They were sister brands acquired earlier and rebranded under Beckett, but technically and UX-wise they remained separate worlds.
A customer who wanted to grade across categories had to go through multiple sites, accounts, carts, and shipping flows. On top of that, Beckett also sold a 60M+ record database subscription - a completely different business model from grading.
Goal: bring Beckett's fragmented sites and services into one platform with a single account, a shared cart for services that could be combined in a single order, and a consistent purchase experience. The database subscription remained a separate purchase flow, but needed to feel visually and functionally integrated with the rest of the platform.
After the PGS project, Beckett expanded the collaboration and brought me into the team responsible for redesigning the platform. Over time, I took responsibility for leading the three-person design team, UX research, and analysis of data from Google Analytics.
The project was delivered by a cross-functional team of more than 20 people spanning design, product, analytics, engineering, and domain expertise. I coordinated design decisions across these areas and was responsible for maintaining a consistent experience throughout the platform.
Standard ecommerce projects can rely on established patterns. Here, there was no single model we could apply directly. The platform combined different services, collectible categories, pricing rules, insurance, and assessment models.
We could not say, “Amazon, eBay, or Walmart solve it this way, so it is a proven pattern.” Every element had to be designed for a specific context and user group, then validated through research with the target audience.
There was no established model for a platform combining multiple collectible services with a database subscription. The cart had to handle different categories, tax rules, insurance, service turnaround times, and item assessment models.
The project therefore required designing from first principles rather than copying solutions from other stores.
We designed the checkout almost from scratch. Design work and research for the purchase flow took about 6 months.
The hardest compromises were not between design and the client. They were between different departments inside the client organization that all had to fit their requirements into one flow.
Designing the full navigation was one of the most complex parts of the project. The structure had to meet the needs of several business domains while remaining understandable to users looking for a specific service. The database subscription was visually integrated with the platform, but retained its own purchase path.
We validated navigation variants with users through tree testing and timed tasks. The research helped assess whether people could find key information and the right purchase paths within such a complex structure.
Phase 1, covering cards and manga, launched in production. After the first quarter, the client reported:
Phase 2, covering comics and collectibles, remained a separate rollout stage.
Established patterns do not replace domain understanding. In this project, every key journey had to be designed around specific services and validated with users.
The hardest trade-offs happened between business domains. A single journey had to reconcile different processes, requirements, and ways of working.
Research and data made decisions more concrete. Tree testing, timed tasks, and behavioral data helped evaluate solutions based on how users actually navigated the product rather than intuition.
If this project caught your interest, get in touch. I would be happy to share more about the process, design decisions and details of the solution.
System do generowania i zarządzania kampaniami marketingowymi banku. Pozwolił ING obsłużyć tę samą skalę kampanii zespołem 3 osób zamiast 14 i wyeliminować potrzebę zlecania kreacji agencjom.
A system for generating and managing the bank's marketing campaigns. It enabled ING to manage the same campaign volume with a team of 3 instead of 14 and removed the need to outsource creative work to agencies.
ING prowadził dużą liczbę kampanii marketingowych w wielu kanałach. Proces opierał się na pracy 14-osobowego zespołu marketerów oraz stałej współpracy z agencją, która przygotowywała kreacje dla serwisu www, aplikacji mobilnej, ekranów w oddziałach, social mediów, mailingu i materiałów drukowanych.
Wraz ze wzrostem skali coraz większym wyzwaniem stawał się sam model produkcji kampanii. Każda kampania wymagała wielu przekazań, briefów i iteracji, a utrzymanie spójności komunikacji między kanałami wymagało coraz więcej koordynacji.
Celem projektu było przeniesienie produkcji kampanii bliżej zespołu ING: tak, aby marketerzy mogli samodzielnie tworzyć i aktualizować materiały w ustalonych ramach, bez angażowania agencji przy każdej zmianie i bez utraty spójności marki.
Brief był prosty: zaprojektować wewnętrzne narzędzie, które pozwoli bankowi produkować kampanie samodzielnie, w pełnej spójności wizualnej i tekstowej.
Pogłębiłem go na serii warsztatów z docelowymi użytkownikami - marketerami ING. Chodziło o zrozumienie ich realnego workflow, frustracji, rzeczy typu "musi być" i edge case'ów.
Kluczowy insight: marketerzy byli średnio zaawansowani technologicznie. Narzędzie nie mogło być Figmą. Musiało być proste dla osoby bez kompetencji designerskich, ale ograniczone tak, żeby nie dało się złamać zasad marki.
System składał się z pięciu głównych modułów:
Typowy flow: marketer wprowadza treść, wgrywa key visual, wybiera nośniki i generuje komplet formatów kampanii.
Proces przygotowania kampanii, który wcześniej trwał kilka tygodni i wymagał zaangażowania agencji, został skrócony do około pół dnia pracy po stronie zespołu ING.
System miał ograniczać zakres decyzji dostępnych marketerom, aby zachować spójność marki i kampanii, a jednocześnie pozostać na tyle prosty, by nie tworzyć wysokiej bariery wejścia.
Każdą decyzję projektową ocenialiśmy pod kątem równowagi między swobodą marketera a spójnością marki. Ostatecznie marketer wybierał szablon i wprowadzał treść, a system automatycznie kontrolował pozostałe elementy: kolory, typografię, hierarchię, marginesy, kompozycję i responsywność.
Jako Product Designer odpowiadałem za proces projektowy: prowadziłem warsztaty z marketerami, opracowywałem architekturę informacji oraz projektowałem ekrany i ścieżki użytkowników. Definiowałem również strukturę szablonów i zasady ich edycji, przygotowywałem dokumentację dla zespołu deweloperskiego oraz wspierałem wdrożenie.
Dobry interfejs ogranicza liczbę decyzji do tych, które są rzeczywiście potrzebne. Marketerzy ING nie potrzebowali pełnej swobody projektowej, lecz narzędzia, które pozwalało szybko przygotować spójne materiały przy mniejszym ryzyku błędu.
Największą wartość tworzy rozwiązanie dopasowane do sposobu działania organizacji. W tym przypadku oznaczało to umożliwienie zespołowi ING samodzielnego przygotowywania standardowych kampanii i ograniczenie udziału agencji w codziennej produkcji materiałów.
Jeżeli ten projekt Cię zainteresował, daj znać. Chętnie opowiem więcej o procesie, decyzjach projektowych i szczegółach rozwiązania.
ING ran a large volume of marketing campaigns across many channels. The process relied on a 14-person marketing team and ongoing cooperation with an agency that prepared creative assets for the website, mobile app, branch screens, social media, email, and print materials.
As the scale grew, the campaign production model itself became the larger challenge. Each campaign required many handoffs, briefs, and iterations, while maintaining consistent communication across channels required more and more coordination.
The goal was to move campaign production closer to the ING team, so marketers could create and update materials independently within defined rules, without involving the agency in every change and without losing brand consistency.
The brief was simple: design an internal tool that would let the bank produce campaigns independently, with full visual and copy consistency.
I deepened it through workshops with the target users - ING marketers. The goal was to understand their real workflow, frustrations, must-haves, and edge cases.
The key insight: marketers were moderately technical. The tool could not be Figma. It had to be simple enough for a non-designer, but constrained enough to prevent breaking brand rules.
The system had five main modules:
Typical flow: the marketer enters content, uploads a key visual, chooses formats, and generates the required campaign outputs.
The campaign preparation process, which previously took several weeks and required agency involvement, was reduced to about half a day of work within the ING team.
The system had to limit the range of decisions available to marketers to maintain brand and campaign consistency, while remaining simple enough to keep the learning curve low.
We evaluated each design decision by balancing marketer flexibility with brand consistency. In the final model, the marketer selected a template and entered the content, while the system automatically controlled the remaining elements: colors, typography, hierarchy, margins, composition, and responsiveness.
As Product Designer, I was responsible for the design process: I facilitated workshops with marketers, developed the information architecture, and designed screens and user journeys. I also defined the template structure and editing rules, prepared documentation for the development team, and supported implementation.
A good interface limits decisions to those that are genuinely necessary. ING marketers did not need complete design freedom. They needed a tool that enabled them to prepare consistent materials quickly and with less risk of error.
The greatest value comes from a solution aligned with how the organization operates. In this case, that meant enabling the ING team to prepare standard campaigns independently and reducing the agency's involvement in day-to-day content production.
If this project caught your interest, get in touch. I would be happy to share more about the process, design decisions and details of the solution.
Projekt i rozwój aplikacji Mój Carrefour oraz zintegrowanych usług PAYBACK, Scan&Go i Tank&Go. Ponad 1 mln aktywnych użytkowników miesięcznie i 5 mln pobrań.
Design and development of the Mój Carrefour app and integrated PAYBACK, Scan&Go and Tank&Go services. More than 1 million monthly active users and 5 million downloads.
W 2019 roku Carrefour Polska rozwijał istniejącą aplikację mobilną, która wymagała gruntownego redesignu wizualnego i funkcjonalnego. Celem było uporządkowanie kluczowych funkcji, zwiększenie konkurencyjności produktu i wzmocnienie aplikacji jako ważnego kanału kontaktu z klientami.
Brief był szeroki: przebudowa praktycznie każdej sekcji aplikacji, od kuponów, ofert i list zakupów, po profil, lokalizacje sklepów, Scan&Go i architekturę informacji.
Przez pierwsze sześć miesięcy odpowiadałem po stronie agencji zarówno za projektowanie produktu, jak i zarządzanie projektem. Prowadziłem badania, architekturę informacji, UX/UI, dokumentację wdrożeniową oraz komunikację z klientem.
Aplikację rozwijały dwa dedykowane zespoły developerskie — osobny dla iOS i osobny dla Androida. Współpracowałem bezpośrednio z każdym z nich, dbając o spójność funkcji i doświadczenia między platformami oraz uwzględnienie potrzeb różnych obszarów biznesowych Carrefour.
Ten etap pozwolił mi dobrze poznać produkt, organizację klienta i zależności techniczne. Wiedza ta była później podstawą do skalowania projektu i budowy zespołu.
Z czasem zakres projektu wymagał zaangażowania kolejnych osób. Przy Carrefour pracował pięcioosobowy zespół UX/UI, który prowadziłem równolegle z innymi projektami agencyjnymi.
Główną metodą były testy użyteczności, uzupełniane badaniami eye-trackingowymi i wywiadami pogłębionymi. Wnioski wykorzystywaliśmy do weryfikacji architektury informacji, kluczowych ścieżek i nowych funkcji przed wdrożeniem oraz w kolejnych etapach rozwoju aplikacji.
Dwa niezależne zespoły developerskie. iOS i Android były oddzielnymi implementacjami. Trzeba było utrzymać spójność marki, ale szanować natywne konwencje każdej platformy.
Skala konsekwencji. Aplikacja z 1M+ MAU oznacza, że zła decyzja w głównym flow generuje natychmiastowy feedback od tysięcy ludzi. Tu nie dało się projektować na zasadzie "zobaczymy".
Carrefour jako organizacja. Pełna obsługa marki oznaczała ciągłe negocjacje z różnymi działami biznesu, każdy z własnymi KPI i tempem pracy.
Pozytywne wyniki testów użyteczności oraz ocena współpracy przy aplikacji doprowadziły do rozszerzenia mojego zaangażowania na kolejne kanały Carrefour: serwis e-commerce do zakupów codziennych, marketplace, stronę korporacyjną oraz interfejsy dla ekranów w sklepach. Serwis zakupowy i marketplace zostały później połączone w jedną platformę. Łącznie współpraca z marką trwała od 2017 do 2024 roku.
Prowadziłem projekt po stronie agencji, łącząc rolę projektanta z zarządzaniem projektem. Odpowiadałem za badania, architekturę informacji, UX/UI, dokumentację, wsparcie wdrożenia oraz koordynację współpracy z klientem i dwoma dedykowanymi zespołami developerskimi: iOS i Android.
Wraz ze wzrostem zakresu przejąłem odpowiedzialność za pięcioosobowy zespół UX/UI. Odpowiadałem za podział pracy, jakość projektową, kluczowe decyzje produktowe, relacje z biznesem oraz rozwój zespołu.
Zakres projektu stopniowo zmienił moją rolę. Z samodzielnego projektowania przeszedłem do prowadzenia zespołu i odpowiedzialności za jakość całego procesu.
Skala produktu wymagała większej dyscypliny projektowej. Każda zmiana musiała być zweryfikowana, spójnie udokumentowana i skoordynowana między zespołami iOS i Android.
Ciągłość wiedzy miała bezpośrednią wartość dla projektu. Znajomość produktu i organizacji pozwalała szybciej oceniać konsekwencje decyzji oraz sprawniej rozwijać kolejne obszary.
Jeżeli ten projekt Cię zainteresował, daj znać. Chętnie opowiem więcej o procesie, decyzjach projektowych i szczegółach rozwiązania.
In 2019, Carrefour Poland was developing an existing mobile app that needed a comprehensive visual and functional redesign. The goal was to streamline its key features, strengthen its competitive position, and establish the app as an important customer channel.
The brief was broad: rebuild almost every section of the app, from coupons, offers, shopping lists, profile, store locations, and Scan&Go to the entire information architecture.
For the first six months, I was responsible on the agency side for both product design and project management. I led research, information architecture, UX/UI, implementation documentation, and client communication.
The app was developed by two dedicated development teams — one for iOS and one for Android. I worked directly with both, ensuring functional and experience consistency across platforms while accounting for the needs of different Carrefour business areas.
This stage gave me a deep understanding of the product, the client organization, and the technical dependencies. That knowledge later became the foundation for scaling the project and building the team.
As the scope grew, additional people joined the work. I led a five-person UX/UI team whose members worked on Carrefour while also supporting other agency projects.
Usability testing was the primary research method, supported by eye-tracking studies and in-depth interviews. We used the findings to validate the information architecture, key user journeys and new features before implementation and throughout subsequent stages of app development.
Two separate development teams. iOS and Android were separate implementations. We had to maintain brand consistency while respecting native conventions on both platforms.
Scale of consequences. An app with 1M+ MAU means a wrong decision in a main flow creates immediate feedback from thousands of people. This was not a "let's try and see" environment.
Carrefour as an organization. Full brand support meant constant negotiation with different business units, each with its own KPIs and pace.
Positive usability test results and feedback on the app project led to my involvement across additional Carrefour channels: the grocery e-commerce service, marketplace, corporate website, and interfaces for in-store screens. The e-commerce service and marketplace were later consolidated into a single platform. Overall, my collaboration with the Carrefour brand lasted from 2017 to 2024.
I led the project on the agency side, combining product design and project management. I was responsible for research, information architecture, UX/UI, documentation, implementation support, and coordination with the client and two dedicated development teams: iOS and Android.
As the scope grew, I took responsibility for a five-person UX/UI team. I managed workload, design quality, key product decisions, business relationships, and team development.
The scope of the project gradually changed my role. I moved from independent design work to leading a team and taking responsibility for the quality of the whole process.
The scale of the product required greater design discipline. Every change had to be validated, documented consistently, and coordinated closely across iOS and Android.
Continuity of knowledge created direct value for the project. Understanding the product and organization made it possible to assess the consequences of decisions faster and develop new areas more efficiently.
If this project caught your interest, get in touch. I would be happy to share more about the process, design decisions and details of the solution.
W 2015 roku dołączyłem do GoldenSubmarine jako UX Designer. W kolejnych latach współtworzyłem i rozwijałem interdyscyplinarny zespół UX/UI, który z czasem zaczął działać jako GoldenGrid. Przez pięć lat pełniłem rolę Head of UX.
I joined GoldenSubmarine in 2015 as a UX Designer. Over the following years, I helped build and develop an interdisciplinary UX/UI team that eventually became GoldenGrid. I spent five years in the Head of UX role.
Do GoldenSubmarine dołączyłem w 2015 roku jako UX Designer. Projektowałem, prowadziłem warsztaty i badania, analizowałem dane oraz uczestniczyłem w ofertowaniu. Nie istniał wtedy osobny dział UX/UI ani GoldenGrid w późniejszej formie.
Wraz ze wzrostem liczby i skali projektów wokół tego obszaru zaczął powstawać zespół. Rozwijaliśmy go stopniowo, odpowiadając na realne potrzeby projektów, klientów i agencji. Z czasem ta praktyka zaczęła działać jako GoldenGrid.
Każda kolejna rekrutacja wynikała z konkretnej potrzeby. Czasem brakowało specjalizacji, czasem osoby gotowej samodzielnie przejąć projekt, a czasem większej przewidywalności przy rosnącej liczbie realizacji.
Pierwszą osobą, którą włączyłem do zespołu, był stażysta bez doświadczenia projektowego. Nie miał rozbudowanego portfolio, ale dobrze analizował problemy, zadawał trafne pytania i szybko wykorzystywał feedback. Z czasem stał się samodzielnym projektantem.
To doświadczenie zostało ze mną podczas kolejnych rekrutacji. Portfolio traktowałem jako punkt wyjścia. Równie ważne było dla mnie to, jak ktoś dochodzi do decyzji, reaguje na brak pewności i potrafi zmienić zdanie pod wpływem nowych informacji.
Potencjał nie zawsze jest widoczny w CV.
W najbardziej rozbudowanym okresie interdyscyplinarny zespół GoldenGrid liczył około 14 osób: UX i UI Designerów, UX Writera, specjalistę dostępności, analityków danych oraz Project Managerów. W zależności od potrzeb projektu współpracowaliśmy dodatkowo ze specjalistami GoldenSubmarine, zespołami po stronie klienta oraz freelancerami — między innymi developerami, motion designerami i art directorami.
Skład nie był stały. Zmieniał się razem z portfolio projektów i sytuacją biznesową agencji. Utrzymanie zespołu nie polegało więc wyłącznie na zatrudnianiu — równie ważne były odpowiednie projekty, rozsądne planowanie dostępności i dopasowanie kompetencji do pracy, która rzeczywiście trafiała do organizacji.
Przez długi czas próbowałem jednocześnie projektować, prowadzić zespół, uczestniczyć w ofertowaniu i pozostawać blisko wszystkich ważnych decyzji. Przy niewielkiej skali było to możliwe. Przy kilkunastu osobach zaczęło ograniczać zarówno mnie, jak i samodzielność zespołu.
Musiałem zaakceptować, że moją pracą nie jest już podejmowanie każdej decyzji projektowej. Ważniejsze stało się ustalenie odpowiedzialności, dbanie o jakość i włączanie się wtedy, gdy projekt wymagał szerszej perspektywy, trudnej rozmowy z klientem albo zmiany kierunku.
Przez około pół roku niemal całkowicie odszedłem od bezpośredniego projektowania. Skupiłem się na ludziach, planowaniu pracy, ofertowaniu i współpracy z klientami. Później zakres tej roli zmieniał się razem z sytuacją firmy — w okresach większego obciążenia wracałem również do pracy projektowej.
Jako Head of UX odpowiadałem nie tylko za ludzi i design review. Pracowałem przy estymacjach, ofertach i przetargach, rozmawiałem z klientami o zakresie oraz ryzykach, a także włączałem się w projekty, które przestawały przebiegać zgodnie z planem.
Z czasem coraz wyraźniej widziałem, że jakość projektu zależy również od decyzji podjętych przed rozpoczęciem projektowania: sposobu sprzedaży, realności zakresu, składu zespołu i tego, czy klient oraz wykonawcy podobnie rozumieją cel pracy.
GoldenGrid rozwinął się z niewielkiego obszaru UX w interdyscyplinarny zespół zdolny prowadzić równolegle złożone projekty dla dużych organizacji. W ciągu kilku lat zrealizowaliśmy ponad 30 projektów obejmujących badania, analitykę, strategię, UX, UI oraz współpracę przy wdrożeniu.
Zespół nie był jedynie wewnętrznym wsparciem projektowym. Braliśmy udział w ofertowaniu, rozmowach z klientami i definiowaniu zakresu pracy, a następnie odpowiadaliśmy za prowadzenie projektów od rozpoznania problemu po przygotowanie rozwiązania do wdrożenia.
Za długo próbowałem łączyć rolę projektanta z odpowiedzialnością za cały obszar UX/UI. Dawało mi to poczucie kontroli nad jakością, ale ograniczało czas, który powinienem przeznaczyć na ofertowanie, rozwijanie relacji z klientami i zapewnienie zespołowi ciągłości projektów.
Dziś wcześniej oddzieliłbym odpowiedzialność za jakość od osobistego udziału w każdym projekcie. Dobry zespół nie powinien potrzebować lidera przy każdej decyzji. Powinien natomiast wiedzieć, kto za nią odpowiada, jaki jest kontekst i kiedy warto poprosić o wsparcie.
Po kilku latach zarządzania świadomie wróciłem bliżej projektowania produktów. Nie był to jednak powrót do wcześniejszego sposobu pracy.
Doświadczenie Head of UX zmieniło perspektywę, z której patrzę na produkt. Interfejs jest tylko jednym z elementów większego układu. Równie ważne są możliwości zespołu, interesy stakeholderów, sposób wdrożenia, zakres odpowiedzialności i konsekwencje biznesowe podejmowanych decyzji.
Dzięki temu potrafię pracować bezpośrednio nad produktem, a jednocześnie dostrzegać problemy, które nie mieszczą się na ekranie.
Chętnie opowiem więcej o budowie zespołu, sposobie organizacji pracy oraz projektach, które realizowaliśmy w GoldenGrid.
I joined GoldenSubmarine in 2015 as a UX Designer. I designed products, facilitated workshops and research, analyzed data and contributed to proposals. At that point, there was no separate UX/UI department and no GoldenGrid in its later form.
As the number and scale of projects grew, a team began to form around the practice. We developed it gradually in response to the real needs of projects, clients and the agency. Over time, the practice became GoldenGrid.
The first person I brought into the team was an intern with no previous design experience.
I decided to work with him because of the way he thought, his curiosity and his ability to learn quickly. Over time, through mentoring and work on subsequent projects, he developed into an independent designer.
This experience shaped my later approach to recruitment. I treated a portfolio as a starting point. How someone reached decisions, handled uncertainty and changed their view when presented with new information mattered just as much.
Potential is not always visible in a CV.
At its largest, the interdisciplinary GoldenGrid team consisted of around 14 people: UX and UI Designers, a UX Writer, an accessibility specialist, data analysts and Project Managers. Depending on the needs of each project, we also collaborated with GoldenSubmarine specialists, client-side teams and freelancers, including developers, motion designers and art directors.
The structure was not fixed. It changed with the project portfolio and the agency's business situation. Keeping the team healthy was therefore not only about hiring. It also required the right projects, realistic capacity planning and matching skills to the work actually entering the organization.
For a long time, I tried to design, lead the team, contribute to proposals and stay close to every important decision. This worked at a smaller scale. With a team of more than a dozen people, it began to limit both me and the team's independence.
I had to accept that my job was no longer to make every design decision. It became more important to establish ownership, protect quality and step in when a project needed a broader perspective, a difficult client conversation or a change of direction.
For around six months, I moved almost entirely away from hands-on design and focused on people, capacity, proposals and client collaboration. Later, the balance changed with the needs of the business, and during busier periods I returned to project work.
As Head of UX, my work extended beyond people management and design reviews. I contributed to estimates, proposals and tenders, discussed scope and risk with clients, and stepped into projects that were no longer going according to plan.
Over time, I saw more clearly that project quality also depends on decisions made before design begins: how the work is sold, whether the scope is realistic, how the team is composed and whether the client and delivery team share the same understanding of the goal.
GoldenGrid developed from a small UX practice into an interdisciplinary team capable of running complex projects for large organizations in parallel. Over several years, we delivered more than 30 projects spanning research, analytics, strategy, UX, UI and collaboration through implementation.
The team was not simply an internal design resource. We contributed to proposals, client conversations and scope definition, then took responsibility for guiding projects from understanding the problem to preparing the solution for implementation.
I tried for too long to combine hands-on design with responsibility for the entire UX/UI practice. It gave me a sense of control over quality, but left too little time for proposals, client relationships and ensuring a steady flow of projects for the team.
Today, I would separate responsibility for quality from personal involvement in every project much earlier. A strong team should not need its leader for every decision. It should know who owns the decision, understand the context and recognize when support is genuinely needed.
After several years in management, I consciously moved closer to product design again. It was not a return to my earlier way of working.
The Head of UX experience changed the perspective from which I view a product. The interface is only one part of a larger system. Team capabilities, stakeholder interests, implementation, ownership and the business consequences of design decisions matter just as much.
This allows me to work directly on a product while also noticing the problems that do not fit on a screen.
I would be happy to share more about building the team, organizing its work and the projects we delivered at GoldenGrid.