DEVOCEAN

안녕하세요! 오픈랩 2기 운영 맡고 있는 kaka 입니다!

하반기 진행 프로젝트 때문에 4번째 모임 후기를 이제서야 올리네요 ;;;

4번째 모임에서는 초기 기획한 와이어프레임 토대로 화면설계 상세화 & Fe 구현위주로 진행되었습니다.

사용자가 인지할 수 있는 서비스의 얼굴이 나온 이후에 뒷단의 Back-end를 어떻게 붙일지,이때 서비스에 필요한 DB가 어떤것들이 있는지 논의하는 자리를 가졌습니다.

아웃풋을 산출하는 스터디인 만큼 일정관리 & 빠른 협의가 필수적이었습니다.

그래서 정기 모임 외에도 파트별로 필요한 미팅을 중간중간 진행하였어요!

프로젝트 초기에는 구체화 된 UX flow 중심으로 Front에서 구현을 어떻게 진행할 것인지 긴밀한 협의가 필요헀습니다.

그 과정 중 한가지를 소개해드리자면,

UI 라이브러리 선정하기

일정 상 전부 다 자체 개발을 진행할 수는 없으니 라이브러리를 활용하기로 했습니다.

그러기 위해서는 어떤 라이브러리를 활용할 것인지 선정하는 과정이 필요했는데요,

이 단계에서 Front 파트에서는 테스트를 진행해보고 어떤 라이브러리가 적합할 것 인지 의견을 공유했습니다.

UX 파트에서는 해당 라이브러리가 서비스를 전개하는데 적합한지 전체적인 디자인과 UX정책 및 기능을 포용하는지를 판단했습니다.

아래 내용을 고려하여 UI 라이브러리 선정을 진행했습니다.

1. UX 요구사항에 부합하는지?

2. 서비스에 필요한 컴포넌트 범위를 충족하는지?

3. 컴포넌트 커스터마이징 옵션을 제공하는지?

이때 발생되는 UX 요구사항과은 라이브러리 디자인 스타일이 우리가 만들고자 하는 서비스의 시각적 정체성에 부합하는지가 될 수 있습니다.

또한 UX요구사항에서 테마 커스텀이 가능한 서비스를 제공하고자 한다면 필요시에 Light/Darkmode 두가지를 모두 지원하는지도 점검 요소가 될 수 있죠.

컴포넌트의 범위는 Wireframe에서 작성된 서비스의 뼈대가 되는 시각적 흐름을 해당 라이브러리가 충족하는지를 판단하게 되는데요,

예를 들어 <검색하고 선택하는> 인터랙션이 많이 발생하는 서비스인데 이러한 컴포넌트가 없다면 해당 라이브러리를 사용할 이유가 없겠죠!

그리고, 모든 사용성을 고려한다면 선정한 라이브러리만 사용하는것은 분명한 한계가 존재하게 됩니다.

이 점을 고려한다면, 서비스의 완성도를 위해서는 필수적인 UI가 발생하는 건들에 한해서는 커스텀이 필요합니다.

그래서 컴포넌트 커스텀의 옵션을 제공하는지도 고려사항이 됩니다.

이미지는 저희가 만들 서비스의 온보딩 과정에서의 간략한 User flow 입니다.

해당 과정에서 사용자의 결정에 따라 페이지/기능을 결정하는 경로가 반드시 발생하는데요,

이러한 시나리오를 충족시키기 위해서는 UI의 일부 커스텀이 필요하게 되는 것이죠.

텍스트 필드를 예시로 들어보겠습니다.

라이브러리에서 제공되는 UI는 <입력 필드>만을 제공하는데,

우리가 사용자에게 제공하고 싶은 서비스는 입력필드가 많기 때문에 어떤 필드를 입력하는지 인지할 수 있는 'Label'이 필요합니다.

또한 입력사항이 제대로 <입력완료> 되었는지 사용자에게 명확히 전달하기를 원합니다!

이처럼 서비스 기획과 목표에 부합하기 위해 UI 커스텀이 발생하게 되는 것이죠 ㅎㅎ

마치는 글

프로젝트 초반이다 보니, UX/FE 파트 위주로 블로그 글이 작성되었는데요. 다음 글에서는 백엔드 파트의 이야기도 공유 드리겠습니다.

글 읽어주셔서 감사합니다~!

다음 글에서 만나요