所謂方法論就是框架。這個是有的，但要具體問題具體分析。
本文會總結工作中用到的所有方法論和遇到的坑，幫助可以在以後的設計中做更合理的決策。（這款產品是為公司教研團隊開發，用於梳理集思學院的學生狀態和反饋，這是教研日常工作的一部分，所以下文“使用者”為公司“教研團隊”）
一 客戶旅途圖
客戶旅程圖能幫助設計師深入解讀教研在工作中的互動節點。覆蓋了他們的目的、互動、障礙。專案開始的時候就引導教研的小夥伴繪製他們工作中的旅途圖（非常簡單哈，甚至可以不用圖形）。旅程圖可以十分有效的幫助設計師在設計專案各個階段確定一些十分有效的的互動節點。
我們有時候經常陷入一種誤區，很多時候我們在設計的時候理論上這個是可行的，但是實際工作中確難以達到我們預期的效果。旅程圖可以有效的幫助我們的產品避免出現和產品格格不入孤立的接觸點，同時可以幫助我們理解使用者的多個步驟的複雜操作。客戶旅途圖可以幫助我們理解使用者的複雜的體驗，讓我們設計更符合使用者思維。
主要流程
1 選擇你的目標使用者，並詳細描述他們
2 使用者角度標註他們所有產生互動的點
3 描述問題，使用者過程中用到的問題是什麼，使用者遇到這些問題在整個使用過程中式怎麼樣的一個情緒變化
4 使用者接觸到的所有的接觸點，新增能改善的關鍵節點
工作中畫的草圖
二 KANO 模型
產品設計初期，你會發現需求像雪花一樣飛來，無論你怎麼羅列，需求表單卻一直不停的增加，好像什麼的功能都是不可少的，但是不可能所有的功能一併開發上線。面對這樣的情況你需要把需求排序，KANO 模型是我用的最多的一個模型。
簡單介紹一下Kano模型，日本教授狩野紀昭(Noriaki Kano)在1984年首次提出滿意度的二維模式，構建出kano模型。將影響因素劃分為五個型別，如下圖所示：
KANO 模型
魅力因素：使用者意想不到的，如果不提供此需求，使用者滿意度不會降低，但當提供此需求，使用者滿意度會有很大提升；
期望因素：當提供此需求，使用者滿意度會提升，當不提供此需求，使用者滿意度會降低；
必備因素：當最佳化此需求，使用者滿意度不會提升，當不提供此需求，使用者滿意度會大幅降低；
無差異因素：無論提供或不提供此需求，使用者滿意度都不會有改變，使用者根本不在意；
反向因素：使用者根本都沒有此需求，提供後用戶滿意度反而會下降；
所有我們必須先滿足使用者的必備因素。這部分功能是最基本的功能，如果不具備，使用者的滿意度將大幅下降。然後則是去儘量滿足使用者的期望因素，這是質量的競爭性因素，提供使用者喜愛的額外功能，加強使用者的好感。最後則是爭取滿足魅力因素，這是錦上添花的作用，可以提升使用者忠誠度。
三 敏捷開發、快速迭代
其實真正的想說的是第三個方法。花最快的時間把整個邏輯跑通，然後快速上線，約團隊小夥伴一起測試使用，最好給到內側使用者深度使用。不要怕產品簡陋和bug，好的產品一定是不斷迭代出來的。
什麼是敏捷開發？
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。
我們設計前期就把整個系統分為3塊，開發其中一塊開發時候不影響另一塊的使用。
敏捷是對整個產品領域需求的高效管理；是短週期的不斷改進、提高和調整；是突出重點、果斷放棄當前的非重點；是每個迭代週期對需求的重新稽核和排序。
工作中最長用的工作方法其實是試錯和迭代，一個想法停留在腦海裡面的時候我們是判斷不了對和錯的，需要快速執行上線，所以半成品也是可以出門的，一定不要吝惜產品發版，醜媳婦才需要儘早見公婆。儘早的讓使用者去評判你的產品，你的設計是否可以贏得使用者的喜愛。快速迭代，緊盯使用者反饋，快速跟你的團隊和使用者調整戰略。
所謂方法論就是框架。這個是有的，但要具體問題具體分析。
本文會總結工作中用到的所有方法論和遇到的坑，幫助可以在以後的設計中做更合理的決策。（這款產品是為公司教研團隊開發，用於梳理集思學院的學生狀態和反饋，這是教研日常工作的一部分，所以下文“使用者”為公司“教研團隊”）
一 客戶旅途圖
客戶旅程圖能幫助設計師深入解讀教研在工作中的互動節點。覆蓋了他們的目的、互動、障礙。專案開始的時候就引導教研的小夥伴繪製他們工作中的旅途圖（非常簡單哈，甚至可以不用圖形）。旅程圖可以十分有效的幫助設計師在設計專案各個階段確定一些十分有效的的互動節點。
我們有時候經常陷入一種誤區，很多時候我們在設計的時候理論上這個是可行的，但是實際工作中確難以達到我們預期的效果。旅程圖可以有效的幫助我們的產品避免出現和產品格格不入孤立的接觸點，同時可以幫助我們理解使用者的多個步驟的複雜操作。客戶旅途圖可以幫助我們理解使用者的複雜的體驗，讓我們設計更符合使用者思維。
主要流程
1 選擇你的目標使用者，並詳細描述他們
2 使用者角度標註他們所有產生互動的點
3 描述問題，使用者過程中用到的問題是什麼，使用者遇到這些問題在整個使用過程中式怎麼樣的一個情緒變化
4 使用者接觸到的所有的接觸點，新增能改善的關鍵節點
工作中畫的草圖
二 KANO 模型
產品設計初期，你會發現需求像雪花一樣飛來，無論你怎麼羅列，需求表單卻一直不停的增加，好像什麼的功能都是不可少的，但是不可能所有的功能一併開發上線。面對這樣的情況你需要把需求排序，KANO 模型是我用的最多的一個模型。
簡單介紹一下Kano模型，日本教授狩野紀昭(Noriaki Kano)在1984年首次提出滿意度的二維模式，構建出kano模型。將影響因素劃分為五個型別，如下圖所示：
KANO 模型
魅力因素：使用者意想不到的，如果不提供此需求，使用者滿意度不會降低，但當提供此需求，使用者滿意度會有很大提升；
期望因素：當提供此需求，使用者滿意度會提升，當不提供此需求，使用者滿意度會降低；
必備因素：當最佳化此需求，使用者滿意度不會提升，當不提供此需求，使用者滿意度會大幅降低；
無差異因素：無論提供或不提供此需求，使用者滿意度都不會有改變，使用者根本不在意；
反向因素：使用者根本都沒有此需求，提供後用戶滿意度反而會下降；
所有我們必須先滿足使用者的必備因素。這部分功能是最基本的功能，如果不具備，使用者的滿意度將大幅下降。然後則是去儘量滿足使用者的期望因素，這是質量的競爭性因素，提供使用者喜愛的額外功能，加強使用者的好感。最後則是爭取滿足魅力因素，這是錦上添花的作用，可以提升使用者忠誠度。
三 敏捷開發、快速迭代
其實真正的想說的是第三個方法。花最快的時間把整個邏輯跑通，然後快速上線，約團隊小夥伴一起測試使用，最好給到內側使用者深度使用。不要怕產品簡陋和bug，好的產品一定是不斷迭代出來的。
什麼是敏捷開發？
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。
我們設計前期就把整個系統分為3塊，開發其中一塊開發時候不影響另一塊的使用。
敏捷是對整個產品領域需求的高效管理；是短週期的不斷改進、提高和調整；是突出重點、果斷放棄當前的非重點；是每個迭代週期對需求的重新稽核和排序。
工作中最長用的工作方法其實是試錯和迭代，一個想法停留在腦海裡面的時候我們是判斷不了對和錯的，需要快速執行上線，所以半成品也是可以出門的，一定不要吝惜產品發版，醜媳婦才需要儘早見公婆。儘早的讓使用者去評判你的產品，你的設計是否可以贏得使用者的喜愛。快速迭代，緊盯使用者反饋，快速跟你的團隊和使用者調整戰略。