[설계를 해보자] 초보 기획자가 설계서 작성할 때 고려해야 할 5가지

Unsplash @alvarordesign

 

 

 

작년 하반기부터 하던 프로젝트가 3월 종료였는데, 추가 프로젝트를 진행하면서 연장되었다. 프로젝트에 신규 인원이 투입되어서 간단한 프로젝트 킥오프를 진행하면서 설계서 작성할 때 이런 것들 포함해줬으면 좋겠다 하는 것들을 정리해서 공유했다. 그 공유했던 내용들도 블로그에 정리하면 좋을 것 같아서 끄적여본다. 나도 나중에 또 교육을 해야 하는 순간이 온다면 그때 참고하려고.

 

 

유튜브 '전과자' 부산대학교 기계공학부 편(https://www.youtube.com/watch?v=x3BqHpzM5dQ)

 

설계서를 포함한 모든 문서의 기본적인 목적은 바로 커뮤니케이션이다. 특히나 설계서의 경우엔 다양한 사람들이 보기 때문에 명확하면서도 혼선이 적게끔 써줘야 한다.

 

마침 즐겨보는 유튜브의 한 에피소드가 이런 상황을 잘 보여줘서 캡처해왔다. 조립지시서 자체는 상세해보일지 몰라도 상대방이 이해하기에 어려움이 있다면 예상했던 결과와 다른 산출물이 나올 수 있다. 

 

 

 

 

 

 

 

1. 정의

페이지에 대한 정의일수도 있고, 요소에 대한 정의일수도 있고, 기능에 대한 정의일수도 있다. 명칭과 대상의 정의를 적어주면 자의적으로 해석하는 상황을 방지할 수 있다.

 

특히 용어의 경우, 용어 가이드를 별도의 문서로 만들어서 모든 작업자들이 공통의 용어를 사용할 수 있도록 하는게 좋다. 생각보다 작업자간 ① 같은 의미를 서로 다른 용어로 사용하거나 ② 같은 용어로 서로 다른 의미를 사용하는 일이 많다. 먼저 정리해준다면 원하는 설계 의도를 전달하기가 좋다. 

어릴 땐 정확한 용어를 쓰려고 영어 단어 공부하듯이 외우던 시절도 있었지만, 결국 일은 모든게 사람의 문제인 것처럼 작업자간에 조금씩 맞춰가면 된다. (주니어일 땐 배우면서 크는거 아니겠는가)

 

 

개인적인 작업 스타일로는 필요한 부분에 대해서만 정의를 적는 편이긴 하다. 용어 같은 경우에는 용어 문서를 별도로 만들고, 요소들에 대해서는 공통 문서를 만드는 경우가 많아서, 영역 이름 정도면 명명하고 특별한 기능인 경우에는 위에 사진처럼 별도로 작성한다. 그래도 꼭 쓰는 정의가 있다면 페이지에 대한 정의다. 이 페이지의 용도나 목적을 작성해주면 코워커들이 페이지의 요소들을 이해하기도 좋고, 더 좋은 아이디어를 줄 때도 있기 때문이다.

 

 

 

 

2. 제약사항

제약사항은 정말정말 다양해서 뭔가 일원화 할 수는 없지만, 가장 흔히 떠올리는 에러 메시지들은  제약사항에서 발생한다.

 

개인정보 보호법이나 정보통신망 이용촉진 및 정보보호 등과 같은 인터넷 서비스를 제공하는 사업자에게 적용되는 법적 항목들을 검토하고 사용자의 동의를 받아야 하는 경우, 동의를 받자.

 

또, 기타 생각나는 것들을 그냥 두서없이 적어보면 다음과 같다.

 

 

언어(영문, 국문 등), 숫자, 특수기호 사용 여부

대표적으로 아이디와 비밀번호가 이러하다. 아이디의 경우 일반적으로 영문과 숫자 조합으로만 이루어지는데, 다양한 경우가 있으니 패스. 하지만 특수기호의 경우 허용가능한 특수기호를 개발자들과 상의 후 정하고 가면 편리하다. 의외로 개발자들이 다 돼요 하다가 제한하자고 하는 경우가 많은게 바로 특수기호...ㅎ

 

 

글자 길이 제약

극단적인 예를 들자면 011 시절 휴대폰 번호는 01x-xxx-xxxx 형태의 10자리였다. 그래서 DB에서 10자리라고 길이제한을 해뒀는데 추후에 010이 도입되면서 010-xxxx-xxxx 형태가 허용되어야 한다면 DB 컬럼의 속성도 수정해줘야 하고 유효성 체크도 수정해줘야 하는 일이 발생한다. 

 

 

DB에서는 데이터의 유형에 따라서 자료형을 결정하는데 이때 우리는 이 데이터의 값이 128자까 최대치라고 생각했지만 사용자가 128자를 넘게 입력하는 경우가 발생한다면 자료형을 변경해줘야 하는 일이 발생한다.

 

아래 표를 이해하려고 하지 않아도 된다.

https://opentutorials.org/module/3921/23515

 

그렇다면 제일 최대의 변수를 사용하면 되는게 아닌가 싶지만, 메모리의 크기가 다른 것처럼 최대한 적합한 자료형을 써주는 게 좋기 때문에 여타 다른 서비스들을 벤치마킹해보고 우리 서비스에 맞는 글자수로 제한을 해주는 것이 좋다. 

 

우리는 무제한이라고 생각하겠지만 우리가 아는 실제로 많은 입력 항목들은 제한이 있다. 만약 우리 서비스는 무한한게 필요한데요? 라고 싶으면 무한한 느낌의 제한을 해도 되는지 정의를 해주면 된다.

 

 

하물며 개발자가 아니더라도 디자이너나 퍼블리셔들도 이 문자가 최대 100자인 경우엔 이게 100자가 노출되어야 하는지 아니면 1줄만 나오고 말줄임처리되어서 나오면 되는지 정의된 내용에 따라서 작업을 하게 되니 꼭 최소/최대 글자수와 영역 내에서 어떻게 표기되면 되는지 작성해주자.

 

 

 

필수 입력 여부

어떤 양식이 있다면, 여기서 반드시 입려되어야 하는 값을 지정해주자. 이에 따라서 필수 입력 항목이 미입력된 경우 에러 메시지가 어떻게 나오면 될지 정의해주자.

 

 

 

 

중복 여부

아이디 혹은 URL을 입력하는 경우에 많이 쓰는 경우이다. 해당 항목이 중복되어도 되는 항목인지 아닌지 정해주자. 그리고 중복된 경우 어떻게 알려줄지도 고민해 보자.

 

 

불일치

비밀번호를 잘못 입력한 경우 또는 비밀번호를 설정할때 비밀번호 입력과 비밀번호 재확인 입력의 내용이 다른 경우 에러 메시지를 알려줘야 한다.

다만, 로그인 화면에서 비밀번호가 잘못된 경우에는 비밀번호를 잘못 입력했다고 알려주면 '유효한 회원 DB는 존재하고 비밀번호가 잘못됐군'이라고 알려주는 모양새가 될 수 있으니 다음과 같은 안내를 해주는 것이 좋다. '아이디와 비밀번호를 확인해 주세요.'

 

 

기타

추후 상태값에서도 한번 더 말하겠지만, 유효성 검사가 필요한 경우가 있다. 

예를 들여, 로그인을 시도했는데 휴면처리되지 않은 회원이라든지, 이메일의 형식이 올바르게 입력되었는지 등 서비스나 항목에 따라 유효성 검사가 필요한 경우 어떤 유효성을 처리하면 되는지 작성해주자.

 

 

 

 

3. 이벤트

버튼 눌렀을 때 어디로 가야 해요? 라는 질문이 생각보다 많이 나온다. 물론 Description 잘 안보는 작업자가 질문하면 화가 나지만 주니어 건, 시니어 건 의외로 많이 놓치는 부분이라고하면 놀랄려나...? 

 

이벤트 종류는 여러 개가 있다. 클릭, 키패드, 양식 제출, 포커스, 로딩, 클립보드 등등 그런데 다른건 몰라도 무조건 써야 하는게 있다면 바로 클릭!!!! 이게 클릭 요소인지 아닌지, 클릭 요소라면 어떤 결과가 나오는 지 작성해주자. 반드시 화면 이동이 아니더라도 말풍선 같은게 나올 때도 있고, 컨펌 창이 노출될 수도 있으니까.

마우스 오버 했을 때 효과도 이벤트!!

 

 

 

 

4. 데이터

데이터에 관련되어서 정의해줘야 하는 부분은 크게 ① 데이터가 있는 경우의 화면의 구성과 ② 데이터가 없는 경우의 화면 구성, ③ 데이터가 너무 많을 때의 화면 구성 또는 기능이다. 일반적으로 ①은 많이들 하지만, ②을 빼먹는 경우가 많다. ②은 공통으로 정의하거나 ①을 그리기 전에 그려놓고 수정하는 방식으로 작업을 하면 빼먹지 않고 작성할 수 있다. ③의 경우는 페이지네이션이나 로딩 이미지 등을 생각해 볼 수 있다.   

 

 

이 블로그만 해도 전체 29개의 글이 있는데, 메인 화면에는 12개만 노출되고  페이지를 넘겨야 다음 목록을 볼 수 있다. 이처럼 한 목록에 몇개의 항목을 보여줄 것인지 처리하는 것을 페이지네이션이라고 한다. 

 

 

저렇게 목차를 끊을 수 없고 한 페이지에 수많은 데이터를 한 번에 보여줘야 하는 경우, 로딩 이미지를 보여줄 수 있는데  로딩 이미지의 경우, 디자인만 작업하고 로딩에 관한 세부적인 것들은 실제 속도나 네트워크 상태 등을 고려하여 개발자가 정의하는게 더 좋을 수 있다. 

 

 

데이터가 있다면, 다음의 내용들을 정의 해야 한다. 이건 위의 글자 길이 제약과 관련 있는 내용이기도 한데 조금 더 세부적으로 작성해보자면 다음과 같은 것들이 있을 수 있다.  

 

1) 개별 데이터의 길이: 최소/최대 글자수 또는 사이즈 

2) 개별 데이터의 유형: 사진, 동영상, 글자, 코드 등

    - 확장자

3) 개별 데이터의 용량

 

그 외의 것들이 있을 수 있는데 이 부분에 대해서도 서비스의 성격에 따라 정의하면 된다.

 

 

카드 내 제목, 본문, 가격의 글자수가 최대 몇글자인지에 따라 또, 사진의 사이즈에 따라 이렇게 카드가 제멋대로 굴러다닐 수도 있다.

 

특히 이미지! 없을 때 어떻게 노출할 것인가 꼭 빠뜨리지말고 디자인 요청하자.

 

 

 

 

5. 성공/실패

블로그 글을 등록하는데 실패하는 경우는 무엇이 있을까? 

정말 많은 케이스들이 있겠지만 지금 머리 속에 떠오르는 건, 등록 버튼을 누르고 완료되는 중간에 네트워크가 끊긴다거나, 글을 작성하다가 세션이 끊어지거나 두가지 경우인 것 같다.

 

사실 더 많은 실패 케이스가 있을 것이다. 사소하게는 제목이 입력되지 않는 것도 있을 수 있겠지만 이 글에서 말하고 싶은 바는, 성공 케이스를 쓰는 건 많은 사람들이 한다. 하지만 실패 처리에 대한 내용이 필요할 때가 있다. 이에 대해서 정의를 해줘야 할 수도 있고 보안책을 마련해야 할 수도 있다. 이것들도 고민해보자.

 

특히나 블로그처럼 글을 오래 쓰고 있는 경우라면, 티스토리는 에디터에 글을 입력할 때마다 세션을 갱신해줄 수도 있고, 일정 시간 단위로 글을 임시저장 처리하고 있는 등의 보안책을 마련해뒀다.

 

 

아니면 우체국에서 송장을 여러 개 등록하는 경우로 예를 들어보자.

엑셀에서 데이터를 입력하고, 엑셀 파일을 업로드 하여 받는 분 목록을 생성하는 form이다. 이 때, 엑셀파일에 입력된 내용을 데이터로 변환하는 과정에서 데이터 타입이 안맞다거나 유효한 주소가 아니라던가 등의 오류가 발생할 수 있다. 이때 우체국의 경우에는 성공/실패를 별도로 보여주고 이에 대해 사용자가 다시 수행할 수 있게 한다.

 

이렇게 하나하나의 성공/실패의 경우를 보여주는 경우도 있고, 내가 전에 했던 프로젝트에서는 사용자의 상태값을 일괄 변경하는 경우가 있었는데 이 경우에는 1개라도 실패하면 전체 처리 실패하는 경우도 있다. 어떤거가 처리되었고, 어떤게 처리되지 않았는지 사용자가 일일히 찾아야 하는 상황을 만들지 않기 위해서였다.

 

무엇이 바람직하냐..라면, 어떤게 그 서비스의 특성, 그 기능의 사용 상황 등을 고려하여 결정하는 것이 좋다. 

 

 

---

 

(예시) 로그인 화면

로그인 화면의 Description을 쓴다면 이렇게 될 것이다.

1. 아이디 입력창 | Admin(회원)
  - 유저가 사용하는 아이디를 입력하는 영역
  - 입력 가능한 기호: 영어 소문자, 숫자, 특수문자(대시-,언더바_, 마침표.)
  - Placeholder: 아이디를 입력해 주세요.
  - 최소 2글자 및 최대 40자 입력 가능
    ㄴ 40자 초과 시, 입력 불가
    ㄴ 2글자 미만으로 입력 시, [로그인] 버튼 비활성화
  - 입력창 활성화 시, 아이디 입력창에 포커스 활성화 및 다음 동작 수행
    ㄴ PC인 경우 커서 활성화
    ㄴ Mobile인 경우, 영문 키패드 활성화

1.1 삭제 아이콘
  - 아이디 입력창에서 입력값이 1글자 이상 있는 경우, 아이디 입력창 내 우측에 노출
  - 아이콘 선택 시, 아이디 입력창 내 입력된 내용 모두 삭제되고 아이콘 비노출 되며 아이디입력창 내 placeholder 노출

2. 비밀번호 입력창
  - 유저가 비밀번호를 입력하는 영역
  - 입력 가능한 기호: 영어 대소문자, 숫자, 특수문자(키보드에 있는 모든 특수문자)
- Placeholder: 비밀번호를 입력해 주세요. 
- 최소 10글자 및 최대 40자 입력 가능
    ㄴ 40자 초과 시, 입력 불가
    ㄴ 10글자 미만으로 입력 시, [로그인] 버튼 비활성화
  - 입력창 활성화 시, 비밀번호 입력창에 포커스 활성화 및 다음 동작 수행
    ㄴ PC인 경우 커서 활성화
    ㄴ Mobile인 경우, 영문 키패드 활성화
 - 비밀번호 입력 시, *로 표기하여 노출

2.1 삭제 아이콘
  - 비밀번호 입력창에서 입력값이 1글자 이상 있는 경우, 비밀번호 입력창 내 비밀번호 미리보기 아이콘 좌측에 노출
  - 아이콘 선택 시, 비밀번호 입력창 내 입력된 내용 모두 삭제되고 아이콘 비노출 되며 비밀번호 입력창 내 placeholder 노출

2.2 비밀번호 미리보기 아이콘
  - 비밀번호 입력창에서 입력값이 1글자 이상 있는 경우, 비밀번호 입력창 내 삭제 아이콘 우측에 노출
  - 아이콘 선택 시, *로 표시되던 비밀번호가 실제 입력값으로 노출
  - 선택된 아이콘 재선택 시, 실제 입력값으로 노출되던 비밀번호가 * 표시로 노출
  - 삭제 아이콘 선택하여 비밀번호 입력창 내 입력값 없는 경우 비노출

3. [로그인] 버튼
  - 아이디 입력창과 비밀번호 입력창에 입력된 내용을 기반으로 로그인을 시도하는 버튼
  - default: 비활성화 
    ㄴ 아이디 입력창 내 2자 이상, 비밀번호 입력창 내 2자 이상 입력해야만 [로그인] 버튼 활성화 
  - 활성화된 [로그인] 버튼 선택 시, 
    ① 로그인 성공 시, 로그인 성공 처리 후 로그인 이전 화면으로 이동
         ㄴ 비밀번호 변경이 필요한 경우, 비밀번호 변경 화면으로 이동
         ㄴ 휴면 처리 예정인 회원인 경우, 상태값 '활성'으로 변경
    ② ID가 존재하지 않는 경우 알럿 메시지 노출: 아이디 또는 비밀번호를 확인해 주세요.
        ㄴ 알럿 메시지 내 확인 버튼 선택 시, 알럿 메시지 닫히고 아이디 입력창과 비밀번호 입력창에 입력된 내용 그대로 노출
    ③ 비밀번호가 틀린 경우 알럿 메시지 노출: 아이디 또는 비밀번호를 확인해 주세요.
        ㄴ 알럿 메시지 내 확인 버튼 선택 시, 알럿 메시지 닫히고 아이디 입력창과 비밀번호 입력창에 입력된 내용 그대로 노출
 - 비활성화된 [로그인] 버튼 선택 시, 
   ㄴ 아이디를 2자 미만으로 입력한 상태에서 [로그인] 버튼 선택 시, 아이디 미입력 토스트 팝업 노출: 아이디를 입력해 주세요.
   ㄴ 비밀번호를 2자 미만으로 입력한 상태에서 [로그인] 버튼 선택 시, 비밀번호 미입력 토스트 팝업 노출: 비밀번호를 입력해 주세요.
   *** 아이디와 비밀번호 둘다 2자 미만으로 입력한 상태에서 [로그인] 버튼 선택 시, 아이디 미입력 토스트 팝업 노출

 

 

 

 

그 외. 우선 순위

예를 들자면, 네이버 혜택 화면에 있는 목록인데 카드 내 라벨(나는 라벨로 부르지만 누군가는 태그로 부를 수도 있다.) 라벨에 대한 각각의 정의와 복수의 라벨이 노출될 수 있는지가 먼저 정의가 되어야 한다. 그리고 복수의 라벨이  노출된다면 어떤 것부터 노출시킬지를 정의해야 한다.

 

지금 이 화면에서 확인을 해보자면 할인 쿠폰은 보라색 라벨로, 행사는 붉은색 라벨로 표기가 되어 있다. 보라색 라벨과 붉은색 라벨 중 붉은색 라벨이 먼저 노출되는 것을 볼 수 있다.

또한 붉은색 라벨 중에서 '타임세일'과 '사은품증정'은 중 '타임세일'이 먼저 오게끔 되어 있고, '신상위크'와 '라이브특가' 중에서는 '신상위크'가 먼저 오는걸 볼 수 있다.  

 

특정 라벨이 있는 경우에는 여러 개의 라벨을 노출시키지 않는다거나 라벨은 최대 2개까지만 노출된다는 등의 조건을 고려해볼 수 있다.

 

 

물론 이런 라벨의 우선순위는 사소해 보일수도 있겠지만, 우선순위를 정해주면 일관성 있는 UX를 제공할 수 있다.

 

 

 

---

물론 이 외에도 고려해야 할 것들은 있다. 상태값, 공통 문서 내 정의, 맞춤법 등등등등 사소한것부터 정말정말 중요한 것들까지도!!! 하지만 위에 내용들만 먼저 정리하고 연습해도 충분하다. 

 

다시 한 번 말하지만, 완벽하지 않아도 된다. 화면 설계도 커뮤니케이션 문서다. 절대적인건 없고 협업하는 사람들과 커뮤니케이션하면서 보완해 나가면 된다 :)