目前為止，我發現大部分市面上的文章都在告訴大家，競品分析怎么做、場景分析怎么做、體驗地圖怎么做、訪談怎么做、度量模型怎么做，但唯獨少了最后落地方案怎么做。
我曾經試著利用迪士尼和環球影城的兩個案例來優化他們的產品，但是很多人開始無腦噴，因為沒有業務做背景，別人想怎么說怎么說，都是“我覺得”。正因為這樣，市面上你幾乎看不到有什么文章教大家實際的交互解決方案，因為怕被噴子噴，反正沒有業務背景你也無法論證自己方案的合理性，靠經驗？別人不認同，你也沒有數據來說服別人，所以這事大家都不敢去做。
但是沒有業務背景的交互方案就不能做了嗎？當然不是，有了業務背景你可以更針對性的選擇你自己知識庫里的方案和頁面結構來解決業務和用戶的問題，那么前提是你的知識庫里有那么多案例才行，否則有再多再清晰的業務背景，你掏不出來，沒有用。
所以從今天開始，我會陸續提供一些咱們小伙伴在做練習時候遇到的一些交互問題，大家一起來探討一下。業務背景會適當的提到，但是還是以交互方案的多樣性為主去討論，再強調一遍，不要揪著業務去框住自己的思維。
學習交互也好，學習UI也罷，如果你完全不懂理論是行不通的，所以很多剛入行的小伙伴基礎不夠扎實，覺得理論沒用，這是不對的，理論有用但是也配合實踐，利用更多的實際案例去加深理論的印象，做到舉一反三，這樣的效果比較好。所以在做案例之前大家務必也要多去了解一下交互的設計理論和基礎指南。
今天練習的主題是：籃球館預定流程和原型
其實以前有文章聊到過，但是大家都有不同的聲音，那么我們就繼續來探討一下有哪些不同的方案。既然業務背景不確定，那么我們的交互方案就不存在最優解。
案例
下文描述以圖片順序做記號，例如第一張界面即為p1。
產品功能為什么這么布局、為什么用這個控件、為什么用這個交互形式，取決于業務目標和設計目標，還有用戶的心智模型，以及該單元本身的屬性。那么首先來看案例1-p1，該練習的背景沒有描述業務特征，所以這個布局說明，該產品是一個平臺型的產品，有各種球館的列表，除了細節不完整以外沒啥大的問題。
再看p2和p3這兩個頁面是這個練習的核心頁面，我們總說產品形態取決于產品本身的定位，平臺型產品的球館詳情大致是可以這樣的，如果產品是自我品牌的產品，那么形態就會發生很大的變化。例如你可以在美團上點星巴克，你也可以在星巴克小程序上下單，但是這兩個應用中的星巴克，是不一樣的內容呈現。
我們從p2依次往下看，從業務和用戶兩個角度來看這個方案，首先從業務的角度看，有問題的點在于場地說明，平臺型的產品一般都會給商家做管理后臺和營銷工具，但是場地說明這個板塊就有點雞肋了，
原因1: 大部分球館的標準都是統一的，不可能一塊木地板一塊pvc這樣錯開，很難看，也不可能。如果有區別那么只有尺寸規格的區別。
原因2：場地類型展示并不是核心用戶需求，只是一種輔助決策，并且是“一次性”決策，該流程的核心任務還是要讓用戶可以去預定場地，但是目前整個頁面只有底部一個預定的按鈕（等會說這個按鈕）
原因3: 頁面頂部有場館的圖片及環境介紹了，所以場地圖片展示可以集中在頂部的圖片區域展示，例如大眾點評，點開后會有更多分類的圖片和視頻標簽。
所以中間這塊區域可以展示快捷預定的入口，比單純展示場地類型性價比高的多。
那么底部是否需要有一個立即預定的按鈕呢？如果這個產品是一個專門用來給籃球館做推廣的平臺，我覺得可以放。但如果是類似大眾點評這樣的平臺的話，就要繼續思考了。
而我們看到大眾點評為什么底部不做成一個大按鈕的形式，豈不是會更加強化這個任務的核心目標嗎？平臺類型的產品對接商家的種類非常多，同時類似這樣的平臺產品核心的產品定位是給幫助用戶去找到好吃、好玩、好看的地方，側重的是真實用戶反饋，所以說到真實用戶反饋這里再舉個小例子，大眾點評在評價的時候當點擊第五顆星的時候是顯示4.5星，而不會直接顯示5星，要再次點擊后才會變成5星。
產品認為為了快速點擊5星好評的行為并不是真實反饋，當真實想要給5星的時候才會再操作一步（題外話）。
回正題，平臺型的產品定位是為了把所有商家和用戶進行高效的匹配（花錢匹配度、曝光更高），而不是為某一個商家去做轉化。并且使用該產品的用戶場景和需求比較豐富，大部分用戶都只是來看看這些場所的評分、口碑和詳情。
所以底部就不會只放一個預定/買單的大按鈕，而改成了用戶反饋的相關功能。為了幫助商家做銷售，營銷管理工具做的還是很成熟的，什么拼團啦、套餐啦、代金券的工具啦等等。
有同學會問，那不就是大眾點評嘛，有什么區別。首先不要為了不同而不同，為了創新而創新，如果有更優秀的解決方案當然是最好了，但在當下的環境中，沒有什么必要。如果一定要做差異化，一定是業務訴求出現了。比如這個產品變成了自有品牌做的一個app/小程序，而不再是靠平臺幫我去宣傳籃球場地，那么會變成什么樣呢？
那我們可以想到的時候在預約入口的地方就會發生了變化（同星巴克），平臺通過列表進入，而自有產品則是在產品首頁中放一個入口，形態也完全改變，首頁不僅僅有場地預定，還會有私教培訓、課程套餐、活動組織等等，圍繞著這個場地衍生出很多的業務。并且像用戶評價這個東西，在自有產品中也變得不那么透明，表現形式肯定也會更加弱化。
所以在本身是平臺的屬性下，這個頁面正常就是這樣，p2缺少了用戶側的一些支線場景和功能的補充，例如咨詢入口、舉報入口等支線的功能。
再看p3，點擊預約入口后開始進行選擇場地的交互，選擇場地需要幾個關鍵要素：1.日期 2.時間 3.場地號 4.場地規格 5.價格，那么這里又涉及到業務背景了，場地號是什么？場地規格又是什么？商家如果要讓別人預定場地，是按照全場預定還是可以半場預定，場地的類型是否有多樣，都會影響到我們這整個預約的交互流程。
p3的這個方案的問題在于：
1.信息關聯度沒做好，這里的日期和時間要更緊密，和買電影票不一樣。
2.時間的交互效率低，并且沒有展示全，可擴展性不好，如果場館早上8點開門怎么辦？商家要求最低2小時起訂或者1小時起訂怎么辦？
3.半場和全場的選擇不夠簡單，全場其實等于兩個半場，而現在的展示形式變成了一個切換按鈕，雖然加了一個箭頭，但是這樣的交互形式和控件的用法是不符合常規的，并且指向性很差，當切換到3/4號場地的時候箭頭就指向了半場，這樣就會產生歧義，所以是不可行的。
所以我們這里就會發現這些信息是需要聯動的，聯動表單最常見的就是橫縱聯合。一般最初級的做法就是一個行為管一個信息，就比如這樣：把選項放入picker中
這種交互方式一般不單獨用，因為其實算是一種樹狀結構，這種結構一般運用在添加收貨地址等完全獨立的信息填寫或者一些多行表單中。
而這里的選擇日期、時間、類型、編號并不完全獨立，而且需要實時查看。
所以這樣也不夠直觀，picker擋住了價格，無法實時查看。更何況在這個頁面中所有內容都收起來版面利用率大幅下降，交互層級更深了。
再看一些其他的方案，難道就一定要選場地嗎？我只需要時間、日期行不行。不行，為什么？
那我們再來看下面這個方案：
這個方案中，同學把圖片加入進來，希望幫助用戶去輔助決策，其實沒必要，之前也說過，圖片屬于認知信息的一部分，在外面認知完了解過就可以了，里面就不需要再展示一遍了，可能也是為了不讓頁面這么空，因為底部用了一個卡片的塊選擇日期時間。但是少了場地類型的選擇（半/全）長，為什么說半全場和場地號一定要選呢？因為有很多場景缺失了，比如你要幫朋友訂另一個場地怎么辦？我要訂兩個半場打全場怎么辦？每次預定只定了時間，老板還要手動標記哪些場地在哪些時間沒有預定，非常的麻煩。所以不選擇場地是不行的。
再來看一個方案：
這個方案的選項和操作過于分散，而一般也不會將需要交互的選項放在左側，有個原則就是內容在上/左，操作在下/右，雖然不能一概而論但大部分情況都要遵循。參考古騰堡圖標原則，左側的日期不經意看以為是一個標題。大部分第一次做交互原型的同學可能都會這樣，一些按鈕和控件的用法和該放、可以放的位置不太清楚，在做交互的時候還有一件事要清楚，就是誰控制誰，控制器怎么觸發。
而這個方案和p3也是一樣，觸點順序亂了：選擇日期-選擇場地類型-選擇場地號-選擇時間。因為預約場地的場景是，今天小王想約朋友去打球，他問了一下朋友哪天有空，朋友說下周六都可以，最好是下午，于是小王打開應用軟件，選擇了下周六的日期和下午的時間，看看還有哪些場地可以預約。
同樣也是順序亂了：場地編號-日期-時間。為什么順序很重要，這就和我們買電影票的習慣一樣，大部分情況是我們想要看某一本電影，然后再考慮自己的時間和去哪個電影院，有人說，我就不一樣，我會先選擇電影院，比如我逛街途中突然想看電影了，再看看電影院最近有什么電影。我只能說，滿足大部分、大概率的用戶需求和場景才是正事，產品是無法滿足全部用戶的。
拋開日期和時間的關聯性，這個方案還有一個問題就是如果要預定多個場地就會比較復雜，例如只有1號場地和9號場地的某一個時間段可以預約，那么就需要用戶在幾個場地中展開收起進行操作，非常繁瑣。
再來看一個案例
這位同學將步驟分為了先通過picker選擇日期和時間，確定后再選擇場地。這個流程問題就在于：
1.picker用的不對，picker雖然叫做選擇器，但往往不會作為一個中間任務承載的模塊去用，而是對于一個頁面中需要選擇一些選項的時候才會用到，選擇完后依然停留在該頁面。否則進入下一個頁面后，再返回，就看不到picker了，還要再選擇一次。
2.場地可能會出現被人預定的情況，所以當選擇日期和時間后再選擇場地，如果被預定了，那么用戶就會比較抓狂。
所以在這個頁面中我們會選擇將其全部展開，怎么展開呢，有人覺的日期時間可以不動，把場地和類型展開。有人覺得全部展開才更直觀，那我們來看這兩個方案
如果日期和時間不展開，會有一個問題，那就是無法選擇多個時間段的場地，只能選擇某個時間段的多個場地，無法滿足這部分用戶需求，并且在信息展示上也會比較擁擠。那么我再看看全部展開，全部展開之后將時間和日期也做一個橫縱形式，然后將半/全場和編號進行結合，默認選擇一個塊即為半場，但是在場地命名上還是需要做一個小心思，那就是如果有人要包全場，如果我們單純給場地編號1、2、3、4….就會讓用戶不知道哪個半場和哪個半場是一體的，所以命名就可以改成1號場A、1號場B…...
當然如果不要編號問題也不大，主要是場地還有些特殊情況，比如不同場地的通風、燈光的區別，所以會有場地編號。
在之前的留言中，也有小伙伴會問，即便是自有產品，用戶在選擇場地的時候到底是否需要再看場地的圖片，直接從入口進來不顯示圖片就讓用戶去定場地合理嗎？這里主要就是分針對老用戶還是新用戶，只要去過一次的用戶基本上也就不需要再看場地圖片了，新用戶的話就需要，他們還需要知道場館的地址、聯系方式等等，所以這些內容會聚合在選擇場館的上一步，也就是首頁，具體首頁可以怎么放這些內容留給大家思考。
我們講到這里，還有一些抬杠冠軍又要說了，一個頁面這么多信息太復雜了，我選擇第一個方案，多簡單，就兩個選項。如果我們知道復雜性守恒定律，那么不管怎么壓縮信息復雜度是不變的，把那么多場地選擇壓縮在一個picker中會更加復雜和難操作。
其實當大家看到這些原型的時候，都明白問題出在哪里，真實情況是，如果讓你們從0開始，一下子就懵逼了。比如預定籃球場地的這個流程，從無到有，如果讓你自己來設計一遍，你可以完整的做下來嗎？每一個細節是否到位。大家產生了一種幻覺，看懂了，等于自己會做。一定一定要腳踏實地去做一遍才知道自己哪里搞懂哪里沒有搞懂。
