經營網站前，先設計網站

經營網站前，先設計網站簡報者 Jimmy Huang

Jimmy at netivism.com.tw

# 2

Jimmy Huang網絡行動科技創辦人 NETivism.com.tw Since 2009-01

從數位公益出發的社會企業

網絡行動科技有限公司是一個社會企業提供網際網路、行動網路的專業諮詢及解決方案並期許每一次所提供的產品與服務，都能對社會有益！

# 3

啟示

# 4

# 5

# 6 http://www.greenschool.moe.edu.tw/partner/item.aspx?key=34276

# 7

寫下目標

● 透過親自的實作，讓師生了解生態工法與傳統利用水泥的方式之差異。

● 搭配低、中、高年級的課程設計，讓孩子一起參與活動。

● 讓學校師生有共同的參與感，可以共同維護這個得來不易的生態池。

# 8

寫下網站改版目標

● 結合社群網站推播分享，讓網站更容易宣傳● 讓網站美觀大方，人人都能驚艷● 讓網站好維護

# 9

寫下我的網站改版目標

● 透過親身的參與，讓員工與團隊了解網站運作的細節，以及學習行銷我們特有服務的方式。

● 搭配單位的服務，讓網站能夠延伸觸角，大家都能透過網路使用服務。

● 讓相關同仁能夠感受到網站經營不易，未來要共同維護這個得來不易，耗盡眾人腦汁產出的網站。

# 10

10 個準則規劃一個共同參與的服務

https://www.gov.uk/designprinciples

# 11

準則 1. 從需求出發來規劃 使用者的需求，通常不是網站主人的需求

通常單位都有自己的一個「官方」申請流程，然而我們應該從使用者的需求出發來設計，藉由跟使用者蒐集的資料來挖掘出真正的需求，而非我們自行想像的規劃。這個過程也得時時謹記使用者「想要」有什麼功能，通常不一定是他們「需要」的功能。

把「需求」放在最前端的設計核心，才能讓使用者接觸網站的過程改善成「幫助他們完成任務」，而擺出的服務項目，不僅僅只是擺出，而是真正經過調查而篩選出來的必要任務。專注在需求，意味著我們可以集中精力，提供最物超所值的東西。

# 12

# 13

能夠集結大家，透過紙上作業往往是最省力有效來發現需求的方式

# 14

事後的紀錄和追蹤也很重要這樣才可排定需求的優先順序

http://digital.cabinetoffice.gov.uk/2011/09/19/introducing-the-needotron-working-out-the-shape-of-the-product/

# 15

準則 2. 少做一點 專精而非包山包海

你的服務應該只做能夠做的，如果別人可以應用你的資訊提供更好的服務，那你應該提供資源（例如提供API）來幫助人們應用你的服務。我們應該專注於不可替代的價值。

如果專注在核心，很有可能省下經費，可以為核心建構更好的服務。

# 16

# 17

專精、專業，讓人信服你的服務公信力

# 18

準則 3. 依據資料來設計 網路美好處，就是可以觀察使用者的行為

如果是一個改版計畫，通常使用者已經用過你們的服務了。正好，可以建立一個雛形（ Prototype）讓使用者試用，並且觀察他們的行為是否符合預期，是否依據我們設計好的路徑來拜訪網頁，來使用服務。

常見的資料蒐集工具，包含利用 A/B測試，調查兩組不同的 Prototype 來比較修正經驗；或是應用 Google Analytics 服務蒐集瀏覽資訊，了解最常造訪和造訪來源。

# 19

利用 Google Analytics 找出流失使用者的步驟

# 20

設定頁面目標，來找出完成目標最好的脈絡

# 21

利用 Sharethis 工具結合，找出社群分享路徑

# 22

建立 Prototype 網站，讓規劃和業主、使用者可參與

# 23

準則 4. 用盡全力來塑造簡單 好用，比看起來乾淨還難的許多

如果背後的機制本身就很複雜，那要讓事情更簡單反而更花力氣 !

但成千上萬的人選用這個系統，那應該為他們節省時間，而非濫用我們的權力。

# 24

清楚簡單，不只是風格，還有途徑 http://us.vanmoof.com/7-vanmoof-3-1-28.html

# 25

# 26

會偵測現在的語言選出鄰近國家，導引你選到鄰近販售點

# 27

> 簡化複雜的規格>考量實體與虛擬賣店>考量跨國銷售> 簡化配件銷售

# 28

準則 5. 週而復始以精鍊設計 小處著眼測試開始，慢慢精鍊設計

建立有效的服務，最好的辦法是從小處著手，反複更替進行。提前發佈最低限度的可用產品，提供給真正的用戶進行測試。

循環更替可降低風險，它使可能的大失敗，變成小失敗的教訓。避免了撰寫數百頁的空泛文件規範，所造成的瓶頸。這種小量漸進的發展方式，不是一次把橋造好，遇到問題就把它拆掉重建的方法，而是提早發現問題，適時快速改進檢討，達成目標。

# 29

從無到有的服務，最起頭一定是一連串的 beta

# 30

從自己的服務驗證

# 31

從為客戶建構系統的過程驗證

# 32

建構出足夠的經驗和案例，來純化服務的可及性、有效性

# 33

目前的線上版本，去蕪存菁

# 34

比起漂亮的服務頁面，我們更重視教學和客服引導

# 35

準則 6. 為大眾設計 會減少使用者存取的任何事情，都不能碰

可以使用就是好設計。即使這些設計可能犧牲優雅的視覺，讓服務盡可能的可讀、易讀、好用，就是應該要貫徹的好設計。

最需要使用服務的，通常會是那些最容易碰到易用性困難的人。字太小、沒有裝上 Flash 、不知道按鈕長什麼樣子 .. 想想這些人，就能明白服務應該長成什麼樣子。

# 36

本系統僅提供 IE 32 位元瀏覽器 /本系統不支援其他瀏覽器

# 37

你看的到上面的字嗎？（研考會無障礙網頁手機版）

# 38

網站有 Flash嗎？用 iPad瀏覽台灣的網站其實滿可憐

# 39

公司 Logo 用 Flash製作的，就更難解了

# 40

準則 7. 了解情境脈絡而非設計畫面 想想看這些人來到這裡，為的是什麼

使用者透過什麼方式來使用服務呢？從手機？從平板？從圖書館的老舊電腦？他們都是 Facebook 的用戶嗎？因此，要了解脈絡，用資訊出發，設計他，而非從畫面的某個像素來錙銖必較。

大多時刻，我們必須為非常多樣性的族群設計，每個人有不同的使用習慣、科技裝置，我們必須練習使用這些科技、裝置，不然就會無法理解使用者的一般生活的脈絡。

# 41

Facebook症狀調查

● 你在 Facebook上按了參加活動，會去嗎？● 你願意用 Facebook帳號登入其他網站嗎？● 你有從 Facebook按讚，卻從來沒有點近轉貼連

結觀看的經驗嗎？

# 42

手機、平板，以及圖書館的老舊電腦

# 43

根據不同裝置而呈現不同的內容，已經成為趨勢

# 44

電子報 / Email 的閱讀情境，更需要考量不同裝置的通用問題

# 45

準則 8. 創造數位服務而非建置網站 服務需串連實體與虛擬，連結用戶穿越網路

我們創造的服務，很有可能不在我們自己的網站上開始，也不在自己的網站上結束。

使用者極有可能從搜尋引擎出發，然後從郵局收到貨品完成一次服務體驗。雖然有些時候這些流程並不如我們想像，但只要我們願意往這個方向邁進，有一天會發現新的值得我們實現服務之處。

# 46

郵遞區號是台灣的網路工程師，常會碰到的痛苦經驗

# 47

當然也有熱心人士提供「數位服務」，補足缺憾

# 48

地政局「網站」

# 49

地政局，其實有「數位服務」，為何不提到首頁呢？

# 50

數位服務，需要經營者，更需要參與、使用者

# 51

準則 9. 保持一致性，而非呆板 一致性幫助使用者了解前後連貫與脈絡

我們應盡可能的用共通的語言語法、共通的視覺元素來設計服務，這可以幫助人們感覺親近好用。

然而，總一些例外無法維持一致性，那應該維持基本的使用方式一致，這樣使用者仍可以猜出他們應該要做什麼動作。

# 52

版面相同，但視覺不同，保持一致性，不呆板

# 53

# 54

即使版面不同視覺和動線讓使用者能知道自己在哪，下一步去哪裡

# 55

準則 10. 開放，會讓事情更好 越多人看到只會讓事情漸趨完美

公開自己的成果，分享理念、設計、程式、創意，也會一同分享了目光、分享成功和失敗。別害怕分享失敗，越多人關注失敗，只會讓事情更容易漸趨完美。

要建構好的網路服務得仰賴大量的 Open Source 社群成果，公開成為必須的選項。然而更重要的是取之社群，回饋社群，這樣下一次社群的演進，才能幫助讓眾人和自己的事情更好。

# 56

網絡行動科技的起源為 Drupal台灣中文社群從翻譯、論壇，到站長交替後

# 57

社群已逐漸壯大，台灣越來越多人使用與響應Drupal台灣社群研討會（ 2010）

# 58

今年新站長上任，一樣熱血，參與人數依然不減網絡行動當然成為贊助廠商

Drupal國內社群研討會（ 2012）

# 59

netiCRM 服務希望能夠幫助 CiviCRM 社群健康發展

# 60

秉持公開分享、遵守 GPL授權netiCRM 程式碼和翻譯皆公開在社群自由取用

# 61

截至目前為止， CiviCRM 在台灣已經超過 60 個單位下載

# 62

1.Start with needs

2.Do less

3.Design with data

4.Do the hard work to make it simple

5.Iterate. Then iterate again

6.Build for inclusion

7.Understand context

8.Build digital servicesnot websites

9.Be consistent, not uniform

10.Make things open: it makes things betterhttps://www.gov.uk/designprinciples

Government Digital Service Design Principles

# 63

END