方格精選

軟體開發見聞錄#6:使用者體驗設計的原則/葉光釗

閱讀時間約 7 分鐘

「體驗設計」這門學問,現在已經成了軟體設計的顯學,其中包含了不同的面向:流程設計、技術架構設計、使用者介面設計等等。在大家還沒有開始重視使用體驗的時代,許多事情只能從嘗試和錯誤中去學習,包括開發團隊也一樣。

針對跟使用者相關的設計觀念,在微軟的發展進程中,可不是一步就走到目前的成績的;曾經有一段很長的時間,還受到了很多批評。
就我自己經驗的瞭解,倒不是微軟以前不重視、或是不投資源,而是早期設計的著重點太過偏向「介面和展示」(user interface and representation)等等看得到的東西,而並沒有注意到背後其實有更深一層的原則。
從「介面」轉變成「體驗設計」觀念的轉捩點,是PM大神:Steven Sinofsky接手Windows 7的開發時,決定做一些根本的改變:他成立了獨立的使用者體驗與設計部門(這以往多半是PM兼任的工作),並且在開發流程中把必要的程序也加進去。
這個策略後來的影響很大:現在所有的產品組都跟進了這種開發模式,不像早期只有遊戲、或是硬體部門才有少數的設計資源。
在這些改變當中,最最重要的,是確立了一個基礎:開發啟動之前,團隊必須先訂定使用者體驗設計原則(Design Principles)。它的作用跟之前所提到的「端到端用戶體驗」很像,是用來協調跨領域設計上的協作。
Windows 7: Design Principles for Windows 7
Together, we can increase customer enthusiasm, satisfaction and loyalty by designing user experiences that are both…channel9.msdn.coma
Windows 7是第一個把這些原則白紙黑字寫下來的產品(微軟還保留了在PDC上的發表,請參閱前面連結中的影片);這裡就容我自作主張,做一些介紹跟解釋:
  • Reduce concepts to increase confidence(少講概念,增加信心)
    盡量集中功能的進入點,增加使用者對功能的掌握程度。
  • Small things matter, good and bad(無論好壞,細節都很重要):
    細節的設計不能馬虎,因為這會影響整體的成敗。
  • Solve distractions, not discoverability(減少用戶分心,而非吸引用戶注意):
    重點是讓使用者一眼就知道如何使用功能,而非一昧增加功能的曝光度。
  • Time matters: build for people on the go(時間也很重要,要設計得讓忙的人也好用):
    如果確知使用者會在移動的環境中使用某個功能,盡可能減少操作的步驟及時間就是重點。
  • Value the full lifecycle of the experience(重視從頭到尾的整體體驗):
    不要只看片面的操作方便,要把整體經驗包含從「安裝」到「解除安裝」一起考慮進來。
  • Be great at look and do(看起來和用起來都好):
    軟題的視覺畫面必須和操作盡可能一致、而且要直覺。
由於篇幅的關係,可惜沒辦法舉實際的例子做仔細地說明,希望之後有機會能持續介紹和說明;另外,蠻建議大家花點時間看看前面提到的PDC影片,很精彩。
當然,微軟並不是從此在設計上就一帆風順,之後還是一路崎嶇坎坷(Windows 8 就又跌了一跤)。
但無論如何,沒有這個重要的基礎,就沒辦法持續累積能量和成果,進一步超越對手。筆者雖然已經離開,但看到前一陣子微軟交出的成績單,感覺還是蠻驕傲的。

使用者體驗設計實例:輸入法

最近有朋友反映,後來的幾篇理論講述偏多,有點偏離見聞錄的精神。想想是有道理,這裡就來用一個例子,來說明之前談的使用者體驗設計,是幾乎每個人都用到的輸入法。
先自首:講到輸入法,估計每個人都有一肚子怨氣。不過老實說,也許是自私的觀點,我並不覺得微軟的開發不夠用心、或是資源不夠,而是它有兩個超級門檻:
  1. 只要它的準確度做不到100%,就是0%;
  2. 使用者操作的習慣性超級高,只要稍微有一點點更動調整,不但馬上被發現,而且通常都會有負面反應。
第二點尤其麻煩,這表示要在輸入法的操作做上大刀闊斧的改變,等同於是不可能的任務。
這裡並不打算將所有輸入法的血淚史全寫出來,這樣可能二十篇都寫不夠,而且會牽涉到微軟的研發機密;所以,我打算講一個還算成功的體驗設計變動。
早期的輸入法,為了順應多數人看ㄅㄆㄇ符號的習慣,在組字的時候,ㄅㄆㄇ符號是垂直顯示在另一個長方形的小框框裡,並且會隨著游標變換位置。
這種模式我們內部稱為「near caret」模式。當初這樣設計有兩個目的:
  1. 比較接近看ㄅㄆㄇ的習慣;
  2. 在組字的時候,已經輸入的文字位置不會動來動去。
可是相對在工程上的缺點是,如果應用程式所傳的座標有問題,這個小方框就會亂跳。這個問題困擾了產品組很久,因為沒有一勞永逸的方案;只要有新產品,這裡的寫碼跟測試功夫都要重來一次。
另外,就算我們把所有微軟的產品都搞定了,永遠會有不按規則來的第三方app會出問題;而對終端用戶來說,這肯定是微軟輸入法的問題。
所以內部一直都在討論要改成「at caret」模式,就是把ㄅㄆㄇ符號顯示在游標當中。這樣的話,不但沒有方框亂跳的問題,而且由於處理方式就跟其他亞洲語言如日語、韓語、簡體中文輸入一樣,測試功夫可以大幅減少跟簡化。
但就是改變太大了,尤其是上面提的第二個目的:一方面擔心使用者會分不清組字中、以及組字完成的文字,而且在極端的情況中,會讓長篇文字來來去去做劇烈的位置變化,所以遲遲沒有下這決定。
最後,欠的債還是要還、該改的還是要改;所以我們在一次輸入法重要改版的時候下了這個決定,當時我們等於把大部分資源都賭在這個改動上。程式碼的改動其實並不多,主要都是設計更動的準備和驗證功夫;綜合來說,大概是以下的步驟:
  • 第一步:先做一個原型。
  • 第二步:由設計工程師與體驗工程師驗證是否符合大部分的設計原則。其實中間有不少工程師之間反覆討論「哪個設計比較好」的互動。
  • 第三步:進行適用度測試(usability study and testing),招募十幾位終端用戶實際使用,由體驗工程師驗證使用者的反應是否符合我們的預期。
  • 第四步:檢驗目前手中有的遙測資料是否也符合新的使用模型。
當時由於台灣沒有體驗工程師,為此還特別從日本請來一位專家。在一連串討論之後,產品組發覺焦點在於「使用者輸入的文字長度」;經過一連串實地測試,觀察到大部分使用者以花在網頁上的時間居多、輸入的也都是短片語。
最後,我們整理了所能搜集到的段落長度,發現約略都在在150–200個中文字之間,所以視覺反應並沒有想像中的劇烈。最後產品組成員一致決定改動就緒,新設計就這樣定稿出門了。
現在,應該多數使用者都已經適應、並且持續使用新的設計。對產品組而言,最好的消息就是「沒有消息」;經過這一次,我們才真正學到好的設計的精髓、以及應該付出的代價。
為什麼會看到廣告
1.4K會員
2.0K內容數
為您送上頂尖作者的最新管理與科技產業思維。
留言0
查看全部
發表第一個留言支持創作者!
手上有了來自創投的現金之後,我們興沖沖開始製造和銷售第二代產品「BeBox」電腦;然而,我們很快就發現了一堆更麻煩的硬體問題,以及後面的「歷史故事」。
在敏捷體系中,Scrum Master(SM)的存在是為了讓開發團隊把事情完成得更好;所以不是SM要求團隊完成事情,是團隊要求SM幫助他們進步。如果Scrum Master沒有要求團隊做什麼的權力,那事情該如何才能完成呢?
員工離職率高、甚至二代不願接班,有時候並不是因為表面上的理由,而是因三種無法克服的累:生理的、心理的、以及情緒上的。如果企業主無法看穿自己公司的問題、創造出「令人不累」的環境,就可能成為自己最大的敵人。
這次,讓我們來看看最重要的網路服務績效指標:ARPU(Average Revenue Per User),也就是每一位用戶對利潤的平均貢獻度。在前幾大網路公司之中,究竟誰能在這個運動項目中拔得頭籌?這樣的結果又隱藏著什麼意義?
在你入行的前五年,應該盡可能爭取所有能累積你定位的基礎,跟展現專業實力的機會。你的定位是什麼呢?你要如何跟別人介紹你的專長?老闆應該要在什麼地方重用你呢?
許多企業家在創業之初都有理想和目標,但面臨競爭時免不了會取巧;久而久之,就形成了短視和扭曲的目標。企業家必須能夠拒絕誘惑,避免各種方便和取巧的手段。因此,一部如同國家憲法一般的企業基本法,對於剛進入高速成長期的公司尤其重要。
手上有了來自創投的現金之後,我們興沖沖開始製造和銷售第二代產品「BeBox」電腦;然而,我們很快就發現了一堆更麻煩的硬體問題,以及後面的「歷史故事」。
在敏捷體系中,Scrum Master(SM)的存在是為了讓開發團隊把事情完成得更好;所以不是SM要求團隊完成事情,是團隊要求SM幫助他們進步。如果Scrum Master沒有要求團隊做什麼的權力,那事情該如何才能完成呢?
員工離職率高、甚至二代不願接班,有時候並不是因為表面上的理由,而是因三種無法克服的累:生理的、心理的、以及情緒上的。如果企業主無法看穿自己公司的問題、創造出「令人不累」的環境,就可能成為自己最大的敵人。
這次,讓我們來看看最重要的網路服務績效指標:ARPU(Average Revenue Per User),也就是每一位用戶對利潤的平均貢獻度。在前幾大網路公司之中,究竟誰能在這個運動項目中拔得頭籌?這樣的結果又隱藏著什麼意義?
在你入行的前五年,應該盡可能爭取所有能累積你定位的基礎,跟展現專業實力的機會。你的定位是什麼呢?你要如何跟別人介紹你的專長?老闆應該要在什麼地方重用你呢?
許多企業家在創業之初都有理想和目標,但面臨競爭時免不了會取巧;久而久之,就形成了短視和扭曲的目標。企業家必須能夠拒絕誘惑,避免各種方便和取巧的手段。因此,一部如同國家憲法一般的企業基本法,對於剛進入高速成長期的公司尤其重要。
你可能也想看
Google News 追蹤
Thumbnail
接下來第二部分我們持續討論美國總統大選如何佈局, 以及選前一週到年底的操作策略建議 分析兩位候選人政策利多/ 利空的板塊和股票
Thumbnail
🤔為什麼團長的能力是死亡筆記本? 🤔為什麼像是死亡筆記本呢? 🤨作者巧思-讓妮翁死亡合理的幾個伏筆
Thumbnail
軟體開發專案管理的失敗原因複雜多樣,但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步,需對軟體開發專案的特徵進行評估,選擇合適的軟體開發生命週期和專案管理方法。
Thumbnail
R036 Blog API 伺服器的維護更新日誌 (2024/04/30) 開發環境技術 語言: Javascript 環境: Node JS 框架: Express.js 本次維護目的 優化及測試API伺服器程運行 重溫程式碼架構以便日後更新優化 Reac
Thumbnail
軟體開發時應該要有固定的命名規則,以提高程式的可讀性,本篇文章帶你認識常見的幾個命名方法。
Thumbnail
OpenAI 正在開发兩種類型的 AI 助手,這些軟體將協助完成原本由人類執行的任務,而無須人類密切監督。其中一種類型的 AI 代理人可以透過接管使用者的設備來自動化某些複雜任務,例如 ChatGPT 助理將數據從文檔轉移到電子表格或填寫費用報告並將它們輸入到會計軟體中。此類 AI 助理將需要使用者
那麼,Scrum 究竟是什麼?它是如何運作的,又是如何能夠幫助我們更有效地開發產品?接下來,我們將為你全面解釋 Scrum 運作流程,通過詳細 Scrum 入門教學,帶你一起掌握 Scrum 敏捷開發方法!
Thumbnail
IBM在今年三月公佈了40位候選人獲選為「全球傑出AI女性領袖」,表揚她們運用IBM AI技術推動產業轉型的傑出成就,其中一名是來自台灣的女性軟體工程師:蔡德怡。現在是軟體工程師,但以前的蔡德怡走過不一樣的路:大學學財金、至澳洲打工渡假、在教育產業工作,她曾走過的路,是如何形塑成現在的她呢?
Thumbnail
一旦甲乙方進到零和賽局,情感上開始對抗之後,兩敗俱傷就是必然的結局了。既然是這樣,合約的撰寫及執行不妨看作是合作誠意的具象表態。
Thumbnail
「幫我做的跟 Facebook 一樣單純就好」 「嗯 … ?」 不管怎麼估計都可能失準,在一件事做完之前你怎麼知道能不能做到?
Thumbnail
團隊最近因為有大型功能要發佈,因此剛完成了一次捕蟲大會(Bug Bash),趁著記憶猶新,來寫一下在舉辦過程中可以注意的一些重點。除了自己紀錄,也希望對看到文章的你有點幫助。
Thumbnail
去年下半年開始了幾個工廠設備的監控專案顧問開發。 有別於以往比較多接觸的消費者端應用,情境確實比較不一樣。系統開發很重要的一個點是因時制宜、因地制宜,這次就算是一個很好的案例。 本篇文章紀錄一下值得分享的心得。
Thumbnail
接下來第二部分我們持續討論美國總統大選如何佈局, 以及選前一週到年底的操作策略建議 分析兩位候選人政策利多/ 利空的板塊和股票
Thumbnail
🤔為什麼團長的能力是死亡筆記本? 🤔為什麼像是死亡筆記本呢? 🤨作者巧思-讓妮翁死亡合理的幾個伏筆
Thumbnail
軟體開發專案管理的失敗原因複雜多樣,但管理不善是其中一大原因。學習為軟體開發專案而設的管理方法是有效管理的第一步,需對軟體開發專案的特徵進行評估,選擇合適的軟體開發生命週期和專案管理方法。
Thumbnail
R036 Blog API 伺服器的維護更新日誌 (2024/04/30) 開發環境技術 語言: Javascript 環境: Node JS 框架: Express.js 本次維護目的 優化及測試API伺服器程運行 重溫程式碼架構以便日後更新優化 Reac
Thumbnail
軟體開發時應該要有固定的命名規則,以提高程式的可讀性,本篇文章帶你認識常見的幾個命名方法。
Thumbnail
OpenAI 正在開发兩種類型的 AI 助手,這些軟體將協助完成原本由人類執行的任務,而無須人類密切監督。其中一種類型的 AI 代理人可以透過接管使用者的設備來自動化某些複雜任務,例如 ChatGPT 助理將數據從文檔轉移到電子表格或填寫費用報告並將它們輸入到會計軟體中。此類 AI 助理將需要使用者
那麼,Scrum 究竟是什麼?它是如何運作的,又是如何能夠幫助我們更有效地開發產品?接下來,我們將為你全面解釋 Scrum 運作流程,通過詳細 Scrum 入門教學,帶你一起掌握 Scrum 敏捷開發方法!
Thumbnail
IBM在今年三月公佈了40位候選人獲選為「全球傑出AI女性領袖」,表揚她們運用IBM AI技術推動產業轉型的傑出成就,其中一名是來自台灣的女性軟體工程師:蔡德怡。現在是軟體工程師,但以前的蔡德怡走過不一樣的路:大學學財金、至澳洲打工渡假、在教育產業工作,她曾走過的路,是如何形塑成現在的她呢?
Thumbnail
一旦甲乙方進到零和賽局,情感上開始對抗之後,兩敗俱傷就是必然的結局了。既然是這樣,合約的撰寫及執行不妨看作是合作誠意的具象表態。
Thumbnail
「幫我做的跟 Facebook 一樣單純就好」 「嗯 … ?」 不管怎麼估計都可能失準,在一件事做完之前你怎麼知道能不能做到?
Thumbnail
團隊最近因為有大型功能要發佈,因此剛完成了一次捕蟲大會(Bug Bash),趁著記憶猶新,來寫一下在舉辦過程中可以注意的一些重點。除了自己紀錄,也希望對看到文章的你有點幫助。
Thumbnail
去年下半年開始了幾個工廠設備的監控專案顧問開發。 有別於以往比較多接觸的消費者端應用,情境確實比較不一樣。系統開發很重要的一個點是因時制宜、因地制宜,這次就算是一個很好的案例。 本篇文章紀錄一下值得分享的心得。