1、Mobile Website、Hybrid App、Native App的區(qū)別

• Native App：基于本地（操作系統(tǒng)）運行的APP，從應(yīng)用商店下載，不一定要聯(lián)網(wǎng)才可以使用，優(yōu)勢在于針對不同平臺提供不同體驗。

• Mobile Website：指基于Web的系統(tǒng)和應(yīng)用，通過手機瀏覽器APP進入，優(yōu)勢在于跨平臺開發(fā)。

• Hybrid App：看上去是一個Native App，但只有一個UI WebView，里面訪問的是一個Web App。優(yōu)勢在于既獲得不同平臺的良好用戶交互體驗，同時不需要通過在應(yīng)用商店來更新版本。

2、Android和iOS的優(yōu)缺點

Android與iOS的最大不同在于設(shè)備分辨率非常多，讓App在各個分辨率下適配良好是一件非常耗費時間的事。

Android的設(shè)備用戶數(shù)多，但是iOS的用戶價值高；

投入Android版本開發(fā)付出比iOS多， 因為適配分辨率帶來的影響；

iOS最大的劣勢在于蘋果冗長的審核機制（平均7天），使得敏捷開發(fā)很難推動；

而Google Play的審核機制就簡單的多，一般幾個小時內(nèi)就審核通過。

3、移動用戶跟網(wǎng)頁用戶的本質(zhì)區(qū)別

• 移動用戶是任務(wù)導(dǎo)向型

移動用戶解鎖手機后，是在尋找一個任務(wù)去完成目標，而網(wǎng)頁用戶則更多的是學(xué)習(xí)和探索。

• 移動用戶使用時間碎片化

  網(wǎng)頁用戶的使用場景是在工作或者放松環(huán)境，在過程中很投入且不會受到打擾。

  而移動用戶則是在碎片化時間內(nèi)完成一個個小任務(wù)，所以在移動產(chǎn)品設(shè)計時需要簡化步驟、手勢操作去盡可能提高完成任務(wù)的效率。

4、對設(shè)計規(guī)范指南有扎實的理解

Android界面設(shè)計規(guī)范和iOS人機交互指南是移動產(chǎn)品設(shè)計時最好的參考資料，提供了App可以遵循的通用設(shè)計規(guī)范，需要對不斷更新的移動設(shè)計和交互趨勢有深刻的熟悉度。

Android：

https://developer.android.com/design/index.html

iOS：

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/

5、使用MVP作為產(chǎn)品試錯的原因

使用某個功能的最簡化版本——最小可行產(chǎn)品MVP（minimum viable products ）來驗證早期的產(chǎn)品想法。

因為有許多混淆因素，會導(dǎo)致剖析用戶行為時受到干擾。如果沒有真正理解每個模塊之間是怎樣相互影響和驅(qū)動用戶行為的，那么做出完整功能的版本也是無意義的。

如果在MVP上做一個小改動配合A/B測試，就能夠很直接的發(fā)現(xiàn)這個改動與用戶行為之間的直接關(guān)系。這樣就可以通過用戶的正向或消極的反饋來驗證產(chǎn)品的想法，避免只靠假設(shè)做判斷。

6、為什么版本迭代要使用列車時刻表模式

就像列車的時刻表一樣，無論你現(xiàn)在是否已經(jīng)上車，列車都會按照時刻表準時離開。版本迭代周期需要常規(guī)化，提前設(shè)置好迭代間隔（比如1周），到達時間節(jié)點無論功能是否完成，都按照計劃上線。迭代的版本可能只是修復(fù)了一些bug，亦或者是全面優(yōu)化。

對比功能迭代的模式，列車時刻表模式減輕了許多壓力和不確定性。團隊知道每個版本的迭代時間點，盡管這個功能沒有100%的完成，也不會影響版本的迭代，只需要放到下個版本上線。這樣就會避免為了趕在時間節(jié)點上完成功能而粗糙編寫代碼，對于用戶體驗如此重要的今天，這種模式帶來的優(yōu)勢顯得如此重要。

7、應(yīng)用商店的約束

阻礙App成功的一些因素與應(yīng)用商店有關(guān)，因為當(dāng)團隊想要更新版本時，必須通過提交一個新的版本到應(yīng)用商店進行審核和上線，從而引起以下三個問題：

• 應(yīng)用商店的審核周期平均是一周

• 一次性讓所有用戶都更新

• 不能回滾到上一個版本

為了應(yīng)對這些問題，許多團隊會選擇每隔一兩個月更新一個大版本，而不是使用上述提到的小版本每周迭代。

這種大版本更新的模式就像回到了盒裝軟件的時期，不再是通過小版本迭代驗證產(chǎn)品想法而是投入很多人力去猜測用戶需要的是什么。

因為不能回滾版本，所以當(dāng)出現(xiàn)了一些嚴重Bug或者影響用戶體驗的問題時，就只能夠重新提交一個版本，而漫長的審核周期會使得處理這些問題的反饋變得很慢，也削減了整個團隊的信心。

8、Feature Flag功能發(fā)布控制

Feature Flag是一種允許控制線上功能開啟或者關(guān)閉的方式，通常會采取配置文件的方式來控制。

Feature Flag允許關(guān)閉未完成的功能，可以在主干上進行迭代開發(fā)，新功能即便未開發(fā)完成也不會影響發(fā)布，因為它對用戶是關(guān)閉的。

當(dāng)功能開發(fā)完成之后，修改配置便可以讓功能發(fā)布。這種操作甚至可以在線上進行，例如代碼已經(jīng)發(fā)布但功能不可見，你可以修改配置讓功能對特定的用戶(線上測試、小流量或者全量發(fā)布等)可見。如果發(fā)現(xiàn)新功能存在問題，那么可以通過配置文件來迅速回滾。

許多大公司都在使用feature flag，比如Uber使用feature flag來進行dogfood測試（讓全部員工來進行測試）、staged rollouts（測試5%的基礎(chǔ)用戶）、A/B測試、功能回滾。

9、一步步的建立流程規(guī)范

對于許多不成熟的移動團隊來說，會把精力都投入到功能的研發(fā)上，而忽視了流程的優(yōu)化。建立一個規(guī)范能夠系統(tǒng)的定義和發(fā)布更高質(zhì)量的迭代，每一個步驟的保證是獲得整體成功的關(guān)鍵。

10、產(chǎn)品優(yōu)化的工具

做定量分析，建立轉(zhuǎn)化漏斗可以知道用戶在哪個步驟流失，從而針對性做優(yōu)化；

做定性分析，通過用戶測試和用戶反饋，可以發(fā)現(xiàn)用戶在使用App的過程中，是否按照你的預(yù)期路徑在執(zhí)行，亦或是在某些步驟有不理解和猶豫。同樣的，做用戶調(diào)研可以讓你洞察出用戶的痛點。

11、獲取App的途徑

App的發(fā)現(xiàn)途徑主要來自于兩種：

• 應(yīng)用商店

應(yīng)用商店搜索優(yōu)化（ASO）是根據(jù)用戶的喜好關(guān)聯(lián)度提升應(yīng)用的可搜索性，主要是通過優(yōu)化應(yīng)用名稱和關(guān)鍵字找準目標用戶。

• 社交分享

77%的移動用戶表示下載App是來自別人的推薦，相比之下，低于20%的用戶表示他們會從廣告或者媒體上下載App。

這意味著社會認同是吸引用戶下載的重要因素之一，可以通過一些工具比如Deep Linking來提升用戶加載的機會。

深度鏈接(Deep Linking)，這種技術(shù)主要是APP開發(fā)者通過主動內(nèi)嵌谷歌編碼的方式來讓Google發(fā)現(xiàn)應(yīng)用中的相關(guān)信息，促使不同APP間可以像網(wǎng)頁鏈接一樣產(chǎn)生平臺間的跳轉(zhuǎn)與瀏覽，簡而言之就是APP不再是獨立的個體平臺，更像是網(wǎng)站一樣可以相互友情鏈接的移動網(wǎng)絡(luò)媒介。

---

可以關(guān)注我的微信公眾號pmkuma ? 每天更新一篇原創(chuàng)產(chǎn)品文章

本文由PMCAFF產(chǎn)品經(jīng)理社區(qū)作者@Y醬 ?原創(chuàng)，未經(jīng)允許，禁止轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的移动产品经理必须要知道的11件事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。