나는 시험 삼아 진행 중인 모든 프로젝트의 일지를 기록해 보기로 했다. 회사 내부 또는 고객과의 업무에서 발생하는 사소한 결정들을 매일 기록해서 모두 한곳에 모았다. 처음에는 스스로 좀 더 체계적으로 정리를 해보려고 시작했지만 (기록을 해나가면서) 이 작업의 이점들을 발견하게 되었고, 내가 하는 일에 대해서도 좀 더 잘 이해할 수 있게 되었다. 뜻밖에도 내가 작업한 디자인을 설명하는 것이 훨씬 수월해졌다. 웹사이트의 어느 곳을 클릭하면 무엇이 나타나는지, 디자인 하나하나마다 어떤 이유로 결정하게 되었는지, 또 이 모든 것이 CMS(콘텐츠 관리시스템) 안에서 어떻게 조화를 이루게 될지를 미리 머릿속에서 그려보고 외울 수 있게 되었기 때문이다.
대규모의 디자인 시스템을 만들 때 가장 힘든 것 중 하나는 프로젝트 전체를 형성하는 작은 결정들을 모두 기록하는 것이다. 프로젝트가 진행되는 동안 수많은 정보가 만들어지고 전달, 수정되고 승인된다. 고객 피드백, 회의 일지, 디자인 방법 등 다양한 형태로 구성된 이 작은 결정들은 더 큰 프로젝트를 만들게 되고 대부분 이메일과 베이스캠프Basecamp 쓰레드thread[1]로 남는다. 그리고 프로젝트가 끝나게 되면 스타일 가이드, 주석, 기능 명세서 등으로 문서화된다. 하지만 수개월이 넘게 걸린 대형 프로젝트를 진행해본 결과, 디자인 작업이 모두 끝난 뒤에 이 모든 것을 기록하는 것이 프로젝트에 큰 도움이 되지 않다는 것을 알게 되었다. (솔직히 도움이 되었던 적이 있었는지도 의심이 간다) 중요한 세부사항을 빠트리거나 잊어버릴 수 있기 때문이다.
나는 작은 결정들을 모두 구글 문서Google Doc에 모아두는데, 쉽게 정리할 수 있어서 편리하기 때문이다. 예를 들면 디자인과는 꼭 관련이 없어도 추후 개발단계에서 이슈가 될 수 있는 고객 피드백을 문서에 옮겨 붙여paste놓는다. 또 디자인 방법과 기능적 논리를 기록해 둔다. 이 작업을 통해 발견한 또 하나의 장점은 모든 것을 글로 기록해 놓았을 때 내가 내린 디자인 결정들의 합리성을 강화하고 논리의 허점들을 더욱 쉽게 찾을 수 있다는 것이다. 일지를 통해 내 작업을 더욱더 깊게 이해할 수 있게 되었는데, 무엇보다 프로젝트의 패턴을 찾고, 큰 그림을 보는 시각을 유지하는 데 도움이 된다.
초기의 디자인 시스템이 틀을 잡기 시작하면, 프로젝트를 진행하는 동안 언제든지 쉽게 찾아볼 수 있도록 웨이파인딩Wayfinding[2], 내비게이션 그리고 기능적인 규칙들을 지속해서 업데이트할 수 있는 로그를 만들면 도움이 된다. 이는 스타일 가이드의 골격을 잡는 데 도움이 될 것이다.
프로젝트의 규모에 따라 이 로그를 시작해야 하는 시점이 다를 수 있다. 내 경우에는 첫 디자인 방향이 확정된 이후 시작하는 것이 도움된다. 이때가 개념적인 선택 사항을 어떻게 조화시켜 시작할지에 대한 기대치를 기록하기에 적합한 시기이다. 이 핵심 개념은 진도가 막힐 때마다 언제든지 다시 확인하고 참조할 수 있는 길잡이가 된다. 다양한 페이지들이 완성되면 사용하고 있는 색깔들의 수를 줄이고 사용되는 글꼴의 계층구조를 기록해 두는 것이 좋다. 일반적으로 이것은 프론트엔드 개발을 보다 빨리 시작하도록 돕는 유용한 정보가 된다. 스타일에 관한 구성요소들을 한 곳으로 모을 수 있기 때문이다.
하지만 일지는 내부 초안이기에, 새로운 스타일이나 수정이 필요하면 바꿀 수 있는 여지가 많다. 중요한 것은 스타일을 효율적으로 정의하는 것과 정의 시기 사이에서 균형을 찾는 것이다. 구조와 유연성의 균형이 맞아야 하는데 쉬운 일이 아니다. 디자인 과정에서 언제 디자인 시스템의 스타일(스타일 가이드)을 정의해서 공식 문서화해야 할지 파악하기가 쉽지 않다. 너무 일찍 모든 것을 정해버리면 따분하고 제한된 디자인 시스템이 되기 쉽고 너무 늦게 정해버리면 수많은 타이포그래피와 링크 스타일들을 추려내느라 정신이 없게 될 것이다.
현재 일지는 내부용으로만 사용하고 있다. 하지만 앞으로는 범위를 확대해 공동작업을 할 방법을 찾고 싶다. 완료된 구글 문서를 한 번에 모두 공유하면 그 정보가 너무 많으므로 나의 경우 가장 좋은 방법은 프론트엔드 개발 단계 시점에 맞춰 이 문서를 조금씩 공개하는 것이다. 이렇게 하면 외관은 스타일 가이드 초안대로 정확한 디자인 스타일을 가져갈 수 있고, 더욱 자세하고 기능적인 기록은 개인적으로 주석 또는 QAQuality Assurance[3] 답변을 위한 참고 정보로 보관할 수 있었다. 또 때에 따라 중요한 정보들을 별도로 골라내는 것도 내부용 도구로서 큰 도움이 된다. 앞으로 누군가 시스템 관리를 도울 사람에게 디자인 결정들을 전달해 주어야 하는데 이것이 많은 시간을 아껴주기 때문이다.
저작권 정보이 글은 Happy Cog의 글을 번역한 것으로, 웹액츄얼리 북스팀이 Jeffrey Zeldman로부터 허가를 받고 올린 자료입니다. 원본은 ‘Get to Know Your Work’에서 확인할 수 있습니다.
번역 및 윤문자 구인웹액츄얼리 북스팀에서 웹디자인 관련 영문 번역이나 윤문을 해주실 분을 찾습니다. 관심 있으신 분은 메일 보내주세요. books@webactually.com
오탈자 신고내용 중에 오번역, 오탈자를 발견하신 경우에는 알려주세요.
