
Bir UI/UX projesinin teslimi yalnızca ekran dosyalarından oluşmamalıdır. Ekibin, hangi problemin çözüldüğünü, tasarımın nasıl davranacağını ve geliştirme sırasında hangi kararların korunacağını anlayabilmesi gerekir. Gerekli teslimler ürünün olgunluğuna, araştırma ihtiyacına ve geliştirme kapsamına göre değişir.
Bu nedenle bir projede bulunabilecek bütün belgeleri istemek yerine, her çıktının hangi kararı desteklediğini sorun. Küçük bir akış iyileştirmesi için kapsamlı bir persona dosyası gerekmeyebilir; çok rollü bir ürün için ise yalnızca ana ekranların çizilmesi yetersiz kalabilir.
Nielsen Norman Group, UX teslimlerini fikirleri ve çalışmanın sonuçlarını aktarmaya yarayan farklı çıktı türleri üzerinden açıklar.[1] Aşağıdaki tablo ise bir proje kapsamını görüşürken kullanılabilecek pratik bir başlangıçtır; her satırın her projede zorunlu olduğu anlamına gelmez.
| Teslim | Desteklediği karar | Kabul sırasında kontrol |
|---|---|---|
| Araştırma özeti | Hangi problem çözülmeli | Bulguların kaynağı ve sınırları |
| Kullanıcı akışı | Görev nasıl tamamlanır | Roller ve alternatif yollar |
| Wireframe | Bilgi nasıl düzenlenir | İçerik önceliği ve etkileşim |
| Arayüz tasarımı | Ürün nasıl görünür ve davranır | Durumlar ve uyarlanabilir düzen |
| Prototip | Hangi varsayım test edilir | Çalışan ve temsili alanlar |
| Geliştirme devri | Tasarım nasıl uygulanır | Bileşenler ve davranış açıklamaları |
Bir bulgu listesi, nereden geldiği anlaşılmadığında kolayca görüş listesine dönüşür. Kullanılan yöntemi, katılımcı profilini ve çalışmanın cevaplamadığı soruları belirtin. Kişisel verileri gereksiz yere teslim dosyasına taşımayın. Ekip; gözlemi, yorumu ve öneriyi birbirinden ayırabilmelidir.
Örneğin varsayımsal bir araştırmada “katılımcı planları karşılaştırmak için sekmeler arasında geri döndü” gözlemdir. “Plan farklarını hatırlamakta zorlanıyor olabilir” yorumdur. “Yan yana karşılaştırmayı prototipte test edelim” ise öneridir. Bu ayrım, sonraki kararların dayanağını görünür kılar.
Yalnızca veriyle dolu ideal ekranı teslim etmek geliştirme sırasında boşluk bırakır. Akış için ilgiliyse yükleme, boş durum, hata, başarı, yetki kısıtı ve eksik veri davranışlarını tanımlayın. Formlarda yardım metni ve hata mesajları da tasarımın parçasıdır.
Uyarlanabilir tasarımda sadece “masaüstü ve mobil çizildi” demekle yetinmeyin. İçeriğin nasıl yeniden sıralanacağını, uzun metinlerin ne olacağını ve bileşenlerin dar alanlarda nasıl davranacağını açıklayın. Klavye odağı ve etiketler gibi erişilebilirlik kararlarını uygulama ekibiyle paylaşın; tasarım dosyasını tek başına uygunluk belgesi olarak sunmayın.
Dosya paylaşımı devrin başlangıcıdır. Ürün ve mühendislik ekibiyle kritik akışları birlikte gözden geçirin. Bileşen adlarını, tasarım değişkenlerini, dışa aktarılacak varlıkları ve karar notlarını anlaşılır biçimde düzenleyin. Açık kalan teknik soruları bir listede tutun ve sahiplerini belirleyin.
Uygulama kontrolü kapsamdaysa hangi ekranların, cihazların ve durumların inceleneceğini önceden kararlaştırın. Tasarımın geliştirilmiş sürümde nasıl çalıştığını kontrol etmek, yeni özellik talep etmekten farklı bir iştir. Bu sınırın açık olması teslim sürecini kolaylaştırır.
Hayır. Mevcut bileşenlerin kullanılması veya sınırlı bir UI kit yeterli olabilir. Karar, ürün ve ekiplerin tekrar eden ihtiyaçlarına bağlıdır.
Genellikle değildir. Belirli etkileşimleri temsil eder; gerçek veri, güvenlik ve performans koşullarını kapsaması ayrıca kararlaştırılmalıdır.
Her çıktının yanında kullanım amacını, kabul koşulunu ve sorumlusunu yazın. Kapsamı birlikte değerlendirmek için VOYA ürün tasarımı hizmetini inceleyebilirsiniz.
Projeniz hakkındaki fikirler, hedefler, talepler ve ulaşmak istediğiniz yer belli mi? Bir görüşme ayarlayarak tümünü hayata geçirme yolundaki ilk adımı beraber atalım.