如何實現和提升軟體易用性

轉載本號文章請註明作者、出處和二維碼及全文信息，否則視為侵權。

今天給大家分享一個同事的工作感言。近兩三年做管理類、工具類軟體設計，對軟體易用性提升和UI設計有一些體會和思考。很顯然，軟體的易用性與UI設計是直接相關的。下面，我們從軟體研發過程來看一下如何提升軟體易用性。

1、上下文梳理

上下文梳理是明確研發系統與哪些外部實體存在關係。在梳理軟體的上下文的時候，一般會更加關注與軟體系統有直接功能交互關係的實體，有時會忽略軟體系統的用戶，而明確軟體的用戶，是易用性提升的起點。

因此，在上下文梳理時需要明確軟體的目標用戶。例如某個軟體的目標用戶是外部客戶和內部服務工程師，那麼在上下文分析的時候，應該明確出來，如圖

需要注意的是，在對軟體首個版本分析上下文的時候，不能只看軟體當前版本範圍的需求，而是需要看軟體所有的需求，例如當前版本做不面向外部客戶的特性，但在上下文分析的時候仍然需要明確出來，否則容易遺漏影響架構的需求。

2、需求場景分析

• 使用場景定義

從易用性分析出發，前面上下文分析明確了用戶角色，這裡要圍繞用戶角色來梳理用戶的使用場景。使用場景表明了軟體被用戶用來幹什麼。

梳理使用場景，即基於對用戶對軟體業務/功能訴求的理解，進行場景的定義。基於使用場景對軟體的各個大大小小相關的需求特性進行歸類，便於下一步的需求分析。更重要的是，使用場景是UI設計的重要依據和輸入。

• 需求特性的易用性分析

需求特性的場景分析，通常是按業務/功能特性的維度展開，圍繞系統和外部實體之間，對業務/功能特性的功能交互過程進行澄清和細化。

從易用性分析的角度出發，在對需求特性進行場景分析的時候，需要強調的地方是：關注業務/功能特性對易用性的特定要求，例如需要給用戶呈現哪些信息，呈現信息的要求，提供哪些操作功能等。

易用性分析只是對需求場景分析過程增加了一些要求，並非引入了另一個獨立的分析活動，在場景分析的活動中就一次性完成了，因此易用性分析沒必要單獨拆分出來作為一項獨立活動，否則會帶來很多重複和工作量浪費。

• 軟體易用性設計約束或要求梳理

除了特定需求特性在易用性方面的要求在場景分析中完成，軟體在易用性方面有一些公共的設計約束或要求需要梳理，包括：

• 呈現風格要求：如採用網頁的平鋪式呈現風格，或傳統的窗口式風格等。

• 呈現信息要求：確定呈現信息的風格，如左樹右表方式或者其它的風格；頁面刷新速率等。

• 使用操作要求：如採用導航式組織操作、提供功能快捷入口、操作響應延遲、操作步驟、操作集中還是分散等。

• 可擴展性要求：信息和和操作功能的組織和呈現，能夠方便軟體未來功能的擴展，例如要求支持UI可定製或可配置驅動頁面呈現等。

3、UI架構設計

UI也是需要架構設計的。目前架構設計的實踐中，更多的是關注軟體功能實現的技術方案，基本沒有涉及UI的設計。不過，從易用性的角度出發，UI也是需要架構設計的。

軟體架構設計除了給出功能視圖、部署視圖、運行視圖等，還要給出UI框架視圖。

基於前面分析給出的使用場景以及易用性設計約束和要求，UI框架視圖的內容包括：

• 確定UI的呈現模式：如採用網頁的平鋪式呈現，或傳統的窗口式等。

• 確定頁面區域布局的方案：包括操作功能布局和信息組織布局，以UI框架草圖的形式呈現。

• UI設計原則和約束。

同軟體架構設計的其它技術方案一樣，UI架構設計方案也需要反覆權衡並做出選擇。同時，UI架構設計主要是確定後續UI設計的方向，因此在這個階段不必急於深入具體的細節。

UI的架構設計最好由軟體設計師來負責，UI設計師參與討論和評審，給出專業意見。這是因為對UI進行架構設計，需要對軟體的產品概念和軟體業務功能場景有深刻的理解和認識才行。

軟體的產品概念除了包括軟體是什麼、能幹什麼，還包括軟體應該長什麼樣子。在軟體設計過程中不能破壞概念的完整性。例如打算做的是一款給專業人士用的專業軟體，需要UI體現專業性，讓用戶容易對軟體功能產生信賴感。如果在UI設計時過於花哨或娛樂化，無法體現專業性，這樣就破壞了軟體產品概念的完整性，導致軟體設計失敗。

另外，UI是表象，軟體業務功能是內涵，UI服務於軟體的業務功能場景。

對軟體的產品概念理解最準確的應該是軟體設計師，對軟體的業務功能場景理解最準確的也是軟體設計師，因此，UI的架構設計最好由軟體設計師來負責。

由於UI設計師在其專業方面經驗更加豐富，對業界趨勢和友商情況更加了解，UI設計師參與設計討論和評審，給出專業意見，有助於彌補軟體設計師在UI設計專業領域方面存在的短板。

現實情況下存在這樣的做法：由UI設計師負責UI的設計。由於UI設計師並不熟悉軟體業務，就需要軟體設計師在旁邊「指導」。由於存在學習和溝通的成本，自然效率不可能高的。更可能發生的情況是：軟體設計師可能忙著其它設計工作而疏於「指導」，UI設計師不得不自己摸著石頭過河，這樣就很容易發生設計方向偏差，從而導致更大的返工。

4、UI低保真/高保真設計

UI的架構設計完成後，UI設計師就可以在UI框架視圖的基礎上，開展低保真以及高保真的設計活動。

一般通過低保真設計，就能展示出軟體會做成什麼樣子，高保真一般是在低保真方案定稿后才進行，在此之前低保真設計反覆討論評審、迭代優化。現實情況下，這個設計階段容易出現的問題是：容易議而不決。導致議而不決的原因，大致有如下幾方面：

• 參與評審的意見會很多，特別是如果做的是一款各方關注的軟體，那方方面面的意見最好都要徵集到。

• UI的評審意見很容易提：不需要很懂技術，每個人都能根據自己的審美和體驗提出意見，有些能給出與現有設計完全不同的建議。審美相關的意見無所謂對錯，也導致了很難做取捨（想以理服人很難做到）。

• 意見聲音的「大」和「小」，也或多或少會影響到設計方案的裁決。

從軟體研發的進展來看，議而不決的狀態是不能接受的，無論如何UI設計都要在適當的時刻進行基線化，這樣軟體的研發過程才能繼續按計劃推進。因此，對軟體設計師和UI設計師來說，既要充分考慮各方意見，又要把握UI架構設計確定的原則和方向不丟失、不偏離，同時仔細鑒別真正代表用戶、符合使用場景的意見。

如果實在不能和所有人達成一致，那就需要設計師果斷裁決，設計必須最終由設計師說了算。

5、軟體試用

UI低保真/高保真設計完成後，就進入軟體開發實現階段。在軟體交付前儘早組織進行軟體試用，是保證軟體易用性的一個有效手段。

前面UI設計的評審討論，基本上還是「紙上談兵」。軟體真正用起來，好不好用立刻就有感覺了，用戶可以體驗到軟體的真實操作響應、頁面刷新速度、信息呈現的效果等，這些是無法通過低保真/高保真體驗到的。這樣軟體在交付前可以有針對性進行優化。

因此，儘早組織軟體試用是一個確保軟體交付時的易用性質量的有效性手段。總之，提升軟體的易用性的有效途徑包括：

• 需求階段明確軟體的用戶、使用場景和易用性的設計約束和要求。

• 開展或加強UI的架構設計活動，給出UI框架視圖。

• 在UI的低保真/高保真設計階段，把握UI架構設計確定的原則和方向不丟失、不偏離，同時仔細鑒別真正代表用戶、符合使用場景的意見，果斷決策避免議而不決。

• 軟體開發完成後儘早組織軟體試用，在交付前可以有針對性進行優化，確保軟體交付時的易用性質量。