Information Architecture Portfolyoda Nasıl Anlatılır?

Information architecture, yani IA, UX portfolyolarında genellikle yeterince görünmeyen bir alandır. Bir site haritası, menü yapısı, kategori diyagramı veya kart sıralama çıktısı gösterilir. Sonra final ekranlara geçilir.

Fakat okuyucu çoğu zaman şu soruların cevabını göremez:

• İçerik neden bu şekilde gruplanmış?
• Navigasyon kararını hangi kullanıcı ihtiyacı etkiledi?
• Hangi seçenekler değerlendirildi?
• Kullanıcı aradığı şeyi daha kolay buldu mu?
• IA kararı final tasarımda nerede görünür oldu?

Bu soruların cevabı yoksa information architecture bölümü sadece teknik bir diyagram gibi kalır. Oysa iyi anlatıldığında IA, tasarımcının karmaşık bilgiyi nasıl düzenlediğini, kullanıcıların zihinsel modelini nasıl düşündüğünü ve ürün yapısını nasıl sadeleştirdiğini gösterir.

Portfolyo açısından IA’nın değeri şurada değildir:

Bir site map hazırladım.

Daha güçlü değer şuradadır:

Kullanıcıların bilgiyi nasıl aradığını, hangi gruplamaların daha anlamlı olduğunu ve navigasyon yapısının tasarım kararlarını nasıl etkilediğini gösterdim.

Information architecture nedir?

Information architecture, bir ürün içindeki bilgi, içerik, ekran, özellik veya aksiyonların kullanıcı için anlaşılır bir yapı içinde düzenlenmesidir.

Basitçe söylemek gerekirse IA şu sorularla ilgilenir:

• Kullanıcı aradığı şeyi nerede bekler?
• İçerik hangi gruplara ayrılmalı?
• Navigasyon hangi mantıkla kurulmalı?
• Bir özellik hangi kategori altında yer almalı?
• Hangi bilgi önce, hangisi sonra gösterilmeli?
• Kullanıcı bir ekrandan diğerine nasıl geçmeli?
• Ürün yapısı kullanıcının zihinsel modeliyle uyumlu mu?

Bu yüzden IA sadece site haritası değildir. IA, kullanıcının ürünü nasıl anladığıyla ilgilidir.

Portfolyoda IA ne zaman işe yarar?

IA özellikle ürün yapısı, içerik organizasyonu veya navigasyon kararının önemli olduğu projelerde güçlüdür.

1. Kullanıcı aradığı şeyi bulmakta zorlanıyorsa

Eğer projenin temel problemi kullanıcıların doğru bilgiye, doğru kategoriye veya doğru aksiyona ulaşmakta zorlanmasıysa IA anlatısı çok değerlidir.

Örneğin:

• Kullanıcı destek içeriğinde doğru cevabı bulamıyor.
• E-ticaret kullanıcısı ürün kategorilerini karıştırıyor.
• Finansal ürün kullanıcısı işlem ve hesap bilgilerini farklı yerlerde arıyor.
• SaaS kullanıcısı ayar, rapor ve ekip yönetimi alanlarını ayırt edemiyor.
• Mobil uygulamada sık kullanılan özellikler menü içinde kayboluyor.

Bu durumlarda final ekran göstermek yeterli değildir. Yapısal kararın nasıl alındığını anlatmak gerekir.

Zayıf anlatım:

Menü yapısını sadeleştirdim.

Daha güçlü anlatım:

Kullanıcılar işlem geçmişi ve hesap hareketlerini aynı kategori altında arıyordu. Mevcut yapıda bu bilgiler farklı menülere dağıldığı için kullanıcılar aynı bilgiye ulaşmak için birkaç farklı yol deniyordu. IA çalışmasında bu iki alanı kullanıcıların zihinsel modeline daha yakın bir yapı altında topladım.

Bu açıklama sadece değişikliği değil, kararın gerekçesini de anlatır.

2. İçerik çok fazlaysa

Bazı ürünlerde problem ekran tasarımı değil, bilgi yoğunluğudur. Çok fazla içerik, kategori, seçenek veya ayar varsa kullanıcı neyi nerede bulacağını anlamakta zorlanabilir.

Bu durumda IA çalışması, case study’nin merkezinde yer alabilir.

Örneğin:

Üründe 40’tan fazla ayar vardı ve kullanıcılar hangi ayarın hangi sonucu etkilediğini anlamakta zorlanıyordu. IA çalışmasında ayarları teknik mantığa göre değil, kullanıcı hedeflerine göre yeniden grupladım.

Bu tür bir anlatım, tasarımcının sadece ekran düzenlemediğini, ürün yapısını düşündüğünü gösterir.

3. Navigasyon kararı tasarımın temel parçasıysa

Bazı projelerde ana tasarım kararı navigasyondur. Kullanıcı hangi alana nasıl ulaşacak, hangi bilgi ana menüde yer alacak, hangi bilgi detay içinde kalacak, hangi aksiyon öne çıkarılacak?

Bu kararlar genellikle final ekranda görünür ama arkasındaki düşünce görünmez.

IA bölümü bu düşünceyi açıklamak için kullanılabilir.

Örnek:

İlk yapıda tüm özellikler ana menüde görünüyordu. Bu durum yeni kullanıcılar için keşfi kolaylaştırıyordu ama sık kullanılan görevleri yavaşlatıyordu. Alternatif yapıda ana menüyü görev bazlı sadeleştirdim ve daha az kullanılan özellikleri ilgili detay alanlarına taşıdım.

Bu açıklama trade-off’u da görünür kılar.

IA ne zaman zayıf görünür?

Information architecture güçlü bir konu olabilir, fakat yanlış anlatıldığında kuru ve teknik görünebilir.

1. Sadece diyagram gösteriliyorsa

Bir site map veya kategori diyagramı tek başına yeterli değildir. Okuyucu, yapının neden böyle kurulduğunu anlamalıdır.

Şu ifade zayıf kalır:

Aşağıda yeni bilgi mimarisi yer alıyor.

Daha güçlü ifade:

Yeni bilgi mimarisinde teknik ürün yapısını değil, kullanıcıların görevlerini temel aldım. Çünkü araştırmada kullanıcıların özellik adlarıyla değil, yapmak istedikleri işlemlerle düşündüğünü gördük.

Bu ikinci anlatım, IA kararını kullanıcı davranışına bağlar.

2. Mevcut yapı ile yeni yapı arasındaki fark anlatılmıyorsa

IA çalışması genellikle bir yeniden düzenleme içerir. Mevcut yapıdaki problem ve yeni yapıdaki çözüm açık olmazsa okuyucu farkı göremez.

Güçlü bir IA anlatısı için şu iki taraf net olmalı:

• Eski yapı neden sorunluydu?
• Yeni yapı bu sorunu nasıl azalttı?

Örnek:

Eski yapıda “limit”, “kart ayarları” ve “güvenlik” farklı menülerde yer alıyordu. Kullanıcılar kart kullanım kısıtlarını değiştirmek istediklerinde hangi menüye gideceklerini bilemiyordu. Yeni yapıda bu seçenekleri “kart kontrolü” altında topladım.

Bu açıklama IA kararını çok daha okunur hale getirir.

3. IA final tasarıma bağlanmıyorsa

IA diyagramı gösterilip sonra final ekranlara geçiliyorsa bağ kopabilir. Okuyucu, IA çalışmasının final tasarımda nerede etkili olduğunu görmelidir.

IA şu bölümlere bağlanabilir:

• Navigation
• Menu structure
• Page hierarchy
• Search and filtering
• Empty states
• Category labels
• Onboarding
• Settings structure
• Dashboard layout

Bu bağlantı kurulmadığında IA bölümü çalışma dosyası gibi kalır.

IA case study’de nasıl anlatılmalı?

Aşağıdaki yapı çoğu portfolyo projesi için yeterlidir.

1. Yapısal problemi tarif et

Önce hangi yapı problemini çözdüğünü yaz.

Örnek:

Kullanıcılar ihtiyaç duydukları bilgiye ulaşabiliyordu ama doğru yolu ilk denemede bulamıyordu. Mevcut navigasyon ürün ekibinin teknik sınıflandırmasına göre kurulmuştu, kullanıcıların görevlerine göre değil.

Bu cümle IA çalışmasının neden gerekli olduğunu açıklar.

2. Hangi veriye dayandığını belirt

IA kararları araştırma, analytics, search logs, müşteri destek kayıtları, card sorting, tree testing veya usability test bulgularına dayanabilir.

Örnek:

IA çalışmasını kullanıcı görüşmeleri, destek kayıtları ve mevcut menüde en çok geri dönülen sayfalar üzerinden değerlendirdim.

Eğer araştırma sınırlıysa bunu da açık yazabilirsin:

Araştırma erişimi sınırlı olduğu için IA kararlarını varsayımsal kullanıcı görevleri üzerinden oluşturdum ve sonraki testlerde doğrulanması gereken alanları belirledim.

Bu, sahte kesinlik üretmekten daha güvenilirdir.

3. Mevcut yapıdaki problemi göster

Eski yapının neden sorun çıkardığını kısa anlat.

Örnek:

Mevcut yapıda kullanıcıların “ödeme geçmişi” ve “işlem detayları” için iki farklı menüye gitmesi gerekiyordu. Görüşmelerde kullanıcıların bu iki bilgiyi aynı bağlamda düşündüğünü gördük.

Bu cümle yeni yapının gerekçesini hazırlar.

4. Alternatif gruplamaları anlat

IA çalışmasında çoğu zaman birden fazla yapı seçeneği vardır.

Örnek:

İlk alternatifte bilgileri ürün tiplerine göre grupladım. Bu yapı ekip için anlaşılırdı ama kullanıcı görevleriyle zayıf eşleşiyordu. İkinci alternatifte bilgileri “takip et”, “düzenle” ve “destek al” gibi kullanıcı amaçlarına göre düzenledim. Bu yapı testte daha kolay anlaşıldı.

Bu anlatım karar kalitesini gösterir.

5. Yeni yapıyı final tasarıma bağla

IA bölümünün sonunda final tasarıma geçiş yap.

Örnek:

Bu yeni yapı final tasarımda ana menünün sadeleşmesini, işlem detaylarının tek bağlamda toplanmasını ve destek bağlantılarının ilgili ekranlara taşınmasını sağladı.

Bu cümle IA’nın final üründeki etkisini görünür kılar.

Güçlü bir IA bölümü nasıl yazılabilir?

Aşağıdaki örnek yapı kullanılabilir:

Mevcut yapıda içerikler ekip içi ürün mantığına göre gruplanmıştı. Kullanıcılar ise ürünü özellik adlarıyla değil, yapmak istedikleri görevlerle anlamaya çalışıyordu.

Görüşmelerde kullanıcıların “işlemi takip etme”, “bilgiyi değiştirme” ve “yardım alma” ihtiyaçlarını ayrı menülerde değil, aynı görev bağlamında düşündüğünü gördüm. Bu yüzden IA çalışmasında teknik kategoriler yerine kullanıcı görevlerini temel aldım.

İlk alternatif ürün tiplerine göre daha düzenli görünüyordu ama kullanıcı görevleriyle zayıf eşleşiyordu. İkinci alternatif görev bazlıydı ve testte daha hızlı anlaşıldı. Final tasarımda ana navigasyonu bu ikinci yapıya göre sadeleştirdim.

Bu anlatımda IA bir diyagram değil, ürün yapısı kararıdır.

IA görseli nasıl sunulmalı?

IA görselleri hızlıca karmaşık hale gelebilir. Portfolyoda görselin amacı her detayı göstermek değil, karar mantığını açıklamaktır.

Şunlara dikkat et:

• Eski ve yeni yapıyı karşılaştır.
• Kritik değişiklikleri işaretle.
• Çok büyük site map yerine sadeleştirilmiş görünüm kullan.
• Kullanıcı görevleriyle kategori ilişkisini göster.
• Haritanın altına ana öğrenimi yaz.
• Eğer test yapıldıysa hangi yapının daha iyi anlaşıldığını belirt.
• Etiketleri okunur tut.
• Görseli tek başına bırakma, kısa karar notu ekle.

Örnek görsel notu:

Yeni yapıda özellikleri teknik kategoriye göre değil, kullanıcının görevlerine göre grupladım. Bu değişiklik, destek ve işlem detaylarına ulaşma yolunu kısalttı.

IA yerine ne gösterebilirsin?

Bazı projelerde IA’yı ayrı bir bölüm yapmak yerine başka bir format daha iyi çalışabilir.

Task flow

Eğer temel problem kullanıcının hangi adımlardan geçtiğiyse, task flow daha net olabilir.

Navigation comparison

Eğer asıl karar eski ve yeni navigasyon farkıysa, karşılaştırmalı bir yapı daha iyi çalışır.

Content grouping table

Eğer problem içerik gruplamaysa, tablo daha okunabilir olabilir.

Örnek:

Eski grup	Problem	Yeni grup
Teknik ayarlar	Kullanıcı anlamıyor	Hesap kontrolü
İşlem kayıtları	Farklı menülerde dağınık	İşlem geçmişi
Yardım içerikleri	Genel destek alanında kayboluyor	İlgili ekran içi destek

Search or filter logic

Eğer kullanıcı bilgiyi arama veya filtreleme yoluyla buluyorsa, IA yerine search/filter kararını anlatmak daha doğru olabilir.

Kısa kontrol listesi

IA’yı portfolyona eklemeden önce şu soruları sor:

• Kullanıcı hangi bilgiyi veya aksiyonu bulmakta zorlanıyordu?
• Mevcut yapı neden sorun yaratıyordu?
• Yeni yapı hangi kullanıcı davranışına veya veriye dayanıyor?
• Alternatif gruplamalar değerlendirildi mi?
• Final tasarımda IA kararının etkisi nerede görünüyor?
• Görsel, karar mantığını hızlıca anlatıyor mu?
• IA bölümünü kaldırırsan case study önemli bir yapısal kararı kaybeder mi?

Son sorunun cevabı hayırsa IA’yı ayrı bir bölüm olarak büyütmek yerine, ilgili tasarım kararının içinde kısa anlatmak daha iyi olabilir.

Sonraki adım

IA bölümünü yazmadan önce şu üç cümleyi tamamla:

Kullanıcıların bilgiyi bulmakta zorlandığı yer şuydu…

Mevcut yapı bunu zorlaştırıyordu çünkü…

Yeni IA kararı final tasarımda şu değişikliği yarattı…

Bu üç cümle netleştiğinde information architecture, portfolyoda sadece diyagram değil, tasarım kararının güçlü bir kanıtı haline gelir.