Ana içeriğe geç

EVENTINN HUMAN EXPERIENCE & PRODUCT NORTH STAR

Büyük Resim · İnsan Deneyimi · Karar Güveni · Ürün-Tarifi Doktrini​

Revizyon v2 · EFFECTIVE · Yazar: EVENTINN AI-CEO · Human-CEO kabulü: 2026-08-07T21:23:45Z · yürürlük: 2026-08-08T22:08:15Z (9 Ağustos 2026, Europe/Istanbul) · v1 kabulü: 2026-08-07T17:22:33Z · Karar sahibi: Human CEO. Bu yürürlük kararı implementation, merge veya deploy yetkisi üretmez. v1→v2 farkları: bu kaydın REVISION DELTA — v1 → v2 bölümü.

Bu revizyon, mevcut kabul edilmiş Human Experience North Star’ın vizyonunu genişletmek ve dönemsel/taktik hükümleri Canon dışına çıkarmak için hazırlanmıştır.

Ana ilke:

EventInn yalnız etkinlik sektörünün dijitalleştirilmiş süreçlerini sunan bir yazılım değil; insanların karmaşık etkinlik kararlarını daha doğru, daha güvenli, daha anlaşılır ve daha koordineli verebildiği bir karar ve çalışma ortamı olmalıdır.

§1 — EventInn’in temel iddiası​

EventInn’in amacı daha fazla ekran, daha fazla form, daha fazla liste veya daha fazla otomasyon üretmek değildir.

EventInn’in amacı:

Etkinlik üretimindeki karmaşıklığı, belirsizliği, dağınık bilgiyi, koordinasyon yükünü ve karar riskini sistemin içinde taşıyarak insanların daha iyi kararlar vermesini sağlamaktır.

Bu nedenle EventInn:

LISTING PORTAL
≠
EVENTINN

CRM
≠
EVENTINN

MARKETPLACE
≠
EVENTINN

AI SEARCH
≠
EVENTINN

EventInn bunların bazı kabiliyetlerini taşıyabilir; fakat ürünün üst kimliği:

ETKİNLİK ÜRETİMİNİN KARAR VE ÇALIŞMA SİSTEMİ

olmalıdır.

§2 — Büyük resim nedir?​

EventInn’in büyük resmi yalnız vizyon, misyon, roadmap veya mimari değildir.

Büyük resim; gelecekte satın almak isteyeceğimiz EventInn’in, onu kullanan insanların hangi işleri hangi özelliklerle, hangi güven seviyesiyle ve hangi deneyim içinde yapacağını insan dilinde anlatan bütünsel hedef ürün tarifidir.

Bir profesyonel EventInn Product Handbook’u okuduğunda şunları anlayabilmelidir:

  • Bu ürün benim hangi problemlerimi çözüyor?
  • Hangi işleri EventInn içinde yapabiliyorum?
  • Hangi kararları daha kolay ve güvenli verebiliyorum?
  • EventInn benden ne ister?
  • EventInn benim yerime neyi hazırlar?
  • Ne zaman bana öneri verir?
  • Ne zaman benden karar ister?
  • Bir bilginin doğru olduğuna nasıl güvenebilirim?
  • Bir şey bilinmiyorsa ne olur?
  • Bir sonraki adımım nedir?
  • Ekip arkadaşlarım ve dış paydaşlarla nasıl birlikte çalışırım?
  • İhtiyaçtan kesinleşmiş işe kadar bağlamım nasıl korunur?

Bu soruların cevabı koddan önce ürün seviyesinde çözülmelidir.

§3 — North Star: Decision Confidence​

EventInn’in birincil deneyim hedefi “daha hızlı tıklama” değil, daha yüksek karar güvenidir.

Kullanıcı bir önemli kararın sonunda şunu hissedebilmelidir:

“Ne bildiğimi, neyi bilmediğimi, seçeneklerimin neden uygun olduğunu, risklerin nerede olduğunu ve şimdi ne yapmam gerektiğini anlıyorum.”

Bu nedenle temel ürün çıktısı:

MORE INFORMATION
≠
BETTER EXPERIENCE

MORE OPTIONS
≠
BETTER DECISION

FASTER CLICK
≠
BETTER OUTCOME

Hedef:

RIGHT CONTEXT
+
RIGHT INFORMATION
+
RIGHT TRUST
+
RIGHT EXPLANATION
+
RIGHT NEXT ACTION
=
HIGHER DECISION CONFIDENCE

§4 — Complexity Absorption​

Etkinlik sektörü doğası gereği karmaşıktır:

  • çok sayıda paydaş,
  • değişken ihtiyaçlar,
  • zaman baskısı,
  • bütçe baskısı,
  • mekan ve tedarikçi bağımlılıkları,
  • fiziksel kısıtlar,
  • operasyonel riskler,
  • sözleşme ve ödeme ilişkileri,
  • sürekli değişen bilgi,
  • kararların birbirine bağlı olması.

EventInn bu karmaşıklığı ortadan kaldırıyormuş gibi davranmaz.

EventInn’in görevi:

SEKTÖR KARMAŞIKLIĞI
→ EVENTINN İÇERİDE MODELLER
→ İNSANA KARAR İÇİN GEREKEN KISMI SUNAR

Kullanıcıya basit görünen ürün, tasarım aşamasında karmaşıklığı çözmüş üründür.

Sistem karmaşıklığını kullanıcıya form alanı, tablo, jargon veya yapı öğrenme zorunluluğu olarak geri yüklemek başarısızlıktır.

§5 — Human Decision First​

Her ürün yüzeyi, veri modelinden veya mevcut koddan değil, insanın işi ve kararıyla başlar.

İlk soru:

“Bu insan şu anda neyi başarmaya veya hangi kararı vermeye çalışıyor?”

Sonra:

  1. Hangi bilgiler bu kararı değiştirir?
  2. Hangi bilgiler yalnız ayrıntıdır?
  3. Hangi bilgiler bilinmiyor?
  4. Hangi bilgiye güvenilebilir?
  5. Hangi riskler görünür olmalıdır?
  6. Kullanıcının bir sonraki güvenli adımı nedir?
DATABASE STRUCTURE
→ UI STRUCTURE

varsayımı yasaktır.

Domain karmaşıklığını içerde korumak, kullanıcıya domain modelini öğretmek anlamına gelmez.

§6 — From Need to Outcome: kesintisiz karar zinciri​

EventInn ekran koleksiyonu değil, uçtan uca karar zinciridir.

Demand yolculuğu:

NEED
→ UNDERSTAND
→ DECIDE
→ DISCOVER
→ EVALUATE
→ COMPARE
→ SOURCE
→ NEGOTIATE
→ COMMIT
→ BOOK
→ OPERATE
→ LEARN

Supply yolculuğu:

BECOME VISIBLE
→ ESTABLISH TRUTH
→ PRESENT CAPABILITY
→ RECEIVE RELEVANT DEMAND
→ RESPOND
→ NEGOTIATE
→ WIN
→ DELIVER
→ LEARN

Organization yolculuğu:

KNOW
→ COORDINATE
→ AUTHORIZE
→ ACT
→ REVIEW
→ IMPROVE

Ürünün herhangi bir modülü bu zincirlerden kopuk değerlendirilemez.

§7 — Context is a product asset​

EventInn’de kullanıcı tekrar tekrar aynı bağlamı kurmak zorunda kalmamalıdır.

Bir etkinliğin:

  • amacı,
  • tipi,
  • tarihi,
  • katılımcı profili,
  • kapasitesi,
  • lokasyonu,
  • bütçesi,
  • zorunlu kriterleri,
  • tercihleri,
  • riskleri,
  • shortlist’i,
  • soruları,
  • teklifleri,
  • karar gerekçeleri

yolculuk boyunca mümkün olduğu ölçüde korunur.

NAVIGATION CHANGE
≠
CONTEXT LOSS

EventInn’in iyi deneyimi:

“Nerede kaldığımı ve neden burada olduğumu sistem hatırlıyor.”

hissini üretmelidir.

§8 — Decision Memory​

EventInn yalnız sonucu değil, mümkün olduğunda kararın bağlamını ve gerekçesini de koruyan sistem olmalıdır.

Önemli kararlarda şu sorular sonradan cevaplanabilmelidir:

  • Neyi seçtik?
  • Neden seçtik?
  • Hangi bilgiye dayanarak seçtik?
  • O sırada hangi bilgiler bilinmiyordu?
  • Kim karar verdi?
  • Sonradan ne değişti?

Bu yalnız audit değildir.

Bu, organizasyonların kurumsal hafızasıdır.

TRANSACTION HISTORY
≠
DECISION MEMORY

EventInn zamanla yalnız daha fazla veri değil, daha iyi karar hafızası biriktirmelidir.

§9 — Truth Architecture: Fact / Inference / Unknown​

EventInn’in güven sistemi gerçeğin türlerini birbirine karıştırmaz.

FACT
≠
INFERENCE

INFERENCE
≠
VERIFIED

UNKNOWN
≠
FALSE

NO DATA
≠
NO

SOURCE UNAVAILABLE
≠
PROPERTY UNKNOWN

AI-GENERATED
≠
TRUE

Kullanıcı bir bilginin niteliğini karar açısından gerektiği yerde anlayabilmelidir.

Bu ayrım backend metadata’sı olarak kalmamalı; kullanıcı güvenini etkilediğinde deneyimin parçası olmalıdır.

§10 — Unknown is actionable​

Bilinmeyen bilgi EventInn’de yalnız boş alan değildir.

Karar açısından önemli unknown şu ürüne dönüşür:

BİLİNMİYOR
→ NEDEN ÖNEMLİ?
→ KARARI NASIL ETKİLİYOR?
→ KİM ÇÖZEBİLİR?
→ NASIL ÖĞRENEBİLİRİZ?
→ ŞİMDİ NE YAPABİLİRSİN?

Amaç unknown göstermek değildir.

Amaç:

Belirsizliği görünür, anlaşılır ve mümkün olduğunda çözülebilir hale getirmektir.

Uzun vadeli veri üstünlüğü:

UNKNOWN DISPLAY
→ weak differentiation

UNKNOWN RESOLUTION
→ verified knowledge

VERIFIED KNOWLEDGE
→ better future decisions

BETTER FUTURE DECISIONS
→ compounding advantage

§11 — Trust is a first-class product capability​

Güven yalnız güvenlik katmanı veya rozet değildir.

Kullanıcı gerektiğinde şu soruların cevabını alabilmelidir:

  • Bu bilgi nereden geldi?
  • Ne zaman gözlendi?
  • Kim doğruladı?
  • AI mı çıkardı?
  • Mekan sahibi mi onayladı?
  • EventInn mi doğruladı?
  • Bilgi güncel mi?
  • Çelişen kaynak var mı?
TRUST
= SOURCE
+ PROVENANCE
+ FRESHNESS
+ VERIFICATION
+ EXPLANATION

EventInn’in marka sermayesinin önemli bir kısmı karar verisine duyulan güven olmalıdır.

§12 — Explainability before persuasion​

EventInn kullanıcıyı bir seçeneğe ikna etmeye çalışmadan önce nedenini açıklayabilmelidir.

Bir venue, space, supplier veya öneri için:

WHY THIS?
WHY NOT THE OTHERS?
WHAT MATCHES?
WHAT DOES NOT?
WHAT IS UNKNOWN?
WHAT IS THE RISK?

soruları gerektiğinde cevaplanabilmelidir.

Sahte kesinlik, açıklanamayan skor ve uydurma yüzdeler yasaktır.

AI SCORE
≠
EXPLANATION

RANK
≠
REASON

§13 — Hard constraints, preferences and trade-offs​

EventInn kullanıcı tercihleri ile zorunlu gereksinimleri birbirine karıştırmaz.

HARD CONSTRAINT
≠
SOFT PREFERENCE
≠
UNKNOWN

Bir zorunlu gereksinim ihlali, yüksek soft skorla gizlenemez.

Bir near-fit öneri gösteriliyorsa:

  • hangi gereksinime uymadığı,
  • neden yine de gösterildiği,
  • kullanıcının bu trade-off’u kabul edip etmeyeceği

anlaşılır olmalıdır.

EventInn’in görevi kullanıcı adına gizlice karar vermek değil, trade-off’u görünür kılmaktır.

§14 — Progressive Disclosure​

Profesyonel etkinlik kararı çok veri gerektirir.

İyi UX bu veriyi yok etmek değil, doğru sıraya koymaktır.

FIRST GLANCE
→ karar yönü

NEXT LAYER
→ karar kanıtı

DEEPER LAYER
→ profesyonel ayrıntı

Kullanıcı her şeyi aynı anda görmek zorunda değildir.

Ama ihtiyaç duyduğunda detay kaybolmamalıdır.

Sadelik, fakirlik değildir.

§15 — Next Best Action​

EventInn yalnız durum gösteren değil, doğru sonraki adımı görünür kılan sistem olmalıdır.

Her kritik durumda:

“Şimdi ne yapmalıyım?”

sorusunun cevabı olmalıdır.

Örnek sınıflar:

NO RESULT
UNKNOWN
PARTIAL DATA
STALE DATA
UNVERIFIED
WAITING
CONFLICT
PERMISSION DENIED
ERROR

Bu durumların hiçbiri kullanıcıyı açıklamasız çıkmaz sokağa bırakmamalıdır.

§16 — Recovery is part of the happy path​

Profesyonel iş akışlarında hata istisna değil, normaldir.

Kullanıcı:

  • yanlış seçim yapabilir,
  • yanlış venue açabilir,
  • bir belge eksik olabilir,
  • teklif değişebilir,
  • tarih değişebilir,
  • kişi yetkisini kaybedebilir,
  • sağlayıcı veri vermeyebilir,
  • sistem bir çıkarımda yanılabilir.

İyi EventInn:

ERROR
→ EXPLAIN
→ PRESERVE CONTEXT
→ SHOW RECOVERY
→ CONTINUE

davranır.

Bir hatadan sonra kullanıcıyı başlangıç noktasına döndürmek deneyim borcudur.

§17 — Collaboration without coordination tax​

EventInn bireysel kullanıcı deneyiminin yanında çok-aktörlü karar deneyimi tasarlamalıdır.

Etkinlikler:

  • ekipler,
  • müşteriler,
  • mekanlar,
  • tedarikçiler,
  • yöneticiler,
  • finans,
  • operasyon

arasında yürür.

Ürün şu soruları doğal biçimde çözmelidir:

WHO KNOWS?
WHO DECIDES?
WHO OWNS?
WHO MUST RESPOND?
WHAT CHANGED?
WHAT IS WAITING?

Amaç daha fazla bildirim üretmek değil, koordinasyon vergisini azaltmaktır.

§18 — Role-specific experience, shared truth​

Planner, Venue Owner, Supplier, Agency, Organization Owner ve Platform Operator aynı sistemi farklı zihinsel modellerle yaşar.

SAME ENTITY
≠
SAME EXPERIENCE

Ancak farklı yüzeyler farklı gerçeklikler üretmemelidir.

ROLE-SPECIFIC VIEW
+
SHARED UNDERLYING TRUTH

temel ilkedir.

Bir tarafın güncellediği önemli gerçek, diğer tarafın karar bağlamında gerektiği yerde güvenli ve anlaşılır biçimde görünmelidir.

§19 — AI is a contextual co-pilot, not an invisible authority​

AI EventInn’in ayrı bir gösteri özelliği değil, gerektiğinde ürünün içine gömülü karar yardımcısıdır.

AI şunları yapabilir:

  • niyeti anlamlandırmak,
  • dağınık veriyi yapılandırmak,
  • seçenekleri açıklamak,
  • önemli unknown’ları bulmak,
  • karşılaştırmayı özetlemek,
  • tutarsızlıkları göstermek,
  • bir sonraki adımı önermek,
  • profesyonel iş yükünü azaltmak.

Ama:

AI MAY PROPOSE
≠
AI MAY SILENTLY DECIDE

AI MAY INFER
≠
AI MAY PRESENT AS FACT

AI MAY AUTOMATE
≠
AI MAY REMOVE HUMAN CONTROL

Önemli karar ve değişikliklerde kullanıcı gerektiğinde:

  • AI’nın ne yaptığını,
  • hangi veriye dayandığını,
  • neyin öneri olduğunu,
  • neyin uygulanacağını

anlayabilmelidir.

§20 — Proactive, not intrusive​

Gelecekte EventInn yalnız kullanıcı komutlarını bekleyen pasif yazılım olmamalıdır.

Sistem bağlama göre:

  • risk yaklaşınca,
  • önemli veri eskiyince,
  • kritik bilgi eksikken,
  • teklif gecikince,
  • karar sıkışınca,
  • uygun fırsat ortaya çıkınca

kullanıcıya yardımcı olabilir.

Ancak proaktivite:

HELPFUL
≠
NOISY

ANTICIPATORY
≠
MANIPULATIVE

AUTOMATED
≠
UNACCOUNTABLE

olmalıdır.

Kullanıcı kontrolünü ve güvenini azaltan “akıllılık” ürün başarısı değildir.

§21 — From workflows to an Event Graph​

EventInn’in uzun vadeli değeri ayrı modüllerin toplamından daha büyük olmalıdır.

Etkinlik bağlamında:

PEOPLE
ORGANIZATIONS
EVENTS
VENUES
SPACES
SUPPLIERS
REQUIREMENTS
PROPOSALS
CONTRACTS
PAYMENTS
DECISIONS
OUTCOMES

birbirinden kopuk kayıtlar değil, ilişkili bir karar ağı oluşturur.

Bu ağ kullanıcıya teknik graph olarak gösterilmek zorunda değildir.

Ama sistem:

“Bu değişiklik kimi, hangi kararı ve hangi sonraki adımı etkiliyor?”

sorusunu zamanla daha iyi cevaplayabilmelidir.

§22 — Learning product, not static software​

EventInn gerçek kullanımdan öğrenmelidir.

Ama öğrenme yalnız conversion optimizasyonu değildir.

Sistem zamanla şunları daha iyi anlamalıdır:

  • hangi bilgiler karar için gerçekten önemli,
  • hangi unknown’lar işleri bloke ediyor,
  • hangi venue/supplier verileri sürekli sorun çıkarıyor,
  • hangi karşılaştırmalar kullanıcıya yardımcı oluyor,
  • hangi süreçler gereksiz sürtünme yaratıyor,
  • hangi kararlar sonradan değişiyor ve neden.
USE
→ EVIDENCE
→ LEARNING
→ BETTER PRODUCT
→ BETTER DECISIONS

Ancak öğrenme gizlilik, yetki ve açıklanabilirlik sınırlarını aşamaz.

§23 — Outcome over engagement​

EventInn’in amacı kullanıcıyı üründe daha uzun tutmak değildir.

Başarı:

  • daha hızlı doğru shortlist,
  • daha az karar belirsizliği,
  • daha az tekrar iş,
  • daha az koordinasyon kaybı,
  • daha güvenilir sourcing,
  • daha yüksek kaliteli teklif,
  • daha net karar,
  • daha az operasyonel hata,
  • daha güçlü kurumsal hafıza

üretmektir.

TIME IN APP ↑
≠
SUCCESS

TASK COMPLETION
+
DECISION CONFIDENCE
+
OUTCOME QUALITY
=
BETTER SUCCESS SIGNAL

§24 — Experience is business architecture​

Kullanıcı deneyimi, kod bittikten sonra yapılan görsel düzenleme değildir.

UX kararları şunları etkiler:

  • hangi veri toplanır,
  • hangi veri önce gelir,
  • hangi bilgi doğrulanmalıdır,
  • kullanıcı ne zaman aksiyon alır,
  • kim neyi görebilir,
  • marketplace nasıl çalışır,
  • hangi unknown çözülür,
  • hangi data loop oluşur.

Bu nedenle:

EXPERIENCE DESIGN = BUSINESS SYSTEM DESIGN

olarak değerlendirilir.

§25 — Global quality, domain-native intelligence​

EventInn küresel ürünlerden öğrenir; onları kopyalamaz.

Amaç:

  • Airbnb kadar anlaşılır discovery,
  • Linear kadar güçlü context preservation,
  • Stripe kadar net state/action,
  • Shopify kadar karmaşıklığı saklayan operasyon deneyimi,
  • Cvent kadar profesyonel sourcing derinliği

gibi kalite özelliklerini etkinlik sektörünün kendi karar gerçeklerine tercüme etmektir.

REFERENCE
→ PATTERN
→ HUMAN PROBLEM
→ EVENTINN TRANSLATION

REFERENCE
≠
COPY

EventInn’in farkı yalnız UI kalitesi değil, etkinlik alanına özgü karar zekâsıdır.

§26 — Mobile, accessibility and inclusivity are product architecture​

Mobil ve accessibility sonradan eklenecek kalite işleri değildir.

Gerçek etkinlik profesyonelleri:

  • mekanda,
  • yolda,
  • toplantıda,
  • sahada,
  • düşük bağlantıda,
  • farklı cihazlarda

çalışır.

Bu nedenle önemli capability’ler:

  • mobil bilgi önceliği,
  • touch davranışı,
  • keyboard/focus,
  • screen-reader,
  • açık hata dili,
  • düşük bağlantıda dayanıklılık

gibi şartlarla birlikte düşünülür.

§27 — No dark patterns, no fake confidence​

EventInn güven kazanarak büyümelidir.

Yasak deneyimler:

  • sahte aciliyet,
  • sahte kıtlık,
  • uydurma popularity,
  • kaynaksız “recommended”,
  • gizli ücret,
  • gizli opt-in,
  • manipülatif sıralama,
  • açıklanmayan sponsor etkisi,
  • uydurma doğrulama,
  • sahte kesinlik.
PERSUASIVE DESIGN
MUST NOT OVERRIDE
TRUTHFUL DESIGN

§28 — Product Handbook is the target product contract​

Normal sıra:

CODE
→ PRODUCT
→ MANUAL

EventInn’de tersine çevrilir:

PRODUCT HANDBOOK
→ EXPERIENCE DEFINITION
→ IMPLEMENTATION BASELINE
→ CODE
→ REAL LEARNING

Product Handbook:

  • son kullanıcı yardım metni değildir,
  • Canon değildir,
  • current-state defteri değildir.

Product Handbook:

gelecekte satın almak isteyeceğimiz EventInn’in insan tarafından okunabilen hedef ürün modelidir.

§29 — Master Map keeps the whole system visible​

Product Handbook detaylanırken büyük resim kaybolmamalıdır.

Master Map her zaman:

  • journey,
  • persona,
  • capability,
  • upstream/downstream ilişki,
  • current active area,
  • customer outcome

arasındaki bağlantıyı görünür tutar.

Her önemli ürün çalışmasında şu sorular cevaplanabilmelidir:

WHERE ARE WE?
WHO ARE WE HELPING?
WHAT HUMAN JOB?
WHAT CUSTOMER OUTCOME?
WHAT COMES BEFORE?
WHAT COMES AFTER?
HOW DOES THIS MOVE THE WHOLE SYSTEM?

§30 — Whole-product first, active-slice deep​

EventInn geleceğin bütün ekranlarını bugünden çözmeye çalışmaz.

Ama ürünün tamamı görünür olmalıdır.

WHOLE PRODUCT
= enough detail to understand
  journeys
  capabilities
  relationships
  value flow

ACTIVE PRODUCT SLICE
= enough depth that
  developers do not invent
  fundamental product decisions

Bu nedenle:

Bütünde geniş, aktif dilimde derin.

§31 — Planning depth belongs to Human CEO​

Product planning bir checklist tamamlandı diye otomatik bitmez.

Müdür ve AI-CEO:

IMPLEMENTATION-READY

sinyali verebilir.

Ama:

IMPLEMENTATION-READY
≠
PLANNING STOP

Planlama derinliğinin sahibi Human CEO’dur.

Human CEO planlamayı durdurduğunda exact baseline freeze edilir.

§32 — Depth ≠ Scope​

Bir ürün davranışını daha iyi düşünmek otomatik scope expansion değildir.

Örneğin:

  • provenance,
  • error recovery,
  • unknown,
  • microcopy,
  • mobile,
  • accessibility,
  • trust,
  • information hierarchy

aynı feature’ın derinliği olabilir.

DEPTH ↑
≠
SCOPE ↑

Yeni ekonomik capability, yeni persona veya yeni bağımsız journey ise gerçek scope artışı olabilir.

§33 — Target can evolve; it cannot drift silently​

Product target dogma değildir.

Gerçek kullanım:

  • varsayımı çürütebilir,
  • yeni problem gösterebilir,
  • kullanıcının farklı davrandığını kanıtlayabilir.

Bu durumda target değişebilir.

Ama:

CODE CANNOT SILENTLY CHANGE PRODUCT INTENT

REAL LEARNING MAY CHANGE PRODUCT INTENT

Target değişimi ürün kararı olarak görünür olmalıdır.

Varsayım yoğun hedefler gerektiğinde BET olarak işaretlenebilir.

§34 — Target ≠ Actual​

EventInn iki gerçekliği hiçbir zaman karıştırmaz.

TARGET​

Ne inşa etmek istiyoruz?

ACTUAL​

Bugün gerçekte ne var?

TARGET
≠
ACTUAL

Handbook TARGET’ı insan tarafından yazılır.

ACTUAL mümkün olduğu ölçüde:

  • Canon lifecycle,
  • implementation/package state,
  • independent Verify,
  • production evidence

üzerinden projekte edilir.

NO EVIDENCE
→ UNKNOWN

STALE EVIDENCE
→ STALE

Manual optimistic state writing yasaktır.

§35 — Experience acceptance​

Teknik olarak çalışan özellik ürün olarak başarısız olabilir.

TECHNICALLY CORRECT
≠
PRODUCT ACCEPTABLE

Feature acceptance:

FUNCTIONAL PASS
+
SECURITY / SAFETY PASS
+
HUMAN EXPERIENCE PASS
=
FEATURE ACCEPTABLE

Human Experience Pass en az şu soruları cevaplar:

  1. Kullanıcı ne yapmak istediğini anlayabiliyor mu?
  2. Karar için önemli bilgi görünür mü?
  3. Bilginin güven seviyesi gerektiğinde anlaşılır mı?
  4. En önemli sonraki aksiyon açık mı?
  5. Gereksiz bilişsel yük var mı?
  6. Unknown/error durumunda toparlanabiliyor mu?
  7. Bağlamını kaybetmeden ilerleyebiliyor mu?
  8. Başarıyla tamamladığını anlayabiliyor mu?

Bu ayrı bir approval töreni değildir; ürün kabulünün içsel boyutudur.

§36 — Scenario before confidence​

Ürün hakkında “iyi çalışıyor” demek için yalnız test veya ekran yeterli değildir.

Kanıt dili ayrılır:

SCENARIO WALKTHROUGH
(seed/simulated)

≠

DOGFOOD
(real internal case)

≠

LIVE HUMAN SCENARIO
(real external/user behavior)

İddia kanıt seviyesini aşamaz.

§37 — The three living product surfaces​

EventInn’in bu doktrini üç yaşayan ürün yüzeyinde uygulanır:

MASTER MAP
= bütün sistemi gör

PRODUCT HANDBOOK
= hedef ürünü tarif et

ACTIVE EXPERIENCE PACK
= aktif parçayı derinleştir

Bunlar yeni bureaucracy ailesi değildir.

Benchmark, UX audit, prototype, scenario, dogfood, measurement ve research bu yüzeylerin içinde kullanılan yöntemlerdir.

§38 — Main Mission Lock​

Ürün geliştirme sırasında yeni teknik ayrıntılar ana görevi ele geçirmemelidir.

MAIN PRODUCT MISSION
=
MASTER MAP
+ PRODUCT HANDBOOK
+ HUMAN EXPERIENCE

Yeni teknik bulgu:

TECHNICAL FINDING
→ relevant product constraint/input
→ supporting engineering work
→ RETURN TO MAIN PRODUCT MISSION

Yalnız security, legal, irreversible-data veya benzeri gerçek blocker ilgili ürün dilimini durdurabilir.

Alt seviye bir teknik problem bütün ürün düşüncesinin yönünü belirleyemez.

§39 — EventInn’s long-term moat​

EventInn’in uzun vadeli savunulabilir avantajı yalnız AI, UI veya katalog büyüklüğü değildir.

Moat şu birleşimden doğmalıdır:

DOMAIN DEPTH
+
TRUSTED DATA
+
DECISION MEMORY
+
RESOLVED UNKNOWNS
+
WORKFLOW CONTEXT
+
MARKETPLACE RELATIONSHIPS
+
REAL OUTCOME LEARNING

Rakipler ekranı kopyalayabilir.

Ancak yıllar içinde:

  • doğrulanmış domain verisi,
  • gerçek karar bağlamları,
  • outcome ilişkileri,
  • güven geçmişi,
  • ekip davranışı,
  • çözülmüş unknown’lar

birikirse EventInn’in karar altyapısı daha zor kopyalanır hale gelir.

§40 — Nihai ürün sözü​

EventInn’in ideal deneyiminde kullanıcı:

“Sistem benden daha fazla şey istemiyor; benim için daha fazla şeyi anlamlandırıyor.”

“Bana yalnız seçenek göstermiyor; karar vermeme yardım ediyor.”

“Bilmediğini saklamıyor.”

“Neden önerdiğini açıklıyor.”

“Bağlamımı kaybetmiyor.”

“Ekibimle aynı gerçeğe bakmamı sağlıyor.”

“Bir sonraki doğru adımı görünür kılıyor.”

“Ben kullandıkça yalnız veri değil, daha iyi karar bilgisi biriktiriyor.”

EventInn’in ürün kültürü:

COMPLEXITY INSIDE
CLARITY OUTSIDE

TRUTH BEFORE CONFIDENCE
CONTEXT BEFORE CONTENT
DECISION BEFORE SCREEN
OUTCOME BEFORE ENGAGEMENT
EXPLANATION BEFORE PERSUASION
RECOVERY BEFORE DEAD-END
HUMAN CONTROL BEFORE AUTOMATION

WHOLE PRODUCT VISIBLE
ACTIVE EXPERIENCE DEEP

Ve ana geliştirme sırası:

UNDERSTAND THE HUMAN
→ DEFINE THE TARGET PRODUCT
→ PRESERVE THE WHOLE PICTURE
→ DEEPEN THE EXPERIENCE
→ FREEZE THE INTENT
→ IMPLEMENT
→ OBSERVE REALITY
→ LEARN
→ IMPROVE THE TARGET

EventInn’in geleceği daha fazla özellik üretmekte değil; etkinlik üretiminin karmaşık gerçekliğini insanların daha iyi karar verebildiği sade, güvenilir ve öğrenen bir çalışma sistemine dönüştürmektedir.

REVISION DELTA — v1 → v2

Bu revizyonda özellikle:

  1. Supply Bootstrap / Acquisition Engine gibi dönemsel ilk uygulama hükümleri Canon’dan çıkarılmıştır.
  2. “UX ilkeleri” seviyesi, karar güveni ve çalışma sistemi vizyonuna yükseltilmiştir.
  3. Decision Memory yeni kalıcı ürün ilkesi olarak eklenmiştir.
  4. Collaboration / coordination tax ürün felsefesine eklenmiştir.
  5. AI co-pilot / human control sınırı güçlendirilmiştir.
  6. Proactive but not intrusive gelecek vizyonu eklenmiştir.
  7. Event Graph uzun vadeli ürün mimarisi olarak, implementation dikte etmeden tanımlanmıştır.
  8. Outcome over engagement ölçüm felsefesi eklenmiştir.
  9. Experience = business architecture açık hükme dönüştürülmüştür.
  10. Global quality + domain-native intelligence ürün iddiası güçlendirilmiştir.
  11. Main Mission Lock teknik ayrıntıların ürün ana görevini ele geçirmesini önleyen kalıcı ilke olarak eklenmiştir.
  12. Uzun vadeli moat, AI özelliği yerine trusted data + decision memory + context + learning birleşimi olarak tanımlanmıştır.
  13. TARGET / ACTUAL, planning authority, depth/scope ve evidence-first ilkeleri korunmuştur.
  14. Master Map + Product Handbook + Active Experience Pack üçlüsü korunmuş; fakat bunların governance töreni değil yaşayan ürün yüzeyleri olduğu daha netleştirilmiştir.

CEO İÇİN KISA AÇIKLAMA

Bu revizyon Canon’u “iyi bir arayüz nasıl yapılır?” belgesi olmaktan çıkarıp “EventInn gelecekte nasıl bir ürün olmalıdır?” anayasasına dönüştürüyor.

Yeni merkez kavram Decision Confidence — karar güveni. EventInn’in başarısı kullanıcının daha fazla ekran görmesi değil; ne bildiğini, neyi bilmediğini, seçeneklerin neden uygun olduğunu, riskleri ve bir sonraki doğru adımı anlayabilmesidir.

Ayrıca dönemsel “ilk önce şu motoru yapalım” gibi kararlar Canon’dan çıkarılmıştır. Çünkü bunlar değişebilir. Canon’un görevi yıllarca değişmeden kalabilecek ürün karakterini korumaktır: karmaşıklığı içeride çözmek, gerçeği ve çıkarımı ayırmak, bağlamı korumak, bilinmeyeni çözülebilir hale getirmek, AI’yı insan kontrolünde kullanmak, ekip koordinasyonunu kolaylaştırmak ve gerçek kullanımdan öğrenerek zamanla daha iyi karar sistemi olmak.

En önemli yeni korumalardan biri de Main Mission Lock: yeni teknik bulgular ürün ana çalışmasını artık ele geçirmemelidir. Teknik konu kendi şeridinde çözülür; Master Map, Product Handbook ve insan deneyimi ana tren olarak devam eder.