中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文作者結(jié)合自己的經(jīng)驗，總結(jié)了產(chǎn)品從0到1設(shè)計過程中的一些反思，與大家分享，希望可以給大家一些啟發(fā)。

2015年的夏天，我以實習(xí)生的身份來到現(xiàn)在的這家公司。剛到公司時，我在一個已經(jīng)比較成熟的部門項目下做著用戶研究的工作，直到有一天，領(lǐng)導(dǎo)讓我做一個關(guān)于XX的競品分析報告。當(dāng)我找遍資料寫完報告交給老板時，雖被領(lǐng)導(dǎo)找出了一千個不足之處，但一番“痛罵”教導(dǎo)后，對我說“1.0的需求原型、周五前給我個初稿”。我好像一個毛頭小兵，突然被委以重任，便開啟了從0到1的產(chǎn)品設(shè)計之路。

在這個項目中筆者參與了iOS端APP以及PC官網(wǎng)、后臺的設(shè)計，那么我著重會以iOS端APP的產(chǎn)品設(shè)計進(jìn)行舉例分析。

如何把原型需求做得更好

關(guān)于如何收集與整理用戶需求、如何繪制原型、如何寫一份優(yōu)秀的需求文檔，網(wǎng)絡(luò)上優(yōu)秀的干貨文章不勝枚舉，在此筆者不再贅述。

值得一提的是，對于需求文檔的撰寫，我并不注重偏形式化的東西，文檔的命名格式以產(chǎn)品名/功能名_版本號_撰寫日期即可，一份需求文檔則是一款產(chǎn)品，那么開發(fā)人員則是使用它的用戶。如何讓用戶體驗好，才是產(chǎn)品經(jīng)理在撰寫文檔時更應(yīng)該注意的。

一份需求文檔可能會被前端開發(fā)、API開發(fā)、后臺開發(fā)、測試等不同的技術(shù)人員閱讀，在文檔中應(yīng)該體現(xiàn)針對不同角色而對應(yīng)的不同閱讀模塊。簡單來說，ios開發(fā)需要閱讀文檔中的整個功能需求模塊，而PHP開發(fā)只需要閱讀所需接口需求模塊，因為對于PHP開發(fā)來說，如何實現(xiàn)一個翻頁操作是他毫不關(guān)心的。在文檔中，針對不同角色分段說明，開發(fā)能明確知道自己的開發(fā)任務(wù)、閱讀體驗更好，也能有效提高開發(fā)效率。當(dāng)然，內(nèi)容條理、邏輯清晰是需求文檔的基礎(chǔ)。我也經(jīng)常會問開發(fā)，你需要什么樣的需求文檔？開發(fā)說“我可以完全按照你的需求文檔開發(fā)，不需要再做任何思考”。那這其中要求的是產(chǎn)品經(jīng)理將各方面考慮詳盡，但在實際操作中，產(chǎn)品經(jīng)理難免也會有遺漏之處。

在1.0原型初稿出爐之后，我面臨了職場的第一次鄙視，來源于隔壁組支援的UI設(shè)計大兵。我仍記憶猶新，在個人中心頁面上，有一個登錄及我的訂單入口。而我居然遺漏了未登錄狀態(tài)下點擊我的訂單入口時的情況。這幾乎對所有產(chǎn)品經(jīng)理來說，是一個不可能犯的錯。我被大兵鄙視了一番“你這原型畫的，我都沒心情設(shè)計”，這也著實給了我一次較沉重的打擊。事后我一直在反思，怎樣才能讓自己在做需求設(shè)計時考慮的更全面呢？

1. 借助思維導(dǎo)圖、流程圖等工具
2. 0與1 、和1到多法則
3. 犯錯后的反思總結(jié)

思維導(dǎo)圖是一個非常簡單但極其有效的幫助思考工具。在思維導(dǎo)圖中，你可以將產(chǎn)品的功能進(jìn)行分類再分類、深入到每一個細(xì)枝末節(jié)。它不僅能幫助你深入思考、而且記錄下思考過程。在繪制原型時你可以遵循思維導(dǎo)圖進(jìn)行設(shè)計，盡可能避免遺漏任何一個枝節(jié)，而流程圖的繪制對于頁面操作交互、流程的設(shè)計十分有利。我們所期望的是用戶能夠在我們的產(chǎn)品中進(jìn)行轉(zhuǎn)化（注冊、下單等），那么要求所設(shè)計的任何一條路徑都是能夠通向目標(biāo)的，如果在流程圖中發(fā)現(xiàn)有一條走不通的路徑，那這里的問題就是產(chǎn)品經(jīng)理應(yīng)該去考量的。

0與1、和1到多法則指的是思考時應(yīng)該針對每一個頁面或功能分析它的對立面和多種情況。有人就會說，“如果我真的能考慮到多種情況，那就不會出現(xiàn)遺漏了”。讓每個人都能考慮所有情況不是一件容易的事，而我這里想說的是你需要培養(yǎng)自己的思維模式。在設(shè)計事，按照0與1、1到多的步驟去進(jìn)行思考每一種情況，不斷地鍛煉加強的自己的思考能力。

在產(chǎn)品設(shè)計中的遺漏和出錯對于產(chǎn)品經(jīng)理來說，總歸都是一次經(jīng)驗教訓(xùn)，失誤之后的分析和總結(jié)是必不可少的。而最基本的要求是不能在同一個環(huán)節(jié)步驟設(shè)計上失誤兩次。

版本開發(fā)時，我應(yīng)該做什么？

在經(jīng)歷了產(chǎn)品評審、技術(shù)評審會議后，1.0需求在修修補補后終于塵埃落定，提交給技術(shù)大哥們進(jìn)行開發(fā)了。在研發(fā)階段，我也必須要完成后續(xù)一系列的工作。

任務(wù)拆分和時間排期

在技術(shù)評審會議結(jié)束后，我將產(chǎn)品的功能模塊拆分成一個個小的任務(wù)，然后以表格形式下發(fā)給技術(shù)人員，技術(shù)人員各自在每個任務(wù)后填寫對應(yīng)的開發(fā)周期及開始時間、結(jié)束時間；在安排前后端開發(fā)時，能夠根據(jù)開發(fā)需求調(diào)整任務(wù)的先后順序，得到一個較為合理的排期。

及時溝通和解決問題

在產(chǎn)品開發(fā)過程中，溝通是必不可少的。所以在產(chǎn)品開發(fā)之前，產(chǎn)品經(jīng)理與開發(fā)人員需達(dá)成共識：在需求文檔不完善或有疑問的情況下，開發(fā)人員需要主動與產(chǎn)品進(jìn)行溝通；而在需求發(fā)生變動的情況下，產(chǎn)品經(jīng)理也需要第一時間告知開發(fā)人員。

而我深感在實際開發(fā)過程中，經(jīng)常會出現(xiàn)一種“我以為我說的，別人就能明白”的溝通方式。這種先入為主的思想，會使訴說方的措辭表述不清，傳達(dá)的信息不準(zhǔn)確，繼而影響問題的解決。

常見的錯誤溝通方式有：

• 產(chǎn)品經(jīng)理小紅為了省事將問題頁面截圖加紅色標(biāo)記，“這里有問題！”后直接甩給開發(fā)。在開發(fā)的視角里，他還需要去猜是什么問題？是如何出現(xiàn)這個情況的？應(yīng)該怎么修改？所以在溝通中，產(chǎn)品經(jīng)理針對問題明確的表達(dá)方式是應(yīng)該【操作步驟+結(jié)果+期望】，什么樣的操作步驟，造成什么樣的結(jié)果，它應(yīng)期望實現(xiàn)的效果是什么？
• 開發(fā)小明問“這里有問題嗎？”這句話看似沒毛病，但在實際揣測時，你會發(fā)現(xiàn)它涵蓋了再次確認(rèn)問題（是否還有問題）、對問題不理解（有什么問題）或不認(rèn)可（這里沒問題）的多層意思。漢語的博大精深讓人捉摸不透，而在項目溝通時盡量避免使用模棱兩可的問句，盡可能通過陳述語句直截了當(dāng)?shù)谋磉_(dá)出自己的問題或看法。
• “這個需求很簡單，怎么實現(xiàn)我不管”這是一句流傳于IT圈的產(chǎn)品經(jīng)理名言，實際上大部分負(fù)責(zé)的產(chǎn)品經(jīng)理是不會是以這樣工作態(tài)度和開發(fā)進(jìn)行溝通的。產(chǎn)品經(jīng)理作為一個和部門各崗位都需要打交道的職務(wù)，心態(tài)尤為重要，并不要因為“經(jīng)理”這個虛名就認(rèn)為自己比其他團(tuán)隊人員級別更高，在與開發(fā)及其他技術(shù)人員進(jìn)行溝通時，應(yīng)該用謙遜請教的態(tài)度，聽取各方意見，避免在開發(fā)一半后發(fā)現(xiàn)一些潛在問題。

這句名言中指出的另外一個問題是：產(chǎn)品經(jīng)理是需要了解產(chǎn)品功能的實現(xiàn)過程的。舉個很簡單的例子，修改文案。對于網(wǎng)站來說，可以在代碼中進(jìn)行修改、發(fā)布上線；而如果在開發(fā)前產(chǎn)品經(jīng)理進(jìn)行要求該文案是可以通過后臺進(jìn)行編輯操作的，那么運營人員直接可以自主修改并發(fā)布文案。對于移動端應(yīng)用來說，如果是在接口中寫入的信息，那么可以通過修改接口中內(nèi)容達(dá)到目的。而如果該文案被開發(fā)寫死在客戶端中，那這一個簡單的修改文案是需要通過重新發(fā)版本才能完成。這時候產(chǎn)品經(jīng)理就該燒香拜佛祈禱這個文案并不會對產(chǎn)品有太糟糕的影響。所以，產(chǎn)品經(jīng)理對于實現(xiàn)方法的把控也至關(guān)重要。

下一個版本迭代工作

在技術(shù)人員緊鑼密鼓的進(jìn)行開發(fā)工作時，我也開始著手準(zhǔn)備下個迭代版本的需求原型。在1.0的需求當(dāng)中，我僅僅是優(yōu)先實現(xiàn)了基礎(chǔ)功能，而忽略了數(shù)據(jù)的投遞工作。在領(lǐng)導(dǎo)的提醒后，我開始研究如何做APP的埋點設(shè)計。

數(shù)據(jù)統(tǒng)計一般分為兩個方面，一方面為基礎(chǔ)數(shù)據(jù)例如新增人數(shù)、啟動人數(shù)、活躍人數(shù)、用戶留存等，還有崩潰率（很重要）；另一方面則為衍生數(shù)據(jù)，頁面的瀏覽人數(shù)次數(shù)、操作的人數(shù)次數(shù)、頁面轉(zhuǎn)化率等。我采用的方法便是，列出所有的功能頁面、操作按鈕、加入人數(shù)和次數(shù)兩個指標(biāo)，直到現(xiàn)在我還是這樣做的。

當(dāng)我正在電腦前構(gòu)思1.1版本的需求原型時，領(lǐng)導(dǎo)問我“APP發(fā)布上線的資料準(zhǔn)備的怎么樣了？”

APP發(fā)布的準(zhǔn)備工作

當(dāng)然是提交APP到應(yīng)用商店的審核資料。

App store開發(fā)者帳號或安卓應(yīng)用商場帳號的申請

因公司而異，有些公司是需要產(chǎn)品經(jīng)理/運營去申請開發(fā)者賬號的；申請APPstore的開發(fā)者賬號流程較慢，需要提前進(jìn)行申請，切勿版本開發(fā)完之后才一拍腦袋發(fā)現(xiàn)帳號沒申請！具體的申請流程可百度查閱。

應(yīng)用截圖

在1.0快上線的最后幾天，我才發(fā)覺還沒有應(yīng)用介紹頁的設(shè)計圖。于是，我只能帶著一杯奶茶求隔壁組UI大兵加加班。應(yīng)用截圖一般是尺寸1242*2208、png格式的3~5張圖片，在APPstore中針對不同尺寸只需上傳一個尺寸的文件通用即可。

應(yīng)用介紹（內(nèi)容提要）

應(yīng)用介紹是用戶對產(chǎn)品的“第一印象”，簡明扼要的告訴用戶為什么我們的產(chǎn)品比別家的要好。在APPstore中展示時僅展示前五行內(nèi)容，需要用戶點擊更多后才能查看完整內(nèi)容，所以前五行的內(nèi)容相對比較重要。而在具體內(nèi)容的撰寫上，我有以下幾個建議：

1. 產(chǎn)品屬性定位到使用場景：你可以試著這樣進(jìn)行分析“一個XX產(chǎn)品——>一個為XX用戶設(shè)計的XX產(chǎn)品——>一個可以幫用戶完成XX操作/行為的產(chǎn)品”
2. 從用戶利益角度出發(fā)：通過介紹產(chǎn)品中的一些優(yōu)惠項、福利活動、個人定制、專屬服務(wù)等吸引客戶。例如“注冊贈送38888元禮包”、“你可以擁有屬于自己的直播間”、“打賞功能”···
3. 加強產(chǎn)品的社會認(rèn)同程度：在應(yīng)用介紹中可以介紹該產(chǎn)品曾經(jīng)獲得的獎項（全國十佳之一）、上榜優(yōu)秀應(yīng)用或擁有千萬級別用戶量等被社會認(rèn)同的成績，讓用戶產(chǎn)生一種“它應(yīng)該不錯”的概念。
4. 加上客服熱線/官方網(wǎng)址：在應(yīng)用介紹的末尾可以加上客服熱線或網(wǎng)址，能幫助用戶快速的聯(lián)系到我們。

ASO優(yōu)化：

當(dāng)領(lǐng)導(dǎo)跟我說ASO的時候，我是懵圈的。我默默的百度了一下，“ASO是手機應(yīng)用商店優(yōu)化的簡稱，是提升你APP在各類APP蘋果電子市場排行榜和搜索結(jié)果排名的過程?！痹谶@個方面，我一般是借助了ASO優(yōu)化相關(guān)的工具。通過工具分析調(diào)整關(guān)鍵詞和應(yīng)用名稱，提高APPstore的排名。

值得注意的是，APP store經(jīng)常會發(fā)布相關(guān)APP審核的最新規(guī)則制度，例如最近的禁止使用熱更新以及應(yīng)用名稱禁止出現(xiàn)“免費”字眼，產(chǎn)品經(jīng)理都應(yīng)及時關(guān)注并調(diào)整應(yīng)用的相關(guān)內(nèi)容。

1.0上線之后

2016年1月6日是這款產(chǎn)品上線APPstore的時間，至今為止已更新迭代15個版本，每個版本的研發(fā)周期在1個月左右。其中四月份到六月份，我回學(xué)校進(jìn)行了畢業(yè)答辯。

在整個產(chǎn)品研發(fā)、迭代期間，我會將每一次版本的開發(fā)周期、上線的時間以及其中發(fā)生的事件（服務(wù)端客戶端bug）均記錄在工作本中。

• 記錄版本的迭代歷程，就好像看著項目產(chǎn)品在一步一步的成長，同時可以幫助你去分析版本間數(shù)據(jù)差異的原因；
• 記錄期間出現(xiàn)的事件或bug，發(fā)生時間、起因和解決方案能夠幫助在以后的開發(fā)過程中避免出現(xiàn)類似的問題，當(dāng)然在領(lǐng)導(dǎo)問你“前幾天的服務(wù)器是出了什么問題？”，你也不至于丈二和尚摸不著頭腦。

寫在最后

很感謝領(lǐng)導(dǎo)能夠讓我參與到這個項目中來，從一開始的我和領(lǐng)導(dǎo)到現(xiàn)在線上開發(fā)團(tuán)隊也已有二十來號人。還記得在項目剛開始時，我每天下班之后也要盯著工作群，生怕領(lǐng)導(dǎo)在群里艾特我，說哪里出了問題。那段時間頭發(fā)都掉了好幾根。壓力大，責(zé)任也大，成長得也越快。

謹(jǐn)以此篇寫給還算努力的自己。

作者：一顆南星，產(chǎn)品汪。微信公眾號：一顆南星

本文由 @一顆南星 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。