本文從產品角度出發，深入探討了如何發起交互設計。通過明確產品目標與用戶需求、進行用戶研究、構建信息架構、設計流程與界面、進行原型測試以及持續優化等關鍵步驟，闡述了如何打造出滿足用戶期望、提升用戶體驗并實現產品目標的交互設計。
在當今數字化的時代，產品的成功不僅僅取決于其功能的強大，更在于能否為用戶提供流暢、愉悅且富有價值的交互體驗。從產品角度發起交互設計，意味著將用戶置于核心，以實現產品的商業目標和用戶需求的完美融合。
產品目標是交互設計的起點，它決定了設計的方向和重點。產品經理需要與團隊共同明確產品的定位、市場需求以及預期的商業成果。例如，是旨在提高用戶活躍度，還是增加用戶轉化率，或者是提升品牌形象。
通過市場調研、用戶反饋、競品分析等手段，深入了解目標用戶的行為習慣、痛點和期望。這不僅包括對用戶顯性需求的捕捉，還包括對潛在需求的挖掘。
基于收集到的數據，構建詳細的用戶畫像，包括用戶的年齡、性別、職業、教育背景、使用場景等特征，以便更精準地理解用戶的行為和需求。
模擬用戶在不同場景下與產品的交互過程，發現可能存在的問題和優化點。
我們要知道，地鐵周邊美食，這是一個解決方案。真正的需求是什么？一個字一個字地找需求，地鐵=快速方便出行，美食=和朋友一起吃飯/自己一人吃飯。這是一個和線下場景很相關的項目，我們要把不同目的核心用戶的主要使用場景寫出來。經過分析，我們得出了用戶會選擇我們產品，且產品未來可能存在的各種場景A、B、C、D、E。如下圖所示：
如果按照目標人群所在場景分類，進行細分，則為下圖：
乘地鐵去地鐵站和附近地鐵站區別：前為用戶會乘坐地鐵去目的地尋找美食；后為用戶不用地鐵/吃完后使用地鐵，地鐵邊美食沒有其他美食團購產品有競爭力。
上班族和普通大眾區別：上班族工作日使用固定地鐵站上下班，時間可能緊急，快速獲取食物；普通找美食吃的大眾不使用固定地鐵站，目的是通過地鐵快速到達某目的地，就近享受目的地美食。
朋友們和個人區別：朋友們一起吃飯，容易出現喝多、吃過點等異常行為，并且在選擇地鐵旁吃飯地點時需要考慮朋友們家的位置就近選目的地。個人均不需要考慮以上，較為自由。
經過領域場景的分析，我們知道了真場景都是用戶有目的乘坐地鐵去到某地鐵站出站口尋找美食的。那么我們對這么一群大眾進行用戶人口統計學類的細分：
-
上圖為前期定位的目標大眾用戶群，依靠地鐵的工具屬性，我們得出了具體的兩個影響因素：時間+美食熱愛程度。同時我們把直接競品和間接競品一同進行用戶群比較。可以看到和大美團有相同和不同維度，這就是產品最初冷啟動時期的差異化！也就是我們的前、中期場景的主要目標用戶類型。
-
紅色部分即種子用戶群，以這些群體為冷啟動階段，可以更快的向四周擴張。因為他們有使用地鐵的時間屬性，同時有較高的美食熱愛程度，有利于帶動其他時間+熱愛程度的用戶加入產品，實現快速并有質量的拉新、活躍的目標。
-
低端直接競品即用戶群工具屬性明顯，只是搜地鐵站，選擇美食的用戶，無明顯其他行為；高端競品即注重社交、ugc為起點，逼格高的搜尋美食工具。這部分開始很難，工作量巨大，且較脫離大眾主流群體。
結合上圖和要做的場景，我們得出了產品具體目標用戶：乘坐地鐵快速到達并尋找目的地美食的大眾用戶（上班族休息日，大學生，個人或一起），要求在地鐵站附近便能方便享受目的地美食。且對美食有一定熱愛程度。
邀請真實用戶進行產品試用，觀察他們的操作行為，收集反饋意見，為后續的設計提供依據。
需求很有可能是在線上接到的，并不是面對面交流傳遞的，并且還會遇到很多坑，例如需求本身不具體，或者自己理解有偏差，因此在接到需求后，最好和交互、產品等同事進行面對面的交流和溝通。
詳細了解測試目的和關鍵點，確定用戶配比。
最好是讓交互帶著跑一下整個程序（半成品demo也好，交互稿也行），這樣能在頭腦中快速形成操作流程的認知，并把相應關鍵點對應上去。同時把大致的用戶配比情況敲定一下，后續就可以直接招募用戶了。
了解demo的完成進度，相應確定具體測試時間。
交互、視覺等完成demo的時間具有太多不確定因素，因此我們需要及時了解整個demo的完成進度，在盡可能快的情況下保險安排測試時間，如果邀請的是外部用戶，結果用戶到了而demo還沒出來，那也是夠了。
讓交互稿幫助自己
。在完成測試方案撰寫的過程中demo還未誕生，具體程序細節記憶又很模糊，不好寫測試方案，怎么辦？不要慌，去看交互稿吧。
及時溝通
。在方案撰寫過程中，如果有一些疑問，例如在看交互稿的時候還不是很理解某個具體操作過程，或者自己對產品有疑問的也可以跟交互等溝通，因為自己會遇到的問題，很有可能在測試用用戶也會遇到，這樣子用戶如果問到了，就可以相應作出解釋。
核實確定方案
。完成方案后，可以在公司溝通交流工具上和交互及產品等同事再確認一下，是否有什么地方遺漏或有不妥之處。
這是一個大多數人都頭疼的一個過程，希望看完了以下幾點，可以稍微緩解一下大家的癥狀。
方案定下來后，再跟交互確認測試時間，了解是否有變動和調整，盡量避免用戶來了demo或者測試環境還不ok的情況。
需要把用戶要求、測試日期和地點、報酬、大致的測試時長、用戶需要在測試中做什么，以及報名方式等表達清楚。有以下幾點可以注意一下，方便我們自己招募：
-
詳細列出測試安排的時間段
。例如10:30-11:15、13:30-14:15，讓用戶自己挑選合適的時間段，這樣就不用事后再協調不同用戶測試時間了；
-
優先人力、信息管理、行政等崗位同事
。盡量避免相關產品人員、設計崗等同事。
-
制作簡單的招募海報，并檢查。
可以事先將“海報”用word或者ppt做好，然后保存成圖片格式，記得檢查核實一下是否有錯。因為在公司IM群上直接黏貼確實方便，但是其排版往往不利于閱讀，導致用戶會遺漏重要信息。而制作成圖片格式，可以更好地去避免這個問題，同時還可以顯得整個招募過程比較正式，突出了對用戶的尊重，也能在一定程度上體現我們用研工作的規范性。
內部用戶可以嘗試先在公司IM群組上招募，之前招募樣本量比較小，因此很快可以招到，其他途徑暫時未嘗試，公司論壇應該也可以，不過隱約感覺效率會比較低。外部用戶可以在朋友圈試試，效果還不錯，大家都很熱情幫忙轉發，群眾的力量大無窮。也可以相應去搜索一些QQ群，加入并發布招募信息。另外還有一些社交論壇什么的，都可以嘗試一下。方法很多，針對具體招募情況，大家就盡情發揮吧~
海報發出去后，有時也會出乎意料用戶數量超過預期了，這是好事，不要擔心，也不要急著拒絕，平和的跟對方說明情況，強調下次還會有測試，把用戶相應信息了解一下做個記錄，下次招募的時候可以直接先聯系這幾名用戶。當然前提是你真的有下次測試需求，如果沒有那還是老老實實說明情況。
確保自己和用戶能彼此聯系上
。
跟用戶強調測試時間和地點，尤其是外部用戶，如果招募和正式測試隔了幾天，最好在測試前一天再通知一下。給出自己的聯系電話，同時詢問用戶的聯系電話。
很多時候demo的完成情況會出現意外，到了測試時間demo還不能用，內部用戶可以方便取消或者更換。另外，在第一次測試前誰都不確定用戶會有什么反應，第一個測試是可以起到試水效果，而外部用戶成本高，用來試水太奢侈。
需要準備的內容有：量表、報酬簽收表、記錄筆記本、錄音筆、會議室借用，以及記錄表格，如果是外部用戶過來，相應準備一杯水，人家大老遠過來也不容易。
其實每次訪談用戶自己都會挺緊張的，不知道用戶是不是也很緊張（PS：好想當一回用戶，體驗一下被訪的感覺）。為了消除這種緊張，同時也是為了更好的完成訪談，可以有嘗試以下幾點：
-
盡可能多的去了解所需測試的產品
。有時候demo出來的晚，下午要測試，demo中午才出來，自己都沒玩過，測試還怎么搞？之前也說了，那就使勁去看交互稿吧，雖然比不上實際操作來的真實，但是也能有不小幫助，但也要給自己留足熟悉demo的時間。
-
按照模塊來列提綱
。其實相當于組塊策略，把同一個模塊的問題放到一起更方便記憶，并且也在訪談中也方便自己和其他同事發現遺漏點。但模塊不要太大，如果太大了就相應拆分一下。例如，在考拉新版測試的時候，有“首頁”、“活動”、“購物車”等測試，但是光是首頁內容也很多，作為一個模塊還是太大了，可以拆分成“首頁整體感知”、“商品詳情”等幾個方面來整理提綱。
-
根據任務演練提綱
。有了提綱后，按照任務大致過一下所有列出來的問題，這個過程會打亂按照模塊列好的提綱，有一次這樣的排練，在測試的時候更不容易漏掉題目，而且也相當于模擬了一下測試，自己心里會更踏實一點，在實際測試過程中也能有更好的應對。
通知交互和產品的同事具體測試時間和地點，邀請他們一起參與。不建議交互和產品只是后期測試查閱報告，如果他們參與到測試中，能更近距離和用戶接觸，并能更加深刻感受到產品存在的問題，也能更好的推動產品的改進。
-
劃分我們和產品的關系。在測試之前跟用戶說明清楚，我們并不是產品的設計者和開發者，我們只是受產品方委托來進行測試，以免用戶不好意思當面如實評價產品。
-
強調測試的是產品，而不是用戶。要跟用戶說明產品尚處于不完善階段，因此邀請用戶過來進行測試，幫助發現問題和改進產品設計，但請注意不是為了評價產品。
-
-
盡可能深入的去挖掘用戶的需求。不要停留在用戶話述表面，更進一步去追問，用戶為什么會這么說或這么問，例如，很多時候在測試中會碰到用戶說“哦，原來這個按鈕是xx功能，我還以為是xx功能“，這個時候可以再推進一步，了解用戶為什么會這么認為。
-
給其他在場的同時發言的機會。主持人如果覺得自己訪談的差不多了，可以詢問一下記錄者以及交互、產品等同事，了解他們是否還有問題需要補充。
-
記得量表評分和報酬簽收。長時間的測試和訪談后容易忘記量表評分和報酬簽收，可以把這兩份東西放在顯眼的地方，另外可以讓記錄的同事打個招呼，幫忙提醒自己。
-
仔細觀察用戶行為并記錄。記錄不僅僅是用戶的觀點、想法等，更重要的是記錄用戶的實際行為。
-
按照模塊記錄。記錄者可以按照測試方案中的模塊來相應記錄用戶的行為和言語表述。
-
查漏補缺。主持人可能會遺漏一些點，記錄者作為旁觀者需要提醒主持人遺漏了什么，或者自己有什么新的內容需要補充。
歡送用戶。對用戶表示感謝，并開門送一下用戶，對于外部用戶，最好能送到大樓外面可以看見出口的地方。
測試后及時討論。這個是重點！
在每一名用戶測試后及時和交互、產品等同事快速過一下主要發現的問題點，這樣做有以下優點：
-
有效達成共識，確定解決方案。剛訪談結束印象最深刻，因此能快速有效達成對主要問題的共識，并討論確定相應的解決方案。
-
體現敏捷優勢。確定了一些比較嚴重的問題后，交互和產品的同事就可以相應去改進產品設計，做到了邊測邊改，加快迭代速度。
-
幫助優化訪談提綱，和測試用戶安排。有些問題在事先撰寫方案的時候可能沒涉及到，在討論后可以補充進去，而有些問題確定后則不需要再測。另外，也可以通過討論對事先安排的測試用戶進行相應調整，例如增刪用戶，或者調整新老用戶測試順序等。
-
事后幫助我們自己快速撰寫方案。通過討論確定了關鍵問題，并且，交互和產品的同事也相應清楚了，因此在最后可以快速形成報告。
再次感謝用戶。所有用戶測試結束后，可以花幾分鐘時間簡單感謝一下用戶。
針對不同大小項目的用戶測試，在完成報告撰寫過程中有兩種具體方式：
-
小測試項目簡單快速撰寫報告。對于那些1-2天的小測試項目，由于在每次測試后都有討論，已對主要問題達成共識，因此在報告撰寫的時候就可以快速地將主要的問題和風險點呈現出來。
-
大測試項目每天總結并反饋主要問題。大的測試項目持續時間比較久，針對每天的測試及討論，簡單總結一下主要發現的問題，并反饋給相關人員，如果到了最后再總結，容易遺忘掉一些內容，并且這樣子也方便自己最后撰寫報告。
思考信息架構有三個核心關鍵詞：用戶角色、產品價值、使用場景。
用戶角色清晰揭示用戶目標，幫助我們把握關鍵需求、關鍵任務、關鍵流程，看到產品哪些是主要的事，哪些是次要的事。我們應該盡可能豐富、形象化我們的用戶角色，讓它在設計決策過程中發揮作用，設計出更符合用戶場景的產品。
作為產品的設計師一定要理解產品的價值，知道用戶想要什么，把最重要的優先級提到最高，盡量移除無關緊要的信息，或降低其他優先級的權重，以免對用戶造成干擾。
要了解產品的業務流程，比如目標用戶是誰、什么場景、如何使用，要把產品業務流程上的節點一個一個梳理出來，還要考慮這個產品對用戶的價值是什么，不要僅僅考慮界面的元素規范、設計細節等等，要知道產品的目標價值體系。
基于三個核心點（用戶角色、產品價值、使用場景）分析，把目標用戶人群核心價值的功能點業務流程梳理出來，分清主次關系，切忌功能堆砌，具體方法可以把所有功能業務邏輯的主線列出來，然后根據業務的優先級做評級，分清楚這些功能哪些是主要的，哪些是次要的，然后通過數字做排序，這樣我們就知道哪些功能設計需要明顯，哪些功能設計需要低調。
從整體上思考信息類產品的分類及整合，比如用戶資料相關的產品會有用戶信息、資料、等邏輯，這樣就要把所有跟用戶相關的信息都歸在同一個分類菜單下，不要讓他們分散在各個頁面中。也就是所謂的一級菜單、二級產品的處理邏輯。
隨著產品規模與復雜度的提升，要隨時關注信息架構是否滿足當前的產品框架，不要等需要時候再去孤注一擲的全盤優化，這樣會讓項目陷入被動的局面，可以逐漸增強，循序漸進的優化，從小的細節對信息架構進行調整，提升產品的易用性。
使用快速原型工具制作可交互的原型，以便更直觀地展示設計方案。
團隊內部進行初步測試，檢查功能的完整性和流程的合理性。
邀請外部用戶進行測試，收集他們的意見和建議，發現潛在的問題和改進空間。
通過收集和分析用戶的使用數據，了解用戶的行為路徑和偏好，為優化提供數據支持。
及時響應用戶的反饋，將有價值的建議融入到后續的優化工作中。
根據數據分析和用戶反饋，不斷對交互設計進行迭代更新，以適應市場和用戶需求的變化。
從產品角度發起交互設計是一個綜合性的過程，需要充分考慮產品目標、用戶需求、信息架構、流程界面、測試優化等多個方面。只有以用戶為中心，不斷追求卓越的用戶體驗，才能打造出具有競爭力的產品，在激烈的市場競爭中脫穎而出。
在未來的產品開發中，隨著技術的不斷進步和用戶需求的不斷變化，交互設計也將面臨新的挑戰和機遇。產品團隊應保持敏銳的洞察力和創新精神，持續探索和優化交互設計，為用戶創造更多的價值。
作者：Charlotte的嘻醬
鏈接：https://www.zcool.com.cn/article/ZMTYyNzM1Mg==.html
來源：站酷
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
