UX交付物（二）

ux交付物（一）分析了：

故事（stories）

產品總結（proverbs)

使用者檔案（personas)

場景（scenarios）

內容盤點（content inventories）

here we go！繼續第6-10種ux交付物分析

我們通過對觀察，分析資料可以更真實的，深層次的了解產品。

產品經理很多時候也要負責看資料。不管是自己產品的資料，還是競品的資料都要看。這方面做得真不多，還是介紹幾個我看過比較經典的例子比較實際。

2.【從亞馬遜和京東的送貨資訊看各自的物流體系】作者（一淘的產品經理）通過觀察兩家的電商的送貨模式，推斷各自的物流系統，最後用資料驗證。

【摘抄一段】

光有理論分析是不夠的，還需要資料來支援。我隨機抓取了3906個亞馬遜的商品詳情頁上的送達日期資料，統計結果如下表：

從上表中可以看出，如果亞馬遜承諾在上海可以次日達，那麼就有46%的商品不能按時送達，這個比例太高了。所以，亞馬遜沒有像京東那樣統一承諾自己的送達時效。

【書籍推薦】

資料分析薄弱，就應該多看書，這兩本接下來就看：

《web站點優化》

《**效能監測與優化》

一般來說使用者調研有這麼幾個方式：

問卷調查

使用者訪談

焦點小組

現場觀察

網上資料很多，不細談。但是我有個觀點：

「使用者調研不是說搞起就搞起」---很多時候時間精力花出去了，收到的效果和花費不成比例，獲取的資料也不一定有用。

依稀記得《人人都是產品經理》裡面介紹過，搞一次「焦點小組」忙前忙後乙個多星期，場地，車馬費，資料等等花費要一萬幾千。創業公司哪有這個時間金錢去折騰？

大一兼職做問卷調查員。如果嚴格按照流程乙份問卷填下來要差不多40分鐘，後來填煩了，就瞎填了。自此之後我對第三方資料調查機構的資料就不怎麼信任了。

這裡的系統圖和我們平時說的work breakdown structure是差不多乙個意思。

（沒找到好看的系統圖 t-t）

：） 這沒啥可以補充了

產品UED流程及交付物

圖1 elya總結的ued流程 如圖1所示，國內的ued團隊主要由互動設計師 視覺設計師和使用者研究工程師組成，ued團隊負責產品的使用者需求把握 視覺呈現優化和使用體驗提公升。1 需求分析階段 使用者研究工程師跟進使用者調研 需求分析，提交需求報告 2 功能設計階段 互動設計師配合pm的功能設計文...

軟體開發各階段交付物列表

目的 說明軟體開發專案的實現在技術上 經濟上和社會條件上的可行性 論述為達到開發目的而可能選擇的各種方案 說明並論證所選定的方案。內容 引言 編寫目的 背景 定義 參考資料等 可行性研究的前提 要求 目標 條件 假定 限制 進行可行性研究的方法 評價尺度 對現有系統的分析 資料流程和處理流程 工作負...

應用交付學習筆記二

1 連線和會話的區別 在四層負載均衡中，連線是最小的元素，乙個連線包含源目ip位址，源目埠等資訊，對於客戶端每發起的乙個soket連線，big ip ltm 識別為乙個 connection。而在通常情況下，會話是有多個連線組成的，對於乙個使用者而言，她針對同乙個源位址和目的vs的連線就是乙個會話。...