#本文為人人都是產品經理《原創激勵計劃》出品。

產品經理在初入職場的時候，往往只會負責某些簡單功能的設計和修護。等到了能力和經驗都具備的時候，就可以進階到獨立負責一個完整的產品設計的階段。本文作者分享如何通過用戶體驗五要素，獨立完成醫療信息系統的產品設計，希望對你有幫助。

能夠不只是負責部分功能模塊的設計，而是能夠獨立負責一個完整的產品設計是很多產品人的職場階段目標之一。筆者也是如此，當年期盼已久后終于有機會負責了一款完整B端醫院?？飘a品的設計。

這款產品的復雜度不算高，卻使我有機會第一次獨立負責設計了一個完整產品，并且順利上線了公司的重點客戶醫院，也獲得了其省份護理學會信息化案例比賽的省級獎項。

這次產品設計經歷使我收獲了一些寶貴的產品設計經驗，現在回想起來當時的過程仍然覺得津津有味。如果你此時正準備躍躍欲試嘗試獨立負責設計完整產品，或者剛剛收到了設計完整產品的工作任務感覺無從下手，那么就跟我一起來回顧我當時通過用戶體驗五要素的方式考慮的設計思路吧。

一、戰略層

簡單介紹下產品背景，我們公司一家重點客戶醫院在上線全院信息系統時，要求上線一個專門針對新生兒病區某個護理工作流程所使用的?？菩畔⑾到y。

公司考慮該醫院主要信息系統都將切換為公司新產品，為了各系統之間更好的互聯互通，決定不使用公司已有的老系統上線，由我們部門在新產品架構下設計一款新產品為醫院上線。

在這樣的背景下，我們領導承擔了這項任務，并將其交由我來做主要設計。我在收到產品設計任務之后，首先想到了按照用戶體驗五要素的思路確定產品的設計流程。

首先從戰略層上主要考慮了以下問題：

1. 目前業務場景及其通點

經過現場調研，該醫院的新生兒病區是其特色病區，針對某項護理工作有更精細化的管理流程。但是這項護理工作目前病區是全部線下操作，并未使用信息系統，導致存在以下痛點：

• 對臨床護士來說，目前的線下各類紙質記錄工作量大，易出錯；相同數據需重復記錄至不同文書，工作效率低；操作規范僅靠護士人工判斷，存在一定的安全風險。
• 對管理層來說，部分流程節點操作不方便記錄，導致后期過程無法追溯；醫護信息系統各類功能未關聯該項護理操作，導致該護理工作未形成閉環管理；業務產生的數據量大，統計報表效率低且準確率沒有保證。

2. 產品目標

從用戶的角度，我希望產品設計能夠解決該醫院管理和臨床業務使用場景的痛點問題，對業務全流程進行實時監督和反饋，實現業務各環節的閉環鏈路。該目標達成的標志就是能夠順利將該產品在醫院上線并獲得認可。

從客戶的角度，系統除了能夠解決用戶在使用過程中的實際需求外，還要能夠支持醫院在信息化評級時滿足評級文件中對對該項業務要求的其它功能。用戶目前階段可能不會使用或者較少使用到這些功能，但是要滿足醫院信息化整體建設評級的要求。該目標達成的標志是產品功能通過醫院信息化評級自評認可。

從產品商業角度，通過對市場情況的了解，該產品的使用規模在行業里較小，單價也僅在數十萬元，好像乍一看是一款市場規模少，經濟效益低的不值得長期投入的產品。但是仔細分析后我們認為，該產品規模小的原因是使用該產品進行精益化管理的都是大型三甲或大型集團醫院，而這類醫院的對我們公司所帶來的口碑和品牌價值是要遠遠超過經濟價值的。

另一方面，雖然我國大部分醫院的該項護理工作并目前未達到需要使用信息系統進行管理的程度，但是由于在某項醫院信息化建設的高級別指標中包含了該信息系統的使用。所以從長遠角度來看，隨著我國醫院信息化建設的整體發展，該款產品的市場規模是會逐漸擴增的。

所以產品的商業目標也就不是項目化的滿足這一家醫院上線，而是實現產品化能夠以較小的成本實現該產品未來市場的批量推廣交付。

二、范圍層

戰略層已經確定了我們要做一款什么樣的產品，以及明確了產品目標和目標達成標志，規劃好了宏偉藍圖。但是真正落地還是要將規劃根據我們的產品和工作現狀再合理分割成產品的各階段以及明確各階段的產品設計范圍。

短期產品設計范圍，適合基于MVP理論實現最小可行化產品，主要以用戶業務使用的主流程為主，完成在醫院規定時間內上線的任務。同時在產品設計過程中也要要考慮到產品的可擴展性，為中長期的功能擴展搭好基礎框架。

中期產品設計范圍，以滿足醫院信息化建設評級為主，對照評級要求在產品主流程中和主流程之外合理的擴充更多功能細節。

長期產品設計范圍，以市場批量推廣為主，要考慮市場需求情況，做到其它醫院能夠通過配置或盡量小的改動成本滿足業務需求和醫院上線要求。

明確好產品各階段的設計范圍后和優先級后，就可以將通過用戶調研、市場分析、競品分析、政策文件等各種方式收集到的需求納入需求池按照優先級進行跟蹤管理了。

需要注意的是，當我們的戰略層和范圍層確定之后，最好和產品的相關方一起再進行確認。

比如要和領導進行確認，工作任務要和領導的目標保持一致，因為領導也需要和他的領導目標保持一致。只有獲得領導的認可和支持，并且由他們協調好相關方，我們的工作才能繼續推進下去，否則再完美的方案如果脫離了公司與管理層的目標也只有被遺棄的結果。

再比如要和研發負責人進行確定，讓研發同事也知曉并認可產品目標，這樣在后期研發開發時，針對需求的優先級處理、實現方式能更好的安排到位。避免出現該配置需求的研發認為加大了工作量、該處理的需求研發認為沒必要做等抵觸情況出現。

三、結構層

明確了產品目標和產品設計范圍之后，再看著需求里新鮮出爐的需求，是不是按捺不住要把原型畫起來立刻征服它們了。

別急，在進行產品設計之前可以先通過流程圖確定好產品的業務流程，并通過業務流程大致確定產品需要哪些功能模塊，再根據產品各模塊之間的相互關系確定產品結構。

在確定產品結構時首先考慮產品的載體。PC端是醫院系統的主要承載方式，所以我們產品以PC操作為主，通過獨立的PC操作即能完成業務閉環。

同時該醫院還具備大量移動端設備，所以針對部分場景的功能也提供移動端操作，這部分功能場景在移動端實時性、準確性的優勢下能較PC發揮更好的作用。所以我們的產品載體就確定為PC+移動。

其次考慮產品入口，因為該產品本身的使用者為護士，并且是由病區護士使用，為了避免護士在病區同一臺電腦需要來回切換多個系統的情況，我不再提供單獨的系統入口。

而是將產品入口嵌入到病區護士主要使用的住院護士站系統中，在PC的住院護士站系統通過一級主菜單作為入口。

移動端入口同理，病區護士主要使用的移動端為移動護理APP，將移動端入口嵌入到移動護理APP的首頁導航一級主菜單中。

之后考慮各功能模塊之間的連接，該項護理工作的流程是具備從前到后的連貫流程屬性的，所以PC端的多個功能模塊可以通過多個子級菜單順序顯示或者一個頁面多個tab頁順序顯示的形式呈現。

又考慮到我們是嵌入到其它系統中，不宜顯示多個菜單占用寶貴的導航欄菜單區域，所以確定通過一個入口菜單進入到頁面后，通過多tab頁的形式展現各個功能模塊，并可在同一頁面切換不同的tab頁，保障業務流程的連貫性。

移動端同理，只以一個菜單作為入口。但是因為移動端所呈現的是部分功能模塊，不是完整的業務流程，移動端對應的用戶角色也是會沉浸在其中一個用戶場景持續性操作。

為了保障用戶的沉浸式操作和各功能之間的數據不會因誤操作互相污染，在移動端就不采用一個頁面多tab頁的形式，而是將移動端的幾個功能模塊再次作為獨立的二級入口，各個入口進去后是獨立功能操作區域。

四、框架層

好了到這里產品結構確定了也就意味著產品的骨架搭好了，接下來就可以在各個骨架中間填充血肉了，也就是框架層的設計。

現在終于可以打開你的原型設計軟件大展身手，對每個業務模塊的功能頁面進行設計了?？蚣軐邮谴_定頁面的整體布局情況，劃定頁面各個區域的功能屬性。

比如這個功能頁面需要選擇患者、顯示患者信息、顯示數據信息、提示信息、增刪改查、其它操作等，針對這些會出現在頁面中的顯示信息、操作組件等內容就要為他們分配合理的區域。

五、表現層

合理分配好頁面各區域功能屬性之后，為了給用戶在各種感官上提供更好的交互體驗，就需要結合業務場景再通過對比、對齊、層次、字體、顏色、排版、特效、一致性等多種展現效果在頁面各個元素的表現上下功夫了。

我們團隊是具備專門的設計部門，通常這部分是我們產品出初稿原型后，再交由他們出專業的設計圖。

一般我們生活工作中用到的產品在框架層和表現層的設計原則其實就是“合理”。合理是我們使用軟件時的一種感受。這里篇幅有限，就不再系統性的進行解釋了，大家可以參考一些設計書籍或向已有的軟件頁面進行學習。

到這里產品設計部分的流程就結束了，產品經理已經可以輸出原型方案了，但是還不要著急讓研發進行開發。因為這款產品既然有明確的目標用戶，在產品方案確定好之后就可以找到關鍵用戶進行功能確認。

這么做一方面是做好用戶的期望值管理，讓用戶提前清楚產品上線時的模樣，不會出現用戶因期望值過高而導致產品上線后對現狀不滿意的情況發生。

另一方面也是做好產品的風險管理，產品的需求雖然來自用戶，但是需求在表達和轉達的過程中避免不了出現誤傳、漏傳的情況。如果等產品開發完成后才發現這些問題，那么就增加了額外的時間成本和人員成本。

所以在條件允許的情況可以和關鍵用戶一起確認方案，把控住產品設計可能會出現風險的地方，這么做也會讓關鍵用戶有更多的參與感，增加對產品的好感度。

六、最后

到這里產品就基本可以進入到評審和研發階段了，產品設計工作算是階段性的告一段落。

大家可以看到通過用戶體驗五要素的思路方法的確能夠比較好的讓自己建立起可執行的工作流程，對產品設計和管理的幫助是非常大的。

推薦大家可以去繼續閱讀學習AJAX之父Jesse James Garrett的原書《用戶體驗要素》~