디스크립션 | 회사에서 규칙을 합의하세요. | 디스크립션의 이해

디스크립션 작성 방식 회사마다 다르다. 그래서 더욱 문제이다.
즉, 일관성이 없다. 
각 각 회사마다 다르게 작성해서 문제다.

회사에서 디스크립션 가이드 회의나 디스크립션 기술 정책 정의를 하고 있는가?

현재 작성하고 있는 디스크립션이 합의되지 않은 채 작성되고 있다.

회사는 다르지만 중요한 건 무엇을 정의해야 하는가?에 대한 "공통의 기준"을 세우는 것이 필요하다.

"화면에서 보이지 않는 '행동'을 누가, 어떻게, 언제 수행하는가?"

이 기준이 디스크립션의 핵심이다. 무엇을 정의해야하는가?에 대한 팀 구성원의 합의가 필요하다.

반응형

 

디스크립션의 이해

1. 디스크립션에는 "규칙"이 필요하다.

세상은 규칙 없이 설명되지 않는다.

기획자의 논리가 깨지면 손(디자이너)과 발(개발자)은 제각각 움직이게 된다.

 

기획자는 "정의하는 사람" 이다.

 

● 정의란?

정확한 기준과 움직임을 잡아주는 일이다.

그리고 그 시작은 바로 디스크립션의 규칙있는 작성이다.

 

2. 플랫폼 설계, 프론트 중심 사고를 넘어서야 한다.

기획자라면 화면을 설계할 떄 "보이는 것"만 생각하기 쉽다.

트러블의 핵심: 디스크립션 소통의 간극

바로 기획자와 개발자 간의 디스크립션 소통이다.

 

기획자는 프로트 화면 구조를 보며 설계해야 한다.

더 잘하면 관리자 화면 구조까지 고려한다.

 

하지만 중요한 한가지,

DB에 대한 정의는 기획자 입장에서는 다가가기 어렵다.

 

● 개발자에게 중요한 건 ERD/DRD

개발자는 데이터가 어떻게 흘러가는지,

즉 ERD(Entity Relationship Diagram)나 DRD(Data Relation Diagram)를 기준으로 사고한다.

화면 속에서 데이터를 찾는다.

 

● 기획자가 ERD없이 화면을 설계하면 어떻게 될까?

→ 결국 존재하지 않는 데이터를 기반으로 기능을 설계

→ 리뉴얼 프로젝트에서는 화면을 통째로 다시 그려야 하는 사태가 발생한다.

 

따라서 기획자는 ERD/DRD를 적극적으로 요청하고, 이해하려는 노력이 필요하다.

 

● 그럼 디자인은 어떨까?

디자이너도 단순히 예쁜 그림을 그리는 사람이 아니다.

디자인은 UI/UX 관점에서 끊임없이 고민한다.

 

디자이너는 기획서에서 드러나는 다음 포인트에서 민감하게 반응한다.

✔️ 핵심가치 (이 기능이 왜 중요한가?)

✔️ 사용자 관점에서의 흐름

✔️ 기능과 맥락과 배치

 

일부 기획자들은 '기능 정의' 중심으로만 사고하고, 컨셉이나 감성적 요소를 등한시 하는 경우가 있다.

이럴 경우 디자이너는 '이걸 왜 이렇게 만들었지?' 라는 감정을 가지게 되고,

키 비주얼이 틀어지면 전체 컨셉과 흐름을 다시 잡아야 하는 재작업이 발생한다.

 

결국 중요한 건 "공감과 명확한 주문"

기획자는 프로젝트에서 주문하는 사람이다.

그렇다면 상대가 "당신이 무엇을 주문했는지" 제대로 이해해야 한다.

 

개발자에게는:

▶ 어떤 데이터(관리자 경로)가 필요하고, 어떻게 흘러가야 하는 지 명확히

 

디자이너에게는

▶ 기능의 핵심 가치와 사용자의 시나리오 맥락 까지 공유되도록

 

특히 디자인은 감각적, 정서적 영역에 민감하기 때문에, 

키 비주얼 하나 어긋나면 전체 흐림이 흔들릴 수 있다.

그래서 초기 커뮤니케이션이 정말 중요하다.

 

● 직무 별 디스크립션을 바라보는 관점

역할	주요 포인트	기획자가 고려해야 할 점
기획자	기능 정의, 화면 구조	ERD/DRD 기반의 구조적 사고
개발자	DB 구조, 데이터 흐름	DB 정의, 데이터 존재 유무
디자이너	컨셉, 감성, UI/UX 흐름	기능의 맥락과 핵심 가치 전달
퍼블리셔	UI 구현, 구조화된 마크	구조화된 설계와 명확한 기준 제공

 

기획은 혼자 만드는 것이 아니라,

함께 이해하는 작업이다.

 

좋은 기획자는 보이는 것만 정의하지 않고, 데이터, 구조, 인간의 감성까지 함께 사고하는 직관이 뛰어난 사람이다.

 

3. 글밥 너무 많이? 너무 적게? NO

● 눈 감고도 이해되는 디스크립션이 진짜다.

"듣기만 해도 그려지는 설명"이다.

눈을 감고도 "아, 이런 흐름이구나!" 하고 상상이 되어야 한다.

 

그래서 양보다 중요한 건 "흐름"이다.

좋은 디스크립션은 순차적인 흐림이 있다.

기획서가 논리적 흐름없이 기능만 나열되어 있다면, 개발자나 디자이너는 "이게 어디에서, 왜 필요한지" 계속 되물을 수 밖에 없다.

 

그럼 어떤 흐름으로 설명해야 할까?

 

좋은 디스크립션의 흐름 : 3단 구성

1. 행동(Action)의 출발점이 어딘지 명확하게

- 사용자가 어떤 버튼을 클릭하거나, 어떤 조건에 따라 자동 노출되는지

ex) 로그인한 사용자가 메인 페이지에 진입했을 때

 

2. 어디로 이동(또는 변화)하는 지 알려주기

- 해당 액션 이후 어떤 화면으로 이동하거나, 어떤 모듈이 호출되는지

ex) 메인 배너를 클릭하면 이벤트 상세페이지로 이동

 

3. 그 화면에서 무엇이 펼쳐지는지 구체적으로

- 이동한 화면에서 어떤 콘텐츠가 어떤 기준으로 노출되는지

ex) 이벤트 상세 페이지에서는 등록된 이벤트 제목, 기간, 설명, 이미지가 카드 형태로 노출

 

● 흐름 있는 디스크립션 VS 단편적인 디스크립션

✔️ 단편적인 디스크립션 (단순 기능만 나열)

      "배너 클릭 시 이벤트 페이지 이동"

 

✔️흐름 있는 디스크립션 (사용자의 행동 → 시스템 반응 → 결과 화면)

     "로그인한 사용자가 메인 화면에서 상단 배너 클릭시, 해당 배너의 이벤트 상세 페이지로 이동한다.

     이동된 페이지에는 이벤트 제목, 내용, 기간, 참여 버튼이 카드 형태로 노출된다"