Önce kanıt, sonra piksel.
Bir ürün ekrandan değil sorudan başlar: kimin hangi işini kolaylaştıracak? Sonra akış, prototip ve test; en son piksel ve devir. Her aşamanın bir çıktısı ve bir onay noktası var.

uiuxtasarim'da bir dijital ürün beş aşamada tasarlanır: keşif (hedefler, roller, kısıtlar), araştırma (görüşme ve veri), akış ve prototip, test ve arayüz, geliştirici devri ve yayın öncesi tasarım kontrolü. Her aşamanın yazılı bir çıktısı ve onay noktası vardır.
- #01
Keşif
Bu ürün kimin hangi işini kolaylaştıracak?
- Ürün hedefleri, başarı ölçütleri ve iş kısıtları
- Kullanıcı rolleri ve her rolün ana görevleri
- Mevcut veri: analitik, destek talepleri, mağaza yorumları
- Teknik kısıtlar, kullanılan bileşen kütüphanesi ve geliştirme düzeni
- Karar verecek kişiler, onay noktaları ve takvim
ÇıktıYazılı kapsam, yöntem ve aşamalı takvim
- #02
Araştırma
Kullanıcı bugün bu işi nasıl yapıyor, nerede zorlanıyor?
- Kullanıcı görüşmeleri (uzaktan, izinli kayıt)
- Yayındaki ürün varsa denetim ve analitik inceleme
- Bulguların temalara ayrılması ve önceliklendirilmesi
- Ekibinizle birlikte karar oturumu
ÇıktıKanıtlı bulgu listesi ve öncelikli fırsatlar
- #03
Akış ve prototip
Kullanıcı hedefine hangi yoldan ulaşacak?
- Kullanıcı akışları: ana yol, karar noktaları, hata ve uç durumlar
- Bilgi mimarisi ve gezinme
- Tel kafes: önce yapı, sonra görünüş
- Kritik akışlar için tıklanabilir prototip
ÇıktıOnaylı akışlar ve test edilebilir prototip
- #04
Test ve arayüz
Tasarım gerçekten kullanılabiliyor mu?
- Prototip üzerinde kullanılabilirlik testi
- Bulgulara göre düzeltme
- Arayüz tasarımı: platform rehberleri, erişilebilirlik, tüm ekran durumları
- Bileşen kütüphanesi ve tasarım token'ları
ÇıktıTest edilmiş arayüz ve bileşen kütüphanesi
- #05
Devir ve kontrol
Geliştirici tasarımı tahmin etmeden uygulayabilecek mi?
- Devir paketi: durumlar, bileşenler, token'lar, erişilebilirlik ve metin notları
- Sprint boyunca geliştirici sorularına cevap
- Yayın öncesi uygulanan ekranların tasarımla karşılaştırılması
- Yayın sonrası ölçüm önerileri
ÇıktıEksiksiz devir paketi ve tasarım kontrol raporu
Nerede birlikte karar veriyoruz?
| Onay | Ne zaman | Ne olur |
|---|---|---|
| Kapsam | Keşiften sonra | Akışlar, roller, yöntem ve takvim onaylanır |
| Bulgular | Araştırmadan sonra | Neyin önce çözüleceğine birlikte karar verilir |
| Akış ve prototip | Arayüzden önce | Yapı onaylanmadan görsel tasarıma geçilmez |
| Arayüz | Testten sonra | Ana ekranlar onaylanır; değişiklik turları teklifte yazılı |
| Tasarım kontrolü | Yayından önce | Uygulanan ekranlar tasarımla karşılaştırılır |
Kim ne yapar?
| İş | Biz | Siz |
|---|---|---|
| Araştırma planı, görüşme ve test | uiuxtasarim | Katılımcılara erişim ve onay |
| Akış, prototip, arayüz, bileşenler | uiuxtasarim | Ürün kararları ve onay |
| Kodlama | Devir paketi ve sorulara cevap | Geliştirici ekibiniz ya da iş ortağınız |
| İzin ve aydınlatma metinleri | Ekranın yeri ve akışı | Metin: hukuk danışmanınız |
| Figma dosyaları ve kütüphaneler | Kurulum ve düzen | Hesap sahibi siz |
Süreç ve takvim
Kapsam, kullanıcı rolü sayısı, araştırmanın derinliği ve katılımcılara ne kadar hızlı ulaşılabildiği. Ürün projelerinde gecikmenin sık nedenlerinden biri karar ve onay döngüleridir; bu yüzden onay noktaları takvimde baştan yazılır.
Ürününüz ve kullanıcılarınız hakkında güvenilir veriniz varsa kısaltılabilir. Hiç araştırma yapılmayacaksa en azından prototipi birkaç kullanıcıyla test etmenizi öneririz.
Evet. Tasarımı geliştirme başlamadan bir adım önde tutar, sprint toplantılarına gerektiğinde katılır ve geliştiricilerin sorularına aynı gün içinde cevap vermeye çalışırız.
Ü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.