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