Startup研發備忘錄（下）：落實教學App新概念將構想製成產品

之前兩篇文章講到，我們為了研發出比YouTube和Patreon更適合教學用途的LearnHour App，分析了現代學生的行為習慣。最後總結出傳統教學和現代科技發展存在一定落差，而市面上現成的工具難以協助導師發展可持續的商業模式。

本文為此系列文章最後一篇，記錄我們將LearnHour的概念製作成產品的過程。

對於LearnHour的用戶體驗（UX／User Experience）設計，我們最優先的指標只有一個字，就是「懶」。因為我相信能「令人活得更輕鬆（更懶惰）」的產品，就是有價值的產品。越能減低用戶的工作量，價值就越高。

設計一個App的重要工作，是建構出用家從接觸一個產品，到成為慣常用戶之間的「User Journey」。設計團隊需要針對User Journey內的每一個階段，用戶所面對的痛點和障礙來改善設計。在UI（用戶介面）層面上，我要求將多餘的部份盡量減到最低，「能用按一下就完成的工作，就別要用戶按兩下」。務求每一個頁面都清晰易懂，減少曖昧難明、或毫無作用的裝飾和過份設計。

設計過程中，我們會不斷檢視系統的邏輯，模擬用戶實際使用時的情景，再不斷微調甚至重新設計，直到修改好大部份設計漏洞，然後才開始編寫程式。

盡快完成開發MVP

製作新產品的時候，經常會墮入一個陷阱，就是怕功能未夠完善而不敢推出市場。我們以往服務過的Startup客戶，大多都遇過這個問題。就算是我們自己出品，也難以例外。

理想的情況，是盡快推出最初版本，再根據市場反應和回饋，決定如何修改。一個新產品不可能做到完美才推出。Startup界有一個術語，叫「Minimum Viable Product」（MVP），只要做到Minimum又Viable，就要推出市場，分析實際使用數據，然後再調整設計。

改革傳統學習與授課模式的App「LearnHour」

開發LearnHour的途中，我們遇上不少技術上的挑戰，經過不斷的摸索，最終總算逐一克服。

我們最終的方案，上客的流程採用類似Patreon，借助Facebook和Whatsapp等工具作為主要發放渠道。用戶觀看預覽內容後，便可以直接註冊及下載LearnHour App訂購導師所有課程或繼續預覽免費內容。

在課程方面，LearnHour有完整的內容管理系統，導師可以建立和編輯不同課程，及課程內每一節課堂。無論是影片、聲音、圖像或文字，都可以作為課堂內容。每個課程都可以設定為免費和收費，收費亦可分為兩級，設定兩種不同價格。

每當導師更新內容，學員便會收到即時推送通知，導師亦可以通過App內的即時通訊功能，隨時和個別或所有學員發出訊息。

每節課堂都有留言及討論功能，採用一般社交媒體形式。對導師來說，就是一個有收費功能的私人社交媒體平台。

另外學員亦可以在App內直接和導師即時通訊，學員可以發送圖像和錄音，而導師更可發送影片。

Startup必要面對「雞與雞蛋」的問題

一個全新的App，首先要面對「有雞先還是有蛋先」的問題。以現在我們研發的LearnHour App為例，沒有用戶基礎，又沒有知名度，怎樣說服導師加入？

開始設計LearnHour時，我們已經考慮過這個因素，所以決定不做「平台」，而是定位為「工具」。用比喻來說，我們大概是提供場地及器材讓導師各自開班，而不是營運一間學校。

作為Startup，最理想是自己都會使用自家研發的產品。所以先由我自己做導師，在LearnHour開設課程，作為第一個用家。而LearnHour的設計比較適合用於學習新技能，所以我選擇開設有關「區塊鏈」的課程，而不是教授我在大學任教的學科。

有了第一個課程，就能夠正式推出市場，給其他導師作示範，亦可以收集用戶意見。

（有興趣的朋友，可以按以下連結試用：https://www.learnhourapp.com/tag/share?tag_id=7f6969f8-9861-41aa-a788-68b8a82b5954&creator_id=keith）

雖然LearnHour的功能看似簡單，但設計和製作上實在花了不少功夫。為了應付未來將會面對的巨大流量（上線人數、數據流量等等），我們還設計了一套比現時主流雲端服務（例如AWS、Azure等等）經濟多倍，又能更快更有效地Auto-Scale的Cloud Infrastructure，並將這個服務發展成獨立產品，這是後話。