UXUI

UXUI 디자인 아트보드 룰 정하기 - 효율적인 관리와 협업을 위해서

debbbie 2024. 7. 7. 10:01

 

 

현재 근무하는 회사에서 아예 디자인/기획 파일이 존재하지 않는 프로덕트를 맡게 되었다. (뚜둥)
기존 조직에서 통용되는 common rule이 없어서 스스로 알아서 잘 만들어보기로 하였다.

이전 직정에서 시행착오를 겪으면서 얻었던 인사이트를 최대한 활용하려했다. :) 

 

 

 

 

 


UXUI 디자인 아트보드 룰 정하기 - 효율적인 관리와 협업을 위해서

2024/07/07

 

 

1. 페이지명 규칙

어느 페이지에서 파생된 기능인지 확인

직관적이고 적절한 영단어 사용

구분자 ‘>’

소문자

띄어쓰기는 ‘-’

=> IA 기준으로 페이지 명을 고려하고 배치한다. 또한, 아트보드 이름은 실제 https 페이지명과 동일해져야한다. 그러기 위해선 직관적으로 적절한 영어 단어를 사용해야 된다. 예를들면 결제는 payment, 디테일 페이지는 detail를 사용하듯이. 그래야 개발자-디자이너-마케터 사이에 커뮤니케이션 시간이 단축된다!

 

 

 

=> 페이지 뎁스를 구분할때는 해당 페이지가 어디서 온건지 명확하게 구분해줘야한다. IA와 동일한 이유. 구분자는 취향에 맞게 사용하면 되는데 '/'를 아트보드에 쓸 경우 폴더화가 되어버려서 대신에 '>'를 쓴다.
대소문자는 각 회사나 프로덕트 규칙에 따라 사용하면 되는데, 오타의 실수를 줄이기위해서 되도록 소문자를 쓴다.
예를 들면, 결제라면 'payment'이고, 다음 뎁스인 결제 디테일 페이지면 'payment > detail'이다.

 

 

  1. 뎁스
    대메뉴 > 소메뉴 > 디테일 기능1 > 디테일 기능 2
    파일명 관리를 위해 되도록 3뎁스 까지 권장
    (예. build > create-build)

    => 3뎁스 이상이 된다면 오히려 경로를 한 눈에 파악하기 어렵다. 이 경우에는 차라리 IA에서 구조를 다시 분리하거나 페이지 구성을 다시 생각하는 편이 좋을지도 모른다.

  2. 모달
    modal을 prefix로 구분
    modal > 대메뉴 > 소메뉴 > 디테일 기능1 > 디테일 기능 2
    (예. modal > build > create-build > site-list)

 

2.케이스 관리

  1. 콤포넌트 화
    모든 시나리오를 페이지로 제작하지 않고 component화를 하여 일괄 관리
    한 페이지내에서 3번 이상 중복 사용 되거나, 2개의 페이지 이상에서 사용
    (*모든 요소를 콤포넌트화 하면 메모리 이슈)
    comp로 네이밍, 폴더관리를 위해 구분자 ‘/’
    (예. comp/request, comp/login)

 

  1. 케이스
    한 가지 기능에 대한 모든 시나리오 variant
    props값을 명확하게 지정
    개발자와 협업에 용이하여 커뮤니케이션 시간 단축
    case를 prefix로 구분
    case > 대메뉴 > 소메뉴 > 디테일 기능1 > 디테일 기능 2
    (예. case > payment > detail)

    => 여러 페이지에서 쓰이는 요소를 콤포넌트화 하지 않는다면 하나의 변경 사항이 있을때 일일히 변경해야한다.
    반드시 최종 GUI를 작업할때는 콤포넌트 화를 해서 케이스 관리를 해야한다.
    다만 한페이지에서 쓰인 단일 요소를 콤포넌트로 만든다면, 파일이 무거워서 메모리 문제가 생길수 있으니 주의.
    사용하지 않거나 잘못만든 콤포넌트는 dettach로 용량 관리를 해줘야한다.
    variants를 사용해서 value를 케이스별로 잘 등록해두고, comp라는 폴더에서 관리할수 있도록 구분자를 '|'로 써주자.
    디테일한 텍스트나 형태 변화의 경우가 있다면 case로 관리한다. 

3.dummy 페이지 관리

dummy 페이지로 추가
이전 기획 및 디자인 삭제가 아닌 재활용, 일자 및 기획 내용으로 구분
파일 용량을 위해 되도록 dettach component하기

=> 선택받지 못한 시안이나, 기획이나 디자인 변경 사항이 생겼을땐 파일을 삭제하지 말고
dummy 페이지에 옮겨서 히스토리 관리를 한다. 언제 어떤 내용인지 명확하게 메모를 해둔다. 

 

 

4.히스토리 관리

파일의 용량을 줄이고 과거 기획 및 디자인 관리를 위해 별도의 파일로 관리
파일 용량을 위해 되도록 콤포넌트는 dettach component하기 (매우 중요!)
히스토리 분기 기준 > 실제 릴리즈 여부