SaaS Panel UI Tasarımı
Onlarca ekran tek sistemle büyüsün
SaaS ürünleri ekran ekran büyür; her yeni modül kendi butonunu, kendi tablo düzenini ve kendi boşluk ölçüsünü getirir. Bir yıl sonra aynı ürünün içinde üç farklı arayüz dolaşır. Panelin görsel dilini ve bileşen mantığını kurup yeni modüllerin bu sisteme oturmasını sağlıyoruz.
- Modüller arası tutarlı navigasyon
- Varyantlı bileşen kütüphanesi
- Rol ve yetki görünümleri
- Form ve veri giriş tasarımı
Birlikte çalıştığımız markalar
SaaS Panel UI Tasarımı kimler için?
Modül ekleyerek büyüyen ürünler
Yeni özellik geldikçe arayüzü dağılan SaaS ekipleri. Sistem kurulduğunda yeni modül, mevcut bileşenlerin birleşimi olarak çıkar.
Tasarımcısı olmayan yazılım ekipleri
Arayüz kararlarını geliştiricinin verdiği şirketler. Kütüphane ve kurallar yazılı olduğunda bu kararlar tek tek tartışılmaktan çıkar.
Yatırım ya da satış öncesi ürünler
Demo ve deneme sürecinde ürünün olgun görünmesi gereken ekipler. Panelin tutarlılığı, ürünün ciddiyeti hakkında ilk izlenimi veriyor.
Kapsam ve teslimatlar
Navigasyon ve ekran iskeleti
Modül sayısı arttığında çalışmaya devam eden bir menü yapısı kurulur. Kenar çubuğu, üst bar, arama ve kırılım yolu birlikte tasarlanır.
Bileşen kütüphanesi
Buton, form alanı, tablo, sekme, modal, bildirim ve boş durum bileşenleri varyantlarıyla kurulur ve adlandırılır.
Form ve veri giriş tasarımı
Uzun formların bölümlenmesi, zorunlu alan işaretleri, doğrulama mesajları ve kaydetme davranışı tanımlanır.
Rol ve yetki görünümleri
Aynı ekranın yöneticide ve standart kullanıcıda nasıl farklılaşacağı, yetkisiz alanların nasıl gösterileceği tasarlanır.
Ayar, profil ve abonelik ekranları
Ürünün çekirdek akışı dışında kalan ama her kullanıcının uğradığı ekranlar da aynı sistemle kurulur.
Teslim ve dokümantasyon
Ölçüler, bileşen adları ve kullanım kuralları geliştirme ekibinin okuyabileceği biçimde toplanır.
Kütüphaneyi kuran değil, büyüten kural belirleyici
Bileşen kütüphanesi teslim edildiğinde ürün genellikle en derli toplu halinde oluyor. Sorun sonraki aylarda başlıyor. Yeni bir ekran için mevcut butona çok benzeyen ama biraz farklı bir buton gerekiyor, biri kütüphaneyi kopyalayıp değiştiriyor ve kısa sürede aynı işi yapan birkaç bileşen yan yana duruyor.
Bunu önleyen şey dosyanın kendisi değil, ekleme kuralı. Yeni bir varyantın hangi durumda açılacağı, kimin onaylayacağı ve mevcut bileşenin neden yetmediğinin nerede yazılacağı baştan belli olmalı.
Bu yüzden teslimde kütüphanenin yanına kısa bir çalışma düzeni bırakıyoruz. Yeni bir ihtiyaç geldiğinde önce eldeki parçalarla çözülüp çözülemeyeceğine bakılıyor; çözülemiyorsa varyant kütüphaneye ekleniyor ve adlandırma aynı mantıkla yapılıyor. Kural basit kaldığında uygulanıyor, ağırlaştığında ilk atlanan şey oluyor.
Kütüphanenin kod tarafındaki karşılığıyla aynı adları taşıması bu düzeni ayakta tutuyor. Tasarımda kart, kodda panel olarak geçen bir parça, birkaç ay sonra iki ayrı bileşene dönüşüyor. Adlandırmayı iki tarafın birlikte belirlemesini bu yüzden öneriyoruz.
Satır yüksekliği estetik bir karar değil
Panellerde en çok tartışılan konulardan biri yoğunluk. Aynı tabloyu gün boyu kullanan bir operatör ekrana daha fazla satır sığmasını istiyor; aynı ekrana ayda birkaç kez giren bir yönetici ise sıkışık bir tablodan hiçbir şey okuyamıyor. İkisini tek bir ölçüyle memnun etmek mümkün olmuyor.
Bu yüzden yoğunluğu bilinçli bir karar olarak ele alıyoruz. Ürünün asıl kullanıcısı kim, günde kaç saat bakıyor ve ekranda kaç kayıt görmesi gerekiyor sorularını cevaplayıp tek bir ölçü seçiyoruz. Gerçekten gerekliyse yoğunluğu kullanıcının değiştirebileceği bir ayara dönüştürüyoruz.
Karar tek bir değerle de bitmiyor. Satır yüksekliği değişince punto, ikon boyutu, iç boşluklar ve dokunma alanları da birlikte değişmek zorunda kalıyor. Bu yüzden yoğunluğu tek tek ekranlarda değil, bileşen düzeyinde tanımlıyoruz.
Yoğunluk kararı tabloların ötesine de geçiyor. Form alanları arasındaki boşluk, kenar çubuğundaki menü öğelerinin yüksekliği ve kart aralıkları aynı ölçekten besleniyor. Tek bir ekranda verilen sıkıştırma kararı, sistem genelinde uygulanmadığında ürün dağınık görünüyor.
Nasıl çalışıyoruz?
Ürün ve ekran envanteri
Mevcut modülleri, ekranları ve tekrar eden bileşenleri çıkarıyoruz. Birbirinin aynısı işi yapan farklı bileşenler bu listede görünür hâle geliyor.
Navigasyon kararı
Modüllerin nasıl gruplanacağını ve kullanıcının bir modülden diğerine nasıl geçeceğini kuruyoruz. Menü yapısı, ürünün gelecekteki modülleri düşünülerek seçiliyor.
Görsel dil ve anahtar ekranlar
Tipografi, renk, yoğunluk ve boşluk kararlarını veriyor, en karmaşık iki üç ekranda sınıyoruz.
Bileşen kütüphanesi ve durumlar
Bileşenleri varyant ve durumlarıyla kuruyoruz. Boş, hatalı, yükleniyor, devre dışı ve yetkisiz görünümler kütüphanenin parçası oluyor.
Modül yayılımı ve teslim
Kalan ekranları kütüphaneyle tasarlayıp dosyayı ölçüleri ve kurallarıyla teslim ediyoruz.
Kullandığımız araçlar ve platformlar
- Figma
- Figma Dev Mode
- Storybook
- Maze
- Stark
SaaS Panel UI Tasarımı fiyatını neler belirler?
Modül ve ekran sayısı
Panelin kaç modülden oluştuğu ve her modülde kaç ekran bulunduğu kapsamın temelini belirler.
Rol yapısının karmaşıklığı
İki rol ile yedi rol arasında büyük fark var. Her rol, aynı ekranın ayrı bir görünümü demek.
Mevcut sistemin durumu
Kullanılabilir bir bileşen kütüphaneniz varsa çalışma uyarlamayla ilerler. Yoksa kütüphane sıfırdan kurulur.
Koyu tema ve dil desteği
İkinci tema ve çok dilli metin desteği isteniyorsa her bileşen birden fazla koşulda tasarlanır.
Sıkça sorulan sorular
Panelin tamamını birden tasarlamak zorunda mıyız?
Hayır. Çoğu çalışma çekirdek modülle başlar. Görsel dil ve bileşen kütüphanesi orada kurulduktan sonra kalan modüller daha hızlı ilerler ve kapsamı zaman içinde genişletebilirsiniz.
Mevcut panelimizin arayüzünü koruyup düzenleyebilir misiniz?
Evet. Yapıyı bozmadan tipografi, renk, boşluk ve bileşen düzeyinde bir düzenleme mümkün. Bu yol geliştirme yükünü düşürür, ancak navigasyondan kaynaklanan sorunları çözmez.
Hazır arayüz kütüphanesi kullanıyoruz, tasarım buna uyar mı?
Uyar. Kullandığınız kütüphaneyi baştan öğreniyor, tasarımı onun bileşenleri ve kısıtları üzerine kuruyoruz. Böylece geliştirme aşamasında uygulanamayan ekran çıkmıyor.
Kullanıcı onboarding akışı bu kapsamın içinde mi?
Arayüz tarafı içinde, akışın kendisi ayrı bir çalışma. Boş durum ekranları ve ilk kurulum adımları bileşen olarak tasarlanır; hangi kullanıcıya hangi adımın gösterileceği ürün kararıdır.
Tasarımı geliştirdikten sonra kütüphaneyi kendimiz büyütebilir miyiz?
Evet. Bileşenler adlandırılmış ve varyantlanmış olarak teslim edilir, kullanım kuralları yazılıdır. Ekibiniz yeni ekranı mevcut parçalarla kurabilir.
Veri tablolarında kaç kolona kadar tasarım yapıyorsunuz?
Kolon sayısından çok kolon önceliği önemli. Hangi kolonun her zaman görüneceğini, hangisinin gizleneceğini ve dar ekranda tablonun nasıl davranacağını birlikte belirliyoruz.
SaaS Panel UI Tasarımı için ilk adımı atalım
- 1Formu doldurun ya da bizi arayın
- 2Bir iş günü içinde ön görüşme planlayalım
- 3Size özel yol haritası ve teklif hazırlayalım