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

這些狀態的集合，就會是一顆按鈕，而在不同的控制情境下，出現的按鈕的狀態就會不同，相同特性還有表單（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 應該要有的五種狀態，就好像水被定義有三種確定的狀態一樣。（這篇是介面設計師必讀的文章）

結論

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