[오오투두 2편] 디자인... 디자인 시스템... 그리고 모듈화.

들어가며

네, 2편으로 찾아왔습니다. 이번 글에서는 제가 디자인을 어떻게 했고, 그에 따라 디자인 시스템은 어떻게 만들려고 했는지 소개하고자 합니다. 여러 레퍼런스나 글을 참고했지만 그 중에서 SOCAR 디자인 시스템을 가장 많이 참고했고 따라하고자 했습니다. 자 함께 가보시죠. (어디를 가자는 걸까요?)

---

재료 준비

본격적인 와이어 프레임과 레이아웃을 만들기 전에 재료를 준비하려고 했습니다. 여기서 재료라고 함은 Color, Typography, Icongraphy, Spacing,  Radius, UI Components 등을 이야기합니다. 뭐 더 많을 숫도 있겠죠? 재료를 먼저 준비해놓고 디자인을 시작했습니다. 정말 개인 프로젝트라 제 맘대로 러프하게 한 것이라서 전문가의 입장에서 보면 허접할 수도 있어요.. 그냥 참고 봐주세요 ㅎㅎ

 

로고(Logo)

로고

초안

 

그림은 아이패드 앱인 프로크리에이트 앱을 이용한 손그림입니다 ㅋㅋ 무심한 듯 그린게 포인트입니다. (사실 그림 실력이 안돼서 합리화 ㅋㅋ) 처음에는 허리 굽은 거를 표현하려다가 되게 이상한 친구가 되어버려서 옷도 입히고 다시 그린게 지금의 로고입니다. 체크 남방도 입혀주었어요. 이 친구는 싹이난 감자를 형상화한 아이인데요. 하기 싫어하는 표정이 일품인 친구입니다 ㅋㅋ 아 좀 더 예쁘게 그려줄 걸 그랬나요.. 어쨌든 로고는 이렇구요. 나중에 다시 그리던가 해야겠어요 ㅋㅋㅋ

 

컬러(Color)

Color

 

커밋의 초록색, 그리고 감자의 노란색을 포인트 컬러로 정했습니다. 단순하죠? ㅋㅋ 그리고 나름 어깨 너머로 습득한.. Grey Scale... (아 뭔가 창피한데.. 어쩔 수 없어요...) 숫자를 100단위로 증가시키면서 색의 진하기를 파악할 수 있도록 했습니다.

 

 

폰트/타이포그라피(Typography)

폰트는 Pretendard 폰트를 사용했어요. 깔끔해서 좋더라구요. 개발하면서 느낀거지만, 디자이너의 수고로움을 정말 많이 느꼈습니다... 아 그리고 처음에는 Bold와 Regular만 생각했었는데 Medium weight의 폰트도 필요하더라구요.. 확실히 시간이 많이 없어서 디자인 계획을 더 꼼꼼히 세우지 못해서 아쉬웠어요...

 

 

아이콘(Icongraphy)

무료 아이콘을 이용했고, 사용하는 아이콘 개수를 최대한 적게 가져가고 싶었습니다. 계획했던 것과 달리 사용하지 않은 아이콘도 있고, 생각보다 어울리지 않은 아이콘도 있었던 것 같아요. 뒤에서 소개하겠지만 SVG 파일로 아이콘을 넣어놓고 사이즈는 필요에 맞게 조절해서 사용하는 방식으로 했습니다. 기본 사이즈는 24px로 생각했어요.

 

 

간격, 둥글기(Spacing, Radius)

개발하면서 가장 애매했던 부분이 Spacing과 Radius였습니다. 처음에 정해놓은 값 이외에도 디자인에 따라 필요한 수치가 다른 것들이 생기더라구요. 나중에는 시간에 쫓기다보니까 수치를 리터럴하게 넣어서 사용했는데 그 부분은 리팩터링 시에 다시 한 클래스/구조체에 모아놓으려고 합니다.

 

 

컴포넌트(Components)

재사용되는 컴포넌트는 따로 정의했습니다. 이 컴포넌트들은 클래스로 따로 만들어 바로 재사용할 수 있도록 하고자 했어요. 특히 네비게이션 바는 기본 형태를 사용하지 않는다면 커스텀 클래스로 만들어 사용하면 편한 것 같습니다.

 

그리고 버튼이나 셀, 텍스트 필드, 스위치 등의 녀석도 일단 이런 식으로 컴포넌트 디자인을 해놓았습니다. 그런데 디자인과 개발을 하면서 고민이 생겼습니다. 가장 많이 들었던 생각은 어디까지 따로 재사용 클래스로 만들어야 할까? 라는 생각이었어요. 처음에는 셀 등의 컴포넌트도 다 따로 모듈로 빼서 가져와서 써야지라는 생각을 했었는데 하나의 뷰에서 사용되는 것이면 굳이 따로 빼서 만들 필요가 있을까라는 생각이 들더라구요. 그래서 그 범위를 어디까지 가져가야 할 지에 대해서도 생각이 필요했던 것 같습니다.

 

---

레이아웃 디자인

레이아웃 디자인에 대해서는 일부만 내용을 적어보도록 하겠습니다.

 

투두 항목 추가 뷰 간소화

UX에 대한 고민을 하게 되는 좋은 시간이었습니다.

투두 항목 추가

투두 항목 추가를 어떻게 해야할 지 고민이 정말 많았어요. 투두 메이트와 같은 앱을 보면 바로 텍스트 필드가 나와서 적기 편한 구조로 되어 있습니다. 또 어떤 앱을 보면 아예 페이지(뷰)가 새로 나와서 할 일을 추가하는 형태로 앱이 구성되어 있습니다. 최대한 사용성을 편리하게 가져가고 싶은데 텍스트 필드에 바로 적는 형태로는 처음에 기획했던 내용을 만족할 수가 없더라구요. 할 일의 우선 순위를 선택하게 하고 싶고, 기본 블록을 동시에 제공하고 싶고, 그리고 이후에 관련 프로젝트까지 선택할 수 있게 해서 프로젝트 매니징의 역할에도 도움을 주기 위해서는 완전 간단한 형태로 할 일을 추가하기에는 어려움이 있었습니다. 그렇다고 새로운 페이지를 push해서 할 일을 추가하는 것은 귀찮기도 하고 앱이 무거워지는 느낌을 받았어요.

 

그래서 타협점을 찾았습니다. 현재 투두 리스트 뷰에서 할 일을 추가할 수 있도록 하되 기획 요소를 최대한 반영할 수 있게 구성해보자라는 것이었죠. 그에 따라 시트를 올려서 할 일(투두)을 추가하는 방식으로 결정하게 되었습니다.

 

처음에는 시트 안에서 기본 블록을 이용해서 할 일을 추가하는 것과 사용자가 직접 내용을 입력해서 할 일을 추가하는 것을 구분짓기 위해서 상단에 스위치를 두었어요. 그런데 멘토님의 피드백을 듣고 나니까 생각이 바뀌게 되었습니다. 사용자가 앱을 사용하는데 들이는 노력을 최소화해야 한다라는 것이었죠. Depth가 깊고, 앱을 사용하는데 귀찮음을 느끼는 순간 사용자는 앱을 사용하지 않을게 분명하기 때문입니다. 생각을 해보니까 저도 그럼 안 쓸 것 같았습니다. 그래서 시트의 작성부를 하나로 통일하는 형태로 바꿨어요. 마지막 화면처럼요!

 

그리고 우선순위 항목도 처음에는 6개 정도 되었는데 사용자가 과연 그 기준을 구분할 수 있을까라는 중요한 고민 지점도 있었습니다. p0~p4까지 구분지었던 우선순위를 직관적으로 선택할 수 있게 상, 중, 하로 바꾸는 작업도 진행했어요.

 

 

프로젝트 아카이빙 뷰 항목 간소화

프로젝트를 아카이빙 하는 부분도 고민과 개선을 시도했습니다. 원래는 작성 항목이 더 많았는데요. 입력하는 필드가 많아질 수록 사용자는 피로를 느끼고 앱을 사용하기 싫어집니다. 그렇기에 최대한 간소화하는 작업이 필요했어요. 그래서 담당한 기능 및 역할, 깨달은 점 등 메모할 수 있는 항목은 메모 필드로 통일해서 작성할 수 있도록 하되 placeholder로 가이드를 주어서 사용자가 입력하려는 내용에 대한 방향성을 잃지 않도록 했습니다. 지금도 항목이 많은 것 같은데 더 줄일 수 있는 방안에 대해서 고민을 해봐야겠어요.

---

디자인 시스템과 모듈화

회고 성격의 글이라서 코드를 자세히 다루지는 않습니다.

 

 

위에서 정의해놓았던 디자인 시스템을 모듈로 따로 분리해서 개발을 진행했습니다. 역할과 성격을 분리해서 개발을 진행하고 싶었어요. 이름은 OOTD-UIKit로 지었습니다 ㅋㅋ

 

 

해당 모듈에 들어가는 내용은 크게 Resources와 Components로 나눌 수 있을 것 같아요. 리소스에는 컬러, 폰트, 아이콘 등이 들어갈 것이고 컴포넌트에는 더 큰 단위의 UI 요소가 들어갈 수 있을 것 같습니다. 모듈안에 커스텀 클래스를 정의 해놓고 실제 개발하는 뷰에서 불러와 사용하는 식으로 개발을 진행했어요.

 

OOTD_UIKit 모듈을 import하고 해당 모듈에서 정의해놓은 ODSNavigationBar 커스텀 클래스를 불러와 사용하는 식입니다. 코드를 더 자세히 분석하고 내용을 적기에는 글이 너무 길어질 것 같아서 해당 부분에 관심이 있으신 분들은 디자인 시스템에 대해서 찾아보시면 좋을 것 같습니다.

 

이런 식으로 개발을 진행하다보니까 처음에 디자인, 준비, 세팅 등의 과정에서 시간은 좀 걸렸습니다. 그런데 뷰를 재사용해서 쓸 수 있는 형태로 만들어놓으니까 이후에 실제 개발 시간은 정말 많이 줄어들더라구요. 그래서 상황에 맞게 진행하는 것이 중요할 것 같습니다. 협업 시에는 디자인이 모두 나와있는 경우나 어느 정도 나와있는 경우에 진행하면 좋을 것 같고 개인 프로젝트의 경우 디자인/디자인 시스템을 만들 수 있는 시간이 충분히 존재하는 경우에 시도해볼만한 것 같습니다. 시간이 부족하다면 이후에 리팩터링 과정에서 모듈화하는 것도 좋을 것 같아요.

 

---

디자인 시스템을 추가하면서 생각했던 것들

초반에는 스스로 리뷰도 해가면서 생각을 많이 했던 것 같아요. 내가 짠 코드라도 개발을 마치고 난 다음에 보면 이런 저런 생각이 들더라구요? 시간만 충분하다면 본인의 코드를 곱씹어보는 시간을 가지면 정말 좋다라는 것을 많이 느꼈습니다. 물론 피드백을 줄 수 있는 팀원 또는 멘토님이 계시면 더욱 좋겠지만요!

 

자체 리뷰 몇 가지만 가져와봤습니다.

 

 

---

디자인편 마무리

- 개발자로서도 UX/UI를 고민해보는 작업은 정말 중요하다고 생각을 하는 입장인데 이를 몸소 체험해볼 수 있는 좋은 시간이었습니다. 언제 혼자 기획, 디자인을 다 해보겠어요...(근데 정말 기획자, 디자이너 존경합니다...)

- 모듈화의 장단점을 생각해볼 수 있는 시간이었고, 정리가 더 필요할 것 같습니다.

- 어느 정도까지를 재사용 클래스로 만들지 기준을 정해야할 것 같습니다. 물론 2번 이상 사용되는 것은 공통 클래스로 만드는 것이 더 나을 것 같은데요. 하나의 뷰에서 사용되는 컴포넌트까지 모듈로 따로 빼올 필요가 있을지는 고민이 되는 것 같습니다.

 

생각보다 디자인하고, 디자인 시스템 만들고 하는데 많은 시간을 썼던 것 같은데 의미있는 시간이었던 것 같습니다. 오히려 무작정 개발부터 시작했으면 마무리가 더 쉽지 않았을 것 같다라는 생각이 들었습니다. 추가로 디자인 시스템 구축에 대한 부분을 좀 더 자세하게 코드랑 공유를 하면 좋았겠지만 그러면 글이 너무 길어질 것 같아서 생략했습니다. 이는 나중에 기회가 되면 적어보려고 해요.

 

다음 편에서는 개발하면서 겪었던 어려움 또는 기술적인 고민에 관련된 내용을 적어보겠습니다. 긴 글 읽어주셔서 감사합니다 :)