210723(금) - 컴포넌트 폴더 구조, 마이 페이지 레이아웃, 이슈 티켓 단위 논의, UX 피드백

1. 컴포넌트 폴더 구조 (프론트)

2. 마이 페이지 레이아웃 (프론트)

3. api 요청 (프론트 + 백)

4. 이슈 티켓 단위 논의 (프론트)

5. UX 피드백

---

1. 컴포넌트 폴더 구조 (프론트)

기존에 components 폴더 안에 다양한 컴포넌트들이 섞여 있었다. 그중에는 Button과 같이 가장 기본이 작은 단위의 컴포넌트도 있고, PreviewList와 같이 우리 팀 도메인의 성격이 담긴 컴포넌트들도 같은 레벨의 수준으로 포함하고 있었다. 이 부분에 대해서 페어와 논의를 했다. 나는 컴포넌트를 common 폴더 등을 통해 이 둘을 구분할 필요가 있냐는 입장이었다. 컴포넌트를 수정하기 위해 검색하는 경우에 보통 cmd + p를 통해서 검색해서 이름만 알고 있다면 components 폴더 안의 컴포넌트들이 어떤 식으로 정리되어 있는지 상관이 없었기 때문이다. 페어는 컴포넌트를 찾을 때 옆의 폴더 구조를 보고 클릭해서 들어가는 경우와 cmd + p로 검색하는 경우가 반반이라고 했다. 이런 이유로 컴포넌트가 많아질수록 찾는데 어려움을 느낀다고 해서 components 앞에 common이라는 폴더를 하나 더 만들어, 이곳에 Button, Avatar 등 도메인의 성격을 지니지 않는 컴포넌트들을 모아놓기로 결정했다.

2. 마이 페이지 레이아웃 (프론트)

마이페이지와 관련해서 레이아웃을 잡았다. 마이페이지는 닉네임, 프로필 사진, 나이 등 개인 정보를 수정할 수 있고, 개인의 백신 접종 인증을 할 수 있는 곳이다. 사실 개인 정보 변경과 여러 서비스별 도메인에서 필요한 인증을 하는 레퍼런스는 많이 있는데, 레이 아웃을 구성하는 게 쉽지는 않았다. 사용자가 마이 페이지에 들어왔을 때 어떤 점을 기대하고 있을지, 어떤 부분을 첫 화면으로 보여주고, 우리 도메인에서 중요한 접종 인증을 어떻게 강조할지 등 이 부분들을 적절하게 합쳐서 구성하는 게 쉽지 않았기 때문이다. 그 결과 마이 페이지에 접근하면 일단 접종 인증을 할 수 있는 페이지를 가장 먼저 띄워주기로 결정했고, 개인 정보 수정 등 세부 내용들은 사이드 바로 선택할 수 있도록 했다.

3. api 요청 (프론트 + 백)

마이 페이지를 만들면서 추가적으로 필요한 api를 백엔드에게 요청했다. 하나는 백신 접종을 인증하기 위해서 필요한 api이다. 완벽한 인증을 할 수 없다는 앱의 치명적인 단점이 있지만, 일단은 인간 지능을 사용해서 사진을 보내면 사용자의 백신 접종 확인 인증을 완료하기로 했다. 따라서 아직 api의 구체적인 스펙은 나오지 않았지만 accessToken과 사진을 보내면 변경된 사용자 정보를 받아올 예정이다.

마이페이지 - 접종 인증 화면

다른 하나는 위 사진의 오른쪽 메뉴에서 보이는 것처럼 내가 쓴 글을 확인할 수 있는 api이다. 이전에 논의를 통해서 이후 구현할 부분이라 요청했다.

4. 이슈 티켓 단위 논의 (프론트)

우리 팀에서 이슈 티켓을 만들어서 작업을 진행하는데, 그 단위가 조금 크다는 느낌을 받았다. 그래서 페어와 같이 이야기를 해봤다. 페어는 아직 프로젝트 초반이라 완벽하게 정리된 상태가 아니기 때문에 과도기적인 상황이라고 했다. 또한, 완벽하게 분리하기 어렵다는 점도 들어서 말했다. 이 부분은 동의했다. 개인적으로 이슈 목록이 보여주기용은 아니지만, 그 수가 다른 팀에 비해 적은 것 같아서 괜스레 초조한 마음이 들었던 것은 사실이다. 그래서 이슈의 크기를 줄이면서 개수를 늘리고 싶었는데, 이게 페어의 말을 들으면서 이슈를 위한 이슈가 될 수도 있겠다는 생각이 들었다. 그리고 페어가 말한 '완벽하게 분리하기 어렵다'는 점도 코드가 완벽하게 모듈화 되어 작업이 진행되는 게 아니라서 여러 부분을 수정하기 마련인데, 그것들을 다 분리해서 커밋하기 어렵다는 점 때문에 일리 있다고 생각했다. 페어에게 이슈는 서로 다른 작업을 하면서 서로의 진행 상황을 알려주는 역할을 한다고 생각했는데, 나는 누군가에게 보여주기 위한 지표라고 생각했던 것 같다. 이 부분에서 이슈룰 생각하는 차이가 발생했다고 생각한다. 논점이 조금 흐려졌는데, 이슈에 대해 논의하면서 결론은 우리가 대부분을 작업을 같이 하고 있으므로 이슈를 계속 생성에게 서로에게 알려줄 필요는 굳이 없다는 점이고, 되도록이면 이슈가 development 브랜치에 pr을 날리는 것과 1대 1 대응이 되도록 해보자라는 점이었다.

5. UX 피드백

UX 디자이너로 일하는 친구에게 우리 애플리케이션에 대해서 피드백을 달라고 부탁했다. 서비스에 관련된 시점으로 바라봤을 때 많이 부족하다고 했다. 사용자가 이 사이트를 통해서 어떤 것을 얻고 싶어 할지 좀 더 고민해보라고 했다. 이 사이트에 방문하는 사용자는 백신을 선택할 수 있는 경우, 어떤 백신을 맞을지 선택하는 사람일 수도 있고, 이미 확정인 경우 백신을 맞기 전에 정보를 얻고 싶어 하는 사람일 수도 있다고 했다. 또한 잔여 백신 신청 방법을 궁금해하는 사람일 수도 있다고 했다. 즉, 다양한 사용자가 있는데 이들을 분류하고 그들이 얻고 싶어 하는 부분을 다시 UI로 풀어가야 한다고 했다. 단순하게 '사용자들은 이 사이트에 와서 백신을 맞고 후기를 공유할 거야'라고 생각한 부분은 부족했던 것 같다. 다시 사용자들의 관점에서 분석하고 필요한 정보는 무엇일까 고민해보는 시간을 가져야겠다.