Grafik Tasarım
Kimlik Doğrulama Ürün Spesifikasyonu Tasarımı
Bir Northwind iki faktörlü kimlik doğrulama önerisi; sahipliği, kapsamı, kullanıcı hikâyelerini, dört örnek hedefi, yayına alma aşamalarını ve çözümlenmemiş kararları birbirine bağlar.
Ürün Spesifikasyonu Kullanım Senaryoları
- Ürün Spesifikasyonu YazarlarıKimlik doğrulama gereksinimlerini sıralı bir teslimat özetine dönüştürün.
- Kimlik Platformu EkipleriGüvenlik kontrollerini, yayına alma aşamalarını ve çözümlenmemiş uygulama kararlarını birbirine bağlayın.
- Ürün ve Tasarım LiderleriSahipliği, kapsamı, ölçütleri ve kullanıcıya dönük kimlik doğrulama önceliklerini uyumlu hâle getirin.
- Kurumsal Hazırlık EkipleriMüşteri güvenliği engellerini benimseme ve destek hususlarıyla birlikte çerçeveleyin.
Kimlik Doğrulama Özetiyle İlgili Öne Çıkanlar
- Problemin ÇerçevelenmesiKurumsal inceleme engellerini kimlik doğrulama açığıyla ilişkilendirir.
- Açık KapsamÖnerilen lansman hedeflerini bilinçli olarak ertelenen işlerden ayırır.
- Yayına Alma HedefleriAmaçlanan sonuçları örnek hedefler ve dört yayına alma aşamasıyla eşleştirir.
- Atanmış SorularÇözümlenmemiş politika kararlarını sorumluları ve tarihleriyle görünür tutar.
Bölüm Bölüm Ürün Spesifikasyonu
1 / 6
Northwind 2FA Özeti
Bu resmî OpenDesign örneği, Northwind uygulamasındaki iki faktörlü kimlik doğrulama için hazırlanmış açıklayıcı bir ürün spesifikasyonudur. Açılış bölümü belgeyi Draft v0.4 olarak tanımlar; belge sahibini, güncelleme tarihini ve dört incelemeciyi belirtir, ardından öneriyi açıklar: oturum açma akışına TOTP ve güvenlik anahtarı faktörleri eklemek.
Görsel kompozisyon, bu talebi planlama ayrıntılarından önce sunar. Bir meta veri satırında ekip olarak Identity Platform, mühendislik lideri olarak Priya Banerjee, tasarım lideri olarak Sasha Lin, hedef yayın tarihi olarak End Q4 (Dec 18) ve tahmini efor olarak ~6 eng-weeks belirtilir. Bu sıralama, okuyucunun problemi okumadan önce sahipliği ve teslimat baskısını anlamasını sağlar.
Ardından Problem bölümü, önerinin varlık nedenini ortaya koyar. Son altı kurumsal güvenlik incelemesinin üçünde ikinci faktör eksikliğinin işaretlendiğini açıklar ve sonrasında Pioneer Robotics'ten Maya Reddy'nin ayrı bir alıntısına yer verir. Bu alıntı, daha geniş güvenlik gerekçesinin yerini almadan ticari baskıyı anlaşılır kılar.
Üç Kimlik Doğrulama Akışı
Örnek User Stories bölümü üç görevi tanımlar: bir çalışma alanı yöneticisi, belirtilen bir kontrol incelemesi hedefi için 2FA'yı zorunlu kılmak ister; günlük kullanıcı, TOTP kaydını iki dakikadan kısa sürede tamamlamak ister; destek mühendisi ise ikinci faktörü devre dışı bırakmayan bir kurtarma yolu ister. Bunlar belgedeki planlama gereksinimleridir; kimlik doğrulamanın çalıştığına veya uyumluluğun sağlandığına dair kanıt değildir.
Bu hikâyeler, her cümlede persona ifadesi vurgulanacak şekilde numaralandırılmış üç yatay satır olarak sunulur. Tekrarlanan bu yapı, sorumluluk farklılıklarını karşılaştırmayı kolaylaştırırken “so that” ifadesi her talebin ardındaki operasyonel gerekçeyi korur.
Sıralama ayrıca bir tasarım ödünleşimini de ortaya koyar. Yönetim önce gelir çünkü çalışma alanı düzeyinde zorunlu kılma, politika yüzeyini tanımlar; kayıt daha sonra gelir çünkü üyenin yapacağı ilk işlem budur; kurtarma desteği ise istisna yolunu tanımladığı için son sıradadır. Dolayısıyla belge, güvenliği yalnızca bir oturum açma ekranı olarak değil, paylaşılan bir sistem olarak ele alır.
Çalışma Alanı Yöneticisi
Bir kontrol incelemesini desteklemek için tüm üyelerde 2FA'yı zorunlu kılar.
Günlük Kullanıcı
Normal iş akışından ayrılmadan hızla bir TOTP uygulamasını eşleştirir.
Destek Mühendisi
Ek güvenlik kontrolünü zayıflatmadan kurtarma sürecine yardımcı olur.
Hedefler, Ölçütler ve Aşamalar
Belgenin orta bölümü kapsamdan değerlendirmeye, ardından teslimata ilerler. “Goals & non-goals”, TOTP, WebAuthn, çalışma alanı düzeyinde zorunlu kılma, kurtarma kodları ve denetim kayıtlarını; SMS, SSO'nun değiştirilmesi, işlem bazında ek doğrulama ve beyaz etiketli dağıtımlar için özelleştirilmiş marka dili gibi kapsam dışı işlerden ayırmak için onay ve çarpı simgelerini kullanır.
Bu ayrım kullanışlıdır çünkü önerinin her kimlik doğrulama talebini bu lansmanın bir parçası olarak ele almasını önler. Authy, 1Password ve Google Authenticator için belirtilen destek, TOTP hedefine somut bir sınır getirirken WebAuthn yalnızca Enterprise planlarıyla sınırlıdır. Ödünleşim, bilinçli bir kapsam seçimidir: spesifikasyon, ilişkili kimlik çalışmalarını ayrı tutarken açıkça tanımlanmış bir ilk sürüm elde eder.
Success Metrics tablosu dört örnek planlama satırı içerir: önü açılan anlaşmalar (3'te 3), ücretli çalışma alanlarında benimseme (en az %60), son 30 günlük hesap ele geçirme olayları (en fazla 1) ve kurtarma kaynaklı destek yükü (taleplerin %1,5'inden azı). Bunlar ölçülmüş sonuçlar değil, hedeflerdir. Benimseme formülü, tekil üye tekrarlarını ayıklama yöntemini tanımlamadan kayıt olaylarını DAU'ya böler; olay başlangıç değeri ise “4 last quarter” ifadesini kullanır. Bu tablonun gerçek bir lansmanı ölçebilmesi için zaman aralıkları ve sayım kurallarının uzlaştırılması gerekir.
Rollout Milestones, bu ölçütleri bayrakla işaretlenmiş dört aşamaya dönüştürür: TOTP kaydı, oturum açma akışı, yönetici tarafından zorunlu kılınan WebAuthn ve GA ile iletişim çalışmaları. Her aşama bir efor tahmini ve somut içerikler listeler; böylece okuyucu hangi kararların ayarları, oturum açmayı, politikayı ve destek materyallerini etkilediğini görebilir.
| Metrik | Başlangıç Değeri | Hedef (90 Gün) | Ölçüm Yöntemi |
|---|---|---|---|
| 2FA açığı nedeniyle bekleyen kurumsal anlaşmaların önünün açılması | 3'te 0 | 3'te 3 | Satış süreci notları + imzalanmış sözleşme sayısı |
| Üyelerin 2FA'yı benimsemesi (ücretli çalışma alanları) | n/a | ≥ %60 | auth.factor_enrolled olayları / DAU |
| Hesap ele geçirme olayları (son 30 gün) | geçen çeyrekte 4 | ≤ 1 | Güvenlik olayı takip sistemi (SEV-3+) |
| 2FA kurtarmasından kaynaklanan destek yükü | n/a | Taleplerin %1,5'inden azı | Zendesk'te auth-2fa etiketi |
Hâlâ Açık Olan Kararlar
Son bölüm, spesifikasyonu tamamlanmış bir uygulama gibi sunmak yerine belirsizliği görünür tutar. Üç soru 28, 29 ve 30 Ekim tarihlerinde Devon Park, Priya Banerjee ve Sasha Lin'e atanmıştır: üyelerin TOTP ile güvenlik anahtarları arasında seçim yapıp yapamayacağı, güvenilir cihaz çerezinin ne kadar süreyle geçerli olması gerektiği ve yöneticinin bir üyenin 2FA durumunu nerede görebileceği.
Bu, kilometre taşı sıralamasının anlamlı bir tamamlayıcısıdır. Yayına alma planı güvenilir cihaz çerezini ve yönetici tarafından zorunlu kılmayı belirtir; ancak açık sorular, bunların politika ayrıntılarının belgede kesinleşmediğini gösterir. Bu soruları sorumlular ve tarihlerle birlikte tutmak, ekibe belirtilen 31 Ekim son tarihine bağlı bir karar kuyruğu sunar.
Faktör Seçimi
Üyelerin bir faktör seçip seçmeyeceğine veya mevcut en güçlü faktörün kendilerine atanıp atanmayacağına karar verin.
Güvenilir Cihaz
Güvenilir cihaz çerezinin geçerlilik süresi politikasını kesinleştirin.
Yönetici Görünürlüğü
Kullanıcı listesindeki durum ile denetim günlüğü görünürlüğü arasında seçim yapın.
OpenDesign'da Kimlik Doğrulama Ürün Spesifikasyonu Tasarımı Nasıl Oluşturulur?
Kimlik Doğrulama Problemini Çerçeveleyin
Ürün talebi, etkilenen hedef kitle ve somut güvenlik ya da ticari baskıyla başlayın. Bu ayrıntılar biliniyorsa ekip, sorumlular, hedef yayın tarihi ve efor bilgilerini içeren kompakt bir sahiplik satırı ekleyin.
Kapsamı ve Ölçütleri Tanımlayın
Önerilen lansman hedeflerini hedef dışı maddelerden ayırın, ardından başlangıç değerlerini, hedefleri ve ölçüm yöntemlerini ekleyin. Planlama değerlerini doğrulanmış sonuçlardan ayrı tutun; örnek formülleri uyarlamadan önce raporlama dönemleri ile tekil kullanıcı sayımını uyumlu hâle getirin.
Önerilen PromptTaslak başlığı, sahiplik satırı, Problem bölümü, Goals and Non-goals, dört sütunlu Success Metrics tablosu, numaralandırılmış üç User Stories maddesi, tarihli dört Rollout Milestones aşaması ve sorumluları atanmış Open Questions içeren Northwind tarzı bir iki faktörlü kimlik doğrulama ürün spesifikasyonu oluştur. TOTP, Enterprise WebAuthn, çalışma alanı düzeyinde zorunlu kılma, kurtarma kodları, denetim kayıtları ve belirtilen yetenek sınırlarını göster; canlı hizmetler veya ölçülmüş sonuçlar bulunduğu izlenimini verme.
Karar Sırasını Kontrol Edin
Belgeyi bir planlama akışı olarak gözden geçirin: problem, kapsam, metrikler, kullanıcı hikâyeleri, kilometre taşları ve açık sorular. Her kilometre taşının somut içeriklere sahip olduğunu ve çözümlenmemiş politika ayrıntılarının kesinleşmiş davranışlar gibi sunulmak yerine görünür kaldığını doğrulayın.
Dışa Aktarın ve Paylaşım Bağlantısı Alın
Bitmiş tasarımınızı dışa aktarın, ardından bir paylaşım bağlantısı almak için OpenDesign'daki Paylaş seçeneğini kullanın. Bağlantıyı göndermeden önce ayrı bir tarayıcı penceresinde açarak amaçlanan sürümün ve bileşenlerinin erişilebilir olduğunu doğrulayın.
Yapay Zeka İş Akışı Editoryal Poster Tasarımı
Yapay Zeka İş Akışı Editoryal Poster Tasarımı, örneklerle açıklanan altı iş akışı iddiasını numaralı bölümler, somut istem örnekleri ve krem-pas rengi tipografiyle sunar.
Grafik Tasarım
Yapay Zekâ İş Akışı Sosyal Medya Karusel Tasarımı
Yedi dikey kart; iri Çince başlıklar, numaralı alışkanlıklar, değişen renk alanları ve kapanış cümlesiyle yapay zekâ düzenleme iş akışlarını anlatıyor.
Grafik Tasarım
Aurora Field Gölgelendirici Tasarımı
Otomatik animasyonlu mavi-yeşil gürültü alanı, bir WebGL hero alanına atmosfer kazandırırken sabit başlık ve küçük yerel kare hızı rozeti sahneyi sabitler.
Grafik Tasarım
Aurora Veil Gölgelendirici Tasarımı
Aurora Veil; katmanlı ışığı, yıldızları ve imleç hareketini atmosferik bir WebGL hero alanına dönüştüren etkileşimli bir gölgelendirici kompozisyonudur.
Grafik Tasarım