Powrót do bloga

Od kiosku Windows do rozwiązania tabletowego: wnioski z prototypu systemu AI

Case study projektu dla ochrony zdrowia: jak prototyp kiosku Windows ujawnił ograniczenia hardware’u i doprowadził do zmiany architektury na rozwiązanie tabletowe.

Cover image for: Od kiosku Windows do rozwiązania tabletowego: wnioski z prototypu systemu AI
Zdjęcie: Sławomir Kocur. Wykonane 9 października 2025 podczas konferencji w Ptak Warsaw Expo.
Case studyAIAutomatyzacjaOchrona zdrowiaArchitektura systemówUX

Od kiosku Windows do rozwiązania tabletowego

Czego nauczył nas prototyp systemu AI dla ochrony zdrowia

W projektach IT – szczególnie na styku software’u, hardware’u i użytkownika końcowego – pierwsza koncepcja rzadko bywa tą docelową. Jednym z takich projektów był system informacyjny dla pacjentów po wypisie ze szpitala, który początkowo zaprojektowaliśmy jako stacjonarny kiosk, a finalnie przekształciliśmy w znacznie prostsze rozwiązanie tabletowe.

Ten artykuł nie jest historią „nieudanego wdrożenia”. To opis walidacji koncepcji w realnych warunkach, wyciągniętych wniosków i świadomej decyzji architektonicznej, która pozwoliła ograniczyć ryzyko i koszty projektu.


Cel projektu

Celem systemu było zapewnienie pacjentom:

  • szybkiego dostępu do informacji po wypisie ze szpitala,
  • prostego interfejsu, niewymagającego wsparcia personelu,
  • spójnych i aktualnych treści informacyjnych,
  • możliwości dalszej rozbudowy o automatyzacje i elementy AI.

Kluczowym założeniem od początku była maksymalna prostota obsługi – zarówno dla użytkowników końcowych, jak i dla organizacji utrzymującej system.


Pierwsza koncepcja: kiosk stacjonarny

Początkowa architektura zakładała:

  • stacjonarny kiosk oparty o system Windows,
  • komputer PC zamknięty w obudowie,
  • drukarkę do wydruku informacji,
  • tryb kiosku ograniczający dostęp do systemu.

Rozwiązanie zostało przygotowane w formie prototypu i zaprezentowane publicznie podczas konferencji branżowej, co pozwoliło sprawdzić je w warunkach zbliżonych do docelowych.


Problemy, które wyszły w praktyce

Testy i prezentacja szybko pokazały, że hardware staje się największym źródłem ryzyka całego systemu.

Najważniejsze obserwacje:

  • awaryjność i nieprzewidywalność elementów sprzętowych,
  • problemy z drukarką (papier, sterowniki, konserwacja),
  • długi czas uruchamiania systemu,
  • złożoność serwisowania i aktualizacji,
  • wysoki koszt utrzymania w relacji do realnej wartości dla użytkownika.

Z perspektywy UX i operacyjnej okazało się, że ciężka konstrukcja kioskowa generuje więcej problemów niż korzyści.


Decyzja: zmiana kierunku

Na podstawie tych doświadczeń podjęliśmy decyzję o odejściu od kiosku stacjonarnego na rzecz rozwiązania tabletowego.

Nie była to decyzja technologiczna, a biznesowo-operacyjna.

Tablet:

  • eliminuje większość problemów sprzętowych,
  • nie wymaga skomplikowanego serwisu,
  • uruchamia się natychmiast,
  • jest tańszy w utrzymaniu,
  • oferuje lepszą ergonomię dla użytkownika.

Co ważne – cała logika systemu, backend i koncepcja funkcjonalna pozostały aktualne. Zmieniliśmy jedynie warstwę sprzętową i sposób dostępu.


Nowa architektura (high level)

Docelowe podejście opiera się na:

  • tablecie (iOS / Android),
  • aplikacji webowej lub PWA,
  • centralnym backendzie i API,
  • automatyzacjach po stronie serwera,
  • możliwościach dalszej integracji elementów AI.

Takie rozwiązanie jest:

  • prostsze,
  • bardziej skalowalne,
  • tańsze w utrzymaniu,
  • łatwiejsze do wdrożenia w wielu lokalizacjach.

Najważniejsze wnioski

Ten projekt potwierdził kilka uniwersalnych zasad:

  • hardware bardzo często jest najsłabszym ogniwem systemu IT,
  • im prostsze urządzenie końcowe, tym większa adopcja,
  • kiosk ≠ tablet, nawet jeśli funkcjonalnie wydają się podobne,
  • AI i automatyzacje mają sens tylko wtedy, gdy UX działa bez tarcia,
  • szybka walidacja w realnych warunkach oszczędza czas i budżet.

Podsumowanie

Publiczna prezentacja prototypu pozwoliła nam szybko zweryfikować założenia i uniknąć kosztownego błędu na etapie pełnego wdrożenia. Zamiast brnąć w rozwiązanie, które „dobrze wyglądało na papierze”, zdecydowaliśmy się na zmianę kierunku opartą o realne obserwacje.

To podejście – iteracyjne, oparte na faktach, a nie przywiązaniu do technologii – staramy się stosować w każdym projekcie.

Jeśli rozważasz systemy łączące software, automatyzacje lub AI z urządzeniami końcowymi i chcesz uniknąć podobnych pułapek, porozmawiajmy.


Dowiedz się więcej o naszym podejściu do wytwarzania oprogramowania i architektury lub poznaj wszystkie realizacje.