Ankara Dijital Ürün Geliştirme: Araştırma, Tasarım ve Yazılımın İş Bölümü

Aynı hedefi paylaşmak için ürünün işini açıklayın

Ankara dijital ürün geliştirme projesinde farklı uzmanlıkların birlikte çalışması gerekir. Araştırmacı kullanıcı ihtiyacını inceler, tasarımcı kullanım akışını ve arayüzü ele alır, geliştirici ise kuralları çalışan bir sisteme dönüştürür. Bu rollerin bulunması tek başına işin bütünleştiğini göstermez. Ekiplerin aynı problemi ve aynı başarı tanımını okuyabildiği ortak bir başlangıç dosyası olmalıdır.

Örneğin ekipman kiralama taleplerini düzenlemek isteyen varsayımsal bir işletmeyi düşünelim. Müşteri uygun ürünü ve kullanım tarihini belirtmek, çalışan ise talebi mevcut envanterle değerlendirmek ister. Ürün yalnızca bir form ekranı olarak tarif edilirse değerlendirme ve geri dönüş süreci görünmez kalabilir. Başlangıç hedefi, müşterinin talebiyle şirketin işlem düzenini birlikte açıklamalıdır.

Projenin karar sahibi de bu aşamada belirlenir. Ürün kapsamı, hizmet kuralı ve görsel tercih aynı kişide toplanmak zorunda değildir. Fakat birbiriyle çelişen onaylar geldiğinde son kararı kimin vereceği bilinmelidir. Her rolün yorumunu almakla her yorumu yeni gereksinim saymak farklı işlerdir. Bu ayrım takvim ve kapsam yönetimine de yardımcı olur.

Araştırma çıktısını tasarımın kullanacağı biçimde teslim edin

Görüşme notları değerli malzemedir; fakat onlarca sayfalık ham not tasarım ekibi için tek başına açık bir brief oluşturmayabilir. Hangi kullanıcının hangi işi yapmaya çalıştığını, nerede zorlandığını ve hangi koşulun önemli olduğunu özetleyin. Bulguyla araştırmacının yorumunu ayrı yazın. Ekran kararına dayanak olacak kanıtın nerede bulunduğu anlaşılabilmelidir.

Kiralama örneğinde müşterinin her zaman ürün kodunu bilmediği görülmüş olsun. Bu gözlem, arama alanına yalnızca kod girilmesini bekleyen bir tasarımın sorun çıkarabileceğini düşündürür. Yine de çözümün mutlaka karmaşık bir öneri sistemi olması gerekmez. Ürünleri kullanım alanıyla açıklamak veya örnek başvuru bilgisi sunmak gibi seçenekler de değerlendirilebilir. Tasarım işi bu seçenekleri görünür hale getirir.

Araştırma ve arayüz tasarımı arasında bir soru listesi tutun. Her ekranın hangi ihtiyaca cevap verdiğini ve hangi kararın henüz sınanmadığını bu listeye bağlayabilirsiniz. Böylece tasarım incelemesi yalnız renk ve boşluk yorumlarıyla sınırlı kalmaz. Ekibin görsel tercihle kullanım varsayımını ayrı değerlendirmesi kolaylaşır.

Ortak akışta müşteri ekranından sonrasını da gösterin

Bir ürün haritasında yalnızca ziyaretçinin gördüğü adımlar varsa şirket içi operasyon eksik kalabilir. Başvuru geldikten sonra kaydı kim inceler, hangi bilgi eksikse nasıl tamamlanır ve kullanıcıya ne zaman geri dönülür? Bu soruların karşılığı çalışan ekranında, bildirimde veya tanımlı bir görevde bulunmalıdır. Hiçbirine ait olmayan işlerin arada kaybolma riski vardır.

Akışı toplantıda bir senaryoyla yürütün. Müşteri tarih seçsin, çalışan uygunluğu kontrol etsin, gerekirse alternatif önersin ve kayıt tamamlansın. Farklı ekipler aynı noktada farklı sonuç bekliyorsa bunu çizimde gösterin. Tasarım onayından önce görülen bir kural farkını düzeltmek, daha sonra birbirine bağlı ekranları yeniden ele almaktan daha yönetilebilir olabilir.

Bu çalışma ilk sürüm kapsamına da yardımcı olur. Bütün operasyonu aynı anda otomatikleştirmek gerekmeyebilir; ancak başlangıçta elle yürütülecek işin sorumlusu bilinmelidir. Ürünün dışında kalan adımları yok saymayın. Kullanıcı deneyimi, şirket içinde hangi aracın kullanıldığını bilmeden sürecin tamamını yaşar.

Ekrandaki her bilginin kaynağını belirleyin

Tasarım dosyasında gösterilen fiyat, stok, durum veya tarih bilgisinin gerçek üründe nereden geleceği açıklanmalıdır. Bazı bilgiler çalışan tarafından girilir, bazıları başka bir uygulamadan alınır, bazıları ise belirli kurallarla hesaplanır. Bu farklar hem geliştirme işini hem hata durumlarını etkiler. Kaynağı tanımlanmamış örnek veriler, tamamlanmış özellik gibi değerlendirilmemelidir.

Entegrasyon varsa veri güncellenemediğinde kullanıcının ne göreceğini konuşun. Eski bilginin gösterilip gösterilmeyeceği veya işlem için çalışan onayı gerekip gerekmediği ürün kararıdır. Geliştiricinin tek başına tahmin etmesi beklenmemelidir. Hangi verinin temel kayıt sayıldığı ve iki sistem arasında fark oluştuğunda kimin inceleyeceği ortak dosyada yer alsın.

Veri alanlarını günlük dilde açıklamak da yararlıdır. Bir ekibin “uygun” dediği durum başka ekip için “inceleme bekliyor” anlamına gelebilir. Durum adları, kullanıcı mesajları ve rapor tanımları birbirini desteklesin. Özellikle yeni personelin sistemi kullanırken sürekli sözlü açıklamaya ihtiyaç duyması, bu dilin gözden geçirilmesi gerektiğini gösterebilir.

Yazılıma aktarımı bir görüşmeyle tamamlayın

Tasarım dosyasının bağlantısını göndermek, bütün kararların anlaşılmış olduğunu garanti etmez. Geliştirme ekibiyle akışı, kuralları, boş ekranları, hata durumlarını ve farklı kullanıcı rollerini birlikte inceleyin. İhtiyaç duyulan örnekler ve açık sorular kayıt altında olsun. Uygulama sırasında alınan yeni kararlar yalnızca sohbet geçmişinde kalmasın; ilgili tasarım veya gereksinim kaydına işlensin.

Yazılım hizmeti kapsamındaki teslim planı, bu belirsizlikleri görünür biçimde ele almalıdır. Dış sisteme erişim, test hesabı ve örnek veri gibi ihtiyaçlar için karşı taraftaki sorumlular da belirlenir. Bazen gecikmenin nedeni kodun kendisi değil, gerekli bilginin veya erişimin zamanında sağlanmamasıdır. Takvim değerlendirmesinde bu bağımlılıkları ayrı konuşun.

Kabulü gerçek görev ve rollerle yapın

Teslim kontrolünde birkaç örnek ekranı açmak yerine baştan sona görev yürütün. Müşteri talep oluşturabilmeli, yetkili çalışan doğru kaydı bulabilmeli ve yapılan değişiklik beklenen yerde görünmelidir. Uygun olmayan girişler, eksik bilgi ve tekrar deneme gibi durumlar da kontrol edilsin. Testte kullanılan senaryo, projenin başında tarif edilen iş ihtiyacıyla ilişkili olsun.

GOV.UK Service Manual'ın beta aşaması rehberi, hizmeti gerçek kullanıcılarla geliştirirken öğrenmeye ve iyileştirmeye devam etmeyi ele alır. Bu yaklaşım, yayının araştırma ve tasarımla bağının kopmaması gerektiğini hatırlatır. Kendi ürününüzde hangi geri bildirimi kimin değerlendireceğini önceden belirleyebilirsiniz.

Yayın sonrasında değişiklik talepleri geldiğinde önce hangi ihtiyacın karşılanmadığını sorun. Her talep yeni bir ekran gerektirmeyebilir; içerik, kural veya çalışan sürecindeki bir düzeltme yeterli olabilir. Fikir geliştirme sürecinden kalan karar dosyasını güncel tutmak, yeni öneriyi eski varsayımlarla birlikte değerlendirebilmenizi sağlar. Ortak dosyanın sorumlusu ve güncelleme yeri, proje tesliminin açık bir parçası olmalıdır.