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