產品設計的過程，會經歷三個階段：可用，好用，用的爽。
產品的可用性，就像一個原始的瓢一樣，可以拿來勺水，但是並不好用。後來在一代代人的改進中，給瓢加了一個把柄，人使用瓢變得更加的方便，這就是從可用到好用的進程。
1. 需求分析的過程
構建產品設計可用的過程，就是需求分析的過程，需求分析的過程產生需求說明書。
需求分析的過程，將梳理清楚業務需求，用戶需求，並推導出軟件需求。
例如：某城市由政府帶領，公安部門牽頭，完成城市的房屋、人口、以及單位信息採集，爲城市精細化治理建立基礎。這是一個業務需求。
而需要參與到信息採集過程的部門主要有：市政府相關工作人員，公安部門相關工作人員，以及各村網格員。他們需要做的事情，就是用戶需求（5W1H）。
例如市政府人員需要發佈數據採集任務，網格員需要到線下進行數據採集工作；數據管理員需要配合進行採集數據數量，質量等的管理工作。這些，都屬於用戶需求。
在用戶需求確定了之後，我們要識別用戶需求哪些是由系統完成的，進行詳細的需求分析，並進行需求建模，構建可供開發使用的實實在在的軟件系統。
例如，我們可能在系統的最初階段，基於資金的短缺，只選擇提供線上數據採集系統，輔助其中最核心，最多工作量的用戶需求：網格員進行數據採集工作。
所以不是所有的業務需求，都會轉化爲軟件需求，需要根據當時的業務目標，用戶需求，以及資源條件等來決定哪些需求會納入軟件需求。
而需求分析的最後，將進行系統建模，確定如下內容：
- 軟件目標
2. 建設內容範圍
3. 系統環境上下文
4. 利益涉衆
5. 系統使用用戶
6. 系統活動圖
7. 用例圖
8. 用例規約
這些系統建模的要素，將作爲需求規格說明書的核心內容。
而需求規格說明書，將作爲系統架構師的系統構建輸入條件，完成系統架構的設計。
由系統內容範圍，構建系統大功能模塊
由系統使用用戶，以及系統活動圖，構建系統類對象
由系統用例規約的業務流程，構建系統數據流轉方式
由系統的上下文環境，以及其他的內容，綜合構建系統技術架構，劃分應用層，平臺層，數據層等，按照不同系統類型做不同的架構層次劃分。
在這裏我們可以看下軟件系統開發的發展歷程，其實，一開始是沒有軟件產品設計人員的角色存在的。都是需求確定了，有需求文檔，開發就可以開發了。而開發出來的軟件，往往按照程序設計的方式進行構建，雖然能滿足用戶的實際需求，但是不包好用。就像插座廠商做出來的家用插座，給你提供兩孔的插座位，也給你提供三孔插座位，但是，你用了兩孔的，三孔的就沒法插進去。用了三孔的，兩孔的就沒有辦法插進去一樣彆扭。
軟件需求說明書，只定義了“可用的產品”，但是它沒有從用戶的使用體驗的角度上來構建“好用，用的爽”的產品。
所以在需求分析之後，我們需要進行產品的“用戶體驗設計”，構建產品“好用，用的爽”的過程。而這個過程也將輸出產品交互原型，以及產品界面視覺。