*본 포스트는 "Invision App Blog"의 2016년 10월 14일 게재된"Kevin Tomasso"의 "Questions to ask developers befor you start designing"이라는 포스트를 국문으로 번역하여 더 많은 사람들에게 정보를 알리고자 하는 목적으로 저작된 포스트임을 밝힙니다.
다음 인용문은 InVision 사에서 제공하는 온라인 교육 과정 중에서 Kevin Tomasso가 강의한 'Designing with your developers in mind'에서 말한 내용입니다.
"대부분의 반응현 웹디자인에서는 다양한 제약 조건들이 존재합니다. 기술적인 측면에서의 제약과 함께, 개발팀이 지니고 있는 지식과 스킬에서도 그 제약 조건들은 발생할 수 있습니다."
본 포스트에서는 웹디자인 프로젝트를 시작하기에 앞서서 개발자들과 프로젝트 상 합의를 진행하기 위해 물어야 할 4가지 질문에 대해서 소개할 예정입니다.
개발자에게 해야 할 질문01.
디자인 결과물을 어떤 형태로 드리면 될까요?
저의 경우 프로젝트를 시작할 때 어떤 레이아웃 그래픽 툴(포토샵, 스케치 등)을 사용할지 고르는 것처럼, 작업 시작에 앞서 개발자들이 디자인 결과물 또는 리소스를 주고 받는 방식에 대해서 얼마나 익숙한지 꼭 물어보는 편입니다.
많은 디자이너들이 디자인 결과물을 어떤 포맷으로 만들어 내야할지 단순하게 자의적으로 가정하는 경우가 매우 많은 편입니다. 이런 경우에 개발을 코 앞에 두고서 다시 디자인 파일을 불러와서 다른 포맷으로 저장하거나 디자인을 수정하거나 하는 등의 상황을 겪을 수 있습니다.
아래 내용은 디자인 시작에 앞서 고려할 만한 질문 및 상황들입니다.
디자인 리소스는 어떤 식으로 준비되어야 할까요?
- 디자인 리소스를 를 다 조각내어서 정리되어진 폴더에 저장하기를 원하는가?
- 디자인 리소스가 뭉쳐진 통합 파일(PSD 등)을 그대로 전달하여, 개발자가 직접 리소스를 추출하길 원하는가?
- 통합 파일의 경우 PSD, AI, EPS, Sketch, PDF 등 어떤 파일 포맷으로 통합하여 전달 받기를 원하는가?
(프로그래의 버전은 디자이너의 것과 동일한가?) - 통합 파일의 그룹핑과 레이어 네이밍이 알아보기 쉽게 정돈되어 있는가?
- 드림위버와 같은 별도의 위지윅 에디터로 만들어진 HTML을 원하는가?
(드림위버와 같은 그래픽 인터페이스 프로그램으로 만들어진 코드가 개발자들에게 친숙함을 지닐 거라고 생각하시나요? 그들에게 묻는다면 10명 중 9명은 'No'라고 답할 것입니다. 대부분의 GUI로 만들어진 코드들은 지저분하고, 정리되지 않고, 사용하기 힘든 성질을 지니고 있습니다. 이런 것들은 개발자와 디자이너 모두의 워크플로우를 느리게 합니다. GUI로 만들어지는 코드는 피하시기 바랍니다. 이것을 옵션으로 생각할 경우 개발자와 충분한 토의 후 진행하는 것이 좋습니다.)
디자인 리소스들이 별도의 문서로 정리될 필요가 있습니까?
디자인 내용을 별도로 문서화하는 작업을 얼마나 자주 진행하십니까? 여기서 문서화란 컬러 코드나, 높이/너비에 대한 값, 폰트, 폰트사이즈, 알파값, 마우스오버 효과, 애니메이션 등등, 개발자들이 추측하거나 임시로 자의적 결정을 내리면 안 되는 부분들에 대한 문서화를 말하는 것입니다.
이런 문서화 작업에 유용한 어플리케이션들로 다음과 같은 것들이 있습니다.
- 옴니그라플(Omnigraffle) : 화살표나, 가종 심볼들을 쉽게 그릴 수 있게 함으로써 디자인의 특징을 쉽게 설명할 수 있게 해줍니다.
- 어보코드(Avocode) : 컬러, 이미지리소스, 폰트, 텍스트, CSS, 사이즈, 위치값 등을 포토샵이나 스케치에서 쉽게 추출할 수 있게 해줍니다.
- 인스펙트(Inspect from InVision) : 인스펙트는 위 소개된 제품들의 기능들을 수행함과 함께, 이미 InVision 사의 다른 제품들을 쓰고 있다면 더욱 더 효과적으로 사용할 수 있는 프로그램입니다. 제가 가장 흥미롭게 지켜보고 있는 프로그램 중 하나입니다.
개발자에게 해야 할 질문02.
웹사이트가 별도의 UI프레임워크를 통해서 제작될 예정인가요?
현재에는 디자인과 개발 사이드에서 큰 역할을 차지하는 다양한 프론트엔드 프레임워크들이 있습니다. 어떤 것이 사용될지 미리 아는 것은 디자인을 문서화하는 데에 있어서 매우 큰 도움이 될 수 있습니다.
부트스트랩이나, 960그리드(960 Grid)와 같은 유명한 프레임워크는 12열(12-column) 시스템을 차용합니다. 왜 12열이냐구요? 12라는 숫자는 작은 숫자 값 중 가장 쉽게 나눌 수 있는 값입니다. 12를 통해서 12, 6, 4, 3, 2 등의 값을 가질 수 있으며, 열이 양쪽으로 고르게 분할된 레이아웃 또한 취할 수 있습니다. 이러한 점은 디자인 프로세스를 더욱 더 쉽게 진행할 수 있게 도와줍니다.
이러한 프레임워크는 일종의 체계를 지니고 있으며, 이러한 체계를 작업 전에 파악하도록 합니다(글로벌 패딩(global padding), 열의 폭(column width), 열 간 간격 폭(gutter width), 미디어쿼리 분할점(media query breakpoints) 등등).
저의 경우 저의 디자인이 부트스트랩이 설정해 놓은 여백값 보다 5px 정도 컸던 적이 있어서, 해당 디자인들을 중단했던 적이 있습니다. 이런 상황은 전혀 즐거운 상황이 아닙니다. 이로 인해 많은 디자인 수정이 수반되야 하기 때문입니다. 어떤 프레임워크가 사용될 예정이고, 해당 프레임워크를 스케치나 포토샵에서 어떤 식으로 적용해야 하는지 미리 고려하시기 바랍니다.
그리드 외에도, 많은 프레임워크들이 버튼이나 폼, 툴팁과 같은 디자인 요소들을 제공합니다. 만약 이런 디자인 요소들을 커스텀하고 싶다면, 개발자들이 그러한 상황에 대해서 분명히 숙지하도록 하십니다.
많은 경우, 제가 특정 폼의 디자인을 별도로 진행한다고 해도 개발자들이 그냥 프레임워크에서 주어지는 스타일의 폼을 활용하는 경우가 많기 때문입니다.
개발자들이 2px의 border-radius 차이를 쉽게 인지하고 적용할 것이라고 생각하지 마십시오. 당연하게도, 디자인이 개발 전공 지식이 없듯이, 디자인 전공자가 아니기 때문입니다.
아래는 가장 유명한 UI(프론트엔드) 프레임워크들입니다.
- 부트스트랩(Bootstrap)
- 저브사의 파운데이션(Foundation by Zurb)
- 야후사의 퓨어(Pure by Yahoo)
- 스켈레톤(Skeleton)
- 시멘틱UI(Semantic UI)
- 그외 더 많은 프레임워크들이 있음
개발자에게 해야 할 질문03.
어떤 언어와 라이브러리들이 개발 환경을 구성하고, 제약사항이 얼마나 있나요?
코딩을 할 줄 모른다고 하더라고, 다양한 위젯과 플러그인들이 있음을 인터넷에서 파악할 수 있습니다. 코드 조각들은 언제나 이용 가능하며, 해당 조각들을 활용해서 사이트에 붙여 넣는 일은 그 어느 때 보다 쉬워졌습니다. 다만 한가지 주의할 점은 플러그인들은 모든 것에 다 쉽게 적용될 수 있는 것은 아니라는 것입니다.
웹사이트에 활용할 미리 정의된 UI플러그인들을 사용하는 것은 괜찮습니다만, 그 전에 미리 어떤 언어가 웹사이트 제작에 사용될 것인지를 미리 파악하는 것은 매우 중요합니다.
대부분의 플러그인이나 위젯들은 특정 언어로 제작이 되었기 떄문에, 다른 언어나 개발 환경에서는 작동하지 않을 수 있습니다.
루비(Ruby)로 제작된 날씨 어플리케이션은 PHP로 제작된 사이트에서는 구동되지 않을 것입니다. 또한 닷넷(.NET)으로 구성된 사이트는 워드프레스 플러그인을 구동하지 못할 것입니다. 같은 자바스크립트 기반이라고 할지라도 앵귤러(Angular) 로딩 바는 백본(Backbone)JS로 구성된 사이트에서는 구동되지 않을 것입니다.
개발 환경과 맞는 위젯/플러그인을 찾았다고 하더라고, 일종의 예시로 보여주는 용도로만 개발팀에 공유를 하기 바랍니다. 해당 플러그인을 그대로 사용할지 또는 새로 개발을 할지는 정의할 것이기 때문입니다. 개발팀에게 코드를 통채로 압축해서 ZIP파일로 전송하고서 '이렇게 개발해 주세요'라고 요청하는 행위는, 당신에게 100px의 이미지 썸네일들을 왕창 보내 놓고서는 '이 이미지들로 근사하고 큰 슬라이드쇼를 만들어 주세요'라고 말하는 것과 다름 없다는 것을 알아두시기 바랍니다. 그렇란 행동은예의에 어긋남과 동시에 겸손이 부족함을 나타낼 수 있습니다.
개발자에게 해야 할 질문04.
어떤 브라우저를 우리가 지원해야 합니까?
알다시피, 인터넷 익스플로러는 파멸의 존재와도 같습니다...
다행히도 최근에는 브라우저들의 다양성이 점점 좁아지고 있는 실정이기는 합니다. 마이크로소프트도 IE에 대한 지원을 버리기 시작했으며, Edge를 주력으로 배포하고 있습니다.
어느정도 까지의 이전 세대의 브라우저를 지원하는지 여부는 디자인에 큰 영향을 끼치게 됩니다. 아래는 이전 세대 브라우저들이 지원하지 않는 빈도수가 높은 CSS 속성에 대한 리스트입니다.
- Border-radius: IE8
- text-shadow: IE8, 9, Firefox 2, 3
- box-shadow: IE8, Firefox 2, 3
- RGBA (color transparency): ie8
- Flexbox (more on this later): IE8, 9. Needs adjustments for older versions of Safari and Firefox
- Multiple backgrounds: IE8, Firefox 2-3.5
- SVG: IE8 (many others for specific things)
- CSS Animation: IE8, 9, Firefox 2-4, Safari 3.1 – 3.2
- CSS 2D transforms (rotation, scale): IE8, Firefox 2, 3
- Media Queries: IE8, Firefox 2, 3
*모든 브라우저들의 기능 가능 범위 확인 'Can I Use'에서 확인할 수 있습니다.
이전 세대 브라우저 중 IE8 또는 구 버전의 파이어폭스나 사파리를 지원해야 한다면, 특정 시각 효과가 제거된 상태에서 어떻게 보일지에 대한 디자인 또한 이루어져야 합니다. 모든 둥근 모서리는 각지게 바뀔 것이며, 애니메이션과 그림자는 사라지게 될 것입니다.
최신 기술을 사용하면서도 이전 세대 브라우저에서도 정상적으로 사용 가능하게 유지하는 작업 방식을 progressive enhancement라고 부르곤 합니다. 완전한 사이트의 완성을 위해서 고려해야 할 또 하나의 요소입니다.
위 소개한 네 개의 개발자에게 해야 할 질문들이 개발자들과의 커뮤니케이션을 효과적으로 하게 해주길 바랍니다. 어떤 제약이 있을지 미리 아는 것은 어떤 디자인 룰을 따를지 생각할 수 있게 해주고, 여러 개발/디자인 문제들에 대해 대안들을 설정할 수 있게 해줍니다.
더 읽어볼 만한 포스트 (개발자와 디자이너 협업 관련)
- 개발자와 디자이너의 협업을 발전시키기 위한 3가지 방법 : http://blog.invisionapp.com/designer-developer-collaboration/
더 많은 개발자와의 협업 관련 팁을 원한다면
Kevin Tomasso가 진행한 E-Course를 등록하여, 더 많은 개발자와의 효과적 협업을 위한 강의를 수강하도록 하세요. 이것들은 모두 무료입니다.
원 저자
Kevin Tomassio, UX/UI Designer/Developer at Homes & Land
이성과 아름다움 사이의 교차점에 서 있습니다.
저작권 관련 정보 (License Info.)
|
'UX 리서치 > 디자인 이론과 리서치' 카테고리의 다른 글
| 해외 웹디자이너들이 선호하는 폰트 10개 (0) | 2019.03.02 |
|---|---|
| 그림으로 알아보는 컴퓨터 아이콘의 역사 (0) | 2019.03.02 |
| 카드 UI디자인 하는 법 파헤치기 (0) | 2019.03.02 |
| 좋은 인터페이스 디자인(UI디자인)의 8가지 법칙 (0) | 2019.03.02 |
| UI디자인 패턴 파악에 도움을 주는 10개의 사이트 (0) | 2019.03.02 |
