Design w cyberbezpieczeństwie – od chaosu 70 produktów do jednolitej platformy #EN268

TL;DR

Design w cyberbezpieczeństwie istnieje od lat 90., jednak dopiero cloud i SaaS wymusiły znaczące inwestycje w UX
Przedsiębiorstwa używają 50-70 różnych produktów bezpieczeństwa, co tworzy ogromne obciążenie kognitywne
Cisco rozwiązuje problem fragmentacji przez etapową integrację – od standalone do micro front-end w jednej platformie
Program GOAT (Give Outcomes a Try) skupia zespoły na wynikach zamiast funkcji już na etapie planowania
Triada PM-Design-Engineering pracuje jako jeden organizm, gdzie decyzje uwzględniają ograniczenia wszystkich dziedzin
AI ewoluuje od chatbotów do generative UI z interaktywnymi elementami
Przyszłość może wyeliminować tradycyjną nawigację na rzecz predykcyjnych interfejsów

Poniższe notatki powstały na podstawie rozmowy z Jasonem Cyrem, VP i Head of Product Design w Cisco Security, przeprowadzonej w ramach Innovation Engine Podcast. Wszystkie przedstawione przemyślenia, obserwacje i przykłady pochodzą od rozmówców podcastu.

Ewolucja designu w świecie cyberbezpieczeństwa

Jason Cyr rozpoczął swoją przygodę z designem w cyberbezpieczeństwie w 1998 roku, pracując dla startupu Excerpt w Vancouver. Firma zajmowała się infrastrukturą klucza publicznego. Początkowo zatrudniony jako webmaster w dziale marketingu, szybko zaczął tworzyć aplikacje demonstracyjne z wykorzystaniem technologii firmy.

Przełom nastąpił, gdy zespół inżynieryjny zauważył kreatywnego pracownika umiejącego pisać kod. W rezultacie Cyr został zaangażowany do przepisania interfejsu produktu firmy. Po przejęciu przez RSA Security odkrył jednak, że jego działania to faktycznie praktyka UX. Większa firma dysponowała laboratorium użyteczności oraz dedykowanym zespołem UX.

Mimo że design w enterprise software długo nie otrzymywał należytej uwagi, sytuacja zmieniła się wraz z rozpowszechnieniem urządzeń mobilnych. Ludzie noszący w kieszeniach urządzenia z wyjątkowym UX zaczęli oczekiwać podobnych doświadczeń od oprogramowania biznesowego. Przejście na SaaS i cloud dodatkowo wymusiło nacisk na jakość doświadczeń użytkowników – świetny UX przekłada się teraz bezpośrednio na wskaźniki przedłużenia umów.

Podwyższone oczekiwania zmieniły również perspektywę na design w enterprise. Przez pewien czas zespoły postrzegały podwyższone doświadczenia jako wyróżnik rynkowy. Obecnie okazuje się jednak, że to jedynie warunki podstawowe. Słabe UX może przegrać transakcje, ale świetne niekoniecznie je wygra – ludzie tego po prostu oczekują.

Fragmentacja jako główne wyzwanie branży

Rynek cyberbezpieczeństwa charakteryzuje się niezwykłą zmiennością ze względu na walkę z ciągle ewoluującymi zagrożeniami. Każda nowa podatność rodzi falę produktów od startupów budujących rozwiązania chroniące przed nowymi atakami. Klienci adoptują te produkty, dążąc do stworzenia najlepszej możliwej obrony.

Problem leży jednak w skali tego zjawiska. Przedsiębiorstwa, z którymi rozmawia Cisco, mają w swoich środowiskach 50, 60, a nawet 70 różnych produktów bezpieczeństwa. To ogromne obciążenie dla administratorów, którzy muszą obsługiwać te narzędzia.

Każdy nowy produkt wymaga wdrożenia, uruchomienia operacyjnego oraz przeszkolenia zespołów. Dodatkowo wszystkie systemy muszą ze sobą współpracować. Ryzyko błędów konfiguracji jest ogromne, ponieważ administratorzy muszą powtarzać te same ustawienia w wielu różnych miejscach.

Cyr podaje konkretny przykład: skonfigurowanie dostępu jednego użytkownika do aplikacji HR wymaga działań w dostawcy tożsamości, oprogramowaniu VPN oraz różnych narzędziach firewall – osobno dla biura i pracy zdalnej. Gdy jedna reguła wymaga konfiguracji w wielu miejscach, możliwość błędu jest ogromna. Co więcej, atakujący często dostają się do środowisk nie przez skomplikowane luki zero-day, ale właśnie przez błędne konfiguracje systemów.

Strategia Cisco – od akwizycji do platformy

Cisco budowało swoje portfolio bezpieczeństwa głównie przez akwizycje innowacyjnych startupów z rozwiązaniami punktowymi. Efektem były jednak różne konsole i dashboardy – każdy startup miał własny wygląd, nawigację oraz systemy designu.

Aby rozwiązać ten problem, firma opracowała etapowy proces integracji nowych produktów:

Etap 1: Produkt standalone z własnym loginem i konsolą
Etap 2: Integracja z systemem Cisco – jeden login, dostęp przez wspólną nawigację
Etap 3: Adopcja wspólnego systemu designu Magnetic
Etap 4: Przejście na architekturę micro front-end i pełna integracja z głównym dashboardem

Jasny proces i ścieżka integracji ułatwiają akceptację zmian tożsamości produktu. Firmy wiedzą, dokąd zmierzają i jak będą częścią większej platformy.

Wyzwaniem w unifikacji są jednak pozornie proste rzeczy. Uzgodnienie terminologii między produktami stanowi ogromną inicjatywę. Różne produkty nazywają tę samą rzecz różnymi nazwami, a konflikty nazewnictwa ujawniają się podczas łączenia w wspólnej platformie.

Dlatego Cisco rozwija modele zarządzania do rozwiązywania takich konfliktów. Kluczem jest kulturowa zmiana na podejście „outcomes over output”. Gdy zespoły próbują rozwiązać konflikt między różnymi procesami pracy, mogą cofnąć się i zapytać o pożądany outcome. To standardowa taktyka negocjacyjna – gdy rozumiesz motywacje, często znajdujesz obszary zgodności.

Program GOAT – metodologia skupiona na wynikach

Program GOAT (Give Outcomes a Try) powstał podczas offsajtu zespołu designu w Austin, prowadzonego przez Greg Petrova, ówczesnego lidera organizacji. Zespół zidentyfikował problem zbyt częstego skupiania się na dostarczaniu funkcji bez rozumienia ich wartości.

W jednej z sesji breakout zespół narysował nawet kozę na szczycie góry jako część prezentacji. GOAT to specjalistyczna wersja design sprintu, różniąca się kluczowym elementem – skupia się na wynikach, nie na rozwiązaniach. Celem jest rzeczywiste zrozumienie efektów przed przejściem do projektowania.

Pierwszy GOAT dotyczył AI. Cisco przejmowało wówczas firmę AI dla zespołu bezpieczeństwa, a zespół miał ograniczony czas na wypracowanie wizji. Program pozwolił na szybkie wypracowanie kierunku rozwoju AI w produktach Cisco.

Sukces pierwszego GOAT zbudował wiarygodność metody. Ludzie zaczęli pytać o możliwość przeprowadzenia własnego GOAT. Obecnie Cisco realizuje co najmniej jeden GOAT kwartalnie, skupiając się na wczesnych, ambiwalentnych problemach – nie na funkcjach już znajdujących się w roadmapie.

Praktyczny przewodnik skutecznego GOAT

Zgodnie z doświadczeniami Cyra, program GOAT wymaga:

Cross-functional team – design, product management i engineering razem od początku
Wczesna faza – problem musi być ambiwalentny, nie feature w roadmapie
Focus na discovery – najpierw maksimum informacji o przestrzeni problemu
Wywiady z klientami – bezpośrednie rozmowy z użytkownikami
Alignment na outcomes – jasne zdefiniowanie oczekiwanych rezultatów
Koncepty high-fidelity – artefakty wizyjne dla kierunku rozwoju
Natychmiastowe wykorzystanie – gotowy output dla kolejnych kroków

Triada PM-Design-Engineering jako fundament

Cyr zarządza organizacją liczącą blisko 240 osób rozsianych po całym świecie. Zespół obejmuje Bangalore, Europę oraz Amerykę Północną i różne dyscypliny – od product design po research ops.

W idealnym świecie Cyr widziałby model podów – 8-10 inżynierów z designerem i product managerem. Obsługiwanie organizacji inżynieryjnej liczącej prawie 5000 osób sprawiałoby jednak, że setki designerów byłyby nierealne.

Rozwiązaniem jest triada PM-Design-Engineering na najniższym możliwym poziomie organizacji. Może to być poziom zespołu scrumowego, managera lub senior managera – w zależności od specyfiki danej części organizacji.

Design wnosi trzy unikalne wartości do tej triady:

Wizualizację przyszłości – mockupy, journey mapy, artefakty pokazujące przyszły stan
Proces double diamond – najpierw zrozumienie problemu, potem rozwiązanie
Fokus na użytkowniku – w enterprise często różni się od kupującego

Bez względu na jakość wykonania, rozwiązanie złego problemu nadal będzie złym rozwiązaniem. Dlatego właściwa diagnoza ma kluczowe znaczenie.

Budowanie skutecznej triady wymaga jednak jasnych ról i odpowiedzialności. Trzech liderów musi ustalić, kto za co odpowiada i kto podejmuje decyzje. Ważne jest również uwzględnienie ograniczeń wszystkich dziedzin – decyzje nie mogą opierać się wyłącznie na możliwościach inżynieryjnych.

Cyr używa narzędzi z design thinking do zapewnienia równości głosów. Ćwiczenia z post-it notes są zaprojektowane tak, aby każdy głos w pokoju był traktowany równo. Gdy ktoś zapisuje pomysł na karteczce i trafia na ścianę, staje się zanonimizowany. W rezultacie pomysł juniora może wisieć obok pomysłu dyrektora marketingu – oceniane są jako idee, nie według pochodzenia.

Często pojawia się również konieczność współpracy między różnymi administratorami. Jeden administrator może być odpowiedzialny za ustawienia kontroli dostępu, ale ta reguła może wymagać zmiany w firewall, za który odpowiada inna osoba. Dlatego konieczne jest głębokie myślenie o współpracy ludzi w enterprise environments – nie tylko jej umożliwienie, ale usprawnienie.

Rewolucja AI w projektowaniu interfejsów

Cyr opisuje swoją przygodę z ChatGPT przy pisaniu bloga o przyszłości designera. Praca z AI przypominała mu współpracę z kreatywnym partnerem. AI przekształciło jego tekst w scenariusz filmowy, co całkowicie zmieniło perspektywę.

To dokładnie to samo, co dzieje się w design thinking – zespoły zmieniają perspektywę problemu oraz tworzą artefakty zmuszające do spojrzenia z innej strony.

W produktach Cisco AI ewoluuje od prostych chatbotów. Zespół tworzy obecnie generative UI – nie tylko tekst, ale tabele, wizualizacje oraz elementy interaktywne w przestrzeni chatu.

Klienci przekazują jednak cenny feedback: przestańcie kierować AI na użytkownika, ukierunkujcie je na system oraz największe problemy z przetwarzaniem danych i analizą incydentów. To zmienia całkowicie podejście Cisco do implementacji AI – zamiast chat interfejsów koncentrują się na AI rozwiązującym największe problemy systemowe użytkowników.

Przyszłość interfejsów bez nawigacji

Najbardziej wizjonerskim elementem rozmowy było przewidywanie Cyra dotyczące przyszłości interfejsów. AI z dostępem do wszystkich danych może być o krok do przodu, powierzchując najważniejsze informacje oraz akcje w momencie logowania.

W przyszłości możemy nie potrzebować nawigacji w sposób, w jaki myślimy o niej dzisiaj. Tradycyjnie nawigacja służy do przeszukiwania systemu w poszukiwaniu miejsca działania.

Przewrotowy model zakłada jednak, że system wie, co jest ważne i kiedy. Zamiast szukać, użytkownik otrzymuje spersonalizowane, kontekstowe informacje od razu po zalogowaniu.

Cyr przyznaje, że tempo zmian nie pozwala na ociąganie się. Zespoły muszą działać na tych rzeczach i myśleć dalej w przyszłość niż wpływ na systemy.

Interesujące jest, że host podcastu Lance Morgan wspomniał o Alanie Cooperze, pionierze HCI, który przewidywał podobne rzeczy lata temu. Uważał nawigację za w dużej mierze porażkę, chcąc całkowicie predykcyjnych rozwiązań. Cyr odpowiedział, że kawałki układanki teraz wchodzą w grę.

Praktyczne rezultaty szybkiego wzrostu

Przykład produktu Secure Access pokazuje możliwości zintegrowanego zespołu. Produkt przeszedł drogę od zera do general availability w niecały rok, a następnie w pierwszym roku wzrósł do prawie 100 milionów dolarów przychodów.

Szybki wzrost wiązał się jednak z wyzwaniami. Zespoły przechodziły przez forming, storming, norming oraz performing – było trochę trudności na początku.

Obecnie ta organizacja stanowi jeden z najwydajniejszych zespołów w Cisco. Decyzje nie są podejmowane tylko na podstawie możliwości inżynierskich. Zespół może zrezygnować z funkcji nie dlatego, że inżynieria nie ma zdolności, ale ponieważ design nie ma zdolności potraktować jej z należytą uwagą.

To przedstawia wysoki poziom dojrzałości designu w organizacji.

Praktyczne prompty AI dla designerów

Na podstawie doświadczenia Cyra z ChatGPT przy pisaniu bloga o przyszłości designera, oto praktyczne prompty mogące pomóc w pracy kreatywnej:

Prompt do zmiany perspektywy konceptów

"Mam [opisz swoją treść/koncepcję]. Przekształć to w [nowy format - scenariusz filmowy/prezentację/case study]. Dodaj [konkretne elementy - dialogi, narrację, kąty kamery/slajdy/dane]. Stylizuj to w stylu [określ styl]."

Kiedy stosować: Gdy utknąłeś z jedną perspektywą i potrzebujesz świeżego spojrzenia na problem projektowy.

Prompt do budowania user journey

"Stwórz chronologiczny dzień z życia [persona]. Pokaż jak [osoba] się budzi, przychodzi do pracy, używa [produktu/systemu], współpracuje z zespołem. Uwzględnij challenge'y, które napotyka i jak je rozwiązuje."

Kiedy stosować: Na początku projektowania nowego produktu lub przy przeprojektowywaniu istniejącego workflow.

Prompt do analizy outcomes vs output

"Mam funkcję [opisz feature]. Nie myśl o tym jak o funkcji, ale jak o zmianie zachowania użytkownika. Jakie konkretne outcomes to może przynieść? Jak zmierzyć sukces tej zmiany? Jakie zachowania chcemy zobaczyć?"

Kiedy stosować: Przed rozpoczęciem pracy nad nową funkcjonalnością – żeby skupić się na wynikach, nie na samej produkcji.

Prompt do design critique

"Jestem [rola] i patrzę na [projekt/mockup/prototyp]. Przeanalizuj to z perspektywy [różnych personas]. Jakie pytania mogliby zadać? Jakie problemy dostrzec? Co ich może frustrować lub zachwycać?"

Kiedy stosować: Podczas iteracji projektowych, żeby uzyskać różne perspektywy przed testami z użytkownikami.

ChatGPT całkowicie zmieniło sposób, w jaki Cyr patrzył na treść, którą pisał. To dokładnie to samo, co dzieje się w design thinking – zespoły zmieniają perspektywę problemu oraz tworzą artefakty zmuszające do spojrzenia z innej strony.

Kluczowy insight

Przepustowość designu jako strategiczny filtr

Standardowo myślimy: Jedynym wąskim gardłem w tworzeniu produktu jest dostępność inżynierów. Jeśli mają wolne moce, powinniśmy natychmiast dawać im kolejne zadania do realizacji.

W praktyce okazuje się, że: W dojrzałych organizacjach to właśnie przepustowość zespołu designu staje się strategicznym filtrem. Funkcja nie jest gotowa do wdrożenia, dopóki nie zostanie w pełni przemyślana i zaprojektowana.

Dlaczego to jest istotne: To zapobiega tworzeniu źle przemyślanych funkcji, które generują dług techniczny, frustrują użytkowników i ostatecznie marnują znacznie więcej czasu inżynierów na kosztowne poprawki. W Cisco decyzje nie są podejmowane tylko na podstawie engineering capacity – zespół może zrezygnować z funkcji, bo design nie ma zdolności potraktować jej z należytą uwagą.

Test na jutro: Następnym razem gdy podczas planowania pojawi się pomysł na nową funkcję, a zespół projektowy nie ma na nią czasu, zamiast dodawać ją warunkowo do backlogu inżynierskiego, spróbuj świadomie ją odrzucić z uzasadnieniem „brak mocy po stronie designu” i sprawdź, jak zmienia to priorytety i dyskusję o wartości tej funkcji.

Polecana książka:

„Outcomes Over Output” – Joshua Seiden – książka, która zrewolucjonizowała myślenie zespołu Cisco o skupianiu się na rezultatach zamiast na samej produkcji

Te notatki powstały na podstawie rozmowy z Jasonem Cyrem, VP i Head of Product Design w Cisco Security, przeprowadzonej w ramach Innovation Engine Podcast. Oryginalne źródło znajdziesz tutaj: