根據功能模塊后臺數據的觸發次數，可以看出，用戶主要用此APP進行收貨、發貨操作。

細細分析每個模塊的功能：

1.收貨，顯示任務總數和已收貨情況，針對此頁面共有如下問題

a ?任務總數的定義是什么？是否為當日任務總數？還是歷史一個月的？表達不清晰，容易有歧義；

b ?點擊確認收貨，提示要先選擇一個訂單，但當前頁面并無訂單，還需要一個個手動輸入進去。現實中是否有批量收貨的情景呢？

c ? 腦補下現實情景，承運商每天必做操作就是收貨的動作，收貨首先需要有一個待收貨的列表清單。所以待收貨任務是承運商在收貨頁面最關心的；

d ? APP登錄不在首頁或頁面上很容易找到的位置，藏在每個功能模塊的右上角，登錄入口不統一；

e ? 上級承運商是否發貨，與本級承運商是否收貨，應該是訂單狀態，屬于訂單詳情，放在收貨里不合適；

f. ? 條形碼掃描可參考京牛，用戶體驗更好；

g. ?收貨頁面返回操作反應遲鈍，有時需要連按三下，才能返回，有待優化；

2. 查看待收貨

待收貨訂單詳情列表展示，需要確定一個承運商一般會有多少條待收貨訂單，以確定此頁面如何設計更科學

a ?上級承運商有抬頭卻無內容顯示；

b ?頂部導航欄下方還有承運商一欄，但點擊無其他選項，此處設置如同雞肋；

c ?點擊進入訂單詳情，卻沒有確認收貨的按鈕；

d ?此處獨立待收貨，與“收貨”頁面里的全部待收貨功能重復；

3、發貨

? ? 此模塊已經展示了所有待發貨的訂單列表，操作明確清晰，快捷方便。

4. 收貨取消申請

腦補現實場景，在收貨的時候，發現問題商品，需要提出拒絕收貨的申請，此時在當前收貨頁面添加取消收貨的申請最方便，但單獨列出，則承運商需要把壞的商品扔到一邊，最后統一進行取消申請，或者跳出當前收貨頁面，發現一單問題單取消一個，兩者都沒有直接在當前頁面申請取消體驗好；

5.? 收貨取消確認

當有下級承運商提拒收申請后，上級承運商就可看到 ?取消收貨 的申請，并需要進行審核的操作。此處應該設置消息提醒，比如有取消申請時，在首頁版塊顯示消息數量，以便清晰的提醒用戶快速審核；否則，每次都要點進去，才能知道是否有未審核的訂單。

?6. 訂單詳情查詢 與 取件單詳情

? ? ?兩個頁面長的一樣，而且都是相通的，在訂單頁也可以查到取件單詳情，保留一個就可以

7. 取件任務收取、取件單指派配送員

? ? 這兩塊兒流程不太清楚，有待節后回來了解流程；

自我感覺，主菜單頁面給人第一感覺功能版塊太多，看不過來，沒有重點

除去還不太了解的取件和指派配送員模塊外，其他模塊可以組合如下：

1、2、6合并，收貨頁面直接顯示待收貨列表頁，可選擇收貨，或取消收貨；

8、9合并，顯示在導航欄上方

5繼續獨立

僅代表個人觀點，具體還有待熟悉承運商收貨流程及現有使用狀況后，再做抉擇~