Narracja budowniczego

Pochodzenie

Grawitowałam, by być na froncie wcześniej, ponieważ jest to powierzchnia, na której intencja spełnia rzeczywistość: piksele, latencja, kopiowanie i przepływ decydują, czy ktoś idzie dalej czy po cichu odchodzi. To pokorne miejsce do pracy - nie można ukrywać się za abstrakcjami, kiedy użytkownik patrzy na wynik. Przez lata ten instynkt zamieniał się w powtarzalny obiektyw: jaką pracę wykonuje ten ekran, jakie ograniczenia nie podlegają negocjacjom i jakie są najmniejsze zmiany, jakie możemy wysłać, które w sposób mierzalny poprawiają zaufanie, przejrzystość czy szybkość? Wciąż piszę UI, ale pytanie za UI jest to, co skala między zespołami i produktami.

Ewolucja

W Luma Health spędziłem znaczący czas wewnątrz Centrum Komunikacji - ciężki, wysoki ruch, gdzie wydajność i przejrzystość nie są polskie; są one częścią koordynacji opieki. Produkt wychwycił warstwy tarcia UX i ścieżki kodu, które sprawiły, że każda zmiana czuła się ryzykowna, czyli jak zespoły zwalniają nie zauważając. Pomogłem odtworzyć tę powierzchnię, więc doświadczenie było lżejsze dla prawdziwych użytkowników i użyliśmy kanałów zwrotnych (w tym raportów użytkowników), aby potwierdzić, że naprawiamy to, co ludzie naprawdę czuli - nie tylko to, co było łatwe do zmierzenia na desce rozdzielczej. Równolegle traktowałem bezpieczeństwo jako część doświadczenia użytkownika: generowany przez użytkownika bogaty tekst jest klasycznym pistoletem na nogi dla XSS, jeśli tylko sanitize "gdzieś". Pomogłem wyeliminować krytyczne narażenie przez oczyszczanie treści przed przetwarzaniem API i ponownie na granicach renderowania, i przyczyniłem się do wspólnego komponentu API i decyzji systemu designerskiego, aby inne eskady nie musiały ponownie odkrywać tych samych ostrych krawędzi.

Sposób myślenia o produkcie w praktyce

Niektóre z moich najwyższych dźwigni pracy siedzi, gdzie UX, zachowanie backend, i operacje spotkać - gdzie krucha integracja staje się bilety, burn, lub późno-nocna strona. Przykład: rurociąg nadawczy SFTP, w którym "działa on na mojej maszynie", nie był wystarczający dla klientów w zakresie wrażliwych przepływów danych. Przeprojektowałem go tak zespoły skonfigurowane zewnętrzne → wewnętrzne mappings pola w UI z walidacji zamiast zgadywania i wsparcia powodzi. Bilety spadły gwałtownie, a my chroniliśmy związek, który nie mógł sobie pozwolić na niechlujne przekazanie. W Sisnet pracowałem na rynku, gdzie prędkość zawartości była równie ważna jak jakość kodu. Zbudowałem AdminJS CMS na Node.js, aby marketing i Operacje mogły wysyłać kopie, obrazy i stylizacja bez inżynierii dla każdego treaka - tygodniowe ćwiczenia przeciwpożarowe spadły do "prawie nigdy", a zespół może skupić się na prenumeratach, Stripe i Klaviyo, a głębokość produktów nad rutynową publikację.

Membrus - budowa z prawdziwymi zgromadzeniami

Oprócz moich ról w pełnym wymiarze czasu współzałożyłem Memberus: platformę dla kościołów do prowadzenia członkostwa, komunikacji i operacji w jednym spójnym systemie zamiast patchwork arkuszy kalkulacyjnych, czatów grupowych i narzędzi ad hoc. Praca nie była "dodać kolejną aplikację CRUD". To było zrozumienie, jak pastorzy i personel rzeczywiście przejść przez tydzień - kto potrzebuje dostępu do co, co łamie, gdy dane są niespójne, i jak wysłać przepływu pracy admin, które nietechniczne ludzie mogą posiadać. Posiadałem produkt i dostawy na powierzchniach: obecność społeczeństwa, doświadczenia członków i narzędzia wewnętrzne, iterając z przywódcami kościoła, którzy byli hojni z uczciwych opinii. To jest produkt, który chcę budować: uziemiony prawdziwymi ograniczeniami, wysłany do prawdziwych użytkowników, ulepszony publicznie - nie slideware.

Trwałe tempo pod presją

W Shifting pracowałem w małym zespole wysyłając rynek sprzedaży biletów pod prawdziwą presją zakresu - szybkość miała znaczenie, ale tak nie spalenie ludzi. Często zachowywałem się jak osoba, która musiała wybrać: co mamy ciąć, co utwardzić, a co odmówić kompromisu? Moje nastawienie było w kierunku żeglugi dobrze, a nie chaotycznie: codziennie odblokowywanie, konsekwentny przegląd kodu, więc opinie zwrotne były przewidywalne, a małe ulepszenia DX, które uczyniły następny tydzień łatwiejszym niż poprzedni. Zbudowałem również wewnętrzne oprzyrządowanie w stylu CMS- tak, aby nietechniczne koledzy z drużyny mogli piterować treści bez konieczności stawania się wąskim gardłem. Wynik nie był tylko "uruchomiliśmy" - był to funkcjonalny rynek dostarczony w zrównoważonym tempie, z klientem, który czuł się prawdziwie dobrze obsługiwany. Ten wynik ma dla mnie znaczenie tak samo jak każdy szczegół techniczny.

Ta strona - zbudowany jako produkt

Ta strona jest celowo więcej niż statyczne CV. To i18n-first, dzieli się UI przez monorepo, a układ priorytetyzuje czytelną hierarchię i odstępy tak długie strony jak ten pozostają przyjemne do czytania. Lucas AI jest częścią tej samej tezy: asystent, który odpowiada w pierwszej osobie, ale tylko z ustrukturyzowanego kontekstu opublikowanego tutaj - projekty, doświadczenie i jak myślę o handlu-off - więc eksploracja wydaje się uziemiona zamiast generycznych. Jeśli czytasz tak daleko, widzisz argument rzemiosła w miniaturze: narracja, systemy i powierzchnię produktu, która zachęca do głębokości.

Jak buduję

  • Zacznij od pracy użytkownika-to-be- done, a następnie zaprojektuj najmniejszą pętlę, która zmniejsza ryzyko i dowodzi wartości wcześnie.
  • Traktuj bezpieczeństwo, dostępność i wydajność jako UX - ludzie czują je nawet, gdy nie mogą cytować podstawowej kwestii.
  • Preferować jasne kontrakty i wielokrotnego użytku primitives nad jednorazową dostosowanie; system projektowania powinien pomnożyć dostawy, a nie dekoracji.
  • Wybierz zakres celowo pod presją: chronić jakość bez poświęcania tempa i zdrowia zespołu.
  • Traktuj bilety, wsparcie i jakościowe informacje zwrotne jako sygnały produktowe - i zamknij pętlę, aby ta sama klasa problemu nie wróciła po cichu.