[TIL] 설문과 API로 서비스 흐름 점검하기

오늘 한 일

• 사전 설문조사 구글폼 작성 및 배포
  • 사전조사를 통해 실제 타겟팅하는 사용자가 이 서비스를 사용할 의향이 있는지, 타인에게 내 소비 습관을 공개한다는 부분에 대해 거부감이 없는지 확인해보면 좋을 것 같다는 피드백을 반영함

• API 명세 초안 작성

• BE 회의

회의

유저 플로우에 대한 이해 부족

• 회의를 통해 가장 크게 느낀 점은 처음 ERD를 설계할 때 실제 사용자 흐름에 대한 이해가 부족했다는 점

• 기존에는 단순히 소비 기록 -> 랭킹 생성 -> AI 결과 생성 정도로만 생각했는데, 실제 와이어프레임과 연결해서 보니 사용자 입장에서 ‘어디서 어떤 결과를 보게 되는지’가 훨씬 중요했음

• 특히 아래 부분에서 프론트 와이어프레임과 초기 설계 차이를 발견함

  • 프론트 와이어프레임 기준
    • 초기

      • 하루에 여러 주제 존재 - 한 사람마다 별칭 제공

      • 주제를 벗어난 기준을 이용한 랭킹 생성

      • 상위 3명에게만 AI 로스팅 제공

      • 4위 이하 사용자는 개인 피드백 확인 불가능

    • 중간 변경 후

      • 하루에 하나의 주제 존재

      • 주제 기준 랭킹 생성

      • 상위 3명에게만 AI 로스팅 제공

      • 4위 이하 사용자는 개인 피드백 확인 불가능

  • 백엔드에서 생각한 방향

    • 개인 페이지에서 자신의 AI 로스팅 확인 가능

    • 또는 순위 공개 없이 4위 이하 사용자도 AI 피드백 확인 가능

  • 즉 단순히 AI 결과를 저장하는 것이 아니라, 누가 어디서 어떤 형태로 결과를 보게 되는지도 고려해야 한다는 걸 느낌

피드 구조에 대한 고민

• 또 하나 논의된 부분은 현재 와이어프레임에 Setlog 같은 피드 구조가 없다는 점

• 만약 피드를 추가한다면 시간순으로 소비 내역이 쌓이는 수직형 타임라인 구조를 생각하고 있음
  • 또한 사진은 저장하지 않기로 했기 때문에, 카테고리 아이콘 / 가맹점 / 금액 / 메모 등을 활용해 소비 피드를 구성하는 방향으로 고민함
• 개인 페이지를 만들어 하루 소비 내역을 누적해서 보여주는 구조도 이야기함

배운 점

• 논의를 하면서 ERD나 API를 단순 데이터 구조 관점으로만 보면 안 되고, 실제 사용자가 어떤 흐름으로 서비스를 사용하게 되는지까지 함께 봐야 한다는 걸 느꼈다.
  • 특히, AI 결과를 누가 볼 수 있는가 같은 정책 하나가 API, DB 구조, 화면 설계까지 모두 영향을 준다는 점이 인상적이었다.
• 처음에는 기능 중심으로 설계했다면, 이제는 점점 사용자 경험 중심으로 사고하게 되는 것 같다.

다음 할 일

• BE 회의 중 논의사항 전체 공유

• ERD 최종 수정

• API 명세 작성

• 각자 맡을 도메인 분담

• 프로젝트 세팅 후 개발 시작