前幾天,球哥給我分享了一篇關于網易云閱讀【iPhone2.0】交互設計回顧的文章,發現我們的產品的開發進度情況跟網易云閱讀一些地方非常相似,再版本不斷迭代中不斷加入新的功能,當產品做到一定階段后,現有的產品框架不再能滿足新增加的功能和需求,并且在快速迭代中只是注重了功能的實現,沒有過多的考慮交互設計及用戶體驗,因此一周前團隊決定對產品框架及UI等重新設計。在那篇文章的啟發下,橫向對比一下彼此產品產品過程中的不同,來回顧及總結這次產品版本改進過程中一些問題,不會涉及到產品具體細節上,更多的是“紙上談兵”。
(一)收集需求
收集需求的方式很多,總結下來主要來自這幾個方面:1.可用性測試;2.用戶反饋;3.競品分析;4.項目內部人員;5.來自老板的需求。
1.可用性測試一般都是放在產品開發完成后去做的,如果不是功能驅動的產品,用產品用例一條條測試就可以了,很多小團隊都是采用這種方式。沒有想到網易的團隊會在收集需求階段做簡單的可用性測試。按照我的理解是他們在原有產品用例的基礎上做測試,主要的目的是為了刪掉一些需求,而不是發現新需求。我們的產品在這次改版中根據需求權重也是去掉了很多功能,具體說這是什么方法更確切的說完全憑“感覺”。因此,網易這樣的做法可以在產品大版本迭代中去使用,效果比憑“感覺”要好的多。因此,要完善現有產品的用例,為下一版本的更新做準備。
2.我們的產品相對來說屬于小眾產品,第一個版本開發完成上線一段時間后,并沒有收到太多的用戶的反饋,或者說沒有系統性的去收集這些反饋意見,并不是產品沒有什么問題,而是用戶基數太少。在本次版本迭代中,沒有太多的用戶反饋可以拿來做參考。這么至關重要的事情,卻在工作的疏忽了。因此,本次版本迭代上去一定要記錄用戶的反饋意見,并且要去試著建立一個完善的用戶反饋系統,即使用戶基數再少也要去做。以前總是在忙著用怎么樣的方式實現什么樣的功能,卻忽略實現的功能用戶反饋是什么樣的。我想以后要花一定的時間去收集整理用戶的反饋,甚至多抽出一些時間去接觸用戶。
3.由于產品的一個特殊的玩法,使得產品很難在市面上找到相似的產品出來,當然拋開那個特殊的玩法,大部分功能上或者提供的服務上有很多同類的產品。而且我們的產品部分功能還是借鑒了同類的產品。所以單獨拿出一個產品或者幾個產品跟我們的產品做競品分析都不合適,另一方面互聯網金融也是剛剛發展并且團隊也剛剛成立沒多久,另一方面,金融市場足夠大 ,大家的關系并不是“競爭者”更多的是“探索者”,研究了幾家互聯網金融的產品,發現彼此之間都在相互借鑒。因此,我個人的理解是通過競品分析去找功能上的差異性進而跟進他人的產品功能,不如把重心放在市場和用戶身上去挖掘或者發現新的需求。
4.現在產品的需求主要來自老板(畢竟是對業務最熟悉的人),還有一部分來自項目內部人員(主要是運營人員)。我相信大多數的創業公司都是這樣的方式,雖然這樣的方式有很多弊端,但是保證了創業公司的產品研發效率,而不像大公司為了一個原型圖都要幾個產品經理能一兩個月。不過想要改變這樣的方式,只能是伴隨著產品經理的業務能力的提升以及用戶反饋系統的建立而逐步改變。
本次產品迭代過程中,跟UI設計又發生了爭執,一方面是自己表達方式的問題,而一方面或者說更主要的是自己過于追求產品界面上的細節,讓自己陷入到一種對“產品質感”的自我意淫中去了?,F在反過來看產品的需求收集,你發現自己偏離了的工作重心,你應該把更多的時間放在產品業務上,也不是產品UI細節上,后者并不能決定你產品的成敗。引以為戒,以后改正。
(二)確定體驗設計的目標
當決定對APP進行大的版本改進時,最先考慮的問題時現有的產品框架已經不再能滿足新增加的功能和需求,出發點并沒有落在用戶體驗上,所以根本沒有考慮體驗設計的目標,更不會考慮到修改某個具體的功能的目的是什么。當看到球哥推薦的那篇文章時,并沒有想著馬上用這樣的方法在產品上面,因為你并不能確定這樣的“目標”驅動的方式是否適合我們的團隊我們的產品。一方面我們收到的反饋意見就很少,再根據這些反饋意見提煉出體驗設計的目標就更加的困難。而一個面對小眾的產品跟面對大眾的產品對產品的目標有著根本上的不同,前者考慮更多的是產品的“有用性”、“可用性”,而后者考慮的是在“有用性”,“可用性”的基礎上要更多的考慮“用的爽”,因此,像網易云閱讀這樣面對大眾的產品,用戶停留在app的時間又比較長,因此就有必要去制定產品詳細的體驗設計的目標,這樣才能保證產品“用的爽”。而對于我們的產品,還在“有用性”階段探索著,甚至有些功能還談不上“可用性”??偨Y說來,產品都是進行大版本迭代工作,但是彼此產品所處的階段不同,而確定產品體驗設計目標這樣的流程或者說方法,放在“用的爽”階段更適合。
(三)方案PK
整體團隊決定進行改版的時候,其實我已經將產品改版的原型圖畫了出來,所以直接是拿著我出來的方案后團隊覺得都還不錯才決定改版的。之所以會出現這樣的問題,跟我來到團隊的時間有關系(這里不再累贅),所以對于大的框架方面沒有所謂的方案PK。事后想想尤其是看了那篇文章后,還是有點后怕,如果你出的方案沒有被大家肯定會是一個什么情況。以后有新的需求出現的時候還是盡量多出來幾套方案會更好一些。
(四)交互細節
這個涉及到產品的具體情況,我會找時間單獨來說,這里就不一一說明了。
(五)開發跟進
最近工作的重心就是跟進開發,中間還是遇到了不少問題,下面一一說明:
1.原型更新問題:即使高保真圖出來以后在開發過程還是會出現修改原型圖的時候,小團隊并沒有一個統一協同辦公軟件,很多的時候都是我一個一個告訴他們有地方需要更新。甚至有些時候還會出現忘記告訴的情況。后來想到了一個方法,就是每周把更新的地方統一告訴他們,后來發現效果也不是很好,有些更新的地方他們前端已經開放完成了。現在只能一點點盯著他們去做,也是更團隊一個慢慢磨合的過程。
2.新的需求出現:版本的改進過程中會有些新的需求出現。現在的做法是全部壓下來,等他們把這些過去的東西全部能完以后再考慮這些新功能,對于我們這樣的團隊我不知道這樣會不會更好,但是,現在只能這樣一步步來,后續遇到什么問題就解決什么問題,關于這一點,等版本上線后或者這個階段產品開發完成后,再去總結這些問題。
這個版本改進過程中遇到過很多問題,這樣的總結更多的是從宏觀上看,涉及到具體細節的問題,我想要等到開發結束后做測試的時候去總結。