Kullanıcı Deneyimi ve Arayüz Tasarımında İlk Yılım
Bir Aceminin Gözünden Uı/Ux yazısını yayınlayalı bir yıl geçti. O günden bugüne dek pek çok farklı şey deneyimledim ve hala daha deneyimlemeye devam ediyorum.
Bu yazıda o süreci anlatmak yerine o süreçte yaptığım hatalardan, yanılgılarımdan ve öğrendiklerimden (en azından öğrenebildiklerimden) bahsetmek istiyorum. Yazının sonunda bunu hala öğrenememişsin dediğiniz bir şey varsa lütfen belirtin.
1) Title takıntısı
Ufak bir itiraf ile başlamak istiyorum başlarda fena halde title takıntısına sahiptim, Dribbble ve diğer mecralarda pek çok kez iş unvanımı değiştirdim. Çoğunlukla bir ürünün tüm görsel materyallerini tasarladığım için kendime kısa bir dönem Product Designer deme gafletine düştüm. O dönem bir Product Designer’ın alanının ne kadar geniş olduğundan bihaber, cahilliğim ile mutlu mesut dolanıyordum ta ki…
Sherpa Blog’ta bu yazıya rastlayana dek. Eğer siz de bu konuda bitmek bilmeyen bir Meksika açmazına düştüyseniz bu yazı sizi aydınlatacaktır.
Yaptığım en büyük hatalardan ve yanılsamalardan birinden kurtulduktan sonra fark ettim ki önemli olan şey iş unvanınız değil sizin işinize veya elinizdeki ürüne nasıl sahip çıktığınızdır. Projenin üretim sürecinde sırf Arayüz tasarımcısı olduğunuz için veya sırf Kullanıcı Deneyimi Tasarımcısı olmadığınız için dışlanacak değilsiniz. Tabi bu kalkıp kendi sorumluluğunuzda olmayan görevleri yapın veya kendi görevinizi aksatın demek değil ama tüm o süreci takip edebilirsiniz.
2) Organize Çalış(a)mamak
Bir arayüz tasarlarken öncelikli hedeflerimiz neler olmalıdır?
- Erişilebilir olmalı.
- Sürdürülebilir olmalı.
- Kullanılabilir olmalı.
Bu hedefler doğrultusunda tasarlıyor ve kullanıcılara hizmet sağlıyoruz. Ben proje sürecinde (umarım bu kısım sadece bana özgü değildir) organize katmanlar oluşturmak yerine dağınık veya isimsiz katmanlar ile çalışıyordum. Copy uzantılı gruplar, çift haneli şekiller ile insanı (çoğunlukla ekip arkadaşlarımı) çileden çıkaran bir dosya teslim ediyordum. Kısa bir sürede bu durumun farkına varıp daha organize çalışmaya başladım ve Tasarım sistemleri hakkında epey bir kaynak tükettim.
O yazılardan birkaçı;
Bu yazıları okuduktan sonra kendi çalışma biçimimi yeniden ele aldım tasarıma geçmeden önce renk paletimden, efektlere kadar her şeyin yer aldığı bir şablon oluşturdum yaptığımız projenin ihtiyaçlarına göre bazen eklemeler ve çıkarmalar yaparak bu şablonla çalıştım.
3) Tool Fanatizmi
Sketch çıktıktan sonra tasarım sektöründe büyük değişiklikler yaşandı insanlar Adobe’nin zulmünden kurtulup daha basit ve hızlı araçlarla çalışmaya başladı sonra işler kızıştı Figma, Adobe Xd ve Invision derken pek uzak olmayan galaksimizde Tool savaşları başladı.
İşin güzel tarafı bu tartışmalar firmaları harlayarak daha fazla üretmelerine neden oldu bu da bizim işimize yaradı. Ardı ardına gelen yenilikler, hayat kurtarıcı pluginler ile alternatiflerimiz çoğaldı. Böyle bir ortamda tek bir araca bağlı kalıp diğerlerine karşı muhafazakar bir tutum izlemek muhtemelen kariyeriniz için iyi bir seçim olmayacaktır. Ben de elimden geldiğince yeni tooları, pluginleri denemeye ve öğrenmeye çalışıyorum bu konuda en faydalı ve güncel kaynaklardan biri designcode.io incelemenizi tavsiye ederim.
4) Tasarımı Dribbble için değil çözüm için üretmek
Bir tasarımcı olarak var olduğunuzu kanıtlamanın ve yeteneklerinizi göstermenin en iyi yolu bir portfolyo sahibi olmaktan geçer. Bu yüzden Behance ve Dribbble gibi platformlarda milyonlarca tasarımcı çalışmalarını yayınlıyor, projelerinden bahsediyor. Son zamanlarda yayınlanan tasarımların çoğunun amacı ise sadece Dribbble’da yer alması oluyor. Çalışmayı incelediğinizde ise uçan kaçan animasyonlar, beyaz zeminde gölgeli kutular, yine beyaz ekranda mavi ve beyaz ağırlıklı yönetim panellerinden başka bir şey göremiyorsunuz ve tüm çalışmalar sanki birbirinin aynısı gibi gelmeye başlıyor.
Geçen haftalarda ProtoPie derslerinden sonra antreman için hazırladığım tasarım hoşuma gitmiş ve Dribbble’da yayınlamıştım. Daha sonra geri dönüş almak için toplulukların Slack kanallarında çalışmamı paylaştım ve şu yorumu aldım.
Bu yorumdan sonra nasıl görünmeli? yerine neden böyle olmalı? sorusuna eğilmeye başladım, çünkü dediğim gibi bir tasarımcının kendini anlatmasının en iyi yolu portfolyodan geçiyor ve portfolyonuzda ki işler sadece hoş görüntüden ibaretse ve siz tasarımda neyi neden yaptığınızın cevabını veremiyorsanız hala eksikleriniz var demektir. Bu yüzden son günlerde Dribbble’da yayınlanan işlerin niteliği de tartışılmaya başlandı.
Özetle işimiz elbette estetik kaygı güden tasarımlar üretmek ama bu bizim sanatçı olduğumuz anlamına gelmiyor. Bu yüzden kullanılabilirlikten uzak, asla kodlanamayacak, sadece görsellikten ibaret olan çalışmalar üretmek yerine kendinize daha gerçekci briefler vererek kodlanabilir ve sürdürülebilir tasarımlar üretmeye çalışmanız portfolyonuz için daha faydalı olacaktır.
Bunun için Tugay Balcı’nın Kodla konuşmasını bırakıyorum (Kullanıcı Deneyimi ve Kullanıcı Arayüzüne dair ilk bilgilerimi bu konuşmada edindim);
5) Ekip içi İletişim
Projenin üretim sürecinde tüm ekibin üzerinde belirli bir stres ve baskı var kimi ekiplerde bu aşırı şekilde hissedilirken kimisinde de o kadar fazla hissedilmiyor. Bu ortamda muhtemelen her tasarımcı tasarımını çok farklı şekilde hatta çok alakasız bir halde görebilmektedir.
Ürün geliştirme sürecinde yazılımcılar bir yandan uygulamayı veya siteyi yapmaya diğer yandan da teslim süresine kadar projeyi yetiştirmeye çalışmaktadır ve onlar için önemli olan şey uygulamanın çalışıyor olmasıdır. Tüm bu süreçte tasarımcı olarak siz sadece tasarım dosyasını Zeplin’den veya Avacode’dan teslim edip köşenize çekiliyorsanız muhtemelen beklediğiniz çıktıyı alamamanızın nedeni budur.
Ekip arkadaşlarınız ile birlikte içinde bulunduğunuz ortamda proje sürecinin yanı sıra aranızdaki iletişimi de tasarlamalı ve yönetmelisiniz. Çünkü her ne kadar muazzam tasarım sistemleri ve gelişmiş programlama dilleri ile çalışırsanız çalışın aranızdaki kopukluklar er ya da geç iş sürecine yansıyacaktır. Son olarak ben tasarımcıyım abi onu da mı ben yapayım tavrını takınmak iyi sonuçlar yardımcı olmuyor (kişisel tecrübe).
Yazılımcının işini kolaylaştırmak için ama diğer yandan da tasarımımı birebir görmek istediğimden yeri geliyor Github’da, Codepen’de kaynak kod tarıyorum böylelikle hem ben istediğimi alıyorum, hem de yazılımcının zamanından çalmadan ve tabii ki sunmayı planladığı bahanelerin önününü kapayarak işi teslim ediyorum. Buna ek olarak kullanılacak animasyonları Protopie’da hazırlayıp abi bak bu buradan şöyle geçecek böyle gelecek yerine direkt gösterebiliyorum.
Protopie Eğitim ve Kaynak
Bu şekilde prototipler hazırlayarak veya Lottie üzerinden güzel animasyonlar kullanarak ve biraz da kodlanabilir bir tasarım çıktısı teslim edersiniz arada yaşanacak onca gereksiz ve motivasyon düşürücü konuşmadan kaçınmış olursunuz. Buna rağmen hala yazılımcı inatla kendi bildiğini okuyorsa o zaman sorun başka yerde demektir.
6) Kişisel Challengelar ve Pratik Yapmak
Tasarımcı olmak sürekli olarak kendini güncel tutmak ve üretmek demek hele bir de daha yeni başlamışsan olmazsa olmazlardan. Kendinize bir brief vererek veya Uplabs, Dribbble Weekly Warm-Up, Daily Ui Challenge ve Sharpen gibi platformlarda aradığınızı bulacaksınızdır.
Benim anlatacaklarım bu kadar gördüklerimi ve deneyimleri daha sık yazmaya çalışacağım son olarak şunu söyleyebilirim ki geçirdiğim şu son bir yılda hevesle üreten ve paylaşan, İşini tutkuyla yapıp eğlenceli bir çalışma ortamı sunan ve ilk yılımın güzel geçmesinde payı olan insanlara ne kadar teşekkür etsem az.
