如何設(shè)計企業(yè)級軟件?

7 評論 8042 瀏覽 49 收藏 21 分鐘

我們的目標不是去挖掘新的工作方法,而是去發(fā)現(xiàn)和整理目前有效的方法,建立適合的團隊結(jié)構(gòu),從而提高整個設(shè)計團隊內(nèi)部、外部的溝通效率。

在Mesosphere(https://mesosphere.com/,后面會有介紹),產(chǎn)品設(shè)計團隊負責中間件產(chǎn)品的UX(用戶體驗)設(shè)計。通常情況下UX主要涉及我們的主打產(chǎn)品DC/OS的GUI(圖形用戶界面)部分,以及CLI(命令行界面)UX設(shè)計、API、文檔和其他開源產(chǎn)品。

我非常喜歡設(shè)計團隊對他們的工作流程的描述。作為一名設(shè)計師,了解和學習其他團隊是如何做的,曾經(jīng)遇到的問題以及如何解決,是非常有用的

在Buzzfeed, Airbnb 和 Shopify等團隊的鼓勵下,我們最近整理了我們的產(chǎn)品設(shè)計流程。我們不是第一個在網(wǎng)絡(luò)上公布我們的工作流程的團隊,但是我覺得以復盤方式把這些內(nèi)容寫下來,分享給大家,并且讓大家一起來討論利弊得失是一個很棒的經(jīng)歷。

我們的目標不是去挖掘新的工作方法,而是去發(fā)現(xiàn)和整理目前有效的方法,建立適合的團隊結(jié)構(gòu),從而提高整個設(shè)計團隊內(nèi)部、外部的溝通效率。

——Tom Harman, Buzzfeed設(shè)計經(jīng)理

關(guān)于 Mesosphere

首先,介紹一下背景信息。

在Mesosphere,我們提供類似于Yelp, Verizon 以及Bloomberg?這類公司管理他們的IT軟硬件基礎(chǔ)設(shè)施的產(chǎn)品和服務。

我們的主打產(chǎn)品Mesosphere DC/OS,是一款以數(shù)據(jù)為中心的操作系統(tǒng),它可以實現(xiàn)跨服務器的資源管理,包括:處理器、內(nèi)存以及硬盤等存儲資源。

鑒于我們的產(chǎn)品特性,它其實是被安裝在公司某一臺服務器上的操作系統(tǒng),也不需要每天發(fā)布更新。我們大版本的發(fā)布周期一年三次,這算是比較長的發(fā)布周期了。

產(chǎn)品設(shè)計的角色

我們和產(chǎn)品管理團隊以及開發(fā)團隊一起努力提供對客戶有價值、有用的、可行的產(chǎn)品及特性。

對每個項目來說,E(Engineering開發(fā))、P(Product Management產(chǎn)品管理)、D(Designer設(shè)計)這就像是一個三腳凳。

在一個成功的項目中,這三個方面都必須得到同樣的尊重。當然,項目中還有一些其他的團隊,但是這三個角色是核心和必不可少的。

從一開始就將開發(fā)、產(chǎn)品以及設(shè)計融入進來……團隊應該像一個三腳凳,每個腳代表了成功構(gòu)建產(chǎn)品的方面。如果一開始我們可以做到圖A的程度,那么以適當?shù)谋壤龜U展后就可以形成圖B。

——Alex Schleifer,?Airbnb設(shè)計副總裁

我們實行“雙軌”產(chǎn)品開發(fā)模式。這種開發(fā)模式有兩條平行的軌道,一條是交付,一條是發(fā)現(xiàn)?!敖桓丁标P(guān)注下個版本的特性開發(fā),而“發(fā)現(xiàn)”關(guān)注再下一個版本。

設(shè)計師會與產(chǎn)品以及技術(shù)組長會聚焦在“發(fā)現(xiàn)”,用大量的時間一起來進行快速學習和驗證產(chǎn)品特性以及市場。

為什么文檔化設(shè)計流程很重要?

我們公司和設(shè)計團隊發(fā)現(xiàn)一些情況:

  • 設(shè)計師在各自的項目上流程不統(tǒng)一。
  • 我們的團隊應該如何工作或者說我們曾經(jīng)做過哪些工作,對于這些問題我們并不清楚。
  • 當新的設(shè)計師入職后,不論是新人還是帶新人的設(shè)計師都不是很清楚在當前項目中應該如何開展工作。
  • 我們有一大堆沒有解決的問題和提出的假設(shè)但是沒有記錄下來。
  • 設(shè)計師無法快速響應,因為他們并不知道他們是否有權(quán)限去進行一些決策。

我們是如何做的呢?

這件事情我無法獨自解決,需要整個設(shè)計團隊一起完成。于是我們找了不同團隊的設(shè)計師,花了兩個小時組織了一次設(shè)計研討會。

我在向大家展示了上述的這些問題。然后我們通過研究其他設(shè)計團隊(例如:Buzzfeed, Airbnb, Intercom and Shopify)了解他們在做什么,包括研究一些在Ideo, Google Ventures, Design Council上發(fā)布的行業(yè)流程。

接著我列出了我們希望達成的目標:

  • 與團隊討論我們的工作流,在達成一致后記錄下來。
  • 在公司內(nèi)部對我們的工作流進行宣講和培訓。
  • 讓團隊新進的設(shè)計師可以快速上手。
  • 讓設(shè)計師能更快速的融入新項目
  • 給設(shè)計師一定的決策權(quán)以便在項目中快速響應。

我們在白板上標出一個項目需要有哪些階段。然后我們用一種顏色的便簽寫出設(shè)計師需要在每個階段做些什么,用另外一種顏色寫出我們需要討論的待明確的問題。

我們對上述的產(chǎn)品還是很滿意的,接著我們就與產(chǎn)品管理以及開發(fā)團隊分享我們的成果。這些成果可以作為他們下一步工作的輸入。

為什么我們不采用已有的流程?

毫無疑問的是,我們可以拿到已經(jīng)發(fā)布的經(jīng)典的流程, 并且可能這些流程可以解決我們80%的問題。但是每個公司,每個團隊是不同的。

想要優(yōu)化工作流要考慮的因素很多。我們的公司目前處于什么階段?我們多長時間發(fā)布一次?我們團隊的大小規(guī)模?產(chǎn)品和開發(fā)的工作模式是怎樣的?是使用敏捷、瀑布還是兩者綜合的開發(fā)模式?工作流程需要適應所有的項目,不僅僅是UI項目,還包括CLIs, APIs和其他的開源項目類型。有太多的因素需要考慮。

我們讓團隊自己來設(shè)計工作流程是大有裨益的。自己設(shè)計意味著給了團隊中每個人發(fā)言的機會,大家對最終的成果都有所貢獻。

我們最終產(chǎn)出了8個工作階段,接下來我將逐一進行介紹:

術(shù)語定義

設(shè)計組長

我們發(fā)現(xiàn)需要明確定義設(shè)計組長的職責,這樣在對設(shè)計進行決策時可以很清楚誰有權(quán)利決定這樣設(shè)計以及想要達成的期望是什么。

設(shè)計組長是:

  • 整個項目的設(shè)計負責人。
  • 對項目的設(shè)計方案的易用性、可用性、可行性負責。
  • 除了需要輸出設(shè)計方案為,還需要對最終產(chǎn)品的效果負責
  • 在與產(chǎn)品經(jīng)理、技術(shù)組長、開發(fā)經(jīng)理和開發(fā)人員合作過程中,需要作為設(shè)計師代表。
  • 對于可視化的設(shè)計以及用戶體驗方面有決策權(quán),在制定決策時與產(chǎn)品及開發(fā)協(xié)商。
  • 負責向干系人收集反饋,并且確保交付符合公司業(yè)務目標、設(shè)計理念以及品牌要求。

設(shè)計類項目

必須要有某種幫助我們在現(xiàn)有的待辦清單中組織和定義項目優(yōu)先級。設(shè)計類項目通常是由(產(chǎn)品團隊負責的)產(chǎn)品路線圖驅(qū)動的。也有一些項目是由UX改進或一些組件項目驅(qū)動的。

  • 設(shè)計項目是由設(shè)計團隊確認接收的任務。
  • 通常情況下,設(shè)計類項目是對要發(fā)布的特性或者設(shè)想進行用戶體驗設(shè)計,這類設(shè)計不一定包括GUI或者CLI。設(shè)想可能會是對“發(fā)現(xiàn)”軌道的特性想法的驗證,未來不一定會真正實施。
  • 每個項目有一個設(shè)計組長,可能會有多個設(shè)計師。
  • 當設(shè)計就緒時(得到其他角色認可),設(shè)計類項目視為“完成”。但是,設(shè)計組長仍然需要跟進測試和開發(fā)工作,因為可能會存在一些改進的需求和項目。

Mesosphere產(chǎn)品設(shè)計流程

第一階段:?定義

確保你理解待解決的問題,并且這個問題已經(jīng)在需求、范圍和用戶故事中定義了。同時,需要確??缏毮艿膱F隊在這個問題上達成了一致。

  • 理解誰是提出這個問題或者受這個問題折磨的客戶。
  • 與涉及到的跨職能團隊開一個啟動會
  • 確保角色和職責清晰。
  • 可視化項目達成目標。
  • 創(chuàng)立于項目相關(guān)的文檔。(例如:項目范圍文檔,wiki相關(guān)頁面和進度跟蹤、會議頁面,任務,待辦)

第二階段:研究

我們用Dropmark 來記錄靈感。

理解用戶的問題并且建立同理心。收集盡量多的信息,并且將這些信息整理并轉(zhuǎn)化為團隊可接收的知識。

  • 與用戶/客戶交談并且嘗試體驗問題。
  • 內(nèi)部專家和干系人交談,找出擁護者。
  • 看看其他人是怎么解決這個問題的,包括競爭對手或者類似的工具。
  • 記錄下來你的分析結(jié)果并且在團隊內(nèi)部進行分享。
  • 理解這里是否有一些技術(shù)的約束

第三階段:想法

跨職能的設(shè)計Workshop可以采用6-up方法來激發(fā)很多想法。

讓跨職能團隊的人參與進來,可以擴展你的思路,打開你的腦洞,給出你之前沒有想到的一些方向。

  • 使用草圖、線框圖、流程圖。
  • 組織跨職能頭腦風暴和設(shè)計研討環(huán)節(jié)。
  • 為設(shè)計團隊提供反饋和輸入。
  • 檢查可行性。對于這點,可以和開發(fā)以及產(chǎn)品一起協(xié)商達成一致。

第四階段:設(shè)計

我們通過InVision 來管理原型。

用最好的設(shè)計來創(chuàng)建一個可測試的概念模型(比如:原型)。在經(jīng)過討論并且達成一致后再進行細節(jié)的設(shè)計。

  • 創(chuàng)建一個可驗證的概念模型,比如圖形、流程圖、可交互的原型(可以使用InVision, Framer等等)。
  • 隨著每次的迭代,逐步細化,提高保真程度。
  • 不要在早期就制作保真度太高的概念模型,否則你會發(fā)現(xiàn)關(guān)注點會失焦:從解決方案的業(yè)務流程是否正確被轉(zhuǎn)移到按鈕的顏色上。
  • 但是保真度過低可能會無法得到預期的反饋,進而影響反饋的全面性。

第五階段:驗證

和干系人、用戶和客戶一起來驗證解決方案和你的一些假設(shè)。得到反饋后對解決方案進行優(yōu)化,不斷循環(huán)直至得到達成一致的解決方案。

  • 進行或者參與用戶測試環(huán)節(jié)。
  • 與客戶進行直接對話。
  • 與開源社區(qū)或者UX研究專家分享工作的成果。
  • 與整個團隊確認當前方案的可行性
  • 與內(nèi)部干系人進行評審。

第六階段:交付

我們?yōu)榇蟛糠值捻椖慷继峁┝藈iki頁面,將交互原型和草圖文件放在里面。

在每次開發(fā)完成前(注:我們每年發(fā)布3次),會有一個發(fā)布規(guī)劃階段,用來概述在這個發(fā)布中會包括的內(nèi)容。這個規(guī)劃會涉及到整個公司的多種干系人。

一旦我們確定了發(fā)布的范圍,我們可以開始打磨和優(yōu)化設(shè)計。我們都知道在開發(fā)過程中,可能會有變更發(fā)生。但是我們需要告知開發(fā)實施人員什么時候我們的設(shè)計是“就緒”狀態(tài),可以開始開發(fā)實施了。

  • 打磨設(shè)計。檢查品牌和設(shè)計系統(tǒng)要求。
  • 確保原型是最新的。
  • 確保任何流程或附件的設(shè)計文檔在修訂范圍內(nèi)是有效的。
  • 更新包括設(shè)計用戶故事和事件的Wiki頁面,并且用Wiki來幫助開發(fā)創(chuàng)建他們自己的任務。
  • 確保在需要的時候考慮不同情況下的設(shè)計方案,比如:錯誤狀態(tài)、空值狀態(tài)、針對開源或者企業(yè)用戶的不同設(shè)計方案。
  • 與即將工作在這個項目上的開發(fā)和文檔團隊進行詳細的對接。

第七階段:開發(fā)

我們前段的開發(fā)包括:React, Node 以及?Webpack。

一旦項目進入開發(fā)階段,開發(fā)工程師開始實施解決方案。在這個過程中,設(shè)計師需要提供持續(xù)的質(zhì)量保證以及指導給開發(fā)。

  • 協(xié)助并與開發(fā)人員積極的協(xié)同工作
  • 對于讀法的問題需要快速響應并給出解決方案。
  • 在過程中對工作成功進行演示。
  • 在這個階段,設(shè)計師會花費自己80%左右的時間在設(shè)計和發(fā)現(xiàn)下一個版本的需求。

第八階段:評估

只有將特性交付給用戶使用,并且用戶也確實在用了,這個時候我們可以認為整個流程結(jié)束。但是,雖然流程是結(jié)束了,我們依舊需要持續(xù)的收集內(nèi)外部的反饋信息。

  • 為每個相關(guān)的問題創(chuàng)建問題清單(任務、缺陷、建議)。
  • 與產(chǎn)品和分析團隊一起評估對解決方案的影響。
  • 持續(xù)通過用戶測試和研究收集定性數(shù)據(jù)。
  • 召開跨職能團隊的回顧會。

產(chǎn)品設(shè)計反饋環(huán)

我們鼓勵在每個階段執(zhí)行這樣的設(shè)計反饋環(huán)。這個方法的理念來自于Buzzfeed項目。當你產(chǎn)出Make一些草圖、界面,展示Show給其他設(shè)計師、開發(fā)、用戶,收集Gather到他們的評價、反饋,過濾整理Synthesize他們的意見(哪些是你同意的,采納誰的意見),接著再循環(huán)一輪。

設(shè)計是一個持續(xù)迭代的過程,這樣開放的心態(tài)是十分重要的。

項目周期

項目的類型以及規(guī)模會決定項目周期。小型項目和團隊可以快速的完成項目,而跨職能的大項目會需要各種干系人參與很多的迭代和反饋環(huán)節(jié)。

這是一個項目周期的示例,每個項目都是不同的。重點是我們?nèi)绾味x每個階段的完成標準,并且在每個階段里面不要忘記去執(zhí)行反饋環(huán)。

一些經(jīng)驗分享

  • 你的工作流程需要來基于你們自己的跨職能團隊,特別是你每天或者每周的工作流程。
  • 需要前后端開發(fā)的共同參與,這樣我們才能明確什么時候設(shè)計被視為“完成”。因為,對于我們來說設(shè)計是也不斷優(yōu)化的,永遠沒有完結(jié)的時候,但是與前后端開發(fā)進行討論后,我們至少可以知道設(shè)計達到一種什么程度可以稱為“就緒”,也就是他們可以以此作為輸入開展自己的開發(fā)工作。
  • 需要產(chǎn)品管理團隊共同參與,這樣我們才能知道待解決問題的優(yōu)先級,以及用性測試和UX評審。產(chǎn)品管理團隊關(guān)注整個工作流程的其中一部分,并且也希望多多參與這些任務的討論。
  • 將整理好的流程放到Wiki上是很有必要的,但是并不是僅此而已。你還需要不斷的對相關(guān)關(guān)系人進行流程的宣講,發(fā)送一些博客、電子郵件,以及在一些非正式的場合進行宣傳。對新的跨職能團隊的成員以及一些會議上進行宣講。

結(jié)語

如果你還沒有整理或者文檔化你們團隊的工作流程,我強烈建議你開始整理。你可能會覺得我們現(xiàn)在的工作模式挺好的,雖然沒有整理或者有成文的工作流程,但是也差不多是我描述的這種工作流程。但是通過整理和文檔化工作流程會讓你發(fā)現(xiàn)一些以前沒有注意到的問題或者你以為達成一致而每個人理解不一樣的地方。

把所有人都召集起來過一遍你的工作流程。大家都可以利用便利貼進行發(fā)言,提出自己的見解。在每個迭代后進行回顧,找出哪些工作正常運轉(zhuǎn),哪些存在問題。在此基礎(chǔ)上迭代優(yōu)化你的工作流程。

最后,不斷的在整個公司宣講你的工作流程。不要指望其他人會問你:“你們的工作流程是怎樣噠?”宣傳你們的工作流程,這是你的工作。

 

譯者:小婧,一名行走在實踐路上的資深業(yè)務分析師(BA),個人公眾號:與小婧同行 (xiaojing-jessieyj)。

原文地址:https://blog.usejournal.com/how-we-design-enterprise-software-916124fb73db

本文系人人都是產(chǎn)品經(jīng)理翻譯團隊@小婧 翻譯,未經(jīng)本站允許,禁止轉(zhuǎn)載。

題圖來自unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 來個項目經(jīng)理,都搞定了。

    來自北京 回復
    1. 項目經(jīng)理不負責設(shè)計。。。。

      來自江蘇 回復
  2. 受益匪淺,反思自己的項目進度流程就是缺少規(guī)范化。
    最近我在參與企業(yè)級業(yè)務項目。我在網(wǎng)上找了很多好看,華麗的模板。但發(fā)現(xiàn)一問題,用戶對象是傳統(tǒng)行業(yè)從業(yè)人員,他們?nèi)粘J褂玫碾娔X基本處于windows xp 或者win 7,用戶使用最多的是低版本IE或者360瀏覽器。最終實現(xiàn)效果確實“沒那么好看” 23333

    來自廣東 回復
    1. 在國內(nèi),有很多的流程都流于形式了。其實,在企業(yè)級的軟件中,業(yè)務流程和業(yè)務邏輯會更加復雜,也會更加重視一些。對于使用“老舊”的操作系統(tǒng)和瀏覽器,這是屬于在項目初期需要定義在“約束”里面的。特別是低版本的IE,有很多兼容性的問題,也有很多性能問題。對于這樣的情況,我很少提供高保真的原型給用戶,這樣會提高用戶期望,造成后續(xù)溝通的障礙。

      來自江蘇 回復