1 니즈분석 : 사용자에게 필요한 것에서 시작하라. (Start with user needs)
서비스 디자인은 사용자의 니즈를 정의하는 곳에서 시작한다.
사용자의 니즈를 모른다면 올바르게 만들 수 없다.
가정하지 말고, 리서치하고, 데이터를 분석하고, 사용자들과 이야기해라.
사용자들과 공감을 하되, 사용자들이 요청하는게 실제로 원하는게 아닐 수 있음을 명심해라.
2 포지셔닝 : 우리만 할 수 있는 것에 집중하라. (Do less)
정부는 정부만이 할 수 있는 일에만 집중해야한다.
어떤 업무를 잘 수행할 수 있는 방식을 찾았다면, 수행할 때마다 업무 방식을 고안하지 말고, 반복적으로 수행할 수 있고, 공유가 가능하게끔 만들어야한다.
즉, 플랫폼을 만들고, API 같은 요소를 제공하고, 여러 사람의 업무를 이어주는 것을 말한다.
가장 핵심 기능만 제공해주어야 한다.
3 데이터 드리븐: 데이터에 기반하여 설계하라. (Design with data)
기존 서비스가 이용되는 방식을 관찰하면서 사용자의 실제 행동을 배울 수 있다. 직감, 추측보다는 데이터를 기반으로 판단하자.
서비스를 제공하고, 프로토타이핑하고, 유저가 서비스테스트를 할 때, 이를 명심하라.
분석은 항상 진행되어야되고, 분석 데이터를 읽기 쉬워야한다.
4 UX: 사용하기 쉽게 하기 위해 수고를 마다하지 말라. (Do the hard work to make it simple)
단순해보이는 것을 만드는 건 쉽다.
사용하기 단순해보이는 것을 만드는 것은 꽤 어렵다.
특히 내부 시스템이 복잡하다면 더더욱 어려워진다.
하지만 꼭 해야만 하는 일이다.
'원래 그랬는 걸'은 안될 말이다.
단순하게 만드는 것은 일을 늘리고, 어려워지게 하지만, 해야하는 올바른 일이기도하다.
5 애자일 : 빨리 선보이고, 피드백 받고, 이 사이클을 여러 번 반복하라. (Iterate. Then iterate again)
좋은 서비스를 만드는 최선의 방법은 규모를 작게 시작한 다음, 조금씩 규모를 키우는 것이다.
MVP(Minimum Viable Product)를 빠르게 런칭하고 실제 사용자들이 사용하는 것을 테스트해라. 알파에서 베타버전까지 기능들을 계속 추가하고, 필요없는 기능은 삭제해라.
피드백을 바탕으로 수정을 진행한다.
위 과정의 반복은 위험을 줄인다. 서비스가 폭망하는 것을 막아주고, 자잘한 실패들은 교훈이 된다.
만약에 프로토타입이 망했다면, 전혀 두려워할 것 없이 이를 교훈삼아 다시 시작해라
6 확장성: 다양한 사용자로 확장될 것을 감안하여 설계하라. (This is for everyone)
접근성이 좋은 디자인이 좋은 디자인이다. 우리가 만드는 모든 서비스는 배타적이면 안되며, 읽기 쉬워야한다. 그 과정에서 우아함을 잃더라도 그렇게 하라. 우리는 청중이 아닌 니즈를 위해 서비스를 만든다. 우리는 웹에 익숙한 사람만이 아니고 전국민을 위해 서비스를 만든다. 서비스를 필요로 하는 사람들은 대개 인터넷이 어려운 사람들이다. 그 사람들로부터 우리의 생각은 출발해야한다.
7 UX2: 사용자가 서비스를 사용하는 상황을 고려하라. (Understand context)
우리는 모니터 화면이 아니라 사람을 위해 디자인한다.
서비스를 이용하는 이들의 맥락을 깊게 고민해야한다.
이 사람들은 도서관에 있는가? 스마트폰을 이용 중인가? Facebook에 익숙한가? 컴퓨터를 사용해보지 않은 사람들인가?
8 목적성: 웹사이트가 아닌 '디지털 서비스'를 만들라. (Build digital services, not websites)
서비스는 사람들이 어떤 일을 하는데 도움을 주는 것이다.
사용자의 니즈를 파악하고, 그 니즈를 충족하는 서비스를 만들어야한다.
물론 서비스의 대부분은 웹상의 페이지이겠지만, 이는 웹사이트를 만드는 것이 아니다.
디지털은 현실과 연결되어야 한다.
우리는 서비스의 모든 경우를 생각해야하고, 사용자의 니즈를 충족하도록 만들어져야한다.
9 서비스컨셉: 일관성은 지키되 획일적이지는 말라. (Be consistent, not uniform)
되도록 같은 언어와 같은 디자인패턴을 사용해야한다.
그렇게 되면 사람들은 서비스에 친숙해진다.
그렇지 못한 경우에서는 우리의 접근 방식이 일관적인지 확인해야한다.
이는 상황마다 다를 수 있으므로 강제되는 규칙은 아니다.
서비스가 이뤄지는 패턴이 있다면 이를 공유하고, 왜 그런지 토의해야한다.
사용자의 니즈가 바뀌고, 더 나은 패턴이 있다면 나아가는 것을 주저하지 말아야한다.
10 피드백: 공유하라. 사람들이 참여하고, 서비스는 개선될 것이다. (Make things open: it makes things better)
가능할 때마다 작업물을 동료, 사용자, 세상에 공유해야한다.
코드, 디자인, 아이디어, 어떤 행동에 대한 의도, 실패를 공유해라.
서비스가 많은 눈길을 받게 되면, 그 서비스는 계속해서 나아질 것이다.
오픈소스와 웹디자인커뮤니티의 관대함으로 우리의 작업은 가능해진다.
우리는 이를 다시 환원해야한다.
영국정부의 웹서비스 제작 설계 원칙이다.
물론 이를 일반적인 웹서비스 설계에 100% 적용할 수는 없다.
하지만 대부분의 이야기들이 왜 웹서비스가 존재해야하는 지에 대한 이유를 되짚어주고, 나아가야할 방향을 제시해준다고 생각한다.
그래서 꼭 공공서비스에 국한되는 이야기가 아니라 IT서비스 전체에 통용되는 이야기라고 생각해서 번역을 하게 되었다.
나도 앞으로 어떤 서비스를 기획하거나 제작할 때 이를 명심해야겠다고 생각했다.
