[翻譯]精實UX簡介（A Simple Introduction to Lean UX）

精實UX是專注於根據設計的體驗，與傳統UX相比較少專注於過渡產出(deliverables)。

他需要整個團隊更好程度合作。

他的核心目的是專注於越早獲得越好 ... GetunlimitedaccessOpeninappHomeNotificationsListsStoriesWrite[翻譯]精實ＵＸ簡介（ASimpleIntroductiontoLeanUX）原文：https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-uxAuthor/Copyrightholder:RosenfeldMedia.Copyrighttermsandlicence:CCBY2.0精實ＵＸ是一種非常有用的方法當你在敏捷開發方式下執行專案。

傳統的ＵＸ時常不能執行在開發急促的情況下—沒有足夠的時間用一樣的方式交付ＵＸ。

基本上精實ＵＸ與其他形式的ＵＸ都有這一樣的目標；交付一個好的使用者經驗，只是跟你在一個專案的工作方式略有不同。

所以讓我們看一下是如何執行的。

精實ＵＸ—那是什麼？精實ＵＸ是專注於根據設計的體驗，與傳統ＵＸ相比較少專注於過渡產出(deliverables)。

他需要整個團隊更好程度合作。

他的核心目的是專注於越早獲得越好的回饋，使其可被用來做快速的決定。

敏捷開發的原則是在快速，可更改的迴圈下工作，和精實ＵＸ相似於這些迴圈去確保所產生的資料可以被用於更改階段。

Author/Copyrightholder:Vimeo.Copyrighttermsandlicence:PublicDomain在精實ＵＸ下假設的需求傳統ＵＸ專案是建立於需求的捕捉和過渡產出。

其目的是確保過渡產出能越細節越好並且適當的回應那些在專案開始時的需求。

精實ＵＸ有點不同。

你不是專注於過渡產出的細節。

你要朝向產出一些改變，那些會在此時此刻改善你的產品—基本上是將你的結果變得更好。

實際上是藉由挖掘“需求（requirements）”和使用“問題狀態（problemstatement）”這些會引導至一系列的假設（assumption）可以被用來創造假說（hypotheses）什麼是假設？一個假設基本上是某件事情我們認為是真實的狀態。

他們被設計用來產生圍繞在想法的常見的理解（commonunderstanding），讓每一個人都可以開始。

假設可能不是正確的，也可能在專案的執行中被更改，當團隊中出現更好的理解（betterunderstanding）。

假設通常產生於工作坊下。

你可以讓整個團隊闡述問題和允許團隊腦力激盪他們的想法去解決問題。

在過程中你會產出一些答案針對特定的問題，而這可以形成你的假設。

典型的問題可能包含：誰是我們的使用者？這產品是用來做什麼的？什麼時候會被用？什麼情境下會被用？什麼將會是最重要的功能？什麼是最大的風險在產品的交期上？每一個問題都可能超過一的以上的答案。

這留下了大量的假設去處理而非這可能是實際的。

如果是這樣，團隊可以排列他們快速產出的假設優先順序。

一般而言，你會想要將假設的優先順序按照他們所代表的風險（其嚴重的錯誤會導致怎樣的後果？越嚴重的後果，他的優先順序就越前面）和目前對於問題理解的程度（對其越少的了解，優先順序就越高）Author/Copyrightholder:visualpun.ch.Copyrighttermsandlicence:CCBY-SA2.0創造假說在精實ＵＸ在精實ＵＸ中所創造的假說，是設計來測試我們的假設。

這裡有簡單的格式你可以使用來創造你自己的假設，快速且容易。

舉例：我們相信那讓人們儲存他們的進度在任何時間對手機用戶是必須的。

這會達到更多的完成註冊。

當我們可以測量改善目前完成率的百分之二十，我們將會展示他。

我們闡述我們的信念以及為什麼它很重要和對誰重要。

我們會遵循他並伴隨什麼是我們所期待達成的。

最後，我們會查明什麼樣的證據是我們需要用來證明我們的信念是對的。

如果我們發現沒有方法可以證明我們的假說—我們可能朝著錯誤的方向因為我們的結果沒有明確地被定義。

這種工作方法的其中一個大的優勢是，消除很多的“我不覺得這是一個好的想法”和內鬨在ＵＸ設計過程中。

每一個想法和證據的證明都將清楚地被查明。

沒有證據？那就是時候放棄這個想法去嘗試其他的。

如果每一個人能夠瞭解假說並且有相同的預期，那他們傾向開心的等待如果那是真的，而非一股腦兒爭論自己主觀的意見。

它與精實ＵＸ最小可行性產品（MinimumViableProduct）是精實ＵＸ的核心概念。

他的想法是建立一個概念的最基礎版本，測試他，假使沒有任何有價值的結果那就放棄他。

ＭＶＰs可以被納入將來的設計並且迴繞著他開發且沒有太多的麻煩。

這裡有一個方法可以極大化你的資源和其中一個理由他跟敏捷開法相輔相成的原因—它允許很多實驗但卻非“神聖不可輕犯”Author/Copyrightholder:Ericdelcroix.Copyrighttermsandlicence:CCBY-NC-SA2.0精實ＵＸ中的使用者研究與測試使用者研究與測試，根據精實ＵＸ的原則，他們跟傳統ＵＸ環境下使用著一樣的原理。

然而，進行的方式傾向於“快和髒（quickanddirty）”—結果需被提交在下一個敏捷衝刺的開始（AgileSprintstarts）；所以較少的著重在厚重的，縝密的文件，更多著重於原始資料。

研究的責任也傾向於更廣泛地展開跨整個團隊，使團隊中沒有“瓶頸”（“bottleneck”）產生，因為讓一個單獨的ＵＸ設計資源嘗試著完成所有工作在緊迫的時間下。

這通常使開發資源也“親身體驗”ＵＸ中的工作，這增加了一定程度的理解和支持ＵＸ工作在開發團隊中。

結論這是一個精實ＵＸ中非常高水平概論，當然，還有很多沒有講述在這一篇簡短的文章中。

然而，這些基本的概念應該能讓你開始朝著正確的方向當你的敏捷開發環境中導入精實ＵＸ時。

--MorefromJeremyHsu(徐偉智)FollowDesignlead@AgodaLovepodcastsoraudiobooks?Learnonthegowithournewapp.TryKnowableAboutHelpTermsPrivacyGettheMediumappGetstartedJeremyHsu(徐偉智)992FollowersDesignlead@AgodaFollowMorefromMediumMonicaGattiReadersandPersonasChristophDibbernWhatactuallyis …aCommunityofPractice(CoP)?SpigotInc.SPEGroupGotNashtyEnigmasNextDoorApplyingContinuousImprovementtoSurveyDesignHelpStatusWritersBlogCareersPrivacyTermsAboutKnowable