看似簡單的功能背后有哪些設計細節和難點？本文講述了 Figma 團隊在「查找與替換」功能設計過程中遇到的問題以及解決思路。

當我們第一次開始研究「查找和替換」時，我以為會很簡單。畢竟我已經在 2019 年設計了一個同名的插件。在頁面上加一個搜索欄并且高亮內容會有多難呢？但我很快意識到，一個看似很小的功能背后包含了復雜的開發和設計挑戰，這些挑戰包括怎樣對搜索結果進行排序、設計專門的 UI。現在「查找和替換」已經在 Figma 和 FigJam 上線了，我們想分享一下面對挑戰的幕后故事、測試方法，以及我們怎樣把從插件中學到的東西轉化為原生能力。

更多大廠案例：

一、憑直覺搭建

我們很清楚「查找和替換」的大部分工作都將集中在直觀的“查找”體驗中，所以在需求評估階段，我們就和設計團隊進行了一次頭腦風暴。我們收集了關于“怎樣打造出色的搜索體驗”的想法和意見，并開始建立一個跨職能的工作小組，這里面包括了產品開發、項目管理、UX 寫作和產品營銷。

收集團隊成員在使用其他工具時認為具有優秀體驗的搜索案例，是我們工作流程的起點。

接下來，我們定義了一些基本原則，用來定義我們認為“搜索”在 Figma 和 FigJam 中應該是怎樣的：

1. 快和輕量；
2. 平滑過渡，尤其在畫布中瀏覽時；
3. 與其他應用程序（如瀏覽器）的搜索體驗相似。

搜索這種功能，很難在沒有 demo 的情況下去感受它的優劣。所以我利用我的插件開發技術做了一個模擬部分搜索體驗的 demo，這樣我們就可以在早期嘗試不同的想法。以此為基礎，開發團隊在過程中不斷地搭建和迭代，因此我們也得以更快地找到正確的解決方案。在嘗試不同方案的過程中，我們會讓 Figma 的同事在日常工作中深度使用，為我們提供反饋、提交 bug。

我開發的模擬部分搜索體驗的demo

二、正確的核心體驗

我們決定先在 FigJam 中設計「查找和替換」功能。這樣我們可以更加專注在核心體驗上，即在文檔中查找文本并瀏覽匹配項。之后我們再拓展到 Figma，因為在 Figma 中會面臨更多的對象類型和更復雜的情況。

1. 排序邏輯

在 Figma 和 FigJam 中搭建搜索功能是一個特殊挑戰：他們的內容是多方位、多維度的。畫布不像網頁或文本那樣從上到下流動，而是有一個用戶自定義的結構。我們要能夠預測到用戶會創造怎樣的結構，這樣我們才能讓搜索順序在面對各種情況時都顯得合理。最終我們一步步地解決了這個問題。

2. 在現有邏輯的基礎上設計

首先，我們需要開發一個邏輯，對頁面的結果進行分組和排序，重點聚焦在瀏覽的起點以及瀏覽的順序。如果這個點沒有做好，用戶在瀏覽多個畫布中的匹配結果時就會有強烈的跳躍感。我們一開始的嘗試都建立在現有 demo 的排序邏輯上，它是自動從水平方向排序對象的。（如果你在 Figma 里面做過演示文檔，你會注意到幻燈片就是按這種方式來自動排序的。）雖然這種邏輯對于像幻燈片這樣整齊排列的對象很有效，但我們很快意識到，在處理的頁面上散布著各種便簽（stickies）和形狀時，這種邏輯就行不通了。

3. 利用「章節」(Section) 功能

自從 FigJam 引入了「章節」功能后，文檔就變得更結構化了。我們能夠依次對「章節」的內容進行排序，從而讓排列順序更符合頁面中呈現的分組狀態。在分析了團隊如何使用 FigJam 之后，我們發現大家經常在頭腦風暴期間將便簽分組在一起，提取關鍵主題并修正下一步的方向。有時候這些便簽就匯集成了一個想法的“線索”。項目工程師布萊恩實現了一種空間排序算法，能夠按接近度對元素進行分組，從而使我們能夠對沒有被納入「章節」的結果進行邏輯上的分組。

4. 形成直覺

我們在測試過程中發現，用戶傾向于在豎向的的模塊中從左到右貼便簽，在橫向的模塊中從上到下貼便簽。以此為基礎，我們圍繞模塊的形狀如何影響排列方向（排除很多細微差異的情況）進行了貼合直覺的探索，以使搜索的遍歷體驗更加自然。

我們繪制了模塊形狀如何影響排序方向的示意圖

三、縮放和平移

當用戶在畫布上搜索文本時，畫布會自動放大到匹配項來聚焦?？s放到 100%（譯者注：即原始比例）通常會將文本結果置于最佳的查看尺寸。但有些文本可能看起來很大或者很小。所以我們定義了一個可接受的“有效字體大小”范圍（字體大小 × 縮放級別），以此來定義它們是否需要被放大或縮小。

我們定下的縮放邏輯

當同一個視圖中有多個匹配項時，我們會避免當用戶選擇每個匹配項時都平移視圖。不過這也使得視圖中靠近屏幕邊緣的結果不容易被看到。所以我們在視圖中央繪制了一個看不見的區域，只有當匹配項落到區域外時，才會發生平移。

我們在 FigJam 文件中心繪制了一個看不見的區域，只有當匹配項落到區域外才會平移。

四、Figma：不止于搜索文本

我們在設計 FigJam 的搜索時會盡量讓其簡單，但對于 Figma 內的搜索，我們希望它能更加強大。與 FigJam 中的一個大畫布不同，Figma 的文件可以包含幾乎無限數量的頁面。同時，與 FigJam 中簡單的文本搜索相比，我們需要支持對畫框、頁面、組件以及其他圖層的搜索。

我們確定了 Figma 中關于「查找和替換」的三個主要場景：

1. 文本搜索；
2. 快速定位到頁面和一級畫框；
3. 搜索圖層名稱。

為了讓 Figma 和 FigJam 的搜索體驗保持一致，我們開始了關于搜索條的探索：在畫布上的浮動搜索條和側邊欄中的搜索條，誰更好？FigJam 的浮動搜索條是輕量級的，可以很好地搜索文本。但是如果用它搜索圖層名（Figma 中的重要搜索場景）則會暴露短板。想象一下，在你找到你的結果前，你要先瀏覽大量繁雜的結果。而側邊欄搜索框在顯示圖層名稱匹配項上做得更好，但感覺比浮動搜索欄更重，而且我們并不清楚如何將文本和圖層的結果更和諧的結合在一起。

浮動的搜索條——我們探索的方向之一

我花了數周時間探索各種方案，包括一些結合了兩種搜索框的混合型設計方案，不過都沒有感覺特別滿意。

我們嘗試了一些方向，但并不滿意。

這是我遇到的最棘手的問題之一。我決定在「評論」中提出我的困惑和想法，讓團隊其他成員提供一些意見，而不是試圖獨自解決這個問題。針對這個復雜的問題，團隊成員給了我很多反饋和不同的意見。

來自同事們的不同觀點

我和我們的產品經理 KC 一起對「查找和替換」的目標進行了優先級排序、分析了我們的方案，最終找到了解決辦法。我們意識到最高優先級的目標應該是圖層和頁面的搜索，所以僅在圖層面板中設置搜索欄是更好的方案。優秀的圖層搜索體驗，比完全與 FigJam 的體驗保持一致更重要。因此，我們刪除了浮動搜索欄，并嘗試在圖層面板中合并文本的搜索結果，最終得出了合理的設計方案。

五、細節和反思

整個項目中有太多的細節需要我們花時間研究。在這里我會用幾個例子來闡述我們是如何研究的。

1. 設計快捷方式

搜索是一個高度依賴鍵盤的功能，從按下 ?F 鍵輸入搜索項到瀏覽結果，設計一組直觀的快捷鍵是重中之重，也是最具挑戰的工作之一。

我們在內部測試中發現了一個有趣的現象：一些來自 FigJam 的用戶會習慣性地按下 Enter 鍵來一個個瀏覽 Figma 中的匹配項。

我們為內部測試創建了一個專門的 Slack 頻道

那么答案似乎很明確了，我們可以如用戶所期望的那樣在搜索中支持 Enter= 下一個。不過仍有很多問題尚需斟酌：

1. 當你按下 ?+F 搜索某個頁面時，按下 Enter 需要打開到這個頁面；
2. 如果我們搜索文本/圖層時支持 Enter= 下一個，但在頁面上支持 Enter= 打開到頁面，那么就會產生不一致性；
3. 如果在頁面上支持 Enter= 下一個，那需要有另一個快捷鍵來支持打開到這個頁面；
4. 如果我們不支持在 Figma 中使 Enter= 下一個，這將與 FigJam 不一致，擾亂了用戶的肌肉記憶；
5. 如果我們在兩個產品中都刪除 Enter= 下一個，那可能無法滿足用過其他搜索工具用戶的期望。

在測試原型和迭代之后，我們的直覺是在文本/圖層中使用 Enter= 下一個，在頁面中使用 Enter= 打開到某個頁面。

2. 向插件學習

把從插件開發中學到的東西應用到原生功能的設計和開發中，給了我們很大的啟發。我們不是簡單的復制插件的 UI，而是把這個過程作為一個學習優秀插件的機會，從而改進我們的工作。

比如我發現，在替換一個文本后，畫布應該稍作停留，然后再跳轉到下一個文本。這確保了用戶能夠在繼續操作之前直觀地看到其替換成功的狀態。

開發Figma和FigJam的原生功能時，我們從插件中學習了不少經驗。

插件中“保留原始大小寫”的設置項允許你保留目標文本的大小寫。我們在新的設計中完全刪除了這一設置項，因為我們采用了一種能覆蓋大多數常見情況的智能規則。這樣用戶就少了一件需要操心的事情?？赡芸雌饋砗芗毼?，但是這些小細節加起來，會在用戶體驗上有很大的提升。

我們在新的設計中移除了“保留原始大小寫”的設置項

最重要的是，我感受到了凡事均需權衡利弊、不可一概而論。即使是看起來很絕對的問題也不會有完美的答案。我們的每一個判斷，都來自產品、開發和設計幾個月的辛勤的工作，都是把實驗和直覺結合的結果。

非常感謝 Figma 工作組：產品經理 KC Oh、工程師 Molly Lloyd、Brian Schlenker、阿克謝·蘇布拉馬尼亞姆、UX 文案設計師 Ryan Reid 和 marketer Sula Yang，是他們讓這一切成為可能。同時感謝社區中參與測試的所有人！您可以了解更多關于查找和替換的內容。

歡迎關注作者微信公眾號：「We-Design」