DuoDo 讀多
舉辦、參與讀書會專用的 APP，協助招募主能集結志同道合的夥伴一起學習交流，讓讀書會能順利進行。
Responsibilities
User Research, Planning, UI/UX Design
Background
我經常參與讀書會，但市面上徵求書友的資訊四散在各個社群平台或論壇，讀書會進行中也需要用到多個工具輔助，沒有統一資訊的平台工具，便與另一個設計師合作，以此題目作為 side-project ，從需求挖掘開始，設計一個讀書會專屬工具來幫助使用者有效運行讀書會。
Goal
設計一個讓使用者可以發起、參與讀書會，並幫助發起人能招募到期望成員，讓讀書會順利進行的產品。
Challege
- 讀書會的舉辦形式有多種，設計上必須保持彈性。
- 團隊缺乏產品經理，自己擔任設計師也同時要兼任產品經理發想功能與制定規格與工程師溝通。
Design Process
Research
我們透過問卷來收集參與讀書會的人們在搜尋、發起、參與過程的流程與痛點，兩週內收集到 45 份有效樣本，並從中挑選參與最多次讀書會的前五名作為受訪者進行訪談。透過訪談資料，最終統整出兩種 Persona 和 User Journey：
Define
根據用戶研究，我們收斂最主要的幾個痛點：
- 讀書會招募資訊不集中，有些人沒有管道僅能問周遭朋友
- 讀書會的進行現況僅能使用通訊軟體溝通，搭配其他工具做紀錄，難有系統的整理每一次的聚會資訊。
- 讀書會的參與度逐次降低，出席的人越來越少，收穫品質不好。
我們假設，上述痛點產生的原因是由於：
- 沒有專門的平台讓使用者方便去尋找跟讀書會相關的資訊
- 沒有能提供適用讀書會情境所需要的工具
- 發起人難以驗證成員是否符合預期、沒有良好的機制去篩選讀書步調相同的成員，導致有些人因為品質中途退出，或讀完書但效果不好
Planing
為了解決上述的問題，我整理了這些需求，轉化爲 User Story 後規劃出產品的主要功能，分為三個部分：
- 探索圖書會 – 使用者可以瀏覽正在招募中的讀書會並加入，也可以自行發起讀書會。作為發起人有機制可以審核決定要哪些人加入他的讀書會
- 我的讀書會 – 可以互相討論、投票決議事情，並集中筆記資源，並設定聚會次數與閱讀範圍讓讀書會可以循序漸進。
- 個人資料 – 讓成員可以互相初步認識以外，勾選興趣清單可以第一時間推薦讀書會給有興趣的會員！
依照規劃的大功能，再往下規劃 Functional Map 流程：
Wireframe
發起讀書會
使用者可以發起讀書會，並設定為是否為審核制，透過人工挑選或是設置問題的機制，可幫助發起人挑選期望的經驗背景、或想法步調較為一致的成員，也可透過出席率參考過往參與度。
申請加入讀書會
使用者也可以從招募中的讀書會探索，瀏覽發起人與參與成員的背景與資料來決定是否要加入。
如果是需要透過回答問題來申請讀書會，申請加入時需要填入回答，並等待發起人的審核。
我的讀書會
可以在列表中瀏覽不同狀態的讀書會。
不同進度的讀書會有各自的資訊呈現：
進行中的讀書會會呈現目前完成度與下次聚會的資訊（或最新更新）為主。
發起人針對招募中的讀書會則可以看到目前有幾人已加入或申請、編輯，或是決定何時要成立讀書會。
已完成的讀書會可瀏覽過往紀錄與資源
進行中讀書會
聚會紀錄 – 設定好聚會次數、頻率時間與每次的閱讀範圍和導讀人，即可自動發出席調查，減少發起人或導讀人的例行事項！
參與投票 – 在需要調查時間或決議其他事項時也可以透過投票功能來決定。
留言討論 – 聊天室功能，方便成員問事討論、聯繫感情。
資源筆記 – 快速瀏覽所有筆記與成員上傳的資源。
Design
由於設計與開發還在進行中，僅顯示部分的設計稿。
反思與學習
在這個專案中透過產品開發前的使用者研究、挖掘使用者的需求與痛點，對目標族群歸納分類與分析旅程有了更多的實務經驗。也作為產品經理來規劃產品、制定功能。
因為出發點是做 Side-project，初期成員只有兩名設計師，所以在商業模式上沒有著墨太多，也想了比較完整的功能規劃。但後續隨著工程師的加入，需要將功能更加細分與排列優先度，確立 MVP 的開發下該如何排列優先迭代順序；也需要思考如果產品實際開發出來並上線上架，產品要用什麼經營模式讓團隊能持續開發與優化。