2012年5月21日

政府數位服務設計原則

政府提供服務時,或應該說是任何單位,於現在的環境中提供數位服務時,應該要考慮哪些原則?或許,我們可以參考英國政府所提出的建議。從這些原則,我們可以回過頭來看看我們提供的數位服務中,有哪些優缺點可供學習與改進,並與他人一同分享。

原文:Government Digital Service Design Principles
原文作者:英國政府
本站翻譯

政府數位服務設計原則(2012年4月3日的alpha版本)

下面所列是我們的設計原則,還有一些範例展示我們目前使用的方式。這些原則是根據或另外加進我們原本的7大數位原則。(譯註:目前沒有翻譯範例,請至原文觀看實際範例)

1 從需求著手*
*是使用者需要什麼,而不是政府想要什麼

在設計的過程中,我們必須了解、思考,從真正的使用者需求出發。我們應該圍繞著這些設計服務──而不是像現在圍繞著「官樣程序」。我們必須透澈地了解──從數據資料中找出答案,別用瞎猜的──還有我們要記住,使用者想要的並不總是他們所需要的。

我們以「需求」當為思考整個數位服務原則時的中心思想,因為民眾來到我們的網站是要完成工作並滿足他們的需求,而不只是上來閒晃。集中資源在民眾的需求,代表我們可以專心讓預算發揮在最大效益的事上。


2 做少點

政府應該做只有政府才能做到的事。如果有別人做了──連結過去。如果我們可以提供資源(像是APIs),可以幫助其他人做事──就要提供它。我們應專心在不可或缺的核心部份。

藉著集中資源於應該在的地方,我們可以提供更好的服務,並省下更多預算。


3 隨著資料而設計

一般來說,我們不是從零開始──使用者已經在使用我們的服務。這表示我們可以從實際的行為中了解使用者。我們應該這樣做,並且我們要確定在建立與發展服務的過程中,都要這樣做──雛型建立和測試都在實際的網路上,與真正的使用者互動。我們應該要了解,我們如何隨著資料而設計?其過程中的期望路徑(desire path)是什麼樣子的?瞭解這些後都要應用在我們的設計之中。

這是數位服務的一大優勢──我們可以觀察且學習使用者的行為。與其讓民眾屈服於我們建立的服務,不如雕塑我們的系統,讓民眾可以自然地做出的下一步。

譯註:
期望路徑(desire path)──在公園中的草地,雖然沒有鋪設走道,但因為經年累月,被人們踏踩而造成幾條光禿禿,沒有草生長的小徑,而這條小徑又會變成之後的人行走時的參考依據。後來引申為當我們進行一件事時,為了要完成目的,自然地產生自己認為最有效率的行為模式,也變成之後其他人做同一件事時的重要參考藍圖。


4 做困難的事,並簡化它

讓一個東西看起來簡單很容易;讓一個東西用起來簡單就難多了──特別是底下的系統盤根錯節──但這就是我們理應要做的事。

能力愈大,責任愈大──絕大多數人別無選擇,只能使用我們的服務。如果我們不努力地讓這些服務變得更簡單且實用,我們就濫用了這項權力,還會浪費人民的時間。


5 重複。然後再重複。

建立有效服務的最好方式是小做起,然後重複擴大。儘早釋出只有基本功能但可運行的產品,由真實的使用者測試,從AlphaBeta測試,直到完成上線,根據實際使用後的回饋,修改、增加服務的功能。

「重複」可以減少風險。它減少大失敗的發生機率,並且可以讓小失敗變成我們學到的教訓。這樣做可避掉200頁的規格文件,及其所可能造成的瓶頸。這樣做,再一次地顯示出數位的核心優勢:我們不是在建一座橋──事情可以「回到上一步」。


6 為廣納民眾而建構

無障礙設計是好設計。我們應該建構一個儘可能有廣納性(inclusive)、易辨性(legible)、可讀性(readable)的產品。如果我們會因此而犧牲掉優雅的感覺──那就犧牲掉。別擔心平淡的外觀,別試著重新發明網頁設計協定,但應清楚地設定好使用者會預期的部份。

我們是為了整個國家的人民而設計──而不是只為了那些有網路經驗的人。事實上,最需要我們服務的人民,通常也是那些覺得服務難以使用的人。如果我們一開始思考時,就以那些人為對象,我們就可以為每個人提供更好的服務。


7 了解使用者的環境

我們不是為了螢幕設計,是為了民眾而設計。我們需要努力地思考他們是在什麼環境背景下使用服務。他們在圖書館?他們使用手機?他們真的只熟悉臉書?他們是否從未接觸網路?

我們的對象包含了不同的族群,使用著不同的科技與不同的需求。我們需要確定自己已經了解,服務會在哪些科技與實際情境下運行。不然的話我們只是冒險設計了一個很漂亮,但卻和民眾的生活無關的服務。


8 建立數位服務,而不是網站

我們提供的服務不會只從網站開始,也不會在網站結束。服務可能從搜尋引擎開始,然後在郵局完成。我們需要這樣設計,儘管我們無法控制別人如何使用。我們需要認知到有一天,在知道那一天來臨之前,它會再次成為不同的數位服務。

我們要考慮的不是網站,我們應該考慮的是數位服務。到目前為止,我們的數位服務的媒介是網頁,但情況也許會改變,並且可能比我們想像的還要快。


9 一致化,但不僵化

不論何處,我們應使用相同的語言與設計模式──這樣可以幫助民眾熟悉我們所提供的服務。但是當這點無法達成時,我們至少要確定服務的基本使用方式是一致的。因此民眾將可以有一定程度的機會,可以猜出他們要怎麼做。

這不是一套給病患穿的約束衣或是一本規則。要求民眾死記硬背才能完成的服務,不是一個好服務。我們沒有辦法想到每一種情況,然後針對各情況寫出守則。每一種狀況都不同,並且只有相對應的方式能夠處理。什麼事情可以讓我們的服務整合在一起,它就會成為我們持續的作法──這個作法可以讓使用者開始了解並且信任──甚至當我們進入到新的數位空間時,也會如此。


10 讓事情公開化:它讓事情變得更簡單

只要可以,我們應該隨時分享我們正在做什麼。與同事分享、與使用者分享、與世界分享;分享程式碼、分享設計、分享意見、分享目的、分享失敗。愈多雙眼睛注視著,我們提供的服務就會變得愈好──隨著發覺缺失、提出更多選項,我們也跟著不斷進步。

部份原因是我們所做的這些之所以成為可能,多虧了開放原始碼和網路設計社群的慷慨成果,所以我們理當回饋。但最主要還是因為愈多的開放,就會有愈好的服務──可以受到更好的了解和檢視。如果我們釋出程式碼,我們將會獲得更好的程式碼。這也是為什麼我們要寫出這些原則…



譯者的話:
所以,如果你覺得有任何應該要注意,這篇文章卻沒有提到的原則,歡迎提供意見與回饋。
可以的話,直接寫電子郵件給英國政府吧。

沒有留言:

張貼留言

為避免垃圾訊息,留言需檢視後會才會顯示,請見諒。