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

“戰(zhàn)略規(guī)劃+需求挖掘”，講完“滿足什么需求？”，本篇講講產(chǎn)品經(jīng)理的“靈魂拷問(wèn)”：需求如何滿足？

我把拷問(wèn)二的解答過(guò)程抽象為兩大模塊：產(chǎn)品設(shè)計(jì)和迭代規(guī)劃，本篇先講產(chǎn)品設(shè)計(jì)。

1. 產(chǎn)品設(shè)計(jì)的目標(biāo)

前面提到：“需求挖掘”過(guò)程中，產(chǎn)品經(jīng)理需要對(duì)來(lái)自四面八方的需求進(jìn)行分析、討論，有時(shí)還需要結(jié)合相關(guān)的調(diào)研與實(shí)驗(yàn)結(jié)果，以確定需要在產(chǎn)品中滿足的需求，輸出相應(yīng)的用戶故事（作為一個(gè)<角色>, 我想要<活動(dòng)>, 以便于<價(jià)值>）。

在該過(guò)程中，重點(diǎn)在于明確具體場(chǎng)景中存在的問(wèn)題，或者說(shuō)用戶期望獲得的價(jià)值（即用戶故事中的<價(jià)值>），而相應(yīng)的問(wèn)題解決方案（即用戶故事中的<活動(dòng)>），則往往僅作概述性定義，因而需要在“產(chǎn)品設(shè)計(jì)”過(guò)程中進(jìn)一步明確、細(xì)化。

例如一個(gè)知識(shí)付費(fèi)產(chǎn)品，為了提高用戶查找意向內(nèi)容的成功率與效率，計(jì)劃優(yōu)化內(nèi)容搜索功能，支持正文內(nèi)容的搜索，并讓搜索結(jié)果根據(jù)內(nèi)容匹配度與熱度排序……

像這樣的需求描述，似乎已經(jīng)很具體了？這對(duì)于用戶來(lái)說(shuō)確實(shí)已足夠明確，因?yàn)橛脩糇铌P(guān)心的是從產(chǎn)品功能中獲得的價(jià)值，略關(guān)心獲得價(jià)值的方式，至于具體的實(shí)現(xiàn)細(xì)節(jié)，則毫不在意也沒(méi)有必要在意。

但對(duì)于企業(yè)團(tuán)隊(duì)來(lái)說(shuō)，這樣的描述就像一篇文章的標(biāo)題而已，具體的實(shí)現(xiàn)細(xì)節(jié)才是“正文”，決定著該需求的用戶期望與企業(yè)期望是否達(dá)成，也影響著運(yùn)營(yíng)與開(kāi)發(fā)等團(tuán)隊(duì)成員對(duì)需求的理解與執(zhí)行。

如果你把這“一句話需求”甩給研發(fā)同事，你會(huì)看到他們滿頭問(wèn)號(hào)：正文內(nèi)容的搜索匹配規(guī)則如何定義與管理？搜索結(jié)果排序邏輯如何定義與管理？搜索結(jié)果是否需要分頁(yè)？是否需要考慮敏感詞？還有樣式、交互，甚至性能等要求……（實(shí)際上，對(duì)于較大規(guī)模體量的產(chǎn)品，該需求甚至意味著一個(gè)“推薦搜索團(tuán)隊(duì)”的成立）。

我們可以把產(chǎn)品設(shè)計(jì)過(guò)程視為對(duì)用戶故事中<活動(dòng)>的具象化，以輸出具體的、能“友好”達(dá)成需求價(jià)值目標(biāo)的功能設(shè)計(jì)方案。該階段具體產(chǎn)出物需支持需求方、研發(fā)團(tuán)隊(duì)、運(yùn)營(yíng)團(tuán)隊(duì)等相關(guān)方進(jìn)行高效溝通與業(yè)務(wù)執(zhí)行。

2. 產(chǎn)品設(shè)計(jì)過(guò)程與輸出

明確了產(chǎn)品設(shè)計(jì)的具體目標(biāo)，相應(yīng)的產(chǎn)品設(shè)計(jì)過(guò)程自然也基于目標(biāo)展開(kāi)。因業(yè)務(wù)類別、產(chǎn)品階段或企業(yè)資源等差異，產(chǎn)品設(shè)計(jì)過(guò)程并沒(méi)有所謂“最正確”的“套路”，只有基于具體需求與團(tuán)隊(duì)自身情況的“相對(duì)正確”。

估計(jì)有一定項(xiàng)目經(jīng)驗(yàn)的產(chǎn)品經(jīng)理也大都會(huì)熟能生巧地形成自己的產(chǎn)品設(shè)計(jì)方法，我也試圖抽象出產(chǎn)品設(shè)計(jì)階段的具體過(guò)程與過(guò)程輸出，把整個(gè)過(guò)程分解為四個(gè)部分：流程設(shè)計(jì)、功能架構(gòu)、信息架構(gòu)、原型設(shè)計(jì)。

2.1 流程設(shè)計(jì)

在“需求挖掘”過(guò)程中，我們定義了用戶需求，對(duì)通過(guò)產(chǎn)品帶給用戶的<活動(dòng)>作了概述。而要讓<活動(dòng)>具象化，必然需要對(duì)<活動(dòng)>的具體流程或所在流程作梳理。

實(shí)際上，在“需求挖掘”階段，對(duì)需求活動(dòng)流程的思考就已經(jīng)開(kāi)始了，但更多只是對(duì)用戶流程的分析，也即我們常說(shuō)的用戶路徑或用戶體驗(yàn)地圖，純粹關(guān)注用戶視角，且往往僅是“一句話描述”。而在輸出具體的產(chǎn)品設(shè)計(jì)方案過(guò)程中，則需要考慮用戶與系統(tǒng)間、系統(tǒng)與系統(tǒng)間的具體交互過(guò)程。

這一方面要求產(chǎn)品經(jīng)理在設(shè)計(jì)用戶的功能使用路徑時(shí)，準(zhǔn)確把握用戶情緒的變化，產(chǎn)品上每個(gè)服務(wù)觸點(diǎn)都可能影響用戶對(duì)產(chǎn)品的感覺(jué)。另一方面也要求產(chǎn)品經(jīng)理結(jié)合業(yè)務(wù)與企業(yè)背景及系統(tǒng)實(shí)現(xiàn)原理，以更高效能的關(guān)聯(lián)需求流程與系統(tǒng)流程來(lái)支持用戶體驗(yàn)流程的運(yùn)作。

比如一個(gè)“線上商城”新增派發(fā)“支付抵現(xiàn)紅包”，你除了得設(shè)計(jì)一個(gè)能讓用戶紅包領(lǐng)得爽、用得爽，邀請(qǐng)機(jī)制也爽的用戶使用流程，還得考慮運(yùn)營(yíng)管理端的紅包派發(fā)管理流程，以及功能具體實(shí)現(xiàn)的系統(tǒng)流程，如系統(tǒng)的交互時(shí)序，解答類似于用戶支付時(shí)的紅包扣減消息該同步還是異步這樣的問(wèn)題。

流程設(shè)計(jì)方案的輸出可以用UML（統(tǒng)一建模語(yǔ)言）規(guī)范的多種圖來(lái)呈現(xiàn)，比如比較常用的活動(dòng)圖、狀態(tài)機(jī)圖、順序（序列）圖等，相較于傳統(tǒng)的“流程圖”，UML建模更規(guī)范、全面，很適合對(duì)復(fù)雜業(yè)務(wù)流程的梳理與表達(dá)（關(guān)于UML建模，可自行查閱相關(guān)資料或圖書(shū)學(xué)習(xí)，如Joseph Schmuller的《UML基礎(chǔ)、案例與應(yīng)用》等，建模工具可用Astah、ProcessOn等完成）。

當(dāng)然最終以什么方式來(lái)表達(dá)還得視具體場(chǎng)景而定，假設(shè)是面向C端產(chǎn)品用戶的客戶訪談，可能以傳統(tǒng)的流程圖、甚至是帶交互效果的原型圖來(lái)表達(dá)會(huì)更便于客戶理解。但如果是面向研發(fā)團(tuán)隊(duì)的需求文檔，則建議PM們?cè)谫Y源允許下，盡可能規(guī)范、完整地用UML來(lái)建模說(shuō)明流程方案，并作為流程驗(yàn)收的標(biāo)準(zhǔn)，減少因文字或口頭表達(dá)的偏差導(dǎo)致需求理解偏差，進(jìn)而影響研發(fā)進(jìn)度。

2.2 功能架構(gòu)

每個(gè)<活動(dòng)>都意味著在產(chǎn)品中新增功能或調(diào)整某些原有功能，而除了具體功能流程的設(shè)計(jì)外，功能的劃分以及功能之間的從屬關(guān)系也影響著用戶對(duì)產(chǎn)品服務(wù)的感知與使用?？梢哉f(shuō)，產(chǎn)品的功能本身決定“產(chǎn)品能不能用”，產(chǎn)品的功能架構(gòu)影響“產(chǎn)品好不好用”。

比如微信的視頻號(hào)如果哪天跳脫出“發(fā)現(xiàn)”模塊，而出現(xiàn)在了“底導(dǎo)”上，可能部分完全無(wú)“公廣或查看短內(nèi)容”需求的用戶就不開(kāi)心了，因?yàn)槟惆岩粋€(gè)他們不需要的功能放在了最明顯的位置上，帶來(lái)了不必要的干擾。

而如果視頻號(hào)變成了微信幾百萬(wàn)個(gè)小程序之一，不再是獨(dú)立功能、也無(wú)常駐入口，盡管具體功能體驗(yàn)完全一致，但“視頻號(hào)”對(duì)于用戶的感知，馬上從會(huì)“短內(nèi)容公眾分享平臺(tái)”變成“某第三方在微信折騰的‘小抖音’”……

你會(huì)發(fā)現(xiàn)，功能架構(gòu)帶給用戶的影響主要還是是因?yàn)楦淖兞擞脩舻墓δ苁褂寐窂?，跟流程設(shè)計(jì)是有所耦合的。但視角不一樣，流程設(shè)計(jì)更多是聚焦在具體的某個(gè)“流程”。而功能架構(gòu)則是基于功能模塊或整個(gè)產(chǎn)品、產(chǎn)品線，甚至是企業(yè)的整個(gè)“大產(chǎn)品”，重點(diǎn)關(guān)注功能間的關(guān)系。除了影響當(dāng)前用戶需求的滿足，“更科學(xué)”的功能架構(gòu)也能讓產(chǎn)品后續(xù)的功能延展及迭代更順暢一些。

比如還是上面“線上商城”的例子，現(xiàn)在又要新增一種“紅包”，如果新增的紅包除了多了“可用商品品類”的使用條件差異之外，其他功能需求與前者完全一致。那這就只是“紅包”類里加個(gè)屬性，沒(méi)有必要新增一個(gè)與前者并列的紅包功能。

但如果新增的“紅包”不再是“支付抵現(xiàn)”，而是直接給用戶發(fā)現(xiàn)金，具體紅包配置信息也有很大差異，那一個(gè)獨(dú)立的“現(xiàn)金紅包”功能在此則顯得更恰當(dāng)一些。而如果某天企業(yè)意識(shí)到，像這樣相似或不相似的、復(fù)雜或簡(jiǎn)單的營(yíng)銷活動(dòng)將成為運(yùn)營(yíng)團(tuán)隊(duì)長(zhǎng)期持續(xù)的需要，這時(shí)相較于一次次地定制開(kāi)發(fā)獨(dú)立的功能模塊，一個(gè)有更強(qiáng)擴(kuò)展性的統(tǒng)一營(yíng)銷管理平臺(tái)就顯得更有長(zhǎng)遠(yuǎn)價(jià)值，當(dāng)然這也意味著需要更全面地探討潛在的營(yíng)銷活動(dòng)模式。

所以功能架構(gòu)并不是簡(jiǎn)單地根據(jù)功能的相關(guān)性進(jìn)行聚合或拆解，而需要兼顧用戶的功能使用路徑，兼顧企業(yè)的系統(tǒng)迭代需要。功能架構(gòu)過(guò)程與流程設(shè)計(jì)過(guò)程沒(méi)有絕對(duì)的先后，更多是協(xié)同推進(jìn)。

至于過(guò)程輸出，功能結(jié)構(gòu)圖是表達(dá)功能架構(gòu)方案的主要形式。

2.3 信息架構(gòu)

用戶對(duì)產(chǎn)品功能服務(wù)的理解與使用，非常依仗于產(chǎn)品所承載的信息（包括：文字、圖片、視頻、音頻等所有能通過(guò)產(chǎn)品讓用戶感知的內(nèi)容）。信息架構(gòu)的目標(biāo)是通過(guò)架構(gòu)出準(zhǔn)確的信息內(nèi)容與合理的信息呈現(xiàn)形式，建立產(chǎn)品與用戶間的高效溝通，讓用戶最低思考成本與操作成本地完成我們希望Ta做的事情。

關(guān)于“準(zhǔn)確的信息內(nèi)容”，我們往往會(huì)借助結(jié)構(gòu)化輸出的信息架構(gòu)圖，遍歷所有需求功能及相應(yīng)界面中會(huì)涉及的信息。除了基于實(shí)際需要來(lái)羅列信息內(nèi)容，還需對(duì)信息數(shù)據(jù)作進(jìn)一步的詳細(xì)描述（如數(shù)據(jù)類型、字段長(zhǎng)度、是否必填、默認(rèn)值、數(shù)據(jù)來(lái)源……），輸出類似于“數(shù)據(jù)字典”但又更易于與業(yè)務(wù)溝通的表格（我暫且喊ta為信息說(shuō)明表）。當(dāng)然有的PM會(huì)習(xí)慣于輸出用例圖與類圖來(lái)表達(dá)。

關(guān)于“合理的信息呈現(xiàn)形式”，這實(shí)際是可視化產(chǎn)品設(shè)計(jì)的專屬，可以理解為對(duì)頁(yè)面信息元素的規(guī)劃布局，例如界面導(dǎo)航的類型選擇與布局等。

目前行業(yè)內(nèi)也形成了一些具體的界面信息架構(gòu)的方法或原則，例如：合理地安排界面信息層級(jí)，突出有限的（最好就一個(gè)）關(guān)鍵信息；信息相關(guān)度聚合原則；如果是手機(jī)端的產(chǎn)品還會(huì)考慮最佳手勢(shì)操作區(qū)域等。這些“套路”的背后都是對(duì)用戶心理的把握，這一點(diǎn)在產(chǎn)品設(shè)計(jì)過(guò)程里可謂貫穿始終。

2.4 原型設(shè)計(jì)

可能部分讀者在看到“信息架構(gòu)”的最后一段時(shí)會(huì)困惑：“這不就是原型設(shè)計(jì)么？”

實(shí)際這得看你怎么定義原型設(shè)計(jì)咯。如果你把原型設(shè)計(jì)定義為“線框圖設(shè)計(jì)”，那倒確實(shí)是對(duì)的。但個(gè)人本篇所描述的“原型設(shè)計(jì)”過(guò)程，涵蓋范圍則會(huì)更廣一些：界面信息結(jié)構(gòu)、交互流程（包括具體的界面操作邏輯與界面流轉(zhuǎn)規(guī)則）、交互效果、視覺(jué)效果等，都是“原型”這個(gè)詞所覆蓋的。原型設(shè)計(jì)就是對(duì)需求流程、功能結(jié)構(gòu)與信息結(jié)構(gòu)的最直觀化表達(dá)。

當(dāng)然，在實(shí)際工作中，產(chǎn)品與設(shè)計(jì)團(tuán)隊(duì)很可能不會(huì)如此周全地輸出高保真原型圖，更不會(huì)待如此高保真的原型輸出后，再與需求方等確認(rèn)需求方案。實(shí)際情況可能是帶關(guān)鍵功能說(shuō)明的低保真原型圖，附加關(guān)鍵的業(yè)務(wù)流程圖整合到文檔里，再配上若干句需求背景描述或數(shù)據(jù)，即呈上那爭(zhēng)分奪秒的需求計(jì)劃會(huì)的討論之中。

這有些時(shí)候是合理的，但也需注意適時(shí)適度地完善設(shè)計(jì)方案。如果盲目為了追求快速迭代而過(guò)份壓縮產(chǎn)品設(shè)計(jì)過(guò)程，而后因考慮不周而有所疏漏，后續(xù)再改需求，實(shí)際效益自然不增反降，這就是我常說(shuō)的“偽敏捷”現(xiàn)象。

另外，原型設(shè)計(jì)階段還是要求產(chǎn)品經(jīng)理對(duì)交互設(shè)計(jì)、視覺(jué)設(shè)計(jì)有較深認(rèn)識(shí)的，尤其是C端產(chǎn)品設(shè)計(jì)。相信經(jīng)常玩弄各種互聯(lián)網(wǎng)產(chǎn)品的你，也沒(méi)少被各種反人類的交互體驗(yàn)鬧得砸手機(jī)（盡管功能本身可能是你需要的、能解決你問(wèn)題的，比如某些銀行App），下次砸完記得想想：“讓你難受的點(diǎn)是什么？如果讓你著手改進(jìn)，你會(huì)怎么做？如何專業(yè)地表達(dá)這么做的緣由？”

尤其最后一個(gè)問(wèn)題，正是讓你平時(shí)能游刃有余說(shuō)服設(shè)計(jì)獅、程序猿們的理?yè)?jù)，多積累點(diǎn)專業(yè)知識(shí)，“撕”起來(lái)也有勁點(diǎn)、高效點(diǎn)吧？

3. 小結(jié)

“產(chǎn)品設(shè)計(jì)”真不是簡(jiǎn)單對(duì)著競(jìng)品畫(huà)畫(huà)原型圖的事。

基于戰(zhàn)略與用戶需求，兼顧創(chuàng)新與可用資源，從用戶流程到系統(tǒng)流程，從功能結(jié)構(gòu)到信息結(jié)構(gòu)，從交互到視覺(jué)，這才算是解答“需求如何滿足？”的正確姿勢(shì)，把“用戶需求”轉(zhuǎn)化成“產(chǎn)品需求”。而原型和文檔只是產(chǎn)品設(shè)計(jì)過(guò)程的產(chǎn)物，讓你與需求方、企業(yè)團(tuán)隊(duì)等更高效溝通而已。

比如說(shuō)，用于溝通迭代計(jì)劃，下篇“迭代規(guī)劃”篇就會(huì)分享相關(guān)內(nèi)容。

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

題圖來(lái)自Unsplash，基于CC0協(xié)議