▶ 직접 해보기

모두가 되는 시간은 없어요.
그래도 ‘되는 회의’는 있어요.

번거로운 일정 조율,
목적에 맞춰 !

빈 시간을 찾지 않아요. 이 시간에 회의가 열릴 수 있는지 판단하고, 근거와 함께 1순위를 추천해요.

프로토타입 직접 해보기추천이 바뀌는 장면 먼저 보기 →

기획 · 제품 설계 · UX 라이팅 · 프로토타이핑
신한영 · 2026

01문제 정의

캘린더가 비어 있어도
모두가 가능한 것은 아니에요

문제는 빈 시간이 아니라, 그 시간을 믿고 확정할 수 없다는 데 있었어요.

캘린더가 비어 있어도 그게 진짜 되는 시간이라는 보장은 없어요.
→ 미응답. 결국 누군가 흩어진 답을 모으고 대조해요.
진짜 마찰은 빈 시간 찾기가 아니라, 오래된 일정을 다시 확인하고 흩어진 답을 모으는 데 있었어요. 그 과정엔 어려운 이유까지 설명해야 하는 부담도 따랐어요.
설계 과제

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

같은 회사 동료 6명이 다음 주까지 1시간 동안 모여야 해요. 점심 직후를 피하고 싶은 사람도 있고, 특정 요일에 외근이 많은 사람도 있어요. 꼭 함께해야 하는 사람과 결과만 공유받아도 되는 사람도 달라요.

인원 6명회의 60분피하고 싶은 시간 있음
02설계 원칙

모두가 만족하는 시간은
예외에 가까워요

6명 모두가 만족하는 시간은 거의 없어요. 그래서 모두의 만족을 똑같이 계산하기보다, 회의가 열리는 조건과 각자의 부담을 나누어 반영했어요. 딱은 가벼운 소규모 회의가 아니라, 꼭 함께해야 하는 사람이 있고 조율 실패 비용이 큰 다인원 회의를 먼저 해결해요.

원칙 01

사람 대신
조건을 보여줘요

“누가 안 된다” 대신 어떤 조건이 맞지 않는지를 보여줘, 특정 사람이 반대한 사람으로 남지 않게 했어요.

원칙 02

답하기 쉽게
선택지만 남겼어요

“언제 되세요?”라는 열린 질문 대신 가능한지, 피하고 싶은지, 확인이 필요한지만 고르게 했어요. 복잡한 조건은 주최자 한 명이 설정하고, 참석자에게는 가입 없는 짧은 응답만 남겼어요.

원칙 03

나열하는 대신
추천해요

후보를 늘어놓으면 사용자가 다시 비교해야 해요. 회의가 열리는 조건을 통과한 후보 중 하나를 근거와 함께 먼저 추천했어요.

03핵심 모델

회의 목적에 따라
필요한 사람이 달라져요

사람의 중요도가 아니라, 이번 회의에 필요한 참여 방식을 구분했어요. 회의 목적에 따라 꼭 함께할 사람을 정하고, 정해진 시간에 다룰 수 있는 만큼만 결과를 고르게 했어요.

김민수 이지현 박서윤 정다은 최준호 한유진
꼭 함께해야 해요
김민수 · 이지현
이 사람이 가능한 시간이어야 회의가 열려요.
불가능 → 후보에서 제외
가능하면 함께해요
박서윤 · 정다은
참석하면 회의 결과가 더 좋아져요.
불가능 → 추천 등급 하락
회의 결과만 받아요
최준호 · 한유진
참석 여부와 상관없이 회의 결과를 받아요.
시간 계산에서 제외
회의가 열리는 최소 조건
꼭 함께해야 하는 사람이 모두 가능하고, 약속한 최소 인원이 모이면 회의가 열려요.
회의가 열릴 수 있는지 판단하는 규칙
  1. 꼭 함께해야 하는 사람이 어려운 시간은 후보에서 제외해요.
  2. 누가 안 된다고 말하지 않고, 어떤 조건이 맞지 않는지를 보여줘요.
판단 기준 자세히 보기 (전체 5개)
  1. ① 꼭 함께해야 하는 사람이 어려운 시간은 후보에서 제외해요.
  2. ② 약속한 최소 인원이 모일 수 있어야 해요.
  3. ③ 피하고 싶은 응답은 가능한 시간끼리 비교할 때만 반영해요. 불가와 부담을 섞지 않아요.
  4. ④ 확실하지 않으면 ‘가장 추천’ 대신 ‘현재 가장 유력’이라고 알려줘요. 추측하지 않아요. 모르면 모른다고 해요.
  5. ⑤ 누가 안 된다고 말하지 않고, 어떤 조건이 맞지 않는지를 보여줘요. 사람 사이에 서운함이 남지 않게요.
이 규칙이 만든 화면의 태도 후보를 나열하지 않고 하나를 먼저 추천한다 · 질문 하나씩 물어 조건을 쌓는다 · 참석자 화면에는 역할을 드러내지 않는다

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

04직접 사용하기

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

한 화면에서는 하나의 질문만 보여줘요. 주최자와 참석자 흐름을 전환해보고, 여러 조건을 바꿔보며 1순위와 추천 근거가 어떻게 달라지는지 확인할 수 있어요.

직접 따라가 보기

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

흐름
시안
9:41
파란 선택지를 눌러 직접 진행해보세요
Interactive prototype by 신한영
이 화면에서 내린 결정

색 시안 3종 (참고용) · 클릭해서 펼치기 ▾
블루
오션
민트
05서비스 흐름

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

가장 자주 지나는 여섯 장면을 먼저 보여줘요. 이 제품의 핵심은 조건 설정 → 응답 → 성립 판정 → 1순위 추천 → 확정이에요. 이후 기능은 이 흐름을 더 안정적으로 만드는 확장이에요.

01 · 인트로
▶ 여기서 조작하기
02 · 회의 목적 입력
▶ 여기서 조작하기
03 · 꼭 함께해야 하는 사람 지정
▶ 여기서 조작하기
04 · 참석자 응답
▶ 여기서 조작하기
05 · 1순위 추천
▶ 여기서 조작하기
06 · 확정 알림
▶ 여기서 조작하기
확정 이후에도 회의 결과까지 이어져요

처음 정한 회의 목적에 맞춰 결과를 남기고, 이번 역할과 조건은 다음 회의에서 다시 활용할 수 있어요.

추천이 흔들릴 때 이렇게 대응해요
  1. 01꼭 함께해야 하는 사람이 어려워졌을 때해당 시간을 후보에서 제외하고 다시 추천해요
  2. 02아직 응답이 남았을 때실패로 단정하지 않고 ‘응답 대기’로 구분해요
  3. 03확정 후 참석이 어려워졌을 때조건을 다시 확인해 기존 시간 유지 또는 재조율을 제안해요
전체 화면 보기 →

전체 화면에는 최초 생성 흐름뿐 아니라 응답, 확정 이후 변경과 예외 상황까지 포함돼요.

입력 정리 추천 확정
주최자 흐름Organizer
조건 비교 · 확정 후 변경 요청설명용 비교

확정 후 참석자 한 명이 다른 시간을 요청한 상황이에요. 기존 시간과 요청된 시간, 다음 후보를 같은 기준으로 비교해요.

기존 시간 · 시스템 추천목요일 10:00꼭 함께해야 하는 사람2/2 충족전체 응답5/6 가능변동 가능성낮음기존 시간 유지 가능
요청된 시간수요일 16:00꼭 함께해야 하는 사람2/2 충족전체 응답5/6 가능변동 가능성보통변경 요청 반영 가능
다음 후보금요일 14:00꼭 함께해야 하는 사람1/2 미충족전체 응답5/6 가능변동 가능성높음꼭 함께 조건 미충족으로 추천 어려움
참석자 흐름Attendee
← 가로로 스크롤 · 각 화면을 클릭하면 아래 프로토타입에서 그 지점부터 조작돼요 → · 본 흐름 아랫줄의 점선 카드는 그 화면에서 갈라지는 분기예요.
06설계 근거

기존 도구에서 배운 것과
다르게 설계한 것

기존 일정 조율 도구를 비교해 효과적인 방식과 반복되는 문제를 구분했어요. 가입 없는 응답과 단일 추천 방식은 참고하고, 오래된 응답과 무응답이 방치되는 문제는 별도의 흐름으로 보완했어요.

기존 도구에서 배운 방식딱에서 확장한 방식
가입 없이 빠르게 응답

가입 없이 이름만 입력해 바로 답할 수 있어요.

When2meet에서 참고
빠른 응답이 확정으로 이어지게 했어요

응답이 없으면 다시 확인하고, 남은 응답 상태를 구분해 보여줘요.

화면 →
가능과 부담을 나누어 응답

단순한 가능 여부뿐 아니라 피하고 싶은 시간도 구분해요.

Doodle에서 참고
그 응답에 유효기간을 뒀어요

한 달 안에 잡히는 회의에는 자동 반영하고, 그 뒤에는 같은지 다시 확인해 오래된 선호가 남지 않게 했어요.

캘린더로 빈 시간 확인

비어 있는 시간을 자동으로 후보에 반영해요.

Calendly에서 참고
캘린더 없이도 답할 수 있게 했어요

제안받은 시간에 먼저 답하고, 다른 가능한 시간은 필요할 때만 추가해요.

화면 →
하나의 시간을 먼저 추천

여러 후보를 나열하기보다 근거 있는 1순위를 보여줘요.

Calendly에서 참고
그 추천에 회의 성립 근거를 붙였어요

꼭 함께해야 하는 사람과 최소 인원을 기준으로 판단해요.

화면 →
가장 크게 다르게 본 점

모두가 가능한 시간을 찾기보다, 회의가 열리는 데 필요한 사람과 최소 인원을 먼저 확인했어요.

화면 →
07회고

결정한 것과
아직 확인해야 할 것

결정 3가지 · 핵심 위험 3가지 · 예외 조건 10가지 점검

결정에 필요한 것만 남겼어요

01가장 큰 결정하나를 먼저 추천했어요

조건을 충족한 1순위를 근거와 함께 보여줘 비교 부담을 줄였어요.

02역할을 드러내지 않았어요

사람에 대한 평가처럼 보이지 않도록 참석자는 같은 중립 화면을 봐요.

03비교 가능한 응답만 받았어요

구체적인 사정 대신 가능 여부와 부담만 받아 후보를 비교해요.

아직 확인해야 할 설계 위험

01가장 큰 설계 위험1순위 추천이 판단을 고정하지 않을까요?

하나를 먼저 추천하면 비교 부담은 줄지만, 추천을 정답처럼 받아들일 수 있어요.

02역할 구분이 사람에 대한 평가로 느껴지지 않을까요?

회의에 필요한 참여 방식을 구분했지만, 사용자는 이를 사람의 중요도를 평가하는 것으로 받아들일 수 있어요.

03개인 응답을 보호하면서 충분한 근거를 줄 수 있을까요?

개인 사정을 공개하지 않으면 관계 부담은 줄지만, 추천 이유가 불투명하게 느껴질 수 있어요.

열 가지 예외 조건으로 추천 로직을 점검했어요

실제 사용자 검증에 앞서 열 가지 예외 상황으로 추천·대기·제외·확정의 경계를 확인했어요. 사용성을 입증하는 테스트가 아니라, 로직의 모순과 누락을 찾기 위한 사전 점검이에요. 아래는 바로잡은 대표 사례예요.

아직 응답하지 않은 사람이 있다면
발견한 문제남은 응답으로 채워질 수 있는 후보까지, 충족 불가능과 똑같이 제외될 수 있었어요
반영한 수정최소 인원 충족 · 응답 대기 · 충족 불가능으로 나눠 안내했어요

다음 사용자 검증

사용자가 추천 이유를 이해하는지, 역할 구분을 평가처럼 느끼지 않는지, 실제 결정 시간이 줄어드는지 확인할 예정이에요.

사람을 탓하지 않고,
회의 시간을 정할 수 있게 설계했어요.

신한영 · Product Design / UX Writing / Prototype