引言

售賣(mài)軟件服務(wù)的公司，最理想的狀態(tài)就是開(kāi)發(fā)一套通用的解決方案或產(chǎn)品，而幾乎不用接收任何定制化需求（定制化需求大多會(huì)被內(nèi)化成通用產(chǎn)品的新功能）。這種經(jīng)營(yíng)模式下，公司全部的業(yè)務(wù)和技術(shù)力量都可以集中在這一套標(biāo)準(zhǔn)化產(chǎn)品上。因?yàn)槿肆Τ渥?，那些為了提升體驗(yàn)滿意度而做的努力就很容易有結(jié)果，設(shè)計(jì)師基本不用太過(guò)擔(dān)心投入的成本。但很多公司面向的客戶形態(tài)無(wú)法做到這種理想狀態(tài)，這些公司對(duì)外交付的版本一般都是基于主線版本的定制化版本。為了效益，客戶當(dāng)然越多越好，交付肯定越快越好，這就意味著評(píng)審交互設(shè)計(jì)師輸出的交互設(shè)計(jì)方案時(shí)，體驗(yàn)至上不再是首肯的目標(biāo)，按時(shí)交付才是。所以支撐外包項(xiàng)目的時(shí)候，交互設(shè)計(jì)師如果沒(méi)有邊界感，輸出的交互設(shè)計(jì)方案在后面的評(píng)審階段將會(huì)被不斷推翻，無(wú)法落地。前面雖然說(shuō)了標(biāo)準(zhǔn)化產(chǎn)品維護(hù)過(guò)程中設(shè)計(jì)師不用過(guò)多考慮實(shí)現(xiàn)成本，但標(biāo)準(zhǔn)化產(chǎn)品也會(huì)有迭代周期，在一個(gè)有限的迭代周期內(nèi)，也同樣需要考慮邊界問(wèn)題按時(shí)完成版本迭代任務(wù)。那么交互設(shè)計(jì)師支撐外包項(xiàng)目或版本迭代項(xiàng)目時(shí)都需要有哪些邊界感呢？今天我們來(lái)談?wù)勑枨筮吔绾图夹g(shù)邊界。

一、需求邊界

1. 什么是需求邊界

需求邊界是指在一個(gè)明確的目標(biāo)或產(chǎn)品版本中，為交付具有規(guī)定特性與功能的產(chǎn)品、服務(wù)或成果而必須完成的有限工作范圍。該范圍可控，不會(huì)在外力驅(qū)使下隨意更改。

2. 為什么要有需求邊界

試想，如果項(xiàng)目經(jīng)理對(duì)客戶的需求來(lái)者不拒，會(huì)有什么后果？項(xiàng)目無(wú)法按時(shí)交付，造成虧損。如果在開(kāi)發(fā)階段，需求依然充滿變數(shù)，會(huì)有什么后果？開(kāi)發(fā)人員可能會(huì)暴走繼而影響團(tuán)隊(duì)士氣。如果提前定義好需求邊界，就等于給下游制定了明確的工作目標(biāo)，也利于項(xiàng)目排期和進(jìn)度把控，從而避免出現(xiàn)上述問(wèn)題。

3. 如何找到需求邊界

① 如何找到項(xiàng)目中的需求邊界

項(xiàng)目在啟動(dòng)階段，對(duì)外需要一份正式的合同來(lái)確立合作關(guān)系，對(duì)組織內(nèi)部一般都會(huì)有《項(xiàng)目工作說(shuō)明書(shū)》《商業(yè)論證》《項(xiàng)目章程》等文件來(lái)建立內(nèi)部協(xié)議拉通內(nèi)部目標(biāo)。其中，《項(xiàng)目章程》會(huì)對(duì)整個(gè)項(xiàng)目的需求范圍做出最原始的定義，一般包含概括性的項(xiàng)目描述、項(xiàng)目產(chǎn)品描述及項(xiàng)目的總體范圍要求，此時(shí)定義的需求顆粒度最大。就比如，某銀行項(xiàng)目在此階段的需求就是"上線企業(yè) OA 產(chǎn)品"，這就明確了需求邊界，我們要做企業(yè) OA，而不是做企業(yè)網(wǎng)銀。如果項(xiàng)目進(jìn)行到一半，客戶忽然要求我們做企業(yè)網(wǎng)銀產(chǎn)品，那完全可以拒絕，因?yàn)槌隽诵枨筮吔?。（不過(guò)站在商業(yè)角度，遇到這種情況商務(wù)員應(yīng)該會(huì)無(wú)比激動(dòng)，因?yàn)閬?lái)年的 KPI 在向他招手。）

接著，在項(xiàng)目規(guī)劃階段最重要的前置工作就是進(jìn)行項(xiàng)目范圍管理，項(xiàng)目成員需要收集需求、定義范圍、創(chuàng)建 WBS（工作結(jié)構(gòu)分解）。這個(gè)階段的 WBS 就是為了打造項(xiàng)目章程中定義的最終產(chǎn)品、服務(wù)或成果而進(jìn)行的需求細(xì)化。此時(shí)，定義的范圍就可以作為我們進(jìn)行交互設(shè)計(jì)工作的指導(dǎo)性文件。（因?yàn)樵谶@個(gè)階段不細(xì)化需求和分解任務(wù)，就無(wú)法進(jìn)行準(zhǔn)確合理的項(xiàng)目時(shí)間管理、成本管理等的規(guī)劃工作）。

接著上面的例子，項(xiàng)目啟動(dòng)階段，《項(xiàng)目章程》里定義的需求邊界為"上線企業(yè) OA 產(chǎn)品"，接著在項(xiàng)目規(guī)劃階段，就需要跟客戶溝通確認(rèn)具體的《功能清單》（見(jiàn)圖 1-1，此文件是項(xiàng)目管理過(guò)程中非常重要的文件，如果沒(méi)有此文件，項(xiàng)目監(jiān)控過(guò)程將無(wú)法進(jìn)行）。比如說(shuō)我方通用解決方案里該產(chǎn)品是包含 18 個(gè)功能，但客戶可能只需要其中 15 個(gè)，然后還要補(bǔ)充幾個(gè)我方通用解決方案里沒(méi)有的定制化功能。這個(gè)功能清單就是需求邊界，也是我們開(kāi)展交互設(shè)計(jì)工作的立足點(diǎn)。

《功能清單》示例

如果設(shè)計(jì)師在設(shè)計(jì)過(guò)程中為了提升體驗(yàn)而增加了額外的功能，比如說(shuō)客戶的需求是對(duì)發(fā)票拍照存檔，交互設(shè)計(jì)方案中拍完照還能 OCR 識(shí)別發(fā)票信息，這個(gè)設(shè)計(jì)方案就超出了需求邊界。單純站在體驗(yàn)的角度上看，真是個(gè)很棒的點(diǎn)子，但站在項(xiàng)目管理的角度上看，這是"愚蠢"的，要知道，項(xiàng)目經(jīng)理時(shí)刻擔(dān)心項(xiàng)目進(jìn)度不可控，一定不會(huì)讓需求蔓延。

但如果評(píng)審交互設(shè)計(jì)方案時(shí)是客戶提出了增加發(fā)票 OCR 識(shí)別的功能，設(shè)計(jì)師了解需求邊界的話就不會(huì)一口答應(yīng)導(dǎo)致后面落子悔棋的尷尬局面。（如果客戶提出了任何非交互設(shè)計(jì)的變更提議，我們都不要一口答應(yīng)，可以說(shuō)會(huì)后跟項(xiàng)目組討論下再給您答復(fù)。）我們也可以了解一些項(xiàng)目經(jīng)理針對(duì)需求變更的處理技巧：需重新評(píng)估需求的變動(dòng)成本，跟客戶說(shuō)明，修改合同；尋找其他簡(jiǎn)單易實(shí)現(xiàn)的方案替代；告知用戶在下一迭代版本中進(jìn)行規(guī)劃。

當(dāng)然，也會(huì)有特殊情況，為了維護(hù)客戶關(guān)系或者按投入結(jié)算或者有什么需要達(dá)到的 kpi，項(xiàng)目對(duì)時(shí)間和成本沒(méi)有特別要求，對(duì)需求變更有很好的包容度，那我們可以盡情發(fā)揮我們的設(shè)計(jì)才能，而不用受需求邊界的約束。

② 如何找到小迭代需求的需求邊界

上面講項(xiàng)目規(guī)劃階段的《功能清單》就可以當(dāng)作項(xiàng)目的需求邊界，但是一般這份功能清單中的功能顆粒度較大，還是需要把一個(gè)個(gè)功能看成一個(gè)個(gè)需求，分別進(jìn)行業(yè)務(wù)需求、用戶需求、功能需求的剖析和拆解。另外，公司標(biāo)準(zhǔn)化產(chǎn)品的維護(hù)過(guò)程中，需求往往是市場(chǎng)聲音或是公司上層產(chǎn)品規(guī)劃策略亦或是專(zhuān)家走查的待優(yōu)化問(wèn)題，這時(shí)候如果沒(méi)有專(zhuān)門(mén)的需求分析師或產(chǎn)品經(jīng)理，交互設(shè)計(jì)師接收到的往往不是拆解后的業(yè)務(wù)需求、用戶需求、功能需求，而是"一句話需求"。我們?nèi)绾握业竭@種需求的邊界呢？

我們先了解幾個(gè)概念：業(yè)務(wù)需求、用戶需求、功能需求。

業(yè)務(wù)需求描述的是用戶為什么需要這個(gè)產(chǎn)品，用戶需求描述的是用戶使用該產(chǎn)品必須要完成的任務(wù)，功能需求描述的是開(kāi)發(fā)人員必須實(shí)現(xiàn)的軟件功能。下面舉個(gè)例子來(lái)說(shuō)明 3 個(gè)維度的需求，真正的需求邊界就會(huì)浮出水面。某個(gè)項(xiàng)目的《功能清單》中，有一個(gè)"碼上付"的功能，進(jìn)行客戶調(diào)研時(shí)，客戶說(shuō)"因?yàn)楫?dāng)前系統(tǒng)跟另一個(gè)系統(tǒng)無(wú)法進(jìn)行數(shù)據(jù)交互，所以在當(dāng)前系統(tǒng)不知道用戶有沒(méi)有申請(qǐng)成功，希望點(diǎn)了碼上付申請(qǐng)彈出一個(gè)彈窗，提示用戶不要重復(fù)申請(qǐng)。"按照客戶的需求描述，方案如圖 1-2：

客戶描述的方案

該方案違背了交互設(shè)計(jì)的"防錯(cuò)原則"，增加了用戶的"試錯(cuò)成本"，那必須按照客戶的要求做嗎？再次分析客戶的描述，可以發(fā)現(xiàn)客戶描述的是功能需求而非業(yè)務(wù)需求。運(yùn)用需求分析方法和技巧挖掘它的上層需求（因篇幅有限不再講述分析過(guò)程），可以得出以下結(jié)論，業(yè)務(wù)需求是："防止用戶重復(fù)提交碼上付申請(qǐng)"。

接著分析，能滿足以上業(yè)務(wù)需求的用戶需求是：1.用戶申請(qǐng)成功后不能再進(jìn)行申請(qǐng)操作（系統(tǒng)阻斷用戶的重復(fù)申請(qǐng)行為）；2.用戶能看到"請(qǐng)勿重復(fù)申請(qǐng)"的文字提示（靠提示讓用戶自主停止重復(fù)申請(qǐng)行為）。

這些用戶需求對(duì)應(yīng)的功能需求是：用戶提交過(guò)申請(qǐng)后，將"碼上付"入口置灰禁用，并在入口處打上標(biāo)簽"已申請(qǐng)"，如果申請(qǐng)成功該入口就一直置灰禁用，如果申請(qǐng)不成功該入口需要變?yōu)閱⒂脿顟B(tài)以便用戶再次申請(qǐng)。

但是客戶的描述給出了技術(shù)邊界（后面會(huì)詳細(xì)講解此概念）：當(dāng)前系統(tǒng)跟另一個(gè)系統(tǒng)無(wú)法進(jìn)行數(shù)據(jù)交互，所以當(dāng)前系統(tǒng)不知道用戶有沒(méi)有申請(qǐng)成功，這就導(dǎo)致上面分析的用戶需求的第 1 點(diǎn)是無(wú)法滿足的，除非我們要求客戶去改造關(guān)聯(lián)系統(tǒng)而且客戶愿意配合，否則我們只能去修改用戶需求：讓用戶看到"請(qǐng)勿重復(fù)申請(qǐng)"的文字提示?？坑脩糇约阂?guī)避重復(fù)操作行為。用戶需求一旦修改，對(duì)應(yīng)的功能需求也會(huì)隨之變化：在申請(qǐng)碼上付的按鈕附近給出醒目提示"如果您已申請(qǐng)過(guò)碼上付，請(qǐng)勿重復(fù)申請(qǐng)"。最后的交互設(shè)計(jì)方案如圖 1-3：

修改后的方案

通過(guò)以上案例分析，我們可以把業(yè)務(wù)需求、用戶需求、功能需求抽象為依次耦合并依次包含的關(guān)系。用戶需求和功能需求可能會(huì)根據(jù)技術(shù)邊界或其他約束而改變，但業(yè)務(wù)需求不會(huì)改變，也就是說(shuō)小迭代需求的業(yè)務(wù)需求才是真正的需求邊界。

從圖 1-4 可以看到，一開(kāi)始設(shè)計(jì)師輸出的方案肯定是滿足業(yè)務(wù)需求的前提下，用戶體驗(yàn)最好的方案，但有些用戶需求+功能需求組合超越了技術(shù)邊界和其他邊界。我們?cè)u(píng)審設(shè)計(jì)稿的過(guò)程，其實(shí)就是不斷將用戶需求+功能需求修正到各種邊界內(nèi)的過(guò)程。（業(yè)務(wù)需求一般是在描述需要解決的問(wèn)題，至于如何解決，就是交互設(shè)計(jì)師可以發(fā)揮的空間。如果業(yè)務(wù)需求都變了，那就是需求變更，需要走需求變更申請(qǐng)流程。）

備注：以上案例將業(yè)務(wù)需求描述為"防止用戶重復(fù)提交碼上付申請(qǐng)"而不是"阻止用戶重復(fù)提交碼上付申請(qǐng)"，大家可以思考一下有何不同？

用戶需求+功能需求修正前后對(duì)比

二、技術(shù)邊界

1. 什么是技術(shù)邊界

技術(shù)邊界是指在現(xiàn)有技術(shù)水平可以被實(shí)施運(yùn)用的有限范圍。

2. 設(shè)計(jì)師為什么要了解技術(shù)邊界

一個(gè)合格的交互設(shè)計(jì)師，能靈活運(yùn)用各種交互設(shè)計(jì)方法輸出體驗(yàn)最佳的概念方案是基本要求，但只站在體驗(yàn)最佳角度考慮問(wèn)題所出的設(shè)計(jì)方案會(huì)是最終方案嗎？顯然經(jīng)常不是。

為什么會(huì)出現(xiàn)這種情況？除了一開(kāi)始的需求不清晰不準(zhǔn)確導(dǎo)致評(píng)審交互設(shè)計(jì)方案時(shí)還需要不斷反向修正需求的原因，還有一大部分原因是體驗(yàn)最佳的方案無(wú)法用現(xiàn)有技術(shù)條件實(shí)現(xiàn)且重新開(kāi)發(fā)成本太大。

設(shè)計(jì)方案評(píng)審的過(guò)程，其實(shí)就是一撥需求干系人在不斷尋找業(yè)務(wù)需求、技術(shù)邊界、最佳體驗(yàn)之間的安全區(qū)（見(jiàn)圖 2-1）的過(guò)程。如果交互設(shè)計(jì)師能熟悉技術(shù)邊界，一開(kāi)始輸出的方案就往安全區(qū)里靠近，會(huì)大大縮短設(shè)計(jì)周期，否則只能一遍又一遍被按在地上摩擦。

安全區(qū)示意

3. 如何獲知技術(shù)邊界

① 新產(chǎn)品項(xiàng)目的技術(shù)邊界

新產(chǎn)品項(xiàng)目的技術(shù)邊界受制于上面提到的《功能清單》，比如設(shè)計(jì)的過(guò)程中，設(shè)計(jì)師覺(jué)得界面上展示一下頭像會(huì)使信息更具識(shí)別度，這時(shí)候就需要去查閱功能清單中有沒(méi)有上傳頭像的功能，如果沒(méi)有該功能項(xiàng)目經(jīng)理也不允許增加該功能，我們只能修改設(shè)計(jì)方案：去掉頭像或者改用通用頭像。其他更細(xì)節(jié)的邊界幾乎是無(wú)法提前預(yù)知的，只能在設(shè)計(jì)方案評(píng)審階段或開(kāi)發(fā)階段暴露出來(lái)，反向修正設(shè)計(jì)方案。因此，設(shè)計(jì)師支撐新產(chǎn)品項(xiàng)目，一定要提前熟知功能清單，有的放矢。

② 已有產(chǎn)品升級(jí)項(xiàng)目的技術(shù)邊界

如果是舊產(chǎn)品的升級(jí)項(xiàng)目，技術(shù)邊界相對(duì)就多一些，因?yàn)橐紤]現(xiàn)有系統(tǒng)的兼容性和現(xiàn)有技術(shù)的復(fù)用性。設(shè)計(jì)師動(dòng)手前要體驗(yàn)產(chǎn)品，瀏覽客戶提供的產(chǎn)品資料、用戶手冊(cè)等，盡可能多地提前預(yù)知和確認(rèn)技術(shù)邊界，這樣可以減少設(shè)計(jì)方案的修改次數(shù)，提高效率。

還有一些明顯的技術(shù)邊界，在需求溝通階段就能暴露出來(lái)，比如上面的案例中，客戶一開(kāi)始就提出"兩個(gè)系統(tǒng)目前無(wú)法進(jìn)行數(shù)據(jù)交互"這個(gè)技術(shù)邊界，但還有一些邊界只能邊溝通邊發(fā)現(xiàn)。比如設(shè)計(jì)師覺(jué)得通用頭像區(qū)分性別更具情感化，所以設(shè)計(jì)方案中女性用粉色通用頭像，男性用藍(lán)色通用頭像，評(píng)審的時(shí)候就需要詢問(wèn)客戶系統(tǒng)能不能區(qū)分性別，如果沒(méi)有又無(wú)法增加該功能，我們只能修改設(shè)計(jì)方案：所有人員用同一個(gè)顏色的通用頭像。如果評(píng)審時(shí)沒(méi)有確認(rèn)此細(xì)節(jié)，開(kāi)發(fā)實(shí)現(xiàn)的時(shí)候就會(huì)找設(shè)計(jì)師溝通，影響開(kāi)發(fā)進(jìn)度。

③ 界面結(jié)構(gòu)體現(xiàn)出來(lái)的技術(shù)邊界

界面結(jié)構(gòu)能反映技術(shù)邊界。如果已經(jīng)確認(rèn)是在現(xiàn)有的技術(shù)能力范圍內(nèi)補(bǔ)充新功能，那設(shè)計(jì)師就需要分析已有同類(lèi)功能的界面結(jié)構(gòu)，以免隨意變更界面結(jié)構(gòu)導(dǎo)致新功能界面結(jié)構(gòu)無(wú)法跟已有同類(lèi)功能界面結(jié)構(gòu)匹配，加大變更成本。

舉例說(shuō)明，某銀行要上線公司的一套主線產(chǎn)品，且要增加一個(gè)功能模塊，該功能模塊的審批流程需要復(fù)用基線產(chǎn)品的技術(shù)。一開(kāi)始考慮用戶可能出于催辦等目的，需要在表單申請(qǐng)界面看到完整的審批流程，所以設(shè)計(jì)新功能模塊時(shí)，將審批流程平鋪顯示在了申請(qǐng)表單頁(yè)面上（見(jiàn)圖 ）。

基于交互經(jīng)驗(yàn)輸出的方案

中間多次設(shè)計(jì)評(píng)審會(huì)也未提及這樣設(shè)計(jì)有何不妥，最后開(kāi)發(fā)做到這里，查看原有功能申請(qǐng)表單頁(yè)的代碼，發(fā)現(xiàn)同類(lèi)功能的實(shí)現(xiàn)邏輯是將審批流程顯示在了彈窗里（見(jiàn)圖 2-3，顯示在彈窗里而非當(dāng)前頁(yè)面上的歷史原因是為了不破壞原有表單的界面結(jié)構(gòu)）。

現(xiàn)有實(shí)現(xiàn)的樣式

開(kāi)發(fā)急轟轟來(lái)找設(shè)計(jì)師："你這個(gè)界面實(shí)現(xiàn)不了啊"、"我們之前是這么實(shí)現(xiàn)的啊"、"要改也是主線產(chǎn)品改，但肯定來(lái)不及呀"，項(xiàng)目經(jīng)理也急轟轟來(lái)找設(shè)計(jì)師："按照現(xiàn)有技術(shù)實(shí)現(xiàn)的方式改下交互設(shè)計(jì)方案吧"、"項(xiàng)目交付時(shí)間快到了，別發(fā)散了啊"，在多重壓力下設(shè)計(jì)師就得硬著頭皮按照彈窗的樣式，把所有表單申請(qǐng)頁(yè)面全部改一遍（不改干凈，新加入項(xiàng)目的開(kāi)發(fā)人員會(huì)思考半天，然后來(lái)問(wèn)你：這里為什么跟其他頁(yè)面不一樣，是有什么考慮嗎？或是碰到"直男"開(kāi)發(fā)，真的就按錯(cuò)誤的交互界面實(shí)現(xiàn)）。

按照現(xiàn)有實(shí)現(xiàn)修正后的方案

如果對(duì)已有產(chǎn)品不熟悉，對(duì)已有的界面結(jié)構(gòu)不熟悉，類(lèi)似的情況會(huì)經(jīng)常發(fā)生，這無(wú)疑增加了時(shí)間成本和溝通成本，是項(xiàng)目大忌。所以，設(shè)計(jì)師一定要會(huì)識(shí)別界面結(jié)構(gòu)體現(xiàn)出來(lái)的技術(shù)邊界。

三、其他邊界

"國(guó)家制度、法律法規(guī)、行業(yè)標(biāo)準(zhǔn)"也是設(shè)計(jì)工作的重要邊界。

比如，理財(cái)產(chǎn)品界面一定要打上"市場(chǎng)有風(fēng)險(xiǎn)，投資需謹(jǐn)慎"的提示字樣，不可用高回報(bào)高收益宣傳口號(hào)誘導(dǎo)用戶；再比如，保險(xiǎn)產(chǎn)品宣傳時(shí)必須明示是保險(xiǎn)產(chǎn)品，且不得與銀行儲(chǔ)蓄、基金、國(guó)債等進(jìn)行收益比較。

硬件設(shè)備的操作方式也是設(shè)計(jì)工作的重要邊界，比如說(shuō)使用遙控器操作的終端界面，要特別考慮遙控器操作的局限性，不可讓用戶輸入大段文字，可通過(guò)手機(jī)掃碼填寫(xiě)的方式替代；再比如，操作觸摸屏?xí)r，不能像操作 pc 一樣出現(xiàn)右擊操作。還有，設(shè)計(jì)規(guī)范也是設(shè)計(jì)工作的重要邊界，如果不考慮設(shè)計(jì)規(guī)范一致性，會(huì)增加用戶的學(xué)習(xí)成本。

除了上面展開(kāi)討論的需求邊界和技術(shù)邊界，還有后面提到的"制度法規(guī)"、"硬件設(shè)備"、"設(shè)計(jì)規(guī)范"，還有很多因素共同決定最終的交互設(shè)計(jì)方案。設(shè)計(jì)師可以在平時(shí)的工作中培養(yǎng)自己洞察邊界的能力，以便輸出更加成熟的方案。

四、如何在各種邊界內(nèi)做出好設(shè)計(jì)

1. 須具備需求分析的能力

設(shè)計(jì)師接收到需求之后，要能判斷接收到的是不是業(yè)務(wù)需求，最好把業(yè)務(wù)需求用自己的語(yǔ)言描述出來(lái)拿給需求方確認(rèn)。（如果團(tuán)隊(duì)分工明確，一般產(chǎn)品經(jīng)理會(huì)把基于各種邊界條件分析好的業(yè)務(wù)需求和用戶需求給到設(shè)計(jì)師。如果團(tuán)隊(duì)無(wú)此角色，就得靠設(shè)計(jì)師自己識(shí)別。）就像前面提到的例子，如果業(yè)務(wù)需求是"阻止用戶重復(fù)提交碼上付申請(qǐng)"，而不是"防止用戶重復(fù)提交碼上付申請(qǐng)"，那性質(zhì)就不一樣了，阻止是不允許用戶重復(fù)提交，那就得逼著客戶和開(kāi)發(fā)調(diào)整技術(shù)邊界。但客戶實(shí)際的意圖是提醒用戶最好不要重復(fù)提交，但允許重復(fù)提交。

確認(rèn)好業(yè)務(wù)需求，如果時(shí)間充裕，可以先不考慮技術(shù)邊界，輸出一個(gè)體驗(yàn)最佳的方案，然后再根據(jù)自己已知的不可抗力約束逐漸修正方案，如果時(shí)間緊張，這一過(guò)程可以在腦海里構(gòu)思，直接輸出修正后的方案組織評(píng)審。

2. 具有洞察邊界的能力但又有打破邊界的勇氣

考慮各種約束久了，我有時(shí)候設(shè)計(jì)方案首先考慮的是開(kāi)發(fā)能不能實(shí)現(xiàn)，好不好實(shí)現(xiàn)，這真的大錯(cuò)特錯(cuò)。設(shè)計(jì)師需要有技術(shù)邊界感，但不能讓技術(shù)邊界感凌駕于體驗(yàn)設(shè)計(jì)之上，否則交互設(shè)計(jì)師就失去了存在的意義。

例如，之前提到的發(fā)票 OCR 識(shí)別功能為例，應(yīng)客戶要求，要在主線產(chǎn)品的發(fā)票夾功能基礎(chǔ)上增加發(fā)票 OCR 識(shí)別的子功能，該需求還要內(nèi)化成主線功能。其中添加發(fā)票的界面，原來(lái)的界面結(jié)構(gòu)是左圖所示，頁(yè)面的主體信息是發(fā)票照片的預(yù)覽圖像，加入發(fā)票 OCR 識(shí)別功能后，我考慮到萬(wàn)一將來(lái)有些客戶不上發(fā)票 OCR 識(shí)別功能，或者識(shí)別不出信息的情況下，還是得按 4-1 左圖展示，所以基于新舊系統(tǒng)和無(wú)數(shù)據(jù)場(chǎng)景的兼容性，我沒(méi)有改變?cè)械慕缑娼Y(jié)構(gòu)，只是在預(yù)覽圖下面增加了識(shí)別信息的展示區(qū)域，即 右圖展示。

不破壞原有界面結(jié)構(gòu)輸出方案（左圖為原有頁(yè)面）

但對(duì)用戶來(lái)說(shuō)，識(shí)別出來(lái)的發(fā)票信息才是他重點(diǎn)關(guān)注的內(nèi)容，預(yù)覽圖只是個(gè)輔助信息，按照這個(gè)心智模型，首屏的主體信息應(yīng)該是識(shí)別出來(lái)的發(fā)票信息，但上面的方案，首屏的主體信息是預(yù)覽圖。

后來(lái) UI 同事在進(jìn)行視覺(jué)設(shè)計(jì)的時(shí)候，詢問(wèn)了開(kāi)發(fā)能不能改變預(yù)覽圖的樣式，得到開(kāi)發(fā)負(fù)責(zé)人同意后，UI 同事按照信息層級(jí)關(guān)系優(yōu)化頁(yè)面（見(jiàn) 4-2 左圖），而且跟開(kāi)發(fā)溝通增加了一個(gè)擴(kuò)展功能：沒(méi)有成功識(shí)別到信息場(chǎng)景下和沒(méi)有上線發(fā)票 OCR 識(shí)別功能的場(chǎng)景下，預(yù)置幾個(gè)各種發(fā)票類(lèi)型都會(huì)有的主要信息字段，讓用戶自動(dòng)填入，見(jiàn) 4-2 右圖（原有的發(fā)票夾功能，只有一個(gè)備注字段）。當(dāng)我還在考慮開(kāi)發(fā)盡量少改動(dòng)時(shí)，UI 同事打破邊界的勇氣和靈活變通的智慧深深地給我上了一課。

擴(kuò)張邊界后輸出的方案

3. 總結(jié)

這篇文章講了交互設(shè)計(jì)應(yīng)具備的幾個(gè)邊界感，希望能幫助設(shè)計(jì)師快速輸出安全區(qū)內(nèi)方案以縮短評(píng)審修改周期，但請(qǐng)切記不可完全被邊界束縛住手腳。交互設(shè)計(jì)師仍要站在體驗(yàn)最佳的立場(chǎng)，去爭(zhēng)取擴(kuò)張技術(shù)邊界和其他邊界，給設(shè)計(jì)打造更大的安全區(qū)和發(fā)揮空間。

擴(kuò)張邊界后的安全區(qū)示意

作者：兆日 UCD