【正文】 據(jù)2）中外企業(yè)在數(shù)據(jù)保存問題上是否有很大差異？%的外企員工認(rèn)為部門內(nèi)很注重數(shù)據(jù)的積累保存，相比中國企業(yè)只有60%的員工認(rèn)為部門內(nèi)很注重數(shù)據(jù)的積累保存，%的中國企業(yè)員工認(rèn)為部門不注重數(shù)據(jù)積累。這說明，做項目時，在用戶招募的速度和質(zhì)量方面，外國企業(yè)會勝過中國企業(yè)。第二，對比用戶體驗行內(nèi)人員和其他部門人員就同一問題的評價。這與調(diào)查開始制定的因素框架是基本相符合的，如圖 22所示：圖 22五因素數(shù)據(jù)積累資源管理部門協(xié)作理論發(fā)展執(zhí)行水準(zhǔn) 影響部門水準(zhǔn)的六個因素 數(shù)據(jù)對比分析本文從以下兩個方面進行了數(shù)據(jù)對比分析。第六類描述了人力資源和項目管理對項目質(zhì)量的影響。觀察第四類，發(fā)現(xiàn)它包含的題項都是在描述用戶體驗工作人員如何執(zhí)行項目以及如何與其他部門的人打交道。第六類Q23項目執(zhí)行人的水準(zhǔn)對項目影響很大。Q19我們只儲存那些長期調(diào)查的、重要的用戶信息。第五類Q15大家經(jīng)常把外國出的新理論套用在實際項目上。Q11有些產(chǎn)品經(jīng)理和程序員不是很認(rèn)可我們部門的工作。Q7我們有時招募用戶會忽略先前制定的比例。第三類Q3有時候客戶會找好幾家公司同時幫他們做同一個項目的用戶研究。將修改過后的問卷正式發(fā)放，回收72份有效數(shù)據(jù)。聚類分析是根據(jù)研究對象的相關(guān)程度，把相關(guān)程度比較強的對象歸為一類[1]。第一套是發(fā)給用戶體驗行業(yè)工作人員的，第二套是發(fā)給程序員、美工、產(chǎn)品經(jīng)理的。第2章 數(shù)據(jù)分析與結(jié)果本章通過對調(diào)查數(shù)據(jù)的聚類分析和對比分析，得出兩個結(jié)論。Q25部門內(nèi)部有一套固定的工作流程。Q21平時報告中的結(jié)論分析占篇幅一半左右。Q17部門內(nèi)有一個詳盡龐大的用戶信息庫。Q13上級或者客戶不懂用戶體驗，但是喜歡亂提要求，我們常覺得很為難。Q9時常能聽到部門內(nèi)員工對客戶或其他部門人員的抱怨。Q6在調(diào)查之前我們可能已經(jīng)想好了結(jié)果。 驗證正式問卷內(nèi)部一致性正式問卷共發(fā)放86份，回收有效數(shù)據(jù)72份。Q13我在為用戶爭取利益的時候總需要對其他部門進行很多解釋。Q29我認(rèn)為現(xiàn)階段應(yīng)該先提高研究質(zhì)量，而不是先考慮效率。Q24我們很少做定量數(shù)據(jù)分析。Q20我們只儲存那些長期調(diào)查的、重要的用戶信息。保留表 16 刪減問題的原因序號問題處理原因Q12從事用戶研究和可用性測試的人不必和程序員有交涉。保留Q30項目執(zhí)行人的水準(zhǔn)對項目影響很大。保留Q26平時報告中的結(jié)論分析占篇幅一半左右。保留Q22我主持訪談和挖掘用戶需求的能力很棒。增加第四類Q29我認(rèn)為現(xiàn)階段應(yīng)該先提高研究質(zhì)量，而不是先考慮效率。保留Q10UI設(shè)計師覺得他們的設(shè)計方案實際并不取決于用戶研究的結(jié)果。保留Q25我們有力的證據(jù)支持是：用戶說…而不是數(shù)據(jù)統(tǒng)計分析。添加第二類Q2部門內(nèi)很少組織進行用戶研究和可用性測試的理論方法研究。保留Q18我做用戶調(diào)查時，很多時候在套用市場調(diào)查的辦法。 cluster功能，選用華生法（ward’s method），聚類樹狀圖如所示：圖 11 聚類樹狀圖通過計算Cronbach α系數(shù)刪減問題的結(jié)果如表 15所示，刪減或轉(zhuǎn)移問題的原因如表 16所示：表 15 內(nèi)部一致性檢驗過程類和α值序號問題處理之后α值第一類Q1公司做可用性測試時，基本一直使用“有效、效率、滿意度”這三條測試標(biāo)準(zhǔn)。再逐條刪減問題，發(fā)現(xiàn)假若刪減一道問題，Cronbach α系數(shù)升高，則應(yīng)從類里剔除這個問題。 信度分析信度（reliability）是指使用相同研究技術(shù)重復(fù)測量同一個對象時得到相同研究結(jié)果的可能性[10]。本文就從這兩個方面來分析調(diào)查的分析效度。我們有力的證據(jù)支持是：用戶說…原問題實際問了兩個問題。上級或者客戶不懂用戶體驗，但是喜歡亂提要求，我們常覺得很為難。訪談提綱和問卷問題的品質(zhì)很高。我認(rèn)為很難避免這種主觀傾向的干擾。從事用戶研究和可用性測試的人不必和程序員有交涉。原問題實際問了兩個問題。部門內(nèi)很少組織可用性的理論方法研究。2）被調(diào)查人是不是覺得問卷問題晦澀難懂？在試調(diào)查之后，可以詢問被調(diào)查人的感想，比如，是否不理解題項的意思？題目是否太長？有沒有歧義？有沒有不好回答的題項？通過試調(diào)查，對以下題目做出了語言上的修改，如表 14所示：表 14 問題問法修改前后對比修改前修改后修改原因公司做可用性測試中，基本一直使用“有效、效率、滿意度”這三條測試標(biāo)準(zhǔn)。第一，在問卷前加上說明。例如，在試調(diào)查中，當(dāng)問到“可用性測試是否在用ISO924111的三條標(biāo)準(zhǔn)”時，有人選擇了十分不同意。 交流效度交流效度（Communication validity），是指你在調(diào)查過程中與被調(diào)查人之間的溝通程度[1]。和其他部門的配合是默契的。有時項目做壞是因為執(zhí)行的人的水準(zhǔn)問題。數(shù)據(jù)積累很有限。以前做過的同類項目的數(shù)據(jù)，在另外一個項目中，我會查詢翻看。報告撰寫部門內(nèi)有標(biāo)準(zhǔn)統(tǒng)一的模版。很少做定量分析。我應(yīng)付訪談和測試主持人沒問題。只有對長期調(diào)查我們才建立用戶庫。有時我覺得自己在做市場調(diào)查而不是用戶需求調(diào)查。做成項目就好，至于什么流程不重要。部門內(nèi)有項目管理混亂。我不知道程序員開發(fā)軟件時需要我提供什么東西。刪去。有時候客戶會找好幾家公司同時幫他們做同一個項目的用戶研究，每份調(diào)查報告都只作為參考。報告里的數(shù)據(jù)實際上有水分。在做用戶研究時，有時靠感覺，缺乏論據(jù)和數(shù)據(jù)支持。內(nèi)心認(rèn)為做出的東西沒有表面上看起來那么有用。刪去。公司做可用性測試時，基本一直使用“有效、效率、滿意度”這三條測試標(biāo)準(zhǔn)。工作流程部門內(nèi)有自己的一套工作流程。他們外行人根本不懂用戶體驗。執(zhí)行效率提高做項目的效率是我的迫切要求。文檔保存雜亂。招募用戶部門內(nèi)沒有詳細(xì)的用戶庫。問卷調(diào)查結(jié)果部門內(nèi)有標(biāo)準(zhǔn)統(tǒng)一的模版。部門或公司內(nèi)部很少進行行業(yè)內(nèi)的理論研究。內(nèi)容效度（Content validity）關(guān)心的是，是否一個因素的內(nèi)容都在測量中呈現(xiàn)出來[10]。請專家驗證因素框架中的問題是不是當(dāng)前企業(yè)在設(shè)計調(diào)查和可用性測試過程中切實存在的。1）全面性。第二，調(diào)查是否全面，它反映全面情況的程度[1]。他們所在的企業(yè)，正是本軟件未來可能推廣的對象。了解軟件概念、功能、開發(fā)過程和現(xiàn)階段功能缺陷。調(diào)查專家級用戶可以深入了解他們在設(shè)計調(diào)查中的工作流程和存在問題。3）第三章建立了用戶模型，描述了設(shè)計調(diào)查過程中哪些環(huán)節(jié)需要數(shù)據(jù)積累。針對以上問題，本文提出一款應(yīng)用軟件概念，目的是幫助企業(yè)用戶體驗部門建立一個有關(guān)用戶調(diào)查和可用性研究資料的規(guī)范化數(shù)據(jù)庫，實現(xiàn)訪談數(shù)據(jù)、問卷數(shù)據(jù)、用戶模型數(shù)據(jù)、可用性測試數(shù)據(jù)的量化、規(guī)范化、標(biāo)準(zhǔn)化，從而提高工作人員的工作效率和質(zhì)量。UX Office用它自身設(shè)計的一套工作流程來規(guī)范和幫助用戶體驗工作人員進行項目管理和可用性測試。本論文作者于2007年底在《產(chǎn)品設(shè)計Ⅲ》課程設(shè)計中獨立提出同樣的產(chǎn)品新觀念，本畢業(yè)設(shè)計項目是按照本文作者的獨立思考進行的，其中有些設(shè)計思想超過了Helmut Degen，并沒有從他處借用任何概念和設(shè)計思想。西安交通大學(xué)本科生畢業(yè)設(shè)計（論文）數(shù)據(jù)的規(guī)范化儲存概念軟件的畢業(yè)設(shè)計目 錄前 言 1 課題來源與背景介紹 1 課題來源 1 UX Office軟件簡介 1 課題針對問題 1 主要工作內(nèi)容 2第1章 調(diào)查的結(jié)構(gòu)框架 3 專家訪談 3 效度分析 3 結(jié)構(gòu)效度 3 內(nèi)容效度 4 交流效度 7 分析效度 8 信度分析 8 通過試調(diào)查信度分析來修改問卷 9 驗證正式問卷內(nèi)部一致性 12第2章 數(shù)據(jù)分析與結(jié)果 15 樣本比例 15 聚類分析 16 數(shù)據(jù)對比分析 18 中國企業(yè)與外國企業(yè)的用戶體驗部門對比 19 行內(nèi)人員與行外人員看法對比 22 分析結(jié)果與討論 24第3章 用戶模型 25第4章 軟件功能架構(gòu)設(shè)計 27 原理 27 軟件模塊 27 各模塊包含的數(shù)據(jù)參量 28 基本功能 30 數(shù)據(jù)查看 30 數(shù)據(jù)轉(zhuǎn)化 31 數(shù)據(jù)導(dǎo)入和導(dǎo)出 33 數(shù)據(jù)計算 36 篩選 37 搜索 37 數(shù)據(jù)展示模式 37 查看模式 37 編輯模式 37第5章 結(jié) 論 39致 謝 40參考文獻 41附 錄 42附錄一：調(diào)查問卷 42附表二：UX Office測試記錄表格 44附表三：專家訪談提綱 46附表四：四個企業(yè)用戶體驗部門的資料收集 49附錄五：英文文獻翻譯 53英文原文 53翻譯譯文 63附錄六：實習(xí)鑒定 70II前 言 課題來源與背景介紹 課題來源本文作者從2008年3月1日到5月26日在北京伊颯爾界面設(shè)計有限公司實習(xí)，畢業(yè)設(shè)計項目來自用戶體驗解決方案部門的UX Office軟件項目。該軟件尚未發(fā)布。UX Office，用戶體驗辦公室，實際上只是可用性測試的軟件平臺。這增加了員工重復(fù)性的手工勞動，也導(dǎo)致部門內(nèi)缺乏規(guī)范化的數(shù)據(jù)資料積累，不利于部門水準(zhǔn)的提高和新員工的培訓(xùn)。2）第一章和第二章通過用戶調(diào)查，得出影響企業(yè)設(shè)計過程的五個因素，并對比了國內(nèi)外企業(yè)在這五個因素方面的差距。 專家訪談專家訪談的目的是為了建立全面真實的調(diào)查框架結(jié)構(gòu)。1）產(chǎn)品經(jīng)理：是北京伊颯爾公司的用戶體驗解決方案部門經(jīng)理，從2006年開始負(fù)責(zé)進行探索性開發(fā)UX Office項目，歷時兩年。2）用戶研究員：在企業(yè)（騰訊、百度、西門子、聯(lián)想）有3年以上做用戶研究、可用性測試項目的經(jīng)驗。第一，調(diào)查是否真實，它的真實程度。本文在設(shè)計因素框架時從以下兩個方面考慮了結(jié)構(gòu)效度。2）真實性。本文最終確立的因素框架如表 11所示：表 11 因素框架一級因素二級因素因素說明理論發(fā)展理論依據(jù)采用的理論依據(jù)是否正確？自主研究部門內(nèi)是否進行方法和理論的自主研究？數(shù)據(jù)資料訪談提綱和問卷是否建立了問卷庫？問卷調(diào)查結(jié)果是否有統(tǒng)一格式保存？用戶模型是否會建立用戶模型？可用性測試數(shù)據(jù)是否有統(tǒng)一格式？用戶錄音錄像是否需要保存錄音錄像？招募用戶是否存在用戶庫？執(zhí)行水準(zhǔn)訪談和設(shè)計問卷的水平水平是否不均衡，項目質(zhì)量是否因人而異？執(zhí)行認(rèn)真程度是否認(rèn)真的完成工作？執(zhí)行效率是否高效的完成工作？部門協(xié)作新員工培訓(xùn)成本是否和程序員和美工很好配合？交接任務(wù)能否保證項目質(zhì)量？資源管理項目計劃與管理是否能制定合理項目計劃？工作流程是否存在統(tǒng)一的工作流程？ 內(nèi)容效度在確定結(jié)構(gòu)因素后，要把各個因素轉(zhuǎn)化為具體調(diào)查內(nèi)容和調(diào)查問題。自主研究沒有系統(tǒng)的歸納過一套可操作的理論方法用于用戶研究或可用性測試。有時我覺得自己在做市場調(diào)查而不是用戶需求調(diào)查。用戶錄音錄像我們長期保存用戶的錄音錄像。項目數(shù)據(jù)同類產(chǎn)品的研究會歸類放置。訪談水平我當(dāng)訪談和測試的主持人沒問題。與其他部門協(xié)作做項目的時候，總要跟上級部門（或客戶）反復(fù)進行交涉。資源管理項目計劃與管理部門內(nèi)有項目計劃與時刻表。問題的問法修改如表 13所示：表 13 修改前后問題對比修改前的問題修改后的問題認(rèn)為可用性測試用ISO924111標(biāo)準(zhǔn)足夠了。部門或公司內(nèi)部很少進行行業(yè)內(nèi)的理論研究。大家經(jīng)常把外國出的新理論套用在實際項目上。多用一些名詞術(shù)語能讓別人覺得我更專業(yè)。有些產(chǎn)品經(jīng)理和程序員不是很認(rèn)可我們部門的工作。調(diào)查結(jié)果其實并不可信。做項目的時候，總要跟上級部門（或客戶）反復(fù)進行交涉。上級或者客戶不懂用戶體驗，但是喜歡亂提要求，我們常覺得很為難。我在為用戶爭取利益的時候總需要對其他部門進行很多解釋。部門內(nèi)部有一套固定的工作流程。我認(rèn)為調(diào)查中設(shè)計的訪談提綱和問卷的品質(zhì)很高。部門內(nèi)有一個詳盡龐大的用戶信息庫。我們有時招募用戶會忽略先前制定的比例。對于數(shù)據(jù)分析，我們經(jīng)常做定性分析。我們有力的證據(jù)支持是：用戶說…而不是數(shù)據(jù)統(tǒng)計分析。同類產(chǎn)品的研究會歸類放置。對設(shè)計沒有指導(dǎo)意義。我認(rèn)為現(xiàn)階段應(yīng)該先提高研究質(zhì)量，而不是先考慮效率。新員工在上崗前需要經(jīng)過一周以上的培訓(xùn)。項目人員應(yīng)該從頭到尾堅持做完項目，其中換人會嚴(yán)重影響項目質(zhì)量。1）本問卷需要被調(diào)查人如實反映所在公司、部門中的實際情況，這點如果不說清楚，被調(diào)查人會誤解為表達他自己的期望或認(rèn)識。解決的辦法是這樣兩點。第二，把問卷量表中的“同意、不同意”改成“與實際情況符合、不符合”。部門內(nèi)很少組織進行用戶研究和可用性測試的理論方法研究。有時候客戶會找好幾家公司同時幫他們做同一個項目的用戶研究。原問題拗口、不通順。在調(diào)查之前我們可能已經(jīng)想好了結(jié)果。我認(rèn)為調(diào)查中我設(shè)計的訪談提綱和問卷的品質(zhì)很高。上級或者客戶不懂用戶體驗，但是喜歡亂提要求。我們有力的證據(jù)支持是：用戶說…而不是數(shù)據(jù)分析。分類效度指從調(diào)查數(shù)據(jù)進行分類的有效程度[1]。其次，對于分類效度，為了更客觀的衡量用戶體驗部門的部門協(xié)作力，還把被調(diào)查者分為了行內(nèi)人員與行外人員。在試調(diào)查和調(diào)查過程中，本文在以下幾個步驟中進行了信度分析： 通過試調(diào)查信度分析來修改問卷對于30份試調(diào)查問卷數(shù)據(jù)，先進行聚類分析，剔除掉和所有問項相關(guān)度都很低的問題，然后進行內(nèi)部一致性檢驗，用Cronbach α系數(shù)檢驗重新聚類后的各類的內(nèi)部一致性。應(yīng)該予以刪除。刪除Q16我覺得工作流程是怎樣的不重要，只要做好了項目既可。刪除Q2部門內(nèi)很少組織進行用戶研究和可用性測試的理論方法研究。保留Q21我們有時招