Minggu lalu nonton video YouTube dari Ryan Singer (orang di balik Shape Up methodology) yang berjudul “Christopher Alexander: A Primer.” Videonya lebih dari satu jam.
Kenapa? Karena untuk pertama kalinya, ada yang menjelaskan sesuatu yang selama ini terasa familiar tapi susah diartikulasikan: kenapa fitur yang sudah sesuai requirement, executed dengan baik, dan technically solid, sering berakhir tidak dipakai?
Ini problem yang umum. Founder SaaS sering komplain: dashboard punya puluhan fitur, user cuma pakai segelintir. Development time berbulan-bulan terbuang.
User cuma pakai 2 dari 47 fitur yang kita bikin
”Tapi requirement-nya jelas kok,” typical response-nya. “Semua fitur ini diminta stakeholder. Kita execute dengan baik.”
Dan di situlah letak masalahnya.
Christopher Alexander, seorang architect dari tahun 1960-an, ternyata sudah memecahkan problem ini puluhan tahun lalu. Yang menarik: dia bukan software engineer. Dia architect. Tapi prinsip-prinsipnya jadi foundational untuk design patterns, agile development, dan bahkan Shape Up yang aku lagi ulik sekarang.
Video Ryan Singer itu membuka perspektif baru. Alexander tidak cuma bicara soal bangunan. Dia bicara soal bagaimana kita design anything: software, produk, organisasi, bahkan cara kita bekerja.
Artikel ini coba rangkum tiga konsep inti dari Alexander yang relevan untuk product builder. Tidak perlu baca 15 buku tebalnya dulu.
Form, Context, Fit: Kenapa Requirement yang “Jelas” Sering Salah
Typical requirement yang sering muncul: “Tambahkan button export PDF di halaman report.”
Simple. Jelas. Actionable. Tim development execute dengan baik. Button-nya ada. Generate PDF work. Feature shipped tepat waktu.
Tiga bulan kemudian? Usage analytics menunjukkan hampir tidak ada yang pakai. Support ticket tentang reporting malah naik. Stakeholder yang request feature itu sendiri komplain bahwa “report masih susah di-share.”
Apa yang salah?
Alexander punya framework untuk ini: Form, Context, Fit.
Pendekatan yang berbeda: form-first vs context-first
Requirement tadi (“tambahkan button export PDF”) itu mendeskripsikan form. Struktur. Fitur. Solusi yang sudah kita tentukan dari awal.
Yang tidak dijelaskan adalah context: apa yang sebenarnya user coba lakukan? Dalam situasi apa mereka butuh ini? Struggle apa yang mereka alami sekarang?
Tanpa memahami context, kita tidak punya cara untuk mengukur apakah form yang kita buat fit atau tidak. Kita cuma bisa bilang “feature sudah ada” tapi tidak bisa jawab “apakah ini solve problem yang sebenarnya?”
Bedah requirement yang sama dengan pendekatan Alexander:
Context yang sebenarnya: sales team perlu share report ke stakeholder eksternal (biasanya client atau investor) lewat email. Stakeholder ini tidak punya akses ke aplikasi. Mereka prefer format yang bisa di-print dan di-highlight. Tapi mereka juga butuh data mentah untuk analisis sendiri di Excel. Report yang di-share harus ada executive summary satu halaman karena client cuma punya waktu lima menit untuk review.
Dari context ini, form yang emerged jauh lebih kaya dari sekadar “button export PDF”:
Export PDF dengan auto-generated summary page di halaman pertama. Export CSV untuk raw data. Shareable link dengan granular access control sehingga tidak sembarang orang bisa akses. Link expiry untuk security. Template email yang pre-filled sehingga sales tinggal klik send.
Hasilnya? Usage naik 300%. Support ticket turun 60%. Sales cycle lebih pendek karena meeting presentation jadi lebih smooth.
Bedanya: pendekatan pertama fokus ke form (“button”). Pendekatan kedua fokus ke context (“share data dengan stakeholder eksternal dalam situasi time-sensitive”). Dan dari context yang jelas, form yang lebih fit naturally emerged.
Yang Alexander sebut fit: empirical relationship antara form yang dibuat dan context yang di-serve. Sukses bukan diukur dari “fitur sudah jadi” tapi dari “apakah struggle berkurang?”
Pattern ini ada di mana-mana. Kebanyakan requirement yang datang ke product team itu describe form: “harus ada menu di sini,” “tambahin fitur ini,” “bikin screen yang bisa begini.” Sangat jarang yang describe context: “user stuck di tahap ini karena begini,” “mereka sekarang workaround dengan cara begitu yang ribet.”
Kalau requirement berbentuk form, kita harus dig deeper. Tanya kenapa. Tanya apa yang mereka coba capai. Tanya apa yang terjadi sebelum dan sesudah moment ini. Tanya kenapa cara sekarang tidak cukup baik.
Dari situ, baru kita bisa lihat context yang sebenarnya. Dan biarkan form emerged dari pemahaman itu, instead of dictating form dari awal.
Living Systems: Produk yang Hidup vs Produk yang Mati
Di buku The Timeless Way of Building, Alexander menulis tentang sesuatu yang dia sebut “quality without a name.” Dia struggle mendeskripsikannya selama bertahun-tahun. Later, dia kasih nama: Life.
Life di sini maksudnya: sejauh mana sebuah form enable berbagai macam aktivitas untuk flourish. Bukan biological life.
Alexander sering pakai contoh perbandingan dua tipe bangunan. Yang pertama: Soviet-style apartment building. Ground floor-nya blank. Uniform. Steril. Function-nya cuma satu: masuk, naik lift, jalan lewat koridor, sampai unit. That’s it. Tidak ada yang lain. Space-nya “mati” karena cuma enable satu narrow activity.
Yang kedua: courtyard dari bangunan klasik Eropa yang dia design. Ada benches. Ada arcades dengan shade. Ada open yard untuk anak-anak main. Ada area yang kena sinar matahari penuh, ada yang teduh. Space ini “hidup” karena enable berbagai macam aktivitas: orang bisa duduk baca buku, anak-anak bisa bermain, orang bisa socialize dengan tetangga, ada yang ambil phone call sambil jalan-jalan, ada yang nunggu teman sebelum masuk bangunan.
Ryan Singer pakai perbandingan ini di video untuk explain konsep yang sama applicable ke software.
Pikir tentang dashboard. Dashboard yang “mati”: fixed grid of metric cards. One view mode. Generic charts. User journey-nya: login, check numbers, logout. Average session: 30 detik. High bounce rate. Users screenshot dashboard terus paste ke tool lain untuk actual analysis.
Dashboard yang “hidup”: customizable. Ada drag-and-drop widgets. Multiple view modes. Quick filters tanpa harus navigate ke page lain. Inline editing. Contextual actions yang muncul based on data state. Bisa save views dan share dengan team. Drill-down tanpa losing context.
Bedanya bukan cuma di features. Bedanya di activities yang di-unlock. Dashboard yang hidup enable: quick stat check during meeting, deep analysis when needed, serendipitous pattern discovery, immediate action on insights, team collaboration on data, personal workspace yang reflects cara kerja masing-masing orang.
Satu dashboard cuma enable “check and leave.” Yang lain enable flourishing dari berbagai macam workflows.
Lens ini berguna untuk audit product. Untuk setiap major feature, tanya: berapa banyak activities yang intended waktu design? Berapa yang actually happening? Apakah user discover creative uses yang tidak expected? Apakah feature ini enable flourishing atau cuma prescribed narrow action?
Feature yang “hidup” biasanya punya usage yang surprising. User hack-nya untuk purposes yang tidak kita design. Session depth tinggi. User bilang “saya tidak bisa kerja tanpa ini” dengan emotional attachment yang genuine.
Feature yang “mati” opposite: cuma dipakai exactly seperti tutorial. Bounce rate tinggi. Feature requests banyak karena product tidak flexible. Users churn karena coba tapi tidak stick.
Alexander percaya bahwa kita bisa see the difference even without analytics. Living form dan dead form punya geometry yang berbeda. Living form punya richness, variety, surprise. Dead form punya uniformity, blankness, predictability.
Ini controversial tapi compelling: kita bisa feel ketika product terasa hidup atau mati. Dan feeling itu correlated dengan actual usage patterns.
Generative Process: Design yang Unfold, Bukan Dictated
Konsep ketiga Alexander: process.
Traditional design approach yang kita kenal: gather requirements, design complete solution, build everything, launch, hope it works. Waterfall klasik atau agile yang masih waterfall di hati.
Alexander punya pendekatan berbeda: generative process.
Cara Alexander design bangunan: identify area yang “not right.” Pahami context deeply. Make the smallest change yang meaningful. Deploy (literally bangun physical structure-nya). Observe apa yang terjadi. See what activities emerge. Let next step reveal itself from that observation. Repeat.
Small, reversible changes. Real usage drives next step. Emergence over prediction. Learn over execute.
Ini literally foundation dari Lean Startup (build-measure-learn), Agile (iterative development), dan Shape Up (6-week cycles).
Evolusi pemahaman tentang design process
Tapi Alexander lebih fundamental. Dia explain why these work: because good design unfolds dari real context observation, not upfront planning. Kita tidak bisa predict semua context dari awal. Context reveal itself through use.
Contoh nyata dari case collaboration tool startup:
Cycle pertama: mereka bikin thread-based messaging. Simple. Timestamp, author, basic search. Deploy ke internal team sendiri. Adoption bagus. Tapi pattern yang muncul: people copy-paste banyak info from external sources. Screenshots, links, notes dari tools lain muncul di conversation.
Emergence: user butuh reference external context within threads.
Cycle kedua: tambah rich link previews, file attachments, embeds untuk Google Docs dan Figma. Usage naik. Threads jadi lebih comprehensive. Tapi new pattern emerge: conversations ini jadi valuable reference material. Hard to find later. People re-ask same questions karena info buried.
Emergence: product bukan cuma chat, tapi evolving jadi knowledge base.
Cycle ketiga: advanced search, pinned messages, thread bookmarks. Deploy. Users mulai stop pakai separate wiki. Threads dengan pinned summary jadi lightweight docs.
Yang menarik: “knowledge base” positioning ini tidak ada di original plan. It emerged from observing real usage. Kalau mereka design everything upfront, mereka mungkin build wrong product (maybe generic chat app yang compete head-to-head dengan Slack).
Ryan Singer explicitly built Shape Up based on Alexander’s generative process. 6-week cycle = generative iteration. Appetite = constraint that breeds creativity. Shaping phase = context discovery. Hill charts = tracking fit progress. Cooldown = emergence reflection time.
Shape Up is Alexander’s philosophy, applied to software development.
Yang menarik: best features sering emerge, bukan planned dari awal. Product roadmap yang terlalu detailed terlalu jauh ke depan sering meleset. Context reveal itself through use. Job product builder bukan dictate form dari awal, tapi create conditions untuk emergence, observe carefully, dan amplify what works.
Kenapa Ini Relevan Sekarang
Era funding ketat. VC money susah. Competition tinggi. User expectations naik. Kita tidak bisa afford waste runway on dead features. Kita tidak bisa compete dengan prescribed workflows. Thoughtful design beats feature factory.
Menarik juga karena konsep Alexander ini connect ke hal-hal lain di blog ini.
Camel startup (yang fokus pada sustainable growth instead of growth-at-all-cost) basically design living systems. Products yang fit context survive longer. Products yang enable flourishing retain better.
Shape Up (dengan 6-week cycles dan appetite constraints) embody generative process. Betting table = choosing which context misfit to address next. Shaping = understanding context before dictating form.
Founder mindset dari Basecamp (build dengan constraints, solve your own problem, ship small and iterate) semua itu rooted di Alexander’s philosophy.
Mulai dari Mana
Tidak perlu langsung baca 15 buku Alexander. Ada starting point yang practical.
Next time dapat requirement atau user story, pause. Tanya: apakah ini mendeskripsikan form atau context? Kalau form, dig deeper sampai menemukan context. Dari sana, let form emerge.
Audit satu major feature di product. Tanya: designed untuk berapa activities? Actually dipakai untuk berapa? Apakah user creative dengan usage? Categorize: living, neutral, atau dead?
Run satu cycle (enam minggu, kalau mau ikut Shape Up) dengan explicit generative mindset. Identify misfit. Understand context. Build smallest form. Deploy early. Observe. Document what emerged. Let that inform next cycle.
Praktik langsung biasanya lebih nempel daripada sekadar baca theory.
Kalau mau deep dive, mulai dari Ryan Singer. Blog-nya di ryansinger.co, especially series “Felt Presence.” Video YouTube “Christopher Alexander: A Primer” yang jadi starting point artikel ini. Shape Up book yang free online di basecamp.com/shapeup.
Untuk Alexander sendiri, start dengan Notes on Synthesis of Form. Thin book. Chapter 1-2 cukup. Explains form-context-fit paling clearly.
The Nature of Order (four thick books) heavy tapi worth it kalau serious. Book 1 paling accessible. Battle (latest book, real case study) most practical dan grounded.
Tapi honest advice: jangan stuck di learning mode. Apply one concept. See what happens. Let your own experience unfold the rest.
Penutup
Video Ryan Singer itu satu jam lebih, tapi worth every minute. Alexander punya cara lihat design yang berbeda: bukan cuma soal fitur atau aesthetic, tapi soal bikin space untuk hal-hal baik terjadi.
Form-context-fit. Living systems. Generative process. Tiga konsep ini cukup powerful untuk shift cara kita approach product development. Tidak perlu langsung apply semuanya. Pick one. Coba di satu project. Lihat apa yang terjadi.
Kalau ternyata berguna, atau malah menemukan challenge menarik, sharing pengalaman itu pasti valuable untuk banyak orang.
Semoga artikel ini berguna, atau setidaknya bikin curious untuk nonton video Ryan Singer atau baca satu chapter Alexander.
Resources:
- Ryan Singer: Christopher Alexander: A Primer
- Shape Up: basecamp.com/shapeup
- Christopher Alexander: Notes on Synthesis of Form
- Christopher Alexander: The Nature of Order (Book 1)
Artikel Terkait: