怎樣做成一個包辦所有對企政策的城市平臺？本文為大家展示的是作者設(shè)計的這個里程碑版本中的主流程。

它是容納了一個城市所有政府對企政策的平臺，它的非正式代號是“城市主站”。它的定位是：只要這個平臺部署在某個城市，那么這個城市的所有企業(yè)，就能從各種五花八門的政府機構(gòu)平臺中得到解放。

企業(yè)不再需要尋找各種政府平臺的網(wǎng)址，尋找某種政策，然后尋找那個政策的相關(guān)文件和附件，然后再想辦法搞清楚需要提交的材料，以及每個材料的填寫與裝訂要求，然后再弄清楚辦理的流程……對于城市主站所降臨的城市，一切都不需要企業(yè)自己去操心了。一切都被規(guī)范化，可以被一站式解決，這就是我所在的公司以及我個人設(shè)計這個平臺的初衷。

這里為你展示的是MPV版本初階里程碑。雖然我所在公司已經(jīng)運營了很多政府的很多業(yè)務(wù)，但是我們顯然無法一次性說服一個城市的所有政府部門都按照新的要求來對接全部業(yè)務(wù)。而對于一個SAAS平臺來講，用戶看不到的業(yè)務(wù)對接工作占據(jù)了開發(fā)量的90%——我們得先做出成績，讓各個部門都看到我們的平臺確實較受企業(yè)的歡迎。

這里為你展示的是這個里程碑版本中的主流程。我所在公司的完整的政務(wù)系統(tǒng)中，需要對接這個主流程的平臺還有：線上表單系統(tǒng)、總庫系統(tǒng)、政策匹配系統(tǒng)、線下辦理OA系統(tǒng)……由于那些系統(tǒng)相對獨立，我將在以后另外介紹。

單位小站

一個城市會有直轄部門，也有各個行政區(qū)之下的部門。這些部門自己會頒發(fā)一些對企政策，同時它們可能還有旗下部門、旗下部門的旗下部門……它們都有可能會直接對企業(yè)開放一些政策。

因此，我們必須用獨立的“單位小站”，加上弱關(guān)聯(lián)來設(shè)計這個平臺。所謂單位小站，是指只要一個單位可以提供政策給企業(yè)，我就平等地視你為大平臺中的一個子站點，因為服務(wù)沒有大小之分。

而所謂弱關(guān)聯(lián)，是指不同的單位小站也許級別不同，或者其中一些單位從屬于另一些單位——這之中的關(guān)聯(lián)可以隨時修改，并不影響小站本身。

單位小站是政策的發(fā)布者和執(zhí)行者，只有讓它們獨立運營、自負盈虧，才能充分利用人性，給企業(yè)帶來最好的體驗。

單位小站是全網(wǎng)內(nèi)容的主要提供者，但它不是我們期待用戶去主動訪問的地方，它更像一個wiki式的資料站，它是信息的來源但不是推薦用戶玩耍之地。所以我在這里用了窄頭部、灰底、緊湊布局的設(shè)計。

整個平臺所有的頁面分為兩種大的設(shè)計基調(diào)，一種是大頭部、白色底、大留白的設(shè)計，代表鼓勵用戶探索；另一種則是單位子站這樣的wiki式設(shè)計。這些原型設(shè)計不規(guī)定UI最終的外觀，只為了向設(shè)計師傳遞調(diào)性。

政策，安靜地呆在單位小站的某個最終分類里，平臺的所有政策都來自這種地方。每個單位都有一套自己的政策分類手段，平臺應(yīng)該盡可能地符合政府人員的文書工作流程。因此，政策的分類可以自由向下延展，也不要求層級數(shù)量的對稱。

錨定于wiki式的子站設(shè)計原則，子分類無需配置任何額外的信息，例如描述或配圖。這是個只專注于服務(wù)企業(yè)的平臺，不應(yīng)畫蛇添足，額外支配各單位政府職員的運營精力。

處于中間層級時（上半圖），路徑下面呈現(xiàn)子層級，提示用戶繼續(xù)往下走。路徑和子層級之間我嘗試過用分割線來區(qū)分，也嘗試過用箭頭來暗示它們的從屬關(guān)系，但都沒有“繼續(xù)深入…”這個標題來得簡潔，而后2×2種目錄底框樣式可以繼續(xù)抵消掉大多不必要的設(shè)計元素。

不論是最高層級、中間層級還是最終層級，每個層級的政策分類都可以儲存“指南”。指南可以是這層分類的指導精神、辦理須知、問答……具體的設(shè)計會在下文“萬物皆論壇”中詳解。

政策

曲徑通幽處，就是最終的政策，某個單位小站某個最終分類下的某個政策。由于政策是整個平臺最實在的一個東西，所以我也用最大的篇幅來介紹它的細節(jié)。

我們對全國各政府平臺、各種形式的政策已經(jīng)研究幾年了。遇到過鏈接帶你各處跳轉(zhuǎn)的政策，遇到過看到一半突然沒有下文的政策。

有些平臺的政策只有一篇正文，企業(yè)根本不知道下一步該做什么；而做的好一些的平臺中，花多一些力氣，在各種不同朝代裝修風格的頁面之間進行網(wǎng)上沖浪，興許能找到申報指南、申請表格下載、材料裝訂指南，以及最終的辦理渠道——得益于這么久以來的歸納，政策的數(shù)據(jù)模型設(shè)計并未耗費太大的力氣。

在政策主頁的排版風格上，我采用了大量的留白和靠左對齊。在無線框風格中，“把右邊空出來”是web頁面相對于移動端最需要體現(xiàn)的差異。

一個政策具有二重身份，除了屬于某個單位小站的分類之外，還會屬于某個城市分類（會在下文“融合與升華”中介紹），所以需要政策主頁需要二重導航。如果將導航放在紅色區(qū)域，會產(chǎn)生體驗上的困惑，因為主站和小站有從屬關(guān)系，而導航跟在后面則暗示了它從屬于小站。因此導航只能放置在藍綠色區(qū)域，而這又會增加一行元素。

為了節(jié)省元素，我將一個政策所屬的城市分類（1）和小站分類（2）放置在政策頭部信息的右邊，這暗示了它們都是一個政策最高級別的信息，因此我不必再強調(diào)它們代表這個政策的路徑。而導航中的首頁入口（1）和子站入口（2）恰好對應(yīng)了路徑的上一層——于是我用最少的元素實現(xiàn)了導航的邏輯完備。

一個政策能看和能辦是兩回事。政策任何時候都可以看，但只有當這個政策屬于一個進行中的申報批次時，它才能夠進行實際的申請（會在下文“批次”中闡述）。因此我把批次信息和辦理通道融合為同一個模塊。

一個政策也許會被頒發(fā)機構(gòu)拆分成幾個可以獨立辦理的款項。不同的款項對應(yīng)著不同的主體（例如外資企業(yè)、孵化器），有著不同的要求（例如年營業(yè)額2000萬、博士人數(shù)20以上），而“政策計算器”可以通過答題的形式，幫助企業(yè)快速過濾出符合辦理條件的款項，并且計算出具體可以獲得的資助金額（假設(shè)資助類型為金錢）。

我在設(shè)計上使用了大量的“省錢”方法，見下圖——

1. 用戶使用了政策計算器之后，符合申報條件的款項直接變藍變寬，右邊增加一個小小的負形對號，這樣就無需額外增加一個“符合辦理條件”之類的標記；
2. 在整個平臺中，所有潛在的、還未確認可以獲得的“實惠”，都用橙色來表示；這樣就跟藍色所代表的，企業(yè)可以“歸為己有”的實惠區(qū)分開了——橙色代表欲望，而藍色代表自我。由于已經(jīng)用顏色跟前面的黑字區(qū)分開，所以就省去了用各種icon來代表不同類型的獎勵（例如有最高值無最低值的金額、資質(zhì)認證），直接用文案來體現(xiàn)其差異；
3. “孵化器”代表誰能申請這個款項，而后面的兩個描述則是具體的要求。一開始我同時使用了縮進和起始符這兩種元素，但后來發(fā)現(xiàn)只用圓形的深淺就可以完整表達這種從屬關(guān)系；
4. 符合辦理條件的款項下方展示針對具體用戶情況的運算摘要。我可以老老實實把他們框起來，然后再標上“運算摘要”四個大字。但由于使用了代表自我（見條目2）的藍色，所以視覺上直接把用戶從上到下引導過來，讓人從潛意識直接認清它們的關(guān)系。

對于政策正文部分，我在后臺強制規(guī)定成了Markdown格式，不是為了美感，而是為了防止各單位的人圖省事：全選、復(fù)制、粘貼，帶進來各種不必要的噪音。

正文區(qū)域盡量縮窄是為了閱讀的舒適。我一開始覺得右邊光禿禿的不好看，想要把一些模塊擺在右邊，但是這帶來了一個嚴重的問題——交互的復(fù)雜性，如下圖——

在交互方案1中，政策正文和右邊拿來湊數(shù)的模塊都可以獨立滑動，但是滑動區(qū)域不占據(jù)整個屏幕。

• 首先，用戶的鼠標必須尷尬而不失精準地，與我所標注的6個“尷尬區(qū)”保持距離，否則就滑動了整個頁面。
• 其次，當你滑到開頭或者結(jié)尾的時候，必須特別小心地放慢滾輪，否則就頁面就會“呲”出去。對于使用蘋果鼠標、無極滾輪或觸控板的朋友來講，此種設(shè)計尤為無情。

在交互方案2種，兩個滑動區(qū)域共同撐滿了整個屏幕，也就是進入了全屏模式。

首先，我們?nèi)绾芜M入這種全屏模式？無疑要靠吸附。吸附的效果是酷炫的，它占據(jù)用戶精力的指數(shù)也跟酷炫成正比。

其次，當用戶進入全屏模式后，如何逃離？假設(shè)滑動到開頭或結(jié)尾才能逃離，那么就陷入了方案1的麻煩，頁面容易“呲”出去；假設(shè)我增加上下各一個逃離按鈕……那么這個頁面實在是為了酷炫而向用戶索取太多。

不知何時起，變幻不定的人機交互已經(jīng)成為一種潮流，很多時候并不考慮別人用起來是不是真的舒服。以上兩種交互方案讓用戶對操縱鼠標滾輪的自信大大降低，從閑庭散步變成雨天開車，所以我把它們統(tǒng)稱為“腳底抹油”式交互。

繼續(xù)往下滑動就來到了這個政策的指南展示區(qū)。上半部分展示了這個政策的“獨有指南”，最右邊是前往指南專區(qū)的入口，可以查看這個政策的全部指南。不論數(shù)量有多少，凡是標記為“配套文件”的指南都會直接在這里堆積它的入口，因為它們很重要。例如：對于《留學生創(chuàng)業(yè)補助》這個政策來說，顯然《留學生資質(zhì)認定流程》會標記為“配套文件”并直接展示在這里。

而展示區(qū)的下半部分則是從這個政策的所有上級分類中繼承下來的“配套文件”。例如：政府人員小明為《孵化器房租補助》這個政策撰寫了一篇名為《申請房租補助所需的認定文件獲取方式集合》的指南，然后小明發(fā)現(xiàn)，《孵化器房租補助》這個政策屬于“科技載體類房租補助”分類，而后者又屬于“企業(yè)用地資助”這個分類。

——此時，小明只需把剛寫好的指南移動到“企業(yè)用地資助”這個分類里，并設(shè)為“配套文件”，那么這個分類下的所有子分類下的一共30個政策，都會在它們的頁面展示這個指南。每個需要看到這篇指南的政策都無法避開它的輻射，正如同穿上淘寶賣的“引力波防護服”無法讓一個人原地升天。

最后是企業(yè)決定申請這個政策時所需要準備的材料。你會注意到每個材料僅僅由一個標題、一段描述和若干個標簽組成。是因為我無視了企業(yè)整理材料時面對的排山倒海的痛苦嗎？恰恰相反，每個材料右側(cè)都可以通往專門為它開辟的一整個專區(qū)，這將在“萬物皆論壇”中詳細闡述。

批次

剛才介紹了一個政策的主要構(gòu)成，例如它含有哪些款項、它的正文、它的相關(guān)文件、它所需要準備的材料……這些都是一個政策的靜態(tài)構(gòu)成，特點是不會隨著時間而變化。從時間的角度來看，它確實會變化，但原因不是時間本身。然而有些東西確實會隨時間直接變化，這個動態(tài)的部分就是這個政策所屬的“辦理批次”，簡稱批次。

對于大多數(shù)政策而言，企業(yè)不是什么時候高興就能什么時候申請的。例如：政府單位A擁有15個科技企業(yè)相關(guān)的政策，打算今年1月份接收企業(yè)的申請，2月份集中審核，3月份集中公示，然后在4月份統(tǒng)一放款。此時，我們把這整個流程配置為“2020年政府單位A科技類政策申報”批次。然后把這15個政策放入批次中，那么用戶只要在其中任一個政策里點擊申請，都可以自動加入這個流程。

歲月如梭，一個回車就來到了2021年。這一年政府單位A還想再處理一批科技類的申請。15個政策本身沒有發(fā)生任何變化，只是辦理的時間變成了第二年，辦理的過程稍有改變。于是，單位A制作了第二個批次：“2021年政府單位A科技類政策申報”，然后直接把去年的15個政策扔了進來，無需對這些政策本身做任何的調(diào)整。

批次分為“常駐型”和“時效型”，現(xiàn)實中大多數(shù)都是后者。一個批次會劃分成不同的環(huán)節(jié)，對于時效型批次來講，這些環(huán)節(jié)是嚴格按照時間來進行的，同時每個環(huán)節(jié)可能對應(yīng)著不同的辦理地點和聯(lián)系人。

在MVP版本中，所有的環(huán)節(jié)都是“自定義類”的，而未來只要加入其它環(huán)節(jié)類型，就可以帶動系統(tǒng)進行特定的任務(wù)。例如，當線上申請徹底打通后，“線上申請類”環(huán)節(jié)就可以被加入批次中，系統(tǒng)將會自動按照時間來開放線上申請的窗口，并在時間結(jié)束后自動把數(shù)據(jù)提交給“線上審核類”環(huán)節(jié)所指定的政府OA系統(tǒng)。

政府人員在后臺進行批次的配置時，由于批次的上下線會涉及到流程的啟動和終止，以及用戶申請狀態(tài)的變更，所以設(shè)計了一些限制。后臺人員同樣需要用戶體驗，所以在配置過程中也設(shè)計了一些捷徑。點開上面這個文檔截圖就可以大致了解。

你可以發(fā)現(xiàn)，批次頁面也存在著跟政策頁面一樣的指南展示區(qū)。用戶對辦理流程有什么疑問，都可以在這里找到或索取解答。我在前文已經(jīng)多次涉及到“萬物皆論壇”的概念，下面就來闡述它如何用偷懶到令人發(fā)指的運營方式，來化解企業(yè)申請政策時遇到的任何困難。

萬物皆論壇

我曾被一個HR打過一個謎之標簽：“只有政府OA系統(tǒng)的產(chǎn)品經(jīng)驗，因此不符合園區(qū)管理系統(tǒng)的經(jīng)驗要求“。因為愛吃精神快餐，所以愛打標簽。因為愛打標簽，所以我們往往放大了不同產(chǎn)品的差異，也小看了同類產(chǎn)品的差異。

斗魚和Twitch都是直播平臺，而Youtube是視頻網(wǎng)站。但是斗魚和Twitch之間的差異，要遠遠大于Twich和Youtube之間的差異。

• 看起來都能在直播間贈送禮物，但一個是圍繞著“送禮”這個主題來設(shè)計整個直播間，其中包括各種爆炸性的特效和分區(qū)聯(lián)動，而另一個只是在聊天文字里加多了一些付費表情；
• 看起來每個主播都能展示實時的熱度，但一個需要先考慮這個主播有無簽約，分成幾幾開，運營小編給了這個主播多少加成，送禮數(shù)量是多少，有沒有“皇帝”給這個主播打榜，然后再進行綜合運算，而另一個只是簡單地統(tǒng)計一下真實在線的人數(shù)——去掉了“直播平臺”這個標簽之后我們可以發(fā)現(xiàn)，斗魚是一個經(jīng)紀人公司運營平臺，而Twitch則是一個延遲較低的視頻網(wǎng)站。

如果帶著“政策申請平臺”這個標簽來設(shè)計這個產(chǎn)品，那么我很容易被競品和套路帶偏。當我設(shè)計政策模塊時，我會想著：我們需要問答模塊、需要專家解讀政策、需要展現(xiàn)政府的文件……當我設(shè)計批次模塊時，我又會想著：我們需要辦理指引、需要執(zhí)勤人員時間表、需要材料攜帶須知……但是，隨著我把腦子里“政策申請平臺”這塊牌匾踢爛之后，我發(fā)現(xiàn)了兩個定理——

• 定理①，互通——所有這些模塊，都是在不同場景下對企業(yè)進行指引；
• 定理②，同質(zhì)——所有這些指引，只有重要和不重要的區(qū)別。

在一個單位里，各個級別的政策分類（詳見前文“政策”）需要放置一些指導性文件，具體每個政策也需要一些指導性文件，政策中的每個材料都可能需要一些辦理教程（材料有通用型的，它們共享一個指南專區(qū)），具體的辦理批次可能需要一些流程指引、交通與時間指南——系統(tǒng)都會逐個地、自動地為它們生成獨立的指南專區(qū)。

在后臺中，不同層級的專區(qū)之間是沒有等級之分的，內(nèi)容可以自由轉(zhuǎn)移，我在前文“政策”中已經(jīng)提到了這個例子——當政府人員為某個政策撰寫了一篇說明或回答了一個問題，而后發(fā)現(xiàn)這個指南遠不止服務(wù)于這個政策。那么只要把它從這個具體的“政策指南專區(qū)”移動到某個具體的“政策分類指南專區(qū)”就搞定了。

在不同類型的專區(qū)之間，內(nèi)容依舊可以自由轉(zhuǎn)移。例如政府人員收到了來自十幾個政策的關(guān)于同一個材料裝訂要求的提問（因為材料說明可以設(shè)為通用），于是撰寫了一篇裝訂說明，并把它放在這個材料說明的“通用材料統(tǒng)一要求指南專區(qū)”中。結(jié)果他發(fā)現(xiàn)，這個裝訂說明其實不來源于這些材料本身的要求，而是因為某個辦理批次在流程上要求這樣做。所以，他就把這篇說明轉(zhuǎn)移到了那個批次的“批次指南專區(qū)”中了。

隨著這樣的不斷轉(zhuǎn)移和歸納，政府人員會發(fā)現(xiàn)內(nèi)容越寫越少，整個單位小站越來越不需要運營，而不是越來越忙。以上是對定理①“互通”的實施。

不論是何種類型的專區(qū)，對于具體的一個指南而言，整個后臺永遠只存在一個通用指南模型。啟用其中的不同模塊，就構(gòu)成了不同場景下的不同指南。

例如，當某個政策分類中需要張貼一個指導文件，或某個批次需要告訴用戶辦理須知時，只需要啟用圖文模塊（MVP版本直接使用Markdown）來寫一篇富文本指南；當某個材料需要用戶自己打印時，啟用附件模塊，把模板和樣板文件一并放入指南；而當回答用戶在某個政策中的提問時，只需要把文章標題模塊替換成問題引用模塊，就可以把這個指南轉(zhuǎn)換成問答形式。

撰寫指南的后臺界面嚴格遵循賽博朋克綱領(lǐng)——功能健全下，看似分崩離析的實用主義。未來的指南遇到瓶頸需要增加功能模塊時，直接暴力插入一個新的標簽頁，不影響原有模塊的代碼，哪怕是前端的代碼。每個模塊的功能越單一越好，只有當數(shù)據(jù)進入用戶端，才需要考慮怎樣讓不同元素融合在一起。

例如，正文里是禁止穿插附件的，兩個模塊必須分開。否則，未來再開發(fā)任何可以在正文里穿插的元素，都必須重新編寫圖文編輯器的代碼——從圖靈以來，這種耦合的思維模式創(chuàng)造了產(chǎn)品經(jīng)理與開發(fā)者之間90%的矛盾，也在此刻某個時區(qū)繼續(xù)發(fā)生著。

最后，當政府人員維護好了各個指南專區(qū)的內(nèi)容，并把其中重要的指南打好標簽，那么這些信息就會自動出現(xiàn)在它應(yīng)該出現(xiàn)的地方，以它應(yīng)具備的重要性來呈現(xiàn)。用戶是看不到任何指南專區(qū)目錄的，因為當用戶真正需要進入某個指南專區(qū)時，用戶總能遇到它——以上是對定理②“同質(zhì)”的實施。

融合與升華

整個城市主站最主要的運營思路是阿米巴經(jīng)營。前面幾章談?wù)摰亩际且粋€單位小站的內(nèi)部情況，而只要每個政府職能機構(gòu)的工作人員都盡量地維護好自己的小站，那么這座城市的幾十個、上百個小站最終融合在一起，就能實現(xiàn)政府服務(wù)的質(zhì)能轉(zhuǎn)換。

企業(yè)無所謂一個政策是哪個單位發(fā)布的，企業(yè)只關(guān)心自己要找哪一類的政策，最后能不能拿到這筆錢，而“城市分類”就是這樣的所在。這里是全平臺內(nèi)容的最終爆發(fā)點。主站的專業(yè)運營人員統(tǒng)一管理，把所有小站的所有政策打亂，并重組到各個主題之下。

上圖所示的MVP版本只設(shè)計了搜索功能，不過這不影響我把這里定為未來所有搜尋政策功能的匯集點。與政策在具體單位小站的實際分類不同，城市分類只有單層結(jié)構(gòu)，用戶在首頁只需一次跳轉(zhuǎn)就可以進入一個主題。

在下一版，上圖（UI也是我畫的，其中右下圖高度借鑒了Behance設(shè)計師Vladimir Ulyanov）所示的小程序政策計算功能會改造成通用性更廣的SAAS產(chǎn)品，同時在進行的還有與華為AI對話團隊的合作——這些功能都將融合在城市分類頁面里，幫企業(yè)更快更準地尋找政策。

其中政策計算功能對應(yīng)了一個很復(fù)雜的后臺系統(tǒng)，只有后臺邏輯夠復(fù)雜，才能讓企業(yè)從最短的操作里找到最適合自己的政策，并計算出最接近事實的放款額度。它也屬于城市主站的一部分，我會另起一篇文章單獨介紹。

最終，這些內(nèi)容注入首頁。

首頁在原型設(shè)計時經(jīng)歷了十幾次改版。雖然模塊也不算多，但是無線框設(shè)計真的是靠工作量堆出來的。剛開始的設(shè)計稿使用了大量的標題、分割線和色塊，隨著我逐個地完善不同模塊的視覺差異，這些噪音也越來越少，直到形成一個比較正規(guī)的無線框設(shè)計。

其中我最滿意的簡化方式是上面這個版塊。這個版塊展示來自各個單位小站的最新內(nèi)容，根據(jù)類型分成了三個小模塊。

1. 在小模塊的劃分上，一開始我采用小標題（左），后來修改了三個小模塊的入口大小（右），直接在視覺上分割了模塊。其中第一和第三模塊已經(jīng)被隔開了，所以再把它倆的大小重新統(tǒng)一，進一步縮減視覺元素；
2. 去掉了標題之后，用戶可能不知道那些入口代表什么，所以把前往“更多”的鏈接擺在結(jié)尾，這個鏈接的線框跟前面的入口保持一致，只修改了內(nèi)部的元素，然后直接用文案（例如“最新政策”）來暗示前面入口的類型；
3. 最后，用中間一排沒有鋪滿畫面的入口實現(xiàn)了無線框設(shè)計中經(jīng)典的“左邊對齊，右邊不定期留白”的效果。

另外我也對通常的短信登錄窗進行了一些改進。在1處，我把文本框激活狀態(tài)做成了一個豎條，這樣就不會對登錄窗的主要操作區(qū)域造成分割；在2處，倒計時的提示結(jié)束后變成回到上一步的按鈕，把前端的鎖（例如接收驗證碼的倒計時、修改手機號的倒計時）集合為一體。

日程

最后當企業(yè)確定辦理一個政策時，這個政策就會進入他的日程。

由于多個政策可能共享一個申請批次，可以一起辦理，所以如你所見，在左側(cè)的政策列表中，若干個政策被某種顏色的色帶串聯(lián)起來，對應(yīng)著右側(cè)日歷中某種顏色的格子。日歷格子的顏色反映了那一天的狀態(tài)，灰色格子代表過去，第一個白色或上色的格子代表現(xiàn)在，后面其余的格子代表未來。

一個批次占用一個色卡，前端備有五種左右的色卡供系統(tǒng)選擇。循環(huán)到第二輪導致不同批次顏色相同的可能性很低，也沒有什么大礙，因為還有交互。

由于一個批次可能會出現(xiàn)多個環(huán)節(jié)，所以該顏色在日歷中的連續(xù)出現(xiàn)也可能超過一次，但是只有正在發(fā)生或即將進行的環(huán)節(jié)，顏色才體現(xiàn)為實色。在色卡中，不同顏色之間存在飽和度的差異，作為底色時跟白色字之間的對比度也存在差異，不能用固定的參數(shù)直接變色，所以色卡的每個顏色都對應(yīng)著不同用途的若干具體色號。

點擊某個政策后，頁面就進入了“政策模式”。日歷只會展示跟這個政策有關(guān)的日期，在中間擠出來的材料清單里，用戶可以記錄自己的材料準備狀態(tài)，和快速跳轉(zhuǎn)到任何細節(jié)之中。

你可以發(fā)現(xiàn)此時日歷格子才是正方形的，而前文“全局模式”的格子反而是被拉寬的，因為政策模式才是日程頁面的主體。當用戶進入日程時，前端先假設(shè)界面是三欄式的，并根據(jù)瀏覽器寬度計算出格子的高度，然后再將它拉寬，以便適應(yīng)初始的全局模式。

日程是典型的單頁應(yīng)用，整體的布局會變化，每個模塊也會有大大小小的變化。用通常Axure制作場景的方法來設(shè)計它會導致窮舉，而如果使用面向?qū)ο蟮脑O(shè)計方法，只需要兩個步驟。

第一步，劃分整體布局的狀態(tài)，以及相應(yīng)的區(qū)塊。目前的日程可以劃分成三個布局狀態(tài)，分別是全局模式、普通政策模式，和無批次的政策模式。而區(qū)塊從左上開始被劃分為政策列表、材料清單、日歷導航、日歷以及批次信息。

第二步，把每個區(qū)塊單獨拿出來制作文檔。在每個文檔里列舉這個區(qū)塊的所有狀態(tài)，其中的每一個狀態(tài)都對應(yīng)著第一步所列舉的，一個具體的頁面布局狀態(tài)。

MVP版本的日程功能初步地實現(xiàn)了整個平臺的初衷——企業(yè)只要來我們這個平臺，就可以找到這個城市所有能夠申請的政策，并且能夠按照指引跑通整個流程。

• 首先，即使這個城市有一部分政府單位還沒開始合作，我們在日程中至少可以提供政策的全部內(nèi)容、線上辦理的鏈接（若存在線上環(huán)節(jié)）、線下辦理的流程指引，和所需準備的全部材料的細節(jié)；
• 其次，如果相關(guān)單位愿意自行運營自己的小站，那么相關(guān)內(nèi)容就會更加準確；
• 最后，如果它們提供了數(shù)據(jù)接口，那么在日程中用戶就可以直接看到自己的辦理狀態(tài)，并且可以直接授權(quán)跳轉(zhuǎn)進去，無需記住各種賬號。

日程模塊的下一步目標是把線上申報系統(tǒng)（我會另起文章介紹）和線下政府審批OA系統(tǒng)完整對接進來，實現(xiàn)這個平臺的一條龍政策辦理。

而整個平臺最終目標是把總庫系統(tǒng)也對接進來?？値欤ㄎ視砥鹞恼陆榻B）是一個能夠?qū)崿F(xiàn)全平臺數(shù)據(jù)互通的系統(tǒng)，企業(yè)在任意一個場景里提交了任何信息，都會通過總庫共享給其它任意場景。

企業(yè)上一次在城市主站里提交了A單位的申請，下次再進入平臺時，平臺會告訴企業(yè)：“你在B單位大概可以獲得300萬元的資助”。企業(yè)點擊進去，對所需數(shù)據(jù)稍加補充，就能在5分鐘后提交申請，然后足不出戶獲得300萬元的政府獎勵。

當然，這是一個艱難的終極目標。它需要的不光是平臺本身的努力，也需要政府提供的大量支援，包括取消各種繁瑣的線下流程，包括把所有OA系統(tǒng)對接在一起，包括不同地區(qū)的不同部門都能傾力合作，但重要的是——它也許正等待著我們的努力。

作者：黃聯(lián)樵，微信：arubagod

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

題圖來自Unsplash，基于CC0協(xié)議