起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識小需求的管中窺豹——微信AA備注
嗯，首先說明，這是個很小的需求（畢業(yè)半年多接觸的多是一些小需求），按理沒什么好寫的。但是之前寫過一篇做用戶體驗設(shè)計的文章后，慢慢有了一些心得，有時候一些小的需求也會有靈光一現(xiàn)的時候，管中窺豹，覺得之前的文章方法還是有所用途，所以總結(jié)一下思路。
一．戰(zhàn)略層
為誰做，為了什么。
戰(zhàn)略層包括商業(yè)目標和用戶需求。
為什么做這個？
當時正值開學(xué)季，一天產(chǎn)品突然找到我。
產(chǎn)品：samper，現(xiàn)在有這樣兩個事情。一個是最近一段時間很多家長都在反饋的問題，新學(xué)期開家長會，班主任用AA收款收班費，家長付款后顯示的是微信昵稱，都不知道是誰交的。不光是家長，很多旅游的群、臨時拉的吃飯的群也有這種問題哈。另外一個AA收款里面的代付，用戶幫好友代付之后顯示的還是自己頭像，收款人不清楚怎么回事。
我：現(xiàn)在的學(xué)校和家長都這么與時俱進？用AA來收班費哈哈。收班費的問題，很多微信群為了方便一開始就讓大家入群改昵稱的，讓用戶付款后顯示群昵稱吧。代付方面選擇微信好友再代付，再依此顯示出被代付者的群昵稱？
產(chǎn)品：首先，收班費直接使用群昵稱可能會有安全問題，其次代付選擇好友涉及好友關(guān)系鏈安全問題，目前內(nèi)部沒有開放這個權(quán)限。
……
2. 初步的需求分析
商業(yè)目標
這里的商業(yè)目標也可說是產(chǎn)品目標，很明顯，滿足用戶的需求，減少投訴量就是這里的產(chǎn)品目標。
用戶需求
產(chǎn)品作為需求的提供者，是對用戶和使用場景的第一手資料來源。我們應(yīng)該引導(dǎo)產(chǎn)品分享出更多的信息，這里初步發(fā)現(xiàn)用戶的需求有兩個，一個是幫助收款人清晰的知道對應(yīng)的付款人真實身份，另外一個是幫助收款人了解被代付者的身份。
3. 調(diào)研
產(chǎn)品的考慮未必代表真實用戶，我們還是需要“眼見為實”?？梢詮闹苓叺耐氯胧肿鲎稣{(diào)查。通過訪談得知，這種場景的確存在，但是很少，所以這里不適合作為一個強需求來做。
4. 詳細需求分析
產(chǎn)品側(cè)和調(diào)研都得到一定的信息后，我們需要對需求信息進行整理。這個從工作內(nèi)容和用戶的角度綜合來看，屬于優(yōu)化型的用戶痛點需求。
整合分析初步需求
其實針對上述問題已經(jīng)有理想的解決方案了，正是因為它們行不通，所以它們和用戶的需求共同構(gòu)成了新的問題。
整理一下從對話中得到的信息，我們能夠?qū)栴}進行初步的定義：這里說的問題貌似有兩個，分別說的是收款人不知道付款人的真實身份和收款人不知道被代付者的身份。又因為原本的理想方案無法實施，加上這個是少數(shù)需求不能影響大眾體驗，所以需要尋找各自相應(yīng)的解決辦法。
掉進解決方案的坑
剛開始產(chǎn)品建議讓付款用戶自己來添加備注，這個似乎很自然。但是因為考慮到這是少數(shù)人的需求，不適合對原有的頁面設(shè)計做太多改動，所以一直在糾結(jié)備注的位置。
如下圖左是微信AA收款新版頁面，右圖是舊版頁面，我們曾經(jīng)一度想恢復(fù)那個留言功能和下面的縱向排列頭像，僅僅因為契合我們的備注需求。
? ? ?
眼看AA的設(shè)計要走回頭路了，我這才冷靜下來想一想，我去，怎么又扎進解決方案的坑里了。問題的定義真的足夠清晰了嗎，清晰到能用一句話能概括出來？意識到自己的失誤之后， 我重新找產(chǎn)品交談了一次，拋開現(xiàn)在的方案和困境不談，從頭來梳理一下我們遇到的問題到底是什么。
到底要解決什么問題？
這里看似有兩個事件，但是實際上說的都是一個身份確認的問題， AA提供的是頭像+微信昵稱來確認身份，但是事件1收班費非好友頭像+微信昵稱無法表明付款人的真實身份，事件2代付的情況則是目前顯示的都是同一人頭像+昵稱，根本就無從確認身份。所以，這里的問題是收款人無法確認相應(yīng)付款人的身份，從而無法收齊款項。
我們再來回顧總結(jié)一下我們到底要解決什么問題：
我們要在理想方案走不通的情況下，另辟蹊徑，既不影響大部分的人的體驗，又要幫助特定場景下的AA收款人通過確認相應(yīng)付款人的真實身份來統(tǒng)計排除誰沒交錢，從而幫助收款人收齊款項。
在加上對于用戶使用場景的梳理，填寫表格如下：
要幫助特定場景下的AA收款人通過確認相應(yīng)付款人的真實身份來統(tǒng)計排除誰沒交錢，從而幫助收款人收齊款項。再加上對于用戶使用場景的梳理，填寫表格如下：
二．范圍層（怎樣來實現(xiàn)需求）
范圍層說的是功能和內(nèi)容，為了解決問題我們提供什么功能和內(nèi)容，也就是初步的解決方案。
1. 功能
考慮到身份直接對應(yīng)的就是姓名，所以這里考慮讓用戶直接修改昵稱來表明自己的身份。
2. 內(nèi)容
盡量簡單易懂，符合用戶常規(guī)認知，所以使用“備注名”一詞來提示用戶修改昵稱。為了不顯得很強硬的逼迫用戶修改，文字建議為“點擊頭像可設(shè)置備注名”，表示非必選項。付款人代付之后提示用戶“代誰支付”，用簡單口語化的詢問來提示用戶填寫代付備注。
三．結(jié)構(gòu)層（怎樣使用功能來實現(xiàn)需求）
結(jié)構(gòu)層說的交互設(shè)計和信息架構(gòu)，通常指的是產(chǎn)品的流程設(shè)計和頁面架構(gòu)。
1. 流程設(shè)計
流程設(shè)計就是設(shè)計用戶的行為，或者說是引導(dǎo)用戶的行為。
入口設(shè)計
作為一個新的功能上線，為了減少對大眾用戶的干擾，大規(guī)模的功能指引是不合適的。所以我們選定在用戶付款完成之后進行提示。提示的頻次也要仔細考慮，修改現(xiàn)有昵稱的場景較少，但考慮到AA本身頻次較低，所以考慮前期在每月第一次支付時進行提示。代付嚴格意義上來說是補全原有的環(huán)節(jié)，可以每次都進行提醒。
用戶操作流程
也叫用戶行為預(yù)設(shè)計。雖然解決的問題是一個，但是存在兩個場景，所以還是要分兩條流程來設(shè)計。這里需要按照用戶的心智模型來看：
修改現(xiàn)有昵稱
備注代誰支付
業(yè)務(wù)整體流程
我們需要把用戶的流程串聯(lián)起來進行觀察，加入業(yè)務(wù)邏輯思考，還有異常情況（如用戶修改失誤可快速再修改）。
2. 信息架構(gòu)
這里只是一個小的功能，并沒有涉及信息架構(gòu)的整理。
四．框架層(做成什么樣）
框架層是結(jié)構(gòu)層的具體表達方式。有了前面清晰的流程，這里主要考慮一些細節(jié)上的問題。
修改現(xiàn)有昵稱
- 為了降低干擾，支付后出現(xiàn)的提示框過幾秒就會消失。
- 按照原有的時間順序排序，當前付款人的頭像可能出現(xiàn)在一屏頁面之下，用戶可能根本注意不到提示，所以這里修改好友列表排序，始終將當前付款人自己的頭像置于首位，保證提示信息能夠及時被發(fā)現(xiàn)。
- 頭像和下方的藍色昵稱都可以點擊，擴大點擊區(qū)域，同時使用彈層進行昵稱修改，如有問題可以再次點擊快速修改，使得操作可逆。
- 原本設(shè)計最多輸入5個字符（主要是中文），但是考慮到輸入框無法識別中英文（英文姓氏一個字母也是一個字符），所以設(shè)計最多顯示5個中文字符的長度，超過部分以省略號形式代替。
備注代誰支付
代付和上面大同小異，被代付的頭像一開始加上代付標簽再提示用戶備注代誰支付。
五．最后
1. 排查
當設(shè)計完成后最好對自己的方案進行排查，這里可以使用尼爾森的可用性原則進行排查。
- 狀態(tài)可見原則：可編輯態(tài)采用藍色鏈接文字，點擊即可彈層修改，修改完立即看到修改結(jié)果。
- 環(huán)境貼切原則：使用了用戶常見的備注昵稱等語言。
- 撤銷重做原則：修改后如有問題可以再次修改。
- 一致性原則：修改操作前后一致。
- 防錯原則：通過提示框文字和彈層標題文字，盡量避免用戶出錯。
- 易取原則：用最簡短的文字引導(dǎo)用戶操作。
- 靈活高效原則：初級用戶提供直接提示，中級用戶通過文字鏈接色了解操作。
- 易掃原則：文字盡量簡短。
- 容錯原則：修改出錯可以再次返回修改。
- 人性化幫助原則：修改昵稱每月首次支付進行提示，代付每次進行提示。
2. 評審
即便在整個項目期間我們一直和產(chǎn)品保持交流，最后的方案評審也仍然可能遇到多方分歧。以備注名顯示字數(shù)為例，產(chǎn)品、視覺、我、重構(gòu)和前端都有各自的考慮。不要帶著一種說服的心態(tài)來辦事而是積極尋求共識，肯定大家的共通點，尋找分歧點。最終在體驗和技術(shù)的平衡下找到較好的實現(xiàn)方案。
總結(jié)
- 這里的確是一個非常小的功能，但是我自己還是很受啟發(fā)，尤其是當做了三四版解決方案之后才回過頭來重新思考問題的本質(zhì)，希望以后多注意少走彎路。
- 這里面也遇到了很多技術(shù)上的小問題，的確一開始考慮不周，造成了一些返工時間上的浪費，以后在思考時要更加腳踏實地的一步步驗證可行性。
- 自己之前摸索的設(shè)計方法在這里有所價值體現(xiàn)，希望以后通過更多的實戰(zhàn)經(jīng)驗來優(yōu)化。
?后記：文章中還是有很多細節(jié)沒有說清楚，例如本來的確是有簡單的理想方案，但是特殊原因行不通所以才要重新來設(shè)計，這個也是挑戰(zhàn)之一。本文的主要目的是并不是來說微信AA這個項目，是來分享心得，望知悉。
本文由 @jxwoosa?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。
一個弱弱的疑惑？
既然有列表可以顯示已交款用戶和未交款用戶，為什么一定要知道真實姓名才能通知催繳？點擊未交款的用戶頭像私聊催繳不行么？
是不是有點簡單問題復(fù)雜化了？
微信的需求就是細膩
思路很清晰，值得借鑒，幾點個人感受：
1.接到需求后進行用戶調(diào)研對需求進行更深入的理解，這一點很好，但是通過簡單的對幾個人進行訪談得出結(jié)論，似乎缺乏充分的依據(jù)；
2.明確需解決的問題后，進行功能定義時，直接得出通過修改備注來解決問題，分析與腦暴似乎做得不太充分，是否有其他的解決方案？
3.設(shè)計方案出來后，未作有效的用戶原型測試，方案的合理與有效性缺少一些驗證；
4.整個需求分析、功能定義的過程可以讓產(chǎn)品經(jīng)理、用戶研究、視覺等角色共同參與，減少方案設(shè)計過程中的分歧，得出共識的結(jié)論。
不知道為什么，看了好幾遍沒看懂。。。。
第四點“修改現(xiàn)有昵稱” 那里，為什么支付按鈕是“代朋友去支付”？