여는 글
프론트엔드로 개발을 시작했고 또 프론트엔드를 사랑하는 사람으로써 나만의 블로그를 처음부터 만드는 것은 어느새부턴가 간직하고 있던 소망이었습니다.
앞선 수 년 동안 시중의 블로그 서비스들을 이용해 왔습니다. 티스토리 블로그를 2021년에 시작했고 2022년에는 Jekyll을 이용한 정적 블로그를 배포했지만 결과적으로 포스트를 올리다가 6개월 이후부터 기록이 끊기고 말았습니다. 포스팅할 시간이 부족했거나 등의 외부 요인도 있었지만 내부적인 요인이 결정적이라고 생각했고, 조금 더 생각해 본 후 내부적인 요인을 경험적 요인과 기술적 요인으로 분류했어요.
경험면에서
- 블로그에 남기는 글이 일관된 방향을 가리키고 있지 않다는 고민
- 너무 사소한 소재들까지 포스팅하는 행위가 동기부여를 잃는 데 주요하게 작용함
저는 프로덕트를 만드는 사람들은 더 나은 사용자 경험을 주기 위해 끊임없이 고민해야 한다고 생각해 왔고 그렇기에 UX/UI 뿐 아니라 유저 시나리오 설계 등 사용자 경험을 디자인하는 프로세스에도 관심이 많았습니다. 따라서 블로그 포스트의 내용도 중요하지만 전체적으로 봤을 때 컨텐츠들이 어떤 스토리를 전달하고자 하는지에 대해서 늘 갈망이 있었습니다.
하지만 기록하는 포스트들의 주제가 알고리즘과 학과 공부 등 너무 다양한 카테고리를 다뤘기 때문에 현재 블로그에서는 정보 이상의 무언가를 전달하기 쉽지 않다고 느꼈어요. 또 너무 작은 소재들까지 블로그에 기록하고자 한 탓에 포스트로 남기는 작업이 과도한 리소스를 필요로 한다고 생각했습니다.
기능면에서
- 여러 블로그 서비스가 제공하는 기능 중 어떤 것은 필요하지만 어떤 것은 필요하지 않을 수 있음
예시로 티스토리를 쓰면서 편리했던 점은 새로운 글을 편집하고 이미 작성한 글을 관리하는 CMS(Content Manangement System) 기능이었어요. Jekyll을 이용한 블로그에서는 코드 블록 지원이나 마크다운 친화성, 정적 페이지 생성 등을 지원한다는 점이 만족스러웠고요.
하지만 어느 선택지를 고르더라도 좋은 점들만을 모으기 쉽지 않다는 것이 난감했습니다. 자연스레 내가 원하는 기능들만을 포함하도록 하려면 내 손으로 처음부터 쌓아 올리는 수밖에는 없다는 결론에 도달했어요. 그런 와중에, 우연히 아래 두 개의 채널을 접했습니다.
이전까지 프로덕트에 대한 UX 디자인은 어깨 너머로 경험해 본 적이 있었지만 블로그를 하나의 프로덕트로 정의하고 독자를 유저로 정의한 접근 방식은 생각해 보지 못했기 때문에 정말 흥미로웠습니다. 제가 부족하다고 생각했던 블로그의 방향성과 어떤 모습으로 내가 가진 지식을 기록하고 전달하고 싶은지에 대한 청사진을 본 것처럼 느껴졌어요.
위와 같은 이유로, 시간이 난다면 나만의 블로그를 처음부터 디자인하고 코딩해 보고 싶다고 생각했습니다. 하지만 시간을 들여 깊게 고민해야 하는 작업이라고 생각했고 무엇부터 시작해야 할 지도 막막했기에 생각만 한 채로 보류해 두고 있었습니다.
그러던 와중 참여하고 있던 부트캠프에서 개인 프로젝트를 진행할 수 있는 2주 간의 시간이 주어졌어요. 마침 한창 새로운 지식을 받아들이는 시기였고 이를 기록할 수 있는 플랫폼이 필요했기에 이보다 좋은 타이밍이 있을까 싶었습니다. 때맞춰 프로그램에 함께 참여하고 있던 UX/UI 디자이너분들께 조언을 구하기 쉽다는 점도 결정에 도움이 됐고요. 어설프지만 보편적으로 적용할 수 있는 UX 방법론들부터 차근차근 부딪혀 보자고 생각했습니다.
1. Pain Point
스스로 “블로그에 지속적으로 포스트을 남기고 싶은 가장 큰 목적은?” , "포스팅을 기록하는 과정을 방해했던 불편함은?” 등의 Guiding Question을 던지고 질문에 따른 Guiding Activity를 수행하기를 두세 차례 반복했습니다.
- 포스팅하는 주기에 대한 부담과 행위의 리소스를 줄일 수 있다면
- 내가 원하는 기능들만을 조합해서 사용할 수 있다면
그 결과, 지금까지 다른 블로그 서비스를 이용했던 경험 속에서 아쉬웠다고 생각되는 포인트들을 Pain Point로 뽑아낼 수 있었습니다. 여타 사이드 프로젝트들을 진행했을 때와 달리, 스스로 느낀 점을 그대로 유저 리서치로 활용할 수 있었기 때문에 비교적 수월하게 느껴졌어요.
2. Solution Concept
앞서 살펴본 내용에서 어떤 점을 개선하고 메인 기능으로 가져갈지를 알아봤다면 다음 순서는 블로그가 어떤 모습으로 독자들에게 다가갔으면 할 지 정하는 단계였습니다.
전달하고자 하는 추상적인 가치를 이에 부합하는 이미지의 구체적인 아이디어 컨셉트들로 연결할 수 있었고 몇 가지로 추려서 표현했습니다. 제가 전하고자 하는 가치가 ‘얕지 않은 컨텐츠‘ , ‘사용 방법보다 원리를 이해하고 남긴 기록‘ 으로 오랫동안 독자들에게 도달할 수 있는 컨텐츠라는 점을 중심으로 정리했습니다.
3. Branding
위에서 준비한 내용들을 바탕으로 브랜드 이미지를 구축했습니다. 위에서 정한 Solution Concept에 부합하는 ‘모래사장‘, ‘발자국‘ 등의 비주얼 컨셉을 도출했고 예전부터 쓰던 푸들이라는 닉네임과 부합하는 “모래사장에 남긴 개-발자국”이라는 재치 있(다고 믿)는 컨셉트에 도달할 수 있었습니다.
4. 기능 정리
블로그를 디자인하면서 어쩌면 가장 오랫동안 고민했던 부분입니다. 많은 프레임워크나 템플릿에서 제공하는 유용한 기능들을 굳이 사용하지 않을 이유는 없지만서도 위에서 도출한 컨셉트에 의해 블로그를 읽는 사람들이 컨텐츠에만 집중할 수 있는 일관적인 경험을 제공하고 싶었어요.
- 자동으로 생성되는 목차 네비게이션
- 스크롤 프로그레스 바
- 카테고리
- 다크 모드
따라서 위의 기능을 제외하기로 결정했습니다. 위의 기능들은 내가 지금 읽고 있는 부분이 전체 컨텐츠의 어떤 부분인지 알 수 있다는 점 등에서 확실히 도움 되는 경우가 있지만, 저는 독자의 움직이는 시선을 고려했을 때 극단적으로 컨텐츠 영역에만 집중되기를 바랐고 이를 위해 미니멀하게 가장 필요한 것들만을 표시하고자 했어요. 어쩌면 밑바닥부터 블로그를 쌓아 올리기에 시도할 수 있는 전략이라고 생각했습니다.
5. IA
다음으로 블로그의 IA를 정리했습니다. 포트폴리오와 CV 링크 또한 네비게이션에서 접근할 수 있도록 할 예정이기에 같은 뎁스로 표현했고 블로그 하위에는 위에서 정리한 핵심 기능들을 제공하는 데 필요한 정보 요소들을 나열했습니다.
앞서 작성해 온 UX 디자인 프로세스들 덕분에 정보 구조를 정리하는 과정에서 해야 할 일이 명확하게 느껴졌어요. 이 과정에서 주변 디자이너분께 정보 그 자체를 나타낸 IA와 행위 중심적으로 나타낸 메뉴 트리를 구분해야 한다는 것 또한 새롭게 알게 되어 좋았습니다.
6. Wireframe
와이어프레임을 그리기에 앞서 기존 시장의 서비스들을 대상으로 데스크 리서치를 수행했습니다. 평소 사용하던 컨텐츠 관련 서비스들을 몇 개 추려낸 후, 가운데 컨텐츠 컨테이너 영역의 너비를 얼마로 정할지 혹은 처음 블로그 홈에 들어와서 마주할 포스트 목록 레이아웃을 어떻게 표현할지 등을 중점으로 레퍼런스를 조사했어요.
위에서 결정한 레이아웃 수치들을 바탕으로 와이어프레임을 배치했습니다. 모든 페이지를 다 그렸다면 좋았겠지만 작업을 진행했던 당시 2주 이내에 발표까지 준비해야 했었기 때문에 제한적으로 핵심에 해당하는 3개 페이지만 와이어프레임을 그리고 다음 단계로 넘어갔습니다.
7. Design System
Figma를 사용해 디자인 시스템을 정리했습니다. 주변의 UX/UI 디자이너들께 조언을 구했고 너무 많은 색상과 타이포그래피 스타일을 사용하지 않도록 주의했어요. 위에서 정한 스타일 가이드를 그대로 이용해 각 컴포넌트를 Figma 내에서 디자인 시스템으로 구축했습니다.
이전에 프론트엔드 엔지니어로 참여했던 아토피 관련 사이드 프로젝트에서 디자이너분들이 작업해 놓은 디자인 시스템 위에서 굉장히 편하게 컴포넌트를 쌓아 올렸던 적이 있었는데, 직접 디자인 시스템을 구축하면서 디자이너 입장에서도 생산성에 큰 도움을 준다는 것을 이번 기회로나마 몸소 느낄 수 있었어요.
8. GUI
- 기본 가로 3열의 그리드 레이아웃 차용
블로그의 홈 레이아웃을 가로 3열의 그리드 레이아웃으로 설정했습니다. 또한 정사각형의 썸네일과 그리드 배치가 너무 단조로울 수 있는 점을 방지하기 위해 가장 최근에 작성된 포스트는 가로로 2칸을 차지하게 함으로써 역동성을 전달하고자 했습니다.
각 포스트에 대한 썸네일 이미지는 일부러 포스트의 내용과는 큰 관계가 없는 높은 채도의 추상적인 이미지들을 실험적으로 배치했습니다. 썸네일 크기의 영역에서는 글에 관련된 이미지를 굳이 표시하는 것보다 포스트 그 자체에 대한 흥미를 불러일으키고 전체적인 일관된 컨셉을 전달하기 위한 이미지를 사용하는 게 효용성이 크다고 생각했기 때문이었어요. 썸네일 이미지들의 선정 기준은 모래사장 속 유리 알갱이가 빛나는 듯한 비주얼을 표현하는 데 중점을 두었습니다.
- 가운데 컨테이너 영역에 시선이 유지되는 것을 의도
앞서 정리한 대로 독자들이 글을 읽으면서 너무 많은 곳에 시선이 분산되어 피로감을 느끼는 것을 가장 피하고 싶었기 때문에 가운데 영역에서만 시선이 이동하도록 흐름을 구성하고 싶었는데요, 읽기 영역을 컨테이너로 분리함과 동시에 스크롤이 일정 수치 이상 내려가면 가운데 영역을 제외한 화면의 밝기를 낮추는 인터랙션을 통해 컨텐츠에 몰입한 것 같은 경험을 전달하고자 했습니다.
다른 한 편으로는 최근의 컨텐츠 제공자들이 행간이나 자간을 극단적으로 줄이는 추세인 것과 반대로 행간과 자간을 충분히 여유롭게 배치했습니다. 글자 크기를 14-16px 사이로 조정하면서 가장 적절한 가독성을 갖는 수치를 실험적으로 알아냈어요. 이러한 문단 배치를 통해 좌우의 여백, 배경색과 조화되어 옛날 시집을 읽는 것 같은 경험을 전달하고 싶었습니다.
맺는 글
블로그를 처음부터 디자인해 보며 아래와 같은 것들을 느꼈습니다.
- 톤 앤 매너를 구성하는 것의 어려움
- 와이어프레임 단계에서 진행 상황을 가둬놓지 말 것
- Figma로 디자인 시스템을 구축하는 것의 편리성
- 사용자(독자)에게 도달하기까지를 상상하며 블로그를 손수 구축하는 즐거움
계속 해 왔던 개발이 아닌 디자인이라는 새로운 역할을 수행해야 했기 때문에 과정 자체만으로도 많은 것을 배울 수 있었던 작업이었습니다. 데드라인의 압박과 생소한 분야라는 점 때문에 주위 디자이너분들이 추천해 주신 UX 디자인 방법론들의 아주 일부분만 가져와서 적용한 것은 조금 아쉬웠어요.
하지만 예전부터 고민해 왔던 블로그의 목적성과 무엇을 전달하고자 하는가에 대해서는 스스로 납득하고 해소하기 충분한 계기가 되었습니다. 누군가 제가 프론트엔드를 좋아하는 이유를 물어볼 때면, 프로덕트를 구성하는 부분 중 사용자에게 가장 가까이 도달할 수 있는 인터페이스를 개발한다는 점이 매력적이라는 이유로 설명하곤 하는데요. 작성한 포스트들이 독자에게 어떤 방식으로 읽히고 정보가 전달될지를 고려하는 작업이 너무나도 재밌었다는 점에서 아이러니하게도 프론트엔드 개발의 매력적인 면을 다시 한번 느낄 수 있던 시간이었습니다.
앞으로 직접 파도를 느끼고 부딪히며 꾸준히 개발자국을 남겨 보려고 해요. 블로그에 글을 올리는 시점은 한순간이지만, 그 글을 작성하기 위해 고민한 시간이야말로 진정으로 의미 있는 순간이라고 생각합니다. 이 블로그를 통해 제가 ‘인터페이스를 통해 사용자에게 감동을 전달하는 프론트엔드 엔지니어‘ 가 되어가는 과정을 담아내는 것뿐만 아니라, 독자들의 피드백을 더 해 흐르는 순간들을 그대로 기록해 나갔으면 하는 게 작은 바람입니다.
잘 부탁드려요! ✨
