瓦薩號沉船與你的 App 很配
瓦薩是一艘古戰船的名字,它是瑞典國王古斯塔夫二世于1625年開始建造的。這艘戰船本來是單層炮艦,可是國王得知當時瑞典的海上強敵丹麥已擁有雙層炮艦,便不顧當時本國的技術條件,下令把炮艦改造為雙層,1628年首航幾分鐘便沉沒,直到1961年才重見天日。
幾個月以來,你和整個團隊都在瘋狂工作為的是構建出一款令人驚嘆的移動 App,最終,帶著疲憊與興奮,it’s showtime!但是,你寄于厚望的夢幻 App 卻帶來了無止境的夢魘:急切的用戶下載了 App,使用過一次之后,就再也沒有回來。
所有的犧牲和幾個月的艱辛勞作———然并卵,哪里出了問題?
你的 App 已經成為最新趨勢(comscore調查)的一個受害者———高達 41% 的 App 被使用一次之后就被拋棄。這個趨勢與 400 年前瓦薩號沉船的故事如出一轍。這個當時令人驚嘆的軍艦,由于存在基本的設計問題,在它的首航分鐘便沉沒。
本文將探討瓦薩號,希望能幫助你的移動項目找到正確的點。
斯德哥爾摩博物館打撈出來的瓦薩號戰艦
一個清晰、引人注目的愿景
雖然瓦薩號最終失敗,但有一點無疑是極好的,建造者竟有如此雄心壯志。
so,在討論瓦薩號的所有問題之前,讓我們簡單的了解一件它做對了的事情:船的建造者有一個宏偉的愿景,并講述了一個引人入勝的關于王室的征服與驕傲的故事。
即使在 400 年后的今天,他們的愿景依然是吸引人的。這是出色的工藝、會聲會色的描繪神話雕像、可怕的武器以及船舶的整體外觀的表達。
談到愿景,你的移動項目或許并沒有那么吸引人。
在開始設計和實現 App 之前,你必須對正在構建的的產品有一個清晰的愿景———以及 App 所能夠提供的價值。
幸運的是,描繪移動項目愿景相當簡單,你可以在短短 20-30 分鐘時間里,僅僅使用幾張便簽紙來描述 App 的主要使用場景。
“Be a hero” ?Storyboard (英文作者)
Storyboard用戶需求場景描述:一個用戶想要通過向慈善機構捐款來支持臺風救援工作,捐贈物資的人感覺像一個英雄,而災難的幸存者也得到了迫切的幫助,開始重建他們的生活。
據《財富》雜志顯示:大多數初新創公司失敗的原因之一是他們制造了一個沒有人想要的產品。制造出令人興奮的愿景,并確保你的移動項目沒有成為這個數據的一部分。
在做任何實際的設計和開發之前,花點時間搞清楚你的愿景是什么,把它展示給潛在的用戶和你的股東,以確保所有關鍵人員的反應是興奮的。
你的愿景必須清晰、引人注目,否則,App 就不值得構建,一旦愿景確定,就可以開始規劃和設計原型解決方案。
盡早測試、調整
當“瓦薩”號的計劃由瑞典國王首次提出后,他犯了兩個致命的修改:一是武裝上重達 24 磅重的大炮,二是使船變的更薄,以便使其更快。
許多人認為,如此詳細的設計指導意味著國王會親自監督,然而事實上,國王只對碼頭進行了一次訪問。
實際上,第一次穩定性測試直到漂浮設備完備后才得以進行。據維基百科記錄:三十個人在上層甲板來回跑去,但只進行了三次就被海軍上將給叫停,因為他擔心船會翻。
盡管穩定性測試做的很失敗,但在首航前還是太晚開始做任何事情,沒有人想告訴國王壞消息,只是堅持說,這艘船很快就可以開始航行了。
最終,我們可以這樣以為,國王得到了他 想要 的東西,但不是他所 需要 的東西———一艘引人注目的船,但只在行駛了一英里就沉沒了。
對于任何重要的項目,執行反饋或設計的修改建議都是沒有錯的,也都是至關重要的,這里缺少的是對早期原型測試與及時反饋。
正如你的愿景與原型需要在設計和開發的每一步都要經過充分的測試,向正確的人傳達測試結果同樣重要,關鍵人( Key people)需要成為解決方案的一部分,否則他們將成為問題的一部分。
作為一名設計師,你的工作是向管理人員提供及時反饋,清楚的溝通任何早期的產品問題,同時也可以得到解決,以確保最好的設計得以向前推進。
如何確保你早日得到反饋?MVP(Minimum Viable Prototype ) 將會非常有幫助。
MVP:最小可用原型
最近在斯德哥爾摩參會(英文作者),我得以有機會去參觀瓦薩沉船博物館。
博物館中,在打撈出來的瓦薩沉船旁邊,放置著原船比例 1:10 的模型,這樣的模型對優化設計來講是最理想的,任何人都可以看的出來如何使船更薄,更高,在頂部增加了的大炮會損害其穩定性。
然而,瓦薩號沉沒后,打造這個 1:10 的模型,沒什么卵用,當然除了可以警示我們:建立你的的移動產品原型,盡早得到反饋,并在開始開發前優化設計。
幸運的是在今天,打造你的 App 原型將會異常容易———你不需要木板、甚至任何特殊的設備或軟件,更棒的是,你的設計和你的原型可以是相同的。
所有你需要的只是一包 3×5 英寸的純色便簽貼紙:
例如,下面是 Be a hero 的 MVP:
有了這個簡單的原型,你可以快速,方便的測試和完善你的 App 的基本設計:信息架構、交互設計、復制等,你甚至可以測試圖標。
精益生產是關于實驗的,通過創建一個 MVP 來建立你的實驗,并直接面向潛在用戶進行測試,也大大加快了實驗和反饋的過程,無論是內部的還是外部的。
事實上,就是以最低成本和最適宜的方式規避風險。
當你的項目啟動后,盡早的對原型進行持續性的測試,有效減少可能致命的設計缺陷,也大大增加了成功的機會。
早期設計優化,制造差異
瓦薩號非常有名,但很多人不知道瓦薩號的姐妹船:蘋果,它的設計者做出了兩個重要的改進,他們在上甲板上安裝了較輕的槍,并對船體加寬了 1 米(只是瓦薩寬度的 10% )。
這個簡單的調整改變了一切:蘋果 成功航行了超過 30 年。
為了確保你的產品的成功,盡早測試,并在一開始就進行大量的迭代,直至達到設計初衷。而一開始就將時間和精力投入到高保真的完美設計上,只會適得其反。
例如在 Be a hero 的例子中,在團隊第一次在便簽紙上提出原型設計后,先后經歷了 5 次迭代。
當團隊完善了設計的關鍵要素后,他們才投入了額外的時間來創建高保真的原型:
在設計的早期過程中,保持高保真的原型、適當的項目狀態,有利于團隊快速推進和解決大部分問題,使團隊能夠在短短三周的時間確定最終方案。
不知道你會做出什么舉動,但這聽起來就像你花費了一包便簽紙的成本就避免了一艘艘沉船,連威嚴的瑞典國王肯定會批準這么做的。
確保你的 App 順利啟航
通過看到瓦薩號戰艦的歷史,如果在遵循一些簡單而深邃的精益用戶體驗指南,可以幫助你的移動項目避免災難性的后果。
在你開始之前,把你的愿景做為 Storyboard 掛起來,花時間與潛在的用戶和利益相關者(股東)來測試———確保他們對你的想法有著同樣的熱情。
一旦愿景確定(被大家所接受),使用通過便簽紙生成的 MVP 同步開始用戶測試與設計。從這一點上來看,快速原型迭代與客戶反饋應該是你的移動設計的核心。
一路上,也別忘了與管理人員和團隊中的關鍵人員進行 雙向溝通 的重要性。
通過包括所有的關鍵人的反饋回路中,確認團隊中的每一個人以為他們的想法是從一開始就被考慮的,這最大限度的減少了任何人在最后一分鐘的變化,使你不能充分測試或實現。
記得原型的精確度與項目的進度相匹配,在設計的關鍵部分,在你覺得很舒服之前,切記不要投入太多的時間和精力在高保真原型上。so,堅持盡可能長時間的使用低保真原型,測試設計快速迭代,并不斷結合見解重新回(重構)到你的原型上。
精益,快速成型,再加上一個連續的反饋循環,將有助于您的團隊工作順利,結合新的想法,構建移動 App,不僅僅是首航成功,而是要在未來成功航行多年,并在對手的心中造成驚人的恐懼。
結語
成功的產品各有各的不同,失敗的產品卻是一樣的原因。
部分句子依據上下文意義沒有直譯并有所發揮,請各位小伙伴查看原汁原味的英文原文。
我想起了自己做的第一個,也是徹頭徹尾失敗的產品,不說了,都是淚,但也恰恰是它的失敗,而使我有所成長,正如:所有弄不死你的東西,終將使你更加強大!
英文原文:http://www.smashingmagazine.com/2015/09/lean-mobile-ux-lessons/
#專欄作家#
大偉,微信電影 產品經理,人人都是產品經理專欄作家,從用戶需求(在一大堆很酷的設想中砍掉當中的絕大一部分)到產品定義(有價值且符合公司戰略發展),從產品原型到視覺設計,從交互到動效,毫無疑問,這些都是非常振奮人心和充滿能量的,希望你可以在我們的會話中找到有用的東東。
本文系作者授權發布,未經許可,不得轉載。
- 目前還沒評論,等你發揮!