Category Archives: Organic Web Design

OrganicWebDesign

做生意跟做網站

搞 IT 這行一定會碰到技術和需求 (requirement) 相衝突的時候,有些來自業務部門的需求要嘛是天馬行空、不然就是疊床架屋。以技術的角度來說,往往不是做不到,而是值不值得做的問題。

學界訓練技術人材,是教導學生找出好的解答,就算不是最佳解,至少也應該要找出次佳解 (suboptimal solution)。”Dirty-hack” 並不在學校教導的範疇內。即便進入業界,所謂的技術大師也往往是因為能夠提出漂亮的架構或是清楚的系統介面而受到尊敬,而不是因為 “總是能讓一個陳舊的系統還可以運行” 而受人稱道。如果說 MBA 畢業生其實只要學會在一上任就喊 “組織重組” 就可以畢業,那資深系統架構師或許也只需要會 “reboot”, “re-install” 和 “re-architect” 就可以混口飯吃了。

可是偏偏做生意是沒有規則的,需求 (requirement) 是沒有止盡的,永遠會有一個新的生意需要 Dirty hack,永遠會有一個新客戶想要而當初沒考慮到的需求。這也是跟做一個拋棄式的網站最大的不同,因為拋棄式的網站沒有維護的問題、沒有陳年的商業邏輯、沒有新需求注入。

先前我認為好的架構是系統穩定最重要的因素,但後來發現,商業網站的程式碼和商業邏輯是切不開的,並沒有一個架構有辦法讓商業邏輯自成一格。除非做生意的變化種類減少,不然網站的程式複雜度就不可能會減少。一旦邏輯複雜,就只有走向 dirty hack 一途。

某種程度上這也解釋了為什麼大公司沒辦法像新創小公司一樣快速產生網站;扣掉繁複的內部流程,程式設計師要擔心的不是 “我加了什麼新功能?”,而是 “我搞爛了什麼舊功能?”

純技術性的想法是,拋棄舊的架構,在新的架構把所有東西重寫。不過走這條路要成功是難上加難,想像你必須抄寫一張已經被立可白塗抹了十幾年的手寫草稿,要怎麼知道現在寫在上面的東西,真的是它表面上的意思呢?

重新架構的另一個問題是,這段時間你的研發能量就被佔滿了;你在原地踏步,只希望未來可以跑得比競爭者快 — 我希望你能活到那時候。

就因為這其實並不是個簡單的問題,所以才讓能夠妥善處理這種問題的公司能夠脫穎而出吧。不過,這樣更好玩,不是嗎?

Advertisements

十個人機介面可用性的評鑑原則

設計人機介面有很多種方式, User Study 應該仍然是最重要也最難在小公司實現的一環。對很多公司來說,除非先前曾經有過慘痛的失敗經驗,不然人機介面設計的預算往往低到不行,所以也只能祈禱工程師設計出來的介面不會太難用了。

不過,這樣的流程會讓介面設計的討論流於情緒化,往往公司裡面會有這樣的對話:

PM: 「我覺得這個按鈕放這裡不對。」
工程師: 「為什麼?」
PM: 「我也不知道,但我就是覺得怪怪的。」
工程師: 「好吧,我改。」

如果 “覺得怪怪的” 是客戶說的,也許我還是可以視為 user study 的一環,但是 PM 並不是 user;這樣的討論最後往往沒有什麼好的結果,為了大家說不出來的 “感覺”,爭得臉紅脖子粗。

所以,如果有一些原則可以遵守,找出自己覺得奇怪的原因,就可以讓討論更為理性。
Continue reading

有機網站設計(5) – 客人自己來

最近聽到一段很耐人尋味的話:「我們提供服務的目標,就是要讓客人自己服務自己。

這段話完全符合有機的概念:「讓整個系統能夠自成一個生態系,自我修復並且自我支持」,所以這個概念也可以套在有機網站設計上。不過,我們要先定義這邊的 “自己服務自己” 為何。

如果現在到美國的機場,會發現和台灣的機場已經很不同。大多數的航空公司都是讓旅客自行 check-in,只有少數櫃台才有服務人員協助。能夠自行 check-in 的旅客,因為面對的是廣佈在機場各處的機器,所以 check-in 所需要等待的時間很短;相反的,需要人力來服務的則需要大排長龍。這個自我服務的流程需要 1) 研發; 2) 教育用戶; 3) 服務品質差異化; 4) Scalable 等四個要素才能夠完成。從個案討論來看,成功導入這種服務的航空公司因而能夠大幅降低成本結構而痛擊對手,以至於今日在美國航空業這種作法已經非常普遍。

對一般網站的設計,雖然並不一定像是航空公司有一個作業流程,但是仍會有一個瀏覽的順序。有時候使用者會脫離這個正常的流程而需要服務,這時候網站設計者如何面對,就決定了網站的未來。

選擇一: 當作沒這問題;網頁上沒有聯絡方式,也沒有其他 FAQ。我在《信賴感與網頁設計》裡也提到過這個問題。

選擇二: 提供 email 信箱或電話,有問題時來問我。個人網頁或小公司網站最常用這種作法。無組織、未經篩選的客服信往往就會灌進公司的內部,而其中大部份是簡單的問題。

選擇三: 提供靜態 FAQ。大多數網站會把最常見的問題整理成 FAQ,讓使用者可以查閱。

選擇四: 提供具有優異搜尋功能的知識庫。如果去看有規模的 web hosting 公司,因為用戶實在太多而問題太多又太相似,這時候就必須仰賴高強的內部搜尋引擎來找答案了。

選擇五: 提供一個自我診斷的互動流程,來找出使用者所需要的答案。當使用者遇到問題時,他可以利用系統來把問題解決。以 Findbook 來說,當使用者找不到一本書時,究竟是因為 a) 下錯關鍵字; b) 系統沒有這本書; c) 搜尋引擎找不到; d) 這本書不存在合作網站中。每一個流程都有不同的應對方式,而在應對的過程中,網站本身可以 a) 教育用戶; b) 增加系統完整性; c) 蒐集問題點; d) 作為未來應加強方向。

互動的過程,越能夠減少人力的干預,有機度就越高。最需要投入人力的,應該是最前端的研發,讓同一個程式可以服務更多人,也讓更多人可以服務自己。和自動化不同的是,有機網站設計除了自動化之外,也把用戶的 feedback 納入系統之中,當系統不知道答案時,讓用戶教導系統、或是提供更多的知識給系統,這樣的流程才可以串上 web2.0 的精神,變成更為有機的網站。

相關閱讀:
有機網站設計

有機網站設計(4) – 交工的智慧

還記得九二一大地震之後,由於供電不穩定的緣故,許多公司紛紛自行購買發電機,發電機和 UPS 廠商也因此大發利市。但過了九年,當時所購買的發電機,除了應付這一個短暫的危機時期之外,幾乎都被塵封在倉庫的角落,甚至也因為不知如何維護而早已故障。

最近台灣的 BSP 界,也因為樂多和天空部落格之間的糾紛而引起了大地震,對其他 BSP 或是網站代管商來說,確實是大發利市的好機會。老貓在這個時候提出良心的建議,值得想要擁有網站的人參考。不過,難道只有痛苦的選擇自力更生,或是依附商業邏輯兩條路嗎?從農業社會的觀點來看,還有第三條路;「交工」,或是所謂的「等價交換」,才是協助農夫保持可大可小、可長可久的經營之道。

Continue reading

有機網站設計(3) – 你對自己的田有多瞭解?

上一篇《網站農夫的鐵律》提到日誌的重要,透過細節的記錄,未來才能夠針對自己的網站進行分析。但是,對於網路農夫來說,該怎麼進行流量分析呢?

最基本的網站農夫看計數器,有經驗一點的會利用程式來分析網站的流量,那麼,更進階的網站農夫是怎麼看這件事呢?

Continue reading

有機網站設計(2) – 網站農夫的鐵律

上次談了有機網站設計的基本想法, 很多朋友對於這個想法還是有一些疑問, 所以我打算先從種田這件事開始講起, 讓大家更聽不懂 :p

首先要說的是,做網站就跟種田一樣,有太多因素會影響收成。但收成好不代表收入好,種出來的東西如果產量過剩就毫無價值了。作為一個現代的網站農夫,是有必要仔細思考一些問題的。

Continue reading

有機網站設計

上週在 Mr.6 的 blog 上刊了由 Funck 發表《蔬菜都有機了,流量呢?》,和我最近在思考的一個 “有機網站設計” 有相當程度的吻合。除了 Funck 提到的流量、媒體、內容之外,其實還有很多方面都可以用有機的指標來測試。

有機的意義,並不只是強調農藥的施用與否,更重要的是要讓整個系統能夠自成一個生態系,自我修復並且自我支持。從網站的觀點來看,有機就包括了 “有機流量”, “有機建置”和 “有機營運” 幾個角度。這幾個角度會交互影響,一個成功的網站雖然不必要是有機的,但是有機的網站卻可以讓網站發展的速度更快,也花更少的精力和金錢。 Continue reading