[팀] 겸상 - 4주차 전체미팅: Wireframe 설계(220529)

| Wireframe 설계

진행 과정

Wireframe 설계에 쓸 툴로 카카오 오븐과 피그마를 놓고 고민했었다. 카카오 오븐은 협업이 곤란하다고 하여 망설임 없이-만장일치-피그마를 채택했다. Wireframe 설계 작업은 만만찮았고 우리 팀은 금요일 하루를 제외하고 매일 밤 자정까지 미팅을 가졌으며, 발표 한 시간 전에도 리허설을 진행했다. 첫 미팅 때는 아래의 유의 사항을 함께 공유했는데 "화면 설계서를 이쁘게 그릴 필요 없다. 필요한 기능이 모두 다 들어가야 한다. User flow에 따른 화면 설계를 해야 한다." 이 세 가지를 특히 강조했다. Wireframe 설계 시 유의 사항은 멘토님의 영상의 내용을 우리 팀장이 정리한 것이다.

 

Wireframe설계 시 유의 사항

• 와이어프레임(화면 설계서)은 선(Wire)으로 이루어진 화면 구조(Frame)를 표현하는 문서이다.
• 해상도(스크린 사이즈)에 따른 레이아웃을 고려해야 한다.
• 메뉴(기능)의 중요도/우선순위에 따라 제작하면 좋다.
• 툴은 피그마, PPT, 종이 다 괜찮다.
• 화면을 어떤 구조, 어떤 필드로 구성, 어떤 버튼 어떻게 배치할지 위한 용도이다.
• 각 화면에는 어떤 데이터 필드가 들어갈 것인지를 정의한다.
• 기간 내-3개월 동안-구현 가능한 목표에 맞게 작성한다.
• 등록 화면은 어떻게 단순화시켜서 만들 수 있을까?
• 전체적으로 서비스의 화면을 설계함에 있어서 전략이 필요하다.
• 화면 설계서를 이쁘게 그릴 필요 없다.
• 필요한 기능이 모두 다 들어가 있도록 잘 그리는 것이 제일 중요하다. (핵심이 되는 화면은 반드시 설계)
• 서비스가 성공하기 위한 전략이 잘 들어가야 한다.
• 와이어프레임을 잘 구성해야 DB 설계를 제대로 잘할 수 있다.
• 얼마큼 잘 풀어내고 잘 접근해서 프로토타입을 만들 수 있나?
• 가능성 및 핵심 기능 잘 구현이 가능한가?
• User flow에 따른 화면 설계를 해야 한다.
• 용어 신경 써야 한다. (레이블링 시스템 활용)
• 불필요한 기능을 중복하여 넣지 않도록 한다.
• 삭제 기능은 유의해서 설계해야 한다.

 

피드백에 대한 생각

발표는 4팀부터 역순으로 진행되었고 약 50분의 시간 동안 탈탈 털렸다. 2팀인 우리 팀은 3번째 발표였고 매 맞기를 기다리는 마음이었다. 당시 단톡방의 기록들이 그때의 불안감을 잘 보여준다. 그런데 이게 웬일인가? 모든 팀을 통틀어 극찬을 받았다. 발표자도 침착하게 아주 잘했고, 나는 손흥민 선수와 함께 경기에 임하는 코칭스태프가 된 기분이었다.

멘토님은 레이블링에 대해서도 칭찬을 아끼지 않으셨다. "겸상"이라는 서비스명, "밥장, 숟갈"이라는 사용자 페르소나, "밥상"이라는 플로우 모두 매력적으로 보셨다. "겸상"이라는 용어는 팀 내에서 선호도가 갈렸었고 다른 서비스명이 없었기 때문에 가칭한 것이었는데 그것 마저도 극찬(?)을 받은 것이다.

멘토님의 피드백 중 중요 내용은 다음과 같다.

1. 굳이 혼행 서비스 내에만 겸상 서비스를 둘 필요가 없을 것 같다. 겸상 홀로-완전한-하나의 서비스이다.
2. 밥장에게 선택받지 못한 숟갈에 대한 안내 메시지가 필요할 것 같다.
3. 밥장이 숟갈을 선택하는 시점을 고민해봐야 할 것 같다.

 

1번의 경우 팀원 모두 100% 공감하였다. 심지어 밥을 먹는 것 외에도 커피, 술 등 모든 혼자 하게 되는 경우에 우리 서비스를 응용할 수 있겠다는 생각이 들었다.

2번의 경우는 발표 이후 진행된 팀 미팅을 거쳐 메시지를 보내지 않는 것으로 결정하였다. 이는 우리 서비스의 정체성에 대한 고민 때문이다. 우리는 일면식 없는 사용자들이 함께 식사를 할 수 있게 하는 것에만 집중하기로 하였다. 그 외의 기능은 가능한 모두 재단하여 미니멀한 서비스를 제공하고 싶었다. 그런 측면에서 "거절" 메시지는 불필요하다고 생각했다. 낚시를 예로 들자면 숟갈이 밥상을 낚기 위해 미끼를 여기저기 뿌릴 것이다. 이때 찌가 움직이거나 낚시 줄이 팽팽해지면 물었다는 것을 알게 될 것이다. 그 외에는 어떤 일도 일어나지 않는다. 미끼를 물지 않은 모든 물고기들이 낚시꾼에게 알림을 줄 필요는 없지 않은가? 그리고 서비스를 사용할 때마다 거절이라는 부정적 메시지를 받게 된다면 UX적으로도 좋지 않을 거라 판단했다.

3번은 꼭 필요한데 결정하기가 정말 난해하다. 몇 차례 회의를 거쳤음에도 결정을 못해 미루고 있는 중이다. 그 과정에서 우리 서비스의 핵심적인 룰 중 하나라는 것을 모두가 동감하게 된 것이 성과라면 성과이다.

 

4주 차 Wireframe 설계 풀영상

https://youtu.be/93TyBAuFGTk

 

※ 참고: 보고서, 발표자료, Wireframe

개발자의품격4기-2팀-4주차-와이어프레임.fig

1.62MB

개발자의품격4기-2팀-4주차-UI설계-보고서.pdf

0.50MB

개발자의품격4기-2팀-4주차-UI설계-발표자료.pdf

2.43MB