重新構想醫療賬單：UI/UX 案例研究

All Data Health 是一家從醫生那裡收集醫療賬單信息並將其發送給保險公司進行付款的公司，該公司聘請我在 2020 年底重新設計其賬單體驗。當時，它的醫生客戶習慣於填寫紙質超級賬單——即包括診斷、程序和保險索賠代碼。

為了提高其理賠流程的速度和準確性，公司領導希望吸引醫生通過現有的醫生門戶提交在線超級賬單（稱為電子超級賬單），但醫生拒絕了。 他們繼續向 All Data Health 郵寄紙質表格，計費專家在向保險公司提交索賠之前手動輸入數據​​。

眾所周知，醫生對新技術持謹慎態度。 安全性、生產力和可負擔性問題導致醫生堅持使用熟悉的方法和工具。 我的任務是重新構想現有的醫療計費軟件，使其用戶友好，以至於醫生會很高興地放棄他們的紙質超級賬單。

方法：研究、線框圖、原型設計

作為一名 UI/UX 設計師和藝術總監，我曾開發過許多面向消費者的產品，我專注於人性化的數字體驗。 三個多月以來，我與 All Data Health 合作更新了計費系統，並構建了一個組件庫和样式指南來配合它。

像往常一樣，我從研究和頭腦風暴開始。 然後，我創建了一個信息架構並使用線框設計了一個低保真原型，然後再轉向高保真原型。 我與客戶的開發團隊密切合作，每天向他們更新我的進度。

用戶體驗研究：確定醫生的工作方式

每個項目都從了解用戶開始。 首先，我會見了 All Data Health 的 CTO 和董事總經理，了解醫生和公司數據錄入專家的需求。 我擁有馬德里卡洛斯三世大學的新聞學學位，並擔任了四年的記者，所以我擅長這種類型的事實調查。

我們一起創建了三個詳細的角色：

• Solo 博士：這位醫生在一個大組織工作，經常填寫表格，上面有相同的診斷和程序。 在電子超級賬單上，他必須能夠輕鬆訪問他最常執行的程序。 表格需要適合移動設備，因為 Solo 醫生需要花費大量時間在醫院樓層和醫療設施之間往返，而且通常無法訪問計算機。
• 辦公室醫生：該醫生經營一個小型辦公室，通常與護士或助理一起工作。 在他的模擬工作流程中，助理準備帶有患者信息的表格，他只需填寫訪問期間執行的程序。
• 有團隊的醫生：這個醫生類似於小企業主； 她經營著一家醫療辦公室並僱用了更多的醫生。 一名全職醫生填寫了部分文書工作，但 Dr. With a Team 最終負責從保險公司收取費用。

特徵分析：注意最佳實踐

我知道 All Data Health 的計費 UX 必須非常直觀，以至於用戶會將其視為一種節省時間的方法，或者至少認識到它不會增加計費時間。 我檢查了將大型項目分解為可管理任務的程序，並受到 TurboTax 網站的幾個方面的啟發：

• 它使用戶一次專注於一項任務。 例如，它通常每頁只問一個問題，例如“您是否出售任何股票、債券、共同基金股票或其他投資？” 並提供簡單的“是”、“否”和“我不知道”按鈕。
• TurboTax 的工作流程不是用冗長的表格壓倒用戶，而是分為工資/收入和扣除/信用等類別。 它還顯示了進度並設定了對下一步的期望——例如，讓用戶知道即將提出的問題將涉及年度收入。
• 它提供並排視圖。 用戶在屏幕的一側填寫工作區域，同時在另一側查看概覽。 概述還用作菜單，因此用戶可以導航到各個部分。

信息架構：設計層次結構

我希望計費 UI 盡可能地模仿醫生紙質表格的佈局，以便讓人感覺熟悉並有助於簡化從紙質到數字的過渡。 我首先將用戶填寫超級賬單的過程分解為更小的步驟。

思維導圖

我使用 Miro 製作了 All Data Health 醫生門戶的思維導圖，以可視化信息的結構。 構建思維導圖使我能夠發現門戶信息架構中的缺陷。 例如，門戶網站只有一個報告選項下拉菜單，但列表很長，這會減慢決策速度。 我建議創建一些高級主題和子主題——一種更清潔、更有效的導航方式。 我還製作了現有電子超級賬單的思維導圖，並確定了需要簡化的區域。

線框

在創建數字版本之前，我經常手繪線框。 然而，這一次，我對自己想要創造的東西有了清晰的認識，所以我繼續使用 Miro。 我修改後的桌面 UI 的第一次迭代在頂部有一個菜單，其中包含四個類別：創建電子超級賬單、報告、患者和個人資料。 它在左側有一個動態導航，它會根據用戶在電子超級賬單中的位置而變化。

在我的建議中，最初的填寫表格很簡單：它要求用戶填寫設施、提供者、日期、程序、診斷和修改器，這些信息提供了有關程序的更多信息。 我還實現了紙質賬單的可視化，以便根據用戶以前的工作方式來定位用戶。

在移動應用程序上，我隱藏了菜單並創建了兩個屏幕，使用戶能夠在完整表單和紙質賬單圖像之間切換，以便他們知道自己在處理過程中的位置。

當我展示最初的線框圖時，CTO 提到我們需要允許添加額外的程序，並且所有內容都必須與保險公司需要的診斷相關聯，因此我創建了一個啟用此功能的組件。

模型：定義用戶流

當我們對軟件的整體外觀和感覺感到滿意時，我們開始模擬用戶流程； 我們為新患者創建了一個，為現有患者創建了一個單獨的。 在模型中，我們涵蓋了理想狀態和基本場景，包括接受多項診斷並接受多個手術的患者，以及在不同機構工作的醫生。 在項目的這個階段獲得客戶反饋至關重要，因此我在每日站立會議上展示了模型。

最後潤色：精煉組件和美學

該項目的目標是創造一種感覺類似於紙質賬單的產品，並且醫生更容易以電子方式提交。 例如，醫生經常填寫紙質賬單的一部分，然後再填寫。 對於重新設計的電子超級賬單，我通過結合在賬單不完整時保存和打印以及在草稿選項卡下檢索未完成賬單的功能來保留這種便利。

此外，我想減少醫生重複輸入相同數據的需要——就像填寫多張紙質賬單時一樣。 所以我創建了一個首選項功能，可以自動填充經常執行的程序。 我還包括使用預測文本的字段。 例如，當醫生輸入患者姓名“Mary”時，軟件會在數據庫中顯示 Marys 的姓氏。

高保真原型

對於原型，我從 Miro 轉移到了 Figma，這更適合設計改進。 客戶對美學的興趣遠低於可用性，並且不希望我花太多時間在視覺設計上。 我瀏覽了 Figma 社區，尋找一個包含我需要的基本組件的設計系統：表單、按鈕、分頁、切換和復選框。

當時，All Data Health 沒有內部設計師或視覺指南，但我希望更新後的計費體驗與公司的其他品牌資產保持一致，因此我從公司主頁中提取了字體和顏色。 我保持視覺語言簡潔，包括盡可能少的文字。

主要學習

我在這個項目上的工作證實，與最終用戶一起驗證產品是值得的。 在這種情況下，醫生在新的電子超級賬單上線之前沒有機會對其進行測試，這導致在發布後進行了多次修復。 此外，我了解到等到設計完成再開始開發的價值。 儘管快速開發可以更快地發布產品，但從長遠來看，由於必須重建系統，因此成本可能更高。

我還能夠對 All Data Health 進行有關敏捷的教育，我們甚至將一些敏捷例程（例如每日站立會議）納入我們的流程。 該公司的領導表示他們計劃在未來包含更多的敏捷方法，並要求我設計另一個將在第二階段推出的功能。

總體而言，All Data Health 認為該項目是成功的，報告稱處理保險索賠的時間減少了一半，並且幾乎消除了錯誤。 通過將醫生從繁瑣的紙質賬單轉變為電子賬單，All Data Health 為其客戶建立了一個高效、有效的系統。

看看最終的電子超級賬單。