O tym, że “jeden obraz wyraża więcej niż tysiąc słów” wiedzą już dzieci w wieku szkolnym lub nawet przedszkolnym. Czego dzieci - oraz niektórzy menedżerowie - mogą już nie wiedzieć to to, że nie zawsze będą to słowa właściwe. I nie chodzi tu bynajmniej o kolokwializmy, tylko o fakt, że obraz zbyt szczegółowy będzie po prostu podszyty kłamstwem.

Przykładowo, jeśli na pytanie “która godzina?” odpowiemy: “jest dziewiąta trzydzieści cztery, czterdzieści pięć sekund i osiemset sześćdziesiąt trzy setne”… wprowadzamy naszego rozmówcę w błąd, gdyż tak dokładny odczyt godziny zmieniłby się zanim jeszcze otworzylibyśmy usta.

Analogicznie, bardzo szczegółowe makiety systemów (nazywane również prototypami “hifi”, od angielskiego “high fidelity prototype”) często wprowadzają ich odbiorcę (inżyniera, programistę, interesariusza biznesowego) w błąd, podając bardzo dużo szczegółowych informacji, które niekoniecznie są prawdziwe. Wynika to głównie z faktu, że dostępne dzisiaj narzędzia takie jak Figma umożliwiają błyskawiczne prototypowanie w oparciu o biblioteki gotowych komponentów (np. firmowy Design System - dobry przykład takowego), a powstałe w ten sposób makiety - często w pośpiechu i na “na roboczo” - sprawiają wrażenie dopiętych na ostatni guzik.

Taki stan rzeczy mogą wykorzystywać dostawcy oprogramowania i firmy konsultingowe. Sam byłem świadkiem sytuacji, gdy aby spacyfikować wątpliwości (zasadne) klienta dot. funkcjonalności systemu dostawca oprogramowania rzucił “na stół” serię pięknych makiet, pokazujących arkana nieistniejącego jeszcze rozwiązania. Miało to być jasnym sygnałem dla inwestora, że już wszystko jest jasne, nie ma co zadawać zbędnych pytań i czas już na dopinanie „dealu”. Całe szczęście, do podpisania kontraktu w tym wypadku nie doszło.

W jaki sposób radzić sobie z tym problemem? W swoim wpisie autor bloga słusznie zauważa, że narzędzia typu CASE np. Visual Paradigm, czy Enterprise Architect umożliwiają tworzenie makiet poglądowych (lofi od angielskiego low fidelity), które stają się integralną częścią modelu projektowanego systemu, co usprawnia wiele aspektów np. śledzenie wymagań lub generowanie spójnej dokumentacji.

Co jeśli nie ma możliwości zastosowania narzędzi typu CASE bo np. prace UX outsourcujemy, bo nie mamy takich rozwiązań w firmie lub z innych względów nie chcemy nawracać zagorzałych "Figmowców" na inne narzędzia?

Wyjściem z tej sytuacji wydaje się wprowadzenie pewnego uproszczonego języka - np. opracowanie zbioru prymitywów UI oraz złożonych z nich komponentów (lub atomów, molekuł i organizmów - stosując nomenklaturę Atomic Design), a następnie przygotowanie dla nich zbioru uproszczonych reprezentacji graficznych, maksymalnie przy tym redukując niefunkcjonalne aspekty ich wyglądu, takie jak kolory, czcionki, wypełnienia i cienie.

Można skorzystać przy tym z masy gotowych rozwiązań (np. to lub to) lub włączyć taki element do zakresu inicjatywy opracowania firmowego Design Systemu.

Roboczy status makiet przygotowanych przy pomocy takiego uproszczonego „języka” będzie klarowny, a jego odbiorcy będą skupiać swoją uwagę na tym, co istotne. Może nawet okazać się, że w większości wypadków przygotowanie makiet hifi okaże się już zbędne.