2023-12-8 周周
引言
售賣軟件服務的公司，最理想的狀態就是開發一套通用的解決方案或產品，而幾乎不用接收任何定制化需求（定制化需求大多會被內化成通用產品的新功能）。這種經營模式下，公司全部的業務和技術力量都可以集中在這一套標準化產品上。因為人力充足，那些為了提升體驗滿意度而做的努力就很容易有結果，設計師基本不用太過擔心投入的成本。但很多公司面向的客戶形態無法做到這種理想狀態，這些公司對外交付的版本一般都是基于主線版本的定制化版本。為了效益，客戶當然越多越好，交付肯定越快越好，這就意味著評審交互設計師輸出的交互設計方案時，體驗至上不再是首肯的目標，按時交付才是。所以支撐外包項目的時候，交互設計師如果沒有邊界感，輸出的交互設計方案在后面的評審階段將會被不斷推翻，無法落地。前面雖然說了標準化產品維護過程中設計師不用過多考慮實現成本，但標準化產品也會有迭代周期，在一個有限的迭代周期內，也同樣需要考慮邊界問題按時完成版本迭代任務。那么交互設計師支撐外包項目或版本迭代項目時都需要有哪些邊界感呢？今天我們來談談需求邊界和技術邊界。
1. 什么是需求邊界
需求邊界是指在一個明確的目標或產品版本中，為交付具有規定特性與功能的產品、服務或成果而必須完成的有限工作范圍。該范圍可控，不會在外力驅使下隨意更改。
2. 為什么要有需求邊界
試想，如果項目經理對客戶的需求來者不拒，會有什么后果？項目無法按時交付，造成虧損。如果在開發階段，需求依然充滿變數，會有什么后果？開發人員可能會暴走繼而影響團隊士氣。如果提前定義好需求邊界，就等于給下游制定了明確的工作目標，也利于項目排期和進度把控，從而避免出現上述問題。
3. 如何找到需求邊界
① 如何找到項目中的需求邊界
項目在啟動階段，對外需要一份正式的合同來確立合作關系，對組織內部一般都會有《項目工作說明書》《商業論證》《項目章程》等文件來建立內部協議拉通內部目標。其中，《項目章程》會對整個項目的需求范圍做出最原始的定義，一般包含概括性的項目描述、項目產品描述及項目的總體范圍要求，此時定義的需求顆粒度最大。就比如，某銀行項目在此階段的需求就是“上線企業 OA 產品”，這就明確了需求邊界，我們要做企業 OA，而不是做企業網銀。如果項目進行到一半，客戶忽然要求我們做企業網銀產品，那完全可以拒絕，因為超出了需求邊界。（不過站在商業角度，遇到這種情況商務員應該會無比激動，因為來年的 kpi 在向他招手。）
接著，在項目規劃階段最重要的前置工作就是進行項目范圍管理，項目成員需要收集需求、定義范圍、創建 WBS（工作結構分解）。這個階段的 WBS 就是為了打造項目章程中定義的最終產品、服務或成果而進行的需求細化。此時，定義的范圍就可以作為我們進行交互設計工作的指導性文件。（因為在這個階段不細化需求和分解任務，就無法進行準確合理的項目時間管理、成本管理等的規劃工作）。
接著上面的例子，項目啟動階段，《項目章程》里定義的需求邊界為“上線企業 OA 產品”，接著在項目規劃階段，就需要跟客戶溝通確認具體的《功能清單》（見圖 1-1，此文件是項目管理過程中非常重要的文件，如果沒有此文件，項目監控過程將無法進行）。比如說我方通用解決方案里該產品是包含 18 個功能，但客戶可能只需要其中 15 個，然后還要補充幾個我方通用解決方案里沒有的定制化功能。這個功能清單就是需求邊界，也是我們開展交互設計工作的立足點。
《功能清單》示例
如果設計師在設計過程中為了提升體驗而增加了額外的功能，比如說客戶的需求是對發票拍照存檔，交互設計方案中拍完照還能 OCR 識別發票信息，這個設計方案就超出了需求邊界。單純站在體驗的角度上看，真是個很棒的點子，但站在項目管理的角度上看，這是“愚蠢”的，要知道，項目經理時刻擔心項目進度不可控，一定不會讓需求蔓延。
但如果評審交互設計方案時是客戶提出了增加發票 OCR 識別的功能，設計師了解需求邊界的話就不會一口答應導致后面落子悔棋的尷尬局面。（如果客戶提出了任何非交互設計的變更提議，我們都不要一口答應，可以說會后跟項目組討論下再給您答復。）我們也可以了解一些項目經理針對需求變更的處理技巧：需重新評估需求的變動成本，跟客戶說明，修改合同；尋找其他簡單易實現的方案替代；告知用戶在下一迭代版本中進行規劃。
當然，也會有特殊情況，為了維護客戶關系或者按投入結算或者有什么需要達到的 kpi，項目對時間和成本沒有特別要求，對需求變更有很好的包容度，那我們可以盡情發揮我們的設計才能，而不用受需求邊界的約束。
② 如何找到小迭代需求的需求邊界
上面講項目規劃階段的《功能清單》就可以當作項目的需求邊界，但是一般這份功能清單中的功能顆粒度較大，還是需要把一個個功能看成一個個需求，分別進行業務需求、用戶需求、功能需求的剖析和拆解。另外，公司標準化產品的維護過程中，需求往往是市場聲音或是公司上層產品規劃策略亦或是專家走查的待優化問題，這時候如果沒有專門的需求分析師或產品經理，交互設計師接收到的往往不是拆解后的業務需求、用戶需求、功能需求，而是“一句話需求”。我們如何找到這種需求的邊界呢？
我們先了解幾個概念：業務需求、用戶需求、功能需求。
業務需求描述的是用戶為什么需要這個產品，用戶需求描述的是用戶使用該產品必須要完成的任務，功能需求描述的是開發人員必須實現的軟件功能。下面舉個例子來說明 3 個維度的需求，真正的需求邊界就會浮出水面。某個項目的《功能清單》中，有一個“碼上付”的功能，進行客戶調研時，客戶說“因為當前系統跟另一個系統無法進行數據交互，所以在當前系統不知道用戶有沒有申請成功，希望點了碼上付申請彈出一個彈窗，提示用戶不要重復申請。”按照客戶的需求描述，方案如圖 1-2：
客戶描述的方案
該方案違背了交互設計的“防錯原則”，增加了用戶的“試錯成本”，那必須按照客戶的要求做嗎？再次分析客戶的描述，可以發現客戶描述的是功能需求而非業務需求。運用需求分析方法和技巧挖掘它的上層需求（因篇幅有限不再講述分析過程），可以得出以下結論，業務需求是：“防止用戶重復提交碼上付申請”。
接著分析，能滿足以上業務需求的用戶需求是：1.用戶申請成功后不能再進行申請操作（系統阻斷用戶的重復申請行為）；2.用戶能看到“請勿重復申請”的文字提示（靠提示讓用戶自主停止重復申請行為）。
這些用戶需求對應的功能需求是：用戶提交過申請后，將“碼上付”入口置灰禁用，并在入口處打上標簽“已申請”，如果申請成功該入口就一直置灰禁用，如果申請不成功該入口需要變為啟用狀態以便用戶再次申請。
但是客戶的描述給出了技術邊界（后面會詳細講解此概念）：當前系統跟另一個系統無法進行數據交互，所以當前系統不知道用戶有沒有申請成功，這就導致上面分析的用戶需求的第 1 點是無法滿足的，除非我們要求客戶去改造關聯系統而且客戶愿意配合，否則我們只能去修改用戶需求：讓用戶看到“請勿重復申請”的文字提示。靠用戶自己規避重復操作行為。用戶需求一旦修改，對應的功能需求也會隨之變化：在申請碼上付的按鈕附近給出醒目提示“如果您已申請過碼上付，請勿重復申請”。最后的交互設計方案如圖 1-3：
修改后的方案
通過以上案例分析，我們可以把業務需求、用戶需求、功能需求抽象為依次耦合并依次包含的關系。用戶需求和功能需求可能會根據技術邊界或其他約束而改變，但業務需求不會改變，也就是說小迭代需求的業務需求才是真正的需求邊界。
從圖 1-4 可以看到，一開始設計師輸出的方案肯定是滿足業務需求的前提下，用戶體驗最好的方案，但有些用戶需求+功能需求組合超越了技術邊界和其他邊界。我們評審設計稿的過程，其實就是不斷將用戶需求+功能需求修正到各種邊界內的過程。（業務需求一般是在描述需要解決的問題，至于如何解決，就是交互設計師可以發揮的空間。如果業務需求都變了，那就是需求變更，需要走需求變更申請流程。）
備注：以上案例將業務需求描述為“防止用戶重復提交碼上付申請”而不是“阻止用戶重復提交碼上付申請”，大家可以思考一下有何不同？
用戶需求+功能需求修正前后對比
1. 什么是技術邊界
技術邊界是指在現有技術水平可以被實施運用的有限范圍。
2. 設計師為什么要了解技術邊界
一個合格的交互設計師，能靈活運用各種交互設計方法輸出體驗最佳的概念方案是基本要求，但只站在體驗最佳角度考慮問題所出的設計方案會是最終方案嗎？顯然經常不是。
為什么會出現這種情況？除了一開始的需求不清晰不準確導致評審交互設計方案時還需要不斷反向修正需求的原因，還有一大部分原因是體驗最佳的方案無法用現有技術條件實現且重新開發成本太大。
設計方案評審的過程，其實就是一撥需求干系人在不斷尋找業務需求、技術邊界、最佳體驗之間的安全區（見圖 2-1）的過程。如果交互設計師能熟悉技術邊界，一開始輸出的方案就往安全區里靠近，會大大縮短設計周期，否則只能一遍又一遍被按在地上摩擦。
安全區示意
3. 如何獲知技術邊界
① 新產品項目的技術邊界
新產品項目的技術邊界受制于上面提到的《功能清單》，比如設計的過程中，設計師覺得界面上展示一下頭像會使信息更具識別度，這時候就需要去查閱功能清單中有沒有上傳頭像的功能，如果沒有該功能項目經理也不允許增加該功能，我們只能修改設計方案：去掉頭像或者改用通用頭像。其他更細節的邊界幾乎是無法提前預知的，只能在設計方案評審階段或開發階段暴露出來，反向修正設計方案。因此，設計師支撐新產品項目，一定要提前熟知功能清單，有的放矢。
② 已有產品升級項目的技術邊界
如果是舊產品的升級項目，技術邊界相對就多一些，因為要考慮現有系統的兼容性和現有技術的復用性。設計師動手前要體驗產品，瀏覽客戶提供的產品資料、用戶手冊等，盡可能多地提前預知和確認技術邊界，這樣可以減少設計方案的修改次數，提高效率。
還有一些明顯的技術邊界，在需求溝通階段就能暴露出來，比如上面的案例中，客戶一開始就提出“兩個系統目前無法進行數據交互”這個技術邊界，但還有一些邊界只能邊溝通邊發現。比如設計師覺得通用頭像區分性別更具情感化，所以設計方案中女性用粉色通用頭像，男性用藍色通用頭像，評審的時候就需要詢問客戶系統能不能區分性別，如果沒有又無法增加該功能，我們只能修改設計方案：所有人員用同一個顏色的通用頭像。如果評審時沒有確認此細節，開發實現的時候就會找設計師溝通，影響開發進度。
③ 界面結構體現出來的技術邊界
界面結構能反映技術邊界。如果已經確認是在現有的技術能力范圍內補充新功能，那設計師就需要分析已有同類功能的界面結構，以免隨意變更界面結構導致新功能界面結構無法跟已有同類功能界面結構匹配，加大變更成本。
舉例說明，某銀行要上線公司的一套主線產品，且要增加一個功能模塊，該功能模塊的審批流程需要復用基線產品的技術。一開始考慮用戶可能出于催辦等目的，需要在表單申請界面看到完整的審批流程，所以設計新功能模塊時，將審批流程平鋪顯示在了申請表單頁面上（見圖 ）。
基于交互經驗輸出的方案
中間多次設計評審會也未提及這樣設計有何不妥，最后開發做到這里，查看原有功能申請表單頁的代碼，發現同類功能的實現邏輯是將審批流程顯示在了彈窗里（見圖 2-3，顯示在彈窗里而非當前頁面上的歷史原因是為了不破壞原有表單的界面結構）。
現有實現的樣式
開發急轟轟來找設計師：“你這個界面實現不了啊”、“我們之前是這么實現的啊”、“要改也是主線產品改，但肯定來不及呀”，項目經理也急轟轟來找設計師：“按照現有技術實現的方式改下交互設計方案吧”、“項目交付時間快到了，別發散了啊”，在多重壓力下設計師就得硬著頭皮按照彈窗的樣式，把所有表單申請頁面全部改一遍（不改干凈，新加入項目的開發人員會思考半天，然后來問你：這里為什么跟其他頁面不一樣，是有什么考慮嗎？或是碰到“直男”開發，真的就按錯誤的交互界面實現）。
按照現有實現修正后的方案
如果對已有產品不熟悉，對已有的界面結構不熟悉，類似的情況會經常發生，這無疑增加了時間成本和溝通成本，是項目大忌。所以，設計師一定要會識別界面結構體現出來的技術邊界。
“國家制度、法律法規、行業標準”也是設計工作的重要邊界。
比如，理財產品界面一定要打上“市場有風險，投資需謹慎”的提示字樣，不可用高回報高收益宣傳口號誘導用戶；再比如，保險產品宣傳時必須明示是保險產品，且不得與銀行儲蓄、基金、國債等進行收益比較。
硬件設備的操作方式也是設計工作的重要邊界，比如說使用遙控器操作的終端界面，要特別考慮遙控器操作的局限性，不可讓用戶輸入大段文字，可通過手機掃碼填寫的方式替代；再比如，操作觸摸屏時，不能像操作 pc 一樣出現右擊操作。還有，設計規范也是設計工作的重要邊界，如果不考慮設計規范一致性，會增加用戶的學習成本。
除了上面展開討論的需求邊界和技術邊界，還有后面提到的“制度法規”、“硬件設備”、“設計規范”，還有很多因素共同決定最終的交互設計方案。設計師可以在平時的工作中培養自己洞察邊界的能力，以便輸出更加成熟的方案。
1. 須具備需求分析的能力
設計師接收到需求之后，要能判斷接收到的是不是業務需求，最好把業務需求用自己的語言描述出來拿給需求方確認。（如果團隊分工明確，一般產品經理會把基于各種邊界條件分析好的業務需求和用戶需求給到設計師。如果團隊無此角色，就得靠設計師自己識別。）就像前面提到的例子，如果業務需求是“阻止用戶重復提交碼上付申請”，而不是“防止用戶重復提交碼上付申請”，那性質就不一樣了，阻止是不允許用戶重復提交，那就得逼著客戶和開發調整技術邊界。但客戶實際的意圖是提醒用戶最好不要重復提交，但允許重復提交。
確認好業務需求，如果時間充裕，可以先不考慮技術邊界，輸出一個體驗最佳的方案，然后再根據自己已知的不可抗力約束逐漸修正方案，如果時間緊張，這一過程可以在腦海里構思，直接輸出修正后的方案組織評審。
2. 具有洞察邊界的能力但又有打破邊界的勇氣
考慮各種約束久了，我有時候設計方案首先考慮的是開發能不能實現，好不好實現，這真的大錯特錯。設計師需要有技術邊界感，但不能讓技術邊界感凌駕于體驗設計之上，否則交互設計師就失去了存在的意義。
例如，之前提到的發票 OCR 識別功能為例，應客戶要求，要在主線產品的發票夾功能基礎上增加發票 OCR 識別的子功能，該需求還要內化成主線功能。其中添加發票的界面，原來的界面結構是左圖所示，頁面的主體信息是發票照片的預覽圖像，加入發票 OCR 識別功能后，我考慮到萬一將來有些客戶不上發票 OCR 識別功能，或者識別不出信息的情況下，還是得按 4-1 左圖展示，所以基于新舊系統和無數據場景的兼容性，我沒有改變原有的界面結構，只是在預覽圖下面增加了識別信息的展示區域，即 右圖展示。
不破壞原有界面結構輸出方案（左圖為原有頁面）
但對用戶來說，識別出來的發票信息才是他重點關注的內容，預覽圖只是個輔助信息，按照這個心智模型，首屏的主體信息應該是識別出來的發票信息，但上面的方案，首屏的主體信息是預覽圖。
后來 UI 同事在進行視覺設計的時候，詢問了開發能不能改變預覽圖的樣式，得到開發負責人同意后，UI 同事按照信息層級關系優化頁面（見 4-2 左圖），而且跟開發溝通增加了一個擴展功能：沒有成功識別到信息場景下和沒有上線發票 OCR 識別功能的場景下，預置幾個各種發票類型都會有的主要信息字段，讓用戶自動填入，見 4-2 右圖（原有的發票夾功能，只有一個備注字段）。當我還在考慮開發盡量少改動時，UI 同事打破邊界的勇氣和靈活變通的智慧深深地給我上了一課。
擴張邊界后輸出的方案
3. 總結
這篇文章講了交互設計應具備的幾個邊界感，希望能幫助設計師快速輸出安全區內方案以縮短評審修改周期，但請切記不可完全被邊界束縛住手腳。交互設計師仍要站在體驗最佳的立場，去爭取擴張技術邊界和其他邊界，給設計打造更大的安全區和發揮空間。
文章來源：優設網 作者：兆日UCD
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計(www.73404.com.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的大數據可視化界面設計、B端界面設計、桌面端界面設計、APP界面設計、圖標定制、用戶體驗設計、交互設計、UI咨詢、高端網站設計、平面設計，以及相關的軟件開發服務，咨詢電話：01063334945。
關鍵詞：UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、用戶體驗公司、軟件界面設計公司、軟件qt開發、軟件wpf開發、軟件vue開發。
