16 Oca 2026·7 dk
Belge-merkezli iş akışları: veri modeli ve kullanıcı arayüzü desenleri
Sürümler, önizlemeler, metadata ve net durumlar için pratik veri modelleri ve kullanıcı arayüzü desenleriyle belge-merkezli iş akışları açıklandı.
Sürümler, önizlemeler, metadata ve net durumlar için pratik veri modelleri ve kullanıcı arayüzü desenleriyle belge-merkezli iş akışları açıklandı.
Bir uygulama, kullanıcıların oluşturduğu, incelediği ve güvendiği ürünün kendisi belge olduğunda belge-merkezli olur. Deneyim PDF, resim, tarama ve makbuz gibi dosyaların etrafında kuruludur; dosyanın sadece bir ek olduğu bir form etrafında değil.
Belge-merkezli iş akışlarında insanlar gerçek işi belgenin içinde yapar: onu açar, neyin değiştiğini kontrol eder, bağlam ekler ve sıradaki kararı verir. Belge güvenilmezse uygulama faydasını yitirir.
Çoğu belge-merkezli uygulama, erken aşamada birkaç temel ekrana ihtiyaç duyar:
Sorunlar çabuk ortaya çıkar. Kullanıcı aynı makbuzu iki kez yükler. Birisi bir PDF'yi düzenleyip nedenini açıklamadan yeniden yükler. Bir taramada tarih, satıcı veya sahip yoktur. Haftalar sonra hangi sürümün onaylandığı veya kararın neye dayandığı bilinmez.
İyi bir belge-merkezli uygulama hızlı ve güvenilir hissettirir. Kullanıcılar şu soruları saniyeler içinde yanıtlayabilmelidir:
Bu açıklık tanımlardan gelir. Ekranları inşa etmeden önce uygulamanızda “sürüm”, “önizleme”, “metadata” ve “durum”un ne anlama geldiğine karar verin. Bu terimler belirsizse, kopyalar, kafa karıştırıcı geçmiş ve gerçek işle uyuşmayan inceleme akışlarıyla karşılaşırsınız.
UI genellikle basit görünür (bir liste, bir görüntüleyici, birkaç buton), ama veri modeli yükü taşır. Temel nesneler doğruysa, denetim geçmişi, hızlı önizlemeler ve güvenilir onaylar çok daha kolay olur.
“Belge kaydı” ile “dosya içeriği”ni ayırarak başlayın. Kayıt kullanıcıların konuştuğu şeydir (ACME'den Fatura, Taksi makbuzu). İçerik byte'lar (PDF, JPG) olup, açıklama yapılmadan değiştirilip yeniden işlenebilir veya taşınabilir; bu, uygulama içindeki belgenin anlamını değiştirmez.
Modellemek için pratik bir nesne seti:
Hangi nesnelere hiç değişmeyen bir ID verileceğine karar verin. Yararlı bir kural: Document ID sonsuza dek yaşar, oysa File'lar ve Preview'ler yeniden oluşturulabilir. Sürümler de sabit ID'lere ihtiyaç duyar; insanlar “dünün nasıl göründüğünü” referans gösterir ve denetim izi gerekebilir.
İlişkileri açıkça modelleyin. Bir Document'in birçok Version'ı olur. Her Version birden çok Preview'e sahip olabilir (farklı boyutlar veya formatlar). Bu, liste ekranlarını hafif önizleme verisi yükleyerek hızlı tutar; detay ekranları gerektiğinde tam dosyayı yükler.
Örnek: kullanıcı buruşuk bir makbuz fotoğrafı yükler. Bir Document oluşturursunuz, orijinal File'ı saklarsınız, bir küçük resim Preview üretirsiniz ve Version 1'i yaratırsınız. Daha sonra kullanıcı daha net bir tarama yükler. Bu, yorumları, onayları veya arama ile bağlanmış Document'i bozmadan Version 2 olur.
İnsanlar bir belgenin zaman içinde değişmesini, “farklı bir öğeye dönüşmesini” beklemezler. Bunu sunmanın en basit yolu kimliği (Document) içeriğinden (Version ve File'lar) ayırmaktır.
Değişmeyen bir document_id ile başlayın. Kullanıcı aynı PDF'yi yeniden yüklese, bulanık bir fotoğrafı değiştirse veya düzeltilmiş bir tarama yüklese bile bu aynı belge kaydı olmalıdır. Yorumlar, atamalar ve denetim günlükleri tek bir dayanıklı ID'ye temizce bağlanır.
Her anlamlı değişikliği yeni bir version satırı olarak ele alın. Her sürüm, onu oluşturan kişinin kim olduğunu ve zamanı yakalamalı; ayrıca depolama işaretçileri (file key, checksum, size, page count) ve o kesin dosyaya bağlı türetilmiş artefaktları (OCR metni, önizleme görüntüleri) içermelidir. “Yerinde düzenleme”den kaçının. İlk bakışta daha basit görünür ama izlenebilirliği bozar ve hataları geri sarmayı zorlaştırır.
Hızlı okumalar için, belgede bir current_version_id bulundurun. Çoğu ekran sadece “en son”u ister, böylece her yüklemede sürümleri sıralamanıza gerek kalmaz. Geçmiş gerektiğinde sürümleri ayrı yükleyin ve temiz bir zaman çizelgesi gösterin.
Geri almalar sadece bir gösterge değişikliğidir. Bir şeyi silmek yerine current_version_idyi eski bir sürüme geri ayarlayın. Bu hızlı, güvenli ve denetim izini korur.
Geçmişi anlaşılır kılmak için her sürümün neden var olduğunu kaydedin. Küçük, tutarlı bir reason alanı (isteğe bağlı bir notla) gizemli güncellemelerle dolu bir zaman çizelgesini önler. Yaygın nedenler: yeniden yükleme ile değişim, tarama temizliği, OCR düzeltmesi, sansürleme ve onay düzenlemesi.
Örnek: bir finans ekibi bir makbuz fotoğrafı yükler, daha sonra daha net bir tarama ile değiştirir, sonra OCR'ı düzelterek toplamın okunmasını sağlar. Her adım yeni bir sürümdür, ama belge gelen kutusunda tek bir öğe kalır. Eğer OCR düzeltmesi yanlışsa, current_version_id sadece bir tıklamayla geri alınır.
Belge-merkezli iş akışlarında kullanıcıların en çok etkileşimde bulunduğu şey genellikle önizlemedir. Önizlemeler yavaş veya hatalıysa, tüm uygulama bozuk hisseder.
Önizleme üretimini upload ekranının beklediği bir işlem değil, ayrı bir iş olarak ele alın. Orijinal dosyayı önce kaydedin, kullanıcıya kontrolü geri verin, sonra arka planda önizlemeleri üretin. Bu UI'nın duyarlı kalmasını sağlar ve tekrar denemeleri güvenli kılar.
Birden çok önizleme boyutu saklayın. Tek bir boyut her ekran için uygun değildir: listeler için küçük bir thumbnail, bölünmüş görünümler için orta boy bir resim ve detaylı inceleme için sayfa başına tam sayfa görüntüleri (PDF'ler için) gerekir.
Önizleme durumunu açıkça takip edin ki UI her zaman ne gösterileceğini bilsin: pending, ready, failed ve needs_retry. UI'de kullanıcıya uygun etiketler gösterin, ama veride durumların net olmasını sağlayın.
Render hızını korumak için, türetilmiş değerleri her görünümde yeniden hesaplamak yerine preview kaydıyla birlikte önbelleğe alın. Yaygın alanlar: sayfa sayısı, preview genişlik ve yükseklik, dönüş (0/90/180/270) ve isteğe bağlı “thumbnail için en iyi sayfa”.
Yavaş ve karışık dosyalar için tasarlayın. 200 sayfalık bir taranmış PDF veya buruşuk bir makbuz fotoğrafı işlem süresi alabilir. Kademeli yüklemeyi kullanın: hazır olan ilk sayfayı hemen gösterin, sonra geri kalanını doldurun.
Örnek: kullanıcı 30 makbuz fotoğrafı yükler. Liste görünümü küçük resimleri “pending” olarak gösterir, sonra her kart preview hazırlandıkça “ready” olur. Birkaçı bozulmuş dosyadan dolayı başarısız olursa, toplu işi engellemek veya kaybolmak yerine açık bir yeniden deneme eylemiyle görünür bırakın.
Metadata, bir dosya yığınını arayabileceğiniz, sıralayabileceğiniz, inceleyebileceğiniz ve onaylayabileceğiniz bir şeye dönüştürür. İnsanların basit soruları hızla yanıtlamasına yardımcı olur: Bu belge nedir? Kimden geldi? Geçerli mi? Sırada ne olmalı?
Metadata'yı temiz tutmanın pratik yolu, kaynağına göre ayırmaktır:
Bu kümeleme ileride tartışmaları önler. Eğer toplam yanlışsa, bunun OCR'dan mı yoksa insan düzenlemesinden mi geldiğini görebilirsiniz.
Makbuzlar ve faturalar için, tutarlı kullanıldığında küçük bir alan seti çok işe yarar (aynı adlandırma, aynı formatlar). Yaygın anahtar alanlar: vendor (satıcı), date (tarih), total (tutar), currency (para birimi) ve document_number. Öncelikle bu alanları isteğe bağlı tutun. İnsanlar eksik taramalar ve bulanık fotoğraflar yükler; bir alan eksik diye süreci engellemek işleri yavaşlatır.
Bilinmeyen değerleri birinci sınıf ele alın. null/unknown gibi açık durumlar ve gerektiğinde bir neden kullanın (sayfa eksik, okunamıyor, geçerli değil). Bu, belgenin ilerlemesini sağlarken gözden geçirenlere neyin dikkat gerektirdiğini gösterir.
Ayrıca çıkarılan alanlar için köken ve güveni saklayın. Kaynak user, OCR, import veya API olabilir. Güven 0-1 arası bir skor ya da high/medium/low gibi küçük bir küme olabilir. OCR “$18.70”u son rakamı kirli olduğu için düşük güvenle okuduyse, UI bunu vurgulayabilir ve hızlı bir doğrulama isteyebilir.
Çok sayfalı belgeler için ekstra bir karar gerekir: hangi bilgiler tüm belgeye ait, hangi bilgiler tek sayfaya ait. Toplamlar ve satıcı genelde belge bütününe aittir. Sayfa düzeyinde notlar, sansürlemeler, dönme ve sayfa başına sınıflandırma genelde sayfa düzeyinde kalır.
Durum şu soruyu cevaplar: “Bu belge sürecin neresinde?” Küçük ve sıkıcı tutun. Her istenen her defasında yeni bir durum ekliyorsanız, sonunda kimsenin güvenmediği filtreleriniz olur.
Gerçek kararlara uyan pratik bir iş durumu seti:
“Processing” gibi teknik durumları iş durumlarının dışında tutun. OCR çalışıyor veya preview üretiliyor olmak sistemin ne yaptığını anlatır, bir insanın sıradaki adımını değil. Bunları ayrı işlem durumları olarak saklayın.
Ayrıca atamayı durumdan (assignee_id, team_id, due_date) ayırın. Bir belge Approved olsa bile takip için atanmış olabilir; ya da Needs review olmasına rağmen henüz bir sahibi olmayabilir.
Sadece mevcut değeri değil, durum geçmişini kaydedin. Basit bir kayıt (from_status, to_status, changed_at, changed_by, reason) “Bu makbuzu kim reddetti ve neden?” sorusuna yanıt verir.
Son olarak, her durumda hangi eylemlere izin verildiğine karar verin. Kuralları basit tutun: Imported -> Needs review; Approved genelde salt okunur olmalı (yeni bir sürüm oluşturulmadıkça); Rejected yeniden açılabilir ama önceki neden korunmalı.
Zamanın çoğu bir liste taramaya, bir öğe açmaya, birkaç alanı düzeltmeye ve devam etmeye harcanır. İyi UI bu adımları hızlı ve öngörülebilir yapar.
Belge listesi için her satırı bir özet gibi ele alın ki kullanıcı her dosyayı açmadan karar verebilsin. Güçlü bir satır küçük bir thumbnail, net bir başlık, birkaç anahtar alan (satıcı, tarih, toplam), bir durum rozeti ve dikkat gerektiren durumlar için ince bir uyarı gösterir.
Detay görünümünü sakin ve taranabilir tutun. Yaygın bir düzen: solda önizleme, sağda metadata, her alanın yanında düzenleme kontrolleri. Kullanıcılar yakınlaştırma, döndürme ve sayfalar arasında kaybolmadan geçiş yapabilmeli. Bir alan OCR'dan çıkarıldıysa küçük bir güven ipucu gösterin ve alan odakta iken önizlemede kaynağı vurgulamak ideal olur.
Sürümler bir açılır liste değil, zaman çizelgesi olarak daha iyi çalışır. Kim neyi ne zaman değiştirdiğini gösterin ve kullanıcıların herhangi bir geçmiş sürümü salt okunur modda açmasını sağlayın. Karşılaştırma sunuyorsanız, piksel piksel PDF karşılaştırması yerine metadata farklarına (tutar değişti, satıcı düzeltildi) odaklanın.
İnceleme modu hızı optimize etmelidir. Klavye merkezli bir üç işlemli akış çoğunlukla yeterlidir: hızlı onay/red eylemleri, yaygın alanlar için hızlı düzeltmeler ve reddetmeler için kısa bir yorum kutusu.
Boş durumlar önemlidir çünkü belgeler sıklıkla işlem ortasındadır. Boş bir kutu yerine ne olduğunu açıklayın: “Önizleme oluşturuluyor”, “OCR çalışıyor” veya “Bu dosya türü için önizleme yok”.
Basit bir iş akışı “yükle, kontrol et, onayla” gibi hissetmeli. Altında ise dosyayı (sürümler ve önizlemeler) işin anlamından (metadata ve durum) ayırdığınızda en iyi şekilde çalışır.
Kullanıcı bir PDF, fotoğraf veya makbuz taraması yükler ve hemen gelen kutusunda görür. İşlem bitmesini beklemeyin. Dosya adı, yükleme zamanı ve “Processing” gibi net bir rozet gösterin. Kaynağı (e-posta importu, mobil kamera, sürükle-bırak) biliniyorsa onu da gösterin.
Yüklemede bir Document kaydı (uzun ömürlü nesne) ve bir Version kaydı (bu spesifik dosya) oluşturun. current_version_idyi yeni sürüme ayarlayın. preview_state = pending ve extraction_state = pending olarak tutun ki UI neyin hazır olduğunu dürüstçe gösterebilsin.
Detay görünümü hemen açılmalı, ama kırık bir çerçeve yerine bir yer tutucu görüntüleyici ve “Önizleme hazırlanıyor” mesajı gösterin.
Arka plan işi küçük resimler ve görüntülenebilir önizlemeler (PDF'ler için sayfa görüntüleri, fotoğraflar için yeniden boyutlandırılmış resimler) oluşturur. Başka bir iş metadata çıkarır (satıcı, tarih, toplam, para birimi, belge türü). Her iş bitince sadece onun durumunu ve zaman damgasını güncelleyin, böylece başarısızlıkları tekrar denemek kolay olur.
UI kompakt olsun: preview durumu, veri durumu gösterin ve düşük güvenli alanları vurgulayın.
Önizleme hazır olduğunda inceleyenler alanları düzeltir, not ekler ve belgeyi Imported -> Needs review -> Approved (veya Rejected) gibi iş durumları arasında hareket ettirir. Kim neyi ne zaman değiştirdiğini kaydedin.
İnceleyen düzeltilmiş bir dosya yüklerse, bu yeni bir Version olur ve belge otomatik olarak tekrar Needs review durumuna döner.
Dışa aktarmalar, muhasebe senkronu veya iç raporlar current_version_id ve onaylanmış metadata anlık görüntüsünü okumalı, “en son çıkarım”ı değil. Bu, yarım işlenmiş bir yeniden yüklemenin rakamları değiştirmesini önler.
Belge-merkezli iş akışları sıkıcı nedenlerle başarısız olur: erken alınan kestirmeler, insanlar çoğaltma yüklediğinde, hataları düzeltip “Bunu kim ve ne zaman değiştirdi?” sorusu ortaya çıktığında günlük bir acıya dönüşür.
Dosya adını belgenin kimliği gibi ele almak klasik bir hatadır. İsimler değişir, kullanıcılar yeniden yükler, kameralar IMG_0001 gibi çoğaltmalar üretir. Her belgeye stabil bir ID verin ve dosya adını etiket olarak kullanın.
Birini değiştirirken orijinal dosyayı üzerine yazmak da sorun yaratır. Daha basit hissetse de denetim izini kaybedersiniz ve sonradan ne onaylandığını, neyin düzenlendiğini veya neyin gönderildiğini cevaplayamazsınız. İkili dosyayı değiştirilemez tutun ve yeni bir sürüm kaydı ekleyin.
Durum karışıklığı ince hatalar yaratır. “OCR çalışıyor” ile “Needs review” aynı şey değildir. İşlem durumları sistemin ne yaptığını; iş durumu ise bir insanın ne yapması gerektiğini belirtir. Bu karıştığında belgeler yanlış Sepete takılır.
UI kararları da sürtünme yaratabilir. Önizlemeler oluşturulana kadar ekranı engellerseniz, yükleme başarılı olsa bile uygulama yavaş hissedilir. Belgeyi hemen gösterin, yer tutucu kullanın, sonra küçük resimleri hazır olduğunda değiştirin.
Son olarak, metadata köken olmadan saklandığında güvenilmez hale gelir. Toplam OCR'dan geldiyse belirtin. Zaman damgalarını tutun.
Kısa bir kontrol listesi:
Örnek: bir makbuz için kullanıcı daha net bir fotoğraf yüklerse, versiyonlayın; eski resmi koruyun, OCR'ı yeniden işleyecek şekilde işaretleyin ve Needs review durumunu koruyun.
Belge-merkezli iş akışları ancak insanlar gördüklerine güvenip sorunları çözdüğünde “tamamlanmış” hissi verir. Lansmandan önce bulanık, gerçek belgelerle test edin (bulanık makbuzlar, döndürülmüş PDF'ler, tekrar eden yüklemeler).
Çoğu sürprizi yakalayan beş kontrol:
Hızlı bir gerçeklik testi: birine üç benzer makbuzu incelemesini söyleyin ve bilerek birine yanlış bir değişiklik yaptırın. Eğer kişi geçerli sürümü tespit edip durumu anlayıp hatayı bir dakika içinde düzeltebiliyorsa, neredeyse hazırsınız.
Aylık makbuz harcama geri ödemeleri belge-merkezli işin açık bir örneğidir. Bir çalışan makbuzları yükler, iki inceleyen kontrol eder: önce yönetici, sonra finans. Makbuz ürün olduğundan uygulamanız sürümlemeye, önizlemelere, metadata'ya ve net durumlara bağlı olarak yaşar veya ölür.
Jamie bir taksi makbuzu fotoğrafı yükler. Sisteminiz Document #1842'yi Version v1 (orijinal dosya), bir thumbnail ve önizleme ile metadata (satıcı, tarih, para birimi, toplam ve bir OCR güven puanı) ile oluşturur. Belge Imported ile başlar, sonra önizleme ve çıkarım hazır olduğunda Needs review'e geçer.
Daha sonra Jamie aynı makbuzu kazara tekrar yükler. Bir çoğaltma kontrolü (dosya hash'i artı benzer satıcı/tarih/toplam) şu seçeneği gösterebilir: “#1842 ile çoğaltma gibi görünüyor. Yine de ekle veya sil.” Eğer eklerse, aynı Document'e bağlı başka bir File olarak saklayın ki tek bir inceleme zinciriniz ve tek bir durumunuz olsun.
İnceleme sırasında yönetici önizlemeyi, ana alanları ve uyarıları görür. OCR toplamı $18.00 tahmin etmiş, ama resimde açıkça $13.00 görünüyor. Jamie tutarı düzeltir. Geçmişi silmeyin. Güncellenmiş alanlarla Version v2 oluşturun, v1'i değişmeden tutun ve “Toplam Jamie tarafından düzeltildi” kaydını bırakın.
Bu tür bir iş akışını çabuk kurmak istiyorsanız, Koder.ai (koder.ai) sohbet tabanlı bir plandan ilk çalışan sürümü üretmenize yardımcı olabilir; ama aynı kural geçerlidir: önce nesneleri ve durumları tanımlayın, sonra ekranlara izin verin.
Pratik sonraki adımlar:
Belge-merkezli bir uygulama, belgeyi yan ek olarak değil, kullanıcıların üzerinde çalıştığı ana öğe olarak ele alır. İnsanlar belgeyi açıp güvenmeli, neyin değiştiğini anlamalı ve sıradaki kararı o belgeye göre vermelidir.
Bir gelen kutusu/listesi, hızlı bir önizlemeye sahip belge detay görünümü, basit bir inceleme alanı (onay/red/değişiklik isteği) ve dışa aktarma/paylaşma yolları ile başlayın. Bu dört ekran, bulma, açma, karar verme ve devretme döngüsünü kapar.
Document kaydı sabit olmalı; gerçek dosya ikili verileri ayrı File nesneleri olarak saklayın. Ardından belgeyi belirli bir dosyaya bağlayan anlık görüntü olarak Version ekleyin. Bu ayrım, dosya değişse bile yorumları, atamaları ve geçmişi korur.
Her anlamlı değişiklik için yeni bir sürüm oluşturun; yerinde düzenlemek yerine bir current_version_id tutun. Bu, onaylanmış olanın ne olduğu konusunda kafa karışıklığını önler ve geri alma için geçmiş sağlar.
Orijinal dosyayı kaydettikten sonra önizlemeleri asenkron olarak üretin, böylece yüklemeler anlık hissedilir ve tekrar denemeler güvenli olur. UI dürüst olmak için preview durumlarını (pending/ready/failed) gösterir; farklı ekran boyutları için birden çok boyut saklayın.
Metadata'yı üç ayrı kümede saklayın: sistem (dosya boyutu, tür), çıkarılmış (OCR alanları ve güven skoru) ve kullanıcı tarafından girilen düzeltmeler. Köken bilgisini saklayarak bir değerin OCR'dan mı yoksa insandan mı geldiğini her zaman söyleyebilmelisiniz.
İnsanların ne yapması gerektiğini anlatan küçük bir iş durumu seti kullanın: Imported, Needs review, Approved, Rejected, Archived. İşlem durumlarını (OCR, preview) ayrı tutun; bunlar sistemin ne yaptığını gösterir, bir kişinin sıradaki adımını değil.
Yüklemelerde değişmez dosya özetlerini (checksum) saklayın ve bunları kıyaslayın; varsa satıcı/tarih/tutar gibi anahtar alanlara dayalı ikinci bir kontrol ekleyin. Şüpheli bir çoğaltma durumunda kullanıcıya aynı belge zincirine ekleme veya atma seçeneği sunun.
Kim neyi, ne zaman ve neden değiştirdiğinin kaydını tutun; sürümler zaman çizelgesinde okunabilir olmalı. Geri alma, içerikleri silmek yerine current_version_id'yi eski bir sürüme çevirmek kadar basit olmalıdır.
Önce nesneleri ve durumları tanımlayın, sonra UI'yi tasarlayın. Koder.ai kullanarak bir sohbet planından uygulama üretirken Document/Version/File, preview ve extraction durumları ile durum kurallarını açıkça belirtin ki oluşturulan ekranlar gerçek iş akışına uyumlu olsun.