Katlanabilir iPhone Duo ile Tasarımın İşi Değişiyor

Bir otel aradığınızı düşünün. Yolda telefondan fiyatlara bakıyorsunuz, bir yeri kaydediyorsunuz, sonra telefonu cebinize koyuyorsunuz. Biraz sonra oturacak bir yer bulup bu kez telefonun kendisini açıyorsunuz. Otel, harita ve seçtiğiniz tarihler aynı anda önünüzde. Güzel tarafı şu: Az önce baktığınız yeri tekrar bulmanız gerekmiyor. Uygulama nerede kaldığınızı biliyor.

Katlanabilir iPhone fikrinde beni heyecanlandıran şey biraz bu. Menteşesi, inceliği, ekranı elbette ilgi çekici. Ama tasarımcı olarak aklım daha çok telefon açıldıktan sonraki birkaç saniyede. Ortaya çıkan alan gerçekten işimizi kolaylaştıracak mı? Yoksa aynı arayüzün daha geniş bir versiyonuna mı bakacağız?

Apple, iPhone Duo’yu 9 Eylül 2026’da duyurdu. Açıklamada 5,4 inç dış ekran, 7,6 inç iç ekran ve iki uygulamayı birlikte kullanmaya yarayan Split View yer alıyor. Satış başlangıcı 23 Ekim olarak belirtiliyor.

Kullanıcı düşünürken ekran değişebilir

Farklı ekranlara tasarım yapmak zaten işimizin bir parçası. Mobil, tablet, masaüstü derken Figma dosyasında yan yana duran pek çok ölçüye alıştık. Katlanabilir telefonu da bunların arasına yeni bir frame olarak eklemek mümkün. Grid’i ayarlarız, kartları genişletiriz, bazı alanları yan yana koyarız. Görsel tarafta ilerlemiş oluruz ama deneyimin önemli bir bölümünü henüz konuşmamış oluruz.

Çünkü burada kullanıcı aynı işi yaparken ekranın koşulları değişebiliyor. Bir arama yaptıktan sonra, mesaj yazarken veya iki teslimat tarihini karşılaştırırken telefonu açabiliyor. Niyeti devam ediyor. Etrafındaki arayüz ise başka bir düzene geçiyor. Benim için tasarımı değerlendireceğimiz ilk yer tam olarak burası: Kullanıcının o ana kadar düşündüklerinin ve seçtiklerinin ne kadarı yeni düzende korunuyor?

Örneğin bir alışveriş uygulamasında bedenimi, fiyat aralığını ve teslimat tercihini seçmiş olayım. Telefonu açınca daha çok ürün görmek işe yarayabilir. Seçtiğim filtreleri daha rahat değiştirmek de işe yarayabilir. Ama filtreler sıfırlanırsa geniş ekranın pek anlamı kalmaz. Kullanıcıya aynı işi ikinci kez yaptırmış oluruz. Bu yüzden geniş ana sayfayı parlatmadan önce bu geçişi tasarlamak isterdim.

Android tarafında öğrenebileceğimiz çok şey var

Katlanabilir deneyimler Apple ile başlamıyor. Samsung’un geliştirici rehberi, cihaz katlanırken veya açılırken kullanıcının durumunu ve bulunduğu yeri korumayı uygulama sürekliliği üzerinden anlatıyor. Android’in yerleşim rehberlerinde de liste ile ayrıntıyı birlikte gösteren yapılar bulunuyor. Bunlar platforma özgü uygulamaları olan, incelemeye değer başlangıç noktaları. Samsung: App continuity; Android: Canonical layouts.

Apple’ın gelişiyle değişebileceğini düşündüğüm şey, özellikle iPhone tarafını birkaç alışılmış telefon ölçüsüyle ele alan ekiplerin gündemi. Artık “Bunun yanında ne görünmeli?” sorusuna daha bilinçli bir cevap vermek gerekebilir. Bazen cevap tablet uygulamasında hazırdır. Bazen de tablet tasarımının bugüne kadar yalnızca büyütülmüş kartlardan oluştuğunu fark ederiz. Yeni cihaz, eski tasarım borcunu görünür hâle getirebilir.

Yine de buradan normal telefonların sonunun geldiği sonucunu çıkarmam. Birçok günlük iş küçük ekranda zaten rahatça yapılıyor. Üstelik telefonu açmak da bir hareket, bazen iki el gerektiren bir tercih. Bence ürün ekibinin önce cevaplaması gereken soru daha somut: Bizim uygulamamızdaki hangi iki veya üç iş, bu ekranda gerçekten daha kolay olacak? Cevap belirgin değilse bir sütun daha eklemek sorunu çözmez.

Ek alan, bilgiler arasındaki ilişkiyi gösterebilir

Benim en çok ilgimi çeken fırsat karşılaştırma. Küçük ekranda bir bilgiyi akılda tutup başka bir bilgiye geçmeye çok alıştık. Bir oteli açıyoruz, iptal koşulunu okuyoruz, geri dönüyoruz, diğer oteli açıyoruz. Sonra ilk fiyatın kahvaltı dâhil olup olmadığını hatırlamaya çalışıyoruz. Genişleyen ekranın burada sağlayabileceği fayda oldukça anlaşılır: Karar vermek için gereken bilgileri bir araya getirmek.

Bir seyahat uygulamasında sonuç listesini haritanın yanına koymayı denerdim. Seçilen otelle haritadaki işaretin ilişkisi belirgin olurdu. Başka bir sonuca geçtiğimde arama bağlamı kaybolmadan ayrıntı alanı güncellenirdi. Bir finans uygulamasında işlemin yanında fişini veya açıklamasını görebilirdim. Yemek tarifinde ise sıradaki adımı okurken malzemeler görünür kalabilirdi. Bunlar benim tasarım önerilerim; mevcut iPhone uygulamalarının doğrulanmış özellikleri olarak düşünülmemeli.

Henüz hiçbir şey seçilmemişken ne gösterileceğini de aynı ciddiyetle ele alırdım. İkinci alan bir yönlendirme mi göstermeli, genel bir özet mi sunmalı, yoksa boş mu kalmalı? Sırf kompozisyon dengelensin diye ilgisiz kampanya yerleştirmek istemem. İki alanın birbirini anlamlı biçimde tamamlaması gerekiyor. Aksi hâlde geniş ekran, yan yana duran iki ayrı dikkat dağıtıcıya dönüşebilir.

Dış ekranı eksik bırakmamak gerekiyor

Katlanabilir bir uygulama tasarlarken dış ekranı asıl deneyimin küçük bir ön izlemesi gibi görmek kolay. Bence bu yaklaşım gündelik kullanımı hafife alır. Kullanıcı bir elinde çanta taşıyor olabilir. Toplu taşımada tutunuyor olabilir. Ya da gerçekten telefonu açmak istemiyordur. Bilet göstermek, rezervasyonu kontrol etmek veya kısa bir yanıt vermek bu koşullarda da tamamlanabilir olmalı.

Otel örneğine dönersek dış ekranda toplam fiyatı, tarihleri, iptal koşulunu ve devam etmek için gereken işlemi anlayabilmeliyim. Geniş ekran karşılaştırmayı daha rahat hâle getirebilir. Fakat temel bir bilgiyi öğrenmek için telefonu açmaya mecbur kalırsam bu kez donanımın sunduğu esneklik bana ek görev olarak dönmüş olur. “Daha büyük ekranda daha rahat” ile “küçük ekranda yapılamıyor” arasında ciddi bir deneyim farkı var.

Her özellik için “Kullanıcı telefonu açmadan bitirebilir mi?” diye sorardım. Bazen küçük ekranda daha fazla adım gerekebilir. Harita ayrı bir görünümde açılabilir, fiş işlem ayrıntısından sonra gelebilir. Yol anlaşılırsa ve seçimler korunursa bu kabul edilebilir. Önemli olan dış ekranın, ürünün yarım çalışan bir versiyonu gibi hissettirmemesi. Kullanıcının işi küçük ekranda da ciddiye alınmalı.

Navigasyon artık tutuş biçimiyle daha yakın ilişkili

Apple’ın iPhone Duo tasarım oturumu; yan kenarlardaki kontrolleri, iç ve dış ekran uyarlamalarını ve kısmi katlanma sırasında arayüz davranışını anlatıyor. Her duruşa ayrı bir tasarım kurmak yerine compact ve regular boyut sınıflarıyla düşünmeyi öneriyor. Bunlar bu platformun yönlendirmeleri; her mobil uygulamanın menüsünü yana taşıma gerekçesi değil. Design for iPhone Duo.

Ben burada önce tanınabilirliğe bakarım. Navigasyon yer değiştiriyorsa kullanıcı onun aynı navigasyon olduğunu ne sayesinde anlayacak? Bölüm isimlerini, anlamlı ikonları, seçili durumları ve bölümler arasındaki ilişkiyi korumak isterdim. Küçük ekranda “Kaydedilenler” olan yerin telefon açılınca başka isimli bir başlığın içine taşınması gereksiz bir arama işi yaratabilir. Yerleşim değişirken ürünün kullandığı dilin tutarlı kalması rahatlatıcı olur.

Bir de cihazı tutan el var. Ortada çok dengeli görünen bir butona ulaşmak zor olabilir. Kenardaki bir kontrol ise sistem hareketleriyle karışabilir. Fiziksel cihazda denemeden bunlardan birine rahat demek istemem. Figma prototipi hiyerarşi sorununu gösterebilir ama kullanıcının aynı butona basmak için telefonu kaç kez elinde düzelttiğini ölçemez. Bazı tasarım kararlarının cevabı gerçekten elde saklı.

“Sayfa açık kalsın” demek yeterince açıklayıcı değil

Bir ekiple çalışıyor olsam şöyle bir senaryo verirdim: Destek konuşmasını aç, eski bir mesaja git, yanıtın yarısını yaz, sonra ekranın kullanılabilir alanını değiştir. Şimdi devam et. Burada korunması gereken şey yalnızca sohbetin adı değil. Seçili konuşma, okunan mesaj, yazılmış taslak ve belki imlecin konumu da deneyimin parçası. Başlığı koruyup taslağı kaybetmek, teknik olarak aynı sayfada görünsek bile işi kaybetmek demek.

Okumada da benzer bir ayrıntı var. Aynı kaydırma değerini korumak, aynı paragrafta kalmak anlamına gelmeyebilir. Satır uzunluğu değiştiğinde metnin sayfa içindeki konumu da değişir. Bu yüzden tasarım hedefini “Kaydırma sıfırlanmasın” diye bırakmazdım. “Okuyucunun baktığı paragraf veya içerik öğesi kolayca bulunabilir kalsın” demek daha açıklayıcı. Nasıl yapılacağını geliştiriciyle birlikte netleştiririz ama beklenen sonuç tasarımda tanımlı olur.

Klavye açıkken telefonu açarsak klavye açık kalacak mı? Onay penceresi varken alan değişirse pencere hangi bölümle ilişkisini koruyacak? Bunlar biraz uğraştırıcı sorular, kabul. Ama ayrı ekranların kendiliğinden tutarlı cevaplar vereceğini beklemek daha pahalıya çıkabilir. Kısa bir geçiş kuralı, kusursuz örnek metinlerle hazırlanmış bir ekran daha çizmekten değerli olabilir. Özellikle de kullanıcı tam bir şey yazarken.

Telefon açık olabilir, uygulamanın alanı yine dar olabilir

Sunumda geniş cihaz çerçevesini görünce uygulamanın hep o alanın tamamını kullanacağını varsayabiliyoruz. Oysa yanında başka bir uygulama bulunabilir. Android’in pencere boyutu rehberi, uygulamaya ayrılan alanı sınıflandırıyor ve genişlikle yüksekliği ayrı ele alıyor. Bu ayrım platformlar arasında düşünmek için yararlı; Android’in ölçü birimlerini ve eşiklerini olduğu gibi iOS’a taşımak için değil. Use window size classes.

Bir ürün araştırırken yanında mesajları açtığımı düşünün. Donanım açık ama mağaza uygulaması yine sınırlı alanda. Orada minik yazılarla sıkıştırılmış bir masaüstü sayfası görmek istemem. Kullanılabilir bir küçük ekran düzeni beklerim. Tam ekranda yan yana duran karşılaştırma, bu kez birkaç adıma dönüşebilir. Bu geçişin başarısını cihazın adı değil, uygulamanın o anda sahip olduğu alan belirler.

Figma’daki isimlendirmeyi de buna göre yapardım. “Küçük iPhone” ve “katlanabilir” hangi çerçeveyi kullandığımı anlatıyor. “Sonuçlar, tek alan” ve “Sonuçlar, liste ile ayrıntı” ise içeriğin nasıl davrandığını anlatıyor. Cihaz görselleri sunum için elbette faydalı. Ama bileşen kuralları yalnızca seçtiğimiz örnek ölçülerde değil, aralarında kalan alanlarda da ne olacağını açıklamalı. Geliştirme sırasında ihtiyaç duyulan bilgi çoğu zaman tam burada.

Katlanma, ekranın masayla ilişkisini de değiştiriyor

Açık telefonu elde tutmakla yarı katlı hâlde masaya koymak aynı kullanım biçimi değil. Bakış açısı değişiyor, elin ekrana uzaklığı değişiyor. Apple’ın uyarlanabilir yerleşim oturumu menteşe çevresindeki ayrılmış bölgeleri ve içerik hareketlerini ele alıyor. Android tarafında da katlanmayı dikkate alan rehberler var. Bunları bütün katlanabilir cihazların aynı özellikleri sunduğu şeklinde okumamak gerekiyor. Apple: Adaptive layouts; Android: Fold-aware apps.

Örneğin bir görüntülü görüşme konseptinde konuşmayı görünür tutup mikrofon ve kamera kontrollerini kolay tanınan bir alanda denemek isterdim. Bir zamanlayıcıda ise süreyi büyütüp çevresindeki seçenekleri azaltabilirdim. Ama her kısmi katlanmayı otomatik olarak “toplantı modu” saymak istemem. Kullanıcının cihazı nasıl tuttuğu bize ipucu verir; ne yapmak istediğini bütünüyle açıklamaz. Bir kitap okuyor da olabilir, cihazı sadece geçici olarak bırakmış da olabilir.

Telefon yeniden ele alındığında geri dönüş de anlaşılır olmalı. Aynı işin görünür kaldığı, az sayıda tutarlı uyarlama bana daha mantıklı geliyor. Her yeni yerleşim için kullanıcıya açıklama göstermek gerekiyorsa önce yerleşimi sorgularım. Belki içerik fazla hareket ediyordur. Belki kontrolün yeni yeri öncekiyle hiçbir ilişki kurmuyordur. İyi bir animasyon yardımcı olabilir ama belirsiz bir düzeni tek başına çözmesini beklemem.

Haber okumakla video izlemek aynı tasarım cevabını istemiyor

Bir haber ürününde geniş ekran için ilk akla gelen düzen, makalenin yanına ilgili içerikleri koymak olabilir. Ben burada biraz temkinli olurdum. Kullanıcı telefonu yazıyı daha rahat okumak için açmışsa sürekli görünen öneriler asıl isteğinin önüne geçebilir. Rahat bir metin genişliği, daha anlaşılır görseller ve gerektiğinde açılan içindekiler bölümü bazen daha faydalıdır. Her boşluğu doldurmak zorunda değiliz.

Videoda ise başka bir karar var. Ekranın genişlemesi, videonun çekildiği oranı değiştirmiyor. Alanı tamamen doldurmak görüntüden önemli bir kısmı kesebilir. Görüntünün tamamını göstermek ise kenarlarda boşluk bırakabilir. Bu tercihi bilinçli ele alır, altyazıların kontrollerle çakışmamasını sağlardım. Dikey kısa video, yatay röportaj ve grafiklerle anlatılan bir haber aynı kırpma kararına güvenilerek teslim edilmemeli. Konuşanın yüzüyle grafikteki bir sayı aynı şekilde tolere edilemez.

İşin ticari tarafı da var. Geniş alan; reklam, abonelik teklifi veya öneri yerleştirmek için cazip görünebilir. Ama önce o alanın kullanıcının yaptığı işi nasıl etkilediğini sorardım. HMI renkleri üzerine yazımda dikkati hangi öğelerin paylaştığına odaklanmıştım. Burada da kendimi benzer bir soruya dönerken buluyorum. Bağlamlar ve sonuçlar farklı olsa da ekrana eklenen her unsurun dikkat üzerinde bir etkisi var.

En güzel yerleşimi klavye açıldığında tekrar değerlendirin

İki alanlı bir ekran sunumda çok dengeli görünebilir. Sonra kullanıcı adını yazmaya başlar ve klavye açılır. Form alanı, hata mesajı, rezervasyon özeti ve devam butonu için kalan yükseklik bir anda azalır. Ekranın birkaç saniye önce büyük olması artık pek bir şey ifade etmez. Kullanıcı girdiği değeri veya nasıl devam edeceğini göremiyorsa tasarımı yeniden düşünmek gerekir.

Yazı yazılan durumu, klavyenin kapalı olduğu durumla birlikte tasarlamak isterdim. Yardımcı alan geçici olarak küçülebilir. Formun kendi içinde kayması gerekebilir. Belki de kocaman rezervasyon özeti o aşamada hak etmediği kadar yer kaplıyordur. Hangi çözüm seçilirse seçilsin, girilmiş değerler ve hata mesajları klavye açılırken veya ekran alanı değişirken birbirinden kopmamalı. Bir hata açıklamasının ilgili alanın çok uzağında kalması da bu kopuşa dâhil.

Dil bu incelemeyi daha gerçekçi yapıyor. Bir dilde kısa olan buton etiketi, başka bir dilde daha uzun bir ifadeye dönüşebiliyor. Hata mesajlarında fark daha da büyüyebiliyor. Bu yüzden İngilizce ve Türkçe ekranları gerçek metinlerle, uzun isimlerle, tarihlerle ve tutarlarla kontrol ederdim. Metnin uzaması istisna değil; iki dilli bir ürünün normal çalışma koşulu. Katlanabilir ekran daha fazla yer sunsa da metinle ilgili kararları ortadan kaldırmıyor.

Erişilebilirlik için daha iyi bir fırsat olabilir

Bu hikâyenin umut verici bir versiyonunda daha büyük yazılar, rahat kontroller ve anlaşılır gruplamalar var. Başka bir versiyonunda ise yeni alanın tamamını daha fazla bilgiyle dolduruyoruz. Ben ilkini bilinçli bir tasarım hedefi yapardım. Yoksa “daha yetenekli arayüz” dediğimiz şey, fark etmeden yalnızca daha kalabalık bir arayüze dönüşebilir. Özellikle de tasarımları hep varsayılan yazı boyutunda değerlendiriyorsak.

Web içeriği için W3C’nin Reflow rehberi, içerik büyütüldüğünde veya görünüm daraldığında bilgi ve işlevlerin korunmasını ele alıyor; iki boyutlu düzen gerektiren içeriklere ilişkin istisnaları da açıklıyor. Bu, deneyimin web tarafında kullanılabilecek bir referans. Yerel uygulamanın bütün erişilebilirlik gerekliliklerini karşıladığını söyleyen tek başına bir onay değil. W3C: Reflow.

Yerel uygulamada ayrıca büyük metni, ekran okuyucu odağını, azaltılmış hareket tercihini ve alanlar açılıp kapanırken okuma sırasını kontrol ederdim. Kullanıcı bir mesaja odaklanmışken yeni beliren menünün odağı almasını istemem. Geçiş animasyonu neyin nereye gittiğini anlatmaya yardımcı olabilir. Yine de kullanıcı bu animasyonu görmeden veya hareketi azaltarak kullandığında da arayüzü anlayabilmeli. Ekran açılınca erişilebilirlik açısından yeniden başlamak zorunda kalmamalı.

Ben Figma dosyasına ne koyardım?

Birbirinden bağımsız on güzel ekran yerine tek bir işi baştan sona ele alırdım. Mesela otel seçimi. Küçük ekranda sonuç, geniş ekranda karşılaştırma, dar uygulama penceresi ve yeniden küçük ekrana dönüş. Hepsinde aynı tarihler, aynı otel ve aynı filtreler bulunurdu. Böylece sürekliliği uzun uzun anlatmadan da görebilirdik. Bir frame’de başka otel, diğerinde başka fiyat kullanmak bu incelemeyi gereksiz zorlaştırır.

Sonra tasarımı rahatsız eden durumları eklerdim: uzun Türkçe başlık, boş sonuç, yavaş yükleme, açık klavye ve işlem sonrasında görünen hata. Bunlar yerleşimin gerçekten bir kurala sahip olup olmadığını hızlıca gösteriyor. Hangi alanın kaydığı, seçim durumunun nerede tutulduğu ve yardımcı bölüm kapanınca neyin görünür kaldığı da dosyada yazardı. Sadece iyi görünen örnek verinin tasarımı taşımasına güvenmezdim.

Geliştiriciye aktarırken geçişleri günlük dille anlatırdım. “Seçilen oteli ve tarihleri koru. Alan daralınca ayrıntıyı göster. Geri dönüşte mevcut sonuç listesine dön.” Bu davranış tartışılabilir ve geliştirilebilir olmalı. Frame’lerin arasındaki boşlukta ne olduğunu geliştiricinin tahmin etmesini beklemek istemem. O konuda anlaşınca boşluk, tipografi ve hareket kararları daha sağlam bir zemine oturur. Tasarım dosyası da yalnızca referans görsel olmaktan çıkar.

Ben kullanıcının kaç kez başa döndüğünü ölçerdim

Geniş ekranı göstermek kolay. Daha iyi deneyimi göstermek içinse gerçek bir görev gerekiyor. Katılımcılardan belirli bir bütçeyle otel seçmelerini, konumunu kontrol etmelerini ve bir kesintiden sonra rezervasyona dönmelerini isterdim. Bazıları küçük düzende, bazıları geniş düzende, bazıları da aralarında geçiş yaparak ilerlerdi. Amacım yerleşimin hangi noktada yardımcı olduğunu ve hangi noktada yeni iş çıkardığını görmek olurdu.

Tamamlama durumuna, hatalara, tekrarlanan aramalara, kaybolan taslaklara ve gereksiz geri dönüşlere bakardım. Kullanıcının “Seçtiğim şey nereye gitti?” dediği anları özellikle not alırdım. Telefonu açmaya değip değmediğini de sorardım. Bir kişi işi başarıyla bitirip yine de geniş ekranı fazla kalabalık bulabilir. İki panelin yan yana ne kadar etkileyici göründüğünden daha değerli bir geri bildirim bu.

Oturum süresinin artmasını da tek başına başarı saymam. Zor bir karşılaştırma da insanı ekranda uzun tutabilir. İlk varsayımım, geniş düzenin belirli bir çabayı azaltacağı olurdu; araştırmada bunun tersini gösteren bulguları da arardım. Buradaki örneklerin arkasında yapılmış kullanıcı testleri veya ölçülmüş iyileşme oranları yok. Anlattıklarım, bu ürün üzerinde çalışsam denemek ve değerlendirmek isteyeceğim yaklaşımlar.

Benim beklediğim yenilik biraz daha gündelik

Katlanabilir iPhone ilgimi çekiyor çünkü alıştığımız bazı tasarım tavizlerini tekrar sorgulatıyor. İki ürünü karşılaştırırken neden sürekli listeye dönüyorum? Adresi okurken harita neden kayboluyor? Daha rahat çalışmak için ekranı açtığımda neden bazen yalnızca daha fazla dikkat dağıtıcıyla karşılaşıyorum? Bu soruların her biri, gösterişli bir yeni özellikten daha küçük ama tasarlanabilir bir problemi işaret ediyor.

Her uygulamanın büyük bir dönüşüm geçirmesine ihtiyacım yok. Seçtiğim oteli hatırlayan bir rezervasyon uygulaması, okuduğum paragrafı koruyan bir haber sayfası ve yarım cümlemi kaybetmeyen bir mesajlaşma ekranı beni memnun eder. Bunlar lansman sunumunda çok iddialı duyulmayabilir. Ama geniş ekranı tekrar açmak istememi sağlayacak ayrıntılar tam da bunlar. Yeni alanın değerini günlük kullanımda biriktirirler.

Telefonu açtığımda, zaten yapmakta olduğum işe biraz daha yer açmışım gibi hissetmek istiyorum. Figma’ya taşıyacağım tasarım hedefi bu olurdu — ortaya çıkan işi de bunun üzerinden değerlendirirdim.