Programing

좋은 UI 설계서란? UI 설계 알짜만 빼먹기

리커니 2023. 10. 6.
반응형

 이번 포스팅에서는 10년간 개발자로 일해오면서 느낀, 좋은 UI 설계서란 무엇이며 UI 설계에 담겨야 하는 내용들에 대해 알아보는 시간을 갖어보겠습니다. 따로 UI/UX에 대해 공부한 적은 없고, 100% 경험에서 나온 생각이라는 것을 참고 부탁드립니다.

 

 SI 업체에서 일을 하다 보면 짧은 개발 기간 동안에 분석, 설계 부터 개발, 테스트까지 진행을 해야 합니다. 핑계일 순 있겠지만 UI 설계서는 감리 대응용이지 실제 개발에 참고하기는 힘들고 요구사항에 변화하는 내용까지 형상관리 하기는 여간 힘든 작업이 아닙니다.

 

 하지만 말 그대로 UI 설계서는 설계문서 입니다. 건축과 비교하면 '도면' 정도가 되겠네요. 아파트를 짓는데 실제와 다른 도면으로 만든다면 어떻게 될까요? 그리고 짓다가 변경되는 내용을 도면에 적용하지 않는다면 어떻게 될까요? 순살아파트니 뭐니 문제가 되는 지금 처럼 난리가 날 것 입니다.

 

1. 개정 이력 관리, 버전 관리

 최초 작성을 한 시점부터 버전을 관리하여, 무엇이 어떻게 변경되었는지 이력만 봐도 알 수 있도록 작성을 합니다. 그리고 각 화면에서는 작게라도 몇 버전에서 변경된 내용인지 알 수 있도록 버전 정보를 작성합니다. 언제 누가 어떤 내용을 몇 버전에서 변경했는지 관리를 합니다.

 아래 내용은 예시 입니다. 

버전 개정일자 개정 내용 작성자 승인자
1.1 2023-10-06 [메뉴관리] 삭제 버튼 제거, 사용여부 값 변경으로 처리    

 

2. 공통사항 정의

 각 페이지에서 중복적으로 사용되는 그리드, 트리와 같은 컴포넌트에서 공통적으로 처리해야되는 내용을 정리하여 작성합니다. 경험이 많은 개발자라면 사용자 입장에서 UX를 고려하여 개발을 하겠지만, 그렇지 않은 개발자들도 많습니다. 아주 사소한 내용이라도 공통적으로 적용되어야 하는 내용을 작성하도록 합니다.

 

  • 조회 영역의 Input Box 에서 엔터 입력 시 조회 이벤트 동작.
  • 그리드 헤더에 단위가 들어가는 명칭은 단위 추가. 예시) 길이 (cm)
  • 입력 영역에 필수 값(*) 으로 설정되어 있을 때 값을 입력하지 않고 저장 시 알림을 주고 해당 영역으로 Focus.
  • 지도에서 사용되는 모든 객체의 범례를 필수로 표출한다.

각 컴포넌트 별로 정리하면 더 좋습니다.

 

3. 업무 로직과 DB관련 정보

 UseCase Diagram이나 Flow Chart,  CRUD 매트릭스와 같은 문서를 별도로 작성하는 것도 좋지만 개인적으로는 UI설계서에 앞선 문서의 내용이 있는 것이 더 좋다고 생각합니다. 일단 여러 문서를 열고 작업을 하지 않아도 되고, 복잡한 프로세스의 화면들을  여러 개발을 할 경우 어떻게 테스트를 해야하는지도 확인 할 수 있기 때문입니다. 한 화면에 나타내기 보다는 별도의 페이지로 구분하여 업무 프로세스나 화면에서 사용하는 테이블의 ERD를 개발자가 참고할 수 있도록 작성하는 것을 권유 드립니다. 이 부분은 좀 호불호가 있을 수 있겠네요..

 그리드를 사용하는 화면에서는 컬럼 매핑 정보와 사용하는 코드가 있다면 코드 정보도 같이 작성을 하였습니다.

 

4. API와 Front 가 나누어져 있을 경우

 한 개발자가 API와 Front를 다 개발한다면 문제가 적을 수 있겠지만 업무적으로 분리되어 있을 경우 나오는 문제들이 있습니다. 예를들어 맞춰본 경험이 없는 업체에 Front 외주를 줘서 진행을 해야하는 경우 API를 담당하는 개발자는 인터페이스 정의서를 작성하거나 swagger로 의사소통을 할 것 입니다. 아무리 내용을 자세히 작성한다고 해도 어떤 상황에 어떤 API를 요청해야 하는지 명확하지 않을 수 있습니다. 이럴 경우에는 swagger에 API ID를 작성하고, 화면정의서 설명에도 해당 ID를 추가하여 어떤 상황에 어떤 API를 사용하는지 명시합니다.

 - 로그인 페이지 연결 시 RSA public key 요청

     - public key로 패스워드를 암호화 하여 전송 [OS-998-01]

 

(FM 이면 GET Method가 맞습니다..내부적인 내용이니 패스..)

 

이렇게 하면 화면정의서만 보고도 어떤 API를 요청해야 하는지 명확하게 알 수 있습니다.

 

지금까지 제가 경험하면서 느낀 좋은 UI 정의서에 대해 알아보았습니다. 실제 구현된 화면과 똑같아야 하고, 설명이 자세해야 하고와 같은 당연한 얘기는 제외하였습니다. 그리고 가장 처음에도 말씀드렸지만 지극히 개인적인 의견입니다. 괜찮네 라고 생각되는 가져가시면 됩니다.

반응형

댓글

💲 추천 글