Prototip Spesifikasyonu: Neyi Yazmalı, Neyi Yazmamalı

Prototipi ekiple paylaştığınız anda sorular başlar: bu butona basınca ne oluyor, metin sığmazsa ne görünüyor, liste boşken ekranda ne yazıyor? Spesifikasyon bu cevapları tek yerde toplar. Ama her şeyi yazmak belgeyi kısa sürede bakım yüküne çevirir, o yüzden asıl karar neyi yazmadığınızdır.

Tasarım dosyasının zaten söylediğini tekrar yazmayın

Element düzeyindeki bilgiyi (yazı tipi, renk kodu, ölçü, boşluk) Figma, Axure ve Zeplin gibi araçlar zaten doğrudan veriyor. Aynı değerleri bir de belgeye kopyaladığınızda ortaya ikinci bir doğruluk kaynağı çıkar ve bu ikisi ilk tasarım revizyonunda ayrışır. Belgede 16 piksel yazarken dosyada 20 piksel duruyorsa geliştirici hangisine bakacağını sormak için size gelir, yani belgenin ortadan kaldırmak için yazıldığı soruyu belge üretmiş olur.

Ölçüleri, renkleri ve boşlukları genelde dosyanın kendisine bırakırım; spesifikasyona yalnızca dosyaya bakarak çıkarılamayan şeyleri yazarım.

Asıl belirsizlik durumlarda saklı

Tasarım dosyası bir ekranın tek bir anını gösterir. Geliştiricinin yazması gereken şey ise o ekranın bütün halleridir. Basit bir form alanını düşünün: boş ya da dolu, geçerli ya da hatalı, odaklı ya da odaksız, etkin ya da devre dışı. Dört ikili nitelik on altı kombinasyon demektir ve tasarım dosyasında bunların genellikle ikisi ya da üçü çizilidir. Kalan on üçünü ya siz tarifleyeceksiniz ya da geliştirici kendi kararıyla dolduracak.

Fonksiyonellik spesifikasyonunda gerçekten iş gören maddeler şunlar:

• Butona basıldıktan sonra yanıt gelene kadar arayüzün hali
• Karakter sınırı aşıldığında girdinin davranışı: kesiliyor mu, uyarı mı veriyor, kaydetmeyi mi engelliyor
• Sunucu hatası, boş sonuç ve yavaş bağlantı durumlarında ne gösterileceği
• Geri dönüldüğünde formun doldurulmuş verisinin korunup korunmayacağı

Genişlik sorusunun kodda karşılığı yok, taşma sorusunun var

“Bu alanın maksimum genişliği var mı?” sorusu CSS'te tek satırla cevaplanır, dolayısıyla üzerinde uzun uzun konuşmaya değmez. Cevaplanması gereken soru bir sonrakidir: metin o genişliğe sığmadığında ne olacak? Alt satıra mı sarılacak, üç noktayla mı kesilecek, kutu mu büyüyecek? Üçü de farklı bir düzen davranışı üretir ve üçü de tasarımda aynı görünür, çünkü tasarımda metin hep tam sığacak uzunlukta seçilmiştir.

Aynı sorunun sinsi hali çok dilli projelerde ortaya çıkar. Türkçe bir etiketin Almancası ortalama olarak belirgin biçimde uzar; sekiz karakterlik bir buton metni için çizilmiş sabit genişlik, çeviri geldiğinde düzeni bozar.

Metni yazmazsanız geliştirici yazar

İçerik spesifikasyonunun tek gerekçesi bu. Hata mesajı, boş durum metni, onay ekranındaki cümle tasarımda belirtilmemişse arayüze mutlaka bir şey girecek ve bu genelde “Bir hata oluştu” olacaktır. Kullanıcı hangi alanı düzelteceğini anlamadığı için destek kaydı açar, siz de aynı metni üç ay sonra acil iş olarak düzeltirsiniz. Doğrusunu ilk seferde yazmak birkaç dakika sürüyor.

Hiç spesifikasyon yazmamanın doğru olduğu durumlar

Oturmuş bir tasarım sistemi üzerinden ilerleyen, bileşenleri daha önce onlarca kez uygulamış bir ekipte ek dokümantasyon yazmak zaman kaybıdır. Tek sayfalık eklemeler, mevcut kalıpların tekrarı ve iki kişilik ekipler de bu kapsamda. Bu durumlarda araçtan çıkan otomatik element bilgisi ve kısa bir sözlü mutabakat yeterli.

Karmaşık akışlarda ise sözlü mutabakat yetmez, çünkü toplantıda verilen kararın ömrü yaklaşık iki haftadır. Konuşun, sonra kararı yazın. Toplantı yerine geçen belge değil, toplantının çıktısını saklayan belge işe yarar.

Yazmadan önce uygulayacağınız test

Belgeye eklediğiniz her satır için şunu sorun: bu satırı silsem geliştirici ya da yazar bunu bana sorar mıydı? Sormazsa satır fazladır. Sorardıysa satır tam yerinde. Bu tek ölçüt, spesifikasyonu hem kısa hem de gerçekten okunan bir belge haline getirir; kimse otuz sayfalık dokümanı ikinci kez açmıyor.