[譯] 是的，重新設計（第一部分）是的, 重新設計(第一部分)

<b>本文講的是[譯] 是的，重新設計（第一部分），</b>

作為一個設計上司者，我經常問自己：“我的團隊怎樣才能夠持續向我們的使用者提供最好的産品體驗？”我的答案總是相同的：我們需要考慮到我們使用者是在持續變化以及在迅速發展的社會中不斷提升的品位。但是，如果重新設計産品的體驗就是解決方案的話，怎樣從内部對話入手來開始這個過程呢？如何實作一個能夠平衡新功能和設計的同時還能保持産品的一緻性的可拓展的解決方案呢？

如果你也面臨着同樣的設計挑戰，我希望這篇文章能夠幫你找到以下問題的答案：

1. 為什麼當使用者已經愛上這個産品的時候仍需要重新設計？ 2. 如何在一個以資料驅動快節奏的公司中執行重新設計？ 3. 你如何衡量結果？ 4. 下一步是什麼？

為了幫助解答這些問題，我想通過分享我們對龍頭産品 “唱吧！卡拉OK”（原文：sing！karaoke）的重新設計的經驗，來帶你看到我們團隊在這一路上所克服的障礙。

兩年半以前，當我第一次加入公司的時候，我們有四個團隊，每個團隊負責下列應用的其中一個： 唱吧！卡拉OK（Sing! Karaoke，以下簡稱唱吧！），魔術鋼琴（Magic Piano），電子豎琴（Autoharp），彈吉他（Guitar）。每個團隊由一名設計師，一名産品經理和兩到三名工程師組成。随着成長速度的不同，我們看到“唱吧！”成為了 Smule 家族中領先的應用。公司決定将重點從基于應用開發的架構轉變為基于功能的架構，這意味着更多的功能，更多的心血将傾注于“唱吧！”應用中，設計師們也需要更多的設計合作。随着業務變化，我們知道我們現有的産品設計和流程不能滿足團隊的擴充和使用者的需求。

我們知道重新設計不會是一個孤立的項目，而是需要與使用者，設計師，産品經理，工程師和執行人員的共同參與。為了重新設計，每一部分的人員都在項目初期就參與進來，針對“如何”重新設計提供意見回報。這幫助我們設定了明确的目标，重新設計将從以下四個方面實作：

來源：shutterstock

提升使用者體驗 授權設計團隊進行規範化 提升産品參與度 建立可持續的工程解決方案

從許多使用者研究中，我們已經知道一緻性是可用性最強的因素之一。“唱吧！”是一個有着很多功能的有趣産品。在 2012 年産品釋出的時候，隻有很少的功能和使用者基礎。由于功能很少，設計采用不同顔色來區分不同場景下的内容。比如，在“唱吧！”的早起版本中，我們用超過四種顔色來展示不同的“行為召喚”（在商場超市裡，我們經常會看見一些新品上市，會推出免費試用以及低價促銷的活動，用以刺激、吸引使用者的購買行為。這就是行為召喚中的一種。譯者注）的不同用途，舊的設計原本旨在取悅使用者，但我們注意到這種花花綠綠的“行為召喚”反而會給新使用者造成困惑。這意味着重新設計需要建立一緻的 UI 語言來改善我們目前的使用者體驗。

通過進行使用者研究，我們發現新使用者往往會帶着他們之前的經驗，和其他應用或産品的 UI 互動的經曆來假設他們和“唱吧！”的第一次互動也會如此。最重要的是，當“唱吧！”的界面沒有符合使用者的預期時，使用者需要花費額外的精力來學習和了解這個界面，這将使得産品試用既讓人興奮又讓人頭疼。我們推測，使用者界面的标準化，或者更新定制化的界面設計，使其與重新設計的設計模式相比對，可以幫使用者更快更容易地熟悉我們的産品。它可以幫助使用者快速了解産品，進而更好的參與進來。

與應用程式的互動具有可量化的實體和心理成本。實體成本是使用者達到特定目标所需的步驟數量或時間來衡量。心理成本是通過讓使用者完成一個任務，或達到一個目标所需的内在和外在的認知負荷以及壓力。比如，當“唱吧！”使用者想要和其他使用者開啟一段合唱時，他們不得不在多個界面進行操作才能達到這個目的，這不僅僅消耗了使用者時間成本，造成了使用者心理壓力，也沒有幫助使用者了解内容。有計劃有信念地使用明确的标準互動和UI設計，将顯著降低使用者的身心成本。

來源:shutterstock

“唱吧！”開始使用的是 Gotham 字型，是一種靈感來自紐約市中世紀建築設計的字型。Gotham 是一款非常棒的字型，可以慶祝 Smule 的樂趣，異想天開的感覺。它仍然代表了 Smule 在今天的品牌形象。然而，Gotham 是用于列印和媒體應用程式的字型。在移動裝置上呈現時，會引起許多問題。Gotham 有着較寬的字間距，會在同樣的詞句上占據更多的位置。移動裝置具有有限的螢幕尺寸，是以設計師必須總是做出額外的努力，以確定文字在 iOS 和 Android 環境中都能顯示正常。很多時候，由于存在使用者可讀性的問題，字型的大小需要縮小以适合小空間。Gotham 引起的另一個問題是基線較低。是以，工程師必須手動，在視覺上確定副本是居中的。正如你所看到的這些例子，我們在開發階段遇到了很多設計問題。我們現在知道，找到可擴充和平台标準字型是我們在重新設計過程中必須做出的關鍵決定之一。

設計是一個既活潑又嚴肅的創作過程。如果沒有一個标準的 UX/UI 設計指南，該産品将成為項目中的不同設計師對于美學了解的大雜燴。繼續研究這些設計會使設計團隊産生混亂，限制設計人員的産出，并降低了産品品質。我們知道我們以前的“唱吧！”沒有明确定義設計标準。這種模糊标準加重了我們設計評審過程中的延遲和難點。當團隊中沒有人能夠闡明我們的目标設計标準時，所有的回報和審查都是基于個人偏好來判斷的，其中大部分都是無效的。作為一個團隊，我們明白我們需要共同努力為使用者提供最好的産品和體驗。為此，我們認識到，我們需要一個明确界定的标準，傳達給所有設計團隊成員，以便在整個重新設計和推進過程中使用。這将為團隊的每個産品設計決策奠定基礎。

設計團隊的巨大增長使我們意識到需要建立一套規則。這個規範的建立是對于資訊架構，布局，字型，顔色，圖像和互動的處理。優點是，它将作為一個架構，适用于大多數設計問題，幫助設計人員在第一次就做出正确的設計決策來加快設計的過程。更重要的是，設計團隊需要建立一個共享的中央存儲庫，根據需要經常更新，記錄我們的樣式，元件和規範。随着這個共享中心的到位，設計的一緻性以及設計的品質和數量将得到改善。這意味着在“唱吧！”的重新設計中，設計團隊需要制定這個指導方針，以減少脫節的空間，個人設計風格和産品的視覺吸引力将保持一緻。我們的目标是最終，設計師們不必緻力于圖示的細節刻畫，不必思考究竟什麼才是正确的規範。相反，他們可以更多地關注使用者的創意設計解決方案。

随着産品功能的更新，更多的使用者加入了我們的“唱吧！”大家庭。我們的設計團隊需要擴張，以及更多的合作。沒有對于建立合作基礎的子產品的共識，壓力将會在團隊增長的同時一直伴随，使得溝通變得複雜。為了確定我們的團隊成功，我們知道我們的設計方法和工作流程需要子產品化。這意味着重新設計團隊需要建立一些設計構模組化塊，這将是重新設計和所有設計工作的基礎。這些單獨的子產品既能幫助我們的設計師輕松協作，又能在必要時進行産品分割。此外，當新設計師加入時，團隊的進階成員可以利用這些子產品來引導項目，并為新成員制定明确的計劃。

當新使用者嘗試新應用時，他們他們會同時學習兩件事情（1）此應用程式的功能和（2）如何通路這些功能。沒有明确和标準化的 UI/UX 設計，使用者可能無法完全了解應用程式中的各個界面元素并感到迷失。為了讓使用者專注于使用産品功能而不是導航界面設計，我們需要了解新使用者的期望并明确傳達對他們有價值的資訊。總體而言，新設計應該簡化我們應用程式的混亂部分，使得使用者在嘗試和新功能進行互動時感到舒服。

在 Smule，我們密切監視使用者存留，定義為在第一次使用體驗後接下來的幾天（例如第 2 天和第 7 天），有多少新使用者回到應用程式。如果使用者在第一次沒有得到很好的體驗他們在第 2 天不太可能回來。通過使用者研究我們發現，如果使用者找到了興趣接入點，他們便會在樂享在新功能中，否則他們仍會停留于已有功能。這些發現表明，我們的設計導航與使用者的意圖不一緻。如果設計沒有幫助使用者知道他們在哪裡，以及他們如何通路他們所想的功能，他們可能會感到困惑，對于繼續使用“唱吧！”失去了興趣。通過重新設計，我們需要提供更好的導航，滿足使用者意圖和産品商業目标。

在 2014 年，我們開始考慮重新設計時，iOS 和 Android 上的産品功能是不一樣的。“唱吧！”在 iOS 上的功能要比 Android 上的功能多，iOS 和 Android 的不一緻使設計團隊的工作翻了一番，延遲了開發周期。當我們開始思考重新設計時，“唱吧！”已經獲得了很多新使用者。我們想，趁着這股勢頭，加快産品設計和開發周期。考慮到這一點，我們知道重新設計需要改進我們内部設計團隊的工作流程和效率。重新設計可以将設計和開發時間縮短 50％，這将為我們提供更多的機會來測試和釋出具有目前資源的新功能。

不一緻的 UI 不僅引起了可用性問題，而且為設計師和工程師創造了額外的工作負擔。例如，對于單個圖示，設計人員建立了多種顔色或大小的元件以在不同的場景中使用。為了確定工程師将元件放在螢幕的正确位置上，設計人員花費了大約 40％的時間來為工程師規劃和建立元件。另一方面，工程師需要遵循規範，編寫自定義代碼，以確定每個元件都位于正确的位置。這些聽起來很容易，但是當考慮到其他變量時，比如螢幕尺寸和不同平台（IOS/Android），這過程簡直可怕。在與工程師交談之後，設計師和工程師都希望以更好的方式互相協作。這再次提出了重新設計需求的另一個視角：創造一個可以使設計師和工程師建立并構造産品更加有效的一套系統的方法。

做設計品質保證是設計者的責任，并確定設計得到正确實施。對設計師和工程師來說，最令人沮喪的時刻是：工程師為了修複設計 bug，不得不修改設計的某些部分，當然這将會産生另一個設計 bug。這導緻，工程師花費更多的時間來修複設計 bug，卻仍然不能保證工程實作和設計是比對沒有 bug 的。我們知道，要重新設計解決可能遇到的所有設計錯誤是不切實際的，但是，建立一個統一設計規範，以界定如何設定邊距，如何建立圖示大小，如何申請壓縮狀态等等，将減少上述場景的發生。

當我們開始思考重新設計時，“唱吧！”從以美國為中心的應用程式轉型為國際産品。為了适應不同國家地區使用者的社群本地化，我們把“唱吧！”從12種語言發展到20種語言。将原本為英文的應用程式更新多語言時，使用者界面很容易出問題。例如，與英語比起來，德語或俄語需要更多的字元來表達相同的含義。通常适合英文标簽的限定空間将不适用于德語和俄語。如果沒有一個清晰的規則，來制定如何設定間距，如何應用層級關系，當地語言字元會就被裁剪，或者以較小的尺寸呈現。逐一解決每種語言的這些問題，花費了我們工程師和品質保證團隊的大量精力。我們知道，通過重新設計我們需要找到一個可持續的解決方案，可以優化我們現有以及未來會有的不同的語言。

<b></b>

<b>原文釋出時間為：2017年6月14日</b>

<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>