그동안은 ‘개발 구현' 보다는, ‘이용자의 문제해결’에 초점을 맞춰 개인/팀 프로젝트를 진행했는데, 이번 프로젝트를 통해, ‘사용성'만큼 ‘개발 가능성'도 중요함을 깨달았다. ‘UX/UI 디자인’ 이란 결국 프로덕트를 통해 문제점을 해결하는 과정이지만, 프로덕트 자체를 개발할 수 없다면 의미가 없기 때문이다.
아이디에이션을 구체화하는 과정에서 인터뷰를 통해 이용자가 실질적으로 ‘IT 강의 수강’에서 겪는 어려움이 무엇인지 파악하려고 했고, 이 단계에서 서비스는 보다 많은 기능을 포함하고 있었다. 하지만, 개발자와 회의를 하면서 현 단계에서 기술적으로 구현 불가능한 부분을 발견할 수 있었다. 이 때, 우선적으로 해결해야하는 문제가 무엇인지 정의하고, 핵심적인 기능만을 간추려 기능을 단순화했다.
처음에는 모두가 욕심이 많아서, 보다 완벽한 서비스에 대한 욕심이 강했던 것 같다. 하지만, 팀원들 모두 사이드 프로젝트를 통해 개발/디자인 간 협업을 통해 역량 쌓기를 목표로 하고 있기에, 이러한 욕심은 오히려 ‘독’일 수도 있다는 생각이 들었다. ‘너무 진을 빼지 않으면서도, 목표한 기한 내에 서비스를 완성하는 것'이 현 시점에서 모두에게 필요한 것이라 생각했다. 가장 우선적으로 개발되어야 하는 것들 위주로 기능 및 화면들을 축소하고, 이를 끝까지 완주하는 것이 더 중요하다. 팀원들 모두 이 생각에 동의 했기에, 2개월이라는 시간 안에 베타 버전을 완성할 수 있었다.
‘프로덕트에 대한 애정'도 프로덕트를 개발하는 데 큰 원동력이 될 수 있다. 팀원들 모두 주도적으로 참여했던 프로덕트라 누가 시키거나 강제하지 않아도, 모두 원활하게 협업했다. ‘각 자 알아서 잘’ 했다.각 자 의문점이 생기거나 모르는 점이 생기면 몇 시간이고 자유롭게 이야기했다. 때론 이 과정이 비효율적이라 느껴질 수도 있지만, 그만큼 이 프로젝트에 모두가 관심을 갖고 열의를 다했기 때문이라 생각한다. 이렇게 프로덕트 오너십을 갖고 있을 때, 자율성 아래에 서로를 믿고 협업할 수 있다.
4명이라는 적은 인원으로 빠르게 작업을 진행해야했기에, 호흡 조절이 필수적이었다. 특히 개발 도중, 이미 개발 구현된 화면들이 전체적으로 사이트 폰트, 요소 크기가 크다는 피드백에서 ‘큰일났구나!’ 싶었다. 나야 다시 디자인을 해서 넘겨도 상관없지만, 다른 팀원들이 불필요하게 힘을 빼서 지칠 까봐 걱정되었다. 결국 오랜 시간 회의를 거쳐, 이대로 진행하되 일부 화면만 수정하자고 결론이 났다. 완주하는 것이 목표인 레이스만큼, 모두가 힘 조절을 잘해서 끝까지 지치지 않게 하기 위해 가장 신경썼던 것 같다. 또, 다음부터 초반에는 디자인과 개발 모두 작업물을 계속 공유하고, 피드백을 받는 것이 필수적임을 느꼈다.
개발 과정에서 예상치 못한 이용자 경험까지 모두 고려해야 하는 일이 잦았다. 예를 들어, 이용자가 비밀번호를 잊어버려 비밀번호 찾기를 할 때, 임시 비밀번호를 발급해야할지, 비밀번호 변경 링크를 보내주는 것이 좋을지 결정해야했다. 혹은 자동 로그인을 통해 회원가입 한 유저가 비밀번호 변경을 할 경우, 기존 회원가입 이용자와는 어떻게 화면 차이를 두어야할까? 같은 문제들! 이 괴정에서, 이용자의 맥락을 이해하는 것도 중요하지만 개발환경을 고려한 기술적인 이해는 더 중요하다. 지속적으로 개발자와 커뮤니케이션을 하면서, 이용자가 경험하는 다양한 변수들을 생각해야했다. 어쩔 수 없이 직접 부딪히면서 플로우를 짜야하는 경우도 분명 있다. 하지만, 최대한 기획 단계에서,이러한 변수들을 고려해 보다 촘촘하게 프로토타입을 설계하는 것이 효율적임을 느꼈다.