[轉貼] iBeacon 走過這一年，十三個不可不知的應用領域

http://www.inside.com.tw/2014/06/05/ibeacon-one-year

我沒有iPhone已經一段時間,雖然目前有iPad,但是畢竟不是那麼的mobility
因此對於ibeacon的發展就沒有如此關注,
但直到看到這篇文章才發現原來ibeacon的發展已經如此完整,
因為身處在台灣,對於許多已經在美國開始應用技術也很難有親身體驗,
我認為,對於廠商來說,這表示把行銷跟銷售又往前邁進了一大步,

以前就是請個人在那邊喊特價或是限量
現在可以在省下人力的狀況下,提供更完整的資訊

但不可避免的是,羊毛出在羊身上

當今天我們享受到所以更加便利的服務之後,
也就意味廠商想要你從口袋掏出更多錢來,
同時,你的隱私權也更廉價(至少,最簡單的一點就是,知道你用iOS Device)
人性很怪,當一直提醒要小心隱私的時候,絕大部分的人都不會當一回事,
但是當今天因為自己開放隱私給別人,而被侵犯的時候 (這種行銷手段基本上就是一種)
我們又會覺得很生氣,可是明明就是因為自己害的

說真的,對於此類技術完整發展這一天的到來,我真是又期待又怕受傷害...

[New Stuffs] VIIA手機行動充電槍套式皮套評測

非常久沒來寫開箱文(哭哭~ 又懶惰又沒錢),

這次應朋友邀來評測一個新產品


本來沒有太大興趣,但是一聽產品概念,

收納之餘還可以順便充電,

之前我沒有看過能完美結合這兩個功能的產品,

所以一下子興趣就來了


先來看產品外盒,外盒我覺得中規中矩

不過大大的寫了一個4000mah的電量標示,清楚強調產品特色,但色彩稍嫌太暗,
雖然感覺廠商想帶出的是科技感,但是這種產品是針對年輕人的話,可能吸睛度沒有那麼高



兩側清楚產品的feature,以及功能,
同樣,設計我覺得沒有那麼貼近比較年輕的感覺,,但是同樣中規中矩




背面設計,我不清楚為何這個產品外盒設計需要開那麼多窗,
我想一個產品的包裝如果足夠清楚敘述特色,並且沒有safety issue的話,
其實可以不用開那麼多窗


背面很明顯地把目標客群設計為年輕人,
As I said, 要強調的點如果放那麼小,色彩又不是一般年輕人所喜歡的多彩,
可能比較難讓他們注意到


來看產品了! 我覺得廠商有設想到不同的情境,
所以才刻意設計了比較黑色中性的產品外觀顏色,
以讓產品可以適用於不同穿著,就算是比較正式服裝也不會顯得太突兀



重點來了,收納之餘還能兼顧充電!


我個人蠻認同這兩個combination在一起的產品,
目前大部分人的解決方案應該都是放在袋子裡面,
拉一條醜醜的線充電,反正在袋子裡面沒有差
只是每次有電話來,不是沒聽到就是手忙腳亂地找電話,
我要說,這樣真的很不Elegant XDDDDDD

這個產品一定程度解決了大家的收納以及充電的需求,
加上做工跟設計很不錯(相信我,鐵環+吸磁鐵不是很便宜...)
掛著一定程度上解決了必需的手機收納以及充電




可惜的是我4.7吋的手機加了保護套其實是放不下去的Orz
我一定要把保護套拿起來才能放進去
我其實有點懷疑5吋手機是不是真的放得進去....


廠商很貼心的是有考慮到那麼大隻抽出的問題,
只要把這個有磁性的扣帶抽起來,
就可以把手機抽出來,不然說真的以皮質的特性,
要及時抽出那麼大支的手機實在有點困難



實際帶出去其實沒想像中那個卡!
我本來以為一個大袋子放在旁邊應該會很卡,
沒想到比想像中的好多了,只是當然還是會感覺有個東西在那邊晃
看來廠商有好好考慮到配戴的舒適度



其實我當初一看到產品是"一個收納袋+一個電池",實在是感到有點傻眼,
對我來說,我自己拿一個雙層腰間收納袋+充電電池也完全可以達到相同效果
只是好不好看,合不合用,有沒有那麼完整化的差別

其實更讓我比較擔心的地方,廠商的想法很好,卻也非常容易被模仿,
我相信華強北或是中關村的人可能一看到,
三天就早出一個一模一樣的東西出來,
加上一些劣質電池,打個六七折絕對不是問題

現在我自己身處在相關產業中,
非常清楚這些廠商的能力,除非你能做出差異化,
而且這個差異化又是極難被追上的,
就這個產品,我沒看到太大的差異化

我相信台灣廠商的用料一定比較佳,但是現在很多消費者不看用料,
只在意好看跟價格能不能接受(哭哭的受害者)
但以定價跟做工品質,我想眼光雪亮的消費者還是會認同這個產品的!
特別的是我納悶之餘特別跑去上了廠商的網站,
我覺得網站設計沒甚麼問題呀~ 甚至比產品彩盒設計還更好....


這邊不負責亂建議廠商一個行銷方法,
既然在官網上面有一些情境跟周邊產品搭配,
那就辦一個活動,請網友們集思廣益想還有甚麼拿來放,
然後選出幾組最有創意的,然後直接送出幾組,
我認為這個效益絕對大過於這幾組的成本費用,
不過說過啦~ 這是我覺得的,不負責的呀~ XDDD

[My Thought] 成就偉大事業，不可能討好每個人

筆者日前看到這篇文章,成就偉大事業，不可能討好每個人



"有意義的成就，常常無可避免地惹火您週遭的世界。"
第一句話就把讓我點頭如搗蒜,
完全說到我心坎裡面去


其實如果跟幾年前的我說這句話,我想當時的我不會有甚麼感受,
我本身個性是天秤座,一直抱持著與人為善的思想,
也想要滿足,講難聽一點,是討好所周圍所有人,
但近幾年越來越覺得,如果要把事情做好,真的必須得罪人

並不說我現在因為想做好某些事,所以得罪別人,
反而是我常常被別人得罪,
在工作上我有時會被同事惹怒,但幾次下來,
發現問題點其實是我自己根本沒有把事情做好,
卻又回過頭去怪同事: 幹嘛那麼兇! 沒做好就沒做好不然擺爛呀!

其實這非常要不得

拿我同事跟主管來說,剛進來的時候,
我非常不習慣會議上有時針鋒相對的狀況,
但漸漸發現那絕對是必要的,因為有人把事情講出來,
攤開來說,大家才會知道問題點出在哪裡,對方在想甚麼,
只有當我知道你在想甚麼,事情才會繼續運作下去
不然繞了好幾圈都是白費工,到頭來你會覺得對方效率很差,
對方也覺得你很挑剔,但是事情永遠不會做好,
當然我們可以選擇大家好好說話,
但是幾次下來之後,你會發現,事情怎麼會動的那麼慢
以前在廣告公司就是這樣,
隨便開個會就是六個小時起跳,然後常常完全只是在繞圈子,
搞得我整個下午就是在等雞排來

事情要效率,一定需要有人出來講話,
只是無可避免的,這個人常常會變成壞人的角色

黑臉誰要扮? 沒有人要扮你就等著事情delay!

不過說真的,雖然我說這篇文章寫得好,但僅在前半段,
我覺得他後半段完全在講不同的事情,應該可以另開一篇來寫....

[My Thought] 張部長新聞有感

這兩天看到這個新聞實在感到百感交集

張善政直指：台灣適合做代工、做品牌愈做愈累

張部長當初上台我想可能是科技業最期盼看到的

畢竟頂著Google亞太總監的光環,有著最前瞻的產學經驗,

我們當然希望他有一番作為

但現在這個新聞一出來,當然有想過可能是被斷章取義的結果,

可是如果是真的不是說對他失望,

而是一個部長,居然對這些希望為台灣拼出品牌一片天的人狠狠的澆了一盤冷水

你看過哪個國家的國防部長還沒打仗就說我們輸定了,塊陶吧!?

這實在令人洩氣到極點! 或許張部長真的高瞻遠矚,

發現台灣不能做品牌才講出如此語重心長的話

但是自己國家產業的最高領導人居然未打先喊輸,你再怎麼樣也不能出去丟自己的面子!



台灣真的不是做不了品牌,

我們看到多少國外企業創始人也是台灣出身,

我們也看到除了科技業,有多少台灣品牌在國外發光發熱,

再回頭講科技業,台積電不是品牌? 大立光不是品牌? 華碩不是品牌?

對,大家都做得很累,大家都知道這是一條艱苦路,

但是大家都很拚,我們知道不可以因為難,

就只做我們會做的,做簡單做的,做現在可以馬上就可以看的到結果的!

我們都知道甚麼才是對的,甚麼才是能長久幫助台灣的,

就算現在看不到結果,我們還是只能選擇往前拚,這才是正確的精神!

[Photo] 日本櫻之旅

 趁著春假跑到日本去玩了一趟,正好碰上櫻花滿開盛況,
這輩子第一次看到這種目不暇給的震撼感,
以前看甚麼天元宮阿里山通通被比下去,
想來下次來日本也未必能遇到這種漫天吹櫻的感覺,

比較可惜的是,因為之前的相機賣掉,跟朋友借了一台富士X-Pro1就衝了,
對於相機某些設定並不熟悉,拍起來有時手忙腳亂,
較難完整呈現出櫻花鋪天蓋地之感
但還是貼出來紀錄一下,真希望下次再來的時候,還能有這種好狀況,
同時有好技術跟好相機 (富士XT-1,好相機,不買嗎?)

[My Thought] Focus

在這個時代,減法比加法更重要,
永遠要focus一件事,從頭貫徹到尾徹底執行,再做下一件事,
而不是以為同時進行很多事情好像很強,
常常只會落到滿手空的地步

[My Life] Work Stuck

最近幾個月的工作只能用悶來說,
從去年11月開始一連串的軟體修改,到新產品的規格制訂發想,
幾乎佔據了我整個腦袋
更別提產品量產時間無限的Delay,
幸好主管的諒解,同事的協助,讓整個過程看起來不那麼糟,
但是該盡的責任要盡,
所以該完成的事情一項都少不了,
偏偏這些工作項目又悶得跟甚麼一樣,
只是不斷的填補漏洞,制式的工作讓我幾乎失去額外的生產力,
跟產線機器人沒啥兩樣

不過再怎麼樣,也只剩最後的幾個月,
不去做,事情永遠在那邊,沒做好,不是只有我Suffer,
很多人都要一起等你,僅能以這首歌來勉勵一下自己

貳零壹肆的第一篇

說來慚愧,整整兩個月沒有任何新文章,
這兩個月其實發生相當多的事情,
也都相當值得大寫一番
其實蠻想非常流水帳的紀錄過去就好,
但我的某些偏執卻又不容許我如此草草帶過,
寧.缺.勿.濫


不過今天會想到上來想,其實是因為前幾日入手了一台NAS,
因此有想到自己架站的可能性,
不過後來想想,這台NAS只有1Bay,架站需要額外的技術,需要研究的事情真不少
如果又要丟照片圖床甚麼的看來是根本不夠用,只能先拿來抓BT用存些資料
再慢慢研究應該如何拿來提升經驗值

[New Stuff] Lumio Light 入荷啦!

不多說,直接看影片



是的,我又再一次戀愛了!


這個Lumio Light是我在癮科技(還是大人物?)看到有人分享出來,
在Kickstarter集資的,一看這個影片我就stunned了
這實在太讚讓我不得不買


終於在11月收到產品了..... (後有說明) Orz
我們來看一下他的包裝,美國貨就是美國貨,
因為前一陣子才在淘寶買了一批東西,
雖然可以很明顯的感受到中國廠商商品的用心跟企圖心,
但要論質感,美國仍然應是贏了一截











這邊是他的配件,後來我才搞清楚那是他的磁鐵跟手提帶,


本體出現!


打


開


了


ㄚㄚㄚ! (從來沒玩過的梗XD)



我相當意外Lumio Light所發出的光相當均衡,不知道是因為跟他所選擇的紙材質是否有關係
廠商應該這方面努力很久




內建電池,聽說可以使用8個小時,不過我還沒有實際用那麼久過
如果沒電的話,可以透過Micro USB充電




可惜的是,我已經錯過前幾批最便宜的集資,
所以買了將近70鎂,加上運費也將近台幣3000了
忍痛買下去之後,才發現集資網站最大的一個問題:
你永遠不知道甚麼時候會正式出貨
(Trust Me, 上面的日期都是參考用的 Orz)
所以其實我在今年四月就下單,等到10月份真的等不下去,
寫信過去問才得到廠商回應說會在11月出貨,
這真是集資網站的痛,不過聽說最近有一個台灣的集資網站宣稱可以解決這個問題,
到時候如果有想要買的東西,就再來比較一下各集資網站的優劣吧~

[轉載] UI Flow教程

前言：群裡有個朋友求UI FLOW（他這樣發的），我認為是 user interface flow,國外很少有這種說明和文檔，於是去國外網站搜了不少，後來，發現他說的不是user interface flow,而是 交互說明文檔（DRD），所以，剛剛接觸UI的設計師們，這些UI相關名詞的縮寫，和意思要搞清楚喲。既然有人求了，於是我發了這篇文章。註：文章內容大部分節選自網絡，因為本人比較懶，懶的碼字了。

界面交互設計文檔是需要交互設計師編寫的，在求職的時候公司也會要求這項基本技能。但是很多設計師們不知道什麼是交互設計文檔(DRD),怎麼寫DRD，格式有沒什麼限制。其實DRD交互設計師自己寫到界面上也行，單獨文檔成文也行，總之就是讓交互設計師能夠將界面承載不了的信息通過文檔沉澱下來，降低項目裡的溝通成本和風險。

　　一、什麼是交互說明文檔(DRD)?

所謂DRD即是用來承載交互說明，並交付給前端、測試以及開發工程師參考的文檔。

在項目中，交互設計師的主要產出物可能依次是：site map，page flow，wireframes。有的大型項目前期，交互設計師有可能還會產出用戶需求分析文檔(與PD產出的市場需求文檔不一樣的是，URD更多側重於對目標用戶的需求分析)。

DRD則很少有人專門撰寫。如果需要對交互設計進行說明，聰明的交互設計師往往會直接標註在線框圖裡，或者在項目中不斷和前端工程師和開發工程師口口相傳，反覆驗收，不斷迭代修改來確保所有的交互設計意圖最終得以呈現。

二、 為什麼要寫?

DRD非項目必需環節，一般情況下也不會為交互設計師專門留出相應的時間預估。沒有這份文檔，項目也會繼續，但是可能項目會為此承擔不必要的溝通成本和時間成本。嚴重的話，項目的質量也會受到影響。所以寫與不寫，交互設計師需要做把握，時間被統一包含在「線框圖」環節內——如果你要寫，請在評估時預留1-2天的時間。

那麼，結合我過去的經歷，談一下此文檔的必要性。

下圖是一個產品開發項目基本的流程。

　　敏捷開發意味著很多不同角色的流程需要並行操作。如果等到產品經理的FRD已經全部敲定，交互設計師再開始去畫線框圖，固然會減少溝通成本和返工風險，但是同時意味著交互設計師的很多想法不被採納。如果產品經理再強一些，他甚至會在FRD裡連原始的DEMO也一併繪製出來了，功能性的需求和界面交互的需求有時無法區分太清楚——比如他會在FRD裡直接要求每頁條目40條，超過40條即分頁。而交互設計師可能會認為像蘑菇街那樣不斷裝載出足夠長的頁面會更親和……所以，我們希望是和產品經理同時開始工作，在術業有專攻的時候相互補充。

同樣，開發工程師也希望及早介入需求，在FRD並未確認的時候就瞭解需求，進而將商業需求和功能需求轉化為開發工程師看得明白的開發需求清單(這個清單，大部分叫做UC，即USE CASE)，當這份清單由工程師需求分析師——在過去，這個角色被叫簡稱為RA，但是目前已經取消此專門的職位，而是由開發工程師代表擔綱此環節工作，為了便於描述，在此文裡，我仍然將做這件事情的人稱為RA——交付給具體的執行工程師後，執行工程師基本上可以當作一條條的checklist開始高效工作，而不必再思考商業邏輯和需求。同樣，測試工程師也需要編寫具體的文檔去指導很多測試人員在開發後高效測試，這也是基於UC和FRD去撰寫的。

所以，開發需求分析是個很重要的環節。那RA是如何來完成需求分析工作的呢?

1、前期介入，對PD進行開發需求評估支持;

2、參與每次的FRD評審會;

3、詳細審閱FRD文檔並不斷與PD確認。

對於做這件事情的人來說，足夠詳盡的FRD是非常重要的。所以一份FRD雖然是PD產出，但是很多實施細節則是由開發工程師不斷溝通評估並確認下來的。而設計需求的傳遞，卻存在很多問題。除了線框圖，沒有「詳盡的說明性的文檔」告訴他們。比如：

　　一方面，交互設計師對產品經理說：這塊由我們來考慮，你的文檔不必包含設計上的說明，這隨時會調整的。

另一方面，線框圖的評審有時會讓RA參與，有時卻沒有叫他們。即使叫上了他們，他們也會發現交互設計的需求變化要比FRD變化快。另外，他們會認為UC不必寫太多關於交互設計的需求。

在某個大型項目結束後，作為交互設計師，我進行了一些調研，聽聽這相關人員是怎麼表述問題的：

開發部門的需求分析師：

1、每次變動都很痛苦，設計變了之後，我就要跟著改UC，改截圖，有時候UED改了還忘了通知我們，導致UC有問題……

2、頁面交互的需求容易漏掉，因為UC裡面不可能寫太多交互方面的東西。

3、希望UED能夠在提交HTML DEMO給RA時，能同時給出一份頁面元素描述文檔，需要介紹html demo中的文案、鏈接以及相關的圖片尺寸或顯示字符個數。現在RA在這方面花費的時間比較多，經常要和UED去確認這些內容。

產品經理：

前期RA和PD溝通過程中，有很多交互點點不能夠明確，比如「默認顯示多少屬性值」，「標題顯示多少字符」等。在以往的需求和項目中，對待這些問題我們都是想到一點補一點的到FRD文檔或者郵件中去。既增加了溝通成本又會存在遺漏細節的風險。PD為了可控性的需求，往往會「越俎代庖」，直接在FRD 註明這種需求(對於交互設計師來講，卻又導致沒有發揮餘地)

一些交互設計師，他們也存在如何清晰無遺漏將交互設計需求傳遞下去的困惑：

交互認為很平常的設計需求，如果不表達出來，還是容易被前端和開發忽略掉。我經歷的一個項目，前端從頭到尾更換了三個人，每次我都要重複去講解下設計需求，講得口乾舌燥。而且做好後，還需要去驗收。

DRD做為參考手冊，一定程度上避免不吻合的問題發生。

即使有問題發生，也可以作為界面驗收時的Checklist。將「我對A說，我對B說，A對B說」，轉變為「A和B共同參考同一份文檔」，減少溝通成本及信息不對稱。

全程影響用戶體驗(一直到測試，都需要參照設計文檔)。

可是以下問題都可以通過一份DRD來解決嗎?

　　三、 寫什麼不寫什麼?

　　要明確文檔的定位，從寫什麼與不寫什麼開始，劃清DRD以及FRD的邊界。

1. 不寫視覺規範規格標註

這些說明與功能實現沒有太大關係，主要是為前端做HTML的時候參考的。一般視覺設計師會在PSD裡標註清楚。如圖：

　　2. 不寫功能實現邏輯。

如下圖所示，作為DRD，你有必要傳達清楚Browse by category區域的設計：鏈接的可點擊性，鏈接的指向，字符與條目的數量限制等，但是具體二級類目排列是按產品數目排還是按字母排，還是人工運營，是FRD要解決的任務。

　　那麼文檔寫什麼呢?

　　舉例子說明下：

1. 字符限制

提高空間利用率，有時網頁上的動態文字需要從數據庫裡提取部分然後截斷處理。比如下圖中的標題和描述。你的DRD需要傳達清楚：1，是否要做限制?2，如果做限制的話，多少字出現截斷?截斷後是顯示為省略號還是不顯示?這個漢語設計相對簡單，如果英文單詞的話，因為是按字符，每個字符的寬度不一致，需要預估，另外還需要註明是整詞截斷還是詞間截斷。

　　2. 鏈接具體化

很多網站都有對搜索結果的篩選設計(refine search)，比如aliexpress搜索結果頁左側。這塊區域的交互事件是非常複雜的。

類目和屬性的不同如何處理

屬性以及每條屬性顯示的屬性值的條目是否有顯示上的限制?

選中後，被選中的屬性值是停留在原地，方便用戶記憶，還是放到統一的位置，方便用戶統一查看?其他未被選中的屬性值是否消失?

　　要確保這些你設想中的複雜的交互邏輯能夠被理解被呈現，除了一頁頁的線框圖，你有必要再三讓前端工程師和開發工程師瞭解並達成認知一致。所以你需要將頁面上的關鍵鏈接事件標識清楚。它們有的指向無需刷新頁面的交互，有的指向你安排的並非PD安排的某個中間頁面(page flow是交互設計師的職責)

　　3. 交互細節說明

相信我，我很不願意寫這些東西。我喜歡在會議室向各位涉眾演示我的線框圖，我會研究用axure製作各種動態效果，達到它足夠逼真呈現各種聯動—— 比如當你選擇了下拉菜單中的某項時，頁面上其他區域也發生相應的變化。可是，Axure不是全能的。即使能夠表達出來，線框圖交付出去，也不能確保其他人都能夠一一進行點擊嘗試。所以只能在會議室反覆講解，在事後再三檢查並敦促修改。

但是當我嘗試用下圖對這塊小小且複雜的區域進行詳細說明後，事情變得簡單多了。所以我用節省的時間去寫了這份PPT.

　　又如，你可以在這裡說明任何你想要的效果。你的受眾也只需要用10分鐘時間閱讀完畢，標註出與他工作相關的重點，存檔並在遇到問題，找不到你人時隨時參考。

　　4. 表單的校驗

這也是一項不怎麼有創意的事情，但是你若不事先想清楚，在項目過程中有點麻煩。寫文檔看似枯燥乏味，反過來想也是讓你自己再好好思量審核設計本身的關鍵步驟。我曾經自以為完善的交互設計方案就是在寫DRD的時候發現存在重大的紕漏，然後及時優化的。

　　5. 瀏覽器的兼容性要求

你們的產品兼容所有瀏覽器簡直是夢想，但是有時出於效率的要求，我們必須戰略性放棄某些瀏覽器，比如IE6.：D 。 這個決定誰來做?是前端工程師還是產品經理?還是你——交互設計師?我認為決定權在交互設計師這裡，但是他必須和產品經理達成一致，並與前端確認。你要求兼容的瀏覽器越多，標準越高，前端的工作量就會越大，測試的工作量甚至也會翻倍。

　　四、 什麼時間交付呢?

Heidi的建議：儘可能與你的線框圖同時交付，如果你先交付出線框圖，在撰寫DRD的時候，極大可能會發現問題或產生優化的想法。但是往往寫DRD至少需要1-2天的時間，你不可能讓所有下游等著你的工作。所以：

你可以交付出線框圖供視覺先開始。視覺設計往往會先做風格定位設計，這和交互細節關係不大。

先交付出已經確定的線框圖給前端，然後在1-2天DRD後，若有改動，與前端當面一一確認並一起交付。

五、如何寫DRD?

1. 選擇最有效率的工具。

我的經驗是這個工具最好能夠提供清晰的目錄導航結構，而且易標註。word確實是個寫文檔的好工具，不管你信不信，反正我是信了。

　　2. 建立固定的目錄結構

下圖僅供參考。

　　具體裡面的細節，就不一一囉嗦了。

六、重要的原則

準備寫DRD的朋友，請認識清楚此文檔真正要解決的問題是什麼?如果是解決溝通偏差、需求遺漏、溝通成本高的問題，你在項目裡沒有出現過這種問題，各合作方也反饋良好，那麼這個文檔就無需寫。如果是解決對設計需求進行存檔，便於後續人員改版時查看的問題，則又是另外一回事(經驗證明，過去的DRD確實能夠在改版時起到一定的幫助，在我離開原項目很久後，新的設計師還找我要過相應項目的文檔，瞭解過去的設計邏輯)。

不是為了寫文檔而寫文檔(而是為瞭解決問題)

適合於項目、合作方(大項目有大文檔，小需求有靈巧的解決方案)

工具不是問題(易傳播，易標註，成目錄即可)

模版不是問題，大家看明白就可

完美的文檔無法取代面對面的溝通(評審會和討論不會因為文檔而減少)

需要在實踐中不斷改進

七、誰來寫?

　　我建議由交互設計師發起，但是由前端工程師進行修訂，再傳遞給開發工程師。

有很多需求，交互設計師只要求實現即可，但是他可能並不在乎是前端實現還是後端實現。前端工程師對DRD進行把關和修訂，能夠將設計語言轉化為工程師能夠看懂的語言，且能夠劃定與開發的實現邊界。

八、與其他產出物的關係

項目中交付物對應不同的使用角色，如下圖所示：

　　但是有個問題是，雖然DRD的目標受眾有開發和測試，但是讓開發工程師同時參考那麼多文檔是不現實的，所以仍然是開發工程師的接口人，也就是事實上的RA需求分析作為需求整合傳遞的角色，將商業需求和設計需求，傳達給具體的執行開發工程師與測試工程師：

　　【總結】

對於堅持撰寫DRD的我來說，DRD的好處自己當然是明白的。但是並非所有人都喜歡寫文檔，都喜歡看文檔。

解決問題有多種方案，DRD只是其中一個。不過，當你因為設計需求傳遞過程中發生了問題，或者你的需求被理解偏差，或者你的需求被遺漏，或者你接手的項目改版，因為要梳理過去的設計邏輯焦頭爛額時，你可以試試用DRD。如果使用過程中還是存在問題，那麼就想想是否還存在別的解決方案吧～

轉載請註明：SPH優秀設計分享聯盟 » UI設計教程|如何編寫界面交互設計文檔