[TOC]
有時候，對于我們的決定只要有一點點的數據支持就夠了。也就是一點點的變化，可能就決定了我們產品的好壞。我們可能會因此而作出一些些改變，這些改變可能會讓我們打敗巨頭。
這一點和 Growth 的構建過程也很相像，在最開始的時候我只是想制定一個成長路線。而后，我發現這好像是一個不錯的 idea，我就開始去構建這個 idea。于是它變成了 Growth，這時候我需要依靠什么去分析用戶喜歡的功能呢？我沒有那么多的精力去和那么多的人溝通，也不能去和那么多的人溝通。
我只能借助 Google Analytics 來收集用戶的數據。從這些數據里去學習一些東西，而這些就會變成一個新的想法。新的想法在適當的時候就會變成一個產品，接著我們就開始收集用戶數據，然后循環。
## 構建-衡量-學習
構建-衡量-學習是在《精益創業》中的一個核心概念，這結合了客戶開發、敏捷軟件開發方法和精益生產實踐。他們是非常重要的一個循環：
數據分析過程
這一過程不僅僅可以改進我們的產品，也可以用于初創企業。它并不是獨立的一個環節，實現上它應該是一整個環節：我們根據我們的想法去創建我們的產品，在使用產品的過程中我們收集一些數據，再依據這些數據來改進我們的產品。
### 想法-構建
想法實際上便是解決一個痛點的解決方案。如果你和我一樣也經常記錄自己的想法，你會發現每個月里，你總會跳出一個又一個的想法。正如，我在那篇《[如何去管理你的 Idea](https://www.phodal.com/blog/use-github-manage-idea/)》中說的一樣：
> 我們經常說的是我們缺少一個 Idea。過去我也一直覺得我缺少一些 Idea，今天發現并非如此，我們只是缺少記錄的手段。
我們并不缺少 Idea，我們只是一直沒有去記錄。隨著時間的增長，我發現我的 GitHub 上的 Idea 墻([ideas](https://github.com/phodal/ideas/issues))一直在不斷地增加。以至于，我有一個新的 Idea 就是整理這個 Idea 墻。
而作為一個程序員，我們本身就可以具備構建一個系統的能力，只是對于大多數人來說需要多加的練習。有意思的一點是，這里的構建系統與一般的構建系統有一點不太一樣的是，我們需要快速地構建出一個 MVP 產品。MVP 簡單地來說，就是最小可用的產品。如下圖的右邊所示：
MVP
在每一層級上都實現一定的功能，使得這個系統可用，而非構建一個非常完整的系統。隨后，我們就可以尋找一些種子用戶來改進我們的產品。
### 產品-衡量
按照上面的步驟，到了這里應該就是客戶開發。而如《精益客開發》一書所說，客戶開發可以分成五個步驟：
* 形成假設。即我們覺得用
* 找到可以交談的潛在客戶
* 提出恰當的問題
* 從答案中找到有用的信息
* 弄明白現階段需要構建什么樣的產品來保持下一個學習循環
在整個過程中，我們其實就是在了解我們的客戶是誰，以及他們的需求。并且在這個過程中，我們可以為我們的開發確認出清晰的假設，我們可以一點點地打造出用戶喜愛的產品。
### 數據-學習
當我們收集到一定的用戶數據，如網站、應用的數據，我們就開始去分析數據。如《精益創業》所說，在分析數據之前，我們需要確定我們的增長模型，即：
* 黏著式增長引擎——其重點是讓用戶成為回頭客，即讓客戶持續使用我們的產品。這就意味著，我們在分析數據和學習的過程中，我們要側重于關注流失率和使用頻率。
* 病毒式增長引擎——其只做一件事：讓名聲傳播出去。即通過用戶間的不斷傳播來擴散產品，我們需要考慮所謂的**病毒式傳播系數**，還有用戶之間的特定行為。
* 付費式增長引擎——賺錢是識別商業模式是否可持續的指標。
針對不同的增長引擎有不同的學習過程，如媒體網站，我們通過不同的方式來導入流量，這些流量最終會有一些會轉化成價值。這些價值會以不同的形式出現，如訂閱率、在線參與度、廣告營收等等。
而從這些數據中學習就需要一些特殊的技巧，詳情請見下面的參考書籍。
參考書籍：
* 《精益數據分析》
* 《精益客戶開發》
* 《精益創業》
## 數據分析
數據分析是一個很有意思的過程，我們可以簡單地將這個過程分成四個步驟：
* 識別需求
* 收集數據
* 分析數據
* 展示數據
值得注意的是：在分析數據的過程中，需要不同的人員來參與，需要跨域多個領域的知識點——分析、設計、開發、商業和研究等領域。因此，在這樣的領域里，回歸敏捷也是一種不錯的選擇（源于：《敏捷數據科學》）：
* 通才高于專長
* 小團隊高于大團隊
* 使用高階工具和平臺：云計算、分布式系統、PaaS
* 持續、迭代地分享工作成果，即使這些工作未完成
### 識別需求
在我們開始分析數據之前，我們需要明確一下，我們的問題是什么？即，我們到底要干嘛，我們想要的內容是什么。
> 識別信息需求是確保數據分析過程有效性的首要條件，可以為收集數據、分析數據提供清晰的目標。
當我們想要提到我們的網站在不同的地區的速度時，我們就需要去探索我們的用戶主要是在哪些地區。即，現在這是我們的需求。我們已經有了這樣的一個明確的目標，下面要做起來就很輕松了。
### 收集數據
那么現在新的問題來了，我們的數據要從哪里來？
對于大部分的網站來說，都會有訪問日志。但是這些訪問日志只能顯示某個 IP 進入了某個頁面，并不人詳細地介紹這個用戶在這個頁面待了多久，做了什么事。這時候，這些數據就需要依賴于類似于 Google Analytics 這樣的工具來統計網站的流量。還有類似于New Relic這樣的工具來統計用戶的一些行為。
在一些以科學研究為目的的數據收集中，我們可以從一些公開的數據中獲取這些資料。
而在一些特殊的情況里，我們就需要通過爬蟲來完成這樣的工作。
### 分析數據
現在，我們終于可以真正的去分析數據了——我的意思是，我們要開始寫代碼了。從海量的數據中過濾出我們想要的數據，并通過算法來對其進行分析。
一般來說，我們都利用現有的工具來完成大部分的工作。要使用哪一類工具，取決于我們如要分析的數據的數量級了。如果只是一般的數量級，我們可以考慮用 R 語言、Python、Octave 等單機工具來完成。如果是大量的數據，那么我們就需要考慮用 Hadoop、Spark 來完成這個級別的工作。
而一般來說，這個過程可能是要經過一系列的工具才能完成。如在之前我在分析我的博客的日志時(1G左右)，我用 Hadoop + Apache Pig + Jython 來將日志中的 IP 轉換為 GEO 信息，再將 GEO 信息存儲到 ElasticSearch 中。隨后，我們就可以用 AMap、leaflet 這一類 GEO 庫將這些點放置到地圖上。
### 展示數據
現在，終于來到我最喜歡的環節了，也是最有意思，但是卻又最難的環節。
我們過濾后我們的數據，得到我們想要的內容后，我們就要去考慮如何可視化我們的數據。在我熟悉的 Web GIS領域里，我可以可視化出我過濾后的那些數據。但是對于我不熟悉的領域，要可視化這些數據不是一件容易的事。在少數情況下，我們才能使用現有的工具完成需求，多數情況下，我們也需要寫相當的代碼才能將數據最后可視化出來。
而在以什么形式來展示我們的數據時，又是一個問題。如一般的數據結果，我們到底是使用柱形圖、條形圖、折線圖和面積圖中的哪一種？這依賴于我們有一些 UX 方面的經驗。
參考來源:?**精益數據分析**。
## 用戶數據分析：Google Analytics
Google Analytics 是一個非常贊的分析工具，而且它不僅僅可以用于 Web 應用，也可以用于移動應用。
### 受眾群體
如下圖是 Growth 應用最近兩星期的數據：
Growth GA
這是 Google Analytics 中的“受眾群體”的概覽，在這個視圖中：
1. 折線圖就是每天的用戶數。
2. 下面會有用戶數、會話、屏幕瀏覽量等等的一些信息。
3. 右角的餅圖則是回訪問用戶和新用戶的對比。
4. 最下方便是受眾的信息——國家、版本等等。
從圖中，我們可以讀取一些重要的信息，如用戶的停留時間、主要面向的用戶等等。在瀏覽器版本會有：
1. 瀏覽器與操作系統
2. 移動設備
這樣的重要數據，如下表是我網站 20160104-20160120 的訪問數據：
| 瀏覽器 | 會話 | 新會話百分比 |
| --- | --- | --- |
| Chrome | 5048 | 75.99% |
| Firefox | 694 | 78.39% |
| Safari | 666 | 78.68% |
| Internet Explorer | 284 | 87.68% |
| Safari (in-app) | 92 | 86.96% |
| Android Browser | 72 | 87.50% |
| Edge | 63 | 79.37% |
| Maxthon | 51 | 68.63% |
| UC Browser | 41 | 80.49% |
| Opera | 34 | 64.71% |
可以從上表中看到訪問我網站的用戶中，IE 只占很小的一部分——大概4%，而 Chrome + Safari + Firefox 加起來則近90%。這也意味著，我可以完全不考慮 IE 用戶的感受。
類似于這樣的數據在我們決定我們對某個瀏覽器的支持情況時會非常有幫助的。也會加快我們的開發，我們可以工作于主要的瀏覽器上。
### 流量獲取
除此，不得不說的一點就是流量獲取，如下圖所示是我博客的熱門渠道：
Phodal.com Traffic
可以直接得到一個不錯的結論是我的博客的主要流量來源是搜索引擎，再細細一看數據：
| 來源/媒介 | 會話 |
| --- | --- |
| baidu / organic | 2031 |
| google / organic | 1314 |
| (direct) / (none) | 1311 |
| bing / organic | 349 |
| github.com / referral | 281 |
主要流量來源就是 Baidu 和 Google，看來國人還是用百度比較多。那我們就可以針對 SEO 進行更多的優化：
1. 加快訪問速度
2. 更表意的 URL
3. 更好的標題
4. 更好的內容
等等等。
除此，我們可以分析用戶的行為，如他們訪問的主要網站、URL 等等。
### 移動應用
除此，我們還可以使用它來分析移動應用，不過這受限于 Google 在國內的訪問程度。如下圖是 GA 收到的應用的使用數據：
Growth 應用數據
我們也可以從上面看到 APP 的安裝來源等等。
## 網站性能
網站性能直接影響到了網站的響應時間、吞吐量等等，也是運維、開發一系列技術的體現。
### 網站性能監測
網站性能監測
> 網站可用性是網站性能監測的重要指標之一，表示在一段時間內，網站處于“正常狀態”的機率。
* DNS 解析
* 內存、硬盤等等
* 網頁打開速度
#### 應用性能指數
> Apdex 聯盟，一個由眾多網絡分析技術公司和測量工業組成的聯盟組織，它們聯合起來開發了“應用性能指數”即“Apdex”(Application Performance Index)，用一句話來概括，Apdex 是用戶對應用性能滿意度的量化值。它提供了一個統一的測量和報告用戶體驗的方法，第一次把最終用戶的體驗和應用性能聯系在了一起。
任務響應時間定義為：當用戶操作（鼠標點擊、輸入、回車）開始到系統（客戶機、網絡、服務器）響應從而用戶能繼續這個過程所經過的時間。這些等待時間定義了應用程序的“響應度”。該指數是基于應用程序響應度的三個方面：
* 滿意:用戶充分工作。這就是目標時間（T秒），即在此時間里用戶的工作沒有因應用程序的響應時間而受阻，如3秒。
* 容忍:用戶感覺到響應滯后，響應時間大于 T，但能繼續這個過程，如3～12秒。
* 挫折:響應時間大于 F 秒的性能是不能接受的，用戶可能放棄這個過程。F 等于 T×4，在本例子中為12秒。
### 網站性能
針對網站性能優化領域，網上已經有相當多的總結，這里只羅列一些常見（我用過）的策略。
##### 減少 HTTP 請求
從網上查找的情況分類來看，有下面的一些情況：
* 合并 JavaScript 和 CSS。只是這種方式需要好好評估，因為合并過多的 JavaScript，可能會導致 JavaScript 文件過大。一個大的文件將增加 Load時間，導致不好的用戶體驗。
* CSS Sprites。即將一個頁面涉及到的所有零星圖片都包含到一張大圖中去。值得注意的是，像 Logo 這一類文件將不要加到里面去了。
* 拆分初始化負載。將頁面加載時需要的一堆 JavaScript 文件，分成兩部分：渲染頁面所必需的和其他的。頁面初始化時，只加載必須的，其余的等會加載。
* 劃分主域。將資源劃分的請求劃分到幾個不同的域上，來加速資源請求。
對于我這樣的懶人來說，我使用 Google 出品的?[PageSpeed](https://developers.google.com/speed/pagespeed/?hl=zh-CN)。它主要的功能是針對前端頁面而進行服務器端的優化，對前端設計人員來說，可以省去優化 css、js 以及圖片的過程。它可以對 CSS 和 JavaScript 壓縮、合并、級聯、內聯，生成一個新的 Script 和 CSS 文件 。還有圖像優化：剝離元數據、動態調整，重新壓縮，如針對 Chrome 瀏覽器生成 WebP 文件。還可以推遲圖像和 JavaScript 加載。
#### 頁面內部優化
HTML 頁面內的優化的目的便是：**盡快渲染出頁面**。常見的優化策略便是：
* 將 CSS 放在頂部，即早點渲染出頁面及其樣式。
* 將 JavaScript 放在底部。如果有后臺渲染機制，那么就應該將 JS 放到頁面底部來加速頁面加載。如果是單頁面應用，那么這個 JS 就應該在頁面頂部。
* 壓縮 HTML。在我們寫模板的過程中，一些判斷可能會導致頁面有過多的空格。壓縮這些 HTML，可以稍微提高一下頁面速度。
這里的大部分內容都應該通過修改代碼來完成。
#### 啟用緩存
前面的緩存一節里，我們說過了一些緩存的策略，我們再稍微提一下。
* 后臺優化，如數據庫端緩存
* 啟用頁面緩存，即應用層緩存
#### 減少下載量
簡單地來說，就是減少對服務器的請求：
* 使用 CDN
* 使用外部 JavaScript 和 CSS
* 緩存：使用 gzip 壓縮、添加 Expires 頭、配置 ETag、使 AjaX 可緩存
#### 網絡連接上的優化
主要就是對域名到服務器進行優化，因此從方法上有：
* DNS 域名解析加速
* 減少 DNS 查找
## SEO
> 這是一個老的，有些過時確非常普遍，甚至每一個程序員都知道的關于搜索引擎優化的技術，所以，我只一筆帶過。
**搜索時發生什么了?**
* 用戶輸入查詢內容
* 查詢處理以及分詞技術
* 確定搜索意圖及返回相關、新鮮的內容
search-engine-arch
**為什么需要 SEO?**
這是一個有趣的問題，答案是`為網站帶來更多的流量`。
### 爬蟲與索引
我們先看看來自谷歌的爬蟲工作的一點內容
> 抓取是 Googlebot 發現新網頁并更新這些網頁以將網頁添加到 Google 索引中的過程。
> 我們使用許多計算機來獲取（或“抓取”）網站上的大量網頁。執行獲取任務的程序叫做 Googlebot（也被稱為漫游器或信息采集軟件）。Googlebot 使用算法來進行抓取：計算機程序會確定要抓取的網站、抓取頻率以及從每個網站中獲取的網頁數量。
> Google 的抓取過程是根據網頁網址的列表進行的，該列表是在之前進行的抓取過程中形成的，且隨著網站管理員所提供的站點地圖數據不斷進行擴充。Googlebot 在訪問每個網站時，會檢測每個網頁上的鏈接，并將這些鏈接添加到它要抓取的網頁列表中。新建立的網站、對現有網站所進行的更改以及無效鏈接都會被記錄下來，并用于更新 Google 索引。
也就是如原文所說:
> 谷歌的爬蟲(又或者說蜘蛛)能夠抓取你整個網站索引的所有頁。
**為什么谷歌上可以搜索整個互聯網的內容**？因為，他解析并存儲了。而更有意思的是，他會為同樣的內容建立一個索引或者說分類，按照一定的相關性，針對于某個關鍵詞的內容。
PageRank 對于一個網站來說是相當重要的，只是這個相比也比較復雜。包括其他網站鏈接向你的網站，以及流量，當然還有域名等等。
### 什么樣的網站需要 SEO？
下圖是我的博客的流量來源
What Site Need SEO
正常情況下除了像`騰訊`這類的`QQ空間`自我封閉的網站外都需要 SEO，或者不希望泄露一些用戶隱私如`Facebook`、`人人`等等。
* 如果你和我的網站一樣需要靠搜索帶來流量
* 如果你的網站只有很少的用戶訪問，卻有很多的內容。
* 如果你的網站為一個公司、企業工作以帶來業務。
* 。。。
**SEO 與編程的不同之處?**
SEO 與編程的最大不同之處在于:?**編程的核心是技術，SEO 的核心是內容**。
內容才是 SEO 最重要的組成部分，這也就是騰訊復制不了的東西。
### SEO 基礎知識
**確保網站是可以被索引的**
一些常見的頁面不能被訪問的原因
* 隱藏在需要提交的表格中的鏈接
* 不能解析的 JavaScript 腳本中的鏈接
* Flash、Java 和其他插件中的鏈接
* PowerPoint 和 PDF 文件中的鏈接
* 指向被 meta Robtots 標簽、rel=“NoFollow” 和 robots.txt 屏蔽的頁面的鏈接
* 頁面上有上幾百個鏈接
* frame（框架結構）和 iframe 里的鏈接
對于現在的網站來還有下面的原因，通過來說是因為內容是動態生成的，而不是靜態的
* 網站通過 WebSocket 的方法渲染內容
* 使用諸如 Mustache 之類的 JS 模板引擎
**什么樣的網頁可以被索引**
* 確保頁面可以在沒有 JavaScript 下能被渲染。對于現在 JavaScript 語言的使用越來越多的情況下，在使用 JS 模板引擎的時候也應該注意這樣的問題。
* 在用戶禁用了 JavaScript 的情況下，保證所有的鏈接和頁面是可以訪問的。
* 確保爬蟲可以看到所有的內容。那些用 JS 動態加載出來的對于爬蟲來說是不友好的
* 使用描述性的錨文本的網頁
* 限制的頁面上的鏈接數量。除去一些分類網站、導航網站之類有固定流量，要不容易被認為垃圾網站。
* 確保頁面能被索引。有一指向它的 URL
* URL 應該遵循最佳實踐。如 blog/how-to-driver 有更好的可讀性
**在正確的地方使用正確的關鍵詞**
* 把關鍵詞放 URL 中
* 關鍵詞應該是頁面的標簽
* 帶有 H1 標簽
* 圖片文件名、ALT 屬性帶有關鍵詞。
* 頁面文字
* 加粗文字
* Descripiton 標簽
### 內容
對于技術博客而言，內容才是最需要考慮的因素。
可以考慮一下這篇文章，雖然其主題是以 SEO 為主?[用戶體驗與網站內容](http://www.phodal.com/blog/user-experience-writing-web-content/)
不可忽略的一些因素是內容才是最優質的部分，沒有內容一切 SEO 都是無意義的。
#### 復制內容問題
一個以用戶角度考慮的問題:?**用戶需要看到多元化的搜索結果**
所以對于搜索引擎來說，復制帶來的結果：
* 搜索引擎爬蟲對每個網站都有設定的爬行預算，每一次爬行都只能爬行 trpgr 頁面數
* 連向復制內容頁面的鏈接也浪費了它們的鏈接權重。
* 沒有一個搜索引擎詳細解釋他們的算法怎樣選擇顯示頁面的哪個版本。
于是上文說到的作者給了下面的這些建議:
> 避免從網上復制的內容（除非你有很多其他的內容匯總，以使它看起來不同 - 我們做頭條，對我們的產品頁面的新聞片段的方式） 。這當然強烈適用于在自己的網站頁面以及。內容重復可以混淆搜索引擎哪些頁面是權威（它也可能會導致罰款，如果你只是復制粘貼別人的內容也行） ，然后你可以有你自己的網頁互相競爭排名！
> 如果你必須有重復的內容，利用相對=規范，讓搜索引擎知道哪個 URL 是一個他們應該被視為權威。但是，如果你的頁面是另一個在網絡上找到一個副本？那么開始想出一些策略來增加更多的文字和信息來區分你的網頁，因為這樣重復的內容是決不可能得到好的排名。
——待續。
#### 保持更新
谷歌對于一個一直在更新的博客來說會有一個好的排名，當然只是相對的。
對于一個技術博客作者來說，一直更新的好處不僅可以讓我們不斷地學習更多的內容。也可以保持一個良好的習慣，而對于企業來說更是如此。如果我們每天去更新我們的博客，那么搜索引擎對于我們網站的收錄也會變得越來越加頻繁。那么，對于我們的排名及點擊量來說也算是一個好事，當我們可以獲得足夠的排名靠前時，我們的 PR 值也在不斷地提高。
更多內容可以參考:[Google Fresh Factor](http://www.seomoz.org/blog/google-fresh-factor)
#### 網站速度
> 谷歌曾表示在他們的算法頁面加載速度問題，所以一定要確保你已經調整您的網站，都服從最佳做法，以使事情迅速
過去的一個月里，我試著提高自己的網站的速度，有一個相對好的速度，但是受限于`域名解析速度`以及?`VPS`。
[網站速度分析與 traceroute](http://www.phodal.com/blog/use-traceroute-analyse-person-homepage-speed/)
[UX 與網站速度優化——博客速度優化小記](http://www.phodal.com/blog/ux-and-improve-website-load-speed/)
[Nginx ngx_pagespeed nginx 前端優化模塊編譯](http://www.phodal.com/blog/nginx-with-ngx-pagespeed-module-improve-website-cache/)
#### 保持耐心
> 這是有道理的，如果你需要考慮谷歌機器人抓取最新的頁面并處理和更新與新內容對應的索引的時間因素。
> 而這可能是相當長一段時間，尤其是當你正在處理 PB 級的內容時。
SEO 是一個長期的過程，很少有網站可以在短期內有一個很好的位置，除非是一個熱門的網站，然而在它被發現之前也會一個過程。
#### 流量
在某種意義上，這個是提高 PR 值，及網站流量的另外一個核心，除了內容以外的核心。
* 流量引導是 SEO 的基礎部分。除非你有一個異常強大的品牌，不需要干什么就能吸引到流量。
* 流量引導永不停止。這是不間斷營銷網站的過程。
關于流量的內容有太多，而且當前沒有一個好的方法獲取流量，雖然在我的網站已經有了。
Links to Your Site
Total links
`5,880`
> 同時引導更多的流量和更有利更相關的流量的帶來的幫助一樣多。如果你有你的內容的分銷合作伙伴，或者你建立一個小工具，或其他任何人都會把流量引導回你的網站上 - 你可以通過確保各個環節都有最佳的關鍵字錨文本從而大大提高搜索的相關性。您還應該確保所有流量到您的網站指向你的主域名（ http://www.yourdomain.com ，像 http://widget.yourdomain.com 不是一個主域名） 。另外，你要盡可能多的聯系，以包含適當的替代文字。你的想法。
> 另外，也許不太明顯的方式，建立鏈接（或者至少流量）是使用社交媒體 - 所以設置你的 Facebook ，Twitter 和谷歌，每當你有新的鏈接一定要分享。這些通道也可以作為一個有效的渠道，推動更多的流量到您的網站。
由社交渠道帶來的流量在現在已經越來越重要了，對于一些以內容為主導的網站，而且處于發展初期，可以迅速帶來流量。一些更簡單的辦法就是交換鏈接，總之這個話題有些沉重，可能會帶來一些負面的影響，如黑帽 SEO。。。。
**參考來源**:
《SEO 藝術》(The Art of SEO)
## UX 入門
用戶體驗設計（英語：User Experience Design），是以用戶為中心的一種設計手段，以用戶需求為目標而進行的設計。設計過程注重以用戶為中心，用戶體驗的概念從開發的最早期就開始進入整個流程，并貫穿始終。其目的就是保證：
* 對用戶體驗有正確的預估
* 認識用戶的真實期望和目的
* 在功能核心還能夠以低廉成本加以修改的時候對設計進行修正
* 保證功能核心同人機界面之間的協調工作，減少 BUG。
關于 UX 的定義我覺得在知乎上的回答似乎太簡單了，于是在網上尋尋覓覓終于找到了一個比較接近于答案的回答。原文是在:?[Defining UX](http://deviseconsulting.com/defining-ux/)，這又是一篇不是翻譯的翻譯。
### 什么是 UX
用戶體驗設計（英語：User Experience Design），是以用戶為中心的一種設計手段，以用戶需求為目標而進行的設計。設計過程注重以用戶為中心，用戶體驗的概念從開發的最早期就開始進入整個流程，并貫穿始終。其目的就是保證：
* 對用戶體驗有正確的預估
* 認識用戶的真實期望和目的
* 在功能核心還能夠以低廉成本加以修改的時候對設計進行修正
* 保證功能核心同人機界面之間的協調工作，減少BUG。
**UX 需要什么**
從下圖中我們可以看到一些 UX 所需要的知識體系：
UX
即
* 信息構架
* 構架
* 工業設計
* 人為因素 (人因學)
* 聲音設計 (網頁設計中比較少)
* 人機交互
* 可視化設計
* 內容 (文字,視頻,聲音)
交互設計便是`用戶體驗設計的重點`。我們再來看看另外的這張圖片
Fields Of User Experience Design
### 什么是簡單？
一個好的軟件應該是簡單的，并且是令人愉快的。
在不同的 UX 書籍里，似乎就會說到【簡約至上】。簡單就是“單純清楚、不復雜”。而這里的簡單并不僅僅只是不復雜那么簡單。對于一個軟件來說，簡單實際上是你一下子就能找到你想要的東西，如：
Search Phodal
而我們并不可能在一開始就得到這樣的結果，這需要一個復雜的過程。而在這個過程開始之前，我們一定要知道的一點是：我們的用戶到底需要什么?
如果我們無法知道這一點，而只是一直在假想客戶需要什么，那么這會變成一條死路。
接著在找尋的過程中，發現了一個有意思的圖，即精益畫布：
Lean
首先，我們需要知道幾個用戶而存在的問題——即客戶最需要解決的三個問題。并且針對三個問題提出對應的解決方案，這也就是產品的主要功能。
那么，這兩點結合起來對于用戶來說就是簡單——這個軟件能解決客戶存在的主要問題。
如果我們可以完成這部分功能的話，那么這就算得上是一個有用的軟件。
### 進階
而實際上有用則是位于用戶體驗的最底層，如下圖所示：
UX
這時候就需要盡量往可用靠攏。怎樣對兩者進行一個簡單的劃分？
下圖就是實用的軟件：
IE Alert
而下圖就便好一點了：
jQuery Popup
要達到可用的級別，并不是一件困難的事：**遵循現有軟件的模式**。
換句話說，這時候你需要的是一本?**Cookbook**。這本?**Cookbook**?上面就會列出諸多現有的設計模式，只需要參考便使用就差不多了。
同樣的，我便嘗試用《移動應用 UI 設計模式》一本書對我原有的軟件進行了一些設計，發現它真的可以達到這樣的地步。
而這也類似于在編程中的設計模式，遵循模式可以創造出不錯的軟件。
### 用戶體驗要素
盡管對于這方面沒有非常好的認識，但是還是讓我們來看看我們現在可以到哪種程度。如在一開始所說的，我們需要滿足用戶的需求，這就是我們的目標：
用戶體驗要素
而在最上面的視覺設計則需要更專業的人來設計。
**參考目錄**
* 《怦然心動——情感化設計交互指南》
* 《用戶體驗要素》
* 《移動應用UI設計模式》
## 認知設計
第一次意識到這本書很有用的時候，是我在策劃一個視頻。第二次，則是我在計劃寫一本書的時候。
### 流
在《認知設計》一書中，提到了下面的學習體驗，即“流” (Flow)。而在我們學習的過程中，我們也會有類似的學習過程。
Learn Design
如在早期我學習 Emacs 和 GNU/Linux 的時候，也曾經放棄過，雖然在當時我已經讀過 Linux 內核。然而，在應用之前進行理論學習并沒有卵用。
通常我們會有類似于下面的學習體驗，對于一本書來說有下面的體驗似乎也是一件很不錯的事:
1. 在最開始學習的時候，我們需要一點理論基礎，以及我們需要學點什么。
2. 然后，我們需要構建一個簡單可用的系統，以獲取信心。如果我們在這一步沒有想象中，那么簡單，那么我們可能會放棄學習。或者等到某個時期成熟的時刻，如在我開始學習《設計模式》的時候，那么本書的高度太高了。直到有一天，我了解到了一本叫《Head First 設計模式》的書，才重新把 GoF 的書看了一遍，發現其實也沒有想象中的難。
3. 接著在我完成了某個功能之后，那么我可能繼續學習某個理論，用于支撐我的下一步計劃。
4. 在那之后，我覺得這一步可能也不是那么難，因為已經有了前面的基礎。如果在一步失敗的時候，那么我們可能會繼續尋找某些可靠的方案，又或者是理論支撐。
5. 。。。
6. 直到有一天，我們來到了一個瓶頸的前面，現有的方案已經不滿足我們的需求。對于這個問題，我們可能已經沒有一個更好的解決方案。于是，我們可能就需要創建一個輪子，只是在這時，我們不知道怎樣去造輪子。
7. 于是我們開始學習造輪子。
8. ….
只有當我們保持一個學習的過程，才會讓我們在這一步步的計劃中不會退縮，也不能退縮。
