gov.uk Design Principles 中文版

編輯歷史

時間	作者	版本
2015-01-31 05:47 – 05:50	nchild	r407 – r446
顯示 diff （5 行未修改） http://www.nationalarchives.gov.uk/doc/open-government-licence/version/2/ 提醒使用到內容的朋友，歡迎修改、衍身、分享，但別忘了附上出處，累積與共享 + Why? （3 行未修改）原文： https://www.gov.uk/design-principles (under OGLv2) 譯來自： - http://goo.gl/WGqsHN ，原翻譯有不少主觀涵義，敬請協助修正h準則1. 從需求出發來規劃 + http://goo.gl/WGqsHN ，原翻譯有不少主觀涵義，敬請協助修正 + 重複發明輪子版 :crying_cat_face:：http://gds.hpx.tw/service-manual/user-centred-design/design-principles/h準則1. 從需求出發來規劃使用者的需求，通常不是網站主人的需求（67 行未修改）
2014-05-24 13:34 – 13:37	Jimmy Huang	r347 – r406
顯示 diff gov.uk Design Principles 中文版 Government Digital Service Design Principles + + 內容授權 + Open Government License for public sector information + http://www.nationalarchives.gov.uk/doc/open-government-licence/version/2/ + 提醒使用到內容的朋友，歡迎修改、衍身、分享，但別忘了附上出處，累積與共享 *Why? （75 行未修改）
2014-05-20 06:15 – 06:15	Chia-liang Kao	r337 – r346
顯示 diff （5 行未修改） and here: http://netivism.com.tw/article/170 - 原文： https://www.gov.uk/design-principles + 原文： https://www.gov.uk/design-principles (under OGLv2) 譯來自： http://goo.gl/WGqsHN ，原翻譯有不少主觀涵義，敬請協助修正h*準則1. 從需求出發來規劃（69 行未修改）
2014-05-20 01:25 – 01:37	Lee	r275 – r336
顯示 diff （45 行未修改）準則6. 為大眾設計會減少使用者存取的任何事情，都不能碰 - - 建立有效的服務，最好的辦法是從小處著手，反複更替進行。提前發佈最低限度的可用產品，提供給真正的用戶進行測試。 - 循環更替可降低風險，它使可能的大失敗，變成小失敗的教訓。避免了撰寫數百頁的空泛文件規範，所造成的瓶頸。這種小量漸進的發展方式，不是一次把橋造好，遇到問題就把它拆掉重建的方法，而是提早發現問題，適時快速改進檢討，達成目標。 + 建可以使用就是好設計。即使這些設計可能犧牲優雅的視覺，讓服務盡可能的可讀、易讀、好用，就是應該要貫徹的好設計。 + 最需要使用服務的，通常會是那些最容易碰到易用性困難的人。字太小、沒有裝上 Flash、不知道按鈕長什麼樣子...想想這些人，就能明白服務應該長成什麼樣子。 + 原先第六點貼成第五點了，修正成投影片上的內容。準則7. 了解情境脈絡而非設計畫面 *想想看這些人來到這裡，為的是什麼（25 行未修改）
2014-05-19 08:00 – 08:00	Charles Chuang	r270 – r274
顯示 diff （79 行未修改）
2014-05-15 08:30 – 08:30	Jimmy Huang	r268 – r269
顯示 diff （79 行未修改）
2014-05-11 06:14 – 06:27	Jimmy Huang	r133 – r267
顯示 diff - gov.uk Design Principle 翻譯 - - 緣起： - https://www.facebook.com/clkao/posts/10152334838265668 + gov.uk Design Principles 中文版 + Government Digital Service Design Principles - Based on: - https://speakerdeck.com/jimyhuang/10ge-zhun-ze-gui-hua-ge-gong-tong-can-yu-de-fu-wu + Why? + here: https://www.facebook.com/clkao/posts/10152334838265668 + and here: http://netivism.com.tw/article/170 - 準則1. 從需求出發來規劃 + 原文： https://www.gov.uk/design-principles + 譯來自： + http://goo.gl/WGqsHN ，原翻譯有不少主觀涵義，敬請協助修正h準則1. 從需求出發來規劃使用者的需求，通常不是網站主人的需求（9 行未修改）如果專注在核心，很有可能省下經費，可以為核心建構更好的服務。 - - 準則3. 依據資料來設計 - 網路美好處，就是可以觀察使用者的行為 + 準則3. 依據資料來設計 + 網路美好處，就是可以觀察使用者的行為如果是一個改版計畫，通常使用者已經用過你們的服務了。正好，可以建立一個雛形（Prototype）讓使用者試用，並且觀察他們的行為是否符合預期，是否依據我們設計好的路徑來拜訪網頁，來使用服務。常見的資料蒐集工具，包含利用A/B測試，調查兩組不同的Prototype來比較修正經驗；或是應用Google Analytics服務蒐集瀏覽資訊，了解最常造訪和造訪來源。 - - 準則4. 用盡全力來塑造簡單 - 好用，比看起來乾淨還難的許多 + 準則4. 用盡全力來塑造簡單 + 好用，比看起來乾淨還難的許多如果背後的機制本身就很複雜，那要讓事情更簡單反而更花力氣! 但成千上萬的人選用這個系統，那應該為他們節省時間，而非濫用我們的權力。 - 準則5. 週而復始以精鍊設計 - 小處著眼測試開始，慢慢精鍊設計 + 準則5. 週而復始以精鍊設計 + 小處著眼測試開始，慢慢精鍊設計 + 建立有效的服務，最好的辦法是從小處著手，反複更替進行。提前發佈最低限度的可用產品，提供給真正的用戶進行測試。 + 循環更替可降低風險，它使可能的大失敗，變成小失敗的教訓。避免了撰寫數百頁的空泛文件規範，所造成的瓶頸。這種小量漸進的發展方式，不是一次把橋造好，遇到問題就把它拆掉重建的方法，而是提早發現問題，適時快速改進檢討，達成目標。 - 準則6. 為大眾設計 - 會減少使用者存取的任何事情，都不能碰 + 準則6. 為大眾設計 + 會減少使用者存取的任何事情，都不能碰建立有效的服務，最好的辦法是從小處著手，反複更替進行。提前發佈最低限度的可用產品，提供給真正的用戶進行測試。 - 循環更替可降低風險，它使可能的大失敗，變成小失敗的教訓。避免了撰寫數百頁的空泛文件規範，所造成的瓶頸。這種小量漸進的發展方式，不是一次把橋造好，遇到問題就把它拆掉重建的方法，而是提早發現問題，適時快速改進檢討，達成目標。 - 準則7. 了解情境脈絡而非設計畫面 - 想想看這些人來到這裡，為的是什麼 + 循環更替可降低風險，它使可能的大失敗，變成小失敗的教訓。避免了撰寫數百頁的空泛文件規範，所造成的瓶頸。這種小量漸進的發展方式，不是一次把橋造好，遇到問題就把它拆掉重建的方法，而是提早發現問題，適時快速改進檢討，達成目標。 + 準則7. 了解情境脈絡而非設計畫面 + 想想看這些人來到這裡，為的是什麼使用者透過什麼方式來使用服務呢？從手機？從平板？從圖書館的老舊電腦？他們都是Facebook的用戶嗎？因此，要了解脈絡，用資訊出發，設計他，而非從畫面的某個像素來錙銖必較。（1 行未修改）大多時刻，我們必須為非常多樣性的族群設計，每個人有不同的使用習慣、科技裝置，我們必須練習使用這些科技、裝置，不然就會無法理解使用者的一般生活的脈絡。 - 準則8. 創造數位服務而非建置網站 - 服務需串連實體與虛擬，連結用戶穿越網路 + 準則8. 創造數位服務而非建置網站 + 服務需串連實體與虛擬，連結用戶穿越網路 - 我們創造的服務，很有可能不在我們自己的網站上開始，也不在自己的網站上結束。使用者極有可能從搜尋引擎出發，然後從郵局收到貨品完成一次服務體驗。雖然有些時候這些流程並不如我們想像，但只要我們願意往這個方向邁進，有一天會發現新的值得我們實現服務之處。 - 準則9. 保持一致性，而非呆板 - 一致性幫助使用者了解前後連貫與脈絡 + 準則9. 保持一致性，而非呆板 + 一致性幫助使用者了解前後連貫與脈絡我們應盡可能的用共通的語言語法、共通的視覺元素來設計服務，這可以幫助人們感覺親近好用。然而，總一些例外無法維持一致性，那應該維持基本的使用方式一致，這樣使用者仍可以猜出他們應該要做什麼動作。 + + 準則10. 開放，會讓事情更好 + 越多人看到只會讓事情漸趨完美 + + 公開自己的成果，分享理念、設計、程式、創意，也會一同分享了目光、分享成功和失敗。別害怕分享失敗，越多人關注失敗，只會讓事情更容易漸趨完美。 + + 要建構好的網路服務得仰賴大量的Open Source社群成果，公開成為必須的選項。然而更重要的是取之社群，回饋社群，這樣下一次社群的演進，才能幫助讓眾人和自己的事情更好。
2014-05-11 06:14	(unknown)	r132
顯示 diff （72 行未修改）
2014-05-11 06:14 – 06:14	Jimmy Huang	r118 – r131
顯示 diff （55 行未修改）大多時刻，我們必須為非常多樣性的族群設計，每個人有不同的使用習慣、科技裝置，我們必須練習使用這些科技、裝置，不然就會無法理解使用者的一般生活的脈絡。 + + 準則8. 創造數位服務而非建置網站 + 服務需串連實體與虛擬，連結用戶穿越網路 + + + 我們創造的服務，很有可能不在我們自己的網站上開始，也不在自己的網站上結束。 + + 使用者極有可能從搜尋引擎出發，然後從郵局收到貨品完成一次服務體驗。雖然有些時候這些流程並不如我們想像，但只要我們願意往這個方向邁進，有一天會發現新的值得我們實現服務之處。 + + 準則9. 保持一致性，而非呆板 + 一致性幫助使用者了解前後連貫與脈絡 + + 我們應盡可能的用共通的語言語法、共通的視覺元素來設計服務，這可以幫助人們感覺親近好用。 + + 然而，總一些例外無法維持一致性，那應該維持基本的使用方式一致，這樣使用者仍可以猜出他們應該要做什麼動作。
2014-05-11 06:14	(unknown)	r117
顯示 diff （57 行未修改）
2014-05-11 06:14 – 06:14	Jimmy Huang	r112 – r116
顯示 diff （49 行未修改）準則7. 了解情境脈絡而非設計畫面 - 想想看這些人來到這裡，為的是什麼 + 想想看這些人來到這裡，為的是什麼 + + + 使用者透過什麼方式來使用服務呢？從手機？從平板？從圖書館的老舊電腦？他們都是Facebook的用戶嗎？因此，要了解脈絡，用資訊出發，設計他，而非從畫面的某個像素來錙銖必較。 + + 大多時刻，我們必須為非常多樣性的族群設計，每個人有不同的使用習慣、科技裝置，我們必須練習使用這些科技、裝置，不然就會無法理解使用者的一般生活的脈絡。
2014-05-11 06:13	(unknown)	r111
顯示 diff （52 行未修改）
2014-05-11 06:13 – 06:13	Jimmy Huang	r98 – r110
顯示 diff （38 行未修改）準則5. 週而復始以精鍊設計小處著眼測試開始，慢慢精鍊設計 + 建立有效的服務，最好的辦法是從小處著手，反複更替進行。提前發佈最低限度的可用產品，提供給真正的用戶進行測試。 + 循環更替可降低風險，它使可能的大失敗，變成小失敗的教訓。避免了撰寫數百頁的空泛文件規範，所造成的瓶頸。這種小量漸進的發展方式，不是一次把橋造好，遇到問題就把它拆掉重建的方法，而是提早發現問題，適時快速改進檢討，達成目標。 + + + 準則6. 為大眾設計 + 會減少使用者存取的任何事情，都不能碰 + + 建立有效的服務，最好的辦法是從小處著手，反複更替進行。提前發佈最低限度的可用產品，提供給真正的用戶進行測試。 + 循環更替可降低風險，它使可能的大失敗，變成小失敗的教訓。避免了撰寫數百頁的空泛文件規範，所造成的瓶頸。這種小量漸進的發展方式，不是一次把橋造好，遇到問題就把它拆掉重建的方法，而是提早發現問題，適時快速改進檢討，達成目標。 + + 準則7. 了解情境脈絡而非設計畫面 + 想想看這些人來到這裡，為的是什麼
2014-05-11 06:13	(unknown)	r97
顯示 diff （40 行未修改）
2014-05-11 06:12 – 06:13	Jimmy Huang	r79 – r96
顯示 diff （14 行未修改） - 準則2. 少做一點 + 準則2. 少做一點專精而非包山包海 - 你的服務應該只做能夠做的，如果別人可以應用你的資訊提供更好的服務，那你應該提供資源（例如提供API）來幫助人們應用你的服務。我們應該專注於不可替代的價值。如果專注在核心，很有可能省下經費，可以為核心建構更好的服務。 + + 準則3. 依據資料來設計 + 網路美好處，就是可以觀察使用者的行為 + + + 如果是一個改版計畫，通常使用者已經用過你們的服務了。正好，可以建立一個雛形（Prototype）讓使用者試用，並且觀察他們的行為是否符合預期，是否依據我們設計好的路徑來拜訪網頁，來使用服務。 + + 常見的資料蒐集工具，包含利用A/B測試，調查兩組不同的Prototype來比較修正經驗；或是應用Google Analytics服務蒐集瀏覽資訊，了解最常造訪和造訪來源。 + + + 準則4. 用盡全力來塑造簡單 + 好用，比看起來乾淨還難的許多 + + 如果背後的機制本身就很複雜，那要讓事情更簡單反而更花力氣! + 但成千上萬的人選用這個系統，那應該為他們節省時間，而非濫用我們的權力。 + + 準則5. 週而復始以精鍊設計 + 小處著眼測試開始，慢慢精鍊設計
2014-05-11 06:12	(unknown)	r78
顯示 diff （23 行未修改）
2014-05-11 06:11 – 06:12	Jimmy Huang	r68 – r77
顯示 diff （7 行未修改）準則1. 從需求出發來規劃 - 使用者的需求，通常不是網站主人的需求 + 使用者的需求，通常不是網站主人的需求通常單位都有自己的一個「官方」申請流程，然而我們應該從使用者的需求出發來設計，藉由跟使用者蒐集的資料來挖掘出真正的需求，而非我們自行想像的規劃。這個過程也得時時謹記使用者「想要」有什麼功能，通常不一定是他們「需要」的功能。（3 行未修改）準則2. 少做一點 - 專精而非包山包海 + *專精而非包山包海 + + + 你的服務應該只做能夠做的，如果別人可以應用你的資訊提供更好的服務，那你應該提供資源（例如提供API）來幫助人們應用你的服務。我們應該專注於不可替代的價值。 + + 如果專注在核心，很有可能省下經費，可以為核心建構更好的服務。
2014-05-11 06:11	(unknown)	r67
顯示 diff （18 行未修改）
2014-05-11 06:11 – 06:11	Jimmy Huang	r64 – r66
顯示 diff （12 行未修改）把「需求」放在最前端的設計核心，才能讓使用者接觸網站的過程改善成「幫助他們完成任務」，而擺出的服務項目，不僅僅只是擺出，而是真正經過調查而篩選出來的必要任務。專注在需求，意味著我們可以集中精力，提供最物超所值的東西。 + + + 準則2. 少做一點 + 專精而非包山包海
2014-05-11 06:11	(unknown)	r63
顯示 diff （14 行未修改）
2014-05-11 06:11 – 06:11	Jimmy Huang	r53 – r62
顯示 diff （6 行未修改） https://speakerdeck.com/jimyhuang/10ge-zhun-ze-gui-hua-ge-gong-tong-can-yu-de-fu-wu - 準則1. 從需求出發來規劃 - 使用者的需求，通常不是網站主人的需求 + *準則1. 從需求出發來規劃 + 使用者的需求，通常不是網站主人的需求 + + 通常單位都有自己的一個「官方」申請流程，然而我們應該從使用者的需求出發來設計，藉由跟使用者蒐集的資料來挖掘出真正的需求，而非我們自行想像的規劃。這個過程也得時時謹記使用者「想要」有什麼功能，通常不一定是他們「需要」的功能。 + + 把「需求」放在最前端的設計核心，才能讓使用者接觸網站的過程改善成「幫助他們完成任務」，而擺出的服務項目，不僅僅只是擺出，而是真正經過調查而篩選出來的必要任務。專注在需求，意味著我們可以集中精力，提供最物超所值的東西。
2014-05-11 06:11	(unknown)	r52
顯示 diff （10 行未修改）
2014-05-11 06:09 – 06:11	Jimmy Huang	r1 – r51
顯示 diff - Untitled + gov.uk Design Principle 翻譯 - This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents! + 緣起： + https://www.facebook.com/clkao/posts/10152334838265668 + + Based on: + https://speakerdeck.com/jimyhuang/10ge-zhun-ze-gui-hua-ge-gong-tong-can-yu-de-fu-wu + + 準則1. 從需求出發來規劃 + 使用者的需求，通常不是網站主人的需求
2014-05-11 06:09	(unknown)	r0
顯示 diff + Untitled + This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!