工作中再一次驗證了，非結構化數(shù)據(jù)的必要性。我司產(chǎn)品用戶在注冊過程中掉弛，大齡用戶很多次發(fā)生搞不懂驗證碼怎么填寫症见。就是input框后那種“3+25=？”的驗證形式殃饿。普通網(wǎng)民水友們很奇怪這難道不好算谋作，小學沒畢業(yè)之云云。
其實問題不是出在運算層面乎芳。而是接受信息邏輯層面瓷们。并且我司產(chǎn)品用戶的有一個特殊性就是大齡，非網(wǎng)癮患者秒咐，平時很少上網(wǎng)用PC甚至手機你能想象嗎谬晕，這產(chǎn)品線有多刁難⌒。“接受信息邏輯”層面是啥呢攒钳，就是說用戶不知道是該運算公式后只填入一個結果數(shù)字“28”呢，還是該模仿寫一個的公式“2+24=?”呢雷滋，還是連公式帶結果一起輸入“3+25=28”呢不撑，還是其它奇思妙想。也因為他們也許很多人之前沒有填過“請寫入右邊數(shù)字或字母”的時代就直接跨度到運算了吧。（PC產(chǎn)品驗證碼形式是挺亂的淌喻，字辨認確實也有很變態(tài)的＿氲邸）
不談提示語的嚴謹性重要性实愚。單說這種驗證碼方式的機器語言，就是所謂的結構化數(shù)據(jù)模式(圖)兔辅，它的的優(yōu)勢在于格式化的信息讓程序處理起來更方便腊敲，我估計也是多年前某程序員大神編寫的。對大眾用戶（9年制義務教育普通人群）是夠维苔。但是碰到我司產(chǎn)品用戶特殊性卻有了障礙碰辅。特別是某些會產(chǎn)生歧義的輸入框！
臨時解決方案是讓前端大神修改為要么是“字母數(shù)字”形式介时，要么是“滑動拼圖”形式没宾，也看他們懶不懶。然后我風聲鶴唳的溫柔交流了下理想中的表單該如何“人性化”的一面沸柔。其實表單的填寫本來就是枯燥厭煩的事情循衰。而且我司產(chǎn)品填寫內容雖然階段性展示了，但是細節(jié)處理上給出了可以更好的方案勉失，就是“非結構化數(shù)據(jù)填寫”說直白了就是隨便填羹蚣。不按照既定規(guī)范格式開放式輸入字符，然后程序查找判斷填寫字段中的可能正確性答案乱凿。不論是填寫日期時候寫成“2017-8-6”還是“2017? 08? 06”顽素，“日期是2017年8月6日”是否有多余字符咽弦，系統(tǒng)都能識別篩查，而不需要像工程師一樣嚴謹胁出。
開放式體驗設計也體現(xiàn)在精簡用戶的操作的細節(jié)上型型。比如在設計客戶端的文件預覽功能，我會在界面的基本框架中布置好一個功能圖標入口全蝶，運用十分邏輯化的流程給予表現(xiàn)：點擊主界面功能圖標 → 彈出文件列表對話框→ 點擊添加新文件圖標→彈出win系統(tǒng)彈框→尋找新文件位置→上傳到文件列表對話框→ 選中新文件打開闹蒜。這種流程優(yōu)勢是邏輯步驟清晰，基本不會發(fā)生歧義誤操作抑淫。但是劣勢是操作十分繁瑣绷落。經(jīng)過用戶調研后，統(tǒng)計用戶在使用預覽文件功能中添加新文件預覽和上次舊文件再次預覽的比例前者約56%始苇。所以只針對新文件預覽流程砌烁，又進行簡化：就是文件直接拖拽到主界面內直接打開，后臺自動添加在文件列表內（防止用戶本地丟失）催式。這樣用戶避免客戶端執(zhí)行邏輯函喉，很迅速的高效使用。
精益化設計中荣月，不能一而再再而三將就開發(fā)成本和快速圈地等因素管呵，大口咀嚼后的細嚼慢咽，對用戶群的周到服務才會逐漸強化用戶依賴感哺窄。而對產(chǎn)品傳達出的品質捐下，無非是在產(chǎn)品設計的想用戶不敢想，為用戶不敢為堂氯，廣于用戶眼界蔑担，高于用戶思維，把諸多用戶無法掌控因素扼殺搖籃里咽白。如果程序結果驗證是利大于弊，即使再艱辛復雜鸟缕，程序開發(fā)中能解決的問題就在開發(fā)中解決晶框，把最方便的體驗給予用戶。
