신규 서비스 출시(#5)_UI 디자인 시스템 공유
스타트업 앱 출시 과정을 기록하다.
안녕하세요.
글쓴이 김효진입니다.
공지사항이 있어 이렇게 글을 남기게 되었습니다.
먼저 저의 `신규 서비스 출시의 처음과 끝`이라는 매거진을 긍정적으로 검토해주시고, 시간이 지난 시점에서도 관심 가져주시는 모든 분께 감사하다는 말씀을 전하고 싶습니다.
본론으로 돌아와, 기존 서비스의 리뉴얼이 결정됨에 따라 앱과 서비스 관련 자료들이 모두 내려가게 되었습니다. 비록 이직한 상태이지만 기존 서비스를 유추할 수 있는 글과 자료들은 잠시 내리는 것이 좋다고 판단되었습니다. 모두 내려가는 것은 아니지만 글을 읽는 데에 있어 어색한 부분이 생길 수 있습니다.
이점 양해의 말씀드립니다.
일교차가 심해진 요즘 모두 감기 조심하시고,
추가 문의 사항은 hyoi03031202@gmail.com으로 DM 남겨주세요!
감사합니다 :)
2019년도에 출시하였던 플랫폼의 디자인 시스템이다. 지금 생각해보니 이 당시 디자인 시스템에 대한 정확한 이해 없이 흉내만 내고 있었던 것 같다.NDS(noonch Design System)를 발전시키게 된 배경
이전 서비스들과 다르게 눈치는 복잡한 흐름을 가지고 있었으며, 디자인해야 하는 프레임 수도 많았기 때문에, 출시 이후 디자인 시스템을 구축한다면 모두가 난감해질 수 있는 상황이었다. 또한 프로덕트의 기능이 확장되었을 때, 서비스의 일관된 경험을 제공하기 위해 디자인 시스템의 개념을 다잡고, 체계화시킬 필요를 느꼈다.
이번 눈치 디자인 시스템은 Xd에서 작업하였으며, 개발자는 Xd도 함께 공유하고 있지만, 추후 디자인 시스템 사이트를 구축할 수도 있기 때문에 위지윅 에디터인 typora에서 문서작업도 함께 진행하였다.
눈치는 1차 출시를 마쳤으며, 앞으로 인터렉션 설계와 사용자 피드백을 토대로 업데이트될 예정이고, 이에 맞춰 NDS도 업데이트될 것이다.
눈치 이후 서비스부터는 Figma에서 작업하고 있다. 현재 기업에서 추구하는 디자인 툴은 Xd에서 Figma로 변경된 상태이다.
NDS Principle
명확성(Clarity): 디자이너가 디자인 신념과 플랫폼 전반에 걸친 디자인 제약에 대해 명확하게 생각할 수 있도록 한다.
일관성(Consistency): 제품 전반에 걸쳐 일관성을 추구함으로써 플랫폼 전반에 안전성, 친숙한 경험을 부여한다.
효율성(Efficiency): 팀 전체에 걸쳐 이해도를 높임으로써, 세부사항에 집중할 수 있도록 한다.
즉, NDS는 디자이너와 개발자, PM, 마케터 간 효율적인 소통을 위한 시각적 디자인 언어이며, 일관성과 효율성을 창출하므로 더 높은 수준의 비즈니스 구축에 도움이 된다.
▪ 신규 서비스 출시(#5)_UI 디자인 시스템 공유 목차
01. UI 디자인 시스템
02. 디자인 시스템은 왜 필요한가
03. 디자인 언어: 문서화
03-1. 마크다운(MarkDown)
03-2. 위지윅(WSYWIG) 에디터를 통해 마크다운 사용하기
04. 시각적 디자인 언어 생성
04-1. Color
04-2. Spacing
04-3. Button
05. 디자인 이슈사항
06. 앱 출시를 위한 필수 항목 체크
01. UI 디자인 시스템
UI 시스템 또는 UI 디자인 시스템은 회사의 디자이너, 개발자 및 협력사가 소프트웨어 제품의 룩앤필에서 품질을 일관되게 유지할 수 있게 도와주는 UI 스타일 및 표준 시스템이다. 이는 컴포넌트 기반 접근법을 사용하는데, 서로 다른 운영체제 표준에 충실하면서도 가능한 기능성과 룩앤필을 표준화하는데 초점을 맞춘다. 사용하는 프로그래밍 언어와 같은 구현 기술을 명시하지는 않는다.
디자인 시스템은 팀이 제품을 설계, 실현 및 개발할 수 있는
모든 요소를 그룹화하는 단일 소스이다.
따라서, 디자인 시스템은 단순 결과물이 아니라 결과물의 집합이다,
제품, 툴 및 기술이 발전함에 따라 지속적으로 업데이트될 것이다.
*룩 앤드 필(Look and feel)
마케팅, 브랜딩, 상표화와 같은 분야의 제품의 내용에 쓰이는 용어로, 사용자의 제품 체험과 겉모양, 인터페이스의 주된 기능을 나타낸다. 소프트웨어 디자인에서 룩 앤드 필은 그래픽 사용자 인터페이스의 관점에서 쓰이며 색, 모양, 레이아웃(텍스트 크기, 글꼴 등)뿐 아니라 버튼, 메뉴와 같은 동적인 요소의 동작을 수반하는 디자인 측면을 이루고 있다.
제니퍼 티드웰, 찰스 브루어, 『사용자를 끌어들이는 UX/UI의 비밀』, 인사이트, 516.
02. 디자인 시스템은 왜 필요한가
• 디자인 및 개발을 규모에 맞게 신속하게 생성, 반복(복제)할 수 있다.
디자인 시스템의 중요 이점은 사전에 구축된 UI 구성 요소를 활용하여 디자인을 신속하게 복제할 수 있다는 것이다. 팀은 동일한 요소를 계속해서 사용할 수 있으므로, 재창조할 필요성을 줄이고 일관성 있는 디자인을 추구할 수 있다.
• 더 복잡한 문제에 집중하기 위해 디자인 리소스에 대한 부담을 덜어준다.
단순한 UI 요소가 이미 만들어져 재사용이 가능하기 때문에 시각적 모양 조정에 덜 집중할 수 있으며, 복잡한 문제(정보 우선순위화, 워크 플로우 최적화 및 여정 관리)에 더 집중할 수 있다. 프레임 수가 적다면 이 장점은 작아 보일 수 있지만, 여러 팀과 수천 개의 프레임을 작업해야 한다면 상당한 효과가 있다.
• 팀 간에 통일된 언어를 만들 수 있다.
디자인 책임자가 부서를 이동하거나 팀이 분산되었을 때 통일된 언어는 잘못된 커뮤니케이션으로 인해 낭비되는 디자인 추출물 또는 개발 시간을 줄여준다.
• 제품, 채널 및 (잠재적으로 분산된) 부서 간에 시각적 일관성을 제공한다.
특히 다른 제품과 독립적으로 운영되는 제품 또는 채널일 경우, 디자인 시스템 부재로 인해 해당 브랜드와 무관한 제품, 채널처럼 보일 수 있다. 디자인 시스템은 구성요소, 패턴 및 스타일의 단일 요소를 제공하고 분리된 경험을 통합하여 시각적으로 통일성을 부여한다. 또한 주요 시각적 요소를 리디자인 또는 리브랜딩 시 디자인 시스템을 통해 관리할 수 있다.
• 새로운 팀원, 콘텐츠 기획자를 위한 지침서가 될 수 있다.
명시적으로 작성된 사용자 지침 및 스타일 가이드는 UI 디자인 또는 콘텐츠 제작을 처음 접하는 기획자를 온보딩 하는데 도움이 되며 나머지 팀원에게도 알림 역할을 한다.
Therese Fessenden, "Design Systems 101", April 11, 2021
※Onboarding(온보딩)
처음 Onboarding이란 신입 사원이 새로운 직장에 적응하도록 돕는 것을 의하는 HR분야에서 비롯된 것이다. 이를 서비스에 적용해보자면 앱을 처음 활용하는 사용자들이 앱을 계속해서 사용할 수 있는 ‘명확한 이유와 가치’를 보여주는 것이다. 또한 소프트웨어 개발에서 Onboarding이란 사용자가 제품을 성공적으로 채택하고 완전히 사용하도록 돕는 것을 말한다.
03. 디자인 언어: 문서화
모든 팀이 같은 방법론과 패턴을 고수하고 있다는 것을 확실히 하기 위해 문서화는 필수이다. 또한 현재 진행 중인 프로젝트에 대한 설계 원칙을 언제든 참조할 수 있어야 한다. 팀원이 소수라고 할지라도 정리되어있지 않은 디자인 언어를 사용하는 것은 의사소통에 장애를 일으키는 주요 원인이 될 것이다.
앞서 말한 바와 같이 추후 디자인 시스템 사이트를 구축할 수도 있기 때문에 문서작업에 신경 쓰는 것도 있지만, 제일 큰 이유는 디자인 시스템에 대한 기업 내부 매뉴얼이 없기 때문에, 초기 가이드라인을 만들고 싶었다. 아직 부족한 부분은 많다. 현재 디자인 시스템은 눈치에 치중되어 있지만, 시행착오를 거쳐 온전히 기업의 디자인 시스템이 완성될 수 있도록 모두가 참여하고 있다.
noonch design system > markdown 파일
noonch design system > markdown 파일초기 눈치 디자인 시스템에 대한 문서화 작업이며, 새로운 이슈사항이 생긴다면, 개발자와 협의 후 업데이트하고 있다. 정리된 문서는 개발자가 언제든 확인하고, 바로 적용할 수 있어야 하기 때문에, Github에 저장소를 만들어 업로드하였다.
noonch Design System 목차 구조의 경우 문서화해 놓았지만, 필요에 따라 좀 더 직관적으로 보일 수 있게 구조화하였다.03-1. 마크다운(MarkDown)
텍스트 기반의 마크업 언어로 2004년 존 그루버에 의해 만들어졌으며, 쉽게 쓰고 읽을 수 있으며, HTML로 변환이 가능하다. 특수기호와 문자를 이용한 매우 간단한 구조의 문법을 사용하여 웹에서도 보다 빠르게 콘텐츠를 작성하고 보다 직관적으로 인식할 수 있다.
마크다운(MarkDown)은 깃허브에서 readme.md의 기본 형식으로 사용하고 있어 학습이 필요하다. 마크다운을 통해 코드에 관한 설치방법, 소스코드 설명, 이슈 등을 간단하게 기록하고 가독성을 높일 수 있다.
03-2. 위지윅(WSYWIG) 에디터를 통해 마크다운 사용하기
위지윅(WYSIWYG: What You See Is What You Get, "보는 대로 얻는다")은 문서 편집 과정에서 화면에 포맷된 낱말, 문장이 출력물과 동일하게 나오는 방식을 말한다. 이는 편집 명령어를 입력하여 글꼴이나 문장 형태를 바꾸는 방식과 구별된다.
현재 대부분의 워드 프로세서, 엑셀도 위지윅 방식으로 사용하고 있다.
우리가 흔하게 접하는 웹에서 사용되는 에디터(네이버, 다음, 구글 등)가 대부분 위지윅 에디터에 속하며 기본적으로 HTML을 이용하여 스타일을 적용하여 문장을 꾸미는 형태를 취하게 된다. 그 외에도 무료 위지윅 에디터 타이포라, 서머노트 등이 있다.
기업의 경우 tpora(타이포라)를 사용하였으며, 추가적으로 Notion도 병행하여 사용하고 있다.
github, ihoneymon, 마크다운(Markdown) 사용법
tistory, hippogrammer, 마크다운 사용법(github readme.md 파일 저장 양식)
webdesignerdepot, ALAN POWER, CREATING A DESIGN SYSTEM LANGUAGE
04. 시각적 디자인 언어 생성
04-1. 컬러(Color)
04-1-1. 명도 대비
WCAG(Web Content Accessibility Guidelines, 웹 콘텐츠 접근성 지침), Success Criterion 1.4.3 Contrast (Minimum)에 의하면 텍스트와 텍스트 이미지(텍스트가 아닌 렌더링 된 텍스트, 예: 명찰에 있는 사람 이름)의 시각적 표현을 위한 명도 대비율은 최소 4.5:1 이상이 되어야 한다. 단, 다음의 경우는 제외한다.
큰 텍스트(Large Text) : 큰 텍스트와 텍스트 이미지가 최소한 3:1의 명도 대비를 가지고 있어야 한다.
※큰 텍스트(Large Text)
최소 18포인트 또는 14포인트의 볼드체(bold)
사용자와 친밀도를 감소시키는 형태의 글씨체(Thin, Light..) 특이한 글씨체는 낮은 명도 대비에서는 읽기가 더 어렵다. 매우 가는 글씨체는 지양하는 것이 좋다.
부수적(Incidental) : 비활성 사용자 인터페이스 요소(user interface element)의 일부, 어떠한 목적이나 기능 없이 심미적인 목적으로만 사용된 장식 , 텍스트 이미지에는 명도 대비 요구사항은 없다.
로고타입(Logotypes) : 로고 또는 상표명에 포함된 텍스트에는 명도 대비 요구사항은 없다.
명도 대비의 목적은 시력이 낮은 사용자도 읽을 수 있도록, 텍스트와 배경 사이에 충분한 대비를 제공하는 것이다.
04-1-2. 선택한 비율에 대한 이론적 근거
3:1의 대비 비율은 [ISO-9241-3]와 [ANSI-HFES-100-1988]에서 권장하는 표준 시력을 가진 사용자에게 허용 가능한 최소 대비 비율이다.
4.5:1의 명암비는 대략 80세 노인의 정형적인 시력을 가진 사용자에게 허용되는 최소 대비 비율이다.
7:1의 명암비는 보조 기술(확대 기능이 내장)을 사용하여 콘텐츠를 확인하는 사용자에게 허용되는 최소 대비 비율이다.
snook.ca, Colour Contrast Check에서 웹 접근성 기준에 부합하고 있는지 색상 대비를 확인해 보는 것도 좋을 것 같다.
04-1-3. 컬러 팔레트
MATERIAL DESIGN, Material palette generator을 통해보다 체계적인 컬러 팔레트를 추출할 수 있었다.
눈치의 메인 컬러는 blue-500이다.
noonch 컬러 팔레트
noonch 컬러 팔레트
noonch Design System - Color / Iconography / Typography
noonch Design System - Spacing04-2. 간격(Spacing)
스크롤 끝 간격, 양 옆 간격 이외에도 Data tables, Tab bar 등 디자인 컴포넌트를 어떤 방식으로 디자인하였는지 개발자와 공유하기 위해 정리해두었다. 디자이너 입장에서도 어떤 원리, 의도로 디자인하였는지 설명할 수 있어야 했기 때문에 일관성에 민감하게 대처하였다.
04-3. Component - Button
결과물이 많고 복잡한 경우, 한눈에 확인할 수 있게 도형을 이용하여 구조를 잡아보는 것도 좋은 방법이라고 생각한다. 또한 버튼의 네이밍을 정할 때도 도움이 되었다.
button은 Large, Regular, Small 세 가지 사이즈로 구분하였으며, Style(Fill, Line)과, Color, Statue(Enabled, Disabled, Pressed)로 세분화하였다.
Button 구성 구조
자주 사용되는 요소의 경우 코드로 정리해놓는 것이 좋다.Regular button의 경우 height: 50px, width:100%(모바일 기준, 양 옆 간격(양옆 margin)을 제외하고 버튼의 너비가 100%)를 주로 사용한다. 버튼의 유형이 반복되다 보니 이런 경우 코드로 정리하여 프론트 개발자가 복사하여 바로 사용할 수 있도록 밑 작업을 해놓는다.
기본적인 css작업이지만, 시간 단축 그리고 문서화해놓았기 때문에 바로 적용하기에도 편해서 도움이 된다는 개발자분들의 코멘트가 있었다.
05. 디자인 이슈사항
식당 리스트식당 리스트를 예로 들면, 아이폰 XS기준으로 작업하였지만, 가로가 좁아졌을 때(아이폰 6, 7, 8, SE) 식당명을 줄 내림 하여 전체를 보여줄 것인지, 1줄로 픽스하고 잘리는 부분은 '...'으로 표시해줄 것인지 고민하여야 한다. 정보의 중요도에 따라 중요한 정보라면 가로폭이 좁아지더라도 줄 내림하여 전체 문장을 볼 수 있게 하여야 한다. 이 부분은 개발자에게 중요한 요청사항이 될 수 있음으로 정해지는 대로 문서화는 필수이다.
06.
디자인 시스템 공유가 마무리되었다면,
앱 출시를 위한 필수 항목 체크
App Store 출시를 위한 필수 항목
• 아이콘
• 앱 이름 + 부제목
• 앱 설명 + 키워드 + 홍보 문구
• 앱 미리보기 또는 스크린샷 (최대 10장)
• 서비스 랜딩 페이지 URL
Google Play 출시를 위한 필수 항목
• 아이콘
• 서비스 명 + 부제목
• 서비스 설명
• 프로모션 동영상 또는 스크린샷 (최대 8장)
• 그래픽 이미지
App Store
스크린샷 (사이즈 두 가지)
• w:1242px / h:2688px
• w:1242px / h:2208px
Google Play
스크린샷
• w:1265px / h:2250px
• JPEG 또는 24비트 PNG(알파 미포함)
그래픽 이미지
• w:1024px / h:500px
• JPEG 또는 24비트 PNG(알파 미포함)
▪ 신규 서비스 출시 시리즈 목차
신규 서비스 출시(#1)_디지털 프로덕트 제작 프로세스
신규 서비스 출시(#5)_UI 디자인 시스템 공유(현재)
