精選內容

從設計端建立設計系統 – part 1

設計系統（design system），我想許多從業的設計師多少都有聽過，或是也曾試著在自家產品導入設計系統，但大多設計師所想像的設計系統，大概僅是在軟體（figma）裡設計好組件（component），讓其他設計師也可以共享這份已經做好的組件，嚴格來說這樣的做法僅是在設計端建立一個共享的資源庫（library），不能稱的上是設計系統。

但要如何建立一套完整的設計系統，每個公司產品的方式都不太一樣，這系列的文章，我會分享我個人在產品導入設計系統的經驗與思路，這套思路，也是我自己近年來對設計系統的理解與經驗累積。放眼望去，我也很少看到真的有設計師去實作整套設計系統，或許受限於產業類型或是產品規模，大多文章的描述還是停留在對原子設計（Atom Design）的認知階段，離真實的設計系統實作仍有一段距離。

而就我個人經驗，設計一套系統並沒有什麼固定的套路，其實以台灣公司的產品規模也未必要導入設計系統，但要建構一套設計系統也是不行，我是根據自己在產品開發經驗的累積，並針對自家產品開發的需求，一步一步完成這套系統邏輯，在每一次執行的專案中，慢慢的偷渡設計系統的概念到產品專案中，在工程師意識到的時候，系統大概也就導入一半了，要讓公司投入資源開發設計系統，在台灣一直都是一件困難的事，但一點一點滲透、嘗試，終究還是可以建立一套屬於自家產品的設計系統。

從「設計端」的角度切入設計系統

這篇文章的標題，強調是從「設計端」來建立設計系統，為什麼要強調設計端？因為大部份的設計系統，無法跟開發端分離，所以不會單純由設計師建立，這邊我指的設計系統，是像 Microsoft 或是 Google 等級的公司的設計系統，設計師扮演提供設計與概念的角色，但要導入開發，還是需要開發人員的協助與配合（亦或是，設計師本身具有開發的能力），所以一般來說，設計系統是設計師與工程師的共同產出物。

但在台灣以代工產業為主的工作氛圍下，很少會有公司願意投入開發資源在設計系統的建立上，因此設計師在設計系統上所能產出內容是有限的，大部份的設計師因為沒有程式經驗，所以設計系統的導入，只停留在與設計師共享組件與樣式的階段，但想設計一套在開發端可執行的系統，仍然是有可能的，本系列文，會以設計師的角度出發，在產品開發端與設計端之間，找出一套讓設計系統可以執行的方式，就算工程端不導入設計系統，設計端仍可以運用這套系統來維持設計的一致性。

只要有心，設計師終究會找到自己的出路。

為什麼要建立設計系統

通常我在思考為什麼要建立設計系統時，都會從目前所「遇到的問題」及「期望看到的結果」來思考如何建立設計系統，一般在產品開發中常見的問題：

  • 「樣式不統一」 → 「在不同裝置、平台上的設計樣式要儘量達成一致」
  • 「設計資源樣式套用混亂，一堆重覆的色號與資源（Asset）圖片」→「所有產品的的樣式、圖片、圖標資源最好應該都由設計師來管理，而且最好可以達到隨意的切換產品樣式與主題」
  • 「組件規格混亂、重複設計組件」→「需要有一份可維護、可擴充的組件文件撰寫規範」

當然上述的問題，未必要透過建立設計系統來解決，只要養成良好的文件管理習慣也可以處理，但在想導入設計系統的需求下，根據問題與期待的結果，建立設計系統會有四個主要我想達成的明確目標：

  1. 建立統一且可管理的樣式規範
  2. 建立一個由設計師管理樣式與資源的方法
  3. 建立設計文件的撰寫規範
  4. 撰寫組件設計規範（component design guideline），並基於此讓工程師持續迭代的組件

設計系統的產出物

為了達成設計系統的目標，設計端應該要有一個很明確的產出成果供工程師使用，我們先不期待做出像 Google Material Design 或是 Apple Human Interface Guidelines 或是 Ant Design 這樣完整的設計規範，因為產品的量級與開發資源差太多了，我們能做的，是建立起一個在100人左右的開發團隊下，仍可穩定執行的設計系統。

而在這個條件下，設計師的產出物主要有兩項：

  1. Design Token
  2. Design Guideline

我想大多數對於設計系統有一些了解的設計師對於這兩個名詞都不會感到陌生，但怎麼建立、怎麼維護、怎麼管理，這才是建立設計系統所需知道的 know how，而 Design Guideline 的撰寫，我之前的文章已經提供了撰寫的規範（介面設計規範（UI Design Guideline）的撰寫方式），後面的文章，我會著重介紹如何建立 Design Token，並將它套用在不同產品與專案上；既然是系統，那也代表只要了解這套方法，想不同產品上要使用它，應該都不是難事。

先完整，再推進

我在自家產品嘗試導入設計系統的心態是，就算工程師不導入，設計師端依然可以根據這兩個產出的文件，來維持設計的一致性，當然有時候也未必是工程師不想導入，也有可能是設計師對於系統的理解不足，沒有足夠的經驗與能力完成 Design Token，對工程師來說，當然也不會冒然的去增加產品開發的風險，畢竟這些都是「額外」的需求，都是在產品需求之外的事。

因此個人建議，這些文件的產出未必要讓工程師馬上去實現，先讓這件事看起來很完整，每個專案的過程，一點一點去推動、滲透。當樣式有被定義、組件有被重覆使用，工程師也會意識到，原來設計端早有一套固定的設計規範，設計系統的雛型也就會在這個過程中，不知不覺的被實現。

總結

Design Token 與 Design Guideline 是設計師與工程師溝通的橋樑，也是整套設計系統的基石，有了這套系統，在團隊成員擴編時，才能漸漸的導入設計營運（Design Ops）。

文末想感謝自己團隊的小伙伴們，雖然我們團隊很小，在撰寫文件或是做 Design Review 時，也是被我各種吹毛求疵與刁難，但這樣的訓練是有代價的，至少迎來產品導入設計系統的第一道曙光。

廣告

掰掰，UI Club 社團

To UI Cluber ：
大家好，我是Rei,

首先要感謝大家加入這個社團，UI Club 2015 成立至今也有 7 年了，這些年產業的變化很大，記得我剛入門介面設計時，一個人摸索著這個新的領域，使用的軟體是 illustrator、photoshop，當時光是標識文件、切圖、交付這件事情就費盡苦心，也寫了不少文章來分享個人經驗，如今時光飛逝，技術日新月異，我們有了更多更方便的軟體可以使用，介面設計這個領域，對於一般人來說，也逐漸不是那麼遙不可及，我很開心在這個過程中我能參與其中。

而 UI Club 早期是由 Daily UI 這個活動開始，當時只是一鼓熱情，招集一些設計師參與這個活動，的確也有許多人因此成了介面設計師，想起那段瘋狂的時光也是一種浪漫，如今大家有很多的選擇，不是管是任何線上課程或是免費教學文章都可以幫助你更了解這個職業所需的技能。

最近我理解到，設計這件事情，指的應該不是你會什麼軟體操作，或是什麼複雜的系統建立流程，或是多花俏的視覺特效，因為這個世界正在飛速的改變，現在所學所用，很快的就會被更新的技術或方法給取代掉，永遠沒有停止的一天，我也經過了許多次這樣的技術迭代歷程。所以，換個方式思考，如果新的技術不斷的出來，你得不斷的學習，最終你只會讓自己精疲力盡，所以是時候反思了，思考一下，什麼才是你職涯發展或是生命中，真正重要的事情，如果你熱愛設計，那你的價值不是取決於你會多少軟體，而是設計這件事參與你的生命的深度能夠有多深。

這幾個月的反思，我理解到，工作也只是一種參與生命的形式，如果想在工作中取得成就，只要你全力投入所做的事情，直到自己滿意，其實也就夠了；也許你跟我一樣，誤把他人對自己工作肯定視為是自己的工作成就，但我後來發現，其實這是一個不健康的心理狀態，當你會這樣想，代表你生命的價值，永遠掌握在他人手上，難道別人沒肯定你，你就毫無價值嗎？如果這樣想，那你工作又怎麼會開心，不開心又怎麼會有好的工作表現，如此的惡性循環，只會把你打入更悲慘的生活裡。

或許有人會問，工作不就是為了讓客戶、老闆認同（滿意）嗎？如果你全心的投入你所愛的事情，你還會擔心找不到認同你的老闆或客戶嗎？世界很大，不是只有 BAT 或是 FAANG ，還有很多企業也需要設計師，不需要盲目的去跟隨，如果心態不正確，就算你在大家稱羨的企業上班，你還是會過的很不開心。

這個是我這幾個月反思後的心得，跟大家分享，同時跟大家宣布，UI Club 社團解散，原因是因為同質性的社團很多，而且我也沒時間再經營社群， 我經營的網站（https://uiclub.tw/） 還會在，因為那是我個人的心得分享。大家依舊可以在其他同性質的社團去取得業界相關的訊息，我個人會去實現我的人生另一個目標，我想設計不該只限於手機介面，而是應該把設計融入我們的生活及社會文化，盡可能去探索設計在生命中的所有可能性。

感謝大家這幾年的陪伴，也感謝那些曾經有過的緣份，在這個社團人才輩出，我希望大家都可以當一個健康又快樂的設計師。

2022/2/13 Rei

UI小知識 — State與Status有什麼不同？

不知道大家在做圖時，有沒有遇到命名的問題，到底說明組件的狀態要用 state 還是 status？這兩個名詞的翻譯都是「狀態」，但使用上好像有點不太一樣，很有趣的是，這個問題不是只有介面設計師會有，工程師也會有相同問題，應該說只要母語不是英文的人，都很容易混淆，所當你上網 google「state vs status」時，不同領域的人，就會給你不同的解釋與答案，而這篇文章就是要用介面設計的角度，來討論 state 跟 status 的差異。

名詞定義

首先我們先看一下這兩個名詞在作為「狀態」使用時的定義：

State | 狀態
【名詞】【可數】
（英）| The mental, emotional or physical condition that a person or thing is in
（中）| 人或物的心理、生理或是物理條件狀態
來源 | https://www.oxfordlearnersdictionaries.com/definition/english/state_1?q=state

Status | 狀態
【名詞】【不可數】
（英）| The situation at a particular time during a process
（中）| 一個流程裡特定時間的情況
來源 | https://www.oxfordlearnersdictionaries.com/definition/english/status?q=status

從字典的解釋中我們可以知道 state 與 status 在英文的解釋與詞性其實是不一樣的，state 強調的是不同條件下的狀態，是可數名詞，所以一個人或物的狀態可以被分為幾種明確的狀態，例如水有不同的狀態：液態、固態、汽態，這時候就會使用 state；而 status 通常會使用在某個時間點狀態下的結果，所以不同的時間點，可能會對應出不同或是相同的結果，是不可數名詞，例如 Marital Status（婚姻狀態）， 這時指的就是某個時間點下婚姻的狀態。

從字義上似乎可以這樣理解，state 比較像是一個條件狀態的集合包，一個人或物體或許在某些條件下，會有不同的狀態，但狀態沒有顯現出來不代表不存在，而是只能在特定的條件來進行切換，而 status 比較像是一個流程中特定時間下的結果，就算有不同的狀態，但這些狀態不能同時存在，而且在狀態之間可能會有相依關係，例如前面的婚姻狀態，可能是單身、已婚、離婚、喪偶，一個時間點下只會存在一種狀態，不會同時單身又已婚。

工程師的 State 與 Status

工程師也常常在變數命名時到相同的問題，像是在 StackExchange 裡關於這個問題就有很多答案，而我覺得最為好的答案是這個：

  • state is used to describe a stage in a process (e.g. pending/dispatched).
  • status is used to describe an outcome of an operation (e.g. success/fail).

在工程裡面，state 比較強調的是一個 process（程序） 裡面的 stage（階段），而 status 比較強調的是 outcome（結果），其實跟前面的定義有點像，但這邊的 state 的 process 會比較像是一個事件集合所包含的不同階段，這些階段是同時存在的，只是發生的條件不同，而 outcome 的結果就只有 success/fail，狀態不會並存。

而在web端常見的 HTTP狀態碼（HTTP response status codes），就有五種常見的狀態（status）碼：

  1. 資訊回應 (Informational responses, 100–199),
  2. 成功回應 (Successful responses, 200–299),
  3. 重定向 (Redirects, 300–399),
  4. 用戶端錯誤 (Client errors, 400–499),
  5. 伺服器端錯誤 (Server errors, 500–599).

英文使用的就是 status ，不是用 state，因為這些狀態是結果，每一次的訪問，只會有一個結果，不會同時存在。但有沒有可能是用 state ？前面HTTP 回應的結果是從客戶端（client-side）所回應的結果，但如果是從服務端（server-side）來看， HTTP 的回應狀態，的確可以視為一個 process 裡不同的 stage ，這時如果使用的是 state 似乎也很合理。

介面設計師的 State 與 Status

介面設計師在做組件（compoenent）的設計時，九成以上是使用 state，因為我們關注的是組件有那些條件狀態，而每個條件下對於組件就會給予不同的樣式（style），例如：按鈕狀態（button states）：

不同的button state

這些狀態的集合，就會是一顆按鈕，而在不同的控制情境下，出現的按鈕的狀態就會不同，相同特性還有表單（form）的輸入框（input），也會有不同的 state，那介面設計師什麼時候會用到 status ？通常會用在描述畫面的狀態時，像是結果頁（result pages）所對應到的資料的回應狀態，我們就有可能會使用到 status，例如：交易成功頁（success page）、交易失敗頁（failure page）、錯誤狀況頁（error page）…等等，但我們統稱這些畫面是 response status pages / result pages ，跟前面的 HTTP response status codes 有點類似，但其實這是從產品流程的角度來描述頁面，但從介面設計師的角度這些狀態的頁面，也能說是頁面的不同state。

UI Stack 裡的 State

另外，介面設計師可能也有聽過 UI Stack，是由產品設計師 Scott Hurff 在他的文章《How to fix a bad user interface》提出來的概念，主要的內是說明如何透過 UI Stack 來修正 UI 體驗，這邊先不細談他的概念，但他提出來的 UI Stack 裡，每個 UI （a page/screen）畫面應該要包含 5 種 states ，這邊使用到的詞就是 states 而不是 status，所以我們可以知道，這邊他想強調的是一個畫面所該包含的所有狀態結構，所以即使是結果頁，也應該要有這五種狀態 ，這篇文章明確的定義出 UI 應該要有的五種狀態，就好像水被定義有三種確定的狀態一樣。（這篇是介面設計師必讀的文章）

UI Stack

結論

寫這篇文章，主要也是因為我在做設計時， 對於這些名詞的選用也會感到困擾，後來發現其實許多人也有遇到相同的問題，畢竟我們的母語不是英文，這麼細微的差異其實不容易發現，像是之前寫需求與動機的文章，文中也有提到，需求所對應到的英文單字是「needs」、「demand」、「requirement」，雖然中文都翻為需求，但在英文的意義上是截然不同的解釋，但多數的人可能都選擇混用，所以導致概念上有點混亂，這篇文章也是想透過一些例子說明，來讓大家稍微了解 state 與 status 的差異。

用戶行為模式（3） — 需求與動機的關係

從上篇的討論我們可以知道動機 ≠ 需求，因為動機有分內、外在動機，這也驗證了一開始前面的那句話：「需求可能形成動機，但動機不一定就是需求」。所以，我們先給一個簡單的結論：「需求不是外在動機。」，看起來應該沒什麼問題（就目前看來），但有幾個問題我們可以繼續探討：需求就是內在動機嗎？外在動機會影響需求嗎？外在動機會變成內在動機嗎？

需求就是內在動機？

這個命題的前題是，行為必須已經發生，不然就不存在任何動機（內、外），但沒有內在動機不代表沒有需求，那要怎麼思考這件事？

回到殺人的例子，有殺人的需求（慾望）代表有內在的殺人動機嗎？通常我們不會這樣推論，動機的存在必須建立在確定的行為之後，或者殺人者在犯案前就先自白，他有殺人需求，但如果沒有實際付出行動，但那也代表殺人動機不存在，這樣的情況通常就會送去心理治療，而不是直接送去法院審判。

那假設殺人的事實存在，那殺人的內在動機就會是需求嗎，或許可以這樣假設，但排除掉外在動機，剩下的動機就一定是內在動機嗎？似乎不是那簡單的事，但如果是，仍然要證明殺人的需求強大到足以產生殺人動機，在電影裡通常會從犯案的行為中觀察，如果殺人的行為是可觀察到重覆性或是固定的犯案模式或儀式，排除了外在動機，那需求 = 內在動機 或許就會成立。

想知道用戶需求是否存在的最快方式，就是讓用戶自白。

UI Club

回產品開發，用戶有需求，就代表有使用你的產品的內在動機嗎？或者是，用戶使用了你的產品，就有使用產品的內在動機嗎？我想這些問題，都很值思考，但真正的答案只有用戶知道，所以探索用戶需求，最快的方式就是想辦法讓用戶自白，至少比讓殺人犯自白容易多了。

外在的動機是否會影響需求？

這個問題要先思考，如果你生病了去看醫生，醫生開藥給你，如果你被治好了，是藥物治好了你？還是醫生治好了你？這問題就像這個看醫生的例子一樣，不好回答。

科學的探討通常都是直接的關係，間接關係可能要再用更嚴謹的方式驗證。例如，你看了很多醫生，只有這個醫生的藥能夠治好你，那或許就能說是這位醫生治好了你，不單純只是藥物的關係。但再思考一下外在動機的定義：「外在動機與會內在動機相牴觸」，也就是一個行為，內外動機之間應該會互相影響，似乎內外在動機會有抵換（trade-off）關係，再重新思考我們的命題：「外在動機是否會影響內在動機進而影響需求？」，回到殺人的例子，有沒有可能殺人同時存在內在動機與外在動機？理論上是有可能的，給個情境，在不考慮法律刑責的情況下，如果有人給你巨額報酬（外在動機），你是否有可能殺人？在一般的道德規範下，或許不會答應，但如果要殺的對象與你有不共戴天之仇（內在動機）呢？或許有人就開始動搖，巨額的報酬可能會讓你強化內在的殺人動機，但再從客觀的角度來看，如果你殺了人，其他人又要如何知道，你是因為報酬而殺人或是你跟他本來就有仇呢？我想這就是一個複雜的問題了。

真實 UX 的研究也是如此，很多用戶可能會說：「只要給我很多優惠，或是開發什麼功能，我就會有使用你們產品的需求了」，真的是這樣嗎？用戶研究很多時候就像見山不見林又或見林不見山，永遠很難摸清用戶真實的需求為何，你可能大費周章的開發了用戶需求的產品，但開發完後，發現用戶根本不買單，我想有些開發經驗的人，應該都有經歷這樣的教訓吧！

外在動機可能變成內在動機嗎？

回到產品開發，我們的確很常用外在的動機去影響用戶的行為，因為外在動機是我們唯一可控的因素，提供更多的誘因，鼓勵用戶產生我們預期的行為，那這樣的外在動機有可能轉化成內在動機嗎？很遺憾的是：「有可能」，就是讓用戶養成習慣，一旦習慣後，行為就會自動產生，有一本書叫：《鉤癮效應》就是在說這件事。

鉤癮模式四步驟

回到殺人例子，在不考慮法律刑責的情況下，如果殺人能夠獲取報酬，而你又必須透過這些報酬維生，殺人就變成了你生存的方式，那外在動機（報酬）的確就轉變成了內在動機（生存）。

回到產品開發，透過外在的誘因，讓行為重覆發生時，或許就會讓用戶產生我有使用這個產品的需求，就像是社群被創造出來一樣，我們每天反覆刷著社群軟體，一開始可能是因為一些外在動機（找朋友聊天、獲取新知識、玩遊戲…等等），但刷著刷著變成了習慣，到最後變成我們的需求，不斷在虛擬的世界裡尋找著歸屬與認同，一樣又回到馬斯洛的愛與歸屬的需求，這個需求一直都存在。

需求能夠被創造嗎？

如果外在動機可以影響內在動機，需求的確可以被創造。但再從傳統行銷的角度，大部份的論述都偏向「需求無法被創造，但可以被滿足」，也就是說，需求本身就存在，但並不是每個需求都處於被滿足的狀態，所以才會產生慾望，商人很了解這個機制，所以透過大量的刺激（例如：廣告）來喚起你的慾望，這不是在創造需求，而是提醒你還有很多需求沒被滿足，或是將行為與更高層次的需求來做連結，讓你相信這麼做可以成為你想像中的自己。

所以，比起創造需求，需求有時更像被喚起，例如，以前曾經有一句很有爭議性的廣告台詞：「借錢是高尚的行為」，這句話，把借錢與高尚行為進行連結，也就是喚起用戶「尊嚴」的需求，如果借錢的動機只是為了「生存」需求，那廣告台應該是：「借錢是為了能過生活」，感覺很一般，但如果將需求提升至「尊嚴」的層級，整個廣告影響的力度就會變的很不一樣，但廣告並沒有創造尊嚴的需求，尊嚴的需求它一直都存在，只是透過廣告來喚起並與行為連結，這在商業廣告裡是很常用的方式，或稱「洗腦」，讓你「相信」這樣行為下的價值主張。

結論

這篇文章，為了讓大家比較好理解，透過一個比較極端的例子來討論需求與動機之間的關係，接著我們再重新檢視一下「用戶行為模式」這個模型。

用戶行為模式

這邊將用戶行為模式中的動機，再分為內、外在動機，同時我們也知道，需求與內在動機不可觀察，而外在動機可觀察可控制，外在動機會刺激用戶的行為、影響用戶的內在動機或是喚起用戶的需求。

再回到產品設計，我們的確會透過一些「研究方法」來探索用戶的需求，前面有提到，讓用戶自白就是我們探索需求的方式，我想了解UX方法論的人，腦袋應該就會浮現一些UX 工具了，另一個方式就是透過行為分析來推敲用戶的動機，再去深入了解用戶的需求，這也是我們認為比較客觀的方式，但這個方式就得建立在用戶行為產生之後，才能去做分析了，所以下一篇文章，我們就來討論用戶的行為、結果與態度。

用戶行為模式（2） — 需求與動機

需求（Needs）與動機（Motivation），這兩個名詞很常見，但常常會被混在一起使用，我常常會問學生能理解需求跟動機的差異嗎？能完整回答出這兩個名詞差異的很少，大部份人都認為它們指的是相同的事情，而且都混在一起使用，但真的是如此嗎？

在閱讀這篇文章前，建議先看過前一篇文章

https://uiclub.tw/2021/05/11/model_of_user_behavior/

如果要去區分它們的差異，舉個電影的例子，大家應該有看過推理的卡通或電影吧？試著回想一下推理劇情中的「殺人動機」這個說法，當我們懷疑某個人有殺人動機時，應該很少會把它說成是「殺人需求」吧？那推理片的殺人動機會是什麼？常見的就是利益衝突、復仇、情殺、謀殺…等等，回到殺人需求這個名詞，聽起來比較可怕，應該比較常出現在「驚悚」電影吧？可見這兩個名詞意義上是不相等的。

說到這系列的影片，我個人蠻喜歡「連續殺人犯（Serial Killers）」類型的犯罪影片（推薦片單： 破案神探 Mind Hunter），很喜歡跟著劇情去推敲這些連續殺人犯的心理狀態、殺人動機、需求、行為模式…等等，在影片中，會犯下連續殺人案件的兇手，他們行兇的動機，會來自於更深層的心理「需求」，所以單從殺人的行為結果來看，需求有可能會形成殺人動機，但再回到推理片的角度來看，殺人動機有很多，但未必是來自於需求。應用在用戶行為模式的解釋，我們可以知道：

需求可能形成動機，但動機不一定就是需求。

UI Club

那需求是什麼，動機又是什麼呢？

需求（Needs）

需求在心理學上指個體內部生理與心理之間的不平衡狀態，它提供了有機體活動的動力，是動機產生的基礎之一。

來源：wiki

Needs 在中文可以翻為「需求」或是「需要」，而動詞的說法就是：欲望（Desire），也就是「我想要的」。所以當我們想了解用戶的需求，就是在了解用戶的需求「是什麼」跟「想要什麼」。需求「是什麼」，可以從「馬斯洛需求層級（Maslow’s Hierarchy of Needs）」理論來理解，馬斯洛需求層級理論是將需求，由低層次到高層次的將需求分類為：生理、安全、愛與歸屬、尊嚴、自我實現，這些都是老生常談，但實際用在分析人身上，又是另一件事，因為人的需求是複雜且難以觀測的，因此單純只從「是什麼」的分析方式顯的有些局限，但仍然可以做為「是什麼」需求的簡單分類工具。而「想要什麼」就是未被滿足的需求或稱欲望，如果需求沒有被滿足，從行為論來看，這些未被滿足的需求，就會轉化成「驅力」，如果驅力讓用戶產生行為，就可以將這些驅力視為「動機」。

﹤補充一﹥
常見的需求理論，除了馬斯洛需求層級理論外，其實還有其他的需求理論，這些理論也是補足了馬斯洛需求理論的一些缺陷，像是成就動機理論（Achievement Motivation Theory）或是ERG理論（ERG Theory）。前者補足了馬斯洛需求層次理論對於高層次需求描述較為模糊，後者則是強調了需求層級之間並非像階梯關係逐層滿足，而是會互相作用影響，這些理論都是不同時代背景下產物，也都是用來探討當時人類需求的理論架構。有興趣人可以自行找查相關的理論內容，這邊就不再贅述。

﹤補充二﹥
這邊所指的需求對應到的是英文的：Needs，而不是 Demand 或是 Requirement，雖然後面兩個單字指的也是需求，這也是中文翻譯容易搞混的地方。Demand 的用法比較偏像經濟學的說法，它是需求（Needs）「量化」的結果，水是維持生命的需求（Need），但如果每個人都須要喝水，我們就可以說，市場存在飲用水的需求（Demand），我們暫時可以理解為「整體需求」，因為經濟學是研究人類整體的行為，像是我們常聽到的「剛性需求（Rigid Demand）」指的就是經濟學針對產品的價格與數量所定義的「價格彈性」較小的產品或服務。而 Requirement可以說是「功能性需求（Function Requirement）」，是從產品開發的角度思考，用來定義軟體要開發的功能或是組件，以上這些「需求」都是 UX 研究的課題，只是發生在不同的用戶行為階段。而我們在需求（Needs ）階段要挖掘的是用戶心理的密秘，就像前面提到的殺人需求，這個需求不會是 Demand 或是 Requirement，而是身為人最為原始的 Needs。

﹤補充三﹥
最近有美國的認知科學家 Scott Barry Kaufman 重新詮釋馬斯洛需求層級理論，認為人的需求不是「金字塔」應該是「帆船」，像這樣的詮釋方式或許比較符合目前社會狀態，其實理論的發展也會隨著時代不同有所改變，社會理論是從對社會的觀察而來，所以社會的狀態改變了，自然就會有新的方式來詮釋社會現象。

參考連結：

人生的需求不是「金字塔」而是「帆船」！他重新詮釋心理學大師馬斯洛的理論，教我們如何找到「目的」

動機（Motivation）

在心理學上一般被認為涉及行為的發端、方向、強度和持續性。

來源：wiki

動機，它是為了滿足需求所產生的驅力，所以在網路上搜尋動機相關的理論時，會發現很多動機理論都與需求理論相關，但動機的面向不是只來自本身的需求，通常我們會用另一個常見的動機分類方式：「內在動機」與「外在動機」來進行討論。

內在動機（Intrinsic Motivation）

指的是任務本身的興趣或愉悅帶來的動機，這存在於個體內部而非依賴於任何外部力量的驅動。

來源：wiki

延續「殺人動機」這個說法，如果殺人動機是來自於「內在動機」，那內在動機會是什麼？是因為殺人這件事，能讓加害者人能感到內心的滿足？前面有提到，來自於需求的殺人動機，通常讓人感到「驚悚」，電影如果演到這一個橋段，我想接著應該就會開始探討加害者的背景故事，以及殺人需求形成的原因，這些原因往往都是不符合常理或跳脫道德規範的；所以，內在動機的殺人需求真的很難透過簡單的觀察發現，只能經由更深入的背景調查、訪談、審問技巧、或兇手自白…等等，逐字逐格的去拼湊需求產生的過程與畫面，可以想像，身為 UX 設計師要了解用戶真實的內在需求動機有多困難，UX 的工具書上常常會提到「同理心」，但要同理「殺人」真的很難，劇情通常是這樣，總會有一個角色能夠「同理」殺人的需求，然後這個人就會陷入自我人格懷疑當中，但好在現實的產品設計場景中，我們要同理的大部份都是一般用戶，我想應該會比較容易一點。

外在動機（Extrinsic Motivation）

指的是從事某個活動的行為是為了取得外部收入，這種動機常常與內在動機相牴觸。

來源：wiki

一樣延續「殺人動機」的說法，如果殺人是「外在動機」，可能的外在動機會是什麼？前面也提到了情殺、仇殺、財務糾紛…等等都有可能，如果是這樣，劇情接著可能會開始釐清加害者與被害者之間的利害關係。用 UX 分析上，或許我們會想知道用戶的行為，是不是自於外在的誘因，像是：優惠活動、朋友推薦、廣告…等等，外在動機非原自於本身需求，所以比較容易觀察與控制，用在產品設計上，透過建立許多外在的誘因，刺激用戶持續的使用產品，這很常見也很好用，但相較於內在動機，外在的動機也比較難持續，一但誘因沒了，動機也會隨之消失。

因此，我們知道動機可以簡單分為內在動機與外在動機，我們要思考的，除了分類用戶動機，另外則是想出辦法來強化或弱化用戶的動機，這與我們想引導用戶的行為方向有關，像是在介面設計上，選擇什麼顏色、圖片、字體、文案內容…等等，確實的影響著用戶行為，因此動機的研究除了了解用戶需求外，更多的是我們要如何透過外在的刺激，來影響或引導用戶的行為達成任務目標。

了解完需求與動機，下篇文章接著就要來討論需求與動機之間的關係。

介面設計常見的「設計」詞彙

這篇文章主要是來介紹在介面設計文件中常見的設計詞彙，這些詞彙常見於各種規範文件；其實多數的設計詞彙並沒有正確或是一致的定義，通常都是各自習慣使用，這些詞彙大多是一些組合名詞，像是「設計原則」就是由「設計」與「原則」組合而成，通常不難理解，但使用上可以多思考這些詞彙背後的含意，在做設計時會更清楚到底在做什麼。

這篇文章除了整理一些詞彙外，還會附上一些參考資源，這些資源也是設計師常會參考的重點資料來源。同時，想透過這次的內容，讓大家能用更宏觀的角度來思考設計系統，其實產品設計須要與公司的發展緊密結合，結合的方式就是明確的定義下面這些會提到的設計詞彙。

許多設計師常常會覺得設計總是孤單的事，但事實是，好的設計必須與產品開發流程及公司發展策略緊密結合，才能發揮設計的價值，仔細思考下面的設計詞彙或許會帶來一些不錯的靈感。

設計價值觀（Design Values）

在了解設計價值觀前，我們先了解價值觀的定義：

價值觀（Values）是一種處理事情判斷對錯、做選擇時取捨的標準。

來源：wiki

價值觀是我們主觀判斷是非的一般標準，套用在公司上，常見的價值觀會來自於公司的使命或是願景，所以套用在設計上，我們可以這樣定義：

設計價值觀是評價設計好壞的一般標準，通常這個標準會與公司產品的使命、願景緊密連結。

UI Club

而設計價值觀會激發出設計原則（Design Principle）和設計模式（ Design Pattern）。如果沒有設計價值觀，代表沒有評斷設計好壞的標準，那你的設計就難以決擇；比較大的公司都會有自己價值觀，另外公司的價值觀也會隨著經營者不同有所改變，例如 Apple 的 Steven Jobs 與 Tim Cooker 價值觀就不太一樣，最終帶給用戶的感受也會呈現在最終的產品或服務上 。

通常我們可以在公司的招募網頁找到官方說法的價值觀，但真實的價值觀，可能要從產品或服務的體驗上去感受它，而大部份的公司通常也不會有太清楚的設計價值觀陳述，有時會將這樣價值觀陳述寫在產品的設計原則上，但最終都要與公司的價值觀有所共嗚。

參考資料：

設計語言（Design Language）

設計語言比較少見，但會出現在比較大量級的公司，像是 IBM、微軟、Google…等等這種等級的公司，設計語言（Design Language）根據wiki的定義：

A design language or design vocabulary is an overarching scheme or style that guides the design of a complement of products or architectural settings, creating a coherent design system for styling.

來源：wiki

所以我們可以知道，設計語言包含了許多建構產品的視覺元素，它有點像是針對「視覺」定義的視覺系統，能夠成為「語言」也就代表它足以作為溝通的工具。例如 IBM 的 Design Language，其中包含了設計哲學（philosophy）及相關的視覺元素：字體、icon、顏色、logo、圖片、動畫…等等都有定義明確的使用建議與規範，而自身的設計系統 Carbon Design System 也是從視覺語言所發展出來的。

另外，做為溝通工具，更多的時候是希望透過視覺語言與用戶溝通，讓用戶對產品有鮮明的品牌認知，像是當我們一想到 Google 的「 Material Design」就能聯想到「扁平化」的視覺特徵，而前一陣子很流行的 Mac Big Sur ，就會想到扁平但又帶有一點立體及漸層的風格，而這些風格也都是產品想帶給用戶的一種形象與感受，因此設計語言也會賦予產品個性，也是公司形象的一種延申。

參考連結：

設計系統

設計系統（Design System），這個詞最近在社群中很常被提及，但什麼是設計系統，各家的解釋或是用法各有不同，翻開國外一些具指標性的文章，對於設計系統的解釋也不太一樣，NNGroup 是這麼解釋設計系統的：

「A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels」

來源：https://www.nngroup.com/articles/design-systems-101/

大致上是說，設計系統是建立一組可以在不同頁面或 channels 裡規模化管理並分享的設計標準。再看由 Smashing Magzine 所推出的 Design System Book 裡的解釋：

「A design system is a set of interconnected patterns and shared practices coherently organized to serve the purpose of a digital product.」

摘錄自: Alla Kholmatova. 「Design Systems」。

指出設計系統是一個用在數位產品的內在聯結模式與共享的實踐方式。以上這兩個解釋，我認為前者比較偏向「產品」或是「功能」來定義設計系統，以「管理」的角度來建構設計系統；後者則比較偏向「組織」、「部門」的合作方式來定義設計系統，這也是我們最近常聽到的「Design Ops （設計營運）」的設計系統邏輯，兩種定義都是為了產生出一致且可規模化的設計結果。

設計系統有很多好處，像是提高工作效率、降低溝通成本、維持品牌的一致性…等等，但仔細想想除了好處，高度系統化的設計，其實也伴隨著一些問題與風險，這邊開放給大家思考，之後會再寫一篇文章專門聊聊設計系統。

參考連結

設計原則（Design Principle）

設計原則，應該也是許多設計師常聽到的詞彙，原則通常就是代表一些不易改變且很重要的事情，而根據 Interaction Design Foundation 對於設計原則的定義是：

Design principles are widely applicable laws, guidelines, biases and design considerations which designers apply with discretion.

來源：https://www.interaction-design.org/literature/topics/design-principles

設計原則就是一些我們在進行設計時考量到的規則。這些規則會幫助你完成設計目標，在設計的領域，我們常常看到許多設計原則，這些原則可能是一些視覺理論，或是某些設計大師的設計哲學，像我就喜歡 Dieter Rams’s 的提出的十個好設計原則（Ten principles for good design），這些原則也會被設計師引用在不同的領域。

而在介面設計看到的原則，泛指的產品介面設計原則，例如 Apple iOS 系統的 Human Interface Guildeline（HIG）裡面，針對iOS的系統就有定義一些「原則」，以產品的角度來看，我們可以說是設計 iOS 產品介面的「大原則」，而 iOS 所例出來的產品設計原則有六項：Aesthetic Integrity、Consistency、Direct Manipulation、Feedback、Metaphors、User Control，每個原則都值得我們在做設計時反覆審視，再細看每個操作元件，都會附上該元件使用的一些「小原則」，也就是元件在使用的一些重點注意事項，這些小原則是以大原則作為設計目標，彼此串聯起來，就是要符合前面提到的設計價值觀，讓用戶能真實感到受到產品價值。

另外，在介面設計領域，也有一些通用的設計原則，會成為通用的設計原則都是因為的大家對於提出者的建議有高度的認同，介面設計最常見的原則就是 Jakob Nielsen 提出來的 10 Usability Heuristics，可以作產品易用性評估的大原則。再回到產品思考，如果可以建立或引用明確的設計原則，在做設計時也比較容易達成明確的設計目標。

參考連結：

設計規範（Design Guideline）

相信許多人都知道或聽過設計規範（Design Guideline），定義參考 Interaction Design Foundation：

Design guidelines are sets of recommendations on how to apply design principles to provide a positive user experience.

來源：https://www.interaction-design.org/literature/topics/design-guidelines

設計規範其實就是一份文件，說明了一些建議的做法與設計原則，是用來溝通的文件，關於撰寫方式可以參考我寫的文章：介面設計規範（UI Design Guideline）的撰寫方式

那怎麼理解設計規範？作為「規範」，我們可以將它理解成「內部標準」，它是由公司內部的團隊制定的規格文件，像是 Apple 的 iOS Human Interface guideline，是 Apple 內部團隊所撰寫的一份標準文件，除了自家的產品外，在蘋果生態內的開發者也會依據這份文件做為設計或開發標準，但對其他公司的產品來說，Apple 的規範文件會更像是一個外在標準文件，設計師或開發者都會盡可能的去遵循這些標準，蘋果公司也會計對這些標準來進行產品上架審核，目的也是為了讓使用 Apple 裝置的用戶能夠有更一致的用戶體驗。

此外，我們常常會提到的設計標準（standard）跟設計規範很像，但能稱為「標準」也代表這份文件具有高度的共識，之於 Apple 或是 Google 所提供的設計規範文件外，文件背後其實還有引用更高的設計標準，這份標準就是 WCAG（Web Content Accessibility Guidelines），這份文件是由 W3C（World Wide Web）組織所維護，它的內容是針對任何人（包含殘疾人士或是年長者），都能通用的 Web 易用性標準，被廣泛的應用在不同系統的開發上，對於設計、開發、測試都有給予一些明確的開發指引，可以說是規範中的規範，也是在 Web 領域公認的一致化標準。

參考連結：

WCAG

設計模式（Design Pattern）

設計模式（Design Pattern），這裡的模式英文是 Pattern，Pattern 在中文也翻為「圖樣」，是一種重覆出現的圖案，因此設計模式我們可以這樣思考：一直重覆出現的元素或組件；使用在介面設計，指的就是介面設計模式（UI Design Pattern），定義參考 Interaction Design Foundation：

User interface (UI) design patterns are reusable/recurring components which designers use to solve common problems in user interface design.

來源：https://www.interaction-design.org/literature/topics/ui-design-patterns

根據它的定義，我們知道介面設計模式是一個重覆使用的組件（components），但重點不是「重覆使用」，重點是這個設計模式解決了用戶遇到的「重覆問題」，所以設計模式是針對特定問題的一般性解決方案。舉個列來說，「按鈕」是一個常見的設計模式嗎？我們的確很常使用到「按鈕」，但不是因為它重覆出現，而是它解決了用戶「接下來我要做什麼？」的問題，按鈕的用途不是只是點擊，點擊只是它的預設用途（affordance）（關於預設用途可以參考這篇），有效的引導用戶完成任務才是我們的設計目的，因此我們要專注於「問題」來設計按鈕，將它變成設計模式，在這樣的思考下才有主按鈕（primary button）、次按鈕（secondary button）之分，再依據用戶情境或操作目的，來選用我們的按鈕組合，這才是「按鈕」的設計模式。

關於介面設計模式，可以參考《操作介面設計模式 》這本書，裡面有介紹並整理常見的介面設計模式，也有詳細說明每個組件所解決的問題、使用情境、方式…等等，對於初學者來說，是理解介面設計不錯的途徑。

參考連結：

操作介面設計模式：https://www.books.com.tw/products/0010880011

結論

以上這些常見的設計詞彙，會出現在許多的設計文件裡，通常我們會從設計系統開始思考，如果我們要架構一個完整的設計系統，要如何開始？如果先不討論那些組件（component）的細節，或許可以從更大方向的方式著手，像是找出「設計價值觀」或是「設計語言」，並在建立設計系統之前，為它們做明確的定義，這也是我們常聽到的「設計策略」。有了大方向，再從「設計規範」開始建立「設計原則」，定義問題並找到「設計模式」，接著才思考更具體的執行方式。

或許這樣的方式更能聚焦在「設計」而非「系統」，透過這篇文章給大家一個思考方向，有任何心得歡迎留言討論。

介面設計規範（UI Design Guideline）的撰寫方式

關於介面設設計規範（UI Design Guideline；以下通稱 Guideline）的撰寫方式，其實目前並沒有一致的規則與邏輯，每一間公司或產品可能撰寫的方式都會不一樣，而且 Guideline 不應該只是單純的「文件標識」，作為文件，最重要的就是用來紀錄與溝通，而Guideline的溝通對象為何？通常就是工程師、設計師或PM/UX，所以在撰寫這份文件時，要確保閱讀者能夠理解，並持續的運用到產品的維護與開發上。

Guideline的溝通對象

  1. 設計師
    對於設計師來說，這份文件必需要能夠共同維護與編輯，因此要有一致的撰寫邏輯。
  2. PM / UX
    用來與PM溝通組件的使用方式與情境，後續 PM / UX 在規劃產品時也會比較有效率。
  3. 工程師
    對工程師來說，文件必需能夠清楚的交待組件的使用方式、規格、相關的參數定義及相關資源（Asset）的取得方式。

建立 Guideline 並不是單純只是標識文件，標識這件事情，目前可以由軟體來處理，而文件的內容應該更清楚的說明 UI 組件（UI Compoenent；以下統稱 Component）的使用情境、狀態、規格，並建立一個可以持續迭代的標準，將 Guideline 帶到產品的開發流程，提高開發效率。這邊列舉出 Guideline 以下的幾個用途：

  1. 提供一致化的設計
  2. 避免組件重覆設計
  3. 建立可複用，可擴充、可迭代的 UI Component
  4. 作為與工程師交付文件一個標準

因此，這份文件在撰寫時必需要能夠擴充、複用、迭代，而在程式的實作上，也要能夠輔助工程師建立程式端的 Component。完整的文件與好的維護方式，才能夠加速並提高產品的開發效率。

Guideline 的撰寫邏輯

Guideline 的撰寫邏輯，可以參考原子設計（Atomic Design），原子設計的邏輯是由小而大去建立整個 UI系統 ，但 Guideline 的撰寫邏輯剛好相反，是由大到小，先看使用方式再看整體頁面的佈局，接著再詳細說明Component的細節與狀態，這樣的邏輯比較好讓閱讀者清楚的了解這個Component 的使用方式。

另外 Guideline 的最小單位，從原子設計來看，應該是 Molecules，也就是 Component，在 Figma 裡我們可以說是一組 Variants，其中包含了這個 Component 的不同狀態（State），而更小的Atoms，應該定義在Style裡，其中包含了：Color、Grid、Font、Spacing、Icons … 等等全域型的樣式元素，在寫 Guideline 的時候，建議可以將 Style 獨立管理。（之後會針對 Style 建立的方式寫一篇文章）。

UI Spec 在撰寫的結構，可以參考我所整理的架構，這邊的內容也是參考 Google Material Design，所整理出來的，這邊以建立 Modal（Dialog） Component 來進行說明：

Usage （使用方式）

說明組件使用的一些原則（Principle）、類型（Type）、如何使用（How to Use）、何時使用（When to Use）、在那裡使用（Where to Use）…等資訊。

這邊參考 Material Design 的 Dialog 使用方式

Layout （佈局）

Component 在畫面的位置（Position）、尺寸（Dimension）。

說明 Component 在畫面的位置、尺寸。

Anatomy （解構）

組件的組成元素，從原子設計的角度來看，是從 Organizms 去拆解使用到的 Molecules

列出 Component 的結構，並做好命名

State & Spec （狀態與規格）

狀態與規格會放在一起的原是，是因為我們需要在不同的狀態下，顯示 Compoenent 的規格，需要包含物件狀態，對應到的詳細參數。從原子設計角度來看，指的就是 Molecules。

詳細說明Compoenent的規格，與相關參數。

Interaction （互動方式）

簡易的描述互動的行為，如果軟體允許，也可以用動畫的方式呈現交互效果。

在 Material Design 的文件裡，會用動畫的方式顯示互動方式。亦可用文字簡單表達預期達成的效果。

Asset（資源）

如果有切圖的話，將切圖整理在該 Component 的文件裡，日後方便維護。

介面設計師最常參考的Guideline

介面設計最常看的參考的 Guideline 應該就是 Google 的 Material Design 或是 Apple 的 iOS Human Interface Guidelines（HIG）；這兩份文件的撰寫方式比較不同，在 Material Design 提供的文件裡，對於Component 的使用及其規格都有做詳細的定義，但 HIG 則都是以大原則的方式來做定義，如果要撰寫公司產品的 Guideline，建議以 Material Design 的撰寫方式來進行參考，列大原則的方式可能比較難在一般產品運行，當然或許 Apple 公司有自己的開發規範，但這個規範可能也只存在於他們公司內部，外界無法取得。

結論

撰寫 Guideline 最大的目的就是「溝通」，如果無法達成溝通的目的，那這份文件基本上就是無效的，許多設計師，喜歡把文件整理的美美的，但內容卻不知所云，好像把所有的狀態列完就沒事了，但事實是，要寫出一份讓工程師看的懂的 Guideline，需要長期的合作經驗與討論，經驗較少的設計師，通常在與工程師溝通的環節是非常簿弱的，經常答非所問，解決方式是多與工程師討論，或是閱讀一些前端框架的規範，像是：bootstrap、ant design …等等，會讓你更快的理解工程端的實作方式。

最後，再次強調 Guideline 不是一次性的文件，需要持續的迭代與維護，它跟產品一樣，需要花時間去了解閱讀者的需求，不管是Material Design 或是 iOS Human Interface Guidelines 至今也都是持續在更新的 。

這篇文章先提出一個簡易的撰寫架構，但並非照本宣科，還是要依情況來進行調整；另外，還需衡量自己所處的公司需求，像是接案型公司（乙方），或許就沒有維運產品的需求，只出 UI Spec 就可以完成開發，那就不需要額外再撰寫 Guideline，或者以將 Guideline 做為可以重覆使用的 Template（模版），來降低撰寫 Guideline 的時間成本，一切都以所處的公司與需求來調整做法，沒有一定怎麼做或怎麼寫會是最好的結論。

撰寫 Guideline 很花時間，必須仔細的去思考產品各項功能組件之間的細節，同時還要思考到組件的可實現性，這也是專精於介面設計的價值所在，所以當有人問介面設計師是在做什麼的，絕不是是什麼「出圖」可以說明的，我們的工作除了讓產品變的更好用，很大的價值是透過設計讓產品開發團隊變的更有效率！

有任何問題或更好的想法都歡迎給予意見討論。

設計的心理學（2） — 設計的基本原則

一個優良的設計要滿足兩個特點：可發現性 （Discoverbility）、易理解性 （Understanding）。從字面上的意思來看，可發現性是指，使用者能夠容易發現那些是可以做的動作 、怎麼做；易理解性是指使用者可以容易理解並知道該如何使用。

— 《設計的心理學》

這篇我要來整理一下這本書所提到的設計基本原則，雖然書中有提到「七個設計的基本原則」，但細讀此書後發現，有些地方不容易連貫，而且解釋上不容易理解，所以我先提出書中的觀點後，再整理成一個我認為比較好理解的概念。

首先，在本書中一開始就提到，一個優良的設計要滿足兩個特點：可發現性 （Discoverbility）、易理解性 （Understanding）。從字面上的意思來看，可發現性是指，使用者能夠容易發現那些是可以做的動作 、怎麼做；易理解性是指，使用者可以容易理解並知道該如何使用。這是設計師在設計任何裝置或介面，必須遵循的大原則，只要失去其中一個原則，就不能稱的上是優良的設計。

而在書中七項行動原則所延伸出以下七項設計的基本原則 ：

  1. 可發現性 （Discoverbility）
  2. 預設用途 （Affordances）
  3. 指意 （Signifiers）
  4. 使用局限 （Constraints）
  5. 對應性 （Mapping）
  6. 回饋 （Feedback）
  7. 概念模型 （ Conceptual Model）

七項設計原則中，有提到可發現性但卻沒提到易理解性，這是我比較疑惑的地方，而在p37有提到：「可發現性是來自五個基本的心理觀念：預設用途、指意、使用局限、對應性、回饋」，但對易理解性並沒有太多的解釋，所以易理解性不包含在七項設計原則嗎？有點不合理，所以我在想可能指的是概念模型？

關於概念模型的解釋在p52有提到：「概念模型是一個東西怎麼運作的解釋」，同時又提到概念模型主要的線索來自於東西的結構，特別是指意、預設用途、使用局限及對應性，也就是說，概念模型是可發現性的組合，能夠讓使用者合理的解釋東西如何運作，所以如果使用者能夠去解釋一個東西如何正確的運作，我想跟使用者對於東西的「理解」有密切的關係，因此我推斷易理解性指的就是概念模型，這是可能比較合理的解釋。

書中將可發現性視為七項設計基本原則之一，但又包含了其中的五項原則，但易理解性卻沒在這七項設計原則之中，這是我覺得書中比較不清楚的地方，因此我將這七個設計原則重新理解為：

二大設計目標、六大設計原則，如下圖。

  • 二大設計目標：可發現性、易理解性。
  • 六大設計原則：預設用途、指意、對應性、使用侷限、回饋、概念模型。

為什麼我要將圖畫成圓型，因為我覺得這是一個合理的解釋模型。使用者透過可發現性由外而內的去認識產品，形成產品的概念模型，所以如果設計師發展出來的概念模型與使用者的概念模型相似，使用者就可以正確的理解、使用你的產品，這就是優良的設計。

但對於設計師而言，這裡有一個很大的陷阱，就是因為使用者是從外而內的去認識產品，所以設計師往往會用自己也是使用者的心態去設計產品，這是根本性的錯誤，但卻又很難去發現。

好的設計方式，要從概念模型開始，去理解使用者的概念模型，這也就是為什麼要做使用者經驗分析，目的是要讓概念模型正確，否則就算介面再好看，操作上讓使用者無法理解，那一切都是枉然。

所以設計師要養成好習慣，做設計一定要有理，系統性的思考整個產品的架構，不建議一開始就上機畫精稿，因為視覺會影響設計師的判斷，應該從線稿開始，從流程、不斷的討論，收斂發散再收斂，才能成就一個很棒的產品。

方向對了，接下來再來好好討論那六項設計原則吧。

設計的心理學（1） — 行動的七個階段

這陣子看了一本設計心理相關的書《設計的心理學》，是 Donald A. Normand — 唐納．諾曼的大作，只要是從事介面或是使用者經驗的設計，應該多少都會看過他的著作 ，而這本書已經是第三版了，作者也不斷的修正及增加新的內容。這本書不太好閱讀，偏重認知心理學，理論與實務之間的結合，但為了把從書中學到的東西內化，我將裡面所提到的重要概念再透過自己理解的方式來進行說明與討論。

書中有提到幾個概念，可以運用在設計思考的過程，包含行動的七個階段，心理歷程的三個層級，及與其相互配合的七個設計基本原則。首先來談談行動的七個階段。

書中對於行動的七個階段的說明是：

  1. 目標：形成目標
  2. 計劃：選擇行動
  3. 制定：決定動作順序
  4. 執行：付諸行動
  5. 感知：知道事物的狀態
  6. 解釋：對感知的結果形成了解
  7. 比較：評估結果與目標的差異

但這七個階段，除了「目標」外，其實可以簡單的理解成兩個部份：「執行動作」、「評估動作後的結果」，而在執行動作之前，使用者通常會有個目標，目標來自於主動（目標驅動）或被動（事件驅動）的目標，而使用者對於目標會存在基本的知識與認知。

對設計師而言，我們無法控制使用者的目標或事件，唯一能做的，是當使用者被目標或事件驅動時，如何透過設計讓使用者正確的執行動作，並讓這動作的結果符合使用者的預期。而七個設計的基本原則，就是作者所提供讓使用者能順利完成任務的設計思考方向。

舉個例來說：用戶小明，與朋友約好要去某餐廳吃飯，而在前往目的地的途中迷了路，於是拿出了手機，打開手機內地圖功能，輸入了餐廳地址，並透過導航的功能，到達目的地。

  • 小明在前往餐廳的途中迷路 → 設計師比較難控制的因素，在案例中使用者是被迷路的事件給驅動。
  • 手機的地圖與導航功能 → 設計師能透過設計來告訴使用者如何使用導航功能完成任務。

而在討論如何設計之前，要先清楚的掌握使用者的七個行動階段，並透過行動的拆解，來了解每一個行動的背後必須去思考待解決的設計問題，從上用戶小明的例子來看：

  1. 目標 → 目標決定設計的情境，使用者 A 在前往餐廳時迷路。
  2. 計畫 → 拿出手機，並執行某個地圖 app。
  3. 制定 → 決定動作的順序，通常是下意識的，像是拿出手機、滑開解鎖，輕撥畫面尋找地圖app，這一連串的動作，其實大多在使用者大腦中是下意識的行為，這關係到手機操作的「概念模型」。
  4. 執行 → 執行每一個動作，可能是「預設用途」，可能透過「指意」、「對應性」來完成一個動作。
  5. 感知 → 每個動作的結果，是不存在「使用局限」、有沒有正確的「回饋」，讓使用者感知到動作後的結果。
  6. 解釋 → 解釋行為後的結果，產生認知或情緒。
  7. 比較 → 比較目標與結果是否一致，產生評價。

從小明的例子，我們從行動的七個階段去思考並了解背後的問題；上述中「」的部份，也就是作者所提出的七個設計的基本原則，是設計師必須要去解決的問題，下一篇會針對七個設計的基本原則再說明。

行動的七個階段不是只用在解決介面的問題上，其實在任何的設計，背後的邏輯都是一樣的，根據本書作者的說明，七個行動階段能用來理解人類行為的基本架構。所以設計時，可以好好運用這個架構來思考每個設計背後的問題。

下一篇在針對七個設計的基本原則舉例說明。 歡迎討論。

用戶行為模式（1） — 用戶行為的五個階段

個人投入UI/UX的教育領域有一段時間了，在數百次與學生互動過程中，累積了一些經驗，在反覆的聽取學生描述想法的過程中，我發現其實用戶的行為，應該有個穩定的模式，先稱這個模式為：「用戶行為模式（Model of User Behavior）」。其實大部份的學生都專注在學習UX的工具，想透過UX方法來探索用戶需求或是了解產品，或許從過程中可以得到一些不錯的產品靈感，但對於用戶的行為解讀，常常會抓大放小或抓小放大，容易使用片面的資訊去解讀用戶的行為模式，我想，應該是缺乏一個比較宏觀的概念來思考用戶行為模式。

消費行為模式

用戶行為模式這個說法目前在網路上沒有完整的文章或說法（歡迎補充），但不代表這樣的模式不存在，概念是從消費者行為模式（Model of Consumer Behavior）中得到的靈感，這個模式是在1910年，由心理學者John Dewey所提出的 — 決策過程的五個階段（Five‐stage Decision Process），廣泛使用在消費者行為的分析上，所以可以理解為消費者行為模式，不直接使用此模式來代表用戶行為，是因為用戶行為未必是消費行為，所以無法單純從消費行為模式來推敲一般用戶行為模式，消費者行為模式主要分為幾個階段：

需求認知→情報搜尋→方案評估→購買→購後結果

Five-state Decision Process; Model of Consumer Behavior -1910, John Dewey

這個模式，廣泛使用在消費者行為的分析上，也是大多數的教科書會寫的內容，其實就是用時間軸來切分消費前、中、後的概念；為了符合用戶行為模式，我把消費者行為模式做一點調整，一樣透過時間軸，廣義的去定義用戶行為模式。

用戶行為模式（Model of User Behavior）

一般來說，用戶的行為會有以下幾個階段：

需求→動機→行為→結果→態度

Model of User Behavior

從主觀的角度來看，人的行為大多是從自我本身的需求開始，接著會產生動機，動機驅動行為，行為導致結果，最後產生對於這個結果的態度。這樣的模式其實蠻好理解的，也符合人類的心智模式，但通常我們在分析人的行為，都是站在客觀的角度，我們可以從任一個階段切入，來了解用戶的行為模式，例如，我們可以從用戶的態度開始（正面、負面），進而推敲是什麼結果（符合預期、不符合預期）導致他的態度，再往前推敲他是什麼行為導致他的結果，進而分析他行為前的動機，必要時深入探索用戶的需求，這是一個比較完整的推論方式，可以完整的理解用戶行為模式，才能深刻體會到用戶真實的需求與感受。

UX工具作用範圍有限

但在一般資源與條件受限的情況下，我們通常只會從我們有興趣的階段切入討論，例如，如果只是要進行易用性測試，在測試的過程，用戶需要逐項完成任務，如果任務的結果是失敗的，我們就可以再往前回推，是什麼行為導致任務失敗，或是往後觀察用戶的態度，進而調整行為的假設，所以透過易用性的測試，通常我們只會觀察到用戶的行為、態度及一堆「設計改善清單」。

受限於當下的條件與工具，只能關注用戶的行為結果，那自然用戶的需求，就不會函蓋在易用性測試的討論範圍。所以，UX的工具百百種，每一個工具能作用的範圍有限，如果不能以宏觀的來看用戶的行為模式，是很難將這些工具用的得心應手。

如何挖掘用戶秘密

這邊舉個用戶行為模式用在訪談的思考過程。如果學生是要做旅遊的app，我很常看到學生會設計這樣的訪談題目：

你平常是用什麼旅遊App？為什麼使用這個App？

像這類問題，從用戶行為模式思考，就是探討用戶的行為結果，因為選擇了使用某個旅遊App，而「為什麼使用這個App？」，則是想了解用戶使用這個App的動機，如果用戶回答的是因為「好用」，回答的其實是對於這個App的「態度」，態度的確會影響「內在動機」，但這絕對不是你要的答案，這邊可以分出兩條思考路線，你可以繼續問：「好用是指那些功能好用？」，繼續了解具體的行為結果，但如果你想知道用戶的真實動機，你就得繼續再追問像這樣的問題：「你如何知道這個產品的？」，或許就可以得到「朋友推薦」，再往前推論這個app，可能滿足了用戶的「社交」的需求諸如此類的結論。

你以為的用戶其實是你自己

像這樣的問題在我與學生的互動過程不斷的發生，但通常大部份的學生，心裡都會假設好一些目標與結果，但其實這比較像是在驗證自己的想法是不是與用戶的一致，而不是探索用戶的行為，得到的結果，八成會與你的假設猜想是一致的，所以你了解的不是你的用戶，而只透過用戶了解自己。但對我來說，這些結論用猜的也猜的到。像是因為好用才用，這很明顯是用戶在講幹話，但如果能從用戶行為模式的方式思考，或許就可以一步一步的去挖掘用戶不為人知的秘密。

這系列的文章，我會針對用戶行為的五個階段進行說明與整理，希望能透過結構化的方式來思考用戶的行為，才能在探索用戶的過程中，得到更貼近用戶的行為與結果。