[Devcon 6] A better collaboration between design and development
[Devcon 6] UX/UI 세션 참관기
- [Devcon 6] A better collaboration between design and development
- [Devcon 6] The Original Sin
- [Devcon 6] Web3 Adoptions
- [Devcon 6] The Future of Web3 — Fully-Decentralized Web
개요
올해 콜롬비아 보고타에서 열린 데브콘에도 어김 없이 수많은 세션들이 있었다. 그 중에서 dApp 유저들과 가장 접점이 많은 프론트엔드 개발자로서 UX/UI세션들을 중점적으로 들었고, 그들을 네 가지 주제로 분류해 소개해보려한다. 이 글은 그 중 첫번째인 dApp 개발 프로세스에 관한 글이다.
일반적으로 dApp의 개발은 최종 사용자인 유저보다는 기술 구현과 연구에 좀 더 초점이 맞추어지는 편이다. 이는 변경이 쉽지 않은 스마트 컨트랙의 특성 때문에 더욱 도드라지는 면이 있다. 스마트 컨트랙의 수정이 필요한 문제점이 UI/UX 단계에서 발생하거나 발견할 시에도 이를 상대적으로 변경이 유연한 UI/UX 측면에서 쉽게 떠앉게 되기 때문이다. 이로 인해 접근이 어려운 사용 난이도가 높은 UI가 탄생하게 되고 이는 자연스럽게 불쾌한 UX로 이어지게 된다. 가시성이 좋지 않고 소설 책과 같은 수많은 텍스트와 툴팁, 임시 방편에 가까운 UI 기믹들은 그나마 양반이다. 이러한 문제는 단순히 유저 경험에서 그치는 것이 아니라 각 팀들을 사일로화시키고 협력의 가능성과 효과를 현저히 떨어뜨린다. 더불어 보다 나은 유저 경험을 위한 적극적인 연구 자체를 소극적으로 만들어 프로덕트와 조직의 경쟁력을 전반적으로 저하시키는 데까지 나아간다.
수정 가능성이 상당히 제한된 스마트 컨트랙의 특성 때문에 dApp 개발은 프로세스가 정립되지 않으면 상당한 비효율을 초래한다는 논지에 나를 포함한 대부분의 청중이 동의하는 듯 보였다. UX 리드 디자이너인 Sasha Tanase 또한 업계에 몸 담으면 이러한 문제를 몸소 여러 번 체험했다. 그녀는 이에 대한 대안으로 자신의 조직에서 직접 만들고 시행했던 Double Diamond Process를 제안한다.
Double Diamond Process
이 프로세스는 우리가 만들 결과물이 단순한 기술이 아닌 유저가 직접 맞닥뜨리는 프로덕트임을 다시 한 번 강조한다. 이를 모든 팀의 공동의 목표로 삼고 각자의 위치에서 함께 추구하는 것이다.
Double Diamond Process는 크게 두 단계로 이루어져있다. 요구 사항을 함께 발견하고 각자의 전문성을 살려 이를 정의, 해결해보는 Explorative와 앞 단계에서 도출된 사항들을 함께 각 팀이 병행으로 구현하고 완성하는 Iterative 단계이다.
| Explorative — Divergent Phase
이 단계에서는 모든 팀(Biz, Design, Development)이 함께한다. Biz팀이 프로덕트 개발을 요하는 이해관계자들의 요구들을 직접 인터뷰해보며 이를 어떻게 프로덕트로 풀어낼 지 정의한다. 요구 사항들이 나오면 각 팀들은 자신의 위치에서 이를 어떻게 실현시킬지 그려본다. 컨트랙 개발자, UX/UI 디자이너, 서비스 개발자 등 모든 이들이 각자의 전문 분야를 살려 이 서비스를 그려보면 각각 예상되는 그림과 문제점이 제각각 다를 것이다. 이를 한 데 모아 예상되는 유저 입장에서의 흐름을 구현해보고 예상되는 문제점과 피드백 반영을 반복하며, 이를 일반적인 수준의 유저가 이해할 수 있을 정도로 구체화시킨다.
이 리서치 단계에서 그녀는 프로덕트의 사용자가 될 유저들과의 소통이 매우 중요함을 강조한다. 리서치 단계에서부터 타겟층으로 삼은 유저가 이해할 수 있을 만큼 아이디어를 구체화하고 이를 이해시켜 미리 피드백을 받는 게 개발 효율에 매우 좋기 때문이다. 이 과정을 통해 자연스럽게 구현 가치가 있는 아이디어가 구분되고 미처 예상치 못 한 문제점을 발견할 수 있다.
이후엔 실제 구현할 사항들을 확정한 뒤 이해 관계자에게 최종 확인을 받은 뒤, 두 번째 스텝으로 넘어가게 된다.
| Iterative — Convergent Phase
두 번째 단계는 실제 개발자들과 디자이너가 주축이 돼 개발을 구현하는 단계이다. 특히 여기서 강조되는 것은 첫 프로토 타입이다. dApp은 보통 개발 기한이나 주기가 짧은 만큼, 첫 프로토 타입을 빠르게 개발자들과 디자이너가 함께 만들어야 불필요한 의사 소통과 작업을 줄이는데 크게 도움이 되기 때문이다. 디테일이 완벽하지 않더라도 큰 형태의 프로토 타입은 앞서 정의한 유저 입장에서의 흐름을 대략적으로 구현할 수 있기에 큰 축에서 불필요한 리소스가 낭비되는 것을 크게 줄여준다. 더불어 개발자와 디자이너가 각각 서로의 분야에서 예상하지 못 했던 문제점을 찾아내는데 무엇보다 도움이 된다.
이 단계에서 무엇보다 강조되는 것은 의사 소통이다. 반복적인 프로토 타입 개발과 수정을 통해 각 팀은 끊임 없이 소통하고 상호 확인하며, 유저 입장에서 구현이 정의되었던 사항들이 올바르게 이행되었는지 자연스럽게 검증이 가능하게 된다. 이러한 의사 소통을 통한 문제 발견과 요구 사항 구현은 단순히 프로덕트의 효율적 구현에서 그치는 것이 아니다. 조직의 역량을 끌어올려 이후에 진행되는 개발에도 큰 영향을 미치게 된다. 그녀는 이 방법론을 반복할수록 구성원들이 여기에 익숙해지고 프로젝트 진행 속도와 효율이 좋아짐을 본인이 진행했던 프로젝트들의 사례를 들어 보강하기도 했다.
Scrum과 Sprint
Double Diamond Process를 보며 프로젝트 관리방법론에서 흔히 말하는 스크럼(Scrum)이 떠올랐다. 설계, 구현, 테스트가 순차적으로 진행되는 폭포수(Waterfall) 방식에 비해 애자일(Agile) 방식의 대표 중 하나인 스크럼은 다음과 같은 특성들을 지니고 있다.
- 특정 개발 언어나 방법론에 의존적이지 않다.
- 단순히 프로덕트 개발이 아닌 일반 프로젝트 관리에도 사용 가능한 프로세스 프레임워크다.
- 스크럼은 작은 주기로 개발 및 검토를 진행한다.
- 변화에 유동적으로 대응이 가능하다.
여기서 스크럼의 핵심은 작은 주기라고 생각한다. 스크럼은 작은 주기의 총합이고 흔히 이러한 작은 주기를 스프린트(Sprint)라고 부른다. 장기 목표 실천을 단기 계획으로 나누고 이를 스프린트의 반복적인 실행으로 이루는 것이다.
앞서 Double Diamond Process에서 말하는 각 팀들의 병행 협업 방식이나 2~3주 정도의 주기로 단계로 나눠 개발 진척을 시키는 방법론에서 스크럼의 영향을 짙게 느낄 수 있었다. dApp 개발 및 유지 보수는 특히 예상치 못 한 변수 사항이 출현할 확률이 높고 기술 및 시장 변화가 상당히 빠르므로, 이러한 사항들에 유연하게 대처할 수 있는 스크럼에 기반한 프로세스가 상당히 잘 어울린다고 생각한다.
마치며
그 동안 dApp들을 개발하며 느낀 아쉬웠던 점들이 언급되는 것에 대해 상당히 고무적이었던 세션이었다. 특히 발표 후 이어지는 Q&A 세션에서도 스프린트 주기, 테스트넷에서의 유저 행동, 테스트 유저 풀 타겟 등 서비스 개발이나 기획을 하는 사람들이라면 한 번쯤 겪어봤을 만한 문제들에 대해 다양한 사람들의 의견을 들을 수 있어 많은 의미가 있었다.
Double Diamond Process가 지적하는 문제점들은 dApp 개발 경험이 있는 어느 직군의 사람이라도 보편적으로 겪어봤을 문제점이라고 생각한다. 필자 또한 크게 다르지 않기에 이러한 프로세스를 환경에 맞춰 어떻게 구현해 볼 수 있을지 고민하고 있다. 특히 아이디어와 요구사항을 정의하는 단계에서 단순히 이를 듣고 어떻게 구현할 지 추상적으로 생각하는 수준을 넘어, 프로세스를 확립해놓고 이를 다 같이 자신의 분야에 맞게 구체적으로 그려보며 의견을 나누는 것은 큰 도움이 될 것이라 확신한다. 초기 기획 단계부터 서비스 구현에 위치한 이들이 참여하지 못 하게 될 경우 UX/UI가 당초 의도와 달리 그려지는 경우를 많이 보았기 때문이다.
‘작은 문제를 해결해 나가면 큰 문제는 저절로 해결된다’는 격언처럼 이 프로세스가 유사한 문제를 겪고 있는 이들에게 작은 문제를 하나씩 해결해나갈 수 있는 실마리가 되었으면 한다.
