← Tüm yazılar
İş Sunumları

Arayüz tasarımı sunumu: kullanıcı akışı ve gerekçe

Arayüz sunumunu ekran galerisi yerine kullanıcı akışı çevresinde kurun. Her önemli kararı kullanıcı ihtiyacı, gerekçe ve doğrulama sorusuyla açıklayın; tamamlanan işleri, taslakları ve sınanacak varsayımları birbirinden ayırın.

Draw Editör Ekibi5 dk okuma

Sunumun amacı ve kapsamı

Arayüz tasarımı sunumunda yalnızca ekranları sırayla göstermek yerine bir kullanıcı hedefini, bu hedefe giden akışı ve tasarım kararlarının gerekçesini birlikte anlatın. Dinleyicinin şu sorulara yanıt bulmasını sağlayın: Kullanıcı kim? Ne yapmak istiyor? Hangi adımlardan geçiyor? Hangi tasarım kararı bu adımları destekliyor? Neler tamamlandı, neler taslak ve hangi noktalar kullanılabilirlik açısından incelenmeli?

Geri bildirim almayı amaçlıyorsanız değerlendirilmesini istediğiniz akışı ve açık soruları belirtin. Uygulamayı tanıtıyorsanız çalışan bölümlerle planlanan bölümleri birbirinden ayırın. Beklentiler ders veya proje yönergesine göre değişebilir; başka bir dersin formatını genel zorunluluk gibi sunmayın. Örneğin, kaynak gösterilen CS4760 ödevi sistemi ve kullanıcıları tanıtmayı, arayüzü tamamlanmış uygulama ve/veya yüksek doğruluklu prototiple göstermeyi, olası kullanılabilirlik sorunlarını ve tamamlanan ya da sonraki hafta tamamlanması planlanan arayüz parçalarını açıklamayı istiyor. Bu koşullar o ödev içindir (ödev yönergesi).

Sunumdan önce hazırlanacaklar

Önce hedef kullanıcıyı, anlatacağınız temel görevi ve sunum sonunda almak istediğiniz geri bildirimi tanımlayın. Her ekranı eklemek yerine görevi açıklamak için gereken görünümleri seçin. Her birinin durumunu doğru etiketleyin: uygulanmış ekran, prototip, taslak veya henüz yapılmamış iş. Görsel gerçek ürünü göstermiyorsa bunu açıkça belirtin.

Slaytları sunumda kullanacağınız biçimde gözden geçirin. Metin okunmuyorsa açıklamayı kısaltıp ekranı büyütmek pratik bir tercihtir. Prototip etkileşimini göstermek sunuma katkı sağlıyorsa gösterin; bağlantı veya etkileşim sunum sırasında çalışmazsa, akışı açıklamak için ekran görüntülerini ve geçişleri kullanabilirsiniz. Bunlar sunum hazırlığına yönelik önerilerdir; belirli bir yazılımı, cihazı veya platform özelliğini zorunlu kılmaz.

Akışı anlatan slayt sırası

Aşağıdaki sıra, dinleyiciyi kullanıcı hedefinden tasarım gerekçesine ve geri bildirime taşımak için kullanılabilir:

  • Amaç ve kullanıcı: Ürünün ne işe yaradığını, kim için tasarlandığını ve ele alınan görevi kısaca açıklayın.
  • Görev ve başlangıç noktası: Kullanıcının nereden başladığını, hangi bilgiye sahip olduğunu ve ulaşmak istediği sonucu gösterin.
  • Kullanıcı akışı: Adımları ve karar noktalarını bir diyagramda veya numaralanmış ekranlarda izlenebilir kılın.
  • Tasarım kararları: Önemli bir bileşenin hangi ihtiyaca yanıt vermesinin amaçlandığını açıklayın. Araştırmayla doğrulanmamış kullanıcı davranışlarını bulgu değil, varsayım olarak adlandırın.
  • Tamamlanma ve açık durumlar: Görevin başarıyla tamamlandığı durumu, varsa hata veya boş durum tasarımını ve planlanan işleri belirtin.
  • Geri bildirim: Hangi kararın veya akış adımının değerlendirilmesini istediğinizi sorun.

Bir slaytta birden fazla ekran varsa aralarındaki geçişi numara veya oklarla belirtin. Her görsele uzun açıklamalar eklemek yerine, ekranın yanına kısa bir gerekçe ve belirli bir doğrulama sorusu koyun.

Varsayımsal örnek: randevu planlama arayüzü

Bu senaryo hayalidir; gerçek ürün, kullanıcı araştırması veya test sonucu hakkında iddia içermez. Bir kullanıcı klinik uygulamasında uygun bir randevu bulup talebini tamamlamak istiyor. Sunumun ana sorusu şöyle olabilir: “Kullanıcı uygun bir zaman seçip randevu talebini gönderebiliyor mu?” Araştırma yapılmadıysa, kullanıcının uzman ve zaman seçeneklerini karşılaştırmak isteyeceğini bir tasarım varsayımı olarak tanımlayın.

  • 1. slayt — Görev: Kullanıcının bir uzmanla uygun zaman seçmek istediğini ve sunumda hangi akışın ele alınacağını açıklayın.
  • 2. slayt — Uzman seçimi: Uzman seçeneklerinin nasıl sunulduğunu gösterin. Gerekçe: Karşılaştırmada yararlı olabilecek bilgileri görünür kılmayı amaçlamak. Soru: Kullanıcı seçenekleri birbirinden ayırabiliyor mu?
  • 3. slayt — Zaman seçimi: Zamanın nasıl seçildiğini ve seçimin sonraki adıma nasıl taşındığını gösterin. Seçilen zamanı özetlemek, kullanıcının seçimini gözden geçirmesine yardımcı olabilir; bunu doğrulanmış sonuç değil, sınanacak beklenti olarak ifade edin.
  • 4. slayt — Bilgileri gözden geçirme: Talep gönderilmeden önce gösterilen özeti açıklayın. Soru: Kullanıcı değiştirmek istediği bilgiyi bulabiliyor mu?
  • 5. slayt — Sonuç ve eksikler: Talebin gönderildiği durumu ve tamamlanmamış parçaları gösterin. Soru: Kullanıcı talebin gönderilip gönderilmediğini anlayabiliyor mu?

Bu örnekteki gerekçeler de tasarım önerisidir; sunumunuzda kendi ürününüzün gerçek ekranlarını kullanın ve doğrulanmamış varsayımları kullanıcı bulgusu gibi aktarmayın.

Tasarım kararlarını gerekçelendirme

Önemli kararları şu zincirle anlatın: kullanıcı ihtiyacı → arayüz kararı → beklenen etki → doğrulama sorusu. Örneğin: “Seçilen zamanın özette görünmesi, kullanıcının göndermeden önce seçimini kontrol etmesini amaçlıyor. Görev sırasında kullanıcının zamanı doğru anlayıp anlamadığını gözlemleyeceğiz.” Böylece tasarım tercihini açıklarken henüz ölçülmemiş bir etkiyi kanıtlanmış gibi sunmazsınız.

Önceki ve sonraki tasarımları gösteriyorsanız değişikliğin nedenini ve hangi geri bildirime dayandığını belirtin. İlgili CS4760 yönergesi, tamamlanmış görünümler için ekran görüntüsü; henüz tamamlanmamış fakat yapılması planlanan görünümler için kâğıt tasarım kullanılmasını istiyor. Bu, söz konusu ödevin talimatıdır; kendi projenizin beklenen gösterim biçimini ayrıca kontrol edin (sunum yönergesi).

Sunum ve geri bildirim sırasında

Kullandığınız sunum aracında konuşmacı notlarını görmeniz gerekiyorsa, bunu sunumdan önce kendi dosyanızda deneyin. Örneğin Google Slaytlar’ın yardım sayfası, sunum görünümünde konuşmacı notlarına erişme adımlarını ve birden fazla monitörle sunum için gereken koşulları açıklar. Ek monitör, bu özel çoklu ekran yönteminin koşuludur; genel arayüz sunumu için zorunluluk değildir. Kullanacağınız araca ve mevcut sunum menüsüne göre uygun görünümü kontrol edin (Google Slaytlar sunum yardımı).

Geri bildirim isterken geniş bir “Ne düşünüyorsunuz?” sorusu yerine belirli bir adımı veya kararı değerlendirmeye açın. Gelen yorumları not edin ve öneriyi hemen uygulama taahhüdü vermeden değerlendirin. CS4760 ödevi, izleyiciden gelen geri bildirim ve fikirlerin kaydedilmesini, sunucuların yorumlara karşı savunmacı olmamasını özellikle belirtiyor; bu da o dersin yönergesidir.

Son kontrol ve sık sorulan sorular

  • Kullanıcı, görev ve sunumun amacı açık mı?
  • Akışın başlangıcı, karar noktaları ve tamamlanma durumu görülebiliyor mu?
  • Önemli kararların gerekçesi ve doğrulama sorusu belirtilmiş mi?
  • Varsayımlar araştırma bulgularından ayrılmış mı?
  • Prototip, uygulanmış ekran ve planlanan işler doğru etiketlenmiş mi?
  • Görseller okunuyor ve istenen geri bildirim belirli mi?

Her ekranı göstermeli miyim?

Hayır. Ana kullanıcı görevini ve ilgili kararları anlatmaya yetecek ekranları seçin. Diğer görünümleri ancak sunumun amacı ve süresi elveriyorsa ekleyin.

Kullanıcı testi yapılmadıysa gerekçeleri nasıl sunmalıyım?

Gerekçeleri doğrulanmış sonuç değil, tasarım varsayımı olarak belirtin ve her varsayımın nasıl kontrol edilebileceğine dair bir soru sorun.

İlgili uygulama rehberleri

Logo tasarımı sunumu: tasarım kararlarını anlatma rehberiyle bu çalışmanın ilgili adımını ayrıntılandırabilirsiniz. İç mimarlık projesi sunumu hazırlama rehberiyle bu çalışmanın ilgili adımını ayrıntılandırabilirsiniz.

← Bloga dön