현재 위치:   » 테크 » 영국 정부의 디지털 서비스 설계 10대 원칙

영국 정부의 디지털 서비스 설계 10대 원칙

“우리가 만드는 것은 디지털 서비스지, 웹사이트가 아니다.”

영국 정부의 디지털 서비스 설계 원칙을 소개합니다. 웹표준은 고사하고 검색조차 제대로 되지 않은 국가기관 사이트가 적지 않고, 무수히 많은 액티브엑스, 공인인증서와 씨름해야 하는 우리 상황에서 영국 정부가 제시하는 10대 원칙은 많은 시사점을 줍니다.

‘개발자 영어’를 운영하는 김나솔 님께서 번역했습니다. 그리고 번역 작업에는 개발자 영어 회원분들께서 큰 도움을 주셨습니다. 번역문과 원문은 오픈 거버먼트 2.0 라이센스(Open Government Licence v2.0)하에서 자유롭게 이용할 수 있습니다. (편집자)

정부 디지털 서비스 설계 원칙
https://www.gov.uk/designprinciples

정부의 디지털 서비스 설계 원칙

우리의 서비스 설계 원칙과 그 적용사례를 소개한다. 이 원칙은 디지털 7대 원칙을 기반으로 보완하여 만든 것이다.

1 사용자에게 필요한 것에서 시작하라.
2 정부만 할 수 있는 것에 집중하라.
3 데이터에 기반하여 설계하라.
4 사용하기 쉽게 하기 위해 수고를 마다하지 말라.
5 빨리 선보이고, 피드백 받고, 이 사이클을 여러 번 반복하라.
6 다양한 사용자를 감안하여 설계하라.
7 사용자가 서비스를 사용하는 상황을 고려하라.
8 디지털 서비스를 만들라. 웹사이트가 아니라.
9 일관성은 지키되 획일적이지는 말라.
10 공유하라. 사람들이 참여하고, 서비스는 개선될 것이다.

1. 사용자에게 필요한 것*에서 시작하라

*정부에게 필요한 것이 아니라 사용자에게 필요한 것.

설계는 사용자의 요구에서 시작해야 한다. 실제 사용자의 요구가 무엇인지 확인하고, 이에 대해 생각하는 것이 디지털 서비스 설계의 첫걸음이다. 현재 정부의 ‘절차’가 이것이니까, 이것을 위한 서비스를 설계해서는 안 된다. 실제 사용자의 필요가 무엇인지를 철저하게 이해해야 한다. 단, 상상으로 요구를 아는 것이 아니라, 데이터를 수집하고 이에 근거해서 사용자가 필요로 하는 게 무엇인지 파악해야 한다. 또한, 사용자가 만들어달라고 요구한다고 해서, 이것이 반드시 사용자의 필요와 일치하는 것은 아니라는 점을 주의해야 한다.

우리는 디지털 서비스를 설계하는 데 있어서 사용자의 ‘필요’를 근본 원칙으로 삼는다. 사람들은 우리 사이트에 놀러 오는 것이 아니다. 정보를 얻거나 업무를 처리하러 온다. 사용자의 ‘필요’에 초점을 맞춘다는 것은 즉, 같은 비용을 들였을 때 사이트에서 가장 가치있는 것을 제공하는 것을 추구한다는 것이다.

2. 정부만 할 수 있는 것에 집중하라

정부는 정부만 할 수 있는 일만 해야 한다. 다른 데서 제공하는 서비스라면, 이 서비스로 가는 링크를 제공하면 된다. API 같은 서비스를 제공해서 다른 사람들이 서비스를 만들 수 있다면, 정부는 API 같은 서비스를 제공해야지, 직접 해당 서비스를 만들지 말아야 한다.

우리가 가진 자원을, 우리만이 할 수 있는 곳에 집중해야, 더 나은 서비스를 만들 수 있고 돈도 절약할 수 있다.

3. 데이터에 기반하여 설계하라

보통 디지털 서비스를 설계할 때, 완전히 새로운 서비스를 만들지는 않는다. 이미 우리 서비스를 이용하는 사용자들이 있다. 즉, 실제 사용자의 행동에 대해 알 수 있다. 우리는 실제 사용자의 행동에 대해 알아야 하고, 또 알아낸 것을 서비스를 설계, 구현하는 과정에 반영해야 한다. 그리고 서비스 프로토타입을 만들면 실제 사용자에게 웹상에서 테스트해봐야 한다. 사용자에 대한 데이터를 실제로 사용해서 서비스를 설계하는 과정에 대해 이해해야 한다.

실제 사용자의 데이터를 서비스 설계하는 데 사용할 수 있다는 것은 디지털 서비스의 큰 장점이다. 사용자의 행동을 관찰하고 그들을 더 깊이 이해할 수 있다. 그 결과, 사람들이 우리 서비스를 이용하려고 자기 행동을 바꾸게 하는 것이 아니라, 우리 서비스를 사용자에게 맞추어서, 사용자들이 자연스럽게 행동해도 원하는 것을 얻을 수 있게 할 수 있다.

4. 사용하기 쉽게 만들기 위해서는 수고를 마다하지 마라

서비스를 단순하게 보이게 만드는 일은 어렵지 않다. 그러나 서비스를 사용하기 쉽게 만드는 일은 훨씬 더 어렵다. 특히 그 서비스 밑에 깔린 시스템이 복잡할 때에는 더 어렵다. 밑에 깔린 시스템이 복잡할수록 우리는 더더욱 서비스를 사용하기 쉽게 만들어야 한다.

힘이 있으면 책임도 따르는 법이다. 사람들은 우리 서비스가 마음에 안 들어도 다른 서비스를 선택할 수 없다. 서비스를 사용하기 쉽게 만들지 않으면, 우리가 가진 힘을 남용해서 사람들의 시간을 낭비하는 셈이 된다.

5. 빨리 선보이고, 피드백 받고, 이 사이클을 여러 번 반복하라

좋은 서비스를 만드는 가장 좋은 방법은 작게 시작하고, 피드백 받아서 적용하는 주기를 짧게 하는 것이다. 선보일 수 있는 서비스를 빨리 출시하고, 실제 사용자를 대상으로 테스트하라. 그리고 실제 사용자에게서 받은 피드백을 사용하여 기능을 추가하고 개선하여, 알파 버전에서 베타 버전으로, 정식 공개 버전으로 넘어가라.

이런 사이클을 반복하면 위험을 피할 수 있다. 서비스가 크게 실패할 가능성이 줄어들고, 작은 실수는 개선하는 기회로 사용할 수 있다. 이런 사이클을 반복하면, 200페이지짜리 명세문서가 필요 없다. 이런 점 역시 디지털 서비스의 장점이다. 우리는 무슨 엄청난 다리를 건설하는 게 아니다. 한 번 만들어 놓아도, 바꿀 수 있다.

6. 다양한 사용자를 감안하여 설계하라

사용자가 접근할 수 있는 디자인이 좋은 디자인이다. 누구나 읽을 수 있고, 읽기 쉽게 서비스를 설계해야 한다. 읽기 쉬우려면 우아함을 포기해야 하는가? 포기해라. 명확하게 보이는 것에 대해 두려워해서는 안 된다. 웹 디자인 관행을 바꾸려고 해서는 안 된다. 사용자가 어떤 행동을 해야 하는지에 대해 명확하게 보여주어야 한다.

우리는 웹에 익숙한 사용자만 위해서 서비스를 만드는 게 아니다. 나라 전체를 위해서 만든다. 사실, 우리 서비스를 필요로 하는 사람은 웹서비스 사용하는 것을 어려워하는 경우가 더 많다. 이런 사용자들을 생각한다면, 모든 사용자를 생각했을 때, 더 나은 사이트를 만들어야 한다.

7. 사용자가 서비스를 사용하는 실제 상황을 고려하라

컴퓨터 화면만을 생각해서 서비스를 설계해서는 안 된다. 서비스를 사용하는 사람들을 위해서 만든다는 점을 기억해야 한다. 사람들이 어떤 상황에서 우리 서비스를 이용하는지 깊이 생각해 보아야 한다. 도서관에서 사용하는가? 전화기에서 접속하는가? 페이스북 서비스에만 친숙한 사용자인가? 웹을 한 번도 사용해본 적이 없는 사용자인가?

우리 서비스를 사용할 사용자는 매우 다양하다. 사용하는 기술도 다양하고 요구도 다양하다. 서비스를 설계할 때에는 사용자가 어떤 환경에서 우리 서비스를 사용하는지 철저하게 이해해야 한다. 이런 부분을 간과하고 서비스를 만들면, 보기에는 좋은 서비스를 만들지는 모른다. 하지만 사람들이 사용하지는 못할 수도 있다.

8. 우리가 만드는 것은 디지털 서비스지, 웹사이트가 아니다

사람들이 우리 웹사이트에서 우리 서비스를 사용하기 시작하는 것이 아니다. 또한, 우리 웹사이트를 떠난다고 해서 우리 서비스가 끝나는 것도 아니다. 사용자는 검색엔진에서 우리 서비스를 사용하기 시작할 수도 있고, 우체국에서 사용하기 시작할 수도 있다. 서비스를 설계할 때에는 이런 부분도 고려해야 한다. 훗날에는 전혀 다른 상황에서 쓰이는 서비스가 될 수도 있다.

우리가 만드는 것은 디지털 서비스이지, 웹사이트가 아니다. 지금 당장은 웹으로 디지털 서비스를 제공하는 것이 가장 좋기 때문에 웹사이트를 만드는 것뿐이다. 하지만 이는 바뀔 수 있으며, 바뀌는 시점은 생각보다 빨리 올 수 있다.

9. 일관성을 지키되 획일적이지는 마라

가능하면 사용하는 표현을 바꾸지 마라. 그리고 설계의 패턴도 일관되게 하라. 이렇게 하면 사람들이 우리 서비스에 익숙해진다. 물론 일관되게 하기 어려운 상황도 있다. 그래도 접근방법은 일관성을 지켜야 한다. 그러면 사용자는 서비스에서 원하는 것을 얻으려면 무엇을 어떻게 해야 하는지 추측할 수 있을 것이다.

일관성을 지키라는 것은 무조건 따라야 하는 규칙이 아니다. 기계적으로 규칙을 따르는 방법으로는 훌륭한 서비스가 나오지 않는다. 모든 상황을 생각해서, 그 상황에 적용되는 규칙을 모두 미리 생각해둘 수는 없다. 각 상황에 맞게 적절하게 대처하는 수밖에 없다. 따라서 통일할 수 있는 것은 접근방식이다. 사용자가 우리의 접근방식을 이해하면, 우리가 전혀 새로운 디지털 공간에서 서비스하더라도, 사용자는 서비스를 수월하게 사용할 수 있을 것이다.

10. 공유하라. 사람들이 참여하고, 서비스는 개선될 것이다

언제든, 우리가 작업하는 것을 공유해야 한다. 동료와 공유하고, 사용자와 공유하고, 전 세계와 공유해야 한다. 코드, 디자인, 아이디어, 설계의도, 실패경험 등 모든 것을 공유하라. 더 많은 사람들이 서비스를 살펴보고, 서비스는 개선될 것이다. 사람들은 어이없는 실수를 발견할 것이고, 더 나은 대안을 제시할 것이다. 그 결과 서비스도 나아질 것이다.

우리가 작업하는 것을 공유해야 하는 이유 중에 부수적인 이유는 이렇다. 오픈소스 코드 없이는, 그리고 웹디자인 커뮤니티가 없이는 우리가 하는 작업이라는 것이 불가능하기 때문이다. 하지만 이보다 더 중요한 이유는, 공유하면 서비스가 더 나아지기 때문이다. 서비스를 공개해서 많은 사람들이 참여하면, 서비스 자체에 대한 이해가 깊어지고, 더 세심하게 살펴보게 된다. 우리가 만든 코드를 공개하면, 더 나은 코드가 돌아온다. 바로 그 때문에 우리는 코드를 공유한다.

Government Digital Service Design Principles

Listed below are our design principles and examples of how we’ve used them so far. These build on, and add to, our original 7 digital principles.

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 services, not websites
9 Be consistent, not uniform
10 Make things open: it makes things better

1. Start with needs*

*user needs not government needs

The design process must start with identifying and thinking about real user needs. We should design around those—not around the way the ‘official process’ is at the moment. We must understand those needs thoroughly—interrogating data, not just making assumptions—and e should remember that what users ask for is not always what they need.

We use ‘needs’ as an organising principle since people come to our sites to accomplish tasks and to fulfil needs, not just to hang out. Focusing on needs means we can concentrate on the things that deliver most value for money.

2. Do less

Government should only do what only government can do. If someone else is doing it—link to it. If we can provide resources (like APIs) that will help other people build things—do that. We should concentrate on the irreducible core.

We’ll make better services and save more money by focusing resources where they’ll do the most good.

3. Design with data

Normally, we’re not starting from scratch—users are already using our services. This means we can learn from real world behaviour. We should do this, but we should make sure we continue this into the build and development process—prototyping and testing with real users on the live web. We should understand the desire paths of how we are designing with data and use them in our designs.

This is the great advantage of digital services—we can watch and learn from user behaviour, shaping the system to fit what people naturally choose to do rather than bending them to a system we’ve invented.

4. Do the hard work to make it simple

Making something look simple is easy; making something simple to use is much harder—especially when the underlying systems are complex—but that’s what we should be doing.

With great power comes great responsibility—very often people have no choice but to use our services. If we don’t work hard to make them simple and usable we’re abusing that power, and wasting people’s time.

5. Iterate. Then iterate again.

The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products early, test them with real users, move fromAlpha to Beta to Launch adding features and refinements based on feedback from real users.

Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. This avoids the 200 page spec document which can turn into a bottleneck. This, again, is the core advantage of digital: we’re not building bridges—things can be undone.

6. Build for inclusion

Accessible design is good design. We should build a product that’s as inclusive, legible and readable as possible. If we have to sacrifice elegance—so be it. We shouldn’t be afraid of the obvious, shouldn’t try to reinvent web design conventions and should set expectations clearly.

We’re designing for the whole country—not just the ones who are used to using the web. In fact, the people who most need our services are often the people who find them hardest to use. If we think about those people at the beginning we should make a better site for everyone.

7. Understand context

We’re not designing for a screen, we’re designing for people. We need to think hard about the context in which they’re using our services. Are they in a library? Are they on a phone? Are they only really familiar with Facebook? Have they never used the web before?

We’re designing for a very diverse group of users with very different technologies and needs. We need to make sure we’ve understood the technological and practical circumstances in which our services are used. Otherwise we risk designing beautiful services that aren’t relevant to people’s lives.

8. Build digital services, not websites

Our service doesn’t begin and end at our website. It might start with a search engine and end at the post office. We need to design for that, even if we can’t control it. And we need to recognise that some day, before we know it, it’ll be about different digital services again.

We shouldn’t be about websites, we should be about digital services. Right now, the best way to deliver digital services is via the web—but that might change, and sooner than we might expect.

9. Be consistent, not uniform

Wherever possible we should use the same language and the same design patterns—this helps people get familiar with our services. But, when this isn’t possible, we should make sure our underlying approach is consistent. So our users will have a reasonable chance of guessing what they’re supposed to do.

This isn’t a straitjacket or a rule book. We can’t build great services by rote. We can’t imagine every scenario and write rules for it. Every circumstance is different and should be addressed on its own terms. What unites things, therefore, should be a consistent approach—one that users will hopefully come to understand and trust—even as we move into new digital spaces.

10. Make things open: it makes things better

We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets—howlers get spotted, better alternatives get pointed out, the bar gets raised.

Partly because much of what we’re doing is only possible because of open source code and the generosity of the web design community. So we should pay that back. But mostly because more openness makes for better services—better understood and better scrutinised. If we give away our code, we’ll be repaid in better code. That’s why we’re giving away all this…

좋은 기사 공유하고 알리기
슬로우뉴스에 커피 한잔의 여유를 후원해주세요. 필자 원고료와 최소한의 경비로 이용됩니다.

필자 소개

김나솔
초대필자, 개발자영어 운영자

개발자영어 운영자 engfordev.com

작성 기사 수 : 1개
필자의 홈페이지 필자의 페이스북 필자의 트위터

©슬로우뉴스 | 개인정보취급방침 | 청소년보호정책 | 슬로우뉴스 안내 | 제보/기고하기 | 제휴/광고문의
등록번호: 경기아51089 | 등록일자: 2014년 2월 10일 | 발행일: 2012년 3월 26일
주소: 경기도 성남시 분당구 동판교로 153 802-902 | 발행인: 김상인 | 편집인: 강성모 | 청소년보호책임자: 강성모

Scroll to top