oa系統二次開發的流程?對具備一定規模的公司來說，OA是非常常見且緻力于提高效率的一套系統而本文在使用體驗一套OA系統後，也就産品設計、頁面設計等方面的内容，展開了一些分析與建議，我來為大家科普一下關于oa系統二次開發的流程?下面希望有你要的答案，我們一起來看看吧!

oa系統二次開發的流程

對具備一定規模的公司來說，OA是非常常見且緻力于提高效率的一套系統。而本文在使用體驗一套OA系統後，也就産品設計、頁面設計等方面的内容，展開了一些分析與建議。

随着互聯網技術的迅猛發展，各公司對于内部的管理流程，從原來的線下處理逐漸轉移至線上，使得公司内部的業務處理效率得到了飛速的提升。但受限于小公司資金不足，無法對線上辦公産品進行全面的開發，市場中便出現了很多以線下業務線上化為目的的公司，主要以出售OA系統為主，并以其專業的OA解決方案，協助中小企業以低成本提升公司内部業務處理效率。

我在長期的職業生涯中，由于互聯網行業的特殊性，用過不少的系統，并且經常對各系統在設計、流程方面的優劣進行總結或與同事進行探讨，但是很少進行正規的書面内容總結，由于疫情當前，時間多少寬松了些，閑來無事的下午随機挑了一款OA系統進行頁面設計方面的問題總結，并整理發表出來，我所總結的内容未必是正确的，當前文章旨在與産品設計方面與大家進行探讨。

以下系統截圖已在重要位置進行馬賽克處理，本人無意醜化任何系統，僅作為與大家讨論産品設計為用。随機在當前平台中挑選了幾個問題，寫出來與大家探讨探讨。

1. 問題探讨

我登錄的是web頁面，當前網站所展示的效果如果沒有猜錯的話，也是Web對應的頁面結構，但是對于鼠标操作的用戶來說，定制化首頁的雙屏切換功能設置成扁平形狀是不是有些“不近人情”。

首先，頁面不是大範圍的鼠标感應區域，無法使用鼠标左右拉取頁面從而達到切屏效果，就像iPad中愛奇藝或者優酷那種全屏幕手指感應切換的方式。

第二，大部分台式機或筆記本都不支持觸屏操作，無法精準的按照使用者的意識瞬間觸達切屏按鈕，建議更換為鼠标可精準操作的其他方式。

2. 建議方案

增大按鈕可點擊面積，提升使用者鼠标的精準點擊成功的概率（讓用戶覺得爽才是真的好）。

将當前首頁與第二個TAB标簽内容相融合，定制化入口頁面做在頁面頂部也是一個很好的選擇，如下圖：

1. 問題探讨

OA為了滿足不同使用者的使用需求和習慣，增加了相關的首頁定制功能，這是一個很好的功能設計，毋庸置疑。

我數了數，可定制的功能模塊高達24個（可配置模塊數量可能與各公司系統管理員配置的菜單數量有關），給我的第一感覺是“不錯”，我确實需要将大量的工作通過定制化頁面展現出來，同時在互聯網飛速發展的今天，各個公司都在顆粒化使用者的需求，這不是什麼問題。

問題在于“可選菜單”中的24個可定制模塊名稱，無法通過篩選關鍵詞的方式進行定位或查找。這意味着使用者如要想使用定制化首頁功能，就必須将這24個模塊内容全部吸收後，才知道自己想要定制的功能是否存在。

2. 建議方案

對于選擇控件中存在大量内容的情況，其實隻需要在可選菜單的列表内容頂部增加一個小小的聯動篩選控件即可，控件采用實時獲取輸入内容，并調整列表中所展示的結果與其内容相符即可。

1. 問題探讨

這個不用多說大家也肯定非常清楚，是用來記錄每個人使用辦公管理系統進行打卡的信息記錄，但是讓我很費解的是，進入當前頁面後，篩選項中的考勤日期，永遠都會定格在上一個自然月中。

在我看來，一個絕大部分使用者，進入考勤列表頁面，是為了查看近期的考勤記錄，是否有遲到、忘打卡的現象等異常現象，如果出現此類現象需盡快進行處理，避免工資結算時的尴尬。

但是就像剛才所說，無論什麼時候進入當前頁面，篩選項中默認設置的時間永遠都是上個自然月的起始與結束時間。

以下圖為例，如果想查看五月份的數據，我需要進入頁面後，将考勤日期的篩選條件清空後，才可以将考勤記錄按照時間倒序的形式進行全盤展示。

2. 建議方案

其實對于當前問題最好的處理方法，就是按照産品設計列表的通用慣例，在進入頁面時，不做任何篩條件的前置，放開當前頁面所展示内容，使其用戶可以查找今日到初條數據即可。

之所以這樣做，是因為考勤查看的需求，大多情況下發生在近期，如用戶查看昨天或本月是否有漏打卡的情況，如有相關問題則需要進行處理。上個月的漏打卡相關問題絕大部分已成既定事實，HR恐怕很難通融。

1. 問題探讨

還記得首頁中可自定義選擇選擇入口的空間麼（下圖），這個控件與列表頁中可自定義列表字段的功能相同，但是交互方法卻有差異。

如首頁的自定義入口功能中，可選菜單與已選菜單是通過 與x的交互方法來進行實現的，但是列表中的自定義交互方式變更為箭頭可左右增加與移除，或直接對項目内容進行拖動，從而達到選擇與删除的效果。

這個位置的設計很奇怪，雖然用戶都能看明白如何去操作，但還是建議同一個網站中在類似的功能下使用統一的選擇方式與風格，降低用戶的學習成本（雖然這個例子）。

2. 建議方案

其實很簡單，隻要保證同一個平台中，同一個控件或元素的表達、交互方式統一、一緻即可。我們互聯網人總是在談論“用戶的學習成本”，殊不知學習成本可以小到一個字段，大到一套流程，為什麼不讓用戶輕輕松松的去操作麼？享受這種暢快操作所帶來的快感。

1. 問題探讨

在OA平台中的請假功能中，如果選擇休假類别與當前賬戶不符合的類型，将會給出相應錯誤提示，這種提示的功能非常好，有效避免了使用者在不符合請假條件的情況下，依然将所有信息完整錄入後，在點擊提交按鈕後才展示出相關的錯誤信息，促使使用者造成所做工的浪費，而達到情緒崩潰的邊緣（還好内容少，不然使用者是要罵娘的）。

不過因為這個平台的錯誤提示交互設計，使用者順利的通過另一種途徑産生了與崩潰類似的情緒變化。

我們來看一下，當錯誤提示信息被觸發後（下圖2），其展現形式是以彈窗來進行實現的，但這個彈窗是沒有關閉按鈕的，使用者無法使用鼠标主動對錯誤信息進行關閉，而是要在當前狀态下等待5秒鐘左右的時間，其系統才能自動關閉錯誤彈窗。且當前彈窗級别位于整體頁面最頂層，這意味着當前彈窗不關閉的話，是無法對當前頁面中任何一個元素進行主動操作的。

換句話來講，錯誤彈窗出現後，使用者意識到了自己的問題，從而主動通過鼠标探測的方式尋找關閉當前彈窗的方法（錯誤信息很打臉的），但無論在這5秒鐘的時間裡，使用者進行了怎樣的操作，都無法達成自己的意願。那麼在這個環節中，使用者經曆了兩種心理，休假類型選擇錯誤所帶來的預期破滅，與無法關閉錯誤彈窗的挫敗感。

另外可以看到，“事由”的輸入框中，最大輸入字符為“32766”個字符或漢字，我是有些不解，為什麼是這麼個不整不零的數字。

且不說三萬多字在當前這麼小的窗口中如何展示，從當前請假需求來看，三萬多字是不是也太多了，不應該是精簡提煉請假事由麼？

即便需要大量文字支持，也建議對輸入框的大小做些調整，使其能夠在更加寬泛的範圍内，滿足既定文字的合理輸入空間。

2. 建議方案

正常的應對無關閉按鈕彈窗的方式為，輕點彈窗或對當前頁面其他部位進行單擊，完成鼠标觸發環節，成功關閉錯誤提示彈窗。這個環節就像是使用者在與系統進行對話， 内容為：“好，我知道我錯了，你别說了，我重新寫，YOU不要在刺激我了”。

改變彈窗樣式，增加關閉按鈕或小叉子，讓用戶知道如何解決因自身錯誤帶來的流程停滞。

1. 問題探讨

網站整體頁面采用左側樹形目錄（狹窄，主要功能在于快速切換不同模塊完成相關需求），右側内容展示的結構進行布局的（對模塊中的内容進行細化顯示），在工資的詳情頁中，右側區域，每行采用兩個字段元素進行顯示，造成頁面位置大量浪費，就像是一個空空蕩蕩房間布置了些許的擺件，看着還是有些别扭。

2. 建議方案

其實建議采用合理化布局，比如增加每行所顯示字段數，如像其檔案管理中的頁面中的設計，每行元素增加至4個會有更好的展示體驗。

如果擔心頁面橫向排列4個元素，造成頁面過短，底部出現大量留白的情況，那麼可以對頁面元素使用單獨的單元格部署（不是列表，而是有着邊框的單元格），利用單元格本身所占用的空間，彌補一些頁面空白缺陷，我想還是可取的。

1. 問題探讨

電腦補貼申請功能比較常用，但是當前頁面可能是獨立頁面，點擊後會新建浏覽器tab展示其對應内容，這一切都很正常。

但是當我點擊電腦補貼申請功能後，當前操作頁面右側卻從原頁面内容突然變為空内容，這是一個很奇怪的現象。

2. 建議方案

新建浏覽器tab打開後，應保證入口頁面右側内容不進行變更，且操作模塊應保留為正在操作的模塊中，這樣會比較合理一些，不然使用者會看到一個大白闆。

#專欄作家#

王榮，微信号公衆号：PM_magic，人人都是産品經理專欄作家。10年産品，專注互聯網後台産品設計，主導電商後台核心業務搭建，多套0到1平台設計、概念落地、多類型系統設計經驗。

本文原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!