多條件查詢設計怎麼做到新手順手、專家更快？從事實型量刑資訊系統談起

​多條件查詢設計最難的地方，是同一套介面要同時服務第一次上門的民眾，以及每天都在用的專業人員。以我們為司法院UIUX設計「事實型量刑資訊系統」為例，涵蓋10種案類、數十個量刑因子，KYART光沅創意負責整體UI/UX設計時，用三個做法回應：圖像化入口降低門檻、單頁流程記住每一步條件、即時儀表板讓使用者隨時知道自己正在查什麼。

 

事實型量刑資訊系統要解決什麼問題？

它讓法官、檢察官、律師與民眾查詢相類似案件的量刑分布。司法院自109年9月起研發，以自然語言處理標註判決中的量刑事由，112年起陸續開放法官、檢察官與律師使用，113年11月起每日更新資料庫並全面開放民眾查詢。

難處在於量刑因子多、法條細，條件稍一複雜，使用者就會在層層頁面中迷路。我們的目標很單純 – 讓第一次使用的民眾也能順手，讓每天使用的法官查得更快。

 

多條件查詢設計，為什麼要從「入口」開始？

使用者得先認出自己的問題，才有心力面對後面的條件。首頁借用行動App的操作邏輯，把10種案類整合成一張圖像化入口，每類都有專屬色系與icon，例如方向盤代表不能安全駕駛、面具代表詐欺，一眼就能找到案件類型。

我們做大型內部資訊系統時也常這樣處理：模組一多，先用顏色與圖示建立辨識，再把細節留到下一層。

 

條件一多，怎麼讓使用者不迷路、不重填？

把流程收進同一個畫面，並記住使用者的每一個選擇。系統採單頁應用設計：點選案類就在原頁展開適用法條，確定後切換到量刑因子；回頭修改都不必重新輸入。

這也呼應W3C在WCAG 2.2新增的3.3.7「Redundant Entry」(A級)：同一流程中已提供的資訊，不該要求使用者再填一次。結果頁的「調整檢索條件」，就是帶著原條件回到上一步微調。

好的查詢介面不是把條件變少，而是讓每一個條件都看得見、改得回。

 

即時回饋還是一次送出，該怎麼選？

我們的做法是兩者混用，依步驟決定。Nielsen Norman Group把篩選分成「互動式」與「批次式」：前者適合邊選邊看，後者適合已知條件的人，但容易選出零筆結果。

因此選法條時即時顯示資料筆數，先避開查無資料的組合；進入量刑因子後，緩刑、加重減輕、犯後態度等以圖示卡片呈現，點選後用彈窗展開題目，每次選擇都即時更新右側「您所檢索的條件」儀表板。

 

結果頁怎麼讓非專業者也看得懂？

先給重點，再給全貌。結果以表格整理有期徒刑、拘役、罰金的件數與刑度，並用「平均刑度」「量刑區間」卡片把最常被問的數字拉到最前面；下方動態圖表可切換刑種全貌與刑度分布，並依月、3月、6月、年調整區間；手機版則改成適合單手滑動與點選的排列。

 

設計要落地，前後端怎麼分工？

關鍵是先把規格寫清楚。前端以Nuxt4 / Vue 3與TypeScript開發、串接RESTful API；我們制定API格式文件作為共同規格，配合委託夥伴負責後端API開發、AI大數據運算與維運部署，雙方並行開發。

在KYART光沅創意的大型系統專案裡，UI/UX設計、前端工程與API規格是同一條線：畫面上每個條件都對應明確的欄位與回傳格式，設計越貼近規格，前後台整合與雲端維運就越少意外。

每一筆判決都是一次審慎的衡量；介面能做的，是讓這份衡量對每個人都有跡可循。

 

參考資料：
KYART作品：事實型量刑資訊系統(kyart.com.tw)
事實型量刑資訊系統官方網站(intellisen.judicial.gov.tw)
司法院：因應國民法官新制，啟用AI量刑資訊系統(judicial.gov.tw)
Understanding SC 3.3.7: Redundant Entry(w3.org)
User Intent Affects Filter Design(nngroup.com)