UI 디자이너의 위기지학 01
글을 보며 함께 따라 하면서 실질적으로 코딩을 배울 수 있는 디자이너의 코딩 수련장(Workbook).
Design Hacking을 통해 코딩 배우기
코딩을 배워야겠다고 생각하는 디자이너는 많아도 새로운 걸 배운다는 부담감이 커서인지 주변에서 실제 코딩을 배우는 사람들은 많지 않다. 그래서 글을 보며 함께 따라 하면서 실질적으로 코딩을 배울 수 있는 디자이너의 코딩 수련장(Workbook) 형식으로 글을 써보려 한다.
UI 디자이너의 의도적 수련과 피드백
디자이너로서 전문성을 키우고 성장하는 데는 새로운 방법과 지식을 습득하는 것도 필요하지만, 직접 디자인하고 그에 대한 피드백을 통해 학습하는 ‘디자인 수련‘이 더욱 중요하다. 김연아처럼 훌륭한 선수가 되는데 필요한 요건으로 ‘피나는, 뼈를 깎는’ 같은 수련의 과정은 항상 빠지지 않는다. 스포츠 같은 분야는 이런 수련의 모습이 머리 속에 쉽게 그려지지만, UI 디자이너가 뼈를 깎는 수련을 하는 모습은 잘 연상되지 않는다.
이는 연습의 행위 보다 피드백 차이에 기인한다고 생각한다. 전자의 경우는 점수를 얻거나 승부를 가리는 규정(측정)이 명확해서 기량이 향상되고 있는지 피드백이 즉각적이고 명료하다.
반면, UI 디자인 자체로써는 사용자가 사용하는 제품이 아니기 때문에 피드백을 얻는 데 불리하다. 개발자의 구현이 있어야만 사용자가 접하고 피드백을 받을 수 있어 응답 주기가 길어진다. 디자인과 사용자 피드백 사이에 다양한 변수가 존재해서 해석하는데 모호함이 생긴다. 다양한 사용자가 각자의 맥락에서 디자인을 판단하기 때문에 어떤 것이 유의미한 피드백인지 판단하기 어렵다.
디자인 에이전시에서 수행하는 과제들은 디자인과 개발 단계가 분리돼 있고, 제품 출시까지의 주기가 길어 디자인에 대한 사용자 피드백을 얻을 기회가 적다. 그래서 과정에 leanUX 방법과 프로토타이핑을 적극적으로 도입하려고 하지만, 일정이나 비용 제약 등으로 적용할 수 있는 과제는 제한적이다.
구체적인 피드백을 제때 받아야 개선하고 실력을 향상할 수 있는데. 일을 많이 해 경력이 쌓인다고 실력이 느는 것은 아니다. 일은 일이고, 실력을 키우려면 개인적인 노력이 필요하다.
그럼 뭘 어떻게 노력해야 할까?
그래서 UI 디자이너의 의도적 수련 방법으로 ‘Design Hacking’을 제안한다.
나를 위한 UI 디자인, Design Hacking 하기
수련에 도움이 되는 구체적인 피드백을 받으려면 변수와 범위를 가급적 제한해야 한다.
- 기존의 것을 개선하기
뭔가 세상에 없던 혁신적인 것을 만드는 것이 좋은 디자인이라고 생각하고 강박적으로 새로운 것만 찾으려고 하는 경우가 많다. 하지만 필자가 하고 싶은 이야기는 그렇게 하지 말라는 거다. 검증(측정)해야 하는 범위가 너무 넓어져 수련 방법으로는 적합하지 않다.
디자인 수련은 문제를 찾고, 해결하는 과정을 연습하려는 것인데 우선은 기존 문제의 해결 부분에 집중하는 게 좋다. 사람들이 이미 잘 사용하고 있어서 그 필요성이 검증된, 항상 시험에 나오는 기출 문제부터 시작해보자. 범위를 보다 제한해서 하나의 화면, 그 안에서도 하나의 모듈, 하나의 기능을 선명한 목적을 갖고 개선해보는 게 좋다. 변수가 통제돼 기존 것보다 좋아졌는지, 아닌지 대조가 명확해야 피드백의 가치가 있다.
- 디자인 해킹으로 동작하는 프로토타입 만들기
페이퍼 프로토타입이라도 만들어보라고 하는 건 안 만들어서 피드백이 아예 없는 것보다는 낫기 때문이다. 가급적 충실도가 높은 프로토타입으로 실제 맥락에서 실제 데이터를 갖고 직접 사용해 볼 수록 보다 좋은 피드백을 얻을 수 있다. 아무리 ‘대박’ 날 것 같은 좋은 아이디어라도 콘셉트 스케치만으로는 배우는 게 없기 때문이다.
그렇다고 미천한 코딩 실력으로 실제 사용 가능한 서비스 프로토타입을 만들기는 어렵다. 프로토타이핑 툴을 이용해서 플로우나 마이크로 인터랙션을 확인 해보는 것은 여기서 말하는 동작(Working)에 해당하지 않는다. 기존의 동작하는 서비스를 여전히 동작하는 범위 안에서 수정해(Hacking) 사용해보고 평가해보는 경험을 많이 해보는 게 좋다.
그래서 코딩을 배워야 한다.
뒤 단에서 서비스가 어떻게 돌아가는지, 시스템 프로그래밍을 하는 것을 기대하는 것이 아니다. 말단 인터페이스의 시각적인 정보 디자인과 인터랙션만이라도 내가 생각하는 디자인으로 바꿔서 현실화해보고 싶다는 분명한 목적으로 코딩을 배우면 좀 더 수월하게 배울 수 있다. 코딩을 체계적으로 배워서 나중에 뭘 해보겠다는 접근 보다는 실질적인 필요를 위해 우선 베껴서라도 돌아가게 하고, 나중에 원리를 이해하는 방법이 실용적이다.
- 디자인 위기지학
UI 디자인을 배울 때 사용자는 ‘내가 아니라는 것’을 강조한다. 특히 디자이너나 개발자는 사용자가 아니라는 사실을. 물론 디자인을 하는데 실제 사용자를 조사하고 이해하는 과정이 중요하다. 그리고 어렵다. 그래서 안 하려고 한다. 이건 따로 연습해야 할 부분이다. 물론 대부분 과제의 사용자는 내가 아닌 경우가 많다. 하지만 일 하는 게 아니라 배우려는 거니까. 내가 사용자인 서비스로 우선 디자인의 핵심에 집중해 연습하는 게 좋다.
사용자 이해 – (문제 정의 – 문제 해결) – 사용자 피드백
힘든 수련을 계속해 나가려면 보상이 필요하다. 내 문제를 스스로 해결하는 즐거움을 경험하는 것도 중요하다. 나를 위한 디자인을 우선하고, 남들에게도 적용할 수 있는지 확장하는 접근을 써보는 게 좋다. 많은 문제들이 ‘User Centered Design’ 보다 ‘Human Centered Design’이 제대로 안된 경우가 많기 때문.
기존 서비스를 사용하다 보면 아쉬운 점 한 두 가지는 꼭 있지 않은가? 내가 사용하면서 불편했던 바로 그 UI를 개선하는 연습을 해야 할 것이다. ‘내가 만족하지 못하는 서비스’는 크게 두 가지 경우다.
첫째. 내가 대상 퍼소나가 아닌 경우
정말 이거 하나만 고쳐주면 좋은데, 왜 안 하는지 이해 못 하는 경우가 있을 거다. 디자인을 하면서 퍼소나 방법을 사용하는 이유다. 개개인의 요구사항을 다 들어주다가는 누구의 요구도 만족시키지 못 하게 된다.
하지만 마이너한 사용자층의 니즈를 발견해 개선하는 것은 디자인 수련에서 앞서 이야기한 사용자의 이해 부분을 연습하는데 많은 도움이 된다. 그냥 ‘내 맘대로’가 아닌 공통된 맥락과 니즈를 가진 사용자 그룹을 객관화하는 훈련을 하면, 다른 관점의 디자인을 할 수 있다.
둘째. 사용자들이 잠재적인 니즈를 아직 의식하지 못하는 경우
얼리어답터는 새로운 제품이 나오면 가장 먼저 그것을 사용해보고 싶어하는 그룹이다. 하지만 그 앞에는 시장에 제품(해결)이 없더라도 필요에 대한 감수성이 높은 Lead Users 사용자층이 있다. 관점은 다르지만, 하라켄야의 욕망의 에듀케이션(Education of Desire)도 비슷한 의미라고 생각한다. 몰라서 필요를 느끼지 못하는 것뿐, 좋은 걸 한번 경험하게 되면 톱니바퀴 효과처럼 이전으로는 되돌아 가지는 못한다. 취향이나 상황이 다른 게 아니라 ‘니즈에 대한 만족도가 남들보다 높다는 건’ 좋은 해결책만 제시해 준다면 모두에게 도움이 될 수 있다.
서비스 제공자 입장에서도 이것을 하나의 사용자 피드백으로 바라보고 두 가지 관점에서 대상이 아닌 건 무시하고, 좋은 건 수용하는 열린 방식으로 접근하면 서비스를 건강하게 만드는데 도움된다. 애플이 시디아(Cydia) 같은 탈옥 기기를 위한 앱 스토어를 강력하게 제한하지 않는 것도 같은 이유라고 생각한다.
Design Hacking 연재에서는 내가 잘 쓰고 있는 웹 서비스의 불편을 느끼는 구체적인 한 부분을 선택해 개선하고, 직접 사용하고, 평가하는 과정을 반복할 것이다. 우선은 필자가 고쳐서 사용하고 있는 사례들을 소개하겠지만, 궁극적으로는 독자들과 함께 개선하고 싶은 서비스를 선정해 함께 디자인 개선을 해보는 방식으로 진행하려고 한다. 리디자인 결과 위주가 아니라 Design Hacking 코드를 공유해 이 글을 보고 있는 독자 스스로가 자신에 맞게 고쳐보도록 할 것이다. 나를 위한 디자인을 하면서 코딩을 배워보자.
<02 이제 바로 코딩을 시작합니다. 다음을 준비하세요.>로 이어집니다.
뉴스콘텐츠는 저작권법 제7조 규정된 단서조항을 제외한 저작물로서 저작권법의 보호대상입니다. 본 기사를 개인블로그 및 홈페이지, 카페 등에 게재(링크)를 원하시는 분은 반드시 기사의 출처(로고)를 붙여주시기 바랍니다. 영리를 목적으로 하지 않더라도 출처 없이 본 기사를 재편집해 올린 해당 미디어에 대해서는 합법적인 절차(지적재산권법)에 따라 그 책임을 묻게 되며, 이에 따른 불이익은 책임지지 않습니다.
- 에디터김 다윤 (kdy@websmedia.co.kr)
