交互設計策劃書(專業(yè)16篇)

字號:

    通過閱讀,可以更好地理解和欣賞文學作品。在總結時,我們要注重分析問題的根本原因。這些范文是通過對各類總結的梳理和歸納整理而來,希望能夠對你的寫作有所幫助。
    交互設計策劃書篇一
    如果在每個80后的心中有份深藏的記憶,43款經典的任天堂紅白機帶給我們的是永遠的感動,童年是癡迷于超級馬里奧(mario)、俄羅斯方塊、冒險島、沙羅曼蛇、綠色兵團單純的歲月……那樣的故事情節(jié)那樣的畫面甚至每個關卡給我們帶來的驚喜,在我們不懂用戶體驗不懂交互的童年時代,卻跟隨著宮本茂和他的馬里奧快速走進了一切以用戶為中心的科技時代。
    談到用戶體驗談到交互設計上有創(chuàng)舉的公司,我們首先想到的無論是蘋果還是亞馬遜,微軟、facebook……甚至迪斯尼這樣的公司也可能會榜上有名,這些公司不僅僅是因為它們能讓用戶彼此交互,更重要的是通過全新的溝通工具嘗試了新的對話方式。例如iphone在人機交互設計方面帶給用戶的是“信息就在指尖”,蘋果公司帶給我們的驚喜耳熟能詳,從八十年代macintosh計算機,定義了至今無人能夠超越的圖形用戶界面(gui)到創(chuàng)新性的ipod系列音樂播放器和itunes在線音樂商店引發(fā)的數字音樂革命,任天堂則是被遺忘的角落。事實上,被稱作馬里奧之父任天堂的傳奇設計師宮本茂,在交互設計領域做出了不可磨滅的貢獻,我們今天很多習以為常的產品設計都是從任天堂開始的,并最終成為了行業(yè)慣例。
    做有劇情的游戲。
    八十年代初期的pc游戲大多停留在一味追求高分的階段,沒有故事情節(jié),只有多彩的畫面,早期的游戲多處在非常低下的硬件水平,所有的游戲用戶之間拼的就是高分,這很大一部分限制了游戲的發(fā)展,沒有文化底蘊,題材單一,同時也導致了用戶粘度低,容易視覺疲勞,不能夠可持續(xù)的update,同時很大一部分也限制在自己的領域里,無法拓展一些周邊的產業(yè),比如漫畫,電視劇,玩偶,人文傳說都不能很好的結合并且發(fā)展,也限制了游戲本身的發(fā)展。
    是否還記得小霸王學習機里的這款經典游戲:瑪麗醫(yī)生()。
    這是一款在fc平臺上發(fā)行的電視游戲,是在俄羅斯方塊的基礎上,增加了一些想象力,使之變?yōu)橐豢钚掠螒?,游戲的目的只有一個:丟擲相應顏色的藥片消滅蟲子。初玩這個游戲的時候覺得很新奇,但隨著關卡的深入,蟲子的增多,單一的投擲而越顯的游戲的乏味。這也反映了那個年代游戲產業(yè)的一個通病。
    另一個例子是80年namco的一款《pac-man》(國內稱“吃豆人”)。
    80年代是游戲行業(yè)的一個重要轉折點,任天堂游戲也因為宮本茂的加入和當時一部非常有影響力的電影《金剛》發(fā)生了質的改變。宮本茂在電影《金剛》中得到啟發(fā),認為游戲也可以是有情節(jié)的,有情節(jié)的游戲才能增加趣味性,提高用戶的粘度。1981年任天堂著名的《大金剛》(donkeykong)誕生,宮本茂設計的是一個英雄救美女的故事,這也是街機歷史上最為成功的游戲之一。
    而此后,英雄救美的情節(jié),也以多種多樣的形式在任天堂之后的各種游戲系列中頻繁出現。比如:
    《影子傳說》(legendofkage)故事一開始,公主kiri就被邪惡忍者綁架,這時,主角影從一片樹林后跳了出來,前去營救公主。這是一部極具電影感的游戲。
    包括后面會提到的《塞爾達傳說》(thelegendofzelda),
    永遠的《塞爾達傳說》。
    宮本茂說,市面上不一定只能有那種需要按圖索驥,讓人耗神費心的游戲。我們希望可以看到新型態(tài)的游戲用不同的面貌和消費者見面。我們不該只想著利用新科技做為未來發(fā)展游戲的籌碼,真正該做的工作是開發(fā)可以吸引到更多民眾的游戲。好比任天堂就是一個讓五歲到九十五歲的民眾都著迷的好例子。
    盡管《大金剛》第一次給游戲加入了故事情節(jié),但是在表現形式上,它和當時那些以獲得高分為唯一目的的游戲依然沒有太大的區(qū)別?!洞蠼饎偂返目涨俺晒κ谷翁焯煤蛯m本茂意識到,未來的游戲,應當擁有更豐滿的劇情,講述更加引人入勝的故事?!度麪栠_傳說》沿用了英雄救美的故事情節(jié),這款游戲融合了動作、冒險、解謎、角色扮演,還包含了少量的平臺跳躍,潛入,競速等等的元素,并融入了三個偉大的交互創(chuàng)舉。
    1.飽滿的故事情節(jié)。
    《塞爾達傳說》系列不存在“經驗”和“升級”這個概念,在這款系列游戲中讓用戶告別了之前不停地刷高分上排行榜為目的的老套中,他呈現在用戶面前的是一個個飽滿的故事情節(jié),這使得用戶在游戲中感受趣味性和和新的交互體驗。
    2.保存進度,讀取存檔。
    在之前的游戲設計中,并沒有設計保存進度這一功能,以至于用戶為了刷高分,通宵達旦的沉浸在游戲中,一旦中斷,必須重新來過。《塞爾達傳說》的一偉大交互創(chuàng)舉是能夠在使用電池的主記憶體中儲存游戲進度,這也是用戶一直期盼和渴求的。記得小的時候游戲玩到正high的時候被媽媽叫去睡覺,每次都會很生氣的說,這個死掉就去睡,好不容易玩到這關。任天堂這一歷史性的創(chuàng)新,讓用戶眼前一亮,也讓游戲開發(fā)商們可以大膽放心無限制的去設計游戲情節(jié),而不必再擔心游戲的漫長用戶無法一次性玩完。此外,最初的設計中存檔就是直接保存在游戲卡里而不綁定主機的,因此用戶們可以方便地把自己的游戲進度隨身攜帶,不管身處何方,只要掏出游戲卡插上任意一臺主機就能繼續(xù)玩下去。寫到這里的時候,突然很想對任天堂道一聲感謝,他傾聽到了用戶的心聲,知道他們最需要的東西是什么,并針對這一方向無限制的創(chuàng)新。
    3.actionroleplayinggame(arpg)動作角色扮演類游戲。
    從游戲發(fā)展來看,最初是先有rpg(role-playinggame),arpg是從rpg發(fā)展出來的分支?!度麪栠_傳說》開創(chuàng)了允許用戶自定義角色的姓名,這樣用戶可以切身的把自己帶入到游戲情節(jié)中,倘若我們把rpg的三大特性定為:故事性、藝術性、交互性,那么arpg恰恰是在交互性上取得了巨大的創(chuàng)新。在這方面,arpg吸收了動作游戲的特長,將激烈的打斗場面融入其中,使得節(jié)奏大大加快,更容易也更直接地調動了用戶的參與欲望。
    總之,《塞爾達傳說》是游戲界的里程碑,arpg的鼻祖,包括之后發(fā)布的《塞爾達傳說-時之笛》首先引入了三維游戲lockon系統,完美解決了以往三維游戲的視角問題,lockon系統在現在幾乎任何一款三維游戲身上都能看到。因此,這可謂是三維游戲進步的一次大革命。在《塞爾達傳說》身上數不清的創(chuàng)意,這么一款游戲性極高的游戲是其他游戲所無法相比的。
    結束語。
    從游戲劇情到讀取存檔,以及后來的十字方向鍵到體感控制,任天堂在游戲行業(yè)的用戶體驗和交互設計領域長期扮演著開拓者的角色。他關注全年齡段的休閑娛樂,把用戶鎖定在5-99歲的人群,無論是白領女性還是老年用戶,都是任天堂希望的用戶群體,也因為這樣的游戲用戶定位創(chuàng)造了wii和nds的銷售奇跡。任天堂不斷嘗試新的游戲交互設計,并且用最低的成本來呈現,把交互方式融合到游戲體驗中。最后感謝任天堂陪我們度過了難忘的童年時光。
    交互設計策劃書篇二
    2.快速理解和評估需求,從設計和體驗的角度給出自己的反饋意見;。
    3.根據產品定位和目標人群,結合用戶研究與數據分析,輸出最合理的交互解決方案;。
    4.推動設計方案落地,跟進并處理落地過程中出現的問題;。
    5.進行數據分析和可用性測試,評估產品上線后的效果,總結經驗或提出改進計劃;。
    6.優(yōu)化組內設計規(guī)范,推動規(guī)范在團隊中的執(zhí)行。
    1.本科及以上學歷,工業(yè)設計、人機交互、心理學、視覺傳達、計算機等相關專業(yè)背景;。
    4.熟練運用sketch、axure、思維導圖等軟件;。
    5.有較強的溝通能力,能清楚的闡述設計過程,表達自己的設計理念;。
    6.有主觀能動性、邏輯嚴謹、樂于接受新鮮事物,對細節(jié)和品質有追求,具備一定的創(chuàng)新能力。
    交互設計策劃書篇三
    上周去北京,用非正式的面試方式和幾位大公司的產品設計師聊了聊,我基本都問到了兩個問題:
    1、分享一個你的實際具體產品設計的過程。
    很失望。第二個問題普遍沒得到答案。設計師們普遍在做完設計之后都不知道“老板為什么要做這個”,或者認為“老板給了一個錯誤的指令”。
    半個月前,在集團的“總裁夜談”上,david給大家分享了他給jack提的一個意見:您去了一趟呼叫部門,說了句“我們的問題應該30%在線上解決”,搞的大家都沖著30%胡亂忙乎了一年…我倒覺得這個案例中的主要問題可能并非是jack的。而是,在執(zhí)行這個“30%”之前,有沒有深入了解“30%背后的目的是什么?”。假設jack的目標是“提高線上服務能力,讓基礎的可以線上解決的問題都能在線上解決”,那么即使在達到這個目標后,線上解決的問題之有10%,我相信jack也不會不滿意。
    如果你只知道老板需要把注冊用戶提升上去,而不知道提升注冊用戶的目的是什么,那么我不相信你的設計能夠做到多么合理。也許那只是為了設計而設計,為了kpi而kpi。
    在北京的書友會上,我分享了支付寶的產品設計師在做設計之前,必須要做的工作:寫一份“設計概要”(可后期迭代),包括:
    1、你理解到的:為什么要做這個產品設計,出發(fā)點和目的是什么。重點的體驗目標是什么。
    2、這個產品要滿足用戶的什么/哪些需求,用什么/哪些功能設計來滿足。先滿足什么需求,再滿足什么需求。
    3、在解決需求的眾多功能中,設計重點有哪些。重要性的先后順序是什么。
    4、這個產品在系統中和其他產品的關聯點有哪些,需要其他產品什么樣的配合。
    5、該產品中需要做好哪些數據統計點,這些數據可以說明什么。
    6、設計時間表和計劃。
    實際上我們在執(zhí)行過程中,也有很多設計師認為沒什么必要,直接動手做就行,干嘛想這么多,還寫出來太耽誤時間了。
    但,這個“設計概要”其實就是設計的構思,是設計之前的“規(guī)劃”。這些事情不做,設計很容易局限于細節(jié),甚至在思路的源頭上直接走偏。只有設計師和規(guī)劃師/老板在“為什么做這個設計”上達成了一致,設計師才有可能充分的徹底發(fā)揮自己在每個點的設計能力,讓設計結果超出規(guī)劃師/老板的期望;如果設計師和規(guī)劃師/老板在“為什么做這個設計”上出現偏差,設計結果的偏移往往在所難免,設計師也會感覺自己的工作總是受到“干涉”。而且,當不合理的設計做出來之后,回頭都來不及,即使回頭,也會帶來很多的負面問題和情緒。
    我一直最關注的是設計師在產品設計過程中的思路,認為暫時的結果好壞并不重要,要重要的是你思考的過程是否合理。但現在我又發(fā)現,最基礎的做一個設計之前先清楚為什么要做這個設計,竟然都普遍沒有答案。這是一種可怕的現象。
    設計者應該學會問“為什么?”。搞清楚“為什么設計這個?”,也許比完成一個自己想象中的完美設計,更重要。
    本文來自:/blog/?p=835。
    交互設計策劃書篇四
    3、協助進行產品易用性和功能性分析,進行用戶研究,優(yōu)化用戶體驗;。
    5、與開發(fā)人員共同完成產品的最終實現,并負責產品的持續(xù)優(yōu)化;。
    6、為gui設計師提供交互設計指導,良好的表達溝通能力和團隊協作精神。
    1、設計類、計算機、軟件工程或相關專業(yè)本科以上;。
    5、主動積極、認真負責、能團隊合作、并能獨立作業(yè);。
    7、面試時可帶過去的uiflow應用相關成品與資料。
    交互設計策劃書篇五
    我們有時候不能不面對產品出錯的時候。無論設計得多么用心,無論做了多少測試,用戶仍然會遇到錯誤和問題。既然出錯不可避免,那么如何進行容錯性設計才是關鍵。
    容錯性設計就是當錯誤發(fā)生時,人們看到的界面。
    就像對付不該發(fā)生的錯誤一樣,容錯性設計的關鍵在于“做好防御”。產品設計者們必須不斷尋找可能造成用戶困惑和不滿的出錯點。好的防御性設計決定用戶體驗的好壞。
    舉個例子:
    有沒有人注意過進入銀行atm機可以有多少種刷卡方式。答案是八種!而正確進入方式只有一種方式。
    如何從設計上避免用戶出錯,限制是一種非常必要的方式。
    限制用戶某些交互操作。
    sim卡如果做成一個倒角避免了長方形帶來多種插入方式的錯誤。
    三項插座和相應插孔的匹配避免了用戶使用兩項或其他插座錯誤的可能。
    置灰是界面上限制某些操作的好方式。
    一方面告訴用戶這可以進行當前操作,另一方面預示后面還有哪樣的操作。
    其次,減少認知困惑也很重要。
    減少用戶認知混淆。
    根據已訂閱和未訂閱的不同,訂閱button和退訂進行視覺上明顯的區(qū)分,避免錯誤操作。
    合理利用系統反饋。
    如果錯誤不可避免的發(fā)生了,合理恰當的提示可以減少用戶的挫敗感。
    1、提前提示某些操作可能引起錯誤。
    在輸入密碼需要區(qū)分大小寫時,capslock鍵打開下作出提示以免出錯。
    2、防止用戶錯誤,操作后提示確認。
    在用戶點擊發(fā)送后提示沒有輸入主題信息,防止用戶直接發(fā)送無主題郵件。
    3、不僅要反饋出錯,更要給用戶解答。
    最好能夠告訴我,具體錯誤的原因在哪里,是那句話和字出現的問題。
    4、給予用戶適當指引和建議。
    當用戶搜人沒有結果的時候,引導用戶繼續(xù)查找或者邀請好友。
    當用戶搜索無結果時,智能猜測用戶的出錯原因或者給予其他引導。
    人非圣賢,孰能無過。用戶是產品的上帝,如何通過設計減少用戶的出錯后的挫敗感。錯誤永遠是產品的,寬容用戶的錯誤,不容忍產品的錯誤。
    感謝seven文檔的啟發(fā)。
    交互設計策劃書篇六
    下面這些原則是由android用戶體驗團隊創(chuàng)建并用以指導他們設計,來讓使用者始終保持興趣,您可以在您的創(chuàng)意和設計理念中來考慮這些原則。如果沒有特定原因,建議您在構思創(chuàng)意和設計理念中考慮這些原則。
    吸引我。
    用令人驚奇的方式取悅我。
    一個漂亮的界面、精心設置的動畫,或者定時的聲音效果都是令人愉悅的體驗。這些都有助于讓用戶感受到操作過程是簡單而毫不費力的。
    真實的物體往往比按鈕和菜單更有意思。
    允許人們直接觸摸和操作您的app中的對象。它減少了人們認知的成本,并且讓人們獲得了更多情感滿足。
    讓我擁有。
    人們會喜歡添加一些個性化的風格,因為有助于他們感到賓至如歸和控制感。提供有意義的、漂亮的默認值,并且也可以考慮提供好玩的、可選的自定義,但不要干擾主任務。
    了解我。
    隨著時間來學習人們的偏好。與其一遍又一遍的詢問用戶來做出相同的選擇,倒不如讓用戶更簡單的使用上次的選擇。
    讓我的生活更簡單。
    保持簡單。
    使用簡單的詞匯和短語。如果一個句子很長,人們通常會跳過。
    圖片或文本更快傳遞信息。
    考慮用圖片來表達創(chuàng)意。它們會獲得用戶的注意,并且能比文本更有效。
    為我判斷,但讓我有最終發(fā)言權。
    盡量猜測和行動,而不是總詢問。太多的選項和判斷會讓用戶不爽。假使你搞錯了,允許“撤銷”。
    只顯示我需要的。
    如果人們一次看到太多東西,會不堪重負,
    把任務和信息拆分成易消化小塊內容。隱藏當前不必要的選項,并且告訴他們如何繼續(xù)。
    我應該總是知道我在哪兒。
    給人信心,讓他們知道自己所在。讓你的app的不同位置區(qū)分明顯,使用過渡動畫來詮釋不同界面的關系。對于正在進行的任務過程提供及時的反饋。
    別弄丟我的東西。
    保存用戶花時間創(chuàng)建的內容,并且允許人們在任何時候訪問。記住人們在不同手機、平板和電腦間的設置、個人風格和創(chuàng)造。這會使得升級是一件極其容易的事情。
    如果他們長得一樣,那么操作應該也是一樣。
    通過顯著的視覺差異,來幫助人們辨別他們功能上的差異。避免使用看起來相似但操作卻不同的模式切換。
    如非重要,別打斷我。
    就像一個好的個人助理,幫助人們屏蔽不重要的技術細節(jié)。人們需要集中注意力,除非遇上嚴重的或者時間敏感的問題,打斷會使得用戶沮喪。
    讓我驚嘆。
    給我到處都可以使用的技巧。
    當人們自己解決問題的時候,他們會感覺更棒。利用人們在其他app中的視覺風格和肢體記憶,讓用戶學習您的app更容易。比如,輕掃手勢會是導航的快捷方式。
    不是我的錯。
    溫柔的促使人們改正他們的錯誤。他們在使用的時候希望覺得自己是聰明。如果出錯了,給他們恢復的指引,但是別給予太多的技術細節(jié)。如果您可以在后臺修復問題會更好。
    給予鼓勵。
    把復雜任務拆分成較小的步驟,來讓它更容易完成。在用戶操作的時候給予反饋,即使是一個微弱的發(fā)光。
    幫我完成繁重的部分。
    幫助新手用戶做他們以為做不了的事情,讓他們感覺自己像專家一樣。比如,通過結合多種照片效果的快捷操作,只須幾步就可以將業(yè)余的照片打造出驚人的效果。
    讓重要的事情完成的更快。
    不是所有的操作都是平等的。決定你的app中哪些是最重要的,然后讓他們更容易發(fā)現和更快的使用,就像拍照界面上的快門鍵或音樂播放器上的暫停鍵。
    交互設計策劃書篇七
    3、運用合理的設計方法,評估產品上線后的.效果,并提出用戶體驗改善計劃;。
    1、本科及以上學歷,工業(yè)設計、心理學、計算機等相關專業(yè);。
    2、工作經驗:3年以上交互工作經驗,有app產品案例更佳;。
    4、能對產出負責,最好有一定的團隊管理能力(優(yōu)先考慮);。
    交互設計策劃書篇八
    最近,總是在想思考自己的目標,ux(ue)的發(fā)展,卻總聽到有人提到概念設計,給用戶傳遞情感,讓用戶愛上自己的品牌。我不盡汗顏,在一個團隊里,如果設計流程和質量還無法保證高效、順暢、一致,純屬空談。換句話說,活才勉勉強強做完。開會的時候,不是想如何提高質量、效率。而是空談什么概念設計、傳遞情感,就只能說說而已。
    在我的記憶里,我總是聽到那些提概念設計、傳遞情感的人,言必提蘋果公司。確實蘋果公司設計上的成功有目共睹。但是不知道,那些空談概念設計和傳遞情感的人有沒有讀過蘋果公司10多年前寫得。
    文檔里說明了小到一個icon該怎么設計設計的時候應該注意什么。沒有在團隊里確立一個相對統一的標準。團隊里的設計師一個人一個風格就連一個按鈕的樣式和文案都沒統一也沒有專門的設計文檔說明和記錄設計思路天天靠開會來溝通上線了也沒有人持續(xù)根據上線后的數據(就看上線后一周)。還空談什么概念設計、傳遞情感……笑談吧。
    本文來自:/。
    交互設計策劃書篇九
    產品設計中,對于一些大的業(yè)務流程,通過頭腦風暴、需求評審,都會比較清晰,而對于業(yè)務的底層邏輯、子流程的設計就只有靠產品設計的嗅覺了。于是我們經常聽到人們這樣說:這個產品體驗很不好、很難用之類的話。
    衡量一個產品成功與否的一個重要標準,叫體驗,也稱用戶體驗。目前的產品設計,誰都喜歡拿幾句用戶體驗來說辭,各有一套見解,都具有很強烈的主觀色彩,比如三次點擊原則、簡約而不簡潔、一致性,業(yè)內比較出名的一篇文章把用戶體驗歸納為品牌、可用性、功能、內容。
    本文并不注重于歸納用戶體驗標準,而是試著從另外一個角度來理解用戶體驗。那就是通過任務流進行產品設計。
    所謂任務流,就是用戶在訪問網站的目標、引導、步驟,通常跟任務分析、導航設計、信息架構、心智模型一起進行。
    (1)鏈接打開方式。
    對于鏈接是在新窗口打開或者新窗口打開,一直是個爭論的話題。通常來說,國外站點主張在當前窗口打開頁面,這符合國外用戶的操作方式,比如卓越網。而國內站點大部分是在新窗口打開頁面,這比較符合國內用戶的操作習慣以及商業(yè)目地,如淘寶。另一方面的衡量標準就是網站類型,如資訊站、購物站、游戲站點等的處理方式又不一樣了。
    而如果用任務流的角度來看,也可解釋這一現象。產品設計之初的用戶調研,會定義好用戶模型,這個時候我們通常會知道我們網站的主要用戶、次要用戶、輔助用戶的用戶特征和行為,我們知道他們訪問站點的目標是什么,并以此設計好任務流。比如,用戶進入資訊欄目—分類列表頁—具體資訊頁面;用戶進入商品頻道-選擇某一推薦商品—商品詳細頁瀏覽—購買支付—跳到網銀支付頁面。這個時候我們就很好辦了,在商品列表頁,在瀏覽為前提下,用戶通常會打開前面1-2頁的資訊,所以設計成新窗口打開。購物時,選擇某商品支付,購買時就要在當前窗口打開。
    2)彈出窗口、提示框、嵌入層。
    萬惡的彈出窗口:
    受windows操作系統影響,前幾年的產品設計中,大多都喜歡用彈出對話框。而彈出窗是最不友好的體驗,赤裸裸的警告和威脅,而且會打斷用戶當前的任務流,試想一下,當我們不得不挪動鼠標去點擊按鈕后,我們當前焦點已經丟失。
    善用輸入提示:
    淘寶的注冊會員,輸入錯誤的選項后,會在當前輸入框后面出現錯誤提示,并且有輸入輸入說明,告訴你如何才是正確的。
    巧用提示框:
    網易博客的日志顯示設置,在彈出窗口中實現操作。
    靈活運用嵌入層:
    在進行某些大的調整時,涉及比較多選項時,往往我們會在新窗口進行,設置好選項后再返回原頁面。在這樣的流程中,同樣會造成用戶流失。
    利用嵌入層,可以減少用戶流失。下圖是雅虎的左側菜單編輯。
    (2)信息架構。
    信息架構對一個網站也是很重要的,大到導航設計、商品分類、小到頁面內的欄目設計都是信息架構的范疇,目前也逐漸涌現出一篇信息架構的人才。
    目標導向設計:以用戶為模型,進行任務設計(簡單做個圖示供參考)。
    向導式引導:
    對于一些步驟比較多的任務,可以采用向導引導,step1-step2,描述當前所處位置,給用戶明顯的預期,還有幾個步驟。
    (3)結合心智模型。
    用戶在使用某個產品后,會在心底產生了一個印記,下次再接觸到類似的產品后,他會用相同的標準來衡量。如果某一個產品,用到了很多創(chuàng)新,會給用戶帶來挫敗和無法掌控的感覺。所以,國內的同類產品,大抵上產品功能是類似的。比如:上一步、下一步、注冊會員、購物車、確定、取消等名稱定義?;蛘弋a品功能:對于大部分電子商務網站,在選擇商品購物后,進入支付頁面,選擇支付方式(網銀和支付寶、財付通等),而想回收站,windiwos采用垃圾桶圖標,于是大部分網站的刪除按鈕都做成一個小垃圾桶圖標,于是用戶看了就懂了。
    (4)巧用任務流程,降低門檻。
    先瀏覽后注冊:
    之前很多網站都只對注冊會員開放權限,于是用戶在網絡上搜索到,但卻無沒法瀏覽。而注冊步驟通常要輸入一大堆資料,于是很多用戶跑掉了。如今很多網站的產品設計都改成先瀏覽、試用后注冊的模式,在誘餌(瀏覽、試用)等前提下,吸引了用戶參與。
    登錄內置:
    很多網站的流程是這樣設計的,在進行某項操作時,提示要登錄,于是頁面跳到登錄頁面,輸入賬號密碼(如果沒有注冊過要跳到注冊流程)后登錄成功(登錄成功跳轉到某某頁,并不一定會跳轉回原頁面),就這樣,好好的一個潛在用戶或者一筆交易就沒了。下圖應該很容易看懂吧,在當前頁面彈出登錄框,輸入賬號密碼后登錄成功,并且收藏成功。
    本文來自:/post/。
    交互設計策劃書篇十
    軟件界面是人—機之間的信息界面,交互是一個結合計算機科學、美學、心理學、人機工程學等工業(yè)和商業(yè)領域的行為,其目標是促進設計,執(zhí)行和優(yōu)化信息與通信系統以滿足用戶的需要,由于現今交互越來越多地考慮人的因素,因而行為和構造就成為用戶界面開發(fā)過程的兩個重要的部分,即交互設計和界面設計,這都關系到用戶和界面開發(fā)人員。
    在交互過程中,交互設計關系到用戶界面的外觀與行為,它不完全受軟件的約束。界面設計師以及決定如何與用戶進行交互的工程師應該在這一領域深入研究。在界面開發(fā)過程中,他們必須貼近用戶,或者與用戶一道來討論并得出結果,所以他們的工作是較為辛苦但是最具有意義的。
    另一方面,界面與軟件代碼的生成,代碼本身的意義以及功能的實現是緊密聯系的。因此編譯代碼的人同樣也應該在這方面做深入的研究。過去,編碼人員只是單獨地進行軟件研發(fā),而缺少必要的美學知識和界面專門技術來處理交互的問題。不幸的是,最終的結果往往不是用戶所期望的。對于用戶而言,最好的交互方式讓程序員去實現往往是最難的,由此矛盾出現了,這使得很多專家或者工程師膚淺地應付一些交互方面的問題。以至于在軟件開發(fā)完成之后,這些專家和工程師驚訝地發(fā)現,用戶對他們所實現的特征感到一片茫然,不知所措,通常選用另外一種方式進行交互。
    要進行界面開發(fā)設計,用戶分析是第一步??偹苤?,進行任務和用戶分析,以及相關調研的必要性和重要性。用戶是計算機資源,軟件界面信息的使用者,由于目前計算機系統以及相關的信息技術應用范圍很廣,其用戶范圍也遍及各個領域。我們必須了解各類用戶的習性,技能、知識和經驗,以便預測不同類別的用戶對界面有什么不同的需要與反應,為交互系統的分析設計提供依據和參考,使設計出的交互系統更適合于各類用戶的使用。由于用戶具有知識、視聽能力、智能、記憶能力、可學習性、動機、受訓練程度、以及易遺忘、易出錯等特性,使得對用戶的分類、分析和設計變得更加復雜化。另外,為了設計友好而又人性化的界面,也必須考慮各類不同類型用戶的人文因素。
    基于上述諸多因素的影響和我們設計師自身的特點,在界面設計和開發(fā)中我們可以遵循一些的科學而合理設計原則和設計步驟,任何時候都不忘學習,并不斷總結,積累經驗,歸結工作庫。
    以下我們可以借鑒人機交互中的一些原則和步驟。
    1.一致性原則。
    2.提供信息反饋。
    交互系統的反饋是指用戶從計算機一方得到信息,表示計算機對用戶的動作所做。
    的反應。如果系統沒有反饋,用戶就無法判斷他的操作是否為計算機所接受,是否正確,以及操作的效果是什么.反饋信息的呈現方式可以是多種多樣的,如文本、圖形和聲音等。
    3.合理利用空間,保持界面的簡潔。
    在界面的空間使用上,應當形成一種簡潔明了的布局。界面設計最重要的就是遵循美學上的原則——簡潔與明了。
    那么再來看看步驟:
    (1)用戶調研,擬定需求,初步建立界面原型。
    (3)環(huán)境分析確定系統的硬、軟件支持環(huán)境及接口,向用戶提供各類文檔要求等;
    (5)確定界面根據用戶的自身特性.以及系統任務、環(huán)境、成本/效益,確定量為適合的界面類型:
    (10)綜合測試與訐估這個階段的關鍵任務是通過各類型的測試與評估,使系統達到預定的要求.它可以采取多種方法,如試驗法、用戶反饋、專家分析、軟件測試等,對軟件界面的諸多因素如功能性、可靠性、效率、美觀性等進行訐估,以獲取用戶對界面的滿意度,便于盡早發(fā)現錯誤或者不滿意的地方,以改進和完善系統設計。
    (11)維護階段維護階段的關鍵任務是:通過各類必要的維護活動,使系統持久地滿足用戶的需要。
    總而言之,我們真正將設計師、用戶和所要開發(fā)的系統這三者之間的關系認識清楚,研究透徹了,再與編碼人員通力協作,不斷的努力把相關細則實施到我們工作的各個環(huán)節(jié)中去,那么我想我們的交互和界面設計也就可以讓用戶滿意了。
    交互設計策劃書篇十一
    之前有談過交互設計師與用戶體驗設計師的一些工作內容的感想,或許很多公司來說還沒有真正自己的用戶體驗設計師,很多中心型公司只有一個角色來做兩份的工作,但是與產品經理(簡稱pd)的合作我想大部分公司的設計師們都有些心得,很多時候似乎感覺pd總是和我們對立。很多交互設計師都會和產品經理進行輪番的pk,有pk需求,也有pk資源等等。
    其實交互設計師距離產品很近,很多時候交互設計師的工作很類似于產品經理。來列舉一下產品經理的職責:
    1.市場調研:。
    市場調研主要的目的是了解客戶的需求點,來分析目前此類產品的競爭對手,分析市場的潛力。個人覺得其中的了解客戶需求為重點,很多時候可以從中發(fā)現很多創(chuàng)新或改進現有產品的想法。在其中用戶研究員(用戶體驗設計師)觀察用戶的一些行為習慣。產生市場分析報告。
    2.產品設計:。
    描述產品的定位等內容(包括:產品遠景、目標市場、功能描述、產品用例等等),一般公司都會寫成一個文檔:產品需求文檔(prd)。很多的需求和功能點都會在這個文檔中反應出來。在prd形成的時候還有另外一個產出物也會出來,那就是demo。uidemo包括了產品的界面,交互包括體驗方面的設計部分。
    3.項目管理:。
    其實主要是確認資源的投入,撰寫項目計劃,跟蹤項目的進度等等。
    4.產品宣傳:。
    很多人認為宣傳是運營部門的事情,pd只需要把產品做出來后扔給運營部門去負責,這樣對于產品的發(fā)展是惡性的。其實在產品調研中就應該去考慮后期的產品宣傳問題,賣點,如何利用媒體等等的。而且要去考慮收集后期的產品數據,不斷的改進產品。
    5.產品生命周期:。
    很多pd不會去考慮產品周期的問題,所以很多時候產品出來了,就淪落到沒人去負責它的發(fā)展,不知道該走向何方?;蛟Spd只考慮到一點而沒考慮到產品線的發(fā)展,所以很多產品的當初就是畸形的。
    其實可以看出來以上的pd的職責,也是我們很多交互設計師去考慮了的東西,包括出產品需求設計的方案,分析用戶行為。細節(jié)的demo設計等等,都是交互設計師在負責。所以交互設計師與產品的距離是很近的。在我們公司很多的產品項目都是交互設計師來擔任,而且交互設計師很容易變成了產品經理。因為兩者只是關注不一樣,一個關注商業(yè),一個關注用戶。但是往往關注了用戶,那么商業(yè)的價值才會獲得更多。
    交互設計策劃書篇十二
    產品經理到底是一個怎樣職位呢?他的主要職責是什么?一個剛入行的產品經理,甚至一個資深產品經理或多或少對該職位都會有某種迷惑,資深產品經理、在線投資管理公司covestor的首席產品官martineriksson發(fā)表了一篇文章《what,exactly,isaproductmanager?》,其中給出了自己對產品經理這個職位的理解。譯文如下:
    我經常會追問產品經理到底是一個什么職位,他們的職責是什么?該如何培養(yǎng)產品經理呢?
    martycagan的著作《inspired》(中文名《啟示錄》)中曾如此描述“產品經理”這個職位:去發(fā)現有價值、可用且合理的產品。同樣,我認為產品經理是商務、技術和用戶體驗三個崗位的交集。一個好的產品經理必須至少具有其中之一的從業(yè)經歷、對三種崗位都有熱情,同時還要與三種職業(yè)的從業(yè)者有很好的交情。
    業(yè)務:產品經理首先是一個業(yè)務崗位,他的主要職責是把產品的商業(yè)價值發(fā)揮到最大。產品經理應全心專注于產品優(yōu)化,從而達到商業(yè)目標,并獲得最大的投資回報。
    技術:如果連產品經理都不知道一個產品該如何構建,那定義該產品就毫無意義了。這并不是要求產品經理會寫代碼,但懂技術,最重要的是清楚努力方向對于做出正確的決定是至關重要的。這一點在敏捷開發(fā)中更加重要,因為產品經理是和開發(fā)團隊一起時間最多的人。
    用戶體驗:這是最后一項但同樣是重要的。產品經理在公司里代表用戶的聲音,他必須關注產品的用戶體驗。這就要求產品經理跳出團隊,以一個用戶的身份來測試產品,與用戶交談,從中獲得第一手反饋資料——尤其是創(chuàng)業(yè)公司的產品經理。
    產品經理的職責到底是什么?
    首先要為產品設定一個目標,這就需要你對市場、客戶及他們存在的你正試圖解決的問題進行反復的研究。你必須能夠消化掉巨大容量的信息——來自客戶的反饋、網站分析所產生的量化數據、研究報告、市場趨勢以及統計數據——你必須了解產品市場和客戶的所有信息,用創(chuàng)新的思維去整合所有信息,以幫助定義所要研發(fā)的產品。
    產品定義一經確定,你要迅速在團隊中宣傳。如果商務團隊和開發(fā)團隊對該產品沒有任何熱情,這就說明你對產品的定義并不成功,因為你以及產品的成功取決于團隊的每個成員對該定義的理解,至少要對此有些激情。
    然后,你就要啟動項目了。你首先要制定一個可行的計劃。逐漸完善的線路圖及迭代的開發(fā)方式可以幫你逐步完成最終的產品目標。這時,你的團隊也會全身心的投入到更好的設計、更好的編碼、為客戶提供更好的解決方案等工作當中。
    在接下來日日與開發(fā)團隊工作的日子里,作為產品的所有者我們要仔細面對。不斷對產品進行定義與迭代;問題一出現立即解決;更緊密地管理各項事務,以保證能及時完成該產品。
    然后按照同樣的過程重新設計新的產品。這并不是一個瀑布式的開發(fā)過程——你不是在一步一步的做產品,而是一次性為多款產品、產品的諸多特性做了準備,在一瞬間把策略轉化成了戰(zhàn)術。
    聽起來很艱辛?
    ucd團隊:
    將本文的word文檔下載到電腦,方便收藏和打印。
    交互設計策劃書篇十三
    很多關于設計的觀念都不是孤立的理論,廣義來看,我們周圍的一切事物都是設計的載體,而norman的《設計心理學》的英文原名正是thedesignofeverydaything,在他緊接《設計心理學》之后的著述《情感化設計/emothinaldesign》中又提出了另外設計的階層概念,本能的、行為的和反思的。這三個名詞是中文版中的翻譯,十分晦澀并且也與原著中的語義有所差異。
    這并非一個全新的設計理念,在norman提出這個理念之前,廣告界早已洞悉情感在營銷中的重要作用。優(yōu)秀的產品設計和成功的廣告是相似的,都試圖將自身與使用者或客戶的某種情感聯系起來,通過這種方式使用者或客戶對于產品形成了獨特的理解和聯想,以至于形成目標的滿意度和忠誠度。
    norman在文中提出了很有趣的問題,當我們看到美麗的產品,但卻會因為糟糕的使用體驗而感到沮喪,而有時我們又會因為一個產品的獨特而忽略它難以操作?是什么使得我們喜歡或者厭惡一個產品?情感又是如何作用于我們對于一個產品的感受?norman有話說,但在閱讀的時候我也慢慢提煉了自己的觀點。
    首先在于norman用人腦對信息的加工方式來定義與之對應的形成設計的三種水平,本能的、行為的和反思的,我并不完全認同。對于設計而言,外觀設計只是設計過程的一小部分,并不能作為設計的水平的分界線,且本能的設計也不能和行為的以及反思的設計成為階梯序列。設計的復雜之處在于它不僅僅是為了滿足大腦本能的信息處理,而是經驗式的。從設計的階段來解讀的話,我更接受用功能的、易用的和情感的來描述設計的不同層次和水平。
    任何設計的目的都是為了解決問題,而解決問題是設計的最基本的要求,
    如果不滿足使用者對于一個產品的定義和要求,那么這個產品要么是失敗的,要么是超越的。以norman在文章開始舉例中的那個“不可能的茶壺”,盡管它很難用,但normal卻非常喜愛,因為它“講述了一個極好的故事”。但這個例子是否也恰好說明了norman對于產品設計概念定義的瑕疵?因為如norman所說,雖然那些茶壺基本上不用,但仍然喜歡,因為它們是“雕塑藝術品”。everydaything和藝術品的最大區(qū)別就在于藝術是無關用途的,他們或許具有意義,但卻從不考慮用途。也就是說,如果一個我們每天使用的產品無論如何的招人喜愛,但如果它不能用,那它也是失敗的。
    這本書的意義不在于人腦的加工模式如何影響使用者對于產品的感受,而在于將情感的價值引入設計領域,設計不僅僅是要賣的產品,設計本身也是營銷。
    “特別的物品結果是那些具有特別回憶或者聯想的物品,那些幫助擁有者喚起特別情感的物品。特別的東西都能喚起往事?!?BR>    這是一個很重要的概念,“特別的”是滿足情感需求的。盡管同樣的旅游紀念品能夠帶給不同的人以不同的回憶和感受,但從更大的范圍來看,能夠使得一款產品對每一個人都能具有不同的感受的話,只能依賴定制和個性化。這或許闡釋了設計的未來方向,設計的作用將不僅僅是滿足能用、好用,還要能在用的時候形成獨有的體驗。用一款ipod滿足一個大群體的時代將慢慢成為歷史,定制和個性化所形成的無限細分市場也將在未來改變設計的格局。
    本文來自://06/。
    交互設計策劃書篇十四
    凡客的這個例子中,搜索建議“時尚斜拉鏈”高亮顯示,這個時候點擊“搜索”,提交的關鍵字是輸入框中的“s”還是“時尚斜拉鏈”呢?答案是“時尚斜拉鏈”。
    再看看百度,當搜索建議中的“sina微博”高亮(鼠標懸停)時,點擊“百度一下”,提交的關鍵字是輸入框中的“s”,而不是高亮的“sina微博”。
    到底哪種方式更好一些呢?我個人是這么認為的:
    就搜索組件來說,主體應該是搜索框和搜索按鈕,搜索建議只是一個附加的工具,甚至可以沒有。
    因此不管搜索建議狀態(tài)如何,“搜索”按鈕(或按“enter”鍵)提交的應該是搜索框中的內容,這樣才不容易產生歧義。
    問題二:是否要高亮顯示第一條搜索建議?
    看了很多相關產品,比如google、淘寶、百度、凡客等,它們的搜索都沒有高亮顯示第一條搜索建議。
    但是也還有少數產品的搜索,是默認選中第一條搜索建議的。這樣會有什么問題呢?
    如果提交的是搜索建議,那按照前面說的方法,把輸入框中的內容替換成第一條搜索建議是行不通的,畢竟這個不是用戶自己選的,那么這個歧義就很難解決了;另外,倘若用戶再手動選擇其他的搜索建議,搜索框中的內容也不適合再被替換成相應的搜索建議了,因為這樣就會和初始狀態(tài)不一致(初始狀態(tài)下搜索框中的內容和默認選中的搜索建議很可能是不一致的)。
    如果提交的不是搜索建議,那么這里高亮顯示它又有多大的意義呢?
    總結:
    若觸發(fā)搜索操作后提交的是高亮的搜索建議,則搜索框中的內容應該被替換成相應的內容。
    在搜索建議中不要高亮顯示第一條內容。
    交互設計策劃書篇十五
    這讓我想起來自己在項目里也大力推行過交互說明文檔(在下文中,簡稱為drd),格式倒沒什么限制,交互設計師自己寫到界面上也行,單獨文檔成文也行,總之就是讓交互設計師能夠將界面承載不了的信息通過文檔沉淀下來,降低項目里的溝通成本和風險。今天整理電腦,翻出以前的ppt,分享之。
    這將涉及到幾個問題:
    一.什么是交互說明文檔(drd)?
    所謂drd即是用來承載交互說明,并交付給前端、測試以及開發(fā)工程師參考的文檔。
    在項目中,交互設計師的主要產出物可能依次是:sitemap,pageflow,wireframes。有的大型項目前期,交互設計師有可能還會產出用戶需求分析文檔(與pd產出的市場需求文檔不一樣的是,urd更多側重于對目標用戶的需求分析)。
    drd則很少有人專門撰寫。如果需要對交互設計進行說明,聰明的交互設計師往往會直接標注在線框圖里,或者在項目中不斷和前端工程師和開發(fā)工程師口口相傳,反復驗收,不斷迭代修改來確保所有的交互設計意圖最終得以呈現。
    二.為什么要寫?
    drd非項目必需環(huán)節(jié),一般情況下也不會為交互設計師專門留出相應的時間預估。沒有這份文檔,項目也會繼續(xù),但是可能項目會為此承擔不必要的溝通成本和時間成本。嚴重的話,項目的質量也會受到影響。所以寫與不寫,交互設計師需要做把握,時間被統一包含在“線框圖”環(huán)節(jié)內——如果你要寫,請在評估時預留1-2天的時間。
    那么,結合我過去的經歷,談一下此文檔的必要性。
    下圖是一個產品開發(fā)項目基本的流程。
    敏捷開發(fā)意味著很多不同角色的流程需要并行操作。如果等到產品經理的frd已經全部敲定,交互設計師再開始去畫線框圖,固然會減少溝通成本和返工風險,但是同時意味著交互設計師的很多想法不被采納。如果產品經理再強一些,他甚至會在frd里連原始的demo也一并繪制出來了,功能性的需求和界面交互的需求有時無法區(qū)分太清楚——比如他會在frd里直接要求每頁條目40條,超過40條即分頁。而交互設計師可能會認為像蘑菇街那樣不斷裝載出足夠長的頁面會更親和……所以,我們希望是和產品經理同時開始工作,在術業(yè)有專攻的時候相互補充。
    同樣,開發(fā)工程師也希望及早介入需求,在frd并未確認的時候就了解需求,進而將商業(yè)需求和功能需求轉化為開發(fā)工程師看得明白的開發(fā)需求清單(這個清單,大部分叫做uc,即usecase),當這份清單由工程師需求分析師——在過去,這個角色被叫簡稱為ra,但是目前已經取消此專門的職位,而是由開發(fā)工程師代表擔綱此環(huán)節(jié)工作,為了便于描述,在此文里,我仍然將做這件事情的人稱為ra——交付給具體的執(zhí)行工程師后,執(zhí)行工程師基本上可以當作一條條的checklist開始高效工作,而不必再思考商業(yè)邏輯和需求。同樣,測試工程師也需要編寫具體的文檔去指導很多測試人員在開發(fā)后高效測試,這也是基于uc和frd去撰寫的。
    所以,開發(fā)需求分析是個很重要的環(huán)節(jié)。那ra是如何來完成需求分析工作的呢?
    前期介入,對pd進行開發(fā)需求評估支持;
    參與每次的frd評審會;
    詳細審閱frd文檔并不斷與pd確認。
    對于做這件事情的人來說,足夠詳盡的frd是非常重要的。所以一份frd雖然是pd產出,但是很多實施細節(jié)則是由開發(fā)工程師不斷溝通評估并確認下來的。而設計需求的傳遞,卻存在很多問題。除了線框圖,沒有“詳盡的說明性的文檔”告訴他們。比如:
    一方面,交互設計師對產品經理說:這塊由我們來考慮,你的文檔不必包含設計上的說明,這隨時會調整的。
    另一方面,線框圖的評審有時會讓ra參與,有時卻沒有叫他們。即使叫上了他們,他們也會發(fā)現交互設計的需求變化要比frd變化快。另外,他們會認為uc不必寫太多關于交互設計的需求。
    在某個大型項目結束后,作為交互設計師,我進行了一些調研,聽聽這相關人員是怎么表述問題的:
    開發(fā)部門的需求分析師:
    頁面交互的需求容易漏掉,因為uc里面不可能寫太多交互方面的東西。
    希望ued能夠在提交htmldemo給ra時,能同時給出一份頁面元素描述文檔,需要介紹htmldemo中的文案、鏈接以及相關的圖片尺寸或顯示字符個數?,F在ra在這方面花費的時間比較多,經常要和ued去確認這些內容。
    產品經理:
    前期ra和pd溝通過程中,有很多交互點點不能夠明確,比如“默認顯示多少屬性值”,“標題顯示多少字符”等。在以往的需求和項目中,對待這些問題我們都是想到一點補一點的到frd文檔或者郵件中去。既增加了溝通成本又會存在遺漏細節(jié)的風險。pd為了可控性的需求,往往會“越俎代庖”,直接在frd注明這種需求(對于交互設計師來講,卻又導致沒有發(fā)揮余地)。
    走訪了一些交互設計師后,他們也存在如何清晰無遺漏將交互設計需求傳遞下去的困惑:
    交互認為很平常的設計需求,如果不表達出來,還是容易被前端和開發(fā)忽略掉。我經歷的一個項目,前端從頭到尾更換了三個人,每次我都要重復去講解下設計需求,講得口干舌燥。而且做好后,還需要去驗收。
    drd做為參考手冊,一定程度上避免不吻合的問題發(fā)生。
    即使有問題發(fā)生,也可以作為界面驗收時的checklist。將“我對a說,我對b說,a對b說”,轉變?yōu)椤癮和b共同參考同一份文檔”,減少溝通成本及信息不對稱。
    全程影響用戶體驗(一直到測試,都需要參照設計文檔)。
    可是以下問題都可以通過一份drd來解決嗎?
    三.寫什么不寫什么?
    要明確文檔的定位,從寫什么與不寫什么開始,劃清drd以及frd的邊界。
    1.不寫視覺規(guī)范規(guī)格標注。
    這些說明與功能實現沒有太大關系,主要是為前端做html的時候參考的。一般視覺設計師會在psd里標注清楚。如圖:
    2.不寫功能實現邏輯。
    電腦資料。
    那么文檔寫什么呢?
    舉例子說明下:
    1.字符限制。
    提高空間利用率,有時網頁上的動態(tài)文字需要從數據庫里提取部分然后截斷處理。比如下圖中的標題和描述。你的drd需要傳達清楚:1,是否要做限制?2,如果做限制的話,多少字出現截斷?截斷后是顯示為省略號還是不顯示?這個漢語設計相對簡單,如果英文單詞的話,因為是按字符,每個字符的寬度不一致,需要預估,另外還需要注明是整詞截斷還是詞間截斷。
    2.鏈接具體化。
    很多網站都有對搜索結果的篩選設計(refinesearch),比如aliexpress搜索結果頁左側。這塊區(qū)域的交互事件是非常復雜的。
    類目和屬性的不同如何處理。
    屬性以及每條屬性顯示的屬性值的條目是否有顯示上的限制?
    要確保這些你設想中的復雜的交互邏輯能夠被理解被呈現,除了一頁頁的線框圖,你有必要再三讓前端工程師和開發(fā)工程師了解并達成認知一致。所以你需要將頁面上的關鍵鏈接事件標識清楚。它們有的指向無需刷新頁面的交互,有的指向你安排的并非pd安排的某個中間頁面(pageflow是交互設計師的職責)。
    3.交互細節(jié)說明。
    相信我,我很不愿意寫這些東西。我喜歡在會議室向各位涉眾演示我的線框圖,我會研究用axure制作各種動態(tài)效果,達到它足夠逼真呈現各種聯動——比如當你選擇了下拉菜單中的某項時,頁面上其他區(qū)域也發(fā)生相應的變化??墒牵琣xure不是全能的。即使能夠表達出來,線框圖交付出去,也不能確保其他人都能夠一一進行點擊嘗試。所以只能在會議室反復講解,在事后再三檢查并敦促修改。
    但是當我嘗試用下圖對這塊小小且復雜的區(qū)域進行詳細說明后,事情變得簡單多了。所以我用節(jié)省的時間去寫了這份ppt.
    又如,你可以在這里說明任何你想要的效果。你的受眾也只需要用10分鐘時間閱讀完畢,標注出與他工作相關的重點,存檔并在遇到問題,找不到你人時隨時參考。
    5.表單的校驗。
    這也是一項不怎么有創(chuàng)意的事情,但是你若不事先想清楚,在項目過程中有點麻煩。寫文檔看似枯燥乏味,反過來想也是讓你自己再好好思量審核設計本身的關鍵步驟。我曾經自以為完善的交互設計方案就是在寫drd的時候發(fā)現存在重大的紕漏,然后及時優(yōu)化的。
    6.瀏覽器的兼容性要求。
    你們的產品兼容所有瀏覽器簡直是夢想,但是有時出于效率的要求,我們必須戰(zhàn)略性放棄某些瀏覽器,比如ie6.:d。這個決定誰來做?是前端工程師還是產品經理?還是你——交互設計師?我認為決定權在交互設計師這里,但是他必須和產品經理達成一致,并與前端確認。你要求兼容的瀏覽器越多,標準越高,前端的工作量就會越大,測試的工作量甚至也會翻倍。
    四.什么時間交付呢?
    heidi的建議:盡可能與你的線框圖同時交付,如果你先交付出線框圖,在撰寫drd的時候,極大可能會發(fā)現問題或產生優(yōu)化的想法。但是往往寫drd至少需要1-2天的時間,你不可能讓所有下游等著你的工作。所以:
    你可以交付出線框圖供視覺先開始。視覺設計往往會先做風格定位設計,這和交互細節(jié)關系不大。
    先交付出已經確定的線框圖給前端,然后在1-2天drd后,若有改動,與前端當面一一確認并一起交付。
    五.如何寫drd?
    1.選擇最有效率的工具。
    我的經驗是這個工具最好能夠提供清晰的目錄導航結構,而且易標注。word確實是個寫文檔的好工具,不管你信不信,反正我是信了。
    2.建立固定的目錄結構。
    下圖僅供參考。
    具體里面的細節(jié),就不一一羅嗦了。
    六.重要的原則。
    準備寫drd的朋友,請認識清楚此文檔真正要解決的問題是什么?如果是解決溝通偏差、需求遺漏、溝通成本高的問題,你在項目里沒有出現過這種問題,各合作方也反饋良好,那么這個文檔就無需寫。如果是解決對設計需求進行存檔,便于后續(xù)人員改版時查看的問題,則又是另外一回事(經驗證明,過去的drd確實能夠在改版時起到一定的幫助,在我離開原項目很久后,新的設計師還找我要過相應項目的文檔,了解過去的設計邏輯)。
    不是為了寫文檔而寫文檔(而是為了解決問題)。
    適合于項目、合作方(大項目有大文檔,小需求有靈巧的解決方案)。
    工具不是問題(易傳播,易標注,成目錄即可)。
    模版不是問題,大家看明白就可。
    完美的文檔無法取代面對面的溝通(評審會和討論不會因為文檔而減少)。
    需要在實踐中不斷改進。
    七.誰來寫?
    我建議由交互設計師發(fā)起,但是由前端工程師進行修訂,再傳遞給開發(fā)工程師。
    有很多需求,交互設計師只要求實現即可,但是他可能并不在乎是前端實現還是后端實現。前端工程師對drd進行把關和修訂,能夠將設計語言轉化為工程師能夠看懂的語言,且能夠劃定與開發(fā)的實現邊界。
    八.與其他產出物的關系。
    項目中交付物對應不同的使用角色,如下圖所示:
    但是有個問題是,雖然drd的目標受眾有開發(fā)和測試,但是讓開發(fā)工程師同時參考那么多文檔是不現實的,所以仍然是開發(fā)工程師的接口人,也就是事實上的ra需求分析作為需求整合傳遞的角色,將商業(yè)需求和設計需求,傳達給具體的執(zhí)行開發(fā)工程師與測試工程師:
    交互設計策劃書篇十六
    交互設計的創(chuàng)新,大家想一想,可不可以理解為:超出常理,玩出新招,新出表現。交互的創(chuàng)新,也一直是眾多產品設計者研究的課題,大家都有不同的理念和思路,所以時不時都會看到一款新產品的亮點,或產品的升級版本淋漓盡致的展現出智慧火花。
    有一點我想說的是,交互設計的創(chuàng)新,是為了什么?脫離于產品基本功能、一切違背可行性可用性的創(chuàng)新都是荒謬的,沒有理論支持的創(chuàng)新,在實際生活中是不可行的。舉個例子:為了實現某種效果一個頁面居然要多加載50多k甚至更多的js,我看來都是不可行的。做web的都知道,速度和效果是雙刃劍。
    1)技術驅動交互創(chuàng)新。
    當原來的瓶頸通過技術升級換代,變得切實可行的時候,自然而然帶來的交互創(chuàng)新。最早的時候,對提示的方式還停留在alert,現在很多都可以通過js庫出更多的效果,ajax的運用讓原來很生硬的提示,變得更人性化、及時化,頁面無刷新,避免了不該的跳轉等等。
    2)場景化設計創(chuàng)新。
    作為一個更可行,應用方式更靈活、更定制的創(chuàng)新模式,場景化交互設計是一個很重要的創(chuàng)新途徑。所謂人人都是用戶體驗專家。我看到很多產品都在這個方面做了很多的嘗試和改進,1、場景化設計更切近用戶、使用者;2)更具體、更形象化、更生動,把一推機械的線框文字說明都拋掉了。如:im的白天場景、夜晚場景或者主題活動的場景設計。
    場景化設計,最后一定要實現:吸引、被喜歡、明白、易操作、易記住、易傳播(或許是口碑傳播)等人性化功能,在整個交互設計過程中,涉及到的視覺、色系、色彩配比等相關知識我忽略不講,還望大家參考其它資料。
    本文來自:/?p=437。