블록체인 응용 서비스 디자인을 위한 방향성 가이드
ethcon korea 2019 강연 내용
블록체인 응용 서비스 디자인을 위한 방향성 가이드
이 포스팅은 블록체인 서비스 기획에 처음 참여하는 디자이너를 대상으로 내용을 구성했습니다.
꼭 디자이너나 기획자가 아니더라도 앞으로 UX 디자이너와 협업하기 위해, 디자이너가 고민하는 부분이 궁금한 관계자분들께 도움이 되었으면 좋겠습니다. 모든 내용은 저의 서비스 기획 경험을 바탕으로, 사용성 개선을 위해 적용한 개인적인 기준임을 미리 말씀드립니다.
(또한 본 글은 제가 ‘ethcon korea 2019’ 에서 발표한 것을 정리한 내용임을 말씀드립니다.)
DApp 서비스의 불편함
저는 DApp 서비스를 기획하면서 많은 문제에 마주치게 됐는데요. 거래 속도가 느리고, 첫 진입 장벽이 높고, 또 어떤 서비스는 코인이 없으면 서비스의 매력을 체험해 볼 기회가 없다던가, 그러면서도 가이드는 불친절한 서비스들을 많이 보게 되었습니다.
DApp 의 불편하고 복잡한 서비스 흐름, 어려운 요소들과 생소한 Task로 인한 불편한 사용성 문제 등 UX 디자이너가 DApp 서비스 기획에서 고민하는 다양한 주제들이 있습니다.
그중에서도 저는 사용성을 높여주는 디테일한 인터랙션에 관한 이야기를 하고 싶습니다.
DApp 서비스를 기획하면서 느낀 수많은 UX 과제들..우리 DApp서비스의 사용성은 어떤가요?
블록체인 기술 기반 서비스에서 좋지 않은 사용성 문제를 해결하려면 어떤 기준들이 필요할까요?
그 기준을 세우기 위해 기획하고 있는 서비스에게 몇 가지 질문을 던지게 되었습니다. 사용성의 질적인 특성을 확인하는 여러 가지 질문 중, DApp 서비스 기획에서 꼭 필요다고 생각한 세 가지만 가져와봤습니다.
사용성의 질적인 특성을 확인하는 질문 일부(참고: NNgroup Usability 101)(1) 첫째로, 유저가 처음 화면을 보고 얼마나 쉽게 main task를 수행하는지입니다. 이것은 경험에 기초하여 유저의 학습 용이성을 판단할 수 있는 내용입니다. ‘가장 좋은 서비스 가이드’는 가이드가 없는 것입니다. 서비스가 그 자체만으로도 직관적으로 구성되어 있으면 가이드가 필요 없을 텐데요.
하지만 아직 DApp 서비스들은 일반 유저에게 불가피하게 학습을 요구하는 부분들이 있습니다. 아직 익숙하지 않기 때문입니다. 그렇기 때문에 좋은 가이드와 시각적 보조 장치가 필요합니다.
(2) 두 번째는 유저가 서비스에 대해 학습이 된 상태에서 얼마나 빠르고 편리하게, 익숙하게 task를 수행하는지, 즉 task의 효율성에 대해 점검해야 합니다.
(3) 마지막으로는 실수와 에러에 대한 대처인데요, 사용자가 얼마나 쉽게 실수로부터 되돌아오게 하고, 실수를 방지하는지 잘 고려해야 합니다.
이 질문에 좋은 대답을 할 수 있다면 그 서비스는 사용자 중심의 구성을 위한 노력의 일부를 하고 있는 것이라고 생각합니다.
DApp UX Checklist
서비스가 다양해서 일반화할 수는 없지만, 위와 같은 질문들에 잘 대답할 수 있는 좋은 사용성을 갖추기 위한 제 나름의 체크리스트를 만들었는데요.
DApp 서비스 기획에 필요한, 실수로 간과하지 않아야 할 기본적인 항목들이라고 생각하는 내용을 정리해봤습니다.
1. 상태의 가시성
어떤 행동을 하기 이전, 현재, 미래의 상태에 대해 유저가 인지할 수 있도록 해주는 것이 특히나 블록체인 기술 기반 서비스에서 중요합니다.
일반 비 개발자 유저에게 DApp 서비스를 사용해보도록 했을 때, 오랜 지연으로 인해 유저가 당황하거나 이탈하는 경우가 있었습니다. 또, 어떤 버튼을 누를 때마다 가장 많이 하는 말은 ‘이 다음에 어떻게 해야 해?’ 라는 말이었습니다.
지금부터 나올 예시는 DApp을 개발할 수 있는 IDE(Integrated Development Environment)입니다. ( De-Labtory 팀에서 구현 중입니다.)
De-Labtory 팀이 개발 중인 IDE 화면의 일부 컴포넌트(변경 전)예시로 이건 IDE 의 일부 component입니다. 세 개의 단계로 나누어져 있는데, 현재 두 번째 단계까지 성공한 상황입니다. 이걸 본 일반 유저는 다음과 같은 혼란을 겪었습니다.
여기서 두 번째 단계까지 성공했다는 것을 잘 인지하지 못함
전체 중에 현재 어느 단계까지 진행되었고 앞으로 얼마나 남았는지 예측하지 못함
이 다음에 어떻게 행동해야 할지 몰라서 추가적인 행동을 취하지 않음
De-Labtory 팀이 개발 중인 IDE 화면의 일부 컴포넌트(변경 후)그래서 변경한 화면은 성공한 상황에 대해 더 명확한 메시지를 전달해주고, 인디케이터 바를 통해 진행 상황을 알려주었습니다.
또한 버튼에서 이미 그 task가 진행되었다는, ‘already deployed’라는 명확한 UI 텍스트를 제공하고, 성공한 결과를 선택해서 다음 단계로 넘어갈 수 있다는 가이드를 제공했습니다.
CryptoDozer, Metamask이건 ‘CryptoDozer’ 라는 DApp 게임 화면의 일부 요소입니다. 제가 지금 이더리움을 지불하고 PLA를 구매한 상황입니다.
여기서 저기 보이는 processing이라는 표시가 없었다면, 참을성이 없는 유저는 돈을 지불하고 PLA를 얻지 못한 상황에 대해 혼란스러움을 겪을 수 있습니다.
하지만 processing이라는 표시로 아직 상태가 완료되지 않았다는 것을 알고 안심하고 기다릴 수 있습니다. 사실 어느 정도 소요될 것인지, 어느 정도 진행됐는지 알 수 있으면 좋겠지만 기술적으로 그 정보를 알아내고 보여주기 쉽지 않기 때문에 이 정도의 타협안이 적당한 것 같습니다.
그리고 구매가 완료되고 나서는 매타마스크라는 프로그램이 성공적으로 구매가 이루어졌음을 알려주는 피드백을 제공하고, 그 내역을 확인할 수 있는 곳으로 바로 이동시켜줍니다.
이런 장치들을 이용하면 상태의 가시성을 높이면서 다음 행동으로 유도할 수 있습니다.
2. 서비스 대상에게 적합한 표현
두 번째는 user-side의 표현을 사용하는 것입니다. 아무리 기술적인 표현의 텍스트가 블록체인 기술의 가치를 잘 드러낸다고 하더라도, 그것을 날 것 그대로 표현하면 어차피 유저한테는 와닿지 않고 학습에 대한 두려움만 안겨주게 됩니다.
그래서 블록체인이 제공하는 기술적 가치를 서비스 가치로 돌려서 표현하려는 노력이 필요합니다.
가장 훌륭한 카피라이터는 사용자라고 합니다. 유저가 생각하는 걸 표현하고자 할 때는 그들이 사용하는 단어를 쓰는 것이 좋습니다.
지금부터 나올 예시는 DApp 게임 화면의 일부입니다. 기획 진행을 위한 wireframe 화면이며, 날 것 그대로의 화면이어서 보기에 불편할 수 있습니다. ( De-Labtory 팀에서 구현 중입니다.)
이 게임은 유저가 NFT를 수집하고 육성하는 메카닉의 게임입니다.
NFT란 Non-Fungible Tokens을 줄여서 쓴 말로, 블록체인 네트워크상에서 구현된 대체 불가능한 토큰입니다. 이 토큰은 다른 이들과 거래하거나 전달할 수 있고, 저마다의 고유한 식별자를 갖고 있다는 특징이 있습니다.
아래 장면은 이더리움을 지불하고 다른 유저의 NFT를 얻으려고 하는 상황입니다.
De-Labtory 팀이 기획 중인 DApp 게임 화면의 일부 컴포넌트(변경 전)이 화면을 본 유저는 ‘Token’, ‘NFT’,’ Transaction’… 이런 표현들이 익숙하지 않아서 검색을 해야만 했습니다. 게다가 ‘Offer price’를 기입하는 인풋 창에 이더리움을 입력해야 하는데, 이게 현금으로 어느 정도의 금액인지 가늠하기가 어렵습니다. 그래서 검색하기 위해 또다시 외부로 이탈하게 됩니다.
실제로 이런 화면을 마주한, heavy user가 아닌 거의 대부분의 사람들이 그런 식으로 이탈했습니다.
그래서 표현을 바꿔보았습니다.
De-Labtory 팀이 기획 중인 DApp 게임 화면의 일부 컴포넌트(변경 전,후 비교)물론 더 다듬을 필요가 있겠지만, 일부 표현들이 바뀌고 추가적인 장치가 생긴 것을 알 수 있습니다.
‘NFT Number’라는 표현 대신에 ‘Gene number’ 라는 표현으로 돌려서 사용하고, 이더리움은 달러나 원화로 바로 변환되어서 따로 얼마인지 검색하러 이탈할 필요가 없어졌습니다.
물론 여기에서 ‘transaction fee’라고 표현해야 이 ‘fee’는 중앙 관리자가 먹는 수수료가 아니라는 걸 더 잘 인지할 수 있을 거라고 생산자들은 생각할 수도 있습니다. 하지만 어차피 일반 유저는 ‘transaction fee’라고 표현한다고 한들 그런 내용을 알지 못합니다. 차라리 그냥 ‘fee’라고 표현하고, 도움말 툴팁을 이용해서 이것이 어떤 목적으로 사용되는 수수료인지 풀어서 설명해주는 것이 좋을 수 있습니다.
3. 에러나 실수에 대처하는 친절한 인터랙션 제공
마지막으로, 에러나 실수에 대처하는 친절한 인터랙션을 제공합니다.
사람들은 항상 실수를 하고, 절대 안전한 제품이란 것은 없습니다. 우리는 뭔가가 잘못될 것이라고 가정할 수 있어야 합니다. 우리가 제공할 가이드는 상황에 따라 그 행동의 무게에 맞는 느낌을 주어야 합니다.
DApp 서비스를 이용하는 유저가 다음과 같은 질문을 하는 순간들이 있습니다.
‘그냥 호기심에 버튼을 눌렀는데 이렇게 쉽게 가스가 나가버렸습니다. 어떻게 합니까?’ 또는, ‘이런 중요한 기능을 하는 버튼을 실수로 잘못 눌렀는데, 어떻게 합니까?’
DApp interface에 노출된 개념들이 상대적으로 어렵다 보니, 유저가 그런 실수를 더 범하기 쉽죠.
그래서 그런 실수를 미연에 방지할 수 있도록 하는 경고를 제공하고, 안전한 방향으로 유도를 해야 합니다.
아래에 IDE 예시를 가져왔는데요, 제 계좌에는 지금 20 이더리움이 있는 상황입니다. 제가 이제 어떤 함수를 실행시킬 겁니다.
De-Labtory 팀이 개발 중인 IDE 화면의 일부 컴포넌트(변경 전)우측 하단에 보이는, 노란색의 ‘RUN’ 버튼을 눌러서 함수를 실행시켰습니다.
De-Labtory 팀이 개발 중인 IDE 화면의 일부 컴포넌트(변경 전)갑자기 20 이더리움이 19.9999..ETH로 바뀌었습니다.
무슨 상황일까요? 스마트 컨트랙트에서 코드를 실행하기 위해 gas(수수료)로 약간의 이더리움이 소비된 것입니다.
이 도구를 탐색하는 유저인 개발자들 중에는 함수를 실행시켜서 그에 대한 결과가 나올 것을 인지하고는 있겠지만, 그것을 진행하기 위해 가스가 소비될 수 있다는 사실을 모르는 유저도 있을 수 있습니다.
한 번만 더 물어봐 주지, 소중한 이더리움이 이렇게 허무하게 사라져버렸습니다.
위 예시는 이더리움이 소비되는 행위나 실제 블록체인 서버로 전송되는 행위 등 돌이킬 수 없고 크리티컬한 행위에 대해 조금 무심했던 상황이라고 느껴집니다.
무게가 있는 행동에 대해 너무 쉽게 접근하도록 허용해서 유저가 충분히 당황할 수 있는 상황입니다.
이 함수를 실행시키면 수수료가 든다는 상황에 대해 아래처럼 충분히 설명하고 한 번 더 확인하면 어땠을까요?
De-Labtory 팀이 개발 중인 IDE 화면의 일부 컴포넌트(변경 후)그리고 정확하진 않아도 예상되는 수수료가 얼마라고 표시해주는 겁니다. 또, 이 행동을 하지 않기로 취소하거나, 확실히 실행시키는 선택도 할 수 있죠.
또 다른 상황의 예시가 있습니다. 이건 블록체인 기술 기반이 아닌 다른 서비스에서도 일반적으로 많이 볼 수 있는 상황이지만, 그냥 IDE 예시를 가져와봤습니다.
De-Labtory 팀이 개발 중인 IDE 화면의 일부 컴포넌트이 상황은 쉽게 풀어서 표현하면 문서를 작성하다가 강제로 닫는 상황입니다. 물론 웹 기반의 IDE는 캐시된 파일을 삭제하지 않으면 파일이 날아가지 않을 수도 있습니다. 하지만 유저는 다양한 방해 요인으로 인해 언제든지 강제로 작성 중이던 문서를 종료할 수 있고, 별생각 없이 캐시된 데이터를 삭제할 수도 있습니다.
De-Labtory 팀이 개발 중인 IDE 화면의 일부 컴포넌트(변경 전)여기서 이 문서를 종료할 것인지 위와 같이 한번 더 물어봤습니다. 이렇게 하면 유저가 조금 더 신중하게 결정할 것이라고 나름 생각했습니다.
그런데 여기서 그냥 종료하게 되면 작성 중이던 내용은 어디에 저장될까요?
웹 브라우저에서 실행된 IDE에서는 열심히 작성한 컨트렉트를 서버로 전송하는 디플로이 과정을 거치지 않는 이상 자동으로 어딘가에 저장해주지 않았습니다. 또 로컬 어딘가에 알아서 저장되지도 않았습니다.
그래서 더 친절하게 방향을 제시했습니다.
De-Labtory 팀이 개발 중인 IDE 화면의 일부 컴포넌트(변경 전, 후 비교)안전하게 이탈하기 위해 export 할 수 있는 기능의 버튼을 바로 붙여주고, 취소라는 워딩보다 파일을 유지한다는 ‘keep files’라는 표현을 사용했습니다.
유저가 통제할 수 있는 권한을 다양하게 열어주면서 안전한 방향까지 안내해주었습니다.
또 부가적인 설명 텍스트를 제공하여 돌이킬 수 없는 행위에 대한 주의를 주었습니다.
DApp 기획에서 중요하다고 생각한 3가지 항목에 대해 저의 체크리스트를 여기까지 소개해봤습니다. 그 외에도 추가적으로 생각한 아래와 같은 체크리스트도 있습니다.
사람에겐 어떤 기능에 대해 기대하고, 보고 싶어 하는 멘탈 모델이 있습니다. 경험과 기대에 근거해서 화면을 훑어본다는 것입니다. 그러므로 익숙하고 일관된 UI를 제공하는 건 직관적으로 interface를 구성하는 중요한 열쇠가 될 수 있습니다.
이런 시스템을 잘 구축하는 것만으로도 유저에게 행동 유도의 단서를 제공할 수 있습니다.
디자인 시스템은 서비스의 외관을 결정한다는 면에서도 굉장히 중요합니다. 많은 웹사이트 연구에서 사람은 신뢰의 첫 번째 지표로 외관과 느낌을 사용한다는 결과가 있습니다. (실렌스의 건강 웹사이트에 관련된 연구에서 서비스를 접하는 사람 중 83퍼센트가 외관, 인상, 구성, 색상, 텍스트 크기 등 디자인 요소와 관련된 이유로 해당 웹사이트를 신뢰하지 않았던 사례를 봐도 그렇습니다.) DApp서비스에서 중앙 당국이 없이 내 토큰을 주고받는 거래를 진행하는 과정을 유저가 신뢰하고 진행하도록 하는 데에 일부 영향을 끼치는 요인이 될 수도 있습니다.
그리고, 유저의 행동에 대응하는 인터렉션을 제공하는 것은 서비스 진입 초기 상황에서 익숙하게 제공받는 슬라이더 온보딩이나, 화면 어딘가 구석에 위치한 헬프 버튼(을 눌러서 나온 사용 설명서를 하나하나 읽게 한다던가) 등의 요소로 인한 귀찮음과 지루함, 학습에 대한 두려움을 훨씬 절감시킬 수 있습니다. 유저의 행동에 따른 피드백을 제공해서 자연스러운 학습을 유도하는 것입니다. 학습을 위한 너무 많은 과업은 생각보다 더 많은 스트레스를 유발하기 때문에 조심해야 합니다.
그 외에도 다양한 체크리스트가 있고 앞으로 프로젝트 경험을 쌓아가면서 더 많이, 그리고 잘 다듬어나갈 생각입니다.
다만 주의할 점이 있습니다. 이런 heuristic 평가에 관련된 항목들이 서비스가 지닌 심각한 사용성 결함을 검토하는 기회를 제공하고 문제를 어느 정도는 해결할 수도 있겠지만, 그렇다 하더라도 문제 해결의 핵심 열쇠가 될 것이라고는 할 수 없으며, 이 과정이 사용성 테스트를 대신할 수도 없습니다. 그렇기에 편리한 서비스 구조 설계, prototyping과 테스트의 반복을 통한 잦은 검증, 테스트 후 행동 데이터 분석 등의 과정이 기반이 되어야 한다는 점을 유념해야 합니다.
프로젝트를 진행하는 전반적인 과정에 대해서도 간략하게 저의 생각을 공유합니다.
블록체인 기술을 기반으로 새롭게 생성되는 서비스들, 그리고 아직 UX 과제들이 많은 이 시장에서 좋은 사례는 아직도 적고, 디자이너나 기획자는 유저의 행동 패턴을 분석할 수 있는 데이터를 얻기가 아직은 쉽지 않은 것 같습니다.
이런 환경에서 서비스를 생산하는 기획자는 prototyping을 이용한 테스트 반복을 통해 비용 대비 학습 효율을 높이고 서비스를 점진적으로 구체화하는 방식이 효율적이라고 느꼈습니다.
하이 레벨의 정식 prototype으로 발전시키기 전에 로우 레벨의 저렴한 검증을 여러 번 거쳐야 합니다.
그 과정은 리서치를 통해 목표와 가설을 수립하고,
아이디어를 발산하며 그리고 검증하고,
보완하고, 구체화하는 플로우를 반복하게 되는데요.
중요한 것은 이 모든 단계에서 모든 관계자들이 참여해야 한다는 것입니다. 그건 디자이너뿐만 아니라 기획자, 경영자, 개발자, 그리고 이 제품을 사용하게 될 유저까지도 모두 포함입니다.
저는 실제로 제 경험 속에서 개발자와 초기 단계부터 함께 기획하는 것이 얼마나 중요한지, 그리고 아직 기술적인 측면으로 많이 받아들여지고 있는 블록체인 기술 기반의 서비스는 특히나 더 기획 단계에서 개발자의 참여가 필요하다고 생각했습니다.
디자이너나 기획자에게 서비스 기획을 맡긴 채로 개발자들이 코어 기술만 연구한다면, 이후의 불필요한 검수와 피드백 리소스만 늘어나게 된다고 느꼈습니다. DApp 기획을 하면서 UX 디자이너와 더 큰 시너지를 발휘하기 위해 신경 쓰면 좋을 부분입니다.
아직 이 블록체인 기술 분야에 디자이너가 많지 않고, 유저 관점이 아닌 기술자 관점으로 보이는 DApp 서비스들이 아직도 너무 많습니다.
그렇기 때문에 저는 디자이너들이 다양한 경험을 서로 공유해서 DApp 서비스에 필요한 사용성 체크리스트를 만들고 다듬어갈 수 있었으면 좋겠고, 현재 THIS라는 디자이너 그룹에서 블록체인 UX 스터디를 진행하고 있습니다.
앞으로도 다양한 기회에 다양한 디자이너나 관련자분들과 만나서 경험을 공유하고 함께 성장하는 기회를 가지고 싶습니다.
author : ohjieun8018@gmail.com
위 내용은 제 미디엄 글을 브런치로 옮긴 것입니다. (미디엄 링크 첨부)
UX 디자이너의 블록체인 탐험기 : https://nexters.me/wg
디랩토리팀(디사이퍼 소속)의 깃허브 주소 : https://github.com/DE-labtory/engine
