Tasarım, tasarımcı içindir — Storyly Studio
Tasarım, tasarımcı için midir yoksa toplum için midir? Gibi bir tartışma konusu aklınıza gelmesin. Bu yazıda WYSIWYG editör tasarlamaktan bahsedeceğiz.
--
Açılımı what you see is what you get olan, sanıyorum 80'lerden bu yana hayatımızda olan ve kabaca tanımlarsak: “Ekranda yaptığınız değişikliklerin, çıktı alacağınız ortam için de birebir aynısı olacağını garanti eden sistemlerdir” diyebiliriz. Mesela Microsoft Word ya da Storyly Studio.
Sonraki kısımların daha iyi anlaşılması için üründen bahsetmem gerekiyor. Storyly, mobil uygulamalarınız için story formatında içerikler üretmenizi sağlayan ayrıca oluşturduğunuz storyleri CTA, Poll, Quiz, Rating, Countdown gibi interaction elementleriyle desteklemenize imkan veren hatta custom source yaratıp, otomatik storyler oluşturabileceğiniz ve hatta bu storyleri kullanıcıya göre segmentleyebileceğiniz bir user engagement aracıdır. Daha fazla bilgiye buradan ya da şuradan ulaşabilirsiniz.
Storyly, Analitik ve Studio olmak üzere iki kısımdan oluşmakta. Analitik tarafında tahmin edebileceğiniz gibi storylere ait verileri izliyorsunuz. Studio tarafında ise storyleri oluşturuyorsunuz. Bu yazıda işin eğlenceli kısmı(aramızda kalsın) Studio’yu konuşacağız.
Neden işin eğlenceli kısmı diyorum? Çünkü WYSIWYG sınıfına giren bir aracı tasarlamak herkese nasip olmuyor. Bazı işler vardır tadını çıkararak yapmak isteyeceğiniz. İşte Storyly Studio benim için tam da böyle.
Bir de ekip olarak Studio’yu yaptıktan sonra kendime sadece tasarımcı değil de story tasarımını yapacak tasarımcının, tasarımı yapacağı arabirimi tasarlayan tasarımcı! gibi bir unvan verdim. Çok hoşuma gitti:)
Kimin için yaptık?
Az önce analitik kısmından bahsetmemin sebebi burada detaylandıracak olmaktı. Çünkü Storyly’de özellikle büyük müşterilerin kullandığı team management yapısı var. Örneğin 100m indirme almış bir uygulamanın CEO’su analitik verilerini kontrol ederken aynı şirketin pazarlama ekibi daha çok Studio tarafında vakit geçirebilir. Bu da bizi haliyle dijital pazarlama uzmanları hangi araçları sık kullanır? Alışkanlıkları nelerdir? Gibi soruları sormamıza neden oldu.
Fakat diğer yandan mobil uygulamasını yaparken tüm süreçleri tek başına yürüten indie developer olarak adlandırılan müşterilerimiz de var. Bu tek başına dev kadro olan insanlar her zorluğa göğüs geriyor. Haliyle bizim de bir zorluk çıkarmamız… Yakışık almazdı.
Bu sebeple temel amacımız ürünümüzde olması gereken ve kullanıcılarımızın ihtiyaçlarının kesiştiği noktayı en sade haliyle Studio’ya dönüştürmek. Tabiri caizse Photoshop’un story için olanını yapmaya hiç niyetimiz yok:)
Eh… Başlıkta “tasarım, tasarımcı içindir” yazdık ama aslında Storyly’nin Studio tarafı; uygulama sahipleri, indie developerlar ve marketingçiler için.
Tadaa! Storyly Studio karşınızda…
Yukarıda, Instagram’dakine benzer komponentleri görünce Steal Like an Artist kitabındaki bazı sayfaların gözünüzün önüne geldiğini biliyorum.
Ve Jakob Nielsen der ki:
Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. Design for patterns for which users are accustomed.
Jakob Nielsen’ın yaklaşımındaki site tanımını; mobil uygulamalara, sosyal medyalara ve çok fazlasına yorabiliriz. Üstteki görselde interaktif komponentlerimizin Instagram’la neredeyse aynı deneyimde olduğunun product ekibindeki arkadaşlarım da farkında ama bunu bile isteye yaptığımızı söyleyebilirim.
Hali hazırda insanların alışık olduğu deneyimden yararlandık. Fakat yine de Storyly’nin farklılaştığı noktalara daha yakından bakmak isterseniz sizi şöyle alalım.
Şimdi kısa başlıklar halinde neyi neden yaptık, neleri göz önünde bulundurduk, hatalarımız nelerdi ve sonrasında ne gibi gelişmeler oldu biraz bunlardan bahsedeceğim.
Neden Dark Mode?
Görselleri ön plana çıkarmak, az ışıklı ortamlarda kullanılacak olması ya da geceleri daha çok kullanıcının aktif olmasıyla pek alakası yok.
Aslında ürüne girdiğinizde sizi direkt Studio karşılamıyor. Analitik, Story Group List, Story List gibi sayfalara benzer mimariyle ulaşıyorsunuz. Fakat Studio’nun yapısı biraz daha farklı. Çünkü bir storyi editlemek istediğinizde Studio’ya yönlendiriliyorsunuz. Böylece ürünün genel hattındaki navbar, breadcrumb gibi yönlendirici ögeler kayboluyor. Ve bu durumu dark mode ile daha iyi anlatabileceğimizi düşündük.
Kullanıcıya “Navbar ve breadcrumb kayboldu panik yapma, şu anda ürünün içindesin ama her zaman yaptığından daha başka bir şeyler yapacaksın” demeye çalıştık. Özellikle ilk kez gelen kullanıcılar için bu çok önemli bir nokta.
Neden Inline Edit değil?
“WYSIWYG bir editörde nasıl inline edit olmaz” dediğinizi duyar gibiyim. Belki de text ya da buton gibi daha basit komponentleri inline edit yapabilidik fakat Gestalt Prensiplerinden yakınlık ilkesi ve tasarım ilkelerinden tutarlılık ilkesini göz önünde bulundurduğumuzda böylesinin daha doğru olacağını düşündük.
Yukarıdaki örneği baz alırsak, kullanıcının countdown’ın tarih kısmını inline edit yapıp, diğer özelliklerini başka bir yerden değiştirmesi pek doğru bir yaklaşım değil. Haliyle bunun gibi bir kaç komponentte bu yakşalımı izlemek zorunda kaldığımız için text gibi basit alanlarda da inline edit yerine sol taraftan editlemeyi uygun gördük. Bu, çok kullanışlı olmasa da editle ilgili tüm yükün sol tarafta olup, birbiriyle ilişkili tüm editlenebilir alanların bir arada bulunmasını sağladı.
Her ortamda aynı görüntüyü nasıl sağlıyoruz?
Yazının başında ekranda yaptığınız değişikliklerin, çıktı alacağınız ortam için de birebir aynısı olacağını garanti eden sistemlerden bahsetmiştik. Ancak Storyly’de durum farklı. Çünkü burada bir sosyal medya postu ya da statik bir görsel hazırlamıyorsunuz.
Storyly’i iOS, Andorid, React Native ve Flutter ortamlarında yazılmış uygulamalara entegre edebiliyorsunuz. Ve Studio’da eklediğiniz bir komponentin, bu dört ortamda yazılmış uygulamaların hepsinde aynı sonucu vermesi gerekiyor.
Burada tabii ki yazılımcı arkadaşlarıma çok iş düşüyor. Ancak bana düşen görev yaptığım her biçimsel değişiklik için “ dört ortam için de destekleniyor mu?” sorusunu sormak. Desteklemiyorsa birlikte alternatif çözümler üretmek.
…ve 1 yıl sonra
İlk fazı başarıyla tamamlayan Storyly Studio artık kabına sığmamaya başladı. Ve ekipçe kolları tekrar sıvadık. Bu süreçte gözlemlediğimiz bazı problemleri listeleyip, bunların bir kaçında nasıl yol izlediğimizi anlatarak yazıyı tamamlayacağım.
Problemler
- Interaktif komponentlerin özellikleri kalabalıklaşıyor
- Her story için branding renklerine göre buton, text yapmak isteyenler renkleri kaydedilmiyor.
- Storylerdeki objelerin(ör: buton) yeri korunarak çoğaltılamıyor.
- Image yüklemeden sıfırdan story üretilemiyor. Bu nedenle düz renge sahip bir story oluşturulamıyor.
- Ekran boyutları değişse de story kanvası statik olduğu için ortadaki alanı iyi kullanamıyoruz.
- Studio’nun içindeyken başka story groupa geçilemiyor.
- Kısayollar ve klavye tuşlarına görev tanımlanmadı.
Interaktif Komponentler
Başlangıçta amacımız her bir interaktif komponentin bütün özelliklerini kendi içinde bir arada tutmaktı. Fakat aşağıdaki görselde sol tarafta gördüğünüz gibi interaktif komponentlerin özellikleri gitikçe kalabalıklaşıyor. Artık estetik olarak da kullanılabilirlik olarak da işimizi görmüyordu. Komponentlere bazı eklemeler yapmamız gerektiğinde işimizi biraz zorlaştırıyordu. Diğer yandan Studio’ya giren kullanıcı için sanki bir kaos varmış izlenimi bırakıyordu.
Users are more tolerant of minor usability issues when they find an interface visually appealing.
Yukarıdaki görselde bulunan sağdaki yapı, interaktif komponentlerin eklenmesi akışındaki yeni yaklaşımımız. Interaktif komponenti storye ekledikten sonra ilgili komponentin özelliklerini üzerine çift tıklayarak açılan bir popupta verdik. Yani inputları gizledik. Çünkü kullanıcı ilgili inputları bir kez doldurduğunda tekrar editleme ihtimalinin çok düşük olduğunu fark ettik. Bu sebeple sürekli göz önünde bulunmasına hiç gerek yoktu. Böylece hem bu input kaosunu azaltmış olduk hem de ilk kez gelen bir kullanıcı için burada neler olduğunu daha iyi anlatan bir yapı kurduk.
Renk Kaydetme, Story Çoğaltma, Create from Scratch
Ekibimizin kararıyla normalde Studio’ya girmeden yapılan upload flowlarını studio içine taşıdık. Böylece “Create from Scratch” sorununu çözebildik. Ayrıca upload flowları studio içinden yapıldığı için artık story kanvasını daha fonksiyonel kullanabiliyoruz. Mesela kanvasın altına color picker ekleyerek branding renklerini kaydetme problemini çözebildik. Ve bir storyi çoğaltmak hiç bu kadar kolay olmamıştı, duplicate’i de ekledik!
Ekran kırılımları (Dikey)
Yapılacak bir tasarımda neyi neden yapacağınız kadar hangi ortam için yapacağınız da önemlidir çünkü alacağınız kararları doğrudan etkiler. Örneğin outdoor tasarımı yapacağınızı düşünün. Bir ihtimal amacınız hızlı hızlı geçen arabalara saniyeler içerisinde bir şeyler anlatmak olabilir. Ya da Grammy’de tüm dikkatleri üzerine çekmek isteyen Daft Punk’ın kostümlerini tasarlayacak olabilirsiniz.
İlk faz için Studio’daki story kanvasına sabit bir ölçü vermiştik. Bunu yaparken FullStory verilerine bakmıştık. Çok iyi bir sonuç almayacağımızı bilsek de hemen hemen her ekranı kapsayacak şekilde bir ölçü belirlemiştik. Bunun yansıması olarak bazı ekran çözünürlükleri için kanvas alanını verimli kullanamıyorduk. Ekipçe buradaki deneyimi yeniden düşünmeye başladık.
“Genelde” desktop için bir ekran tasarlayacağımız zaman yatay ekseni baz alarak kırılımlar veririz. Örneğin; genişlik 1200'den küçükse nasıl gözükür, 1200 ile 1600 arasındaysa nasıl gözükür ya da 1600den büyükse nasıl gözükür gibi. Bu durum bizim ürünümüzün hangi aygıtlarda çalıştığına göre ya da kullandığımız altyapıya göre değişiklik gösterebilir.
Fakat bu kez dikey kırılımlara ihtiyacımız vardı. Çünkü kullanıcılardan Studio’ya yükleyecekleri görsellerin 9:16 oranında olmasını istiyorduk. Ve doğal olarak ekranınız ne kadar geniş olsa da story kanvasının ölçüsünü yükseklik belirliyordu.
Daha iyi anlatabilmem için aşağıdaki iki görselin yeşil kısımlarını ekran olarak düşünelim. Genişlikleri aynı olan bu ekranların içindeki 9:16 oranındaki kanvasın ölçüsünü ekranların yükseklikleri belirliyor.
Burada farklı dikey uzunluklardan en iyi verimi almak için izlediğimiz yolu anlatırken, resolution verilerinde başı çeken 1440x900 çözünürlüğünü ve Chrome’u baz alacağım.
Bu kez daha ince hesaplar yapmamız gerekiyordu:) Yükseklik 900 ama kullanıcının Chrome tarayıcıda yer imlerini göstermesi bile 32 pixele mâl oluyordu. Kaldı 868px. Genel kullanımda olacağını düşündüğüm için üst bar ve docku da çıkardığımızda yükseklik 696 pixele kadar düşüyordu.
Pixel pazarlıklarına girmemizin diğer bir nedeni ise 1280x720 gibi yüksekliği daha az olan ekranlar. Çünkü storyi bu küçük monitörlerde tasarlarken, kanvası gösterebildiğimiz kadar en büyük şekilde göstermek istiyoruz. Bir de storyleri Studio’da yan yana dizeceğimiz için olası dikey scrollu önlemeye çalışıyoruz.
Vee Storyly Studio tekrar karşınızda!…
Günün sonunda hepimizin içine sinen şeyler ortaya çıkardık. Storyly ekibindeki arkadaşlarımın elbette benden çook fazla emekleri vardır. Ben naçizane minik bir kısmını yazmak istedim.
Umarım her zaman severek yapacağınız işlerde yer alırsınız. Okuduğunuz için teşekkür ederim.
Kaynaklar:
