Photo by Rohit Farmer on Unsplash

本文為<如何應對設計意見>系列文章的中篇,著重在要求設計意見時的建議做法。若想知道糟糕的設計意見有哪些特徵,請參考我寫的上一篇文章:

<如何應對設計意見> 系列由 Handling Feedback as a UX Designer (By Treehouse)的課程學習筆記所彙整改編。如果看完我的整理認為有所收穫的話,去上一遍該課程一定會讓你覺得更加滿載而歸。連結如下:

上一篇文章談到糟糕的設計意見有哪些特徵,了解這些特徵可以幫助我們給出更好的設計意見。

但很多時候我們也會要求其他人對自己的作品給出一些意見。有時候僅僅是思慮枯竭,需要有人從旁提供新鮮的視角;也有時候我們會在正式提交作品之前,徵詢需求方或是設計主管的意見。這時候我們應該如何詢問才可以引導意見的給出方給出適當的設計意見呢?

本篇文章會介紹 6 個能夠用來引導給出方給出好意見的資訊。你可以在要求設計意見時同時給出,為雙方省下不少時間與精力。

1. 設計的目標對象與情境假設

充分表達設計所針對的目標用戶有什麼特徵、想要達成什麼任務以及身處什麼情境。

了解這些之後,可以讓人有充足的資訊同理目標群體去思考設計的有效性,也更能去理解設計師的設計決定。

2. 限制

說明設計專案所面臨的各種限制:如時間、技術或任何其他的設計限制。

在不明白設計限制的情況下,意見給出方可能給出超過限制的建議,造成溝通時間的浪費。先行溝通設計限制就可以大幅避免這樣的情況。

3. 目標

清楚表達設計案欲達成的目標,如提升點擊率、引導分享、增加使用時間等等。

將項目目標表達清楚可以為接下來的討論建立基礎,避免發生偏題的情況,也可以引導對方給出有利於項目目標的建議。

4. 設計決定與背後的邏輯

演釋你的設計決定以及背後的邏輯與依據。

這樣做可以讓對方了解你的思考邏輯、運用了哪些額外資料、考量了哪些交互法則。這樣做也可以讓對方對於你在本次設計中格外重視的部分有所了解,讓溝通更加流暢。

另外,不要忘了提到你做了哪些嘗試 — 無論是失敗的或成功都無仿。這樣做可以讓對方知道有哪些設計想法已經被嘗試過而且是行不通的,避免對方提出你已經知道不可行的意見,浪費彼此的討論時間。

5. 目前所處的設計階段

產品設計從手繪草稿到高度擬真的 Mockup 可以分為很多階段,表明你正處在哪個階段可以讓對方知道應該著重在什麼地方給出建議。

這點在設計圖無法表明設計階段的時候格外重要。例如有的團隊會使用 Mid-Fi Wireframe 來進行前期的解決方案嘗試;如果團隊具備設計組件庫,甚至也可能會直接使用UI組件進行。如果不加以解釋,觀看設計稿的人很有可能會假定設計已近乎完成,進而影響到給予設計意見的焦點甚至是意願。

6. 需要哪些方面的協助

每個設計師都有自己的強項與弱點,每個設計案也有不同的能力需求 — 如文案撰寫、視覺傳達、流程設計等。讓對方知道你在哪方面特別需要建議,可以引導對方給出更合乎你當下需求的建議。

給出設計意見不是一件簡單的事情,而透過為意見的給出方提供更完整的資訊可以幫助他們給出更好的意見,為雙方甚至整個團隊省下更多寶貴的時間。

全文完。

如果喜歡我的文章,請給我個Clap或訂閱我吧👏👏👏

我的其他文章👇


Photo by Icons8 Team on Unsplash

本文為<如何應對設計意見>系列文章的上篇,著重在糟糕設計意見的特徵。

<如何應對設計意見>系列由 Handling Feedback as a UX Designer (By Treehouse)的課程學習筆記所彙整改編。如果看完我的整理認為有所收穫的話,去上一遍該課程一定會讓你覺得更加滿載而歸。連結如下:

避無可避的爛意見們

幸福的家庭都是相似的,不幸的家庭則各有各的不幸。設計意見也是一樣 — 好的意見都是相似的,但爛意見卻各有特色、千奇百怪。

好的意見能夠明確指出設計可改進的地方。除了表達清晰、易於理解,還可以讓人知道接下來該如何行動。一個極品的意見甚至能恰到好處的給出方向但又不限制想像,讓設計師有足夠的空間自由發揮、設計出更好的作品。

相反的,爛意見則很難幫助設計師產出好設計。不僅會讓設計師感到困惑、喪失自信、對自己的專業能力或審美感到懷疑,一不小心甚至發展成人身攻擊(或物理攻擊)也非常有可能。

那麼爛意見有哪些種類或特徵呢?

過於主觀

過於主觀的意見是基於個人偏好所給出的意見,就像有人喜歡貓、有人喜歡狗、有人害怕鳥一樣。

這類的意見通常都圍繞在視覺上,例如顏色、粗細、字體等等。赤裸裸的主觀意見會以「我比較喜歡」開頭;稍經包裝的則會使用寬泛,但僅能表達好壞的形容詞 — 例如「不好看」、「不適合」、「沒感覺」。

由於這類意見基於的是個人偏好,缺乏討論的共同基礎 — 沒有一個人可以說服另一個人。最後很容易演變成對設計師審美能力的攻擊,讓氣氛尷尬到不行。

Credit: Giphy
💡例外: 當意見給出方與產品的目標群體是高度吻合時,主觀意見是極具參考價值的。

指示性太強

指示性太強的意見是直接告訴設計師「做什麼」的意見。這類的意見沒有指出為什麼現行方案行不通,也未闡述該意見背後的設計邏輯。

缺少設計邏輯的支持會降低意見的說服力,也無法幫助意見交流。長期下來對團隊的氣氛、設計師能力的精進都有負面的影響。

不完整

不完整的意見與指示性太強的意見類似,都缺少了意見背後的前提、邏輯與事實根據。但不完整的意見更加糟糕,因為他連改進設計的指示都沒有,留給設計師的只有五百個為什麼。

不明確

不明確的意見是讓人摸不著改進方向的意見,通常伴隨著非常抽象的形容詞:例如「清晰」、「質感」、「設計感」等等。

這類意見大概是最常見的爛意見了,畢竟不是每個參與討論的人都受過設計訓練,也不是每個人能夠精準表達自己的想法。甚至有時候就算是設計從業者也沒辦法給出很明確的設計建議。

Credit: Giphy

不顧項目範疇

有時候意見的給出方會建議設計師「想得更廣」、「全盤考慮」、「花時間做更多研究」等等 — 這類的意見通常都高估了項目的範疇,認為為了達到更好的效果,設計師應該要「Dream Bigger」。例如功能列表不好懂,就建議重定義整間公司的產品框架;用色不好看,就建議對產品主視覺進行全面升級, etc.

不可諱言,這類的建議很多時候是有價值的,甚至是帶領產品前進的原動力之一。但儘管如此,它們對眼下項目的幫助極其有限,設計師也沒有辦法依據這類的建議去產出更好的設計。

自私

自私的建議是企圖達到自身業務目標而不顧項目目標的建議。舉例而言,筆者過往就曾經遇到過產品經理為了增加自身產品的曝光量,硬是建議設計師在設計時特別強調某個元素,儘管這樣做對整個項目有害。

偏題

偏題的設計意見是與設計師所需要的意見主題不同的意見。

廢話。( ⇦ btw這就是個爛意見,不完整那種)

在每個設計階段,設計師所需要的意見主題都是不同的。在設計前期,設計師更加需要方向性的意見,以確保設計走向符合期待;在設計完成之前,則可能需要更多視覺細節、文案細節的意見。

專案的內容、設計師本身的能力構成也都會影響到他所需要的意見主題。重視資訊結構的專案需要更多這方面的建議、平面設計能力較弱的設計師需要更多相關的指導。

偏題的意見大多數時候是有其價值的,但因為與設計師當下所需的意見不相稱,因此還是無法有效率的幫助設計師解決眼下的問題。

Credit: Giphy

結語

儘管糟糕的意見千奇百怪俯拾皆是,但與這些邪惡的東西和和平相處並且解決他們大概是設計師的天職。

了解糟糕意見的種類可以幫助我們更有效率的溝通,避免將來同樣糟糕的意見繼續傷害自己,也可以防止我們自己變成糟糕意見的產地去荼毒別人。

然後世界大概就會和平一些了吧。

👇看看我的其他文章


Photo by Jack Hamilton on Unsplash

這是一篇關於設計系統的失敗經驗的分享。內容裡並沒有扭轉局面然後最後成功的情節,如果喜歡喜劇結尾的讀者可能要失望了。

但如果你跟我一樣是喜歡幸災樂禍的正常人,那可能會覺得有趣。

故事背景

我的公司是一間專做印度市場的線上旅遊公司,目前總部約有一百五十位員工。在這個悲劇發生時,產品部門總共分成三個小組:UI(四人)、UX(三人,包含我本人)、產品經理(五人)。

我們的產品橫跨各種裝置,並且已經上線有兩年的時間。

所有悲劇都有一個美好的開頭

Credit: Giphy

時間是2019年年中,我正結束一個中大型的項目,並正要開始另一個中大型的項目。

在剛進公司就被委以重任,並且獲得廣泛認可的我,認為我們應該要開始進行設計流程的重整。會有這樣的想法除了因為公司的產品確實需要一致性的規範,我也認為無所不能的自己,可以也應該帶領這樣結構性的工程(真是蠢斃了)

我很快的做了基本的資料搜集,研讀了Material Design的整份文件。同時,致電給在Oppo擔任高級設計經理的哥哥,徵詢他建構設計系統的經驗。

在接下來的一個禮拜內,我徵得了主管的認可,找了UI設計師、工程師們開了第一次的設計系統的Kick-off meeting。向他們推廣設計系統的優點,並且把自己對建構設計系統的想法、預設的時程向他們熱情的分享。

大家點著頭點著頭、原則性的同意我所說的,會議就這樣在我的樂觀情緒下結束了。

問題漸漸浮現,但被刻意忽略

Credit: Giphy

團隊裡有四個設計師,我請他們做的第一件事,就是整理出我們產品中的各個使用得到的組件清單 — 我的想法很簡單:先整理出一個全面的清單,再依據重要性決定設計的優先順序,接下來進行開發、維護。

一個禮拜之後,我請他們交出所整理的組件清單,卻發現清單的內容粗淺、組件的分組方式不合理,不適合作為項目的規劃依據。

設計師們表示他們並不了解組件清單應該包含的內容,因此只憑藉直覺與經驗輸出了這份清單。我接著問他們是否有去瞭解過主流的設計系統,怎麼對組件進行規劃分組、是否了解原子設計理論,最後卻得到不置可否的答案(就是沒有,但不好意思說)。

「沒有關係吧,這只是一個小挫敗,項目開始的時候都會這樣的,大不了清單自己列。」我想。於是我花了一些時間把清單完善,然後開始規劃執行的計畫。

船到橋頭,才不會自然直

Credit: Giphy

一個多月之後,我們還在沒完成第一階段的設計。

到了設計交付的那一天,我滿懷期待的招集了部門,希望進行一次盛大的發表。這一次的交付內容主要包含了顏色系統與字體系統的設計。

意料之外的是,本應充滿掌聲與激勵的初次發表換來的卻是滿場的沈默。

在顏色部分,設計師列舉了目前使用的品牌色,但卻沒有給出將來的用色規範、用色比例、所有的顏色也沒有進行足夠的擴充。在字級部分,設計師給出的字級分類方式並不標準、沒有考慮Spacing、Casing。

最重要的是,設計師在呈現設計規範的時候,並沒有呈現出任何支持這些設計決定的理論依據、思考過程。也沒有使用現有的產品介面進行實用演示。所有人都不知道這份設計規範實際投入使用會是什麼效果。

會議因此就在一個「大家覺得不說些什麼會大事不妙,但卻不知道怎麼給建議」的氣氛下結束了。

在會議的最後,我向所有人重新解釋了一次設計系統的重要性。但其實在發表這些結語的同時我已經意識到大事不妙了 — 我以為事情就會自己走上正軌的想法過於天真,但為時已晚。

接二連三的失敗,然後集體失憶

Credit: Giphy

兩個禮拜之後,負責icon設計的設計師交付了產品所有icon的新設計,但結果慘不忍睹 — 與品牌不搭、與字體不搭,甚至與其他icon不搭。儘管如此,我們為了支持設計還是堅持使用了這些icon,然後在幾次的會議上被公開挑戰美感。

在之後其他專案中,我們嘗試使用設計規範所訂定的顏色與字體,但產品經理卻以不夠美觀、無法創造視覺層級、無法凸顯個別元素的理由而拒絕使用有設計系統的版本。

當我們把這個問題上升到產品部門主管時,得到的回應卻是「依照產品經理的決定執行」。甚至主管自己的需求也幾乎不會遵照設計規範進行設計。

設計師們也因此大受打擊。原本積極參與的設計師開始展現似有若無的逃避心態,而本來就不看好這項專案的設計師更是直接罷工。

這個時候的我才終於意識到這項專案已經失敗了,而且早在我意識到之前就已經死得透心涼。

設計系統從此成為一個大家避而不談的話題,每當有人提起總是被苦笑以對。項目計劃遭到擱置,我悄悄把在任務管理系統裡與他相關的任務一個一個撤下。主管似乎也跟我心照不宣,原本的部門周會裡追蹤設計系統的議程也被直接取消了。

就這樣,在幾次熱烈的會議、數百個小時的工作時間之後,我們換來不堪使用的icon庫、沒人敢用的顏色字級系統,以及低落的士氣。

所以,問題到底出在哪裏?

在擁有更豐富的管理與項目經驗之後回想起來,我想這次失敗的原因主要包含以下:

正當性不足

設計系統的執行者、使用者(UI設計師)與這項專案的發起者(我 — UX設計師)並不匹配,降低了管理專案的正當性。

在背景介紹中提到,我們的部門分成UI、UX、產品經理三種角色。在理想的情況下,應該由UI設計師來發起並執行這項專案。但我以為自己的能力足夠,就有意識地忽略了這個問題。

另外,雖然我對於設計系統的要比部門內的UI設計師要熟悉,但在沒有視覺設計的經驗背景的前提之下,我與UI的溝通總是講著不同的語言、有著肉眼可見的鴻溝。我與UI設計師之間也沒有上下級的隸屬關係,在組織授權層面就沒有正當性。

不自量力

團隊中有一半是初級設計師,剩下的設計師也沒有搭建設計系統的經驗,因此在設計系統的搭建過程中,所有人都像摸著石子過河,對項目目前狀態、下一步是什麼一片茫然。

除此之外,我們一開始設定的目標就太過弘大了。

我的第一步是請設計師們列舉所有可能使用到的組件清單,而這個工作流程背後的思想就是希望可以一次性做出涵蓋所有組件的設計系統。現在看來真是既不自量力也不切實際呢。

欠缺共識與認可

我想這是整個專案失敗的最主要原因,也是我從項目的開始到最後不了了之都持續在犯的錯。例如:

  • 在與主管提議時,我高估了主管對設計系統的重視。以至於我沒有花足夠的時間準備詳盡的提案、讓她充分認可專案並 onboard
  • 在與主管提議時,並沒有先與UI設計師討論過,讓UI onboard
  • 在項目正式的啟動會上,並沒有把產品經理邀請進來,讓產品經理 onboard
  • 在制定項目計劃的時候,並沒有與主管、UI設計師充分討論,取得他們對工作方式與流程的認可

這些我該做未做的溝通,為專案留下許多後遺症。部門上司不認為設計系統重要,沒有給項目足夠多的關注或資源,沒有給我充分的授權;UI團隊的角色流於聽話辦事的執行者、對項目一頭霧水;產品經理不了解設計系統對於體驗、系統健康的重要性,對設計規範不認可也不想用。

結語

以上就是我在執行設計系統時的失敗經驗。除了娛樂一下喜歡幸災樂禍的讀者之外,也希望提供了一些自己的屍體讓大家可以踩著前進,做出更好的設計。

其實寫這篇文章的一個重要背景,是因為我又發起了一次設計系統的專案。事過境遷,我已經成為了團隊的組長,直接控制了UI設計師們(反派笑),也在過程中盡量避免了以上所提到的問題。

這次成功了的話,我會再寫成另一篇文章描述始末,祝我好運。

Credit: Giphy

如果喜歡我的文章,請給我5個clap👏
預祝我的專案成功,請給我10個Clap👏👏
如果暗暗希望他失敗好讓你可以繼續幸災樂禍,請給我30個clap(當然我知道你在開玩笑)👏👏👏

👇我的其他文章


From Original Post of 12 Signs You’re Working in a Feature Factory

本文翻譯自 John Culter 的 ”12 Signs You’re Working in a Feature Factory“。

「功能工廠」是本文的作者用以描述一個軟體公司像無頭蒼蠅一樣一昧打造新功能,不顧長期目標與產品策略,最後不僅一事無成,還累垮工程師的奇異現象。

儘管聽來獵奇,但在軟體、網路相關產業工作幾年之後,我發現這樣的現象並不少見。功能工廠非常糟糕,且並不單單對於工程師。一個流於功能工廠狀態的公司對所有人都是有害的。

注:為求文意通暢,譯者在不影響主旨的前提下,對於本文進行了修飾性的增刪。

以下正文開始:

(這篇文章寫在2016年,我最近在2019年寫了另一篇關於從那之後學到的事情的文章

過去兩年裡,我曾在許多研討會上使用過「功能工廠」這個詞。我之所以開始使用這個詞彙,是因為一個軟體 …


Photo by Austin Distel on Unsplash

本文將介紹五種我在工作時常用的UX設計指標,希望可以在設計管理上對大家有幫助。

為什麼需要有UX指標?

應該訂定UX指標的原因有很多,最重要的是可以幫助你診斷問題、高效的管理團隊、對標競爭者與協助多方溝通

診斷問題

指標之於產品就像血壓或體溫之於人體,是產品的健康指標。每一個指標都是以不同的視角觀察產品的健康狀況,當指標發生了變化時,也就代表什麼地方出問題了。

一個優良細緻的指標體系可以精準的定位出問題的出處。許多業務問題,例如銷售額的下降、註冊用戶數的減少都可以經由指標的分析進行診斷與發現瓶頸。

團隊管理

在團隊管理上,指標可以用來證明個別成員的價值,也可以用來證明整個UX團隊的價值。

畢竟介面是否好看易用只是主觀且模糊的現象,實質上對業務的改善並沒有被捕捉計算,唯有客觀且公正的指標才是能夠讓各方心服口服的關鍵。


在專案發想、資料搜集或進行設計時,我們常會用到多種不同的視覺輔助工具來釐清思緒,舉凡心智圖、表格、便利貼、流程圖等等。

很多不同的工具都可以幫助我們描製這些視覺輔助的圖,諸如Draw.ioProcessonTrelloXmind等等。儘管他們都十分好用,但管理這些不同的文件工具總是讓人頭很大火很大。

使用的工具太多,不僅檢索資料變得麻煩,也拉低了與同事溝通的效率。每次為了講解主題,需要同時打開多個視窗,分享參考文件時也需要附上一長串的連結清單,讓人手忙腳亂。

Whimsical

Whimsical 官網

今天要介紹的Whimsical就是一款可以解決這個問題的繪圖工具。

Whimsical 集心智圖、流程圖、便利貼與原型圖於一身,讓使用者可以在一個畫面上表示所有專案相關的資訊。

更棒的是,他是純線上的工具,只要有瀏覽器就可以直接使用。分享簡單方便,還可以實時與多人進行編輯,非常利於多人的線上Brainstorming

如果你的團隊利用Notion來做項目的管理,那Whimsical更是超級方便,可以直接以嵌入的形式展示在Notion文件,補齊了Notion無法繪圖的缺點。


儘管UX設計師這個職位已經存在很久了,但很多人還是不了解這個職業在做什麼。

我嘗試在Google 搜尋「UX設計師是什麼」,所得到的答案幾乎都很抽象,甚至有的敘述與我目前的工作經驗相差甚遠。

例如出現頻率很高的這張番茄醬圖就大錯特錯的傳達了UI 與 UX相互對立的概念。真實的情況是我們各司其職,一起把產品做得更好。

大錯特錯的UX & UI 比較圖

因此,我希望可以透過一個假設性的案例,向讀者說明UX設計師的真實的工作內容,以及我們為軟體設計提供了什麼價值。

那麼,我們就開始吧。

註:本篇文章會以產品經理、UX設計師、UI設計師共同合作的前提做討論。至於這些角色分別在軟體的設計上擔任什麼角色,將來會再撰文說明。

1. 了解需求

UX設計師的工作通常都是由與產品經理發起的。產品經理會先與需求方溝通後生成產品描述,並與我們進行初步討論。

在這個階段,我們需要暸解以下四點:

  1. 客戶:也就是需求方,可能是老闆、其他部門或甲方
  2. 用戶: 產品的終端使用者
  3. 目標:本次需求的問題。例如加入XX功能、提升XX%的購買量都是可能的目標
  4. 限制:時間、成本、或設計限制

在本次的案例中,我們假設需求極為單純:


Photo by Web Hosting on Unsplash

本文假設讀者有基礎的GA知識以及事件層級知識。

Google Analytics 的事件(event)功能讓我們可以在頁面層級下,更細緻的管理、查看我們所需要的使用者行為資料。但當你的產品規模愈來愈大、功能愈來愈多,你的事件也就愈來愈難以管理。特別是在你的團隊不只一個人需要進行事件蒐集的時候。

本文旨在分享筆者的事件管理經驗,以四個步驟去避免一些事件設定常見的問題,如命名模糊、重複命名、事件功能重疊以及跨團隊溝通

步驟一:建立唯一真實來源(Single Source of Truth)

一個數位產品可能會區分成多個組成模塊,並由不同的團隊負責。有些時候行銷人員也需要對行銷相關功能進行追蹤以衡量行銷活動成效(如Banner點擊)。不同團隊各自為政、訊息不流通,就會讓資料變得難以閱讀,也可能造成相同資料重複搜集的情況。

建立唯一真實來源就可以解決這個問題 — 意即讓所有的事件追蹤都統一的在同一份文件、或同一組文件之中進行管理。這份文件應該詳實紀錄事件的追蹤目標、需求方、提出日期、設置者、生效日期等。

這樣一來,所有新的事件設置前,都可以參照此份文件以考慮到過往的事件設置,並讓所有部門保持訊息的一致。也可以讓負責設置事件的夥伴有單個、可信賴的參照目標。

筆者的做法是使用Google Sheets,方便各個相關團隊進行查看。

步驟二:建立檢索邏輯與命名規範

GA事件提供了四種資料維度:Category, Action, Label, Value。除了Value限制了只能傳送數值之外,其他三個維度都沒有形式的限制,給予了使用者很大的自由。因此你可以依據不同的檢索邏輯去建立自己的事件歸類系統。

但分類邏輯若不一致就會造成災難。考量以下的例子:

產品:襪子電商
頁面:商品列表
需求:搜集使用者的篩選行為

這個事件就可以用至少三種檢索邏輯設定,舉例如下:

  1. Category: Product List(頁面)
    Action: Filter(行為)
    Label: Used Filter (輔助資料)
  2. Category: Filter(功能)
    Action: Apply Filter(行為)
    Label: Product List (輔助資料)
  3. Category: View Product List (使用者階段)
    Action: Filter (行為)
    Label: Used Filter (輔助資料)

不同的命名慣例也會造成衝突。如Product List就可以被命名成Product List、ProductList、Product_List_Page。

由上可見,如果不建立一個統一的檢索邏輯與命名規範,在多個部門與時間的齊心協力之下,事件管理文件亂成一團指日可待。

至於該用什麼檢索邏輯,筆者認為依據不同產品的業務需求與企業文化,會有最適合的方式,不必依照他人的規範來做。命名規範方面,建議用首字大寫、空格分字的形式,較方便閱讀。

步驟三:指派事件文件管理員

為了確保管理文件的精確性,並簡化問責機制,最好指派一個、或少數的夥伴擔任文件管理員的角色。

文件管理員應該要是唯一可以編輯事件管理文件的人員。對文件的品質全權負責。文件管理員的工作包涵但不限於:

  1. 確保事件資料沒有重複搜集
  2. 審閱事件檢索邏輯與命名是否遵循規範
  3. 紀錄事件開始追蹤、更新的時間

步驟四:建立事件設定流程

最後只需要根據你的團隊結構與組織文化,設計一個可以通用的事件設定流程即可。

以下以筆者的團隊為例:

團隊基本訊息

  • 設置需求來源:行銷團隊、產品團隊與其他團隊
  • 事件設置實踐者:開發團隊
  • 設置方式:前端程式碼與GTM通用

設定流程

  1. 向文件管理員提交事件規則與命名
  2. 檢查合規後,管理員將事件需求記錄於待設置文件
  3. 通知開發團隊
  4. 進行設置
  5. 上線後,管理員將該事件由「待設置」移至「線上」

Tips: 建議可以將設定流程也記錄於事件管理文件中,以方便事件需求方隨時查看。

結語

事件的管理方法並不複雜,真正複雜的是在實踐的過程。

如果你的團隊已經進行事件追蹤一段時間,那要建立這套制度更是有可能遇到重重的困難與阻擋,畢竟每個人都有自己的做事方式,而且沒有人喜歡改變。

除此之外,合適的檢索邏輯也需要時間去研究與規劃,並且也需要定時檢討,確保現下的規範、邏輯符合業務需求。最重要的是文件管理者需要扮演好自己的角色,嚴格執行規範與流程。

如果你喜歡我的文章的話,就請不吝嗇的給我一個掌聲吧!

鄭斐凡 Ian Zheng

UX Designer@ EyeBuyDirect — the most fast-growing online Eyewear Store in U.S. Currently base in Shanghai, China. Personal Website 👉 http://bit.ly/ffcUXDesign

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store