全栈工程师?
嗯.....目前并不是!

產品總結:工具類軟件設計難點該如何解決?

本文筆者通過自身對工具類軟件設計的經驗,為大家總結了工具類軟件的設計難點以及相關的解決方案。

近期,做了份地圖樣式編輯器交互設計任務。地圖樣式編輯器是款工具類軟件,本着以小見大的原則,將以該產品為例着手總結與推理一下工具類軟件的交互設計總結。

細細回想,在產品設計過程中仍有需要待商榷與調整的地方,但這並不妨礙業務目標與核心功能的用戶體驗,梳理總結目的之一也是為了改善這些細節點。

當然,因為是以小見大原則,該文必然會有它的局限性,比如:作者的閱歷與經驗局限,舉列量少是否具備代表性, 工具類軟件類目是否可以具體再細分之類的問題。這些問題希望讀者能在閱讀過程中能一一辯解,畢竟該文僅僅算的上是私人總結。

那麼,話不多說,開始談談:個人在地圖樣式編輯器設計過程中總結的工具類軟件設計經驗。

一、產品設計背景

地圖樣式編輯器是一款地圖可視化類的軟件。接到這項任務時,其實地圖編輯已有初版核心頁面,但產品功能、業務流程、人機交互與界面設計都存在很大的問題點,不然也不會找到我們部門提需求。

那麼,首先理順與確認需求,方法論參考5W2H。

在這個過程中,注意兩點:

  1. 預計該項目參與人數與制定計劃。我是認為參與人數不同,具體配合方式就具有差異性。這個因人而異,涉及團隊成員的能力、工作方式以及為人等因素;
  2. 一定要二次(多次)確認需求,保證我們的設計方向正確。因為,理想工作方式是交互人員參與到定義需求中,但是實際工作,可能往往是產品經理直接制定需求拍板再丟給交互設計師,所以在與他們溝通中,要帶有疑問與建議與他們確認二次需求。

其次,開始交互設計工作,工作流程如下:

二、產品設計難點

在產品設計之前,預計將要面臨難點:

  1. 由於兩個合作的部門不在同地,所以是異地視頻溝通;
  2. 現存版本混亂,UE體驗交互差,任務流程片段式操作;
  3. 功能龐雜,暫無法做測試判斷是否取捨某些非核心功能,以節省開發時間;
  4. 之前版本無法給到大量用戶操作體驗反饋數據信息做為設計參考依據,產品本質上依然是理論上假設。

梳理這些難點后,會發現其實該產品依然處於0到1的過程。那麼,如何解決這些難點?

先歸納這些難點所屬那方面的問題,然後對應解決方案。

第一點屬於設計師溝通問題。

異地溝通除了面臨高成本溝通問題外,其實與面對面溝通沒有太大出入,依然是需要設計師在溝通過程中理解人際關係,減少認知負荷,聆聽理解與控制自己的心態。

(具體參考《設計師要懂溝通之術》)但需要注意一個現象,視頻溝通無法營造共現(Co-Presence),且心理重視程度:視頻溝通小於面對面溝通。那麼,必然溝通流暢度不夠,需要反覆確認。

第二點屬於人機交互問題。可遵循尼爾森十大定律,不多贅言。

第三點屬於需求定義問題。這個問題比較複雜,涉及每個公司的工作流程問題——即:交互設計是否參與到產品定義需求的過程中。能參與當然最好,未能參與也不用沮喪,那就帶着質疑與建議向產品經理反覆溝通需求。

第四點屬於用戶調研與用戶體驗的問題。理論指導可遵循上篇文章《探討產品價值下的UX設計》

三、遇到的問題點

在產品設計過程中,遇到的問題:

  1. 團隊合作,如何保持與能力不同的同事之間共同合作,推進工作。
  2. 保持個人建議的同時,如何去除個人情緒,以贊成產品經理的產品規劃與安排?即,如何委婉的向上級提出建議訴求?
  3. 只有信息架構的情況下,是否就能滿足UE設計的全部需求,什麼情況下需要流程圖?
  4. 個人的設計是有一定局限性的,得承認與認識到自己的局限性,聆聽他人的更合理意見,並學習它;(老生常談的問題)。
  5. 確保一次定義所有需求不切實際,一定會有遺漏點,需要承認這種現象的存在,所以不要怕返工補充(老生常談的問題)。

問題點1、2、4歸屬設計師溝通問題,不多贅述,參考《設計師要懂溝通之術》。

問題點3歸屬流程問題。當時在設計產品UE時,為了節省時間與偷懶,理清產品信息架構后,就直接上手線框圖,結果在中途就與到流程不確定的問題,又返回與溝通流程問題。所以在任何時候,尤其是工具類軟件交互設計時,核心流程必須走一遍。

問題點5歸屬需求問題。一次無法定義產品全部需求除了是因為MVP的工作方式外,還因為我們沒有給需求分類。當具有需求分類檢查的參考時,會很好拾起被遺忘的需求,以便確認。需求可以按照“FURPS+”模型進行分類(模型來源《UML和模式應用》第五章進化式需求)。

具體如下:

  • 功能性(Functional):特性、功能、安全性。
  • 可用性(Usability):人性化因素、幫助、文檔。
  • 可靠性(Reliability):故障頻率、可恢復性、可預測性。
  • 性能(Performance):響應時間、吞吐量、準確性、有效性、資源利用率。
  • 可支持性(Supportability):適應性、可維護性、國際化、可配置性。

“FURPS+”中“+”是指一些輔助性的和次要的因素,比如:

  • 實現(Implementation)資源限制、語言和工具、硬件等。
  • 接口(Interface)強加於外部系統接口之上的約束。
  • 操作(Operation)對齊操作設置的系統管理。
  • 包裝(Packaging)列如物理的包裝盒。
  • 授權(Legal)許可證或者其他方式。

亦可以使用其他需求分類方式進行檢查,並不局限該分類方式。如果記不住,那麼,打印出來,在溝通時照着一一提出,若沒有就跳過。

有些需求是技術上,那就確認技術是否可實現,以及實現到什麼程度。

四、小結

以上地圖樣式編輯器在設計過程中,遇到的問題以及現有解決版,說是工具類軟件設計總結,但也可以說是通用的產品設計難點與目前解決辦法總結,只是舉的案例恰恰是工具類軟件設計。

 

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《產品總結:工具類軟件設計難點該如何解決?》
文章链接:https://www.pmbear.com/archives/9374
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们