CASE 02 · PRODUCT DESIGN · HEALTHCARE SaaS
Mind Speak CMS.
내부 관리 화면을,
외부 사용자가 직접
운영하는 SaaS로.
본사·파트너·의료기관이 같은 데이터를 각자의 책임 범위 안에서 운영하도록 설계했습니다. 화면보다 권한과 데이터 경계를 먼저 정의하고, 7개 운영 도메인을 하나의 제품 구조로 연결했습니다.
- ROLE
- Product Designer 1 · 단독
- SCOPE
- 기획 · IA · UX/UI · 디자인 시스템 · AX 구조
- TEAM
- Designer 1 · Developer 1
- PERIOD
- 2025.09–11 · 3개월
01 / WHY
기존 CMS는 데이터를 모았지만,
외부 사용자의 운영은 담지 못했습니다.
회사 모든 제품을 한 화면에 모은 내부 도구에는 장비 사후관리, 외부 파트너 권한, 의료기관 결과 포털이 없었습니다. Mind Speak를 여러 기관에 설치하려면 화면 개편이 아니라 운영 주체를 다시 설계해야 했습니다.
- USER
- 내부 운영자 1종
- STRUCTURE
- 제품별 메뉴
- OPERATION
- 요청 후 전달
- DEVICE
- 현재 상태만 확인
한 명의 내부 운영자가 모든 제품을 다뤘습니다.
제품 메뉴 병렬 · 장비 이력 부재 · 결과 요청 중개
- USER
- 본사 · 파트너 · 의료기관
- STRUCTURE
- 역할 × 도메인
- OPERATION
- 기관 직접 운영
- DEVICE
- 설치부터 교체까지
세 역할이 각자의 범위에서 직접 운영합니다.
3개 권한 · 7개 운영 도메인 · 기관 직접 조회
02 / OPERATING MODEL
화면 전에,
책임선을 그렸습니다.
같은 데이터를 사용해도 본사·파트너·의료기관의 책임은 다릅니다. 저는 메뉴부터 만들지 않고, 역할별 데이터 범위와 수정 가능 여부를 먼저 정의했습니다.
제품 거버넌스 · 전체 센터 · 장비 라이프사이클 · 사업 지표
소관 센터 · 자사 장비 · 도입 상태 · 권한 분배
환자 · 검사 · 결과지 · 일상 운영
기관 정보와 보고서 타입
시리얼·이슈·교체 이력
권한 타입과 기관 매칭
결과지·영상·다운로드
등록·검색·관심 대상
검사·재검·인구 분포
공지·FAQ·사용 가이드
IA 구조 상세 보기 3개 역할 × 7개 운영 도메인
화면 수가 아니라 역할별 책임 범위를 먼저 읽을 수 있도록 1단계 구조만 요약했습니다.
7개 도메인의 전체 데이터 · 권한 · 제품 운영 기준
담당 센터·장비·계정 · 배정된 대상자·검사·통계
소속 센터 · 사용 장비 · 대상자·검사·결과 · 공지·가이드
센터·장비·계정·검사·대상자·통계·자료를 하나의 운영 구조로 연결했습니다.
장비를 등록하는 화면에서,
장비의 생애를 추적하는 시스템으로.
- 기존 한계
- 출고 이후 설치·이슈·교체 맥락이 흩어짐
- 설계 판단
- 시리얼을 중심으로 상태와 사건을 한 이력에 연결
- 1.0등록
시리얼 · MAC · 계약 방식
- 2.0설치
사용 기관 · 활성 상태
- 3.0이슈
오류 로그 · Raw Data
- 4.0교체
교체 기록 · 재활성화
MY PRODUCT DECISION장비 목록을 재고표로 끝내지 않고, 이전 사건과 다음 조치를 연결하는 상세 화면을 중심에 두었습니다. 이 구조가 OBELAB의 첫 장비 단위 사후관리 체계가 됐습니다.
화면을 복제하지 않고,
권한·범위·행동만 분기했습니다.
- 기존 한계
- 모든 사용자가 같은 정보 범위를 전제로 함
- 설계 판단
- 공통 데이터 모델에 역할별 규칙을 적용
| ROLE | CENTER | DEVICE | ACCOUNT | EXAM | PATIENT | STATS | RESOURCES |
|---|---|---|---|---|---|---|---|
| MASTER | 전체 생성·수정 | 전체 이력·교체 | 전체 권한 부여 | 전체 검사 | 전체 대상자 | 전체 통계 | 전체 공지·자료 |
| PARTNER | 담당 센터 | 파트너 장비 | 담당 범위 | 배정 기관 검사 | 담당 기관 대상자 | 담당 범위 통계 | 역할별 공지 |
| ADMIN | 소속 센터 | 사용 장비 상태 | 기관 계정 | 기관 검사·결과 | 기관 대상자 | 기관 통계 | 공지·가이드 |
MY SYSTEM DECISION새 역할은 페이지 한 벌이 아니라 권한 매트릭스의 한 행으로 추가됩니다. 권한 침범과 잘못된 데이터 노출을 허용하지 않는 것을 설계 가드레일로 두었습니다.
결과를 요청하고 기다리던 흐름을,
기관이 직접 찾고 설명하는 흐름으로.
- 기존 한계
- 결과 요청과 전달을 사내 운영팀이 중개
- 설계 판단
- 찾기 → 검토 → 설명 순서로 결과 흐름을 제품화
MY WORKFLOW DECISION대상자와 검사 정보를 먼저 찾고 결과 유형을 고르는 순서로 재배치했습니다. 운영팀의 전달 업무를 의료기관의 직접 운영 흐름으로 바꾼 것이 이 SaaS의 핵심 외부 임팩트입니다.
04 / FROM STRATEGY TO SYSTEM
두 명이 세 달 안에 확장하려면,
화면보다 설계 언어가 먼저 필요했습니다.
Mind Speak SW에서 만든 브랜드·상태 규칙을 재사용하고, CMS에 필요한 운영·분석 컴포넌트를 추가했습니다. 저는 기획부터 IA, UX/UI, 컴포넌트와 LLM용 문서 구조까지 하나의 시스템으로 연결했습니다.
검사 SW와 CMS가 같은 제품군으로 읽히도록 컬러·타입·상태 의미를 이어받았습니다.
권한별 메뉴, 대량 데이터 탐색, 상태 태그와 계정 흐름을 운영 도구용으로 확장했습니다.
사업·운영·임상 데이터를 같은 화면에서 판단할 수 있는 분석 패턴을 정의했습니다.
- 01tokens
color · type · space
- 02components
button · modal · table · status
- 03patterns
role-based view · matrix-driven page
- 04prompts
LLM 화면 생성 가이드
05 / OUTCOME
더 많은 화면이 아니라,
더 독립적인 운영을 만들었습니다.
출시 속도만이 아니라, 누가 어디까지 직접 운영할 수 있게 됐는지로 결과를 정리했습니다.
OBELAB 최초의
외부 사용자 운영 SaaS
권한·데이터·검사 기록
운영 속도 향상
3개월 안에
7개 운영 도메인 설계
환자·검사·결과지·뇌 활성도 영상을 운영팀 중개 없이 조회
시리얼·MAC·이슈 로그·Raw Data·교체 흐름을 장비 단위로 통합
본사·파트너·의료기관의 범위와 협업 기준을 권한 매트릭스로 공유
관리자는 한 화면이 아니라,
책임이 다른 여러 개의 제품입니다.
권한과 데이터 범위가 다른 사용자를 한 CMS에 담으려면 화면보다 먼저 책임선을 설계해야 합니다. 이 프로젝트를 통해 권한 매트릭스와 운영 도메인의 경계가 B2B SaaS의 확장성을 결정한다는 기준을 만들었습니다.