｢為什麼換App要重新下載，登入流程又這麼複雜｣上線初期看著App Store上類似的評價，都有種有苦說不出的感覺。
現實面是換了開發商，舊的廠商仍要負責維護、開發舊的App直到新App上線那一天，過程中公司完全沒有人碰過原始碼，也沒有能力驗證程式碼的正確性，更不要說接回來營運、開發一陣子；光想要讓兩個完全不同的開發團隊協作就相當困難，對於舊App的流程跟架構也完全不熟，問營運單位一問三不知。再加上，舊App開發商在上架的時候，直接把公司的名稱放在Package name上面，直到現在仍在其他零售app的Package name上有這樣的情況。訪查了一下其他零售的App有幾間是能夠直接看出開發商的名字，推測應該是開發商是將套裝的軟體依照品牌客戶需求做一定程度的客製上架，不確定在這樣的基礎下，是否可以調整Package name。不過像公司的App從上架、開發者資訊、客戶服務信箱等，都是由品牌方的名稱直接對外，與91App的模式不太相同，這部分牽涉到開發商的營運模式，在這裡就不多談了。
登入的問題起因於公司複雜的會員系統架構，過去有另外一個案子是在做這方面的整合，舊App幾經討論後，直接決定等新App上線再來處理吧，但一等又是一年多了，中間做了一些流程的優化，但仍無法滿足到所有舊用戶的情境，導致重新下載的人，也不一定能使用原本的帳號密碼登入新的App。這幾個問題算是阻礙使用者最大的問題吧，在系統架構龐雜、資訊人員對於系統掌握度低的情況下，只能說這是換系統的必要之惡。
突破了重重關卡，真的下載、開始使用之後，會覺得內容很多，但偶爾會有怎麼找不到那個什麼資訊呀，或是這裡怎麼這樣設計的想法。
你的首頁不是你的首頁
依照公司的業態首頁除了一目了然的會員資訊外，應該要放一些同步零售現場的資訊，串聯線上線下的體驗。從提案到初期產出是這樣規劃的，後來在業務單位的兩個主管私下磋商後，零售端決定將版位給線上端的的內容露出，這部分不算太大的架構變動，只是在提供的資訊價值層級不一樣，一個是讓使用者可以知道熱銷的商品，透過真正的銷售量累積的結果；現行的則是選品，從企業端策展的角度來提供內容。後來，在另一位行銷主管參與一次會議後，首頁架構有了比較大幅度的調整，他的需求基本上是把公司內容網站有的分類架構直接搬到App上，透過加一些Tab來解決這件事，有趣的事情是這位主管既不是內容產出者或是營運單位，後來也離職了，那個版位上線後儼然成為蚊子館，使用者點擊少到以為收集錯了有Bug。
首頁的樣貌是各個事業單位透過像是資源爭奪戰的會議談出來的，少有人在意提供好的內容來提升使用者黏著度，改變過去只有在門市結帳才開啟App的使用場景。
這個功能不能這樣設計？！
聯絡我們不論在網站或是App的設計上，層級都不是最重要的那一層，通常不會放在首頁的位置，網頁上因為有footer的設計，可以常駐在下方，App通常都會收在第二層或第三層的更多資訊底下。甚至有些企業不希望非常容易的被找到。另一方面，公司是一個有實體服務場景的企業，如果有問題可以透過門市反應，再者也有網頁的聯絡客服管道，或是電話可以撥打（非24小時服務），一般人如果真的想要找到公司的客服應該是上網搜尋客服電話，而不是刻意下載App寫客戶意見書，也無法得到即時的回應。然而，在這個功能設計時，權責單位很堅持要單獨拉出來有一個在首頁或是會員專區第一頁就可以找到的位子。經過至少3～5次的討論，最後是找了約10間不同的App才以現在的版本定案。
也有在畫面的前一步驟很清楚的說明接下來的使用情境，設計跟操作動線是按照雙平台的UI design guideline設計，同事反映不夠明顯。反覆的在同一個畫面多次來回討論，忽略整體操作流程及用戶對於手機操作的直覺，增加設計確認溝通的困難度，更有可能因為外行領導內行，影響整體的使用者體驗。
當UX設計遇到系統架構的取捨
在設計確認當下，一直以為只要有資料、技術串接好應該都沒問題。不過與不同系統串接，沒有一個有效的中台做資料過濾或處理，導致過程中偶爾會遇到需要回來調整設計的時候，但比較多的時候是開發端透過各種串接、繞道把問題處理掉。這個過程有點像踩地雷，不知道哪裡會碰到系統限制，為了要達到設計的要求，及公司對於美學的堅持，這部分花了滿多功夫處理。特別是會員專區，超級複雜的會員制度一起做調整跟上線，UX出圖的時候制度同步在內部提案，一路摸著石頭過河，成了最後大家看到的樣子。
另一個例子是內容的呈現，全部用Native開發，為了不被內容網站的設計影響App的體驗跟風格，但最後發現上稿的內容相當多元，有時候要變色、有時要粗體，又有些時候要下錨點或是播放影音，後來把內容主要的區塊改成可以接受html，但在測試時期遇到許多跑版的Bug，讓上稿的同事透過試錯（trial&error）的方式找到最佳上稿方式，並做成規範。如果重新一次來討論，這裡也許會考慮使用webview，可以避免很多問題跟限制。
數位產品的迭代
這個是花最多時間溝通的概念，零售業在過往開店的習慣，一個設計、裝潢做下去，至少要等兩三年才會做下一次的調整，因此養成了在設計的時候要將方方面面都考慮進去，需求盡量提好、提滿。數位產品的設計模式恰恰相反，有較高的調整彈性，在大架構不變的情況下，都能夠做一些微調或伸縮，對於需求的反應能力比較快。
一開始有一版80％的功能先上線，先把滿足用戶跟業務單位認為最重要的功能，後續的20％可以待上線後，透過用戶回饋及業務端的需求，再做調整。Product Roadmap在需求訪談完後，大概已經被加了15項大大小小的新需求，有些小的可以在時間內做完，大的功能或需求有些尚在「概念」階段，需要重新整理業務流程，需要花費大量的時間做需求確認。另一方面，要說服高階主管哪些功能放到後續的階段再執行，需要花許多時間。一來是擔心未來的「擴充彈性」不足，二來是前述的實體設計「一次到位」的概念根深蒂固。在專案管理有一定的目標時程上來說，只能安排後續的時程再進行相關工作。因此，將功能排出權重是相當重要的事情，有助於解決在資源固定的情況下，該專注投入在哪些事情上。
關於數位轉型的專案管理，也有整理了一些我的觀點與感想。
留言列表
