SaaS ve Web Uygulaması Tasarımı
Bir SaaS ürününde kullanıcıyı kaybettiğiniz yer çoğu zaman satış sayfası değil, kayıttan sonraki ilk dakikalardır. Boş bir panel, ne yapacağını söylemeyen bir menü ve ekip arkadaşını nasıl davet edeceğini bulamayan bir yönetici, deneme süresinin sessizce bitmesine yol açar.
SaaS ürün tasarımı, kullanıcıların abonelikle kullandığı bir web uygulamasının kayıt, ilk kullanım, ana görevler, ekip ve yetki yönetimi, ayarlar ve faturalama akışlarını tasarlamaktır. Amaç kullanıcının ürünün değerini olabildiğince erken görmesi ve günlük işini en az sürtünmeyle yapabilmesidir.
Tasarıma ürününüzün değer anını tanımlayarak başlarız: kullanıcı neyi gördüğünde bu ürünün işine yarayacağını anlıyor? Kayıt ve ilk kullanımı bu ana giden en kısa yol olarak kurar, ana görev akışlarını sadeleştirir, roller ve yetkiler gibi karmaşık konuları anlaşılır hâle getiririz. Büyüyen ürün için bileşen kütüphanesini baştan kurarız.
[01]Kimler için?
- İlk sürümünü ya da büyük bir yenilemesini planlayan SaaS ekipleri
- Deneme süresinden ücretli kullanıma geçişte zorlanan ürünler
- Kurumsal müşterilere açılan, rol ve yetki ihtiyacı büyüyen yazılımlar
- Mühendislik ağırlıklı ekiplerle tasarım kapasitesi kurmak isteyen şirketler
[02]Kimler için değil?
- Kurumsal site, e-ticaret sitesi ya da kampanya sayfası arıyorsanız bu bir web sitesi projesidir.Web sitesi için websitemx
- Uygulamanın kodlanmasını arıyorsanız: biz tasarlar, geliştirici ekibinize eksiksiz devreder ve yayın öncesi tasarım kontrolünü yaparız; kodlamayı sizin ekibiniz ya da iş ortağınız üstlenir.
[03]Ne teslim edilir?
| Teslimat | İçerik | Sıklık |
|---|---|---|
| Değer anı ve akışlar | Kayıt, ilk kullanım, ana görevler, ekip daveti | Başlangıç |
| Bilgi mimarisi | Gezinme, nesneler ve ilişkileri, arama ve filtreleme | Tasarımdan önce |
| Prototip ve test | Kritik akışlar için tıklanabilir prototip ve kısa test | Onaydan önce |
| Arayüz tasarımı | Masaüstü öncelikli, mobil uyumlu; boş, yükleniyor ve hata durumları | Onay noktalı |
| Roller, ayarlar, faturalama | Yetki matrisi, hesap ve plan ekranları | Proje |
| Bileşen kütüphanesi ve devir | Token'lar, bileşenler, durumlar; geliştirici notları | Teslim |
[04]İlk 90 gün
- 1. aşama
Keşif
Kullanıcı rolleri, değer anı, mevcut veri ve teknik kısıtlar.
- 2. aşama
Yapı ve akış
Bilgi mimarisi ve kritik akışların tel kafesleri.
- 3. aşama
Prototip ve arayüz
Prototip testi, ardından arayüz ve bileşen kütüphanesi.
- 4. aşama
Devir
Geliştirici devri, sprint içinde tasarım desteği ve yayın öncesi kontrol.
[05]Neyle ölçülür?
- Kayıt sonrası değer anına ulaşan kullanıcı oranı
- Ana görevlerin prototip testinde başarı oranı
- Destek taleplerinde tasarım kaynaklı konuların azalması
[06]Sık yapılan hatalar
Boş panelle karşılamak
Kayıttan sonra boş bir ekran kullanıcıya iş yükler. Örnek veri, ilk adım rehberi ya da şablonla değerli bir başlangıç sunulmalı.
Her ayarı ilk gün göstermek
Gelişmiş seçenekler yeni kullanıcıyı korkutur. Önce temel görev, sonra ihtiyaç oldukça derinlik.
Yetkiyi sonradan eklemek
Rol ve yetki konusu sonradan eklendiğinde her ekran yeniden düşünülür. Kurumsal müşteri hedefi varsa baştan tasarlanmalı.
[07]Fiyatı ne belirler?
Sabit paket fiyatı yayınlamıyoruz; çünkü iki “mobil uygulama” ekran sayısı, kullanıcı rolleri, araştırma ihtiyacı ve mevcut tasarım sistemi açısından çok farklı iş yükü olabilir. Görüşmeden sonra kapsamı, yöntemi, takvimi ve fiyatı yazılı iletiriz. Dış katılımcı paneli gibi üçüncü taraf maliyetler ayrıca yazılır.
- Ana akış ve nesne sayısı
- Kullanıcı rolü ve yetki karmaşıklığı
- Mevcut ürünün durumu (sıfırdan ya da yenileme)
- Bileşen kütüphanesinin kapsamı
- Sprint içi tasarım desteği süresi
[08]Sık sorulanlar
Genellikle hayır. Önce bir denetimle en çok sorun yaşanan akışları buluruz, ardından onları öncelik sırasıyla yeniden tasarlarız. Böylece ekibiniz geliştirmeyi durdurmadan ürünü adım adım iyileştirir.
Ekibinizin sprint düzenine uyarız. Tasarımı geliştirme başlamadan önce bitirip devreder, sprint boyunca sorulara cevap verir ve yayın öncesinde uygulanan ekranları tasarımla karşılaştırırız.
Evet, çoğu zaman mantıklıdır. Geliştiricilerinizin kullandığı kütüphaneyi temel alıp markanıza ve ihtiyaçlarınıza göre uyarlarız; böylece tasarım ile kod arasındaki fark azalır.
Arayüz metinlerini yazıyoruz. İzin ve onay ekranlarının yeri, sırası ve anlaşılırlığı tasarımın parçasıdır; aydınlatma ve rıza metinlerinin içeriği ise hukuki bir iştir ve hukuk danışmanınız tarafından hazırlanmalı ya da onaylanmalıdır.
Ürününüzü birlikte inceleyelim
Görüşmede ürününüzü, kullanıcılarınızı, takıldıkları yerleri ve ekibinizin yapısını konuşur; yazılı bir kapsam, yöntem ve takvim önerisi çıkarırız. Bağlayıcı değildir.