Case 01 — Medical Platform
Medistaff
민감도 높은 의료 도메인에서 권한·예외·운영 제약을 구조로 풀어낸 커머스와 운영 어드민을 0에서 설계했습니다.
MedistaffChapter 01
커머스 · 어드민
In this chapter
Contents
Medistaff — Chapter 01Phase 2
열고 나서 손볼 일은 대부분 결제 뒤에 몰려 있었습니다
앱 안 웹뷰에 커머스를 얹은 구조에서, Phase 1 이후 드러난 결제 뒤 예외와 상태를 한 흐름으로 재구성했습니다. 뒤로가기 이탈, 시간 기준 주문 상태, 복수 품목 환불, 각인 옵션의 갈래를 함께 정리했습니다.
웹뷰 이탈 방지
앱 안 웹뷰에서 뒤로가기가 곧 서비스 종료로 이어지던 구조를, 이탈 직전 확인 얼럿과 앱 메인 복귀 경로로 다시 설계했습니다.
배송 상태 정합성
결제 완료 시간 기준 익일 11시 이전은 주문완료, 이후는 상품준비중으로 갈리고, 주문 취소와 배송지 변경도 같은 시각을 경계로 닫힙니다. 예외와 운영 혼선을 줄이기 위해, 이 기준이 주문 내역·취소 화면·안내 문구에서 같은 말로 읽히게 맞췄습니다.
각인 주문 옵션
의료진 대상 각인 옵션은 단품과 각인 조합, 입력 검증(한글 6자·영문 10자), 토스트, 예외까지 갈래가 많았습니다. 화면을 늘리는 대신 한 바텀시트 안에서 12개 상태를 전환할 수 있게 묶었습니다.
긴 옵션명
긴 의료 제품 모델명에서 가독성과 판독성을 확보하기 위해 2줄 표기 규칙을 뒀습니다.
환불 화면 구조
한 환불 건에 여러 품목이 들어올 수 있어, 영수증 한 장으로 이어 보일지 품목으로 묶을지 검토한 뒤 품목 단위 반복 모듈로 바꿨습니다. 날짜·상태 헤더는 한 번만, 합계는 하단에 고정했습니다.
As-is / To-be 문서
Phase 1 운영에서 드러난 정책과 예외를 화면 단위 As-is/To-be로 정리했습니다. 고친 결과보다 고친 이유가 팀 안에 남는 것이 목적이었습니다.
Medistaff — Chapter 01구매 여정
다음에 할 수 있는 일이 다르면 화면도 달라야 합니다
결제 실패는 재시도 가능하고, 재고 부족은 재시도 불가입니다. 배송지가 저장된 고객에게는 입력 대신 확인만 남겼고, 주문이 끝난 뒤에도 배송지를 바꿀 구간을 열어 뒀습니다. 저장된 정보는 검증만 하면 되고, 사후 수정 구간은 운영 예외를 받기 위한 장치입니다.
Order
주문서
배송지 · 요청사항 · 세금계산서를 한 화면에서 받습니다. 저장된 배송지가 있으면 첫 화면이 달라집니다.
Payment
결제
PG 결제창이 웹뷰 위에 떠서, 닫기 버튼이 어디인지부터 보이게 했습니다.
Complete
주문 완료 · 내역
끝난 뒤에도 익일 11시 전까지 배송지를 바꿀 구간을 열어 뒀습니다. 그 안에서 도서산간·제주로 바꾸는 경우는 배송비가 달라져 고객사 이메일로 넘깁니다. 세금계산서는 발급 여부로 갈립니다.
Medistaff — Chapter 01정책과 예외
예외는 뒤에 붙이지 않고 순서 안에 넣습니다
주문서는 한 장이지만, 그 한 장 안에서 갈라야 하는 경우가 계속 나왔습니다. 기능을 더한 게 아니라 갈릴 지점을 먼저 찾는 일이었습니다.
주문서에서 갈린 경우를 모아 보면 지역, 사업자 여부, 이탈 시점 세 가지였습니다. 셋 다 사용자가 뭘 잘못해서 생긴 게 아니라 원래 다른 상황인데 화면이 같았던 것입니다. 그래서 상품군이 늘어도 갈릴 자리가 같은 곳에 붙습니다.
도서산간 · 제주
주소를 넣는 순간 배송비와 안내가 달라집니다. 결제 금액이 바뀐다는 사실을 주소 입력 화면에서 바로 보이게 했습니다.
세금계산서
미발급 · 발급 · 작성 중 세 갈래입니다. 사업자 고객이 섞여 있어 주문이 끝난 뒤에도 발급 경로가 열려 있어야 했습니다.
주문서 이탈
뒤로가기를 누르면 고른 옵션과 수량이 사라지는데 경고가 없었습니다. 확인 팝업을 붙이고 버튼을 「계속 작성하기 / 나가기」로 나눴습니다.
도서산간&제주 지역
세금 계산서 발급
주문서 이탈
Medistaff — Chapter 01취소 · 환불 · 배송
운영자가 직접 바꾸되, 무엇을 바꿨는지는 남깁니다
송장 등록, 부분 환불, 세금계산서 발급은 성격이 다른 운영 책임입니다. 셋 다 운영자가 어드민에서 직접 처리하되 바뀐 기록은 남고, 되돌릴 수 없는 처리에만 확인을 한 번 더 뒀습니다. 확인 버튼 때문이 아니라, 부분 환불 뒤의 주문 상태를 따로 정해 상태 전이의 기준을 고정해야 했기 때문입니다.
일부 품목 환불
한 주문에 여러 품목이 담기면 환불도 품목 단위로 갈라야 했습니다. 부분 환불 뒤의 주문 상태를 따로 정했고, 일부 환불된 주문은 전체 환불로 넘어가지 않습니다.
전체 환불
되돌릴 수 없는 처리라 확인 단계를 한 번 더 뒀습니다. 환불 이력은 주문 상세에 남겼습니다.
주문 상태 변경 이력
누가 언제 어떤 상태로 바꿨는지를 남겼습니다. 상태를 바꾸는 일보다 바꾼 뒤에 설명하는 일이 더 잦았기 때문입니다 — 감사, 재처리, 책임 분리를 위한 기록입니다. 수기 변경은 결제와 관련 없는 상태만, 단계별로 진행 또는 역진행합니다.
배송 처리
송장번호 등록 · 변경과 배송완료를 리스트에서 바로 하게 두고, 여러 건을 한 번에 처리하는 경우(선택 처리 · 택배사 연동 일괄 처리)를 정했습니다. 배송 완료 뒤 7일이 지나면 구매 확정으로 넘어갑니다.
편집 중 이탈
주문과 상품 상세를 고치다 이전을 누르면 저장하지 않은 내용이 사라져서 두 화면에 같은 경고를 붙였습니다.
세금계산서 처리
주문서에서 받은 발급 요청을 처리하는 화면을 따로 뒀습니다. 없으면 요청이 전부 메일로 흘러갑니다.
Medistaff — Chapter 01상품 등록 · 수정 · 판매 중단
상태 하나가 화면 전체의 권한을 정한다
상태 하나가 화면의 권한과 되돌림 가능 여부를 정합니다. 대기 · 판매 중 · 판매 종료 · 판매 취소 — 종료와 취소에서는 되돌아갈 수 없습니다. 되돌리면 이미 산 사람의 주문 내역이 흔들리기 때문입니다. 재고와 가격도 한 덩어리로 보지 않고 운영 단위로 분리합니다.
이미지도 상태를 따른다
이미지도 상태를 따르게 했습니다. 대기에서는 등록, 교체, 삭제가 가능하고 판매 중에는 등록만 가능하며, 판매 종료 후에는 수정할 수 없습니다.
재고를 합치지 않았다
옵션이 있는 상품은 합계만 보여주면 어떤 품목이 비었는지 바로 드러나지 않기 때문에, 총 재고 대신 품목별 재고로 관리한다는 안내를 뒀습니다.
가격을 세 층으로
공급가·소비자가·판매가를 세 층으로 나눠 정산과 노출 기준을 분리했습니다.
주문번호를 품목 단위로
품목 하나마다 주문번호를 뒀습니다. 앞 장의 일부 품목 환불과 부분 배송이 여기서 나옵니다.
반품 조건까지 상품에서 정해진다
반품 조건까지 상품에서 정해집니다. 기본 · 도서산간 · 제주 배송비와 변심 환불 시 고객이 낼 편도 · 왕복 배송비가 상품마다 다릅니다. 무료배송 상품을 변심으로 환불하면 기본 배송비의 배액이 차감됩니다.
Medistaff — Chapter 01 · 확인된 것Findings
정책과 예외가 데이터만으로 유지되지 않아 화면과 Admin 규칙으로 보강했습니다
결과
부가 기능이 예상 밖의 구매 수요를 확인시켰다
첫 협업 상품은 컬러 2종 × 사이즈 8종, 총 16개 옵션 조합의 패션 카테고리였습니다. 다음 달 두 번째 상품은 옵션이 없는 식품이었고, 기존 커머스 구조와 Admin을 뜯지 않고 얹었습니다.
지금은 웹심포지엄 실시간 라이브가 이 커머스를 얹고 있습니다. 다른 제품이 기능을 가져간 뒤에도 상품 수는 그대로였고, 해당 화면 역시 제가 설계했습니다.
사이즈 × 컬러
옵션이 열 개를 넘어가면, 같은 화면이 다른 화면이 된다
개발이 붙인 화면을 테스트했더니 옵션 조합이 늘어날수록 품목 리스트가 길어져 저장 버튼이 화면 밖으로 밀렸고, 저장 시간도 함께 길어졌습니다. 특히 옵션 그룹 3개에 옵션명 10개를 넘긴 테스트 조합에서 문제가 두드러졌습니다.
버튼을 리스트 아래로 내려 저장 플로우가 끝까지 읽히게 했고, 저장 중 딤과 인디케이터로 진행 상태를 보여줬습니다. 빈 화면에서 저장 버튼이 중복 클릭되던 것도 여기서 막았습니다.
판매 이력
지난 주문을 지키는 일은 화면에서 시작됐다
이 커머스는 판매가 끝난 상품의 이력을 따로 보관하지 않습니다. 상품 정보를 고치면 이미 구매를 마친 사람의 주문 내역까지 함께 바뀝니다.
새 데이터를 쌓을 수는 없었지만, 손댈 수 있는 것과 없는 것을 상태로 나눠 지난 주문을 지키는 장치를 만들었습니다. 화면으로 막은 것이라 완전한 답은 아닙니다.
Medistaff — Chapter 01어드민 공통 규칙 제안
회사 단위 운영 기준으로 재구성했습니다
커머스 어드민을 시작점으로 같은 회사의 여러 어드민을 염두에 두고, 메뉴와 세션, 상단바, 화면 폭 같은 공통 요소의 판단 기준을 먼저 정리했습니다.
그 결과 신규 어드민이 추가돼도 매번 구조를 다시 결정하지 않도록 공통 규칙을 제안했습니다. 제안한 메뉴 구조와 화면 폭은 두 주 안에 커머스 어드민에 반영됐고, 이후 어드민도 같은 구조를 기준으로 설계했습니다.
메뉴
아코디언을 없애고 한 단계로
최고 관리자 텍스트와 아코디언 대신, 클릭되지 않는 카테고리 헤더 아래에 바로 이동하는 1뎁스 메뉴를 뒀습니다. 메뉴가 늘어도 깊이는 고정됩니다.
세션
30분 방치면 다시 로그인
탭 사용 중에는 세션을 유지하고, 이탈 후 30분이면 만료되도록 기준을 정했습니다. 상단바에는 접속 시각, 타임존, 계정 정보를 두어 현재 상태를 즉시 확인할 수 있게 했습니다.
화면 폭
고정 1100px을 유동형으로
고정 1100px 대신 유동형 래퍼와 공통 여백 기준을 두어 넓은 화면에서도 공간 낭비 없이 쓰도록 했고, 편집 중 이탈 경고, 리스트 페이징, 모달에도 같은 레이아웃 기준을 적용했습니다.
Medistaff — Chapter 01파트너스 광고 · 콘텐츠 통계
광고주가 숫자를 보고 다음 집행을 정할 수 있게, 지표를 기간별로 바꿔 보는 통계 화면을 잡았습니다
파트너스는 외부 기업이 배너 광고와 채널 콘텐츠를 직접 운영하는 B2B 서비스입니다. 광고 성과와 콘텐츠 통계는 유료 플랜 사용자에게 열린 기능으로 나갔습니다.
역할: 화면·상태 = 본인 · 지표 정의 = 기획과 협의(명세 반영 = 기획) · 화면 숫자는 예시 데이터
지표
숫자 셋을 한 줄에
노출 대비 클릭을 누적·금일·이번 주·이번 달로 바꿔 보게 하고, CPM·CPC·CTR을 같은 줄에 두었습니다. 효과 분석은 클릭률 기준으로 진료과목·근무유형·나이·성별·시간·회원유형별 상위 셋을 보여 줍니다.
바꾼 것
점유율 대신 경쟁 배너 수
11월 시안에는 같은 슬롯 광고주별 노출 점유율 파이가 있었습니다. 12월 판에서는 이 파이를 빼고, 일간 그래프에 같은 슬롯에서 집행된 다른 배너 수를 선으로 얹었습니다. '같은 슬롯'이 무엇인지는 설명 모달로 따로 보여 줍니다. 광고주가 다음 집행 판단을 더 잘 할 수 있도록, 어떤 데이터를 줄지 기획과 함께 정하고 화면 구조를 잡았습니다.
콘텐츠 통계
모수를 공개 범위에 맞춰
채널 콘텐츠 통계는 요약·콘텐츠 성과·그룹 세분화 세 탭이고, 기간 선택은 모든 탭에 같이 걸립니다. 비율의 모수는 공개 범위별 일간 이용자입니다. 전체 공개면 의사와 의대생, 의사만 공개면 의사입니다. 본문에 넣은 연락처·이메일·URL 클릭은 아웃링크 전환으로 따로 셉니다. 무엇을 어떻게 셀지는 기획과 함께 정했고, 저는 세 탭의 화면과 상태를 잡았습니다.
MedistaffChapter 02
웹 버전 신규 제작
왼쪽 — 앱 퍼스트 시절의 가입 · 인증 화면 · 오른쪽 — 웹 기준으로 거꾸로 교체한 뒤
Medistaff — Chapter 02택한 것과 버린 것
웹을 Upstream으로, 앱을 Downstream으로
신규 기능은 웹에서 먼저 정의하고 앱으로 확장하기로 PO·CTO와 합의했습니다. 앱 하나뿐이던 플랫폼에 웹 버전을 처음부터 만들면서, 둘 중 어느 쪽이 기준이 될지를 먼저 정한 것입니다. 8~9년간 앱 퍼스트로 쌓인 구조는 화면을 더 손대기 어려운 상태였고, 실제 사용자인 의사들은 진료실에서 PC를 쓰는 비중이 높았습니다.
면허 인증을 거친 의료진만 진입하는 폐쇄형 서비스였기 때문에, 웹 로그인은 앱 OTP와 QR로 연계해 보안 정책은 유지하고 진입 마찰은 낮췄습니다.
택한 것
진료실 PC 앞의 개원의를 겨냥한 마케팅·영업 요구를 출발점으로, 웹을 앱의 바리에이션이 아닌 독립 채널로 정의했습니다. 정식 발족 전부터 웹 전용 컴포넌트와 토큰을 선제 구축해 이후 기능 정의의 기준선을 마련했습니다. 공홈 리뉴얼 이후, 8~9년 된 앱의 가입·인증·커리어 화면을 웹 기준으로 역교체했습니다. 신규 웹 확장과 구형 앱 정리를 동시에 해결할 수 있었고, 이후 새 기능은 웹에서 먼저 정의하며 앱 담당 디자이너와의 역할 경계도 이 기준으로 나뉘었습니다.
버린 것
통합검색 자동완성은 화면까지 그렸지만 검색 엔진 쪽 개발 부담이 커서 이번 릴리즈에서 뺐습니다. 공고 탭 필터는 공고 수가 충분히 쌓여야 효용이 생기는 기능이라, 데이터 축적을 출시 조건으로 두고 보류했습니다.
Medistaff — Chapter 02게시판
인증 상태와 게시판 접근 기준을 웹에서 정렬했습니다
앱에만 있던 게시판을 웹으로 세우면서, 인증 상태에 따라 무엇이 열리는지부터 다시 맞췄습니다.
앱에 남아 있던 레거시는 웹에서 현재 디자인 시스템 기준으로 재정렬했습니다.
접근
인증센터를 게시판 옆에 두고, 인증 단계에 따라 열리는 카테고리를 달리했습니다. 병원 리뷰는 인증을 거쳐야 쓸 수 있고, 봉직의 인증은 병원 리뷰가 조건이 되기도 합니다. 접근 규칙은 기획이 정했고, 저는 그 조건이 화면에서 바로 읽히도록 상태와 문구를 맞췄습니다.
기준
기본 흐름은 앱을 따르되, 모달처럼 웹에서 달라져야 하는 기준은 별도로 맞췄습니다. 이렇게 정리한 웹 기준은 이후 앱 적용의 기준점이 됐습니다.
이름
기획이 정한 닉네임 정책을 기준으로, 이미 쓴 글과 댓글을 단 글에서는 닉네임을 변경할 수 없도록 설정 진입이 비활성으로 보이게 화면을 구성했습니다.
Medistaff — Chapter 02검색 · 홈 · 알림
검색의 첫 진입 밀도와 알림의 복귀 규칙을 맞췄습니다
웹 버전의 홈·통합검색·알림 화면입니다. 규칙은 기획 명세에서 왔고, 화면과 상태는 제가 잡았습니다.
역할: 화면·상태 = 본인 · 추천 검색어 포맷 = 본인 제안(백엔드 확인 · 기획 승인) · 알림 진입 랜딩 규칙 = 본인 제안 · 나머지 규칙 = 기획 명세
검색
첫 진입의 정보 밀도
검색창 진입 시 레이어 팝업으로 열리는 검색 화면입니다. 첫 진입의 정보 밀도가 부족하다고 판단해 추천 검색어 영역을 추가했습니다. 포맷을 정하고 백엔드에 API가 되는지 확인한 뒤, 기획 승인을 받아 반영했습니다.
홈
결과가 없으면 영역을 숨긴다
맞춤 초빙은 진료과·근무유형·관심·지원 이력으로 관련도를 매기고, 결과가 없으면 영역을 보여 주지 않습니다. 의대생에게는 커리어·구인 메뉴를 열지 않고, 승인 전 회원은 메뉴를 비활성으로 둡니다. 명세의 규칙을 상태별 화면으로 옮겼습니다.
알림
들어온 자리를 보여 준다
알림을 누르고 들어오면 해당 미션 위치로 스크롤하고 카드를 잠깐 강조합니다. 다른 기기에서 이미 받은 보상이면 강조 없이 완료 상태로, 서버가 숨긴 항목이면 맨 위 기본 상태로 엽니다. 이 진입 규칙은 제가 제안해 반영됐습니다.
Medistaff — Chapter 02웹 전용 컴포넌트
넓게 잡아두고 좁혀야 앱과 어긋나지 않습니다
데스크톱은 앱과 다른 브레이크포인트와 레이아웃 기준이 필요했습니다. 게시판이나 이력서처럼 정보 밀도가 높은 화면은 모바일 컴포넌트만으로 감당하기 어려워, 앱 기준으로 시작하면 화면이 넓어질수록 컴포넌트를 새로 만들어야 했습니다.
좁히는 쪽은 규칙 하나로 통일할 수 있지만, 늘리는 쪽은 플랫폼 맥락마다 판단이 필요했습니다. 그래서 앱과 웹의 책임 범위도 여기서 정했고, 앱 쪽 화면의 절반은 당시 앱 담당 디자이너와 분담했습니다.
Foundation
토큰과 4단계 반응형 그리드
컬러·타이포·스페이싱을 토큰으로 정의하고, 4단계 브레이크포인트를 설계해 진료실 데스크톱부터 태블릿까지 같은 정보 구조와 경험 기준을 유지했습니다.
Component
도메인별 컴포넌트
Board, MyPage처럼 도메인 단위로 나누고, 웹 전용 컴포넌트 1,138개는 개발 컴포넌트명과 1:1로 맞춰 앱 디자인 시스템 안의 별도 페이지로 정리했습니다.
Interaction
넘기지 않는 화면
길 잃음을 줄이기 위해 넓은 화면에서는 페이지 이동 대신 모달로 탐색 구조를 닫고, 모달 위 모달은 막아 예외를 통제했습니다. 반면 모바일 웹에서는 전체 팝업으로 진입 구조를 다시 열어 작은 화면의 맥락을 유지했습니다.
MedistaffChapter 03
리뷰와 경력 인증 화면 설계
Medistaff — Chapter 03인증 · 리뷰 · 블라인드 정책
병원 정보 출처를 심평원 기준으로 통일하는 매핑 흐름을 설계했고, 인증 후 리뷰 노출로 검증된 후기만 보이도록 했습니다
심평원 병원정보 API, 본인인증 자격득실, 회원 입력 병원명이 충돌하는 경력인증에서, 심평원 기준을 기준선으로 두고 관리자와 회원의 상태 흐름과 문구를 정리해 같은 기준으로 해석되도록 만들었습니다.
인증 완료 전에는 리뷰가 노출되지 않도록 순서와 상태를 묶어 검증되지 않은 정보가 먼저 보이는 리스크를 차단했습니다.
매핑
바꿔도 되는 것과 안 되는 것
자격득실 정보와 회원 입력값이 충돌할 때 관리자와 회원이 같은 기준으로 읽을 수 있도록 상태와 문구를 정리했습니다. 반려 시 사유 필수, 매핑 후 병원명은 심평원 표준명으로 고정, 병원이 아니거나 폐업한 기관은 인증대상아님으로 처리되도록 관리자와 회원 화면의 상태와 문구를 맞췄습니다.
게시
리뷰 상태 넷, 그중 하나는 인증 대기
관리자 승인과 리뷰 게시가 분리되어, 경력인증이 완료되지 않으면 저장 단계에서 차단됩니다. 상태는 검토 중, 검토 완료, 게시됨, 블라인드됨 넷이고, 검토 완료는 승인 후 인증 대기 상태입니다. 계정 연결이 해제된 리뷰는 이름과 ID를 "-"로 남깁니다.
블라인드
내릴 것과 남길 것의 기준을 화면으로
병원 비공개 요청 시, 관리자는 기획·법무 기준으로 판정했고 개인 특정과 범죄 단정 표현은 내렸습니다. 반면 주관적 평가, 욕설 없는 부정적 의견, 평판 사유만 있는 요청은 남겼습니다. 승인과 반려 화면의 안내 문구와 상태 흐름을 일치시켜 같은 기준으로 읽히게 했고, 승인, 반려, 댓글 수정 요청은 각각 다른 후속 조치로 알림을 분기했습니다.
Medistaff — Chapter 03인증 상태와 판정
새 자격이 기존 자격을 끝내는 인증을, 웹에서 다시 잡아 앱으로 옮겼습니다
메디스태프는 면허를 인증해야 들어오는 서비스이고, 의사의 자격은 전문의·군의관·레지던트·봉직의·개원의처럼 계속 바뀝니다. 웹에서도 모든 인증이 됩니다. 저는 웹 버전을 만들며 인증 화면과 상태, 판정 흐름도를 통째로 다시 잡았고, 그 흐름을 앱에 옮겼습니다.
역할: 인증센터 화면·상태·판정 흐름도 = 본인 · 규칙 = 기획 명세 · 웹에서 다시 잡아 앱 이식(앱 원판 = 전임) · 문구 = 화면에서 맞추고 기획에 공유
상태 다섯
지우지 않는 이력
인증은 대기·완료·만료·반려·인증불가 다섯 상태로 나뉩니다. 만료는 기간이 끝난 경우와 새 자격으로 바뀐 경우 둘이고, 인증불가는 화면에 보이지 않습니다. 자격이 만료돼도 이력에서는 지우지 않습니다. 저는 이 상태들이 인증 내역과 신청 화면에서 어떻게 보일지 화면으로 나눴습니다.
막는 범위
병역/근무만
병역/근무 인증이 하나라도 심사 중이면 병역/근무 신청만 막히고, 전문의 인증은 언제든 신청할 수 있습니다. 새 병역/근무 자격이 승인되면 기존 자격은 자동으로 만료되기 때문에, 신청 전에 이를 알리는 확인 창이 뜹니다.
서류 없는 인증
2주 뒤 자동 반려
개원의는 파트너스 계정 연동으로, 봉직의는 승인된 병원 리뷰로 서류 없이 인증됩니다. 2주 안에 연동이나 리뷰 승인이 없으면 자동으로 반려됩니다. 저는 이 분기를 판정 흐름도로 정리하고, 연동 대기·리뷰 없음·기기별 안내 화면을 나눴습니다.
재인증
어디서든 맨 위에
관리자가 특정 회원이나 전체에 재인증을 요청하면, 앱을 다시 켜도, 강제 업데이트 창만 빼면 재인증 창이 맨 위에 뜹니다. 인증번호는 6자리·3분이고 하루 10번까지 받을 수 있습니다.
정지
막히는 곳에 출구를
면허번호가 세 번 맞지 않으면 계정이 일시 정지되고, 소명은 고객센터 메일로 받습니다. 인증 대기와 정지 상태마다 화면과 문구를 맞추고 기획에 공유했습니다.
전문의·변경 제한
전문의는 진료과별로 인증하고, 이미 인증한 과는 다시 고를 수 없습니다. 프로필 변경에는 기간 제한이 있습니다. 저는 웹을 만들며 이 흐름을 다시 잡아 단계마다 화면을 나눴고, 앱에 옮겼습니다.
MedistaffResult
주문 상태 체계 정리와 화면 제작 리드타임 절반 단축
앱에 커머스와 운영 어드민을 정리해 단일 운영 구조를 만든 뒤, 웹을 독립 제품으로 열어 진입 구조를 넓혔습니다.
7종
주문 상태 정의
주문 완료부터 배송, 취소, 환불, 확정까지 상태를 일곱 갈래로 나눴고, 한 주문 안에 여러 품목이 담기면 품목별 상태가 따로 움직이도록 정리했습니다.
1/2
문서 → 화면 초안 리드타임
제가 쓰던 유저 플로우 포맷을 AI가 그대로 따르도록 맞춰, 문서에서 화면 초안까지 걸리는 시간을 절반으로 줄였습니다.
16종
첫 협업 상품 옵션 조합
첫 협업 상품에서 컬러 2종, 사이즈 8종 조합이 생기자 품목 리스트가 길어졌고, 저장 버튼이 화면 밖으로 밀리는 문제가 발생했습니다.
In closing
처음엔 화면만 그렸지만, 커머스·어드민·웹을 차례로 세우는 과정에서 웹과 앱의 방향을 PO·CTO와 함께 정하는 역할까지 맡게 됐습니다.