UI 디자이너의 위기지학, Design Hacking을 통해 코딩 배우기

Re-design!

UI 디자이너의 위기지학, Design Hacking을 통해 코딩 배우기

無異 2017. 4. 5. 07:50

pxd에서는 2017년을 UI 디자이너가 코딩하는 원년으로 삼기로 했습니다. 저 혼자 정한 거지만요. :)
UI 디자이너가 코딩을 배워야 하는 이유에 대한 글들은 많이 보셨을 텐데요. 저는 UI 디자이너의 의도적 수련에 필요한 능력으로써 코딩을 배우면 좋겠습니다.
코딩을 배워야겠다고 생각하는 디자이너는 많아도 새로운 걸 배운다는 부담감이 커서인지 주변에서 실제 코딩을 배우는 분은 별로 없습니다. 그래서 같이 따라 하면서 실질적으로 코딩을 배울 수 있는 디자이너의 코딩 수련장(workbook) 형식으로 글을 써보려고 합니다.

UI 디자이너의 의도적 수련과 피드백

디자이너로서 전문성을 키우고 성장하는 데는 새로운 방법과 지식을 습득하는 것도 필요하지만 직접 디자인하고 그것에 대한 피드백을 통해 학습하는 디자인 수련이 더욱 중요합니다. 김연아 같은 훌륭한 선수가 되는데 필요한 요건으로 피나는, 뼈를 깎는 같은 수사의 노력과 훈련을 빼놓지 않는데요. 스포츠 같은 분야는 이런 수련의 모습이 머리속에 쉽게 그려지지만, UI 디자이너가 뼈를 깎는 수련을 하는 모습은 잘 연상되지 않습니다.
연습의 행위 보다 피드백에 차이에 기인한다고 생각합니다. 전자의 경우는 점수를 얻거나 승부를 가리는 규정(측정)이 명확해서 기량이 향상되고 있는지 피드백이 즉각적이고 명료합니다.

반면에 UI 디자인 자체로써는 사용자가 사용하는 제품이 아니기 때문에 피드백을 얻는 데 불리합니다. 개발자의 구현이 있어야만 사용자가 접하고 피드백을 받을 수 있어 응답 주기가 길어집니다. 디자인과 사용자 피드백 사이에 다양한 변수가 존재해서 해석석하는데 모호함이 생깁니다. 다양한 사용자가 각자의 다양한 맥락에서 디자인을 판단하기 때문에 어떤것이 유의미한 피드백인지 판단하기가 어렵습니다.

디자인 에이전시에서 수행하는 과제들은 디자인과 개발 단계가 분리되어 있고 제품 출시까지의 주기가 길어 디자인에 대한 사용자 피드백을 얻을 기회가 적습니다. 그래서 과정에 leanUX 방법과 프로토타이핑을 적극적으로 도입하려고 하지만 일정이나 비용 제약으로 적용할 수 있는 과제는 제한적입니다.

구체적인 피드백을 제때 받아야 개선을 하고 실력을 향상할 수 있는데요. 일을 많이 해서 경력이 쌓인다고 실력이 늘지 않습니다. 일은 일이고, 실력을 키우려면 개인적인 노력이 필요합니다. 그럼 뭘 어떻게 노력해야 하나요? 그래서 UI 디자이너의 의도적 수련 방법으로 Design Hacking을 제안합니다.

나를 위한 UI 디자인, Design Hacking 하기

수련에 도움이 되는 구체적인 피드백을 받으려면 변수와 범위를 가급적 제한해야 합니다.

1. 기존의 것을 개선하기

뭔가 세상에 없던 혁신적인 것을 만드는 것이 좋은 디자인이라고 생각하고 강박적으로 새로운 것만 찾으려고 하는 경우가 많은데요. 하지마세요. 검증(측정)해야 하는 범위가 너무 넓어져서 수련 방법으로는 적합하지 않습니다.

디자인 수련은 문제를 찾고 해결하는 과정을 연습하려는 것인데 우선은 기존 문제의 해결 부분에 집중하는게 좋습니다. 사람들이 잘 쓰고 있어서 필요가 검증된, 항상 시험에 나오는 기출 문제부터 시작하세요. 범위를 보다 제한해서 하나의 화면, 그 안에서도 하나의 모듈, 하나의 기능을 선명한 목적을 가지고 개선해보는 게 좋습니다. 변수가 통제되어 기존 것보다 좋아졌는지 아닌지 대조가 명확해야 피드백의 가치가 있습니다.

2. 디자인 해킹으로 동작하는 프로토타입 만들기

페이퍼 프로토타입이라도 만들어보라고 하는 건 안 만들어서 피드백이 아예 없는 것보다는 낫기 때문입니다. 가급적 충실도가 높은 프로토타입으로 실제 맥락에서 실제 데이타를 가지고 직접 사용해 볼 수록 보다 좋은 피드백을 얻을 수 있습니다. 아무리 대박이 날 좋은 아이디어라도 컨셉 스케치만으로는 배우는 게 없습니다.

그렇다고 미천한 코딩 실력으로 실제 사용 가능한 서비스 프로토타입을 만들기는 어렵습니다. 프로토타이핑 툴을 이용해서 플로우나 마이크로 인터랙션을 확인 해보는 것은 여기서 말하는 동작(working)에 해당하지 않습니다. 기존의 동작하는 서비스를 여전히 동작하는 범위 안에서 수정해서(hacking) 사용해보고 평가해보는 경험을 많이 해보는 게 좋습니다.
그래서 코딩을 배우세요. 뒤 단에서 서비스가 어떻게 돌아가는지, 시스템 프로그래밍을 하는 것은 기대하지 않습니다. 말단 인터페이스의 시각적인 정보 디자인과 인터랙션만이라도 내가 생각하는 디자인으로 바꿔서 현실화해보고 싶다는 분명한 목적을 가지고 코딩을 배우면 좀 더 수월하게 배울 수 있습니다. 코딩을 체계적으로 배워서 나중에 뭘 해보겠다는 접근 보다 실질적인 필요를 위해 우선 베껴서라도 돌아가게 하고 나중에 원리를 이해하는 방법이 실용적입니다.

3. 디자인 위기지학

UI 디자인을 배울 때 사용자는 내가 아니라는 것을 강조합니다. 특히 디자이너나 개발자는 사용자가 아니라고요. 물론 디자인을 하는데 실제 사용자를 조사하고 이해하는 과정이 중요합니다. 그리고 어렵습니다. 그래서 안 하려고요. 이건 따로 연습하세요. 물론 대부분 과제의 사용자는 내가 아닌 경우가 많습니다. 하지만 일 하는 게 아니라 배우려는 거니까요. 내가 사용자인 서비스로 우선 디자인의 핵심에 집중해서 연습하는 게 좋습니다.

사용자 이해 - (문제 정의 - 문제 해결) - 사용자 피드백

힘든 수련을 계속해 나가려면 보상이 필요합니다. 내 문제를 스스로 해결하는 즐거움을 경험하는 것도 중요합니다. 나를 위한 디자인을 우선하고 남들에게도 적용할 수 있는지 확장하는 접근을 써보는게 좋습니다. 많은 문제들이 user centered design 보다 human centered design 이 제대로 안된 경우가 많거든요.

기존의 서비스를 사용하다 보면 아쉬운 점 한 두가지는 꼭 있죠? 내가 사용하면서 불편했던 바로 그 UI를 개선하는 연습을 할 것입니다. 내가 만족스럽지 못한 서비스는 크게 두 가지 경우 일텐데요.

내가 대상 퍼소나가 아닌 경우

정말 이거 하나만 고쳐주면 좋은데 왜 안하는지 이해 못하겠는 경우가 많죠? 디자인을 하면서 퍼소나 방법을 사용하는 이유입니다. 개개인의 요구사항을 다 들어주다가는 누구의 요구도 만족시키지 못 하게 됩니다.
하지만 마이너한 사용자층의 니즈를 발견하여 개선하는 것은 디자인 수련에서 앞서 얘기한 사용자의 이해 부분을 연습하는데 많은 도움이 됩니다. 그냥 내맘대로가 아니라 공통된 맥락과 니즈를 가지는 사용자 그룹을 객관화하는 훈련을 하면 다른 관점의 디자인을 할 수 있습니다.

다른 대상의 사용자를 위한 product hacking - Desiging Interactions

사용자들이 잠재적인 니즈를 아직 의식하지 못하는 경우

얼리어답터는 새로운 제품이 나오면 가장 먼저 그것을 사용해보고 싶어하는 그룹입니다. 하지만 그 앞에 시장에 제품(해결)이 없더라도 필요에 대한 감수성이 높은 Lead Users 사용자층이 있습니다. 관점은 다르지만 하라켄야의 욕망의 에듀케이션도 비슷한 의미라고 생각합니다. 몰라서 필요를 못 느끼는 거지 좋은 걸 한번 경험하게 되면 톱니바퀴 효과처럼 이전으로는 되돌아 가지 못합니다. 취향이나 상황이 다른게 아니라 필요에 대한 감수성이 남들보다 높은 부분은 좋은 해결만 찾아준다면 모두에게 도움이 될 수 있습니다.
서비스 제공자 입장에서도 이것을 하나의 사용자 피드백으로 바라보고 두가지 관점에서 대상이 아닌건 무시하고 좋은 건 수용하는 열린 접근을 하면 서비스를 건강하게 만드는데 도움이 됩니다. 애플이 시디아 같은 탈옥 기기를 위한 앱 스토어를 강력하게 제한하지 않는 것도 같은 이유라고 생각합니다.

Design Hacking 연재에서는 내가 잘 쓰고 있는 웹서비스의 불편을 느끼는 구체적인 한 부분을 선택해서 개선하고 직접 사용하고 평가하는 과정을 반복할 것 입니다. 우선은 제가 고쳐서 사용하고 있는 사례들을 소개하겠지만 궁극적으로는 여러분들과 함께 개선하고 싶은 서비스를 선정해서 함께 디자인 개선을 해보는 방식으로 진행하려고 합니다. 리디자인 결과 위주가 아니라 design hacking 코드를 공유해서 여러분 스스로가 자신에 맞게 고쳐보도록 할 것입니다. 나를 위한 디자인을 하면서 코딩을 배워보세요.

이제 바로 코딩을 시작합니다

우선 다음을 준비해 주세요.

크롬 브라우저

브라우저는 웹페이지의 HTML, CSS, Javascript 코드를 해석해서 보여줍니다. 크롬은 확장을 통해 서비스 제공자의 코드에 사용자 자신의 코드를 삽입하여 디자인을 바꿀 수 있습니다.
HTML은 실제 화면에 보여주는 내용과 tag로 요소의 구조를 정의한 코드입니다. CSS는 각 요소들이 어떻게 보여지는지를 정의하고 Javascript는 요소들을 동적으로 변화시키도록 하는 코드입니다. 코드를 보고 싶으세요? 크롬에서 보기>개발자 정보>개발자 도구 를 여세요.
매트릭스에 오신 걸 환영해요.

styler 확장

개발자 도구에서 요소의 스타일을 바꿔보거나 콘솔에서 코드를 실행해 보는 것만으로도 다양한 실험을 해볼 수 있습니다. 하지만 수정은 일시적일 뿐인데요. styler 확장을 이용하면 스타일을 변경하고 실행 코드를 삽입하는 규칙을 설정해서 특정 사이트의 디자인을 항상 변경할 수 있습니다. 구글 계정 동기화를 통해 다른 컴퓨터에서도 그대로 사용할 수 있어 편리하고요. s tyler는 여기 에서 설치하세요.

코딩을 배우고 오세요

설마 코딩을 가르쳐 준다고 생각한 건 아니죠?같이 문제를 풀어보자고 했지 가르쳐준다고는 안했어요. :) 코딩을 배울 수 있는 좋은 책과 좋은 온라인 교재가 많습니다.
온라인 강의는 egoing님의 생활코딩을 추천합니다. HTML, CSS, Javascript 수업도 들어보고 서점에 가서 자기 수준에 맞는 책을 골라 계속 참고하시길 바랍니다.
물론 먼저 따라해보고 코딩은 나중에 배워도 됩니다.

첫 디자인 해킹. 아직도 돋움으로 보세요?

저는 못생긴 폰트 사용하고 글자 작고, 줄간 간격 너무 좁고, 여백 좁아 답답하고 화가 나는 웹사이트 목록이 한 가득이에요. 타이포그래피도 UI 디자인에서 중요한 부분이지만 국내 웹사이트에서는 많이 간과하고 있는 것 같습니다. 이것도 디자이너가 코딩을 하지 못하는 것이 큰 이유라고 생각하는데요. 디자인 툴을 이용할 때는 타이포그래피 장인이어도 코드로 구현된 웹에서는 섬세하게 디자이너의 의도가 반영 되지 못하고 있는 것 같습니다. 폰트의 선택에서도 웹폰트가 많이 도입이 되고 있지만 전국민을 대상으로 하는 포탈 서비스에서는 요원합니다. 로마자에 비해 엄청나게 큰 한글 폰트의 용량 관계로 전 국민을 대상으로 하는 포탈 서비스에는 적용하기 어렵습니다. 가급적 모든 사용자의 컴퓨터에 미리 설치된 폰트를 선택할 수 밖에 없는데요. 그래서 네이버, 다음의 기본 폰트는 아직도 돋움입니다. 고조선이야 뭐야? 윈도우 95야?

다음 금융 http://finance.daum.net/ 사이트처럼 숫자가 많이 사용되는 곳에서는 특히 숫자 가독성이 중요한데요. 그리 만족스럽지 못합니다.

기본 글꼴로 숫자는 arial을 사용하고 있는데요. 69 같은 글리프의 획이 8과 비슷하게 둥글게 말려있어 판독성(legibility)이 떨어집니다. 구분을 못할 건 아니지만 이런 작은 인지 부하가 쌓여서 가독성이 떨어지게 됩니다. 숫자 폰트 중에서는 스포카에서 lato를 좀 더 간결하게 커스텀한 스포카한산스를 선호하는데요. 이 폰트로 바꿔보겠습니다.

Styler 확장 사용법

크롬으로 사이트에 접속해서 styler 확장을 클릭하면 CSS와 JavaScript/jQuery 두개의 입력창이 보이는데요. 이곳에 코드를 적으면 상단에 보이는 도메인에 대해서는 항상 적용이 됩니다.

우선 모든 요소에 대해서 폰트를 강제 지정합니다. 스타일 부분에 아래 코드를 적어보세요. 아. 폰트는 미리 설치하셨죠?

* *{
  font-family:spoqahansans !important;
}

주가의 상승 하락의 빨강과 파랑이 너무 자극적이어서 피곤합니다. 네이버도 마찮가지인데요. 조금 톤을 낮추는게 좋겠습니다.

.factor_up, .factor_up_type2 {
    color: #cc3e3e !important;
}

.factor_down, .factor_down_type2 {
  color:#477fd2 !important;
}

타이포그래피 측면에서 단위 기호 표기 방법 고민해 보셨나요?

비율 % 표시도 많이 사용되는데 숫자에 단위 기호가 딱 붙어 있는 게 보기 좋지 않습니다. 국제 단위 표기법에서 알파벳 기반의 단위는 수치값과 한 칸 띄우고 (123 cm, 45 kg) 기호 단위는 붙여 쓰는게 (67%, $89) 맞긴 합니다. 텍스트 표기의 원칙이 그렇다는 것이고 타이포그래피를 이용하면 좀 더 보기 편하고 잘 읽히게 만들 수 있습니다. 단위가 반복되고 맥락상 이해할 수 있으면 정보값이 잘 읽힐 수 있게 단위가 쉽게 구분 되는게 좋습니다. 이걸 서버단에서 처리하는 건 너무 귀찮은 작업이고 또 이런걸 신경 쓰는 사람도 별로 없으니까 그냥 다들 하는데로 내버려두는데요. 구현의 귀찮음의 비용을 사용자 인지 비용으로 떠넘기고 있는 셈입니다. 스크립트로 후 처리하는 방법을 적용해 주면 좋겠습니다.

저는 페이지가 로딩되고 난 후 숫자가 표시된 요소들에서 %를 <sub>%</sub>로 감싸고 sub 여백을 좀 주고 글자를 조금 작게하여 정보값인 숫자와 구분이 되도록 했습니다. (sub는 이런데 쓰는건 아니지만). 전문 개발자라면 제대로 된 쌈박한 라이브러리를 만들 수 있을 거라고 생각합니다. 관심을 가져주세요.

$(function(){
  $("span").each(function(){
	var num=$(this).html().replace(/%/,"<sub>%</sub>");
	$(this).html(num);
  });
});

sub{
  font-size:50%;
  margin-left:0.2em;
  vertical-align:bottom;
  opacity:0.6;
}

Before

After

TO-DO

이제 여러분 차례입니다. 여러분의 관점에서 디자인을 개선해 보세요. 도대체 뭐라는 건지 하나도 모르겠으면 개발자 도구 에서 속성값을 조금씩 고쳐보세요. 어떻게 하면 디자인이 망쳐지는지 어떻게 하면 더 나아지는지 직접 고쳐보고 경험해보는 게 좋습니다. 그리고 왜 이렇게 되는지, 뭘 더 할 수 있는지 궁금해지면 책을 보고 공부해보세요.

제가 디자인한 코드는 이곳에 공유 합니다. http://codepen.io/taekie/pen/xqBLab

여러분도 여러분의 디자인과 코드를 공유해 주세요.

[참고##Design Hacking##]