Gaye DinçUI/UX Designer / Frontend Developer
Çalışmalarıma dön
UI/UX CASE STUDY

HasarLink

HasarLink, farklı sigorta şirketlerine ait hasar bildirimlerini ortak ve takip edilebilir bir akışta buluşturan mobil ve web ürün deneyimi.

Rol
UI/UX Tasarımı ve Frontend Desteği
Platformlar
Mobil · Web
Araçlar
Figma · TypeScale
Hedef kullanıcı
Sigorta servisleri ve sanayide çalışan ustalar

Farklı şirket süreçlerini tek bir ürün mantığında buluşturmak.

01

Bağlam

Her sigorta şirketi farklı form alanları, belgeler ve işlem adımları kullanıyordu. Kullanıcılar aynı işi yaparken değişen kuralları ve yoğun bilgiyi yönetmek zorundaydı.

02

Tasarım problemi

Amaç uzun formları yalnızca daha iyi göstermek değildi. Ortak alanları belirlemek, gereksiz girdileri azaltmak ve farklılıkları anlaşılır bir bilgi hiyerarşisi içinde korumak gerekiyordu.

03

Yaklaşım

Karmaşık operasyonu, uygulanabilir ve takip edilebilir bir ürün akışına dönüştürmek.

Kararlar, süreç farklılıklarını saklamadan yönetilebilir hale getirmeye odaklandı.

01

Farklı sigorta süreçlerini ortak akışta toplamak

Problem

Farklı şirket gereklilikleri ortak başlangıç görevini parçalı hâle getiriyordu.

Neden bu yolu seçtim?

Sigorta şirketi ve başvuru türü seçimlerini kontrollü adımlarla ortak bir başlangıçta toplamak.

Nasıl uygulandı?

Kullanıcı önce ilgili sigorta şirketini, ardından sigortanın hangi taraf üzerinden açıldığını seçiyor.

Oluşturduğu yapı

Şirkete özgü gereklilikleri ortak başlangıç akışı içinde yöneten yapı.

Favori ve tüm sigorta şirketlerinin listelendiği sigorta şirketi seçim ekranı
Sigorta şirketi ve başvuru türü seçimlerinin ortak başlangıç akışı içinde yapılandırılması.
02

Uzun formu adımlara ayırmak ve kullanıcı kontrolünü korumak

Problem

Yoğun bilgi alanları özellikle mobilde kullanıcının ilerlediği aşamayı ve eksik bilgileri takip etmesini zorlaştırıyordu.

Neden bu yolu seçtim?

Kullanıcının yalnızca bulunduğu aşamayla ilgili bilgilere odaklanması ve ilerlemeden önce verdiği cevapları kontrol edebilmesi gerekiyordu.

Nasıl uygulandı?

Mağdur, sürücü ve araç bilgilerini adımlara ayırdım. Belgeleri ayrı yükleme kartlarında sundum ve sonraki adıma geçmeden önce seçimlerin kontrol edilip düzenlenebildiği bir özet yapısı kullandım.

Oluşturduğu yapı

Bilgi girişi, belge yükleme ve kullanıcı kontrolünü aynı adımlı akış içinde birleştiren form deneyimi.

Mağdur, sürücü ve araç bilgileri adımlarından mağdur bilgileri form ekranı
Bilgilerin adımlara ayrılması, belgelerin ayrı alanlarda yüklenmesi ve kullanıcıya ilerlemeden önce kontrol imkânı sunulması.
03

Dosyaları hızlı taranabilir kılmak

Problem

Farklı dosyaların durumu liste seviyesinde kolayca karşılaştırılamıyordu.

Neden bu yolu seçtim?

En kritik bilgileri ilk bakışta okunabilen bir özet yapısında göstermek.

Nasıl uygulandı?

Plaka, sigorta şirketi ve başvuru durumlarını tutarlı liste öğelerinde bir araya getirdim.

Oluşturduğu yapı

Kullanıcının öncelikli kaydı hızla bulabildiği taranabilir dosya listesi.

Plaka, sigorta şirketi ve başvuru durumlarını gösteren dosya bildirimleri listesi
04

Dosya durumunu ve geçmişini takip edilebilir kılmak

Problem

Güncel aşama, geçmiş hareketler ve ilgili detaylar birbirinden kopuk sunulduğunda takip zorlaşıyordu.

Neden bu yolu seçtim?

Seçilen dosyanın bütün sürecini tek bir detay hiyerarşisinde toplamak.

Nasıl uygulandı?

Güncel aşamayı, geçmiş işlemleri, taraf ve kaza bilgilerini, belgelerle birlikte anlamlı bölümlerde düzenledim.

Oluşturduğu yapı

Liste seviyesindeki hızlı taramayı ayrıntılı süreç takibine bağlayan dosya detayı.

Dosya aşamalarını, taraf bilgilerini, kaza detaylarını ve yüklenen belgeleri gösteren uzun dosya detay ekranı

Tasarımların yalnızca Figma üzerinde doğru görünmesi benim için yeterli değildi.

Rolüm ürünün bütün frontend geliştirmesini üstlenmek değil, uygulama kalitesini tasarım kararlarıyla birlikte kontrol etmek ve gerektiğinde arayüz tarafına destek vermekti.

Bu çalışma biçimi, tasarım kararlarını yalnızca Figma’da değil gerçek ürün koşullarında değerlendirmemi sağladı.
  • Spacing, boyut, hizalama ve renk kontrolü
  • Responsive davranışların doğrulanması
  • Değişken veri uzunluklarının kontrolü
  • Tekrar kullanılabilir bileşenlerin değerlendirilmesi
  • Gerektiğinde kod üzerinden arayüz düzenlemeleri

Proje, yoğun operasyonel bilgiyi tasarım ve uygulama arasında birlikte düşünmenin önemini gösterdi.

Tasarım sistemi, ekranları değil kararları tutarlı hâle getirir.

Sadeleştirmek, bilgi silmek değildir.

Gerekli ayrıntıyı korurken doğru anda ve doğru grupta göstermek daha belirleyiciydi.

Responsive tasarım bilgiyi yeniden önceliklendirir.

Mobil ve web için aynı hiyerarşiyi ölçeklemek yerine kullanım bağlamına göre yeniden kurdum.

Otomasyon kullanıcı kontrolünün yerine geçmemelidir.

Belge okuma önerileri düzenlenebilir ve doğrulanabilir bir adım olarak ele alındı.

Tasarım kodlandığında da çalışmalıdır.

Değişken veri, responsive davranış ve bileşen tekrar kullanımı uygulama kontrolünün parçası oldu.