原文：Government Digital Service Design Principles
原文作者：英國政府
本站翻譯
政府數位服務設計原則(2012年4月3日的alpha版本)
下面所列是我們的設計原則，還有一些範例展示我們目前使用的方式。這些原則是根據或另外加進我們原本的7大數位原則。(譯註：目前沒有翻譯範例，請至原文觀看實際範例)
1 從需求著手*
*是使用者需要什麼，而不是政府想要什麼
在設計的過程中，我們必須了解、思考，從真正的使用者需求出發。我們應該圍繞著這些設計服務──而不是像現在圍繞著「官樣程序」。我們必須透澈地了解──從數據資料中找出答案，別用瞎猜的──還有我們要記住，使用者想要的並不總是他們所需要的。
我們以「需求」當為思考整個數位服務原則時的中心思想，因為民眾來到我們的網站是要完成工作並滿足他們的需求，而不只是上來閒晃。集中資源在民眾的需求，代表我們可以專心讓預算發揮在最大效益的事上。
2 做少點
政府應該做只有政府才能做到的事。如果有別人做了──連結過去。如果我們可以提供資源(像是APIs)，可以幫助其他人做事──就要提供它。我們應專心在不可或缺的核心部份。
藉著集中資源於應該在的地方，我們可以提供更好的服務，並省下更多預算。
3 隨著資料而設計
一般來說，我們不是從零開始──使用者已經在使用我們的服務。這表示我們可以從實際的行為中了解使用者。我們應該這樣做，並且我們要確定在建立與發展服務的過程中，都要這樣做──雛型建立和測試都在實際的網路上，與真正的使用者互動。我們應該要了解，我們如何隨著資料而設計？其過程中的期望路徑(desire path)是什麼樣子的？瞭解這些後都要應用在我們的設計之中。
這是數位服務的一大優勢──我們可以觀察且學習使用者的行為。與其讓民眾屈服於我們建立的服務，不如雕塑我們的系統，讓民眾可以自然地做出的下一步。
譯註：
期望路徑(desire path)──在公園中的草地，雖然沒有鋪設走道，但因為經年累月，被人們踏踩而造成幾條光禿禿，沒有草生長的小徑，而這條小徑又會變成之後的人行走時的參考依據。後來引申為當我們進行一件事時，為了要完成目的，自然地產生自己認為最有效率的行為模式，也變成之後其他人做同一件事時的重要參考藍圖。
4 做困難的事，並簡化它
讓一個東西看起來簡單很容易；讓一個東西用起來簡單就難多了──特別是底下的系統盤根錯節──但這就是我們理應要做的事。
能力愈大，責任愈大──絕大多數人別無選擇，只能使用我們的服務。如果我們不努力地讓這些服務變得更簡單且實用，我們就濫用了這項權力，還會浪費人民的時間。
5 重複。然後再重複。
建立有效服務的最好方式是小做起，然後重複擴大。儘早釋出只有基本功能但可運行的產品，由真實的使用者測試，從Alpha、Beta測試，直到完成上線，根據實際使用後的回饋，修改、增加服務的功能。
「重複」可以減少風險。它減少大失敗的發生機率，並且可以讓小失敗變成我們學到的教訓。這樣做可避掉200頁的規格文件，及其所可能造成的瓶頸。這樣做，再一次地顯示出數位的核心優勢：我們不是在建一座橋──事情可以「回到上一步」。
6 為廣納民眾而建構
無障礙設計是好設計。我們應該建構一個儘可能有廣納性(inclusive)、易辨性(legible)、可讀性(readable)的產品。如果我們會因此而犧牲掉優雅的感覺──那就犧牲掉。別擔心平淡的外觀，別試著重新發明網頁設計協定，但應清楚地設定好使用者會預期的部份。
我們是為了整個國家的人民而設計──而不是只為了那些有網路經驗的人。事實上，最需要我們服務的人民，通常也是那些覺得服務難以使用的人。如果我們一開始思考時，就以那些人為對象，我們就可以為每個人提供更好的服務。
7 了解使用者的環境
我們不是為了螢幕設計，是為了民眾而設計。我們需要努力地思考他們是在什麼環境背景下使用服務。他們在圖書館？他們使用手機？他們真的只熟悉臉書？他們是否從未接觸網路？
我們的對象包含了不同的族群，使用著不同的科技與不同的需求。我們需要確定自己已經了解，服務會在哪些科技與實際情境下運行。不然的話我們只是冒險設計了一個很漂亮，但卻和民眾的生活無關的服務。
8 建立數位服務，而不是網站
我們提供的服務不會只從網站開始，也不會在網站結束。服務可能從搜尋引擎開始，然後在郵局完成。我們需要這樣設計，儘管我們無法控制別人如何使用。我們需要認知到有一天，在知道那一天來臨之前，它會再次成為不同的數位服務。
我們要考慮的不是網站，我們應該考慮的是數位服務。到目前為止，我們的數位服務的媒介是網頁，但情況也許會改變，並且可能比我們想像的還要快。
9 一致化，但不僵化
不論何處，我們應使用相同的語言與設計模式──這樣可以幫助民眾熟悉我們所提供的服務。但是當這點無法達成時，我們至少要確定服務的基本使用方式是一致的。因此民眾將可以有一定程度的機會，可以猜出他們要怎麼做。
這不是一套給病患穿的約束衣或是一本規則。要求民眾死記硬背才能完成的服務，不是一個好服務。我們沒有辦法想到每一種情況，然後針對各情況寫出守則。每一種狀況都不同，並且只有相對應的方式能夠處理。什麼事情可以讓我們的服務整合在一起，它就會成為我們持續的作法──這個作法可以讓使用者開始了解並且信任──甚至當我們進入到新的數位空間時，也會如此。
10 讓事情公開化：它讓事情變得更簡單
只要可以，我們應該隨時分享我們正在做什麼。與同事分享、與使用者分享、與世界分享；分享程式碼、分享設計、分享意見、分享目的、分享失敗。愈多雙眼睛注視著，我們提供的服務就會變得愈好──隨著發覺缺失、提出更多選項，我們也跟著不斷進步。
部份原因是我們所做的這些之所以成為可能，多虧了開放原始碼和網路設計社群的慷慨成果，所以我們理當回饋。但最主要還是因為愈多的開放，就會有愈好的服務──可以受到更好的了解和檢視。如果我們釋出程式碼，我們將會獲得更好的程式碼。這也是為什麼我們要寫出這些原則…
譯者的話：
所以，如果你覺得有任何應該要注意，這篇文章卻沒有提到的原則，歡迎提供意見與回饋。
可以的話，直接寫電子郵件給英國政府吧。
沒有留言:
張貼留言
為避免垃圾訊息，留言需檢視後會才會顯示，請見諒。