關(guān)于交互在跟進項目進度中的一些反思

2 評論 8192 瀏覽 19 收藏 9 分鐘

本文作者結(jié)合自身經(jīng)驗與大家分享:作為一名交互設(shè)計師,在跟進項目時該如何做?希望他的反思總結(jié)可以給你帶來一定的思考~enjoy~

交互設(shè)計師往往手頭上總會同時負責多個項目,因此很多時候會發(fā)生這樣的情況:

上面是我自己遇到的問題,聊天記錄反應了兩點問題:

  1. 開發(fā)幾近完成,甚至開發(fā)人員還做了一些調(diào)整,然而身為交互設(shè)計師卻沒有及時跟進;
  2. 直至問了才知道設(shè)計稿還沒有出,沒有及時的跟進設(shè)計師遇到的情況。

由于前段時間同時負責幾個項目,就對其中一個較小的項目關(guān)注不夠,沒有及時的跟進和同步項目的開發(fā)進度,導致信息的滯后。作為交互設(shè)計師沒有跟進項目的進度是一種失職。

這只是項目已經(jīng)在開發(fā)階段時的疏忽,但是其實在整個項目進行過程中,同樣會有許多事情需要我們跟進,以下是我個人為避免一些疏漏做的一些總結(jié)。

開發(fā)前:建立信任

1、做好需求會前準備

需求評審會是全面了解一個項目的重要會議,作為交互設(shè)計師需要提前了解項目背景,競品的設(shè)計等,因為在會上大家總是會腦洞大開,而此時的你如果能夠給出一些中肯的建議或回答,會讓人留下深刻的印象,時間長了,大家就會發(fā)覺你是個專業(yè)知識豐富,并且做事認真負責的人,信任感會慢慢的樹立起來。這部分內(nèi)容可以參看我之前文章《需求評審會:一個神奇的會議》

2、學會緩和氣氛

需求會上難免總會有產(chǎn)品和開發(fā)因為需求而出現(xiàn)討價還價,抑或產(chǎn)品總會有考慮不夠周全被抓到漏洞的時候,每每出現(xiàn)情況時,交互設(shè)計師作為卡在產(chǎn)品與開發(fā)之間的崗位,在保證方案內(nèi)容不跑偏的情況下,可以適當?shù)挠靡恍┳猿盎蛘咄嫘Φ姆绞骄徍鸵幌職夥?。這個時候不但會體現(xiàn)你的高情商,陷入窘境的同事也會對你感到感激。

3、要提高全局觀

如果我們只將自己定位于交互設(shè)計師,那么腦海中的藍圖就只是自己的線框圖、交互文檔,然而現(xiàn)實確實往往要受到來自各個階層的束縛。

但如果我們將自己定位于整個產(chǎn)品的負責人,站在老板、PM、開發(fā)、測試、運營多維度的角度去看問題,會發(fā)現(xiàn)自己格局會變大,因為你什么都考慮到了,哪怕不夠深入,但是你已經(jīng)將這個不確定因素考慮其中。

你說的話,表的態(tài)也跟別人的角度不一樣,而這種思維高度大家當然也能體會到。到時,擁有的不僅是話語權(quán),而是尊重與敬佩。

開發(fā)工程中

1、主動詢問項目的進度

交互設(shè)計師對于自己負責的項目要有一個根據(jù)優(yōu)先級的排期表,并且對每個項目都要定期的去跟進項目進度,比如你可以每天下班前一個小時固定去溝通你排期項目的進度。當然,每個人的溝通習慣不同,并且隨著時間越來越了解團隊成員,你基本可以判斷出哪些人對于交互方案的實現(xiàn)會打折扣,哪些人可以嚴格實現(xiàn)交互方案,你的對項目的跟進也會開始有一定的傾向性。這是交互設(shè)計師的日常工作,會隨著經(jīng)驗越做越好,這里就不多家贅述了。

2、做好交互方案的維護

(1)維護方案歷史

根據(jù)經(jīng)驗,交互方案一稿過的可能性幾乎為0,在和需求方確認需求,需求評審會,程序開發(fā)測試過程中,或多或少都會遇到方案需要調(diào)整的情況,最終確定的方案肯定也是多方共同妥協(xié)的結(jié)果。而及時的維護方案的更新歷史(包括修改內(nèi)容和作出修改的原因),雖然比較麻煩,但可以在后續(xù)開發(fā)過程中遇到種種對于設(shè)計細節(jié)的疑問挑戰(zhàn)時,能夠幫我們迅速回想起當初作出設(shè)計決策的原因,給出充分合理的答案。

(2)記錄客觀限制

交互設(shè)計需要在需求、業(yè)務與開發(fā)之間做好權(quán)衡取舍,客觀的業(yè)務與開發(fā)技術(shù)限制也一直存在,這會使得我們的設(shè)計方案有時候看上去并不是那么完美合理。當我們因為客觀因素的限制而不得不在設(shè)計方案上作出妥協(xié)時,不妨也將這些客觀限制條件一一整理記錄下來,既幫別人更好地理解我們這么設(shè)計的原因,也能幫自己在后續(xù)的同項目迭代中及時回避對同類限制條件考慮不周的情況。

(3)及時同步狀態(tài)

當交互方案發(fā)生變動后,即使是細節(jié)微調(diào)、或口頭確認得比較清楚,最好也還是及時同步更新最新的交互方案鏈接給項目組成員。否則的話,開發(fā)按照舊版本設(shè)計方案執(zhí)行,測試會將改動后的交互方式當成Bug提交,這一類的烏龍并不在少數(shù)。完全及時同步更新方案來避免這一系列錯誤的發(fā)生。

項目完成后

在開發(fā)完成之后,交互設(shè)計師的工作仍然沒有完成。要開始進入驗收、走查的階段,我整理了一些走查的注意事項:

其中需要說明的是:

  • 頁面交互走查:這個是必須要做的事情。如同一開始的案例中所看到,開發(fā)人員總會根據(jù)實際的開發(fā)情況對頁面的交互做一些調(diào)整,因此交互設(shè)計師更要根據(jù)自己的交互文檔對界面進行一一的走查。
  • 壓力測試:這部分測試看起來更像是產(chǎn)品經(jīng)理關(guān)注部分。其實不然,每次在做壓力測試的時候,總會出現(xiàn)一些極端情況下暴露出來的問題,而且是原來沒有考慮周全的,一旦發(fā)現(xiàn),交互部分也要迅速的填坑。
  • 灰度測試:算是交互設(shè)計師拿到的第一批用戶的使用反饋意見,要趕緊對反饋進行篩選分類,然后在產(chǎn)品上線前根據(jù)重要程序進行排期優(yōu)化。

交互設(shè)計師在一個項目中并不是交付了交互文檔之后工作便結(jié)束了,在整個項目的開發(fā)過程中,乃至上線運營后,仍然還有很多交互細節(jié)需要去跟進和維護。

以上。

 

本文由 @endlishted 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來自StockSnap.io,基于 CC0 協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 希望作者大大能多講些關(guān)于灰度測試細化的內(nèi)容

    回復