brunch

매거진 생각하기

You can make anything
by writing

C.S.Lewis

by maus x maus Nov 02. 2018

기타등등

#UI 디자인 작업


UI 디자인 연습을 안하는 이유는 잘만든 UI가 너무 많고 누구 말대로 큰 차별점이 없다고 생각이 들었습니다.

최근에 인상깊게 본게 하나 있는데 엄밀히 보면 편집디자인에 가까워서 사실 UI 디자인 역량을 알려주기엔 거리가 있었다고 생각이 들었습니다.


뭐 워낙에 틀이 명확하니 챌린지하기 꺼려하는 부분도 있었던거 같은데 말이죠..

UI 디자인의 핵심은 컨텍스를 UI에 얼마나 잘 녹여주는가에 달려 있다고 봅니다. 심미성이랑은 거리가 멀죠..

미니멀함을 추구한다면 분명 제약적인 기능일테고.. 그 중간 접점을 어떻게 타협해서 푸느냐가 관건이라고 봅니다.


이런것에 대해 브런치에 정리해서 글을 쓸까 했는데..안쓸려고요 ㅋㅋ

디자이너가 생각하는 UI

포트폴리오로 만들어지는 UI

실제 프로젝트에서 디자인되는 UI 는 확연히 틀립니다. 아주 많이 투박해 지겠죠.


그렇다고 포트폴리오의 과장된 디자인을 무시할수도 없는거 같습니다.


-



#Plugin과 업무 효율


스케치 그룹 커뮤니티에서 플러그인 이야기가 많이 올라옵니다.

저는 플러그인을 추천하지 않습니다. 기타 이외 서드파티도 최소화하고 있습니다.

유관툴이 많아 지면 관리 포인트도 동시에 증가합니다.


디자인 업무를 위해 사용하는 툴을 최대한 나열해 보면

일러, 포토샵, 스케치, 인비전, 제플린, 앱스트랙트, 프레이머, 프로토파이, 오버플로우 등 너무 많습니다.


저는 회사에서 스케치 x 제플린 조합으로만 사용하고 있습니다.

최근에 프로토파이를 도입했지만 실무보다는 빠른시간안에 제안이 필요할때 부가기능(있어도 그만 없어도 그만)으로 활용할 생각입니다.


플러그인은 시중에 많이 나와있고 괜찮은 기능도 많지만 버전 호환이 안되는 경우가 너무 많아서 아예 사용하지 않습니다. 그래도 한번씩은 돌려보는데 역시 버전 호환이 안되어서 “안쓸거야” 이런 상황입니다.


제가 플러그인을 써야하는 상황 3가지에 대해 생각해 봤는데요.

1. 제플린류의 플러그인은 커넥터의 성격을 가진지라 안쓸수가 없습니다.

2. 스케치 업무 효율을 200% 이상 올려주는 경우(rename it: 써봤는데 거기서 이름 바꾸는 패턴이 저랑은 달라서 안쓰는걸로..)

3. 스케치에서 물리적으로 구현못하는 경우(스케치 매직 미러).


이번 어도비 Xd 업데이트에서 add-on 이 생겼습니다.  플러그인 같은 개념인거죠.

플러그인은 왠만한 레거시가 아닌 이상 구동이 되어야 한다고 생각하는데 버전 업 마다 구동이 안되는건 사실 쓰지 말라는거랑 같다고 봅니다.

보헤미안코딩도 이러한 상황을 방관하지 않고 버전에 상관없이 구동되도록 구조를 잘 짜주었으면 합니다.


그리고 anima 같은 툴은 앵간하면 사용 지양합니다. 실무에서 그 정도의 기능을 활용할 일도 없습니다.



-




#UI KIT


제가 지금 직장에 와서 제일 먼저 한게 모바일웹 UI KIT을 만들었고 1달 반 걸렸던거 같습니다.

기존 PSD 수치가 정확하지 않아서 마크업된 작업물 기반으로 그렸습니다.

그리고 다음에는 똘똘한 팀원들 시켜서 모바일앱을 2배수에서 1배수로 줄이는 작업을 했습니다. 이건 좀 시간이 걸렸는데, UI KIT는 여러명이 이해가능한 수준으로 고민해야되며 “정석“이라는게 없기에 수많은 시행착오를 겪었습니다. 무수히 많은 반복작업들…심볼 아트보드 이름이 이상하다 싶으면 모든 이름을 다 바꾸는것도 서너번 했습니다.


저는 저희 UI KIT가 스탠다드라 말할순 없지만 그래도 대한민국 모든 디자이너들 앞에서 자랑하고 싶은 마음은 큽니다. 그러나 그럴일은 없어 보이네요. 그리고 많이 분들이 오해하시는데 UI KIT는  Design system 하고 다릅니다.


*UI KIT는 디자이너를 위한 디자인 에셋을 구조화 해 놓은것이고 Design system은  실제 프론트엔드 코딩까지 구현되어 UI KIT랑 맞물려 작동하는 개념입니다.


(1)

여튼 UI KIT를 만들기 위해 제일 먼저하는건 `patter`n 추출입니다. 공통된 컴포넌트가 어디에 얼마나 있는지 정리해야 합니다.

그래서 실제로 먼저 해야하는건 엑셀로 장표를 만들어서 어느 화면에 어떤 요소가 있는지 모아두어야 합니다.


(2)

그리고 그 pattern에 근거하여 `naming convention`을 각 (아트보드/ 심볼)레이어 폴더에 지정된 이름을 부여하도록 규칙을 만들어야 합니다.

프론트엔드 개발자랑 같이 협업하면 도움이 됩니다.


--UI KIT 제작의 절반은 `규격화` `규칙` 입니다. --


고려해야 될 점

- 새로운 디자이너가 작업할 수 있도록 레퍼런스 문서가 있는가?

- 새로운 컴포넌트 추가시 다른 컴포넌트에 영향을 주는가? ‘확장’

- 최소한의 컴포넌트로 최대한 다양한 UI 스크린 제작이 되는가?


너무 재사용을 많이하게 되면 네스티드 심볼이 복작하게 되기 때문에 심볼은 최대한 단순한 구조로 설계해야 합니다.


step by step 으로 (계산해 보니 대락 200페이지 분량) 책도 써볼까 생각도 해봤는데 차라리 어느 시점이 되면 온라인에 배포하는게 낫다 하는 생각이 들더군요.


지금까지 젤 궁합이 좋다는 프론트엔드 개발 언어는 react라고 합니다.

엑셀 문서는 10번 100번 갈아엎을 각오로 준비하세요.


제작 팁:

- 맥은 대소문자를 별도의 문자로 구분한다.

- 아트보드 이름의 시작을 숫자로 심볼 순서를 지정할 수 있는데 01, 02로 시작해라.

- 가급적이면 컴포넌트는 아토믹처럼 찢지 말고 심볼 갯수를 최소화해라.

- 회색 계열 컬러 규칙을 정해라.

- 심볼 크기는 최소화 된 경우를 기준으로 제작하라*

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari