項目名稱：長春中醫(yī)藥大學迭代二
端口：PC端大渤；web app端
項目類型：定制化項目制妄，升級和新功能開發(fā)
我所做的工作：pc端信息梳理，產(chǎn)品流程重新梳理和設計泵三，交互細節(jié)優(yōu)化耕捞；web app 交互細節(jié)優(yōu)化衔掸。
設計師：我 & LML
此次項目工期很趕，是需要在四月就完成開發(fā)和交付俺抽。由于交互的工作需要涉及到和產(chǎn)品經(jīng)理反復溝通需求敞映、確認交互設計方案，需要同研發(fā)那邊開展原型評審磷斧，因此留給設計的時間很緊振愿。為了在短短的幾天時間內(nèi)完成交互設計的工作，我和L加班加點弛饭，整整花了一個星期的時間終于完成交互設計部分的工作冕末。
其中來回反復溝通需求的時間大概花了4天，評審花了1天侣颂，設計花了2天档桃。
確定需求在整個設計流程中真的很重要很重要很重要（重要的事情說三遍）
真正設計花的時間其實不會是最多的，只要需求溝通的夠清楚横蜒，設計目標越明確胳蛮，設計出來的東西其實越接近產(chǎn)品和用戶。
想起我做的另外一個項目丛晌，由于產(chǎn)品經(jīng)理需求不是很確定仅炊，常常在溝通確定后我設計一個解決方案，他也認可澎蛛，但是因為需求不定抚垄，產(chǎn)品經(jīng)理又愛天馬行空，完全提出一個新的需求也是常有的事谋逻，這導致來回浪費了很多時間呆馁。
在項目中碰到的幾個問題統(tǒng)一梳理一下，其中也有自己做得不夠好的地方毁兆，希望下次改進：
1.信息架構的梳理浙滤，能化繁為簡
此次項目是定制化項目，是結(jié)合數(shù)字化教學平臺已有的功能气堕，針對長春中醫(yī)藥大學的需求進行一定調(diào)整而成的產(chǎn)品纺腊。數(shù)據(jù)分析的功能是數(shù)字化教學平臺已有的功能，綜合評價是學校提出的具體需求茎芭。單單通過原型去看揖膜，會發(fā)現(xiàn)很多相近的名字出現(xiàn)在腦海，給人很混亂和難以梳理清楚的感覺梅桩。但是從信息架構圖中可以看到二者之間存在重合壹粟、包含與被包含的關系。問題一下就明了了宿百。
為了資源最大被利用趁仙，可以將二者整合到一起洪添，既能復用系統(tǒng)已有的部分功能，也能滿足學校個性化的需求幸撕。
2.當兩個設計師各自有自己的想法并且堅持己見時怎么辦薇组？
在前期需求溝通時，遇到這樣一個場景：考生報考國家級中醫(yī)藥技能考試后具有考試資格坐儿，保密員在設置考試時律胀，需要選擇考生，那么問題來了貌矿，對于一個“固定”的已報考考生名單炭菌，是系統(tǒng)自動讀取不需要用戶選擇還是用戶可以在名單的基礎上進行微調(diào)設置呢？根據(jù)產(chǎn)品經(jīng)理從學校了解到的需求逛漫，老師希望要求能對考生名單進行修改黑低，可以再次選擇哪些學生能參加考試。
有兩個聲音：
L認為不需要給用戶編輯學生名單的權限酌毡，考生名單的修改可能會導致數(shù)據(jù)容易出現(xiàn)問題克握，如果用戶有誤操作，影響會比較大枷踏，應該直接讀取考生名單菩暗；編輯功能可以給后臺管理員，由管理員對數(shù)據(jù)進行增刪改查旭蠕。
而我認為通常學校中擔任管理員角色的很可能是信息部的工作人員停团，對考生名單的修改同樣存在數(shù)據(jù)的誤操作問題；管理員提供的考生名單是具備考試資格的名單掏熬，不是實際參加考試的名單佑稠，直接在名單上做刪減，對數(shù)據(jù)的完整性有破壞旗芬；其次舌胶，考生名單從生成到用戶在調(diào)用這個數(shù)據(jù)時，中間存在空檔時間疮丛，如果管理員這邊可以修改辆琅，那么會存在用戶在不知道數(shù)據(jù)可能會有變動的情況下，完成考試的安排这刷，那管理員端數(shù)據(jù)的變化將導致用戶這邊的設置無效。
我們兩個針對這個問題進行了充分的“辯論”娩井，各自為自己的方案舉證啊暇屋，為對方的方案提出反面案例啊，總之從誤操作的可能性洞辣，誤操作后果咐刨，后果原因的追溯等等方面反復討論（旁邊產(chǎn)品經(jīng)理看著我們兩個交互設計師的不分上下的討論昙衅，一度插不上一句話...但是，請原諒設計師對細節(jié)問題的偏執(zhí)）定鸟。
后面我們對方案進行了折中而涉，給用戶編輯的功能，但是增加選擇之后的文案提示联予，讓用戶明確知道自己的操作結(jié)果啼县，減少誤操作的可能性。
通過這次對一個小問題的討論沸久，感覺更多的是收獲季眷，雖然討論的過程，感覺兩個人瀕臨吵架翻臉的邊緣卷胯，但是在這樣的一個高壓的環(huán)境下討論子刮，我們思維飛速運轉(zhuǎn)，考慮各種情況窑睁，以期能夠找到一個更貼近用戶的解決方案挺峡。不同的聲音背后的出發(fā)點是一致的，就是為設計師心中的用戶提供更好的體驗担钮。因此橱赠，有不同的聲音是好事也是常見的事，關鍵是我們最終的目的是求同存異裳朋，爭取在不同中求得一個最優(yōu)方案病线。
3.確定需求、確定流程再開始設計有多重要鲤嫡？
此次項目中送挑，存在一個優(yōu)先級很高、全新的一個功能暖眼，就是保密員安排考試惕耕。安排考試的過程很復雜，涉及到考試信息诫肠、考試時間安排司澎、考場與學生的配置、考官設置等問題栋豫。產(chǎn)品經(jīng)理提供需求是凌亂的挤安。他也根據(jù)自己的理解提供了一個考試安排的流程，簡單來說就是：考試信息設置-考場及考官設置-考生信息設置及排考-完成排考丧鸯。但依然存在很多不明確的地方：如蛤铜，上午安排考試的最大容量是不是固定的？報考人數(shù)不確定的情況下，如果安排考場和考官围肥，在數(shù)量上如何去匹配剿干？技能考試是實操考試，每輪考試實際操作中的時間很難按預期來穆刻，這中間的時間差怎么控制置尔？在需求評審會上，大家針對這些問題和漏洞進行了頭腦風暴氢伟，統(tǒng)一認識到現(xiàn)有的方案是漏洞百出的榜轿，需要大改。
由于臨時接觸到需求腐芍，對需求的了解還不夠熟悉差导。考慮到工期很趕猪勇，在對需求還存在疑問的情況下设褐，我開始了在產(chǎn)品經(jīng)理原有的方案上的修修補補，主要針對會議上暴露出來的問題最多的考試時間安排模塊集中考慮解決方案泣刹≈觯花了大半天時間針對局部問題設計出解決方案后，卻發(fā)現(xiàn)整個路程依然是模糊的椅您，流程不夠清晰的問題依然沒得到明顯解決外冀。
第二天，L看到整個流程掀泳，大驚到流程怎么如此胡亂雪隧，犀利地提出在大流程上存在著順序倒置的問題。原有的流程是先設置基本信息员舵，考試區(qū)域脑沿，再根據(jù)考試區(qū)域配置考場老師，最后才由系統(tǒng)來分配學生马僻。但是問題是：一次考試庄拇，往往學生報考人數(shù)是確定的（只要報考成功就能考試），而考場韭邓、考試時間輪次措近、監(jiān)考官數(shù)量是變動的，會根據(jù)報考人數(shù)而變動女淑。但是目前的流程卻是相反的瞭郑，這樣子混亂的流程怎么能開始設計呢？
聽了L提出的觀點鸭你，才反思到自己沒有首先把全局的問題考慮清楚就急于進行設計凰浮，這是交互設計的大忌我抠。交互設計最先應該梳理的就是流程問題，而不是沉浸在設計形式的實現(xiàn)上袜茧。這些觀念我們常常心里清楚，但是在實際操作中卻容易受到外界環(huán)境的干擾瓣窄，而導致出現(xiàn)舍本逐末的問題笛厦。
經(jīng)過討論，我們明確了主流程俺夕，再反復跟產(chǎn)品經(jīng)理明確需求裳凸，溝通細節(jié)，確認了整體優(yōu)化的方向劝贸，才最后開始方案的設計姨谷。設計出來的方案，也得到了我們自己和產(chǎn)品經(jīng)理的肯定映九。
4.交互細節(jié)把控梦湘，考慮得全面一點，再全面一點
在項目設計中件甥，除去對主流程的設計捌议，對交互細節(jié)的把控也很重要（當然不能太過于陷入細節(jié)），尤其是移動端的設計引有。下面是在移動端設計時遇到幾個典型問題瓣颅，以及當時的解決方案。
（1）首頁設計
產(chǎn)品經(jīng)理提供的原型中首頁存在的問題主要是信息的展示沒有主次之分譬正，甚至主要的功能還被次要的信息弱化宫补；其次，首頁除了展示信息曾我，還有引導用戶開始操作粉怕，增加使用軟件的欲望。因此優(yōu)化的版本主要在這幾個方面進行了優(yōu)化：
1°明確主要功能是學生在這個平臺刷題您单，因此抽題練習在首頁的占比可以加大斋荞，把抽題聯(lián)系單獨放出來，凸顯出重要性虐秦，讓用戶進入考評系統(tǒng)就可以一目了然看到這個功能平酿。
2°增加做題數(shù)據(jù)展示，讓用戶知道自己的做題情況悦陋，可以激發(fā)他繼續(xù)做題或者開始做題的欲望蜈彼。
（2）練習記錄的列表在設計上存在的問題主要有：
圖標按鈕所表達的功能不夠直觀；未完成和 已完成的數(shù)據(jù)劃分不明確俺驶；列表信息缺乏學生關注的信息幸逆。主要做出以下優(yōu)化：
1°重新分析用戶使用未完成棍辕、已完成數(shù)據(jù)列表的場景，梳理未完成还绘、已完成列表數(shù)據(jù)的展示邏輯楚昭。確定為，所有未完成的練習包括重測所生成的練習拍顷，均以一條獨立的數(shù)據(jù)展示出來抚太；在已完成列表中，只要練習已完成昔案，即使練習之下有未完成的重測練習記錄尿贫，都作為整體展示出來。
2°按鈕確定使用文字按鈕踏揣，主要考慮到重新測試和繼續(xù)練習這兩個功能難以找到相匹配的圖標按鈕來展示庆亡。
3°增加練習正確率的信息，讓用戶可以在列表中就能對練習的得分率有所了解捞稿，從而做出判斷是否需要重測又谋。
總的來說，在確定整體流程后具體到每一個小的功能的設計時括享，考慮得再細也不為過搂根。
