UXPin İncelemesi: Prototiplemede Nereye Kadar İşe Yarıyor

UXPin, tarayıcıda çalışan bir arayüz tasarımı ve prototipleme aracı. Çizim yetenekleriyle değil, prototipin gerçek bileşen davranışına ne kadar yaklaştığıyla ayrışıyor. Aşağıda aracın karşılığını verdiği yerleri ve fazladan yük getirdiği yerleri ayırdım.

Asıl kazanç durum tabanlı prototiplerde

UXPin'in tek gerçek farkı burada. Bir butona, bir input alanına ya da bir karta birden fazla durum tanımlayıp aralarındaki geçişi tıklamaya, hover'a veya bir koşula bağlayabiliyorsun. Boş liste, yükleniyor, hata, dolu liste. Dört ekranı ayrı ayrı çizmek yerine tek bileşenin dört halini tanımlıyorsun ve testi yapan kişi akışı gerçek ürün gibi geziyor.

Statik ekranları genelde daha hafif araçlarla çizerim; UXPin'e ancak akışta koşullu bir davranış test edilecekse geçerim. Tıklanabilir görsel yığını isteyen bir sunum için kurulum maliyeti fazla.

Kütüphane hızı sonradan gelir

Hazır iOS ve Material bileşenleri, ikon setleri, platform şablonları. Tanıtımlarda bunlar ilk günden hız vaadi olarak anlatılıyor ama işleyiş öyle değil. İlk projede sürükle bırak ile kurduğun ekran, kendi ürününün diline benzemediği için baştan özelleştiriliyor. Hız, kendi bileşenlerini kütüphaneye taşıdıktan sonra başlıyor.

Yani "öğrenme eğrisi dik" eleştirisiyle "prototipi dakikalar içinde çıkar" vaadi aslında çelişmiyor, sadece aynı cümlede söylenmemeleri gerekiyor: kurulum yavaş, sonrası hızlı. Tek ekranlık bir fikir için bu yatırımı yapma. Aynı ürüne aylarca dokunacaksan yap.

Bileşen güncellemesi tasarımda yayılır, kodda yayılmaz

Merkezi kütüphanede bir bileşeni değiştirdiğinde bunun tüm projelere yansıması doğru, büyük ekiplerde tutarlılığı gerçekten kurtarıyor. Ama otomatik yayılma tasarım dosyalarının içinde kalıyor. Üründeki butonun padding değeri, tasarımcı kütüphanede padding'i değiştirdi diye değişmiyor; birinin gidip kodda karşılığını bulması gerekiyor.

Devir teslimi ölçerken bakılacak yer burası: tasarım sistemindeki bir değişiklik üretime kaç dosya değişikliğiyle iniyor? Bu sayı bileşen sayısıyla birlikte büyüyorsa tasarım tarafında kurulan tutarlılık koda geçerken kayboluyordur ve araç değiştirmek bunu çözmez.

Spec Mode ve dokümantasyon

Spec Mode, seçilen elemanın renk, tipografi ve ölçü değerlerini hazır CSS olarak veriyor, elemanlara not düşülebiliyor. Karmaşık edge case'leri tasarımın üstünde bırakmak, sonradan yazılan bir wiki sayfasından daha iyi çalışıyor.

Çıkan CSS'i olduğu gibi kopyalama. Üretilen kod o tek elemanı tarif ediyor, senin değişkenlerini bilmiyor; kopyalayıp yapıştırdığında projede bir kez daha 14px, bir kez daha #4A4A4A oluşuyor. Değeri token'a bağla, kopyayı bırak.

Eksikler

• Öğrenme eğrisi dik. Ekipte bir kişinin aracı sahiplenmesi gerekiyor, herkesin yarım öğrendiği bir kurulum dağılıyor.
• Tüm ekranları tek karede gösteren kuş bakışı görünüm zayıf; akış büyüdükçe nerede olduğunu kaybediyorsun.
• Illustrator entegrasyonu yok. Sketch ve Photoshop dosyaları katman yapısıyla içe aktarılıyor, Illustrator tarafında dışa aktarmayla uğraşacaksın.

Kime uygun

Tek başına çalışan tasarımcı ya da tek seferlik bir fikir sunumu için ağır kalıyor. UXPin, aynı ürünü uzun süre taşıyan, tasarımcıyla geliştiricinin aynı bileşen sözlüğünü kullanması gereken ekiplerde karşılığını veriyor. Kararı verirken şunu sor: prototipin gerçek durumları taşıması senin için gereklilik mi, yoksa hoş bir ekstra mı? İkincisiyse daha hafif bir araçta kal.