從一個簡單的H5預約活動看產品帶領程序員、設計寶寶們踩過的坑。

作為一個入門的產品“小司機”，目前正在“開車帶路”，與幾位程序員“老司機”閉眼踩坑，在摸索上線的我們教育產品的第一版當中，期間用了兩周的時間上線了一款預約H5應用。借用這款簡單的產品，筆者想和大家簡單地分享一下在這短短的兩周之內踩過得大大小小的“坑”！希望在警醒自己的同時能給各位帶來幫助。

不想聽我BB的小伙伴總結概述如下：

1. 加強溝通確保信息對稱

• 建立需求溝通機制，并嚴格執行；
• 信息透明，各團隊知悉彼此工作節奏；
• 及時同步需求落實的關鍵節點；
• 管理好需求方產品預期；

2. 文檔細致，邏輯清晰完整

• 細致！細致！細致！原型輸出采用真實的數據；
• 保證文案精煉、設計風格預期明確；
• 邏輯規則清晰、頁面狀態無遺漏；

3. 多動手，少動嘴；

4. 在產品設計時一定要明確觸達用戶的路徑，在用戶想喚醒產品的時候能夠出現在用戶預期的行為路徑當中；

5. 上線前一定要在實際場景當中多角色體驗產品。

下面是這個H5活動頁面

坑一：溝通！溝通！溝通！

重要的事情說三遍！產品經理的工作就是從紛繁的業務、場景、用戶亂象中理出需求，然后利用研發寶寶的技術能力解決問題。網絡上流傳著各種鎖定需求的秘籍寶典，筆者就不在這里班門弄斧了。但是筆者要強調一點就是溝通！

產品經理作為需求方（Boss&甲方）以及實現方的紐帶溝通是一項基本且很重要的能力。溝通包含對內溝通以及對外溝通，對外溝通協助需求方理清業務邏輯，對內幫助設計、研發、測試寶寶們更好的理解需求推動產品實現。

1.需求

筆者這次對外溝通對接的業務團隊業務能力Max，在半個小時的需求會議當中敲定了整體的業務需求。筆者從未遇到如此順利的需求會議，簡單地認為需求“So easy”，然而事實告訴筆者，還是太！年！輕！

為了快速地落實需求在當天晚上全公司內部進行了詳細的需求討論、任務拆解及開發進度評估，需求初稿為提前鎖定業務團隊冬季銷售業績的預約活動，只需承載預約功能即可，筆者輸出了如下圖的第一版需求：

然而在和團隊同學腦暴時，我們發現用戶的購買場景有可能與線下團隊的推廣場景是分開的。只有這一頁，誰會買單呢？

頁面一定是會通過各種傳播轉發的，只有這么簡潔的說明，啥也說明不了啊。所以，又需要加一頁預約產品詳情介紹……

2. 視覺

由于需求非常緊急，為了節省開發時間，讓設計同學和研發同學同步啟動。設計同學先確定了活動詳情頁頭圖的設計思路及配色，選擇了紫色作為基本色，白色輔助，綠色強調；然后便開始了預約等功能型頁面的設計，而將最花費時間但開發起來相對容易的活動詳情頁放在最后設計。

輸出的樣式是醬的：

然而和業務團隊的同事確認需求時頁頭部分的進度條文案是醬的：

業務團隊的同事對于設計稿的預期是醬的：

經過一番討si論bi后，我們定稿了初稿的樣式。

3.文案

開始時業務方的同學給了兩條建議文案：

• 冰雪王國沒有黑魔法，但我駕馭了雪上“飛行”；
• 我會變成巨人，踏著雪板，踩著風；

開始覺得第二句還不錯，就按這個文案的感覺做出了頭圖的效果。但這兩句文案太過文藝，不能很明確的表達主題，不太適合做頁面的主標題，所以打算用做輔助文案，而主標題直接采用“2017萬科梅沙冬令營預約開始”。

根據頁面的設計效果，需要一句過渡文案引出下面的詳情介紹。當時我們的產品同事們給出了眾多的文案備選：

最后我們采用的是“讓我們再聚冰雪世界，體驗雪上飛行”這句文案。輸出的樣式是醬的：

4.圖片

大部分用戶是看不出頁面的設計效果如何（比如字體設計，色彩搭配什么的），但是他們能看懂圖片所傳達的內容和情緒，所以圖片的選擇一定是至關重要的。由于設計同學本身只關注了其他視覺效果的設計，而忽略了內容與頁面整體效果的把控，從而忽視了圖片選擇的重要性。

原來的單板滑雪圖片居然用了這張，是醬的（哪里是冬令營啊，是老年人在蹣跚吧）：

（老年人走路，改成了醬，如下圖）比原來好一些，其實還不滿意，沒辦法，自己拍的有版權的圖片也就這一張好一點，今年冬天，要多拍冬令營的滑雪照片啊……

原來的雪圈（雪上運動）圖片是醬的~

（收拾東西回家了！改成了醬，如下圖）替換之后畫面有木有更High？

5.研發

細致！細致！細致！對內溝通產品經理要能準確的傳達需求，幫助設計、研發、測試的同學實現需求。在同業務團隊的同事溝通確認需求之后，Alex自信滿滿的輸出了如下的幾張原型：

然而在設計師同學看到以后的真實OS：

文案怎么這么長……價格說明一坨什么鬼……暫！定！這文案什么意思……研發同學看到以后的真實OS……
流程怎么走不通……這個功能不好做……在評審中Alex受到了10000萬點傷害，陣亡的節奏。

經過一番溝si通bi后輸出了如下的設計稿，然后進入了研發階段：

然而在體驗驗收時……

產品經理：營期交互我要的是點選不是滑動~改……
程序員：……

產品經理：營期選擇點擊按鈕太小了，容易誤觸發~改……
程序員：…………

產品經理：這個彈窗提醒的文案有歧義~改……

此時的程序員是這樣的：

對內溝通時請一定要細致！細致！細致！原型作為對內溝通的工具在輸出時盡量要采用真實的數據，保證文案精煉、設計風格預期明確、邏輯規則清晰、頁面狀態無遺漏。溝通時紙筆比嘴巴好用、圖文比嘴巴好用、案例比嘴巴好用！

經過了一番改！改！改！之后給到了業務團隊的同事驗收。然而在驗收的時候結果就是……

居然不能選多個……一人居然只能預約一次……居然不能退款……

對于互聯網產品上線節奏缺乏了解的非專業同學，很容易想當然的將產品實現的過程想的很神秘或者很簡單，同時在需求表達時又很容易跑偏，所以在Alex與教育團隊的小伙伴確認需求時，小伙伴并沒有意識到原型就是產品整體實現的樣式，導致在驗收階段產品的實現功能同需求方小伙伴的預期不一致。

為了能保持高效的產品迭代節奏，在需求對接時請一定要共享各個配合團隊之間的工作流程節奏，建立需求溝通反饋機制，明確需求的確認節點，同時及時同步需求方小伙伴的產品預期。

坑二：不要讓產品處于黑箱狀態

做產品時很容易沉浸于邏輯細節，而疏忽實際場景的體驗細節。業務團隊的預約產品需求是為了配合線下產品推廣，線下場景的產品入口為一個二維碼，而用戶的實際購買場景多樣，當用戶脫離了線下的推廣場景以后想再次購買的時候發現

找！不！到！產品入口！

從而丟失了此部分用戶。同時當用戶完成產品的整體購買體驗流程后，除了頁面的預約成功提醒，用戶并未收到任何可自動存檔的預約信息，當用戶想查閱自己的預約信息時依然是

找！不！到！入口！

發現問題后再綜合實現成本、產品特性、業務邏輯，筆者又拉著研發同學們熬夜接入產品預約通知短信以及在公眾號下面添加二級標簽的預約入口。

在產品設計時一定要明確產品觸達用戶的路徑，在用戶想喚醒產品的時候能夠出現在用戶預期的行為路徑當中。

坑三：上線前一定要在實際場景當中體驗產品

同研發同學們排了這么多的“坑”，順利的把產品上線以后，筆者剛剛松了一口氣。然而，務團隊的同學給筆者截了一個圖：

最下面，預約按鈕，去哪里了？廣！告！什！么！鬼！

再看一張清晰一點的，圖片下部，運營商“中國電信”的廣告啊，偏偏從底部彈出，把重要的按鈕擋住了。

被梅沙教育的同學們一通嫌棄，經研發同學鑒定，以后是網站被劫持，需要把協議從Http變更為Https。

什么是Https?

大致可以理解為我們訪問網頁的時候，我們使用的瀏覽器要和服務器有一個信息交流，瀏覽器使用的是四川話，服務器使用的是東北話，雙方為了能保持暢通的交流約定大家溝通時統一使用普通話，這里的普通話大致就可以理解為Http協議的意思。

瀏覽器和服務器在交流的時候，中間會通過路由器來傳話。由于大家說的都是普通話所以路由器就會被別人劫持，篡改了服務器與瀏覽器的溝通內容，所以我們看到的頁面就會有廣告。

Https協議是瀏覽器和服務器約定的一種加密的交流方式，可以理解為：瀏覽器和服務器剛好都在溫州上過學，兩個人剛好都會說溫州話，而路由器不會說溫州話所以就無法篡改服務器與瀏覽器的交流，這樣就保證了服務器與瀏覽器的對話環境，隔離了廣告植入的可能！

http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。

http的連接很簡單，是無狀態的。HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全。

經過一番盲眼踩坑之后終于保證產品有驚無險的開始接客了。

最后BB了這么多，大概意思如下：

1. 需求階段要和需求方（業務團隊、Boss等等）保持溝通順暢，建議大家先和需求方建立溝通機制，具體方式不限制：可以是每天一個10分鐘的小會、可以是郵件、可以是任何準確傳達需求的方式等；

2. 設計階段要能準確傳達設計需求，原型輸出采用真實的數據，保證文案精煉、設計風格預期明確；

3. 研發階段保證業務邏輯能準確傳達無歧義，邏輯規則清晰、頁面狀態無遺漏，同時及時同步研發進度保證實現進度；

以上，期望對各位有所幫助，同時筆者目前正在摸索上線我們教育產品的第一版當中，期望未來的她能帶給你我一點點幸福感！

這就是一個年輕的產品經理反思成長的過程。要是在騰訊，從P2.1打怪升級到P3.1，通常需要3-5年；而創業公司，則等不起那么長的時間，而是需要促使產品經理快速成長。

作者：梅沙 Alex Niki

本文由@梅沙 Alex Niki原創發布于人人都是產品經理。未經許可，禁止轉載。