許我們經常會碰到這么一副畫面：很多產品經理在梳理好了產品架構的腦圖之后，都會火急火燎打開原型設計工具Axure，開始進行原型設計工作去了。三下五除二就基本將產品線框圖給畫完了，然后就屁顛屁顛地跑去和研發工程師過需求，討論的時候會發現：不是這里有個小問題，就是那里有個邏輯沒想明白，整理整理返工，結果下一次又發現有一個流程沒有考慮清楚，這樣來回反復幾次才能將一個產品需求和原型界面給討論清楚。

其實，這樣的場景出現的頻率還比較高。想想自己第一次去和公司開發溝通的時候，也是碰到了這樣的情況，被開發噴這里邏輯不對，那里漏了一種分支情況的思考，當時那個囧啊，真想找個地縫鉆進去。后來才知道，在設計原型之前，其實還少了一個關鍵的步驟，那就是確定產品的業務流程，梳理產品的流程圖。

什么是流程圖

從字面來理解，流程圖＝流程＋圖。流程，是指特定主體為了滿足特定需求而進行的有特定邏輯關系的一系列操作過程；而圖呢，就是將這些流程進行顯性化和書面化的一種表達。

流程圖有時也稱作輸入-輸出圖，某種程度上來說，流程圖是一種溝通性質的圖形化語言。一般會使用一些標準符號代表某些類型的動作，如判斷用菱形框表示，具體的操作行為、活動用方框表示，開始和結束用圓角矩形框表示。

但比這些符號規定更重要的，是必須清楚地描述產品業務流程的順序及使用邏輯。從產品經理的角度來理解，流程圖其實就是一個用戶使用產品的過程，基本的三要素是“從哪進—做什么—從哪走”。比如用戶打開一個電商APP，會有這樣一個使用產品的過程：

「搜索商品」→「查看商品詳情頁」→「加入購物車」→「生成訂單」→「開始支付」，以及支付之后的「確認收貨」

用戶從電商商城的首頁進入，通過搜索來找到自己想要購買的商品，了解后將其加入購物車，購買了自己想要的商品，支付結束后便離開APP，待收到商品后又回到APP進行確認收貨。

可以看出，只要產品用戶在使用我們產品的過程中有其自身的目標和任務，產品流程就會存在。產品經理要做的，就是通過一系列步驟完成任務和流程的梳理，最終目的是幫助用戶，完成核心任務。

而且制作產品流程圖不僅可以幫助產品經理梳理、完善用戶操作使用流程，還能有效降低團隊成員間的溝通成本。在實際的工作中，產品經理需要向很多人（尤其是開發人員）描述產品需求和原型界面，借助可視化的流程圖，溝通的效率會提高很多，畢竟一份步驟清晰的流程圖要比一大段文字直觀易懂得多。

常見的流程圖分類有兩種，一種是業務流程圖（Transaction Flow）, 一種是頁面流程圖（Page Flow）。

對于產品經理來說，用的比較多的自然是業務流程圖，頁面流程圖一般是設計師那邊使用比較頻繁。在工作中，我們經常能夠看到兩種業務流程圖，一種是單純的用戶操作行為流程圖，這種流程圖往往只涉及一種用戶角色，不需要進行跨部門或者跨功能完成某項任務，如下圖所示：

另一種則很好區分，俗稱為“泳道圖”，在樣子上也挺像游泳池里的泳道，可以有橫向的泳道，也會有縱向的泳道。泳道圖在某些文檔里會被稱為“以活動為單位的流程圖”，浮在泳道中的都是一個個活動。泳道圖是處理多角色、多系統、多模塊的復雜需求的最好方法，它的本質就是希望可以通過角色、系統、模塊的劃分將復雜的功能梳理切割清晰，因此多模塊之間的關聯盡可能單一，實際中也很少存在多聯系線條的情況，因此如果泳道之間多條關聯，最好自己反思下是不是之前的功能模塊架構切割的不太合理，導致繪制出來的圖不夠簡潔。

如何確定產品流程

講完了基礎的東西，接下來我們來梳理下，該如何確定產品的流程。

首先我們要設計的是產品的核心功能流程，也就是用戶的核心使用路徑。拿微博進行舉例，微博用戶的核心操作路徑是這樣的：

• 路徑一：登錄微博——查看微博動態－－轉發、點贊、評論微博
• 路徑二：登錄微博－－發表自己的微博－－查看私信，回復微博評論

這是微博用戶最常有的兩種操作行為，所以你會發現：所謂產品的核心功能流程，就是一個產品對用戶產生的價值，用戶要感知到這個價值需要完成的最簡操作步驟。微博這個產品對用戶來說，最大的價值無非就是兩個方面，一個是可以碎片化地瀏覽資訊，一個是可以碎片化地發表自己的動態信息。用戶要感知到這兩個價值，就必然要做出上述的一系列操作流程和步驟。

所以，在確定產品的主干流程的時候，需要先弄清楚產品的價值到底體現在哪里，用戶要完成對這個產品價值的感知，需要付出哪些行為。通過這樣一個簡單的分析，我們就能得出產品的主流程了。

當然，這里輸出的產品主流程，只是一個產品的整體使用流程，具體到某一個功能如何進行操作使用，就需要花費更多的精力去進行細化分解。

那對于某個功能的產品操作流程梳理，我們又具體怎么來做呢？

我建議可以從下面3步著手。

1. 業務調研

如果你是在梳理一個簡單的功能操作流程，或者已經比較通用成熟的產品流程，那么只需要好好研究幾款產品，就可以知道常規的流程是什么樣的，典型如產品的注冊登錄流程；但如果是梳理一個全新的業務功能流程，尤其是設計企業內部支撐系統的時候，就需要對相關業務進行系統的調研了。

其實調研的過程，倒是和我們小時候寫記敘文有點相似，無非就是要解決who，what，why，how，以及where的問題：誰，在什么情況下，做了什么事情，這個事情需要什么前置條件，又輸出了什么，這個事情在哪里完成的？基本上只要我們深入到業務環境里去，和業務相關人員好好溝通交流，搞明白這幾個問題也不是什么難事。然后把調研結果做一個完整記錄，我們的調研就可以算是圓滿完成了。

舉個例子：假設你老板派你去調研一個商業地產開發商的業務流程，調研的目標是為了給他們提供商鋪和業主管理系統。

那么在調研中：

1. 首先可以要求精通業務流程的人給你系統講解一遍
2. 調研具體操作的人，來驗證他給你講解的是否全面和是否存在偏差
3. 實地觀察和記錄，可以花點時間走遍整個業務流程，了解各個細節

這里提供的三種方式可以相互結合使用。第一種方法可以讓你首先建立一個全局觀，了解業務的整體運行邏輯，但對于業務細節問題則不能那么深入。第二種方法比較依賴于問題的質量以及問問題的場景，這就要求我們在提問之前就做好充分的準備工作，有很多結論的不正確其實是因為問錯了人或者問問題的方法不對。第三種方法的存在，就是為了在觀察中再進行驗證。

2. 梳理與呈現

做好了調研工作后，我們就該立即對調研結果進行整理。

首先，明確你要梳理的業務流程的范圍，具體是包含哪幾個功能模塊，涉及到哪些用戶角色，這個時候可以先使用一些關鍵節點，弄一份該業務流程的主干流程圖出來；

接下來，就是對上面這個粗的流程圖進行分解，好比去拆解一個金字塔，層層分解下去，直到不能分解為止；

最后，就是用流程圖將其給畫出來，通常來說，會有三種結構的流程圖出現——順序結構、選擇結構、循環結構。

3. 評審與確認

一份流程圖能否通過評審，關鍵是看其能否真正反映現實中的業務，評審主要是讓業務部門和開發部門參與，如果都覺得沒有問題，那么恭喜你，你的流程算是過關了。這里稍微要強調的是，好的流程圖具備怎樣的一些特征，大致歸納起來如下：

• 清晰易懂：整個流程圖結構清晰，讓瀏覽流程圖的人一眼便能看懂主體流程是怎樣的，這也體現了為什么要使用標準化的流程圖圖示語言來進行描繪的用處了；
• 簡單明了：流程圖存在的本身意義，就是為了將復雜的東西簡單化。如果流程圖上面密密麻麻地堆了一堆，可想而知是怎樣的一種閱讀體驗；
• 完整準確：這就要求產品經理能夠考慮到各種情況和邏輯判斷，梳理流程圖的過程，其實也是一個查漏補缺的過程，評審的意義也在于此，找出有錯誤的地方，大家一起來完善流程圖；

上面說的這三個步驟方法，比較偏向于做后臺業務功能的流程梳理和調研，其實對于to c 類的產品來說，方法都是通用的，只不過調研業務部門換成了調研用戶，只有更了解用戶的操作行為、習慣、心理預期才能做出更好的流程設計。

流程圖的繪制工具

制作流程圖的工具有很多種，比如，Visio、Axure、Smartdraw、Omnigraffle（Mac）等等，產品經理只需要選擇一款適合自己的工具即可。

這里介紹幾個常用工具。

1. Visio

Visio是微軟推出的一款流程圖制作工具，也是目前產品經理最常用的一款流程圖工具。通過Visio可以方便、快速地把業務流程、系統實現流程畫出來。它本身有很多的組件庫，可以很方便的完成各類流程圖、結構圖和網絡圖的制作。Visio的另一個特色功能在于它有非常豐富的自帶模板。

2. Omnigraffle（Mac）

OmniGraffle是由The Omni Group制作的一款繪圖軟件，其只能于運行在蘋果電腦和iPad平臺之上。個人感覺在很多方面，OmniGraffle都類似于微軟的Visio，不過繪制出來的任何圖表不知為何總會覺得很美，有Mac電腦的產品經理可以下載軟件試試。

3. ProcessOn（支持在線協作）

ProcessOn 是一款網頁版的在線作圖工具，用戶只需要有一個瀏覽器即可制作思維導圖、流程圖、UML圖、界面原型設計、組織結構圖等等。這款工具上手非常容易，而且免費，更重要的是省去了安裝、授權等各種付費軟件的煩惱。作為一款用 HTML5 開發的在線網頁版作圖工具，ProcessOn一個很大的特色就是可以做到無延遲協作，方便兩個或多個人同時對一個文件協作編輯和溝通，對創業團隊或者企業辦公小組來說，是一款簡單易用的工具。

其它常見的圖——時序圖、狀態圖

有時候光有流程圖，還不能夠準確完整地表達清楚業務邏輯和產品需求，這個時候就需要借助時序圖和狀態圖來完成相關的補充說明了。

流程圖、時序圖、狀態圖都可統稱為UML圖，那什么是UML呢？先來看看百科是怎么解釋的：

Unified Modeling Language (UML)又稱統一建模語言或標準建模語言，是始于1997年一個OMG標準，它是一個支持模型化和軟件系統開發的圖形化語言，為軟件開發的所有階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。 面向對象的分析與設計(OOA&D，OOAD)方法的發展在80年代末至90年代中出現了一個高潮，UML是這個高潮的產物。它不僅統一了Booch、Rumbaugh和Jacobson的表示方法，而且對其作了進一步的發展，并最終統一為大眾所接受的標準建模語言。

是不是看不太懂？看不懂才是正常的表現，因為這是面向對象軟件的標準化建模語言，簡單地說就是一種有特殊用途的語言。

大家有空可以參考《UML基礎、案例與應用》詳細了解下。

這里就給大家介紹兩種常見的圖，一種叫時序圖，一種叫狀態圖。介紹這兩種圖之前，我們先說下什么是對象，什么是類的定義嗎？類就是一類事物的總稱，那對象呢？對象就是這類事物中的個體，比如手機類，蘋果手機就是手機類的一個對象。

1. 時序圖

時序圖顯示對象之間的動態合作關系，它強調的是對象之間消息發送的順序，同時顯示對象之間的交互。時序圖的一個用途是用來表示用例中的行為順序。當執行一個用例行為的時候，時序圖中的每條消息對應了一個類操作或引起狀態轉換的觸發事件，如下圖所示是一個ATM 用戶成功登陸的時序圖：

在 UML 中，時序圖表示為一個二維的關系圖，其中，縱軸是時間軸，時間延豎線向下延伸。橫軸代表在協作中各個獨立的對象。當對象存在時，生命線用一條虛線表示，消息用從一個對象的生命線到另一個對象的生命線的箭頭表示，箭頭以時間的順序在圖中上下排列。

2. 狀態圖

所謂狀態圖，就是用來描述一個對象的可能狀態以及各個狀態之間的轉換關系的一種圖。

上圖就是典型的狀態圖，一本圖書經過不同的觸發行為或滿足一定的條件，就變成了不同的狀態，我們在產品設計的過程中，也會經常碰到這樣的情況需要用狀態圖去表示。

熟悉了這么多種流程圖，算是為后面的原型設計打下了堅實的基礎，下一篇我們來講具體如何做產品的原型設計。

作者：壹百度（微信公眾號：倒退集），在線教育企業服務領域產品經理，創業公司Team Leader。常常自詡是文藝青年和極客青年的結合體，在宅與不宅之間可以自由切換，曾主導多款重量級產品的產品策劃和設計工作。

本文由 @壹百度 原創發布于人人都是產品經理。未經許可，禁止轉載。

他信息

訂單狀態頁面是一項新功能，仍在開發中。可在下面找到一些關于該功能的狀態的信息，以及我們近期計劃的功能改進。

——受支持的運輸承運人

——不受支持的承運人

——有多個貨件或承運人的訂單（部分發貨）

——向訂單狀態頁面添加備注或消息

——客戶隱私

受支持的運輸承運人

目前，完全支持新訂單狀態頁面的發貨承運人只有 USPS、UPS、FedEx 和加拿大郵政。

通過受支持的承運人發送的貨件的訂單狀態頁面包括會實時更新的運輸地圖。

不受支持的承運人

訂單狀態頁面尚不完全支持除 USPS、UPS、FedEx、DHL Express 和加拿大郵政以外的任何承運商。但是，您仍應更新您的電子郵件模板，并繼續為訂單發貨添加運單號，以便客戶收到 order status URL。

在訂單狀態頁面上，通過不受支持的承運人發貨的訂單仍然會顯示一個運單號，此編號會鏈接到運輸承運人的網站，客戶可以在此網站上獲取有關訂單狀態的更多信息。

與受支持的承運人不同，通過不受支持的承運人發貨時，不會顯示訂單狀態，地圖上的圖釘標記也不會實時更新。

有多個貨件或承運人的訂單（部分發貨）

訂單狀態頁面支持部分發貨或通過多次發貨來發貨的訂單。Shopify 將在訂單狀態頁面上創建包含運單號和內容的第二個訂單狀態部分。

我們支持部分發貨，即使它們是通過不同的運輸承運人完成的。

添加備注或消息

您可以使用 JavaScript 對象將內容框添加到結賬的訂單狀態頁面。

如果按照我們的指南操作，則只需知曉一些 HTML 即可在訂單狀態頁面中添加內容，例如備注或消息。

客戶隱私

盡管轉至訂單狀態頁面的鏈接似乎是可以公開訪問的 URL，但客戶的郵寄地址是安全的，并且對其他任何人均不可見。

當有人通過不同于用來完成結賬的設備的其他設備訪問訂單狀態頁面時，需要他們進行登錄來確保客戶信息的安全。若要訪問此頁面，客戶需要兩個憑據：

訂單號（他們可以在他們的電子郵件中檢索），以及用于完成結賬的電子郵件地址。（來源：Shopify）

以上內容屬作者個人觀點，不代表雨果網立場！如有侵權，請聯系我們。

相關鏈接：Shopify自定義訂單狀態頁面：Shopify后臺訂單頁面怎么查看客戶訂單的狀態？