RUDA DIRECTOR / BEFORE & AFTER · PATTERN 015
기능이 많아 보이면 보통 덜어내는 일부터 시작합니다. 카드 수를 줄이고 설명을 합치고 메뉴를 숨깁니다. 그런데 화면은 짧아졌는데도 제품이 무엇을 해결하는지 더 선명해지지 않을 때가 있습니다.
문제는 기능의 개수가 아니라 관계가 보이지 않는 데 있을 수 있습니다. 차례대로 써야 하는 단계, 먼저 갖춰야 하는 조건, 둘 중 하나를 고르는 선택지, 다른 사람이 맡는 일이 모두 같은 모양으로 나열되면 독자는 그것을 서로 경쟁하는 기능으로 읽습니다.
아래 상황은 여러 관찰에서 공통 구조만 추려 만든 합성 예시이며, 실제 고객사나 실제 성과를 뜻하지 않습니다.
BEFORE — 모든 기능을 같은 카드로 보여준다
한 업무용 소프트웨어가 있다고 가정해 보겠습니다. 첫 화면에는 자료 가져오기, 정리, 검토, 승인, 전달, 기록 기능이 같은 크기의 카드로 놓여 있습니다. 팀은 카드가 많아 복잡해 보인다고 판단하고, 비슷한 이름을 합쳐 세 개의 큰 기능으로 줄입니다.
기능 수는 줄었지만 구매자는 여전히 묻습니다. 어디서 시작해야 하는가. 검토 전에 무엇이 준비돼야 하는가. 승인과 전달은 누가 맡는가. 일부 단계만 써도 되는가. 화면은 단순해졌지만 판단은 단순해지지 않았습니다.
DIAGNOSIS — 나열은 관계를 선택지로 바꾼다
같은 모양의 카드는 “이 중 무엇이 더 중요한가”라는 비교를 만듭니다. 그러나 실제 제품 안에서 기능은 늘 경쟁하지 않습니다. 하나의 일을 완성하는 순서일 수도 있고, 다음 단계가 작동하기 위한 전제일 수도 있습니다. 조직 안에서 담당자가 바뀌는 지점일 수도 있습니다.
이 관계를 지운 채 기능을 합치면 구매 판단에 필요한 정보까지 사라집니다. 사용자는 기능 이름보다 자신의 일이 어디서 시작해 누구에게 넘어가고 무엇으로 끝나는지 알고 싶습니다. 제품이 그 흐름을 끝까지 책임지는지, 중간에 다른 도구나 사람이 필요한지도 확인해야 합니다.
VISUAL EVIDENCE — 기능은 어떤 관계로 연결되는가
| 관계 유형 | 구매자가 확인할 질문 | 적합한 표현 | 같은 카드로 놓을 때 생기는 오해 |
|---|---|---|---|
| 순서 | 무엇부터 시작하고 다음은 무엇인가 | 방향이 있는 작업 흐름 | 각 기능을 따로 선택해야 한다고 느낌 |
| 의존성 | 다음 단계 전에 무엇이 필요한가 | 전제와 결과를 연결한 계층 | 필수 조건을 부가 기능으로 오해 |
| 대안 | 내 상황에는 어느 경로가 맞는가 | 공통 비교축이 있는 선택표 | 차이를 설명하지 못한 채 선택지만 늘어남 |
| 선택 확장 | 기본 흐름 뒤에 무엇을 더할 수 있는가 | 핵심 흐름과 분리한 보조 영역 | 처음부터 모두 배워야 한다고 느낌 |
| 책임 전환 | 어느 단계에서 담당자가 바뀌는가 | 역할별 구간과 인계 지점 | 제품이 끝까지 자동 처리한다고 오해 |
DECISION — 삭제하기 전에 관계부터 분류한다
- 구매자가 끝내려는 일을 한 문장으로 정합니다. 기능 이름이 아니라 시작 상태와 완료 상태를 적습니다.
- 각 기능의 관계를 표시합니다. 순서, 의존성, 대안, 선택 확장, 책임 전환 가운데 무엇인지 구분합니다.
- 관계에 맞는 시각 문법을 선택합니다. 순서는 흐름으로, 대안은 비교표로, 전제는 계층으로, 책임은 인계 지점으로 보여줍니다.
- 그다음에만 줄이거나 합칩니다. 같은 일을 반복하는 요소는 합치되, 판단에 필요한 단계와 경계는 남깁니다.
AFTER — 기능 목록을 하나의 일로 다시 읽히게 한다
| 비교축 | BEFORE | AFTER |
|---|---|---|
| 첫 질문 | 어떤 기능이 있는가 | 어떤 일을 어디까지 끝낼 수 있는가 |
| 정보 구조 | 동일한 카드의 나열 | 시작→준비→판단→인계→확인의 흐름 |
| 우선순위 | 모든 기능이 같은 무게 | 핵심 단계, 전제, 선택 확장을 분리 |
| 역할 | 누가 무엇을 맡는지 불분명 | 사람과 제품의 책임 경계를 표시 |
| 범위 | 기능 수로 제품의 크기를 설명 | 완료 가능한 작업 범위로 설명 |
| 수정 기준 | 많아 보이면 삭제 | 관계를 해치지 않는 중복만 제거 |
합성 상황의 수정안에서는 여섯 기능을 세 이름으로 뭉치지 않습니다. 자료가 들어와 정리되고, 검토와 승인을 거쳐 전달되며, 마지막에 기록이 남는 흐름을 먼저 보여줍니다. 선택 기능은 핵심 흐름 뒤로 보내고, 사람이 확인해야 하는 지점은 따로 표시합니다. 구매자는 기능을 세지 않고 자신의 일이 끝까지 이어지는지 판단할 수 있습니다.
WHEN NOT TO APPLY — 흐름으로 묶으면 오히려 틀리는 경우
- 서로 독립적으로 구매하는 제품군이라면 억지로 하나의 흐름에 넣지 않습니다.
- 사용자 목적이 처음부터 다른 경로라면 순서가 아니라 선택 기준을 먼저 보여줘야 합니다.
- 기능 관계가 아직 검증되지 않았을 때는 완성된 흐름처럼 단정하지 말고 가설과 미확인 지점을 표시합니다.
- 실제로 중복되거나 쓰이지 않는 기능까지 흐름이라는 이유로 보존해서는 안 됩니다. 관계 분류는 삭제를 막는 규칙이 아니라 올바른 삭제를 위한 전제입니다.
DECISION RULE
기능 수를 줄이기 전에 기능 사이의 관계를 분류한다. 순서는 흐름으로, 의존성은 계층으로, 대안은 비교로, 책임 전환은 경계로 보여준 뒤에도 남는 중복만 제거한다.
좋은 단순화는 정보를 감추지 않습니다. 사용자가 자신의 일이 어떻게 끝나는지 더 적은 추측으로 이해하게 만듭니다.