起源

我們的故事不傳奇,來自一個小團隊的成立,沒有資本、沒有資源、沒有高手,兩年前的我,以iOS 開發的角色,剛剛加入這間剛成立、剛轉型的公司,沒有敏捷開發、沒有 CI/CD、沒有 Cloud 的觀念,土法煉鋼,本地超英趕美,接近隕石式開發。

幾週前我們發佈了我們對於 DevOps 文化的養成與建立,今天要跟大家分享我們建立 UX 流程與思維的過程與心得,理論與實踐總有一條鴻溝,但我們還是必須先走一步。

目標是強化需求與最終體驗的流程(基於 Lean UX),並且透過理論引導實踐,希望對於正在閱讀的你們有些幫助。

另外關於文內的製作的細節應該有許多優質可靠的文章可以參考了,因為本身並不是 Designer,所以應該沒辦法給大家太多製作細節的建議,今天就會主要從大框架、思路來討論。

也把其他系列文章列在下面之中,方便正在閱讀的你快速點閱

從 0 到 1 的 DevOps 文化建立-我們是如何在兩年半的時間建立 DevOps 文化(上)

從 0 到 1 的 DevOps 文化建立-我們是如何在兩年半的時間建立 DevOps 文化(下)

從 0 到 1 的 DevOps 文化建立-基礎架構篇

沒有 UX 流程與思維建設之前,是什麼樣子?

在沒有體系的時代,土法煉鋼就是可能就是能活下去的最好的方式。還沒建立這些流程之前,我們與客戶討論需求與項目,其實就是工程師與產品經理一同與客戶討論。

然而,這大致上有幾個問題

  1. 產品經理與工程師以工程還有業務思維記錄下這個專案整體需求,缺乏使用者體驗與動線流程。
  2. 做出來的功能雖然能用,不過,客戶或者用戶就是會覺得沒有滿足感 or 少了些什麼。(就像餐廳食物都很好吃,也吃得很飽,但卻少了服務體驗的滿足感,這一點海底撈就是透過客戶服務補足了這一點,所以讓用餐的客戶既有生理上的飽足,也有心靈上的滿足)
  3. 產品經理與工程師帶回來的需求描述 UI 通常不能很好的理解與體會,沒有靈魂的需求。
  4. 在第三點的情況下呈現出來的 UI 會跟實際上的需求不太相匹配,也不接地氣
  5. 在第四點的情況下工程師與產品經理常常會自己修改 UI 來達到需求,但不會主動與 UI 討論,導致整體元件、視覺、設計與動線不協調,並且整體專案成全對於整體進度與細節不同步。
  6. 大前端工程師只看 UI 時,對於動線、元件的邏輯一無所知,好點會找 UI 、產品經理討論,不過通常會先自己腦補,先做再說,導致溝通成本極高,開發效率下降,專案透明度降低。進階影響到敏捷開發 / DevOps 的進行(關於這個部分的過程,可以參考稍早的文章)
  7. 最終導致產品與原始需求相差甚遠,或者不能符合使用者真正的需求。交付出來的東西,不是客戶想要的,那在多麽快的持續交付,其實都沒有用。
  8. 設計師的作品沒有辦法被很好的呈現,工程師的技術沒有辦法完全發揮,敏捷與 DevOps 無法產出有價值的交付,這其實是最大的資源浪費,也是我們必須導入這個制度的最大原因,我們希望每個人都可以展現與發揮自己最有興趣的價值與成果,那才是真正有靈魂的成品。

然後其實很容易變這樣 😂

理論先行,我們怎麼先有一版 SOP

有鑒於上述的種種問題,還有團隊之間無法順暢的溝通,我們決定先學習理論,再透過 SOP 與 文件的形式釋出到內部,透明化這個流程,其中大概分為幾個部分,專案起始的研究、Wireflow 出版與設計、互動文件設計、 UI 設計、開發階段(敏捷與 DevOps)、優化追蹤、結合傳統 SA 設計階段、Lean UX。並且透過這些項目,先在內部整體討論,並於專案開始實踐。

下圖是在內部執行討論後紀錄的,內部取名為 UX Roadmap

另外為了在內部科普這些知識點,我們也整理了科普文件。這也是我們筆記文化的其中一項。

專案起始的研究

桌面研究就我們內部而言,通常會配合頭腦風暴、商業模型圖,目標是儘早的搜集想法,整理想法,歸納想法。然後進行競品分析,市場研究。這邊會根據專案或項目產品的屬性有些許不同。

這個階段的目標就是搜集大量訊息與素材,作為日後材料使用。

下圖是我們頭腦風暴的畫面,有實體的也有電子的

便利貼才是頭腦風暴,~梗圖請參考

這是商業模型圖

使用者需求討論

使用者研究我們通常會進行使用者與客戶的訪談,有時候客戶與使用者會是不同的兩群人,如果都聽得到這兩邊的想法是最好的。大致步驟就是(UX、PM、代表工程師一同前往)

  • 第一次約見客戶 - 聽聽看客戶怎麼說,我們這邊不要有太多意見或忍住想法,這次的需求訪談一定會很發散也很零散,另外如果是產品項目,會請內部一些小夥伴或者合作方來當客戶。
  • 第二次約見客戶 - 根據上一次的成果,設計與提出我們的問題或想法,這邊應該要初步有些結構性了,或者建議,與客戶達成需求上的需求框架與思考的同步。
  • 第三次約見客戶 - 根據第二次會議,微調與調整需求框架,做最後確認。

經過這三次的會議之後,UX、PM與開發一定對於這個需求有不同角度的看法,接下來就是要整合這些看法後,整理結果,並且出一版內部的需求報告

這份文件照慣例也會管理在我們 notion 的該專案下。

使用者情境與場景

使用者情境與場景是基於需求分析後的情境場景分析,常用的工具會是 PersonaUser StoryUser Journey ,這邊建議還是要整個團隊一起參與,比如說我們執行的時候會請開發小姊姊來演那個使用者,~人生在世全靠演技~,這樣不僅僅會讓團隊更有參與感,執行起來也有趣許多。

簡單來說就是把人設搞好,劇本寫好,實際演一次,然後記錄下來。

PersonaUser Story 會像這樣

User Journey 會像這樣

系統功能分析與規劃

功能規劃大約會有幾個比較重要的事情要執行,產品定位、產品策略規劃、功能資訊架構規劃

通常這邊我們也會讓整個團隊都參與,透過頭腦風暴的方式進行,其實團隊中每個角色看每個功能都會有不同視角的,可以提取大家有價值的部分,提煉成這個產品或項目的精華。

下圖是功能資訊架構的示例

到此就暫時完成了前期研究的部分,這部分觸碰到核心的需求,這階段做得越扎實,後面會感覺收益越大。接下來要進入 Wireframe 的設計。

Wireflow 出版與設計

Wireflow 出版與設計階段,最主要的目的是圖像化流程與需求的具象化,不僅僅可以讓客戶更確認需求,也可以讓團隊小伙伴對於這個專案與產品的需求更加理解,也可以開始做頂層設計。這邊我們大概會有三個部分,分別是User flowWireframeWireflow

根據項目的大小與嚴謹度,不一定會三份都產出,可能會全部整合成 Wireflow,一方面給客戶確認,一方面也給內部小夥伴確認畫面與動線邏輯,作為之後開發的邏輯規則依據。

Wireflow 示例,會包含頁面上的邏輯與動線

互動文件設計

互動文件設計目的通常是讓上面的畫面在開發前可以真正的先動起來,不僅僅對於客戶或使用者提出的需求更加確認外,也可以讓團隊、相關人員先體驗產品或專案動起來的感覺。大概有幾個重點項目要做,製作 Prototyping 、易用性測試,調整設計(根據反饋與總結調整或修改流程或操作,並且更新 Wireflow

這階段通常是一個循環的,即使到了開發期間,發現流程與邏輯需要調整,也會回來執行調整設計,然後再看 UI 是否需要接著調整。

這邊團隊還會算是融合傳統 System Analysis 的步驟,把這些需求與流程動線整理出來。

UI 設計

經過上列的一系列的執行步驟,UI 設計就是根據上述的資料與文件,製作符合 UX 設計的 UI,這階段要掌握元件、視覺設計與易用性,並且確認動線與操作。

UI UX 需求說明會議

UI 設計完之後,會進入到開發階段,在開發前通常公司內部會舉行一個 UI UX 的說明會議,會完整把目前為的 WireflowUI 過一遍,確保團隊都清楚並且了解這些需求與規則邏輯。

開發階段

這邊就跟敏捷與 DevOps 比較有相關了,可以直接參考稍早的系列文章。

從 0 到 1 的 DevOps 文化建立-我們是如何在兩年半的時間建立 DevOps 文化(上)

從 0 到 1 的 DevOps 文化建立-我們是如何在兩年半的時間建立 DevOps 文化(下)

從 0 到 1 的 DevOps 文化建立-基礎架構篇

Lean UX 在我們團隊的實踐

Lean UX 是一種互相協作、跨職能的方法,更快與敏捷的展現出產品本質的實踐工作。可以把他當作是一種敏捷開發,其中也把設計師納入。

屬於設計師與開發團隊的 DevOps

Lean UX + DevOps,根據上述的工作細節,其實可以發現,我們每個環節其實都是團隊一同參與的,這根 DevOps 與敏捷重點描述的跨職能與參與進來的概念不無不同。如次一來從需求階段團隊就參與其中,並且熟知整體流程與系統,不僅僅可以提高團隊成員的價值觀,也會增進文化中的參與感與認同感。在我們團隊實踐中,我認我取得不錯得成果與效果。

每一次的頭腦風暴也可以進一步提升團隊幸福感,無論是集體心流或參與感的感覺,思想在團隊中流轉,是一件非常高校且開心的事情。

讓設計師也加入敏捷思維

敏捷思維可以說是一個精益思維,透過小步快跑,快速迭代,驗證想法與做法,已經是這個時代的必備技能。透過 Lean UX 讓設計師也具備敏捷思維,可以說是助益非常大的。

未來

未來我們要做的除了繼續保持已經做好的事情與流程外,還必須不斷的精進與改善,加強各個方法論的實行與實踐經驗,並且將這些元素提煉成團隊的文化與價值觀,讓新成員也可以很快的融入這些流程之中。

  • 互動重於流程與工具
    也就是流程與工具已經內化成團隊的心法,更加重視團隊成員之間得互動、溝通與了解,設計師不固執己見,工程師不隨波逐流,產品經理不道聽途說。
  • 完善的產品重於完美的文件
    這不代表文件不重要,同時團隊會知道,交付出完善的產品遠比完美的文件更重要,文件可以回補,但產品釋出常常只有一次機會。
  • 客戶合作重於合約談判
    如果能夠讓客戶也加入這個流程,那是最好不過了。不過通常我們並不能改變客戶的思維,盡量以客戶的角度去思考各個職位的問題,就如同那句名言,「客戶不是想要更快的馬車」。
  • 因應變化遵守計畫
    唯一不變的就是會改變,這應該已經是軟體世界常常聽到的一句話了。我們希望團隊有更高的大局觀去面對改變這件事情。分析每一道改變所帶來的影響,而不是為了遵守計畫而遵守,失去敏捷精神。

總結

Lean UX 與 Design 的關係就如同 RD 與 DevOps 的關係,這些流程、團隊文化、團隊組織的框架,可以帶領團隊朝向比較正確的方向前行。他們都不是一套規則,而是一套方法,考慮到各種差異,不得不做客製化與些微的調整,但都不會脫離他們精益的核心理念。

對我們團隊來說,僅僅半年的使用就有感受到明顯的變化,即使我們還尚未全面套用。並且根據這些基礎,我們做到了讓毫無遠端工作經驗的團隊,實現了完全遠端工作,並且效率保持一樣如此高效,實屬難得。

今天就跟大家分享到這裡,感謝你的閱讀,我們下次見。

澄思設計-沈思世界的解決方案
解決問題的路上,也給大家解決過的問題不同的角度思考方案,包含軟體工程、架構、使用者體驗、專案管理等方法論。澄思設計以顧問的角色,積極解決客戶的問題。理解客戶的想法,這個客戶不一定是企業,也可能是個人,解決企業問題,我們使用專案解決,解決個人問題,我們使用產品解決。我們想要找的人,是能夠解決這個世界上各種大大小小問題的人,無論是透過溝通、技術解決,同時他應該會有積極與強大的自學能力,對於解決問題充滿熱誠,與團隊、與公司共同搭上火箭成長,那你可能就是我們要找的人Klearthink Design Co., Ltd.
如果你對我們公司有興趣,歡迎參考我們的職缺,我們有機會聊聊吧 :D
職缺參考

yasuoyuhao,自認為終身學習者,對多領域都有濃厚興趣,喜歡探討各種事物。目前專職軟體開發,系統架構設計,企業解決方案。最喜歡 iOS with Swift, [email protected]
如果喜歡我的文章,可以按下喜歡或追隨讓我知道呦,拍手可以拍 50 下,更歡迎許多大神指點討論。感謝您的閱讀。
部落格:yasuoyuhao’s Area