iOS程序員眼中的首次使用產品體驗

2017.11.23

一. 前言

首先想說一下爲何寫這篇文章：

• 《啓示錄》這本書曾提到：若是開發的產品沒有市場價值，那麼不管開發團隊多麼優秀也無濟於事。那麼一樣的，在咱們程序員費盡周折抓取各類數據，嘗試不一樣的技術方案只爲了讓冷啓動快0.1秒的同時，可能在產品層面稍微一個小技巧就能讓用戶感受這1秒過得更快，那咱們程序員進行代碼層級的優化以前是否是最好思考一下產品層面的優化呢？

• 有數據統計，App安裝前三天，平均流失77%的日活躍用戶。由於新用戶是沒有耐心的，他不知道你的產品可否給他們帶來便利，提升效率，產生價值，帶着這種懷疑的態度使用App過程當中，可能一丁點的的不爽、彷徨就致使用戶卸載了App。就比如相親，若是外在的皮囊在第一時間讓對方感到不適，那麼不管你的內在的靈魂多麼有趣也是無濟於事（除非你是個會吹牛逼的程序員🤓）。換個角度來說，可能整個App的產品設計很棒，代碼設計和優化也作到了極致，可是由於用戶第一次使用感受使用起來太複雜，跟預期相差太遠，就致使用戶還沒體驗到核心模塊就卸載了App。

• 你只有一次機會給別人留下好印象，一樣的，近年來手機、電腦、無人機等數碼產品也愈來愈重視開箱體驗，好比能夠研究下錘子手機的包裝設計和內置配件的排列布局，也是經過這樣的第一視覺衝擊提供更好的用戶體驗。

• 可能有人會以爲，「產品🐶工做的一部分就是優化以上所講的用戶體驗，程序🐒寫好代碼就好了」。然而在有些產品和設計上的原生樣式規則，程序員是應該比產品和設計師更清楚的

  • 好比有次設計師提了個需求：要求原生彈框的肯定設置爲加粗Medium的顏色，取消設置爲普通regular顏色。固然，這個需求站在設計師的角度來說是合情合理的：90%的人(用戶)都是右撇子，產品自己具備引導和指望性質的button放在右邊，同時顏色上更醒目

    

  • 但問題是美團的彈框是自定義的，對於原生的Alert彈框按鈕類型而言，有三個枚舉值：

    • UIAlertActionStyleDefault:Apply the default style to the action’s button.
    • UIAlertActionStyleCancel: Apply a style that indicates the action cancels the operation and leaves things unchanged.
    • UIAlertActionStyleDestructive:Apply a style that indicates the action might change or delete data.

      

      

  • 從代碼實現層面來說，無非是換一下按鈕枚舉值，可是違反了蘋果的官方規範可能後形成意想不到的問題，好比iOS11升級後，發現項目中有這樣一個問題

    

    

  • 這是 UITableViewCell 對應的一個 UITableViewRowAction，其對應的style也有三個：

    • UITableViewRowActionStyleDefault:Apply the default style to the button.
    • UITableViewRowActionStyleDestructive:Equal to the default style.
    • UITableViewRowActionStyleNormal:Apply a style that reflects standard non-destructive actions.

  • 後來查明緣由就是以前的代碼把刪除對應的style設置成了UITableViewRowActionStyleNormal，改成UITableViewRowActionStyleDestructive才得以修復該問題，由於執行刪除後，數據源及cell已進行了刪除更新操做，可是UITableViewRowAction對應的動畫效果倒是UITableViewRowActionStyleNormal，所以會形成上面的問題

  • 可是這個手誤是在iOS11 新增的交互動效上才暴露出來的，在以前的系統上是沒有問題的，所以我拒絕了那位設計師，確實可能會埋下一些隱患，除非整個 App 的 Alert 風格都改成自定義😅

二. 各類權限彈框的處理邏輯

在互聯網上半場，不少不精細的產品中存在這樣一個問題：用戶首次下載後咔咔咔三四個權限彈框接連彈出，這就好像你跟女神第一次見面，對方還沒說話，你就笑嘻嘻地問：「妹妹家有幾口？從哪裏來又到哪裏去啊？能夠加個微信麼？要不要考慮作我女友啊？」

1. WLAN與蜂窩權限

iOS10之後，因爲工信部的要求，在國行手機上用戶首次下載App，須要向用戶請求網絡權限，針對該彈框，有如下幾個問題：

• 開發者不能判斷該彈框的狀態，也不能主動觸發該權限的請求，在蘋果爸爸面前，依舊是「人爲刀俎，我爲魚肉」

• 蘋果官方的bug：畢竟是臨時改需求，有時候第一次下載該彈框沒有彈出，致使App一直不能聯網，App對應的權限列表也沒有WLAN和蜂窩權限，目前在iOS11上測試屢次，目測該bug已修復

• 有的用戶習慣性拒絕，小手一抖就不容許訪問網絡了

蘋果是爸爸，可用戶也是大爺啊，針對以上問題，常規的處理方式是這樣的：

• 在檢測到沒有網絡的前提下（無網絡訪問權限/手機確實沒有聯網），告知用戶多是由於網絡權限問題致使的無網絡狀態，並向用戶提供解決方案：
  1. 給出設置路徑，讓用戶手動到達路徑並更改網絡權限
  2. 點擊按鈕直接跳轉到該 App 設置界面修改網絡權限

我我的通常是使用第二種，由於通常用戶手機裏面都有不少App，手動查找太費勁了，可是微信倒是讓用戶手動去查找，這點我不太明白，如哪位大佬看透還望告之(QQ的大部分權限是直接跳轉的)

• 但這裏還有一個硬傷：各類權限修改以後，再次進入 App，就會回到首頁，至關於進行了一次冷啓動。至於這個現象的緣由，我的猜想：假如如今正在使用麥克風錄音，用戶卻進入設置界面關掉了麥克風權限。你讓蘋果爸爸怎麼處理這個尷尬的局面？

• 對於特殊狀況，好比該 App 沒有彈出網絡權限彈框，對應的設置界面也沒有網絡權限，一下是各類偏方：

  • 多進行幾回打開、殺死App的操做，在這過程當中有必定概率會彈出網絡權限彈框
  • 先進入設置界面隨便關掉一個App的網絡權限，而後再進入目標App設置界面，對應的網絡網絡權限就顯示出來了
  • 簡單粗暴的重啓必定好使！！

2. App中重要且緊急的權限獲取

好比導航類產品的地理位置權限、修圖軟件的相冊權限、時間管理類軟件的日曆權限。針對這種**「缺了你不行」**特徵的App，除了網絡權限沒法控制以外，其餘全部權限最好先不要觸發，能延遲儘可能要延遲，只留這一個權限選擇，最好在給出必定的提示

3. 其餘重要不緊急的權限獲取

• 好比IM聊天軟件中麥克風權限，普通工具類App中相冊權限（好比針對換頭像這種功能）。用戶須要正常進行這些操做須要對應的權限，可是不該該在App 第一次啓動的時候就馬上去請求權限。

• 對於這種重要不緊急的權限，通常都採起懶加載的方式，也就是等到用戶探索到這個功能的時候，主動觸發去發送請求。在用戶暫時還不須要這個信息的時候，千萬別給他提供！就像平時的待人接物同樣，要給對方想要的，而不是你認爲他想要的

三. 登陸相關的優化

1. 免登錄邏輯

• 登陸註冊功能自己就是對用戶的一個限制，在用戶還未體驗到你產品價值的時候，卻讓用戶提交我的信息進行註冊，這顯然是不合適的。

• 所以，除非是即時通信相似的與帳號強關聯的App，其餘App最好都要進行免登錄操做：先向用戶展現一部分基本的功能，當用戶觸發了與帳號強關聯的操做(好比評論、買單等)，再去提示用戶進行登陸註冊操做

• 以前作過一個工具類App，用戶剛下載就要進行登陸註冊操做，統計數據顯示在注這部分流失掉的用戶爲10%之多！

• 關於免登錄，以前寫過一篇文章：iOS程序員眼中的客戶端免登錄，在此再也不贅述

2. 登陸相關的優化

• 若是用戶以前在該手機登錄過，在不須要考慮安全前提下，能夠給用戶提供更便捷的登陸方式，或者對用戶進行提示（諸多第三方登陸選擇，可能用戶隨便點了一個，下次就忘記了）

  

該功能通常使用UDID來實現，關於這個有個小插曲，在 iOS 10.3 版本的 beta 2 - beta 5版本中，keychain 中的數據會由於 APP 的刪除而刪除，當時趕忙找其餘替代方案，調研了知乎、領英以後，發現用的不是簡單的keyChain，而是 iOS9 推出的SFSafariViewController，這個能夠將密碼、共享Cookie、iCloud Web表單數據、證書等存儲在系統裏面，與 iCloud keyChain 進行綁定。最後代碼寫的差很少了，發現 10.3 beta 6 版本，keychain 又能夠繼續使用（10.3正式版也是如此）。

• 在登陸註冊的整個過程當中，儘量地減小用戶的操做(最開始有信電話是這樣作的，後來滴滴改版也變成這樣；AppleID 新設備登陸須要的驗證碼也是這樣的)：

  • 好比用戶輸入11位的電話號碼後通過正則判斷有效後，直接觸發獲取驗證碼按鈕的操做，光標進入驗證碼輸入框
  • 輸入短信驗證碼後直接觸發登陸操做
  • 也就是在整個過程當中，用戶只須要輸入電話號碼和驗證碼，不須要其餘任何切換的操做

• 其餘的諸如格式自動檢測、小屏幕適配、用戶手感上的優化在此再也不贅述

四. 引導用戶瞭解核心功能的使用

1. 用戶下載以前

通常狀況下，用戶經過社交媒體、產品運營活動或者App Store接觸到產品，經過這個首次接觸，會對產品創建一個初步認識，若是在這些途徑中，你所描述的產品核心價值成功打動了用戶，並進行下載操做。

2. 用戶下載以後初步使用

《用戶體驗要素》這本書提出：最底層的架構是用戶需求和網站目標同樣，推進新手引導設計的緣由也有兩個：用戶需求和產品目標。對於新手引導來講，用戶需求是快速、愉悅地學習使用產品。產品目標是將新手用戶快速轉化爲活躍度高、黏着度高的忠實用戶。

新手引導要維持這兩方面的平衡，根據各自產品特性進行不一樣的引導操做：

• 內容社區類產品，開始用戶是沒有數據的，所以要首先給用戶展現內容定製界面
• 工具、遊戲類 App 就要引導用戶成功使用一次核心操做，在引導的過程當中最好完成一次階段性流程就給予用戶必定的鼓勵

引導頁與App Store 推廣圖相似，在此不作討論

• 在這個過程當中最好對用戶行爲進行更細化的統計並追蹤結果，根據各類統計數據分析用戶流失的緣由，從而不斷優化引導的流程
• 在第一次打開App或者用戶第一次登陸成功後，可能要下載一些歷史數據（好比微信登陸成功後要下載部分歷史消息、通信錄數據），技術能夠在這方面儘量地作優化；設計層面也能夠考慮增長一些動效，讓用戶在心理上感受時間過得很快（若是亞馬遜網頁下載速度慢 1 秒鐘,1 年就有可能損失 16 億美圓；若是谷歌提交搜索結果的時間延遲 0.4 秒,一天的搜索量就會減小 800 萬次；好吧，這個浮躁的快節奏世界🙃 ）
• 固然，在用戶完成第一次使用App以後，運營方面也能夠作一些諸如電話回訪、短信通知紅包下發、push推送活動信息等喚醒用戶操做

五. 寫在最後

• 產品懂技術，就像流氓會武術。技術會點產品，就像會武術的人去耍流氓👻👻👻
• **雷軍曾經說過：若是寫代碼沒有寫詩的感受，那就轉行作產品經理吧！**雖然確實沒有寫詩的感受，可是有時候把用戶的感受歸入進去，對每個小的功能點都保持着敬畏感，把人做爲中心點去考慮而非代碼，好吧，我編不下去了🤣🤣。。工頭喊我搬磚了

感謝閱讀。