Anatomia skutecznej strony SDK: Jak zdobyć zaufanie dewelopera, zanim otworzy dokumentację #EN306

Ten artykuł to moje notatki z prezentacji Iry Nezhynskiej pt. „Design Anatomy Of A Perfect SDK Page”, która odbyła się podczas konferencji DappCon 2023. Wszystkie przedstawione koncepcje i obserwacje pochodzą bezpośrednio od prelegentki.

TL;DR

Podróż dewelopera to „pętla oceny”, a nie prosta ścieżka – strona produktowa jest kluczowym punktem na tej pętli
Projektowanie opiera się na trzech warstwach: architekturze informacji, ścieżkach użytkownika oraz stylu wizualnym
Fundamentem projektu są wywiady z użytkownikami, podczas których odkrywa się „złoto UX” – autentyczne potrzeby odbiorców
Najczęstsze błędy: nadmiar tekstu we wstępie, przedwczesne wezwania do dołączenia do społeczności, nagromadzenie przycisków CTA
Inwestycja w przykładowe, działające projekty jest cenniejsza niż tworzenie tutoriali wideo
Informacje o wspieranych językach i platformach należy umieścić na samej górze – to kluczowy filtr oszczędzający czas
Strukturę strony buduje się od danych z badań (tzw. „UX gold”), a nie od tego, co chcemy przekazać

Strona SDK to znacznie więcej niż wizytówka produktu. Stanowi pierwszy punkt kontaktu z deweloperem, który jeszcze nie otworzył dokumentacji, ale już ocenia czy warto spróbować. Ira Nezhynska pokazała, jak zaprojektować taką stronę, aby skutecznie przeprowadzić użytkownika przez proces decyzyjny.

Dlaczego strona SDK w ogóle ma znaczenie?

Według Nezhynskiej deweloperzy nie przechodzą bezpośrednio do dokumentacji. Najpierw pokonują tzw. „consideration and evaluation loop” – szczególnie gdy na rynku dostępnych jest kilka projektów oferujących bardzo podobne SDK. W takiej sytuacji zaczynają porównywać i zastanawiać się: co jest lepsze?

Website znajduje się właśnie w tej pętli. To moment oceny przed rozpoczęciem właściwej pracy. Z kolei sama dokumentacja reprezentuje już „user experience loop” – wewnętrzne doświadczenie użytkownika. Natomiast strona jest wcześniej. To decyzja, czy w ogóle warto podjąć próbę.

Cała ścieżka onboardingu przed dokumentacją

Nezhynska pokazuje, że zanim użytkownicy dotrą do dokumentacji, przechodzą przez różne punkty kontaktu:

Website (właśnie o tym mówimy)
Strony eventów
Newslettery
Hackathony i wydarzenia branżowe

Dopiero po tym wszystkim sięgają po prawdziwą dokumentację deweloperską. Każdy z tych punktów odgrywa swoją rolę w budowaniu przekonania i zaufania.

Trzy warstwy projektowania – metafora miasta

Nezhynska dzieli proces projektowania na trzy poziomy. Dlatego używa metafory miasta, aby zilustrować te abstrakcyjne pojęcia.

Warstwa 1: Architektura informacji

To jak planowanie miasta. Decydujesz, jakie budynki postawisz i gdzie je umieścisz. Czy będą uniwersytety? Fabryki? Strefa przemysłowa? W kontekście strony internetowej chodzi o to, jakie bloki informacji są potrzebne i jak je ułożyć.

Warstwa 2: Ścieżki użytkownika

Teraz myślisz, jak mieszkańcy przechodzą między budynkami. Jaka jest ich typowa trasa w ciągu dnia? Jak kompletują swoją podróż? Na stronie chodzi o to, jak deweloper nawiguje między sekcjami, aby zebrać wszystkie potrzebne informacje.

Warstwa 3: Styl wizualny i interfejs

To branding i estetyka. Czy to miasto w stylu Bauhaus? Solarpunk? Underground? Struktura może być identyczna, jednak wygląd całkowicie odmienny.

Fundament: Zanim narysujesz pierwszy piksel, szukaj „złota UX”

Nezhynska jest tu bezwzględna: nie zgadujemy, co potrzebne. Pytamy bezpośrednio użytkowników.

Proces zaczyna się od dwóch typów rozmów:

Badania UX z osobami, które już pracowały z SDK – dowiadujesz się, co działa, co nie działa, czego użytkownicy szukają i czego faktycznie potrzebują
Wywiady z odbiorcami – identyfikujesz główne grupy odbiorców i rozumiesz ich różne potrzeby oraz cele

Częsty przypadek: różne segmenty audiencji mają różne cele końcowe. Przykład z prezentacji dotyczy partnerów biznesowych versus akademickich. Współpraca może wyglądać podobnie, jednak ostateczne cele są zupełnie inne – komercyjne versus naukowe.

Deweloperzy zwykle stanowią główną grupę odbiorców. Dlatego większość informacji na stronie jest dla nich. Trzeba z nimi rozmawiać osobno, aby zrozumieć ich specyficzne potrzeby.

„UX gold” – jak wyciągać wartość z badań

Po zebraniu danych Nezhynska grupuje je w kategorie pytań. Następnie szuka wzorców – nazywa to „złotem UX”.

To moment, gdzie surowe dane zamieniają się w konkretne decyzje projektowe. Widzisz, gdzie są „zielone kropki” – tam znajduje się złoto. To wskazówki, co musi być na stronie i w jakiej kolejności powinno się pojawić.

Na tym etapie pracujesz już na dwóch warstwach jednocześnie: architekturze informacji oraz ścieżkach użytkownika. Jeśli widzisz określoną wątpliwość u użytkowników, umieszczasz tam blok informacji. Pytanie następujące po tym pytaniu sugeruje, co powinno być dalej. W rezultacie cała struktura buduje się od ścieżki edukacyjnej użytkownika.

Anatomia strony – sekcja po sekcji

Nezhynska przechodzi przez konkretną strukturę, używając fikcyjnego przykładu „Radial SDK”.

Sekcja Hero: Jak w 5 sekund zdobyć uwagę dewelopera

Pierwszy ekran, który widzi użytkownik, stanowi najważniejszy test dla strony. Z tego powodu musi być zwięzły, konkretny i pozbawiony marketingowego szumu.

Jednak właśnie tutaj popełnia się trzy podstawowe błędy:

Błąd 1: Za dużo tekstu we wstępie

Ludzie nie czytają długich bloków na stronach internetowych. Warto trzymać to zwięźle, ponieważ nikt nie przeczyta trzech akapitów opisu.

Błąd 2: Drugi CTA do „dołącz do społeczności”

Ta strona jest dla użytkowników odwiedzających ją po raz pierwszy i drugi. Jednak dołączanie do społeczności to za wcześnie. Najpierw muszą zrozumieć, po co tu są – żeby poznać SDK, a nie żeby od razu dołączać do community. Wezwanie do akcji związane ze społecznością może pojawić się gdzieś niżej, ale nie w pierwszej widocznej części strony.

Błąd 3: Niepotrzebny tekst typu „for developers, by developers”

Nezhynska nazywa to „Christmas tree of copywriting”. Jeśli to SDK, oczywiste jest, że dla deweloperów. Mimo to wiele stron powtarza to wszędzie, co nic nie wnosi. Lepiej użyć ostrego, zwięzłego sloganu opisującego główny cel produktu – działa to zarówno dla SEO, jak i komunikacji.

Ważne: wspierane platformy od razu na górze

To ograniczenie, które lepiej pokazać natychmiast – oszczędzasz czas odwiedzającym. Jeśli SDK nie wspiera danego języka czy platformy, deweloper musi to wiedzieć od razu, zanim straci czas na dalsze czytanie. To kluczowy filtr oszczędzający czas.

Sekcja funkcji: Przetłumacz technologię na korzyści

W tej sekcji masz dwa cele: pokazać, co SDK potrafi (możliwości) oraz przekuć to na korzyści dla użytkownika.

Punkty te są ze sobą połączone. Najpierw musisz znać możliwości techniczne. Następnie przepuszczasz je przez kilka ćwiczeń copywriterskich, aby przerobić na korzyści biznesowe lub praktyczne.

Jeśli na rynku jest kilka alternatyw, to dobry moment, żeby pokazać, co wyróżnia Twoje SDK. Zwykle będzie 5-7 funkcji, każda z obrazkiem. Niektóre są bardzo konkretne – możesz linkować z nich bezpośrednio do konkretnego miejsca w dokumentacji.

Jednak 2-3 funkcje będą bardziej ogólne. Tu pojawia się pokusa: skoro wszędzie są przyciski, dodajmy „przejdź do dokumentacji” też tutaj. To błąd, który Nezhynska nazywa „CTA clustering” – nagromadzenie wezwań do akcji obniża skuteczność całej strony.

Rozwiązanie polega na pogrupowaniu tych ogólnych funkcji jako nieklikalnych, informacyjnych bloków. Jeśli są ważne, należy umieścić je na górze nad tymi klikalnymi.

Setup / Get started: Pokazuj, nie opowiadaj

To sekcja, która prowadzi od poziomu początkującego do zaawansowanego. Jej zadaniem jest udowodnienie, jak łatwo można rozpocząć pracę z narzędziem.

Struktura powinna obejmować:

Setup jako pierwszy i bardzo widoczny element – może być duży, ponieważ często masz instrukcje dla różnych środowisk
Ścieżkę edukacyjną od beginnera do advanced – wszystko linkuje do konkretnych punktów w dokumentacji, nie tylko do strony głównej
Sample projects jako priorytet inwestycyjny – lepiej tu niż w tutoriale wideo
Miejsce na tymczasowe treści – nadchodzący przewodnik po hackathonie, nagranie z warsztatu, recording z ostatniego wydarzenia

Sample projects to najważniejsza inwestycja. Nezhynska jest tu jasna: według prelegentki najcenniejszym zasobem dla deweloperów są kompletne, działające przykłady projektów. Okazuje się, że to właśnie one, znacznie bardziej niż tutoriale wideo, budują zaufanie i pokazują realną wartość SDK.

Jeśli ktoś aktywnie utrzymuje stronę i ma ona charakter promocyjny, to dobre miejsce na przewodnik po nadchodzącym hackathonie czy video z warsztatu. W rezultacie tworzy to solidną sekcję edukacyjną.

Aplikacje zbudowane z SDK: Dowód dla architekta

Pokazanie, że inni zaufali narzędziu, jest kluczowe, zwłaszcza dla decydentów takich jak architekci oprogramowania.

Typowy błąd wygląda tak: pięć logo, napis „tysiące aplikacji używa naszego SDK”, przycisk „zacznij budować” linkujący ponownie do dokumentacji. To działa tylko wtedy, gdy masz dedykowany marketplace aplikacji napędzany przez Twoją dokumentację.

Jeśli nie masz, Nezhynska radzi: dostarcz trochę więcej. Zamiast standardowej listy logo, znacznie lepiej jest pokazać realne, działające projekty i bezpośrednio do nich linkować. Dzięki temu ludzie zobaczą, że to prawdziwe projekty, a nie tylko puste obietnice.

Bonus: zwykle będą to mniejsze projekty niż Twój. Będą dumni, że są na Twojej stronie, co daje im powód, aby podzielić się Twoją stroną SDK z innymi. W ten sposób tworzy się marketingową symbiozę – obie strony na tym zyskują i dostarczasz autentycznego dowodu na działanie technologii.

Zaawansowane zasoby i elementy społecznościowe

Co powinno się znaleźć w tej sekcji:

Zaawansowane zasoby (whitepapers, przewodniki) – mogą zostać na stronie, są relevantne
FAQ – może przenieść się do dokumentacji, ponieważ tam i tak pojawiają się pytania
Fora deweloperskie i czat deweloperski – linki do Discorda i forum
Newsletter deweloperski – rozdziel od newslettera nietechnicznego, jeśli robisz dużo email outreach

Newsletter deweloperski – częsty błąd polega na używaniu etykiety „dołącz do naszej społeczności”, podczas gdy faktycznie to zapisanie się do newslettera. Nezhynska podkreśla: to zadanie dla copywritera. Gdy piszesz „dołącz do społeczności”, a użytkownik otrzymuje newsletter, czuje disconnect. Zatem bądź jasny w przekazie.

Bonus: to dobre miejsce na oferty pracy i granty deweloperskie, umieszczone na końcu strony.

Co jeszcze? Przypadki użycia

Nezhynska pyta słuchaczy: gdzie umieścić aplikacje zbudowane z SDK? Istnieją dwie opcje:

Po tutorialach – logiczne, ponieważ pokazuje przykłady użycia dokumentacji. Wtedy lepiej dać same logo na górze jako dowód społeczny.

Po funkcjach – bardziej promocyjne podejście. W tym przypadku zrób to klikalne i upewnij się, że najlepsze projekty są na górze.

Optymalizacja i kwestie techniczne

Mobile versus desktop – kontekst decyduje

Pytanie z sesji Q&A dotyczyło tego, czy lepiej projektować mobile-first czy desktop-first.

Odpowiedź Nezhynskiej była jednoznaczna: zależy od odbiorców i następnej destynacji. Dla deweloperów i strony SDK? Desktop-first to podejście w pełni uzasadnione, ponieważ deweloperzy pracują i testują kod na komputerach, a nie na telefonach. Strona SDK jest zatem częścią ich profesjonalnego środowiska pracy.

Jednak jeśli następna destynacja to aplikacja mobilna, wtedy mobile-first ma sens. Z tą konkretną strukturą (strona SDK) layout jest prosty. Wystarczy jeden klik w Figmie, aby stworzyć układ mobilny bez dodatkowej pracy.

Gdzie kończy się zakres odpowiedzialności?

Ważna uwaga Nezhynskiej pojawiła się przy pytaniu o wybór między unikalnym wyglądem a ugruntowanym szablonem dla dokumentacji.

Ona nie odpowiada na to pytanie, ponieważ dotyczy ono organizacji samej dokumentacji – to produkt sam w sobie. Istnieją specjalni designerzy, którzy pracują z deweloperami nad doświadczeniem developmentu i organizacją dokumentacji.

Jej praca polega na przyprowadzaniu deweloperów DO dokumentacji. Z kolei jeśli jesteś deweloperem lub designerem dokumentacji, Twoja praca to utrzymanie ich W dokumentacji. To dwie różne pętle i dwa różne zakresy odpowiedzialności.

A/B testing – kiedy i co testować?

Pytanie z sesji Q&A dotyczyło momentu przeprowadzania testów A/B.

Przykłady dobrych momentów na testy:

Pozycja „aplikacje stworzone z SDK” – gdzie lepiej działa, po funkcjach czy po tutorialach?
Ścieżka edukacyjna przy hackathonach – hackathon to tymczasowa sekcja, warto przetestować, gdzie najlepiej ją umieścić. Dane z takich testów mogą z kolei pomóc w planowaniu przyszłych kampanii
Targetowanie większych firm – kiedy architekt oprogramowania podejmuje decyzję

Nezhynska radzi uruchomić test A/B przy pierwszym hackathonie, zebrać dane i wykorzystać je przy następnym.

Ważna obserwacja: nawet w przestrzeni web3, w środowisku deweloperskim, deweloperzy zachowują się na różne sposoby. Nie ma uniwersalnego podejścia, dlatego nie będziesz wiedział na pewno, gdzie najlepiej umieścić daną sekcję bez testów dla Twojego konkretnego odbiorcy.

Checklist: czego unikać przy projektowaniu strony SDK

Użyj tej listy, aby sprawdzić, czy nie popełniasz typowych błędów:

Za dużo tekstu we wstępie – skróć do minimum, nikt nie czyta długich bloków
„Dołącz do społeczności” CTA w pierwszej widocznej części – za wcześnie, użytkownik musi najpierw poznać produkt
CTA clustering – za dużo przycisków w jednym miejscu obniża skuteczność całej strony
„For developers by developers” i podobny fluff – unikaj dekoracyjnego copywritingu
Ściana logo bez prawdziwych linków – pokaż prawdziwe projekty z działającymi linkami zamiast pustych logo
Mylenie „dołącz do społeczności” z newsletterem – bądź precyzyjny w przekazie, to nie to samo
Ogólne „przejdź do dokumentacji” przy każdej funkcji – linkuj do konkretnych miejsc albo nie linkuj wcale
Brak wspieranych platform na górze – to ograniczenie, pokaż je natychmiast, aby oszczędzić czas użytkownikom

Checklist: obowiązkowe elementy strony SDK

Upewnij się, że Twoja strona zawiera:

Sekcja górna (above the fold)

Zwięzły tytuł i krótkie wprowadzenie (max 2-3 zdania)
Jeden główny CTA (do dokumentacji lub get started)
Wspierane platformy/języki widoczne od razu

Sekcja funkcji

5-7 funkcji z obrazkami
Tekst pokazujący korzyści, nie tylko możliwości
Konkretne funkcje linkują do konkretnych miejsc w dokumentacji
Ogólne funkcje jako nieklikalne bloki informacyjne

Setup / Get started

Instrukcje instalacji (może być dla różnych środowisk)
Ścieżka edukacyjna: beginner → intermediate → advanced
Sample projects (priorytet nad tutorialami wideo)
Linki prowadzą do konkretnych punktów w dokumentacji, nie tylko do strony głównej

Dowód społeczny

Prawdziwe projekty używające SDK (z działającymi linkami)
Pozycja: po funkcjach (promocyjnie) lub po tutorialach (jako przykład użycia)

Zaawansowane zasoby i społeczność

Zaawansowane zasoby (whitepapers, przewodniki)
Linki do forów deweloperskich i czatu
Newsletter deweloperski (oddzielony od nietechnicznego)
FAQ (opcjonalnie – może być w dokumentacji)
Oferty pracy i granty deweloperskie (na końcu)

Badania i podstawy

Badania UX z użytkownikami SDK przeprowadzone
Główne grupy odbiorców zidentyfikowane
„Złoto UX” wyciągnięte z danych badawczych
Struktura strony oparta na ścieżce edukacyjnej użytkownika, nie na tym, co chcesz powiedzieć

Więcej od Iry Nezhynskiej

Jeśli chcesz zgłębić temat, Nezhynska poleca:

Nagranie z East Denver – na jej stronie, prawie na samej górze. Prezentacja o tym, jak positioning można wykorzystać dla architektury strony i strategii brandingowej.
45-minutowe nagranie o „medium viable brand” – również z East Denver, niepublikowane w momencie DappCon.
2-godzinny warsztat na Radicle Unite – dokładnie o tym samym temacie co prezentacja, jednak w formie warsztatowej.

Kluczowy insight

Prawdziwy dowód zamiast logo

Standardowo myślimy: Najlepszym dowodem społecznym (social proof) jest umieszczenie na stronie logo znanych i dużych firm. Im większa firma, tym większa pożyczona wiarygodność. To naturalne, że chcemy pokazać najgłośniejsze nazwy z branży.

W praktyce okazuje się, że: Bardziej przekonujące dla technicznej publiczności jest pokazanie kilku mniejszych, ale realnych i klikalnych projektów, które faktycznie używają SDK. Link do działającej aplikacji lub publicznego repozytorium jest silniejszym dowodem niż samo logo. Deweloperzy chcą zobaczyć kod w akcji, a nie tylko nazwę firmy.

Dlaczego to jest istotne: Takie podejście zmienia postrzeganie użytkowników z pasywnego źródła wiarygodności w aktywnych partnerów. Promując ich pracę, tworzysz marketingową symbiozę i udowadniasz, że narzędzie faktycznie działa w praktyce. To autentyczny dowód zamiast pustych obietnic.

Test na jutro: Następnym razem gdy będziesz projektować sekcję „Zaufali nam”, zamiast prosić o listę największych klientów, znajdź 3-4 aktywne projekty używające Twojego SDK i poproś ich o zgodę na podlinkowanie. Sprawdź, jak ta autentyczna forma dowodu wpłynie na reakcje społeczności.

Podsumowanie: Twoja strona SDK to funkcja produktu

Na koniec warto potraktować stronę produktową SDK nie jako materiał marketingowy, ale jako pierwszą, najważniejszą funkcję produktu. To właśnie ona odpowiada za onboarding, buduje zaufanie i decyduje, czy deweloper w ogóle da szansę Twojemu kodowi. Dobrze zaprojektowana, staje się cichym, ale jednocześnie najskuteczniejszym ambasadorem technologii.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: DappCon 2023: Design Anatomy Of A Perfect SDK Page – Ira Nezhynska