어김없이 기록해보는 '모닥모닥' 프로젝트.
어 그런데 생각해보니 서비스 이름도 언급 안 하고 계속 프로젝트에 대한 얘기를 썼었네..!
React 7기 트랙의 분들과 함께 제작했던 서비스의 이름은 '모닥모닥'입니다!
이제 프로젝트라는 이름 말고 편의상 모닥모닥이라고 부르겠어요
이렇게 된 김에 서비스 링크도 올릴테니 구경해보실래요??
너무 소중한 나의 Baby인 모닥모닥 링크는 https://modak-modak.vercel.app/
모닥모닥
추억을 공유해요 친구들을 초대할 수 있어요!
modak-modak.vercel.app
손길이 안 닿은 곳이 정말 0.5도 없습니다... 관리자 페이지부터 사소한 로딩 화면 디자인까지
디자인관련 부분은 100% 제가 모두 담당을 했다는~
여튼 그래서 오늘도 저번 글에 이어서 이렇게 회고를 남겨보도록 하겠습니다.
와이어프레임 작업을 이런 식으로 유저 스토리를 기준으로 각 플로우의 화면을 제작 해서 공유를 드렸다.
개발자분들은 공통으로 사용되며 반복되는 UI를 컴포넌트로 만드시고 재활용하시는 걸 알기에 최대한 불필요한 요소를 없애는 식으로 작업을 진행했다.
피그마에도 비슷?동일?한 기능인 마스터 컴포넌트 기능이 있어서 나도 반복 작업을 줄이고 수정 사항을 한 번에 반영할 수 있게 반복되고 재사용되는 UI들은 마스터 컴포넌트로 만들어 관리했다. 사용할 때는 인스턴스를 사용하는 식으로!
오른쪽 사진은 사실 프로젝트 끝나고 정리해 놓은 것 ㅎㅎ...
#디자인 고도화
와이어프레임 작업을 진행하고 튜터님 피드백도 반영해서 디자인을 고도화 해나갔다!
개발자분들은 공통된 컴포넌트들을 조금씩 만들고 계셨고 개발 환경 구축을 해나가셨다.
디자인 고도화를 해 나가면서 WCAG에 맞춰 우리의 Main 색상을 다시 잡았다.
처음에는 오렌지?계열로 잡았었지만 접근성이 떨진다는 테스트 결과로 인해 AAA레벨을 최대한 맞추고 최소 AA까지 충족할 수 있는 색상으로 재선정했다.
테스트 했던 사이트는 https://webaim.org/resources/contrastchecker/
현재 색상이 더욱 모닥불스럽게 깊으면서 따뜻하고 친근한 이미지를 주어 바꾸길 잘 했다고 생각했다!
나는 직관적이고 명확한 디자인을 추구한다. 다소 심플해보일 수 있는 디자인이라고 해야하나?
그래서 여백, 간격 등의 위계를 굉장히 중요하게 여긴다! 이런 부분은 팀원들과 첫만남 때 아이스브레이킹하면서도 많이 말씀을 드렸던 부분이다. 그리고 브랜딩...?이라고 하기엔 좀 그렇지만 우리 서비스의 핵심 기능과 어울리는 컨셉과 이미지를 많이 고려한다.
모닥모닥이라는 서비스는 지인들과 함께 그 모임만의 추억과 일정을 공유하는 서비스이다.
이처럼 커뮤니티 형태의 서비스였기 때문에 부드러운 느낌을 줄 수 있게 UI요소에 라운드 값을 많이 활용했고 라이팅에서도 '-해요'체를 주로 사용했다.
만약 금융 서비스거나 조금 무거운 느낌의 서비스였다면 조금 더 신뢰감이 느껴지게끔 브랜딩(?)을 했을 것이다.
디자인 에셋같은 것들은 구글 드라이브에 폴더링해서 전달을 드렸다.
이번에 Webp라는 확장자에 대해 처음 알게 되었는데 이미지를 불러올 때 효율이 좋다고 하셨나?
그래서 팀원들이 다 webp 확장자로 달라고 하셔서 사용되는 이미지, 아이콘을 변환을 해서 svg, webp 두 가지로 전달을 드렸다!
그리고 rem에 대해서도 처음 알게 되었는데 나는 피그마로 디자인 작업을 하니 px값만 생각을 했다..!
다른 단위로 변환이 필요한지는 생각을 못했었다는ㅎㅎ... 하나 더 배워서 이 프로젝트 참여하길 잘 했다고 또 한번 생각했다.
그래서 rem에 대해 알아보고 튜터님께 자문을 구한 결과 px값을 rem으로 변환해주는 플러그인을 사용하면 된다고 하셨다.
피그마에 내가 저장해둔 스타일, 예를 들어 'body/14px'이라고 하면 이 값을 rem값으로 변환해 일관되게 코드에 사용하면 된다!
이런 맥락이었다. 그래서 관련 아티클과 플러그인을 첨부해서 개발자분들께 공유를 드렸다.
#예상하지 못했던 문제
디자인 고도화를 하며 핵심 기능 디자인은 완료하고 엣지 케이스들이나 예외적인 케이스에 대한 디자인을 하고 있던 도중 하나의 큰 장벽(?)을 만났다. 바로 우리 서비스는 모임을 만들고 일정을 등록하지 않으면 게시글을 쓸 수 없는 구조였는데 이 구조에 대한 의문..?이었다.
이게 왜 문제라고 생각을 했냐면 유저에 입장에서 불편할 것 같았기 때문이다.
만약 한 유저가 모닥모닥을 알게 되어 친구들과 쓰려고 로그인도 하고 회원가입을 하고 모임을 만들었다고 하자
그리고 친구들을 초대했다. 그러면 바로 글을 쓰고 싶을텐데 모닥모닥은 일정을 등록하지 않으면 게시글을 쓸 수 없다...
왜냐하면 우리 서비스는 모임의 일정을 기준으로 모임의 추억을 기록해주는 게 차별점(USP)이었기 때문에..!
일정이라고 하면 직접 만나는 날을 제일 먼저 떠올릴텐데... 친구들과의 일정을 바로 잡을 수 있는 것도 아니고
아무리 이전 일정을 등록할 수 있다고 해도 그 귀찮은 과정을 사용자들이 할까..? 하기 전에 귀찮다고 이탈하지 않을까?
이런 생각들이 들었다.
그래서 팀원들께 내가 생각해본 방안과 함께 빠르게 공유를 했다.
방안 2가지는 정말 가볍게 생각해 본 것이라 공유를 하고 나서 회의 시간 전까지 계속 고민을 해봤다.
(주말에 슬랙드려서 너무 죄송한 마음..ㅠ 회사였으면 절대 슬랙 안 했겠지..?)
#대망의 회의시간
매번 회의가 시작되기 30분 전에 이전 회의를 복기하며 현재 진행 상황, 공유드려야 할 내용 등등을 노션에 미리 정리해갔는데
이번에는 논의사항이 크게 있었기에 그 내용도 정리했다. 작성한 내용을 공유를 드리며 회의를 시작했다.
매번 열띤 회의를 해서 쉬는 시간도 막 지나갈 때도 많은 우리 팀ㅠ
여튼 이번 회의의 결론만 이야기 하자면
- 일정 등록->게시글 작성 플로우는 유지. 왜냐하면 일정을 기준으로 추억을 관리할 수 있다는 USP가 확립되었기 때문
- 대신 모임을 생성하면 '우리 모임이 생긴 날'이라는 일정명으로 자동으로 일정을 만들어주기
- 사용자에게 일정이라는 건 반드시 만나야하는 오프라인의 일정은 아니라는 것을 알려주기
이렇게 결론을 지었다. 납득이가고 만족스러운 결론이라고 생각했다.
(그런데 사용성 테스트 후 더더더 발전했다!! 그 내용은 다음 글에서 적어보겠다.)
모임을 만들어진 날에 맞춰 일정이 자동으로 생긴다면 게시글을 쓰러갔을 때도 당황하지 않을 것이고 일정을 선택해서 글을 써야 한다는 것을 자연스럽게 경험할 수 있을 것이다. 혼자 고민했으면 이런 결론에 도달하지 못했을 것 같아 함께 고민해준 우리 팀원들에게 너무 고마웠다!
그리고 UT를 통해 사용자들이 자연스럽게 받아들이는지 검증하기로 했다.
모임원의 생일이나 새해, 크리스마스 등등 그런 이벤트(?)에도 서로 일상을 어떻게 나누게 유도할지...
이것을 고민하는 게 나의 숙제였다.
그리고 추가로 공유드릴 것이랑 개발자 팀원들께 질문해야할 것들을 공유하며 회의를 마무리했다.
이렇게 프로젝트를 회고 하면서 느끼는 건 진짜 재밌었고 나 열심히 살았다.. 라는 것
얼른 취뽀해서 일하면서 도파민을 맛보고 싶다..! 일하면 도파민 터지는 사람=나
이번 글을 주저리 주저리 쓴 것 같다. 다음 글에서는 프디의 꽃 UT를 진행하면서 있었던 일에 대해 이야기를 해봐야지!
UT... 웃기도 하고 울기도 해서(진짜로 운 거 아님) 자세히 담고 회고 해봐야겠다.
아 그리고! 1차 시안에 대한 피드백을 멘토님께 받아서 팀원분들께도 함께 공유했었다!
크하하 하나 빼고 다 동그라뮈~!
원래 앱이랑 반응형까지 고려해서 웹 디자인도 하기로 했었어서 나머지 디바이스라는 말씀을 써주셨는데
우리는 결국 앱까지만 하고 반응형을 고려하지는 않기로 했다! 근데 웹에서도 접근할 수 있게 디자인 하긴 했다.
이 내용은 또 다음 글에서 같이 언급해보겠습니다~!!
'React 프로젝트' 카테고리의 다른 글
| Ep. 1 서비스 기획 마무리&와이어프레임 작업(근데 이제... 디자인을 곁들인) (1) | 2025.03.08 |
|---|---|
| Ep. 0 서비스 기획 과정(기획을 할 때 중요하다고 생각하는 점) (1) | 2025.02.07 |
| 오랜만에 근황을 남겨보자면... 새로운 프로젝트를 시작했습니다(?) (2) | 2025.02.01 |