Government Digital Service Design Principles
Open Government License for public sector information
http://www.nationalarchives.gov.uk/doc/open-government-licence/version/2/
here: https://www.facebook.com/clkao/posts/10152334838265668
and here: http://netivism.com.tw/article/170
原文： https://www.gov.uk/design-principles (under OGLv2)
翻譯來自： http://goo.gl/WGqsHN ，原翻譯有不少主觀涵義，敬請協助修正
重複發明輪子版 :crying_cat_face:：http://gds.hpx.tw/service-manual/user-centred-design/design-principles/
通常單位都有自己的一個「官方」申請流程，然而我們應該從使用者的需求出發來設計，藉由跟使用者蒐集的資料來挖掘出真正的需求，而非我們自行想像的規劃。這個過程也得時時謹記使用者「想要」有什麼功能，通常不一定是他們「需要」的功能。
把「需求」放在最前端的設計核心，才能讓使用者接觸網站的過程改善成「幫助他們完成任務」，而擺出的服務項目，不僅僅只是擺出，而是真正經過調查而篩選出來的必要任務。專注在需求，意味著我們可以集中精力，提供最物超所值的東西。
你的服務應該只做能夠做的，如果別人可以應用你的資訊提供更好的服務，那你應該提供資源（例如提供API）來幫助人們應用你的服務。我們應該專注於不可替代的價值。
如果專注在核心，很有可能省下經費，可以為核心建構更好的服務。
如果是一個改版計畫，通常使用者已經用過你們的服務了。正好，可以建立一個雛形（Prototype）讓使用者試用，並且觀察他們的行為是否符合預期，是否依據我們設計好的路徑來拜訪網頁，來使用服務。
常見的資料蒐集工具，包含利用A/B測試，調查兩組不同的Prototype來比較修正經驗；或是應用Google Analytics服務蒐集瀏覽資訊，了解最常造訪和造訪來源。
如果背後的機制本身就很複雜，那要讓事情更簡單反而更花力氣!
但成千上萬的人選用這個系統，那應該為他們節省時間，而非濫用我們的權力。
建立有效的服務，最好的辦法是從小處著手，反複更替進行。提前發佈最低限度的可用產品，提供給真正的用戶進行測試。
循環更替可降低風險，它使可能的大失敗，變成小失敗的教訓。避免了撰寫數百頁的空泛文件規範，所造成的瓶頸。這種小量漸進的發展方式，不是一次把橋造好，遇到問題就把它拆掉重建的方法，而是提早發現問題，適時快速改進檢討，達成目標。
可以使用就是好設計。即使這些設計可能犧牲優雅的視覺，讓服務盡可能的可讀、易讀、好用，就是應該要貫徹的好設計。
最需要使用服務的，通常會是那些最容易碰到易用性困難的人。字太小、沒有裝上 Flash、不知道按鈕長什麼樣子...想想這些人，就能明白服務應該長成什麼樣子。
使用者透過什麼方式來使用服務呢？從手機？從平板？從圖書館的老舊電腦？他們都是Facebook的用戶嗎？因此，要了解脈絡，用資訊出發，設計他，而非從畫面的某個像素來錙銖必較。
大多時刻，我們必須為非常多樣性的族群設計，每個人有不同的使用習慣、科技裝置，我們必須練習使用這些科技、裝置，不然就會無法理解使用者的一般生活的脈絡。
我們創造的服務，很有可能不在我們自己的網站上開始，也不在自己的網站上結束。
使用者極有可能從搜尋引擎出發，然後從郵局收到貨品完成一次服務體驗。雖然有些時候這些流程並不如我們想像，但只要我們願意往這個方向邁進，有一天會發現新的值得我們實現服務之處。
我們應盡可能的用共通的語言語法、共通的視覺元素來設計服務，這可以幫助人們感覺親近好用。
然而，總一些例外無法維持一致性，那應該維持基本的使用方式一致，這樣使用者仍可以猜出他們應該要做什麼動作。
公開自己的成果，分享理念、設計、程式、創意，也會一同分享了目光、分享成功和失敗。別害怕分享失敗，越多人關注失敗，只會讓事情更容易漸趨完美。
要建構好的網路服務得仰賴大量的Open Source社群成果，公開成為必須的選項。然而更重要的是取之社群，回饋社群，這樣下一次社群的演進，才能幫助讓眾人和自己的事情更好。