▶ 직접 해보기

완벽한 시간은 없어요. 그래서 ‘되는 회의’를 판정해요.

번거로운 6명의 회의,
목적에 맞춰 딱.

빈 시간을 찾지 않아요. 이 시간을 잡아도 회의가 되는지를 판정하고, 근거와 함께 1순위를 정해줘요.

↓ 직접 해보기, 프로토타입으로 바로 가기 · 응답을 바꾸면 추천이 다시 계산되는 장면 먼저 보기

문제

캘린더가 비어 있어도,
되는 시간은 아니에요.

증거

응답을 바꾸면 추천이
실제로 다시 계산돼요.

직접 해보기 →
해결

빈 시간을 찾지 않고, 규칙으로 판정해요.
성립 = 꼭 함께할 사람 전원 ∧ 최소 인원.

01
Overview · 문제 정의

캘린더가 비어 있어도,
되는 시간은 아니에요

캘린더가 비어 있어도, 그게 진짜 되는 시간이라는 보장은 없어요. 카톡 “수요일은?” → “확인해볼게” → 미응답. 결국 누군가 흩어진 답을 대조해요. 진짜 마찰은 시간표가 아니라 누락·미기입·신뢰예요. 그래서 이 서비스는 참석자를 역할로 나누고, 회의가 성립하는 최소 조건부터 계산해요. 꼭 함께할 사람이 가능한 시간만 남기고, 선호·변동까지 반영해 가장 안정적인 1순위를 추천해요.
The Brief

6명이 회의 일정을 잡는 경험을 설계

같은 회사 동료 6명이 다음 주까지 모여야 합니다. 회의는 딱 1시간. 누군가는 점심 직후를 피하고 싶고, 어떤 사람은 특정 요일에 외근이 많습니다. 꼭 참석해야 하는 사람도, 선택 참석이어도 되는 사람도 있습니다.

인원 6명회의 60분기한 다음 주정성 조건 있음
02
Principles · 설계 원칙

‘완벽한 시간 없음’이
예외가 아니라 기본값

6명의 실제 제약이 겹치면 전원 만족 시간은 거의 없어요. 제품의 진짜 일은 “누구의 불편을 어떻게 다룰지” 설계하는 거예요.

원칙 01

거절은 사람이 아니라
시스템이 대신한다

개인 사정은 비공개로 받고, 결과 화면엔 “박서윤님이 안 된대요” 대신 “이 시간은 조건 충족이 낮아요”라고 말해요. 주어가 시스템이에요. 아무도 ‘반대한 사람’이 되지 않아요.

원칙 02

가용성은 묻지 않는다.
사람만 묻는다

“언제 되세요?”는 정중한 소음만 낳아요. 정성 조건은 자유 입력이 아니라 고르는 반응으로 받아서, 앱이 실제 계산에 쓸 수 있게 해요.

원칙 03

나열하지 않고
판정한다

후보를 늘어놓는 투표 앱이 아니라, 필수 조건을 거르고 안정성·선호로 점수를 매겨 1순위 하나를 근거와 함께 강하게 추천해요.

03
Core Model · 핵심 모델

6명을 동등하게
계산하지 않는다

회의 목적에 따라 참석자를 세 역할로 나눠요. 이 가중치가 곧 계산 엔진이에요.

김민수 이지현 박서윤 정다은 최준호 한유진
꼭 함께해야 하는 사람
김민수 · 이지현
이 사람이 불가능한 시간은 회의가 성립하지 않습니다.
불가능 → 후보에서 제외
함께하면 더 도움이 되는 사람
박서윤 · 정다은
없어도 회의는 되지만, 있으면 결과 품질이 올라갑니다.
불가능 → 추천 등급 하락
회의 후 결과를 받아볼 사람
최준호 · 한유진
참석은 선택. 원하면 참석 의사를 열어둘 수 있습니다.
시간 계산에서 제외
+ 정족수 모델 (국회식 결합)
역할 위에 개회 조건을 결합, ①꼭 함께(=의장 필수) ②최소 인원(의사정족수) ③결정형 회의엔 과반 권장(의결정족수).
성립 = 필수 전원 ∧ 인원 ≥ 최소
DECISION RULES · 이 회의를 판정하는 규칙
  1. R1 · 성립 = 꼭 함께할 사람 전원 가능 ∧ 인원 ≥ 최소. 다수결이 아니라 정족수예요.
  2. R2 · 꼭 함께할 사람이 안 되는 시간은 성립 불가라서 후보에서 빼요. 아래 프로토타입 추천 화면에서 직접 확인할 수 있어요.
  3. R3 · 선호(피하고 싶어요)는 ‘가능’이라 답한 시간에만 반영해요. 불가와 부담을 섞지 않아요.
  4. R4 · 확실하지 않으면 ‘가장 추천’ 대신 ‘현재 가장 유력’이라 말해요. 추측하지 않아요. 모르면 모른다고 해요.
  5. R5 · 거절의 주어는 시스템이에요. “○○님이 안 된대요”는 없어요. 사람 사이에 원망이 남지 않게요.
  6. 우선순위 · 규칙이 충돌하면 성립(R1·R2)이 선호(R3)에 항상 우선해요. 편한 시간보다, 성립하는 시간이에요.
이 규칙이 만든 화면의 태도 후보를 나열하지 않고 하나를 강하게 민다 · 한 명씩 물어보며 가중치를 쌓는다 · 참석자는 전원 같은 화면을 본다
R2가 실제로 도는 장면 바로 보기 →

화면은 이 규칙의 출력이에요. 시각은 도구로만. 차분한 추론·부드러운 확신의 톤을 위해 절제된 단색과 Pretendard를 썼어요.

04
Interactive Prototype · 직접 사용하기

질문 하나씩,
골라가며 만드는 흐름

화면엔 늘 하나의 질문만. 고르면 다음이 이어져요. 상단 탭으로 주최자·참석자를 전환해보세요. 추천 화면에서 꼭 함께할 사람을 ‘어려워요’로 바꾸면, 추천이 눈앞에서 다시 계산돼요.

Live walkthrough

주최자가 6명의 회의를 잡는 흐름

흐름
시안
9:41
파란 선택지를 눌러 직접 진행해보세요
이 화면의 설계 의도
Design note

색 시안 3종 (내부 확인용)
토스블루
오션
민트
05
Service Flow · 서비스 흐름

입력에서 확정까지,
한눈에 보는 화면 흐름

주최자·참석자 두 여정을 실제 화면으로 연결했어요. 가로로 스크롤해보세요, 본 흐름 아랫줄의 점선 카드는 그 화면에서 갈라지는 경우예요. 참석자는 전원 같은 중립 화면을 봐요. 누가 필수·병목인지 드러내지 않아요.

입력 정리 판정 확정
주최자 흐름Organizer100%
참석자 흐름Attendee100%
피그마처럼 보세요: 드래그 이동 · ⌘/Ctrl+스크롤 확대 · Shift+1 전체 맞춤 · [전체보기]로 크게 · 각 화면을 클릭하면 아래 프로토타입에서 그 지점부터 조작돼요
확정 화면은 경험의 끝이 아니라, 다음의 시작점

확정하면 끝이 아니라 회의록 예약 → 역할 기록 → 다음 회의로 이어져요. 여기서 정해진 역할은 원래 팀에 있던 거예요. 회의를 잡는 순간 드러날 뿐이에요. 그래서 다음 회의부터는 그 역할 위에서 계산이 먼저 시작돼 더 빨라져요.

06
Evidence · 최소 근거

왜 인트로·동의부터
고쳤나, 이탈 퍼널

업계 공개 벤치마크로 보정한 가설 퍼널입니다, 숫자는 주장할 사실이 아니라 출시 후 검증할 가설이에요. ‘권한·동의’와 ‘입력·응답’이 최대 이탈 가설 지점, 그래서 동의는 가치를 먼저 보여주고, 입력은 한 번에 하나씩으로 설계했어요.

진입 (링크·앱)
100
인트로 (가치 이해)
74
−26%“이게 뭐지 / 또 투표앱?”
권한·동의
52
−30%캘린더 권한·약관 = 최대 초크포인트
입력·응답
41
−21%필드·스텝 과다
완료 (확정 공유)
34
−17%응답 뒤 확정이 안 오는 방치

출시 후 측정, 같은 5구간으로 단계별 이탈률·체류시간을 재서, 이 가설 퍼널을 실측으로 바꿔요.
첫 실험, 최대 이탈 구간(권한·동의)에서 ‘가치 먼저’ 동의 화면 A/B로 −30% 가설을 확인해요.

위닝 패턴, 훔쳐온 것

  • 무마찰 응답 (When2meet), 가입 없이 바로: 딱의 ‘이름만 잇고 30초’ 화면 →
  • if-need-be (Doodle), 가능/부담의 2층 응답: ‘가능하지만 피하고 싶어요’ 화면 →
  • 캘린더가 대신 답함 (Calendly), 가용성을 사람에게 묻지 않기: 캘린더의 빈칸만 자동으로 화면 →
  • 단일 확정 (Calendly), 후보 나열 대신 하나를 강하게 미는 추천 화면 →

실패 패턴, 피한 것

  • 응답 노후화, 받아둔 가용성은 썩는다: 변동 가능성 수집·재확인으로 대응 화면 →
  • 무응답 방치, 투표만 걷고 끝: 기한 관리·에스컬레이션·강제 판단으로 화면 →
  • 그리드 피로 (When2meet), 전원 풀그리드 강요: 제안 칩 + 선택적 그리드 화면 →
  • 전원 합의 신화 (Doodle), 다수결 ≠ 성립: 역할·정족수 판정으로 대체 화면 →