Free Mind Free Web

외부 사이트 링크를 새 탭으로 여는게 옳은가?

mindfree — Thu, 29 Mar 2012 18:21:12 +0900

댓글의 출처: http://www.smashingmagazine.com/2012/03/26/an-analysis-navigation-portfolio-websites/

특히 브라우저들이 '탭' 기능을 추가함에 따라, 새로운 브라우저를 열고 닫는 불편함이 없어진 뒤로, 웹페이지 내에 포함된 외부 사이트 링크는 당연히 새로운 탭에 열리도록 하는게 맞다고 생각했는데, 다른 의견을 가진 UX전문가가 있다.

디자이너 혹은 디자인 에이전시의 포트폴리오 사이트를 사용성 관점에서 평가한 포스트에 달린 댓글.

방문자 의견:
You should probably use target=”_blank” in your links to external sites so that people who want to view one of the sites they’re reading about don’t have to leave the article, they just go to the new tab and close it when they’re done.

외부 사이트로 이동하는 링크에 "target=”_blank”를 써서 읽고 있던 글을 떠날 필요 없이 새 탭에서 읽고 다 읽으면 닫도록 하는게 좋겠다.

그러자,

저자 답변:
First of all, thanks for your comment.
Without going into the merits that this styling is part of the Smashing Magazine style rules, I would like to comment why I agree with the fact that links open in the same window. From a usability perspective, studies show that users know they reached a page via a link so they will intuitively hit the browser’s back button to go back where they were. If a link opens in a new tab, this is not possible so users will likely close that tab or, worse still, hit the close button for the browser. On the other hand, it is recommended that non-HTML documents such as PDFs open in a new tab because users are likely to close the document after reading.
Hope this clarifies why we opted for this method.

설명하자면, 일단 글이 실린 스매싱 매거진의 스타일 규칙이 있다는 걸 말한 다음, 그 뒤에 자기 '왜 링크가 같은 윈도우에서 열려야 한다고 생각하는지' 의견을 덧붙인다.

사용성의 관점에서, 사용자가 링크를 클릭한 다음 브라우저의 뒤로 버튼을 눌러서 원래 있던 곳으로 돌아오는 것을 연구가 보여준다. 새 탭에서 링크가 열리면 이게 불가능하므로 탭을 닫거나 혹은 브라우저 닫기 버튼을 누르는 더 안좋은 상황이 생긴다.

나는 저자의 말에서 '아예 브라우저 닫기 버튼을 클릭해버리는 상황이 생긴다'는 말에 공감할 수 있을 것 같다. 탭 기능은 최근에 등장한 기술이고, 새로운 브라우저가 뜨고 그걸 닫는 방식은 아주 오랫동안 써온 방법이다. 그러므로 뒤로 버튼을 클릭하면 이전 화면으로 돌아간다는 건 대부분의 인터넷 사용자가 알고 있지만(연구결과를 보면 오히려 내비게이션보다 이걸 더 많이 쓴다. 뒤로를 계속 누르는거지), 탭은 상대적으로 익숙하지 않다는 얘기.

근데 뒤로 버튼을 이용할 때 생기는 문제 중 하나는, 내가 읽던 부분이 아니라 문서의 맨 위로 이동한다는 데 있다. 글을 읽던 중에 이동하면 다시 읽던 곳을 찾아와야 하는. 이런 관점에선 새 탭이 나은 것 같기도 하고.

어느 쪽 손을 들기 어려운 문제...

성공적인 '구매 버튼'을 디자인하는 5가지 팁

mindfree — Wed, 07 Mar 2012 15:11:38 +0900

hongkiat.com에 올라온 5 Tips to Designing a Winning “Buy Button”을 번역한 글. 아주 기초적인 내용인데, 의외로 '버튼'의 기능이나 의미를 생각하지 않고 디자인하는 경우가 종종 있다. 특히 쇼핑몰을 디자인한다면 기본 원칙으로 꼭 염두에 둘만한 내용.

만약 당신이 디자이너거나 온라인 마케터 혹은 어쩌다보니 어떤 시점에 어떤 물건을 팔아야 하는 웹사이트를 소유하게 되었다면, 적합한 '구매 버튼'을 디자인할 필요성이 생긴다. 그러고 나면, '지금 구매' 텍스트를 푸른색 사각형 안에 넣는 것만으로는 기대하는 좋은 결과를 얻지 못한다는 사실을 금방 알아챌 것이다.

다행히도, 적합한 '구매 버튼'을 디자인하는 일은 일단 기본 지식만 알고 나면 그다지 어렵지 않다. 시작해볼까.

우선, 버튼 위에 올리는 텍스트가 가장 중요하지만, 갖춰야할 다른 몇 가지 다른 기능도 있다. 왜 텍스트가 가장 중요하다고 했을까? 이걸 상상해보라 - 멋지게 디자인된 버튼 위에 '지옥에나 가라!'는 텍스트가 있다면 어떤 의미가 있나? 상황 종료다. 좋은 카피에서 돈이 만들어진다.

이번 글에선 적합한 '구매 버튼'의 결정적인 다섯 가지 특징에 대해 논하려한다. 한 번 살펴볼까.

1. 전체적인 스타일

이것이 이유 없이 가장 중요한 특징으로 목록의 첫 번째에 올라온 것은 아니다.

버튼을 보랏빛 소로 전환시켜야 한다. 보랏빛 소는 세스 고딘에 의해 유명해진 컨셉이다. 간단히 말해서 버튼을 눈에 띄도록 해야 한다; 눈에 띄도록 한다는 말은 그냥 지나칠 수 없는 무언가를 만든다는 뜻이다. 목장 한가운데의 보랏빛 소같은 무언가 말이다.

어떤 디자이너들은 특별히 이점에 잘 대처하지는 못한다. 버튼이 자리잡은 웹사이트의 색상과 스타일에 아름답게 어울리는 버튼을 만드려 하는 유혹 때문이다. 처음 볼 때는 아주 좋은 생각 같은데, 결국 그렇지는 않다.

문제는 이같은 버튼은 눈에 띄지 않는다는 것이다. 당신도 버튼이 섞여 들어가길 원하지는 않을 것이다; 버튼이 돋보이길 원한다. 그러므로, 버튼은 웹사이트에 섞여들어간 무언가가 아니라, 버튼이 자리잡은 웹사이트에서 완전히 분리된 요소가 되어야 한다.

보랏빛 소 같은 버튼의 멋진 예를 들어보자.

Mozilla Firefox

파이어폭스 다운로드 페이지의 모습이다. 여기서 한 가지를 알아채길 바란다. 왼쪽에 있는 다운로드 버튼은 이 페이지에 있는 다른 어떤 것과도 비슷하지 않다. 녹색 요소는 이것 뿐이다. 파이어폭스 로고가 보이는 곳도 여기 뿐이다. 이 페이지에서 가장 큰 요소 중 하나다. 화면을 나눈 부분의 상단에 자리잡고 있다.

이 모든 특징이 이 버튼을 극단적으로 눈에 띄게 만든다. 이것이 보랏빛 소다. 이 버튼이 보이지 않는다고 한다면, 그저 누군가에게 인상적으로 보이고 싶어 그러는거다.

요약하자면: 눈에 띄는 버튼을 만드는데 목표를 두라.

2. 겉모습

색상 얘기로 시작해보자.

눈에 띄도록 하고 싶다면 페이지의 다른 곳 어디에서도 사용하지 않은 색상을 사용하라. 딱 파이어폭스를 만든 사람들이 웹사이트에서 한 것처럼 그대로. Color Scheme Designer 같은 툴을 사용해서 웹사이트의 기존 색상 계획에 어울리면서도 아주 다른 색을 찾아낼 수 있다.

그리고 "다름"이 키워드다. 만약 웹사이트가 대부분 푸른색이라면, 푸른색 구매 버튼은 안된다. 푸른색 음영도 안된다. 푸른 빛깔을 띈 어떤 것도 안된다. 분홍색 혹은 오렌지색 같은 걸 써야 한다. 무슨 말인지 알 것이다.

비법 하나 더. 오렌지색은 붉은색 다음으로 가장 눈에 띄는 색상이다. 그러나 붉은색이 하는 것처럼 부정적인 감정("멈춤", "조심!", "위험" 같은)을 고조시키지는 않는다. 인터넷에서 가장 유명한 오렌지색 버튼은 amazon.com에서 찾을 수 있다.

다음으로 집중할 것은 버튼의 크기다. 뭐, 달리 할 말이 없다. 버튼은 커야 한다. 클수록 좋다. (다시 한 번, 파이어폭스 예시를 떠올려라)

"이보다 더 크게 할 수 있을까?"는 디자인 과정에서의 좋은 질문이다.

단순하게 혹은 화려하게?
버튼은 화려할 수도 있다. 파이어폭스 버튼을 한 번 더 보자. 화려하다. 오렌지색 여우도 있지만 여전히 버튼처럼 보인다. 그리고 이 점이 넘어서면 안되는 경계선이다. 만약 버튼처럼 보이지 않는 버튼이라면 아무도 클릭하지 않을 것이다.

이 점이 둘 중 어느 게 나은지 간단히 말할 수 없는 이유다 - 화려한 것 혹은 단순한 것. 스스로 알아내야만 한다. 언제나 분리된 테스트를 하라. 화려한 것과 단순한 것 두 가지 버튼을 만들어라. 같은 시간에 두 개를 모두 사용해서 어느 것이 더 효과적인지를 알아보라. Google Website Optimizer가 이런 테스트에 도움이 된다.

단순한 버튼의 간략한 예시.

ThemeFuse

보다시피 어떤 오렌지색 여우도 쓰지 않았지만, 여전히 아주 잘 보인다. 사실 ThemeFuse (내가 속한 프리미엄 워드프레스 테마 스토어)는 shortcodes라 불리는 걸 제공한다. 다른 것도 많지만, 이러한 shortcodes는 멋지게 보이는 버튼 제작을 아주 쉽게 해준다.

한 줄만 사용한 예시:

[button link="domain.com" class="btn_orange"]Click here to buy my awesome product![/button]

내가 얻는 결과:

3. 글꼴

산-세리프 폰트는 모든 종류의 표준이다. 왜냐하면 산-세리프 폰트는 모든 온라인 사용처에서 가독성이 높기 때문이다. (다른 면으로 세리프 폰트는 인쇄 출판용으로 더 좋다)

버튼 위의 카피는 페이지 내에서 가장 중요한 텍스트인만큼, 가능한한 읽기 쉽도록 만들고 싶을 것이다. 모두 대문자를 쓰는 건 좋은 생각이 아니다. 섞어쓰는 것이 훨씬 낫다. 섞어 쓴다는 말은 단어의 첫번째 글자만 대문자로 쓰라는 뜻이다. ("for", "the", "and" 같은 것은 제외하고)

(Image source: Gomediazine)

사용할 수 있는 안전한 글꼴들 몇 개: Arial, Helvetica, Franklin Gothic, Myriad 혹은 그외 어떤 클래식 산-세리프 폰트도. 정말이다.

이제 색상에 대해. 카피는, 당연하게도, 고대비 색상으로 써야 한다. 회색에 회색은 안된다. 흰색에 검은색이거나 오렌지색에 푸른색을 쓰라.

다시 한 번, 텍스트는 가독성이 아주 높아야 한다.

4. 위치

별로 놀랍지 않겠지만, 가장 좋은 자리는 웹사이트의 디자인에 따라 다르다. 그러나 여전히 변치 않는 법칙이 있다.

가능한한 가장 당연한 자리에 놓아라. 이럴 때 창의적으로 하려고 하면 안된다. 고객/사용자에게 당연한 곳에 놓아야 한다.

누군가 웹사이트를 방문할 때마다 일정한 것들은 일정한 자리에 있기를 기대한다. 가령: 로고는 상단 왼쪽 모서리에 있고, 쇼핑 카트는 상단 오른쪽 모서리에 있고, 카피라이트 문구는 하단에 있고, 등등. 당신의 일은 구매 버튼이 있어야할 당연한 자리가 어딘지를 파악해서, 그 자리에 놓는 것이다.

물론, 동시에 가장 잘 보이는 곳이기도 해야 한다. 이건 두 가지를 뜻한다:

무조건 화면이 접히는 지점 상단에 있어야 하고,
여백을 두려워하지 말라. 여백은 모든 좋은 웹디자이너의 친구이다. 명심하라. 웹사이트에 얼마나 많은 것들을 채워넣느냐가 아니라, 얼마나 많은 것을 덜어낼 수 있느냐가 관건이다.

버튼을 반복해서 페이지 하단에 넣는 것만으로도 배치 계획에 큰 힘을 줄 수 있다. 이렇게 하면 누군가 한 페이지를 다 읽고 난 다음에도 여전히 버튼을 실행할 수 있다.

5. 부가 요소

바로 이것이 화룡점정이다. 부가적인 요소는 버튼이 더 돋보이도록 가시성을 강화한다. 예시 요소: 화살, 쇼핑 카트, 돋보기, 더하기 사인 혹은 여러가지 브랜딩 요소.

내가 가장 좋아하는 예시 -파이어폭스 예시- 는 정말 멋진 부가 요소를 활용했다 - (그들의 로고로 알려진) 오렌지색 여우.

부가 요소를 사용하는 첫 번째 규칙은 버튼의 목적을 강조하는 것이다. 일례로, 두 개의 화살표가 아래로 향한 것은 다운로드 버튼으로 딱이다. 쇼핑 카트 아이콘은 장바구니에 담기 버튼으로 잘 어울린다(위의 아마존 예시). 돋보기는 검색 버튼으로 적합하다. 이런 것들은 더 있다.

어떤 브랜딩 요소도 활용할 수 있다. 가령: 표준 RSS 아이콘을 피드 구독 버튼에 사용하고, 새 아이콘을 트위터에서 팔로우하기 버튼에 사용하고, 오렌지색 여우를 파이어폭스 다운로드에 사용하고, 자체 로고를 내 물건 사기 버튼에 사용하는 식이다.

몇 가지 예시:

"무료"의 힘

또 다른 기법은 영어에서 가장 힘있는 단어를 사용하는 것이다 -무료. 언제든 무료라고 광고하면, 사람들은 예측할 수 있는 불합리한 행동을 한다 (내 말이 무슨 뜻인지를 확인하려면 Dan Ariely의 멋진 책 "The Upside of Irrationality"^[각주:1]를 찾아보라)

더 많은 예시:

Freshbooks

Wufoo

Freeagent.com

다음은?

당신이 포토샵이나 다른 비슷한 소프트웨어에 능숙하다면 지금 당장 멋진 버튼을 만들러 가면 된다. 다른 방법으로 이 포스트에서 앞서 말한 것처럼 ThemeFuse가 제공하는 아무 워드프레스 테마를 사용하는 운좋은 사람이 되거나.

국내에는 '댄 애리얼리, 경제 심리학'으로 출간됐다. [본문으로]

직원을 채용할 때 매번 묻는 질문은?

mindfree — Mon, 20 Feb 2012 13:27:06 +0900

원문은 'UX디자이너를 채용하는 방법(How to recruit a UX designer)'. 이 글을 쓰기 위해 인터뷰한 전문가들에게 질문한 것들 중 하나인데, 꽤 인상적이라 소개한다.

모든 (채용)후보들에게 하는 질문이 있다면? (What one question do you ask every candidate?)

프로젝트가 심하게 잘못되었을 때를 설명해 주세요. 왜 잘못되었는지, 그로부터 배운 것은 무엇인지?
: 후보자가 실패에 대처하는 방법을 이해할 수 있다. 후보자가 겸손한지, 실패를 통해 그의 전문적인 능력을 더 발전시켰는지를 알아볼 수 있다.

이번 달에 인터넷에서 본 가장 멋진 것은 뭔가요?
: 후보자가 흥미를 가지고 있다고 말한 것에 실제로 흥미를 가지고 있는지를 알아볼 수 있다. 팀과 프로젝트에 문화적으로 잘 맞을지도 알아볼 수 있다.

무엇이 매일 아침 침대에서 일어나 이 일을 하게끔 하나요?
: 무엇이 후보자에게 동기를 부여하는지 이해할 수 있다. 만약 무엇이 동기부여를 하는지를 직설적으로 물으면 일반적인 답변을 듣겠지만, 질문을 구체적으로 함으로써 보다 정직한 답변을 얻을 수 있다.

당신의 야망(ambition)은 무엇인가요?
: 전문가로서의 단기/장기적인 계획이 있는가를 알아볼 수 있다.

원문: http://uxdesign.smashingmagazine.com/2012/02/16/how-to-recruit-ux-designer/

모서리가 둥근 사각형이 각진 사각형보다 좋은 이유

mindfree — Wed, 18 Jan 2012 18:20:49 +0900

UX Movement 블로그에 실린 글 중 2011년 한 해 가장 많이 읽힌 글, 첫 번째. 간략히 핵심만 간추렸다. 자세히 보고 싶은 분은 이곳을 방문해서 전문을 보기를 권장. 요약본만 보더라도 글을 읽은 후, 원문에 있는 예시 이미지를 보면 이해하기 더 쉽다. 아이폰을 처음 개발할 때 스티브 잡스가 엔지니어의 반대에도 불구하고 아이콘의 모서리를 둥글게 만들어야 한다고 했다는데, 그냥 고집이 아니라 근거가 있다.

출처; http://uxmovement.com/thinking/why-rounded-corners-are-easier-on-the-eyes/

1. 둥근 모서리는 받아들이기 더 쉽다.
뾰족뾰족한 모서리보다 둥근 모서리가 뇌가 정보를 처리하는데 더 쉽다. 모서리가 날카로울수록 밝게 느껴지고, 밝게 느껴질수록 시각적인 정보를 처리하는데 영향을 준다.

2. 우리는 둥근 모서리에 익숙하다.
둥근 모서리리는 보다 자연적으로 인식된다. 아이들은 각진 모서리가 다칠 가능성이 더 큼을 빨리 알아차리고, 둥근 모서리가 더 안전하다는 것도 배운다. 둥근 모서리가 자연에 가까우며, 덜 위험하다는 것은 본능이다.

3. 둥근 모서리가 정보를 처리하기 쉽다.
둥근 모서리는 이동 경로를 부드럽게 따라가는 반면, 각진 모서리를 꺾이는 지점에서 시선이 멈춘다. 각진 모서리를 가진 네모 두 개를 놓으면 네모 바깥에 시선이 초점이 맞춰지고, 두 개를 구분하기 어렵다. 반면 둥근 모서리를 가진 네모 두 개를 놓으면 네모 안쪽에 초점이 맞춰지고, 두 개를 구별하기가 더 쉽다.

결론:
둥근 모서리를 눈이 받아들이기 쉬울 뿐만 아니라, 정보를 처리하는데도 좀 더 쉽다. 둥근 모서리가 보다 어필한다는 것에는 의심의 여지가 없다. 이런 요소들이 사용하고 싶도록 끌어들이는 역할도 한다. 고객에게 둥근 모서리가 더 낫다고 설명할 때, 그냥 보기 좋다고 하지 말고 여기에 나온 이유를 같이 얘기하시길.

모바일 먼저!

mindfree — Wed, 18 Jan 2012 11:12:44 +0900

스마트폰만 있을 때는 그나마 덜했는데, 아이패드를 비롯한 다양한 기기들이 쏟아져나오면서 웹 디자인 업계에 있는 사람들은 여러 모로 골치가 아프다. 스마트폰은 아예 화면이나 작지, 타블렛은 화면 크기는 큰데, 작동은 터치로 한다. 그러니 모바일 사이트를 만들어서 그대로 적용하기도 어렵고, 그렇다고 전통적인 방식대로 데스크탑 사이트를 만들어놓고 타블렛 기기를 맞이할 수도 없다. 진퇴양난?

물론 답은 있다. 최근에 개편한 트위터를 보면 알 수 있는데, 각 요소들을 큼직 큼직하게 만들고(애플이 권장하는 터치 포인팅 영역의 크기는 44x44픽셀이다. 트위터는 딱 여기에 맞췄다), 롤오버 이벤트를 사용하지 않고 모두 '클릭' 기반으로 만드는 등의 디자인 개편을 통해 타블렛에도 잘 대응하도록 만들었다. 그 외에도 각 영역을 모듈화하고, 상단에 집어넣은 '홈, 친해지기' 같은 내비게이션을 모바일 웹과 네이티브 앱에도 그대로 적용함으로써 기기와 상관 없이 동일한 정체성을 가져가도록 했고. 여러모로 꽤 신경을 많이 쓴 모습이다.

이와 관련해서 스매싱 매거진에 글이 올라왔기에, 글 마지막에 있는 팁 부분만 번역했다. 원문에 포함된 예시 이미지 등도 참고할만 하다.

마지막에 나온 팁과 마음에 담아둘 것들(Tips and things to keep in mind)만 간략 번역.

반응형을 생각하라
전체적인 반응형 디자인을 사용하지 않는다 하더라도, 반응형식을 생각하는 것만으로도 쓸만한 유니버셜 디자인에 도움이 된다.
(유니버셜 디자인을 잘 모르면, 제가 쓴 글 하나 소개. http://www.thinkofweb.net/56)
'터치'를 먼저 생각하라
손가락 끝에 맞춰 버튼 크기를 정하면 마우스 커서로도 잘 작동한다. 그러나 마우스 커서를 위한 버튼 크기는 손가락으로 쓰기엔 너무 작다. '터치'를 먼저 생각한 디자인은 웹사이트나 어플리케이션을 다른 맥락에서도 잘 작동하게 할 것이다.
'유니버셜'하게 생각하라
"일찍, 자주 테스트하라"는 말은 여전히 통용된다. 디자인을 진행하면서 당신의 디자인이 여러 기기에서 어떻게 작동할지 일찍, 자주 생각하라.
모바일을 먼저 생각하라
모바일을 먼저 생각하는 디자인은 진짜로 사용자에게 중요한 것이 무엇인지에 촛점을 맞추도록 해준다. 핵심 기능에 계속 초점을 맞춤으로써 여러 기기에 걸쳐 동일한 경험을 제공하는 것이 훨씬 쉬워진다.
조심하라
여 러 기기의 인터페이스에 걸쳐서 적용되지 않는 상호작용에 대해서 조심하라. Hover states(역주: 마우스 오버 이벤트 같은 것)는 터치 기기에서는 작동하지 않는다. 터치 제스쳐는 마우스와는 다르다. 이건 그런 효과를 사용할 수 없다는 뜻이 아니라, 그것의 한계를 알고 있어야만 한다는 뜻이다.

모바일웹 디자인을 할 때 반드시 갖춰야할 5가지

mindfree — Fri, 13 Jan 2012 14:26:47 +0900

최근 온라인 서비스를 기획하면서 데스크탑 버전을 먼저 시작해서, 지금은 모바일 버전을 구성 중이다. 아이폰을 쓰면서 나름대로 모바일에 익숙해졌다고 생각했는데, 천만에, 모바일 버전을 만들다보니 곳곳에 암초와 함정이 깔렸다. 그 와중에 구독하는 블로그에 등장한 반가운 칼럼. 다시 한 번 되짚어 보는 계기로 삼아보자. 언제나 그렇듯 번역 품질을 장담할 수 없으므로, 원본을 읽으시길 권장.
원본: http://tympanus.net/codrops/2012/01/12/5-things-every-mobile-design-should-have/

그렇다, 이러한 모바일 웹 유행이 가까운 시일 내에 사라질 것 같지는 않다. 보다 모바일에 친화적인 웹사이트를 만들어야 한다는 생각이 슬슬 들고 있다. 모바일 웹 디자인이 풀 스크린 웹 디자인과 많이 다르다고 생각하는데, 사실은 그렇지 않다. 스크린이 더 작고, 그걸 터치할 수 있음에도 불구하고, 가장 기본적인 디자인 원칙은 여전히 적용된다. 그러나 모바일 브라우저를 위해 디자인을 할 때 약간의 차이를 보정하기 위해서 생각해볼 것이 몇 가지 있다. 모바일 사이트가 반드시 갖춰야할 5가지를 뽑아봤다.

    1.    의미 있는 내비게이션 Meaningful Navigation
    2.    간추린 콘텐츠 Focused Content
    3.    피드백 Feedback
    4.    명확한 브랜딩 Clear Branding
    5.    넉넉한 여유 공간 Plenty of Space

모든 모바일이 갖춰야 요소가 더 많이 있음을 알지만, 이 5가지 요소가 지나쳐서는 안될 핵심적인 부분이며, 모바일 버전을 디자인할 때 꼭 고려해야할 부분인 듯 하다.

모든 예시는 mobileawesomeness.com에서 가져옴. (역주: 원문에 예시로 들어간 스크린샷은 가져오지 않았습니다)

1- 의미 있는 내비게이션 Meaningful Navigation

모바일 기기에서 이 화면 저 화면으로 이동하는 것은 사실 즐거운 경험이 되어야 한다. 그러니 재미있고 의미있게 만들자. 단지 스크린을 클릭(혹은 탭 하는 횟수)를 줄이는 것만으로는 모바일 앱을 사용하기 쉽거나 보다 의미있게 만들지 못한다. 내비게이션은 사용자가 하고자 하는 행위에 대한 것이어야 하며 그 일을 해내도록 분명한 이동 경로를 제공해야 한다. 어디로, 무엇을 위해 이동하는지만 안다면 모바일 사용자는 (기꺼이) 한 두번 더 탭(화면을 터치) 할 것이다.

우선 내비게이션이 시각적으로 클릭할 수 있는 것처럼 보이게 하는 걸 명심해야 한다. 내비게이션을 버튼이나 목록, 심지어 '손가락으로 꾹 잡을 수 있을 것 처럼' 보이도록 그래픽으로 박스 모양을 씌워두는 것이 훨씬 낫다. hover state(역주: 마우스를 올렸을 때 변하는 시각 효과 같은 것)나 제목 태그 같은 사용자를 돕는 보조도구를 사용할 수 없으므로, 내비게이션은 누를 수 있는 것처럼 보이게 만들어야 한다.

레이블은 아주 중요하며, 사용자에게 의미가 있도록 해야 한다. 모든 사람이 '뒤로'의 뜻을 알고 있으니, 그걸 사용하라. 몇 번의 탭이 필요한 경로를 갖고 있다면, '이전 페이지로' 같은 제목과 함께 뒤로 이동하는 버튼을 쓰는 대신 그냥 '뒤로'라고 이름을 붙여라. 레이블을 단순하고 의미있도록 유지하라. 또한 'about' 이나 'info' 처럼 대체 뭘 하는 것인지도 모르는 뭉뚱그려놓은 항목은 사용하지 말아야 한다. 이것들이 사용자를 함정에 빠뜨릴 수 있다. 적은 내비게이션이 사용하기 쉽다는 뜻이 아님을 명심하라. 그러니 '내 프로필'이나 '비밀번호' 같은 내비게이션 버튼을 별도로 추가해 두는 것이 이들을 '설정' 아래에 묻어두는 것보다 낫다.

아이콘은 쉽게 뜻을 전달하는 아주 좋은 방법이다. 휴대폰으로 글을 읽는게 어렵거나 너무 많은 시간이 걸리기 때문이 아니라, 그래픽이 보다 시각적 균형을 잘 표현하기 때문이다. 모바일은 쓰기에 재미있고, 잘 만들어진 아이콘은 사용자 경험을 전반적으로 향상시켜 준다. 여기에 더해 명확한 레이블이 붙은 아이콘은 사용자에게 더 의미 있고, 분명한 내비게이션 경로를 제공한다.

2- 간추린 콘텐츠 Focused Content

단지 탭을 없애는 것이 일을 쉽거나 빠르게 해주지 못하고, 단순히 콘텐츠를 없애는 것이 모바일 웹사이트를 쓰기 쉽도록 해주는 것도 아니다. 웹사이트에 있는 콘텐츠를 모바일 사이트에서 지워버리는 것이, 사용자가 필요하거나 원하는 콘텐츠를 지우는 것일 수도 있다. 콘텐츠에 초점을 맞춰야 하며, 이것이 웹사이트와 모바일 사이트를 보다 낫게 만들어줄 것이다. 중요하지 않은 콘텐츠를 지우는 대신, 재편성하거나 다른 의미를 부여하라. 모바일 디스플레이의 큰 영역을 차지하는 커다른 텍스트 뭉치를 치워버릴 수도 있겠지만, 모두가 읽기 쉽도록 만들기 위해 불렛(bullets)이 붙은 작은 문단으로 용도를 바꿔라. 또한 인용구, 선 혹은 다른 디자인 요소로 가득찬 큰 텍스트 영역을 잘게 쪼개면, 큰 텍스트 덩어리를 보다 즐겁게 읽을 수 있도록 해준다. 큰 덩어리의 콘텐츠를 지우는 대신, 보다 작은 조각으로 쪼개라.

텍스트 요소를 보완하는 비주얼 요소를 사용할 때 고려할 점:
    • 제목 텍스트 옆에 타이틀 아이콘 사용하기
    • 단순히 날짜를 나열하는 대신 그래픽 요소 사용하기
    • 설명하고자 하는 것을 강화하는 작은 인포그래픽 사용하기
    • 글꼴 크기로 구분하는 대신 서로 다른 본문/제목 색상 사용하기
    • 각각 다른 콘텐츠 요소를 정의할 때 밝은 배경색 사용하기
    • 중요한 영역을 강조할 때 하일라이트 사용하기
    • 본문을 강조하거나 구별할 때 간격이나 네거티브 영역(역주: 문단 뒤에 어두운 배경색을 둬서 글꼴 색상을 밝게 표시하는 것) 사용하기
    • 큰 콘텐츠 덩어리를 잘게 쪼갤 때, 다른 '형식(views)' 사용하기

사용자는 여전히 당신의 콘텐츠를 원하니 그것을 제공하되, 보다 접근하기 쉽도록 (데스크탑 웹사이트와는)다른 시각적 매커니즘을 사용하라.

3- 피드백 Feedback

그렇다, 이것 모바일 웹사이트 뿐만 아니라 모든 웹사이트에서 중요하다. 사용자 피드백은 아주 큰 부분이고, 특히 모바일에서는 도움을 받을 수 있는 브라우저 보조도구가 없기 때문에 더욱 중요하다.

hover states(역주: 마우스 오버 이벤트 같은 효과)나 애니메이션 같은 브라우저 피드백 보조도구가 모바일 터치 기기에는 존재하지 않는다. 모바일 기기는 터치하기 전까지는 아무런 변화가 없다. 그러니 뭔가를 터치하면 '이것을 터치했다'는 효과나 움직임을 명확한 피드백으로 제공하는 것이 매우 중요하다. 사용자는 터치할 수 있는 목록이나 아이템이 있어서 그것을 터치하면, 실제 생활에서 뭔가를 만졌을 때 얻는 것과 동일한 반응을 기대할 것이다.

일례로 ATM 기계를 터치하면 기계로부터 두 세가지 형식의 피드백을 받게 된다. 디스플레이가 어떤 모습으로든 시각적으로 반응할 것이고, (기계가 만들어낸 소리든 아니면 실제로 뭔가 부딪혀서 나는 소리든 간에) 버튼은 약간의 소리를 내고, 내 손 끝으로 차가운 금속 버튼을 느낄 수 있게 된다. 이것이 내가 뭔가를 했다는 걸 기계가 나에게 일깨워주는 방식이다. 대부분의 모바일 기기에서는 하나의 선택안밖에 없다. 바로 시각적인 반응이다. 사용자의 행위에 대응하는 시각적 피드백 매커니즘을 고려해야 한다.

    • 이미 선택했거나 활성화된 영역을 색상을 써서 표시하기.
    • 한 요소에서 다른 요소로 이동할 전환할 때 나타나고 없어지는 애니메이션 사용하기
    • 터치할 때 희미한 색깔과 글라디언트 효과 사용하기
    • 다른 형식의 버튼이나 텍스트 색상으로 상태값이 변하는 걸 표시하기
    • 드롭 다운 메뉴를 선택하면 회전하는 화살표 모양(역주: 드롭다운 메뉴 옆의 ►▼를 뜻하는 듯)으로 표시하기
    • 변화하는 모습을 표현하는 데 슬라이드나 사라지고/나타나는 애니메이션 사용하기

4- 명확한 브랜딩 Clear Branding

디자인 지식과 기술을 내세워서, 믿을 수 없을 정도로 환상적인 웹 디자인을 디자인하는 것 만큼이나 그 어떤 디자인에서도 가장 중요한 요소 중 하나는 브랜딩이다. 브랜딩을 잊으면 안된다. 모바일 기기의 실제 크기에서 오는 한계에도 불구하고 끊임 없이 브랜드를 내세우는 것을 잊으면 안된다. 언제나 회사 로고를 넣을 공간은 있기 마련이다.

어느 회사든, 어떤 어플(App)이든 브랜딩 요소를 표현하는 많은 방식이 있다. 그러나 브랜드를 명확히 하는 로고/마크와 회사를 상징하는 색상 배열, 이 두 가지가 핵심이다. 모바일 웹 디자인에서는 이런 요소를 분명히 드러내는 것이 매우 중요하다. 로고가 자리잡는 방식은 풀 스크린 버전과는 다를수도 있고 웹 어플리케이션의 홈에만 보일 수도 있다. 바로 이 점이 어플리케이션 전반을 관통하는 브랜드를 표현하기 위해 색상을 잘 배열하는 것이 중요한 이유다.

또 다른 작은, 하지만 고려해볼 할 중요한 것은 모바일 브라우저는 사이트 제목이나 파비콘을 표시하는 주소창이나 제목창이 없다는 것이다. 풀 스크린 브라우저에서는 이런 작지만 중요한 세부 요소가 사용자가 어디에 있으며, 어디를 지나쳐 왔는지를 알 수 있도록 해준다. 모바일 기기는 제목창이나 주소창이 없어서 사용자가 단지 위를 올려다보는 것만으로 어느 사이트에 있는지 알 수 없기 때문에, 브랜드를 디자인하는 것이 더욱 중요하다.

5- 넉넉한 여유 공간 Plenty of Space

작은 화면 크기만 생각하는 바보 같은 짓은 하지 마라. 여전히 여백은 필요하다. 여백은 어떤 좋은 디자인에서든 디자인의 핵심 요소이다. 오히려 풀 사이즈 디자인보다 모바일 디자인에서 여백이 더 중요한데, 사용자가 어찌해볼만한 공간이 얼마 없기 때문이다. 모바일 디자인이 효과적이고 사용하기 쉽고 읽기 쉽기 위해서는 모든 디자인 요소(버튼, 내비게이션, 아이콘, 텍스트 등)이 분명하게 구별되어야 하고 적절히 구획되어야 한다.

보다 좋은 사용자 경험이 여백을 위해 콘텐츠를 제한하는 것을 뜻하지는 않으며, 읽기 쉽도록 하기 위해 커다란 글꼴을 사용하는 것을 뜻하지도 않고, 제한된 화면 크기를 위해서 간격을 주지 않아야 한다는 뜻도 아니다. 모바일 웹사이트는 커다란 화면을 디자인 할 때보다 더 많은 UI 계획이 필요하다. 여백은 효과적인 사용자 경험에 아주 중요한 역할을 한다.

보다 나은 사용자 경험을 만들기 위해 이런 방법을 생각해보라:
    • 따닥 따닥 붙은 커다란 글꼴 말고, 보다 많은 여백으로 둘러싼 더 작은 글꼴을 사용하라.
    • 텍스트 블록이나 아이콘을 둘러싼 박스에 충분한 간격을 사용하라.
    • 각각의 요소를 분명히 분리하는 충분한 여백이 적용된 명확한 그리드를 사용하라.
    • 충분한 간격을 두고 모든 요소를 둘러싸고, 각 요소를 서로 맞닿지 않고, (실수로) 터치할 수 없을만큼 떨어뜨려라.

브레인스토밍의 장애물 뛰어넘기

mindfree — Fri, 06 Jan 2012 14:13:14 +0900

브레인스토밍의 단점을 지적하는 사람도 많습니다만(가장 대표적인 경우가 '집단사고'로 들어가버리는 거죠. 한 명의 의견에 매몰되거나, 획일화되는 것을 말합니다), 여전히 브레인스토밍을 장려하는 사람들이 많고 또 장려할만 합니다. 특히 IDEO 같은 회사에서는 브레인스토밍을 아주 중요시하고, 강조한다더군요. (이 회사에서 출판한 책도 있습니다)

구독하는 블로그에 브레인스토밍에 대한 글이 올라와서 간략히 정리해봅니다. 전체 원문은 이곳에서 읽을 수 있습니다.

브레인스토밍의 장애물 뛰어넘기(Jumping the hurdles of Brainstorming) 작성자 Patrick Cox

해결해야 할 문제를 반복해서 적으라:
브레인스토밍을 시작하기 전, 시작한 이후 문제를 반복해서 종이에 적으라. 브레인스토밍을 진행하는 동안 다른 생각이 들면 다시 적으라. 이렇게 하면 문제해결법을 찾거나 혁신적인 아이디어를 끌어낼 때 애초의 목적을 놓치지 않도록 해준다.

어처구니 없는 아이디어를 적으라
브레인스토밍을 시작할 때, 생각해낼 수 있는 가장 멍청한 아이디어를 적으라. 브레인스토밍에서는 아이디어가 또 다른 아이디어를 끌어내기 때문에, 바보같은(silly) 아이디어나 이상한 컨셉을 적는 것이 이 과정에 도움이 된다. 이런 웃긴 아이디어를 단순히 웃어넘기지 말고 계속 발전시켜라. 진정한 혁신은 다른 생각에서부터 온다.

펜을 이용하라.
공간이 부족해서, 이상해서 등의 여러 이유로 이미 생각해낸 아이디어를 지우는데, 그러지 못하도록 펜으로 적어라. 가장 멍청한 아이디어라도 가장 놀라운 아이디어로 발전할 수 있다.

스스로 약속을 잡고 스케쥴을 정하라.
브레인스토밍은 프로젝트의 다른 일만큼 중요하다. 그러니 스스로 일정표에 브레인스토밍 일정을 넣고, 스스로 고객이 되어 진행하라. 일정을 계획하고 마치 프로젝트 매니저와 만나는 것처럼 대하라.

시간 제한을 하라.
하루 종일 아이디어를 찾아내는 데 쓸 필요는 없다. 30분에서 1시간 정도의 시간으로 진행하거나 세션을 나눠 진행하라. 현실적인 시간을 설정하라. 효과적인 세션은 굳이 긴 시간이 필요한 것이 아니다.

평가하라.
브레인스토밍이 끝난 뒤에 평가하는 시간을 들여라. 브레인스토밍 직후에 하지 말고, 가능하면 다음날 진행하는 것을 권장한다. 그 전날 남긴 많은 아이디어는 컨셉도 여러 가지이고, 마구 엉켜있을 수도 있다. 하지만 불필요한 아이디어라 판단하더라도 삭제하지 말라. 단지 더 괜찮아보이는 아이디어에 형광색을 칠하거나, 동그라미를 쳐서 표시하라. 가끔은 서로 연관없어 보이는 아이디어를 한데 모아서 보라. 몇 개의 컨셉에만 집중하는 것을 막아준다.

아이디어가 막힐 때
어떤 것도 떠오르지 않을 때가 분명히 온다. 그럴 때 도움이 되는 팁.

예수님이라면 어떻게 했을까? 예수님이 아니라도 역사적으로 유명한 인물 아무나 괜찮다. 그 사람이라면 이 일을 어떻게 해결했을지 생각해보라. 관점을 바꾸는 것은 문제를 다른 각도에서 볼 수 있도록 도와준다.
스스로에게 무제한의 예산을 부여해보라. 시간, 예산 같은 현실적인 문제를 모두 잊어버리고 아이디어를 생각해보라. 자유는 당신을 보다 창의적이 되도록 도와준다. 진짜 혁신적인 해결책을 찾아낸 다음에 예산을 고민해도 된다. 혹시 알아? 아이디어가 정말 좋아서 투자를 받을만할지.
상위 10개를 적으라. 문제를 해결할 수 있는 10개의 해결책만 적으라. 생각이 막혔을 때 목표를 제시해준다. 그러나 잊지 말아야 할 것은 가장 어처구니 없는 아이디어도 포함해서 적으라는 거다. 정말 기발한 아이디어로 발전할 수 있다.
주변을 둘러보라. 생각이 완전히 막혔다면 주위를 둘러보라. 주위 사물을 무작위로 골라서 -연필, 캐비넷, TV, 카페트, 쓰레기통 같은 것들- 이것을 이용해서 문제를 해결한다면 어떻게 할지 생각해보라. 생각을 잠시 흐트러놓을 수 있지만, 문제를 다른 관점에서 볼 수 있도록 도와준다.

쉬운 것이 더 좋은 것보다 낫다

mindfree — Tue, 29 Nov 2011 12:16:20 +0900

오역이 수두룩할 겁니다만, 원문을 읽는 것보단 오역 가득한 한글이 낫다는 분만 읽으세요. ^^;

원문: http://www.smashingmagazine.com/2011/11/28/easier-is-better-than-better/

Barry Schwartz는 그의 책 '선택의 패러독스'에서 인간의 선택에 대한 흥미로운 결론을 내놨다.

사람들은 무엇이 가장 중요한지를 판단해서 선택하는 것이 아니라, 가장 평가하기 쉬운 것을 선택한다.

상식적으론 당신이 선택지를 받아들면 당신에게 가장 중요한 것을 선택하는 것이 맞겠지만, 실제 사람들은 가장 이해하기 쉽고, 평가하기 쉬운 것을 선택하곤 한다. 우리는 아주 자주 그러곤 하는데, 왜냐하면 주어진 선택지를 들고 무엇이 필요한지를 찾아볼만한 시간이 없기 때문이다. 사람들이 정치인의 배경과 정책에 대해 조사한 후 그걸 기초로 정치인을 당선시키는 경우는 드물다. 사실 정치인들은 그들이 퍼뜨리는 메시지를 우리가 전에 들어봤다는 이유로 당선된다.

우리가 디자인을 할 때, 우리는 사람들이 다음 단계에 뭐가 올지 잘 아는 상태에서 결정을 내린다고 가정한다. 어쨌거나 그들은 남은 하루 동안 우리가 만든 디자인보다 더 중요할 것 같은 결정을 400개가 넘게 하고 있다.

거의 모든 사람들이 오토매틱 차량 대신 수동 기어를 사용할 때 얻는 혜택을 알고 있다고 생각하는가? 그 사람들이 그걸 신경쓸 거 같은가? 오토매틱을 더 쉽게 택할 수 있는데 다른 선택을 할 이유가 있을까?

'인앤아웃버거'에 가본 적이 있나? 나는 그 가게의 전설적인 버거와 감자튀김에 대한 멋진 이야기를 들은 적이 있다. 거기엔 단 몇 개의 메뉴만 있다고 한다. 거기선 더블 더블 치즈버거나 햄버거만 주문할 수 있는데, 원한다면 감자튀김이나 밀크쉐이크 혹은 음료수를 추가할 수는 있지. 당신이 가진 옵션은 그게 전부다. (비밀메뉴를 알고 있는게 아니라면 말이지) 지금은 나도 거기 가서 먹어봤고, 맛도 괜찮았다고 생각하지만, 그렇다고 '웬디스'와 그닥 다른 것 같지는 않았다. 이 가게가 가진 장점은 당신의 선택권이 제한적이라는 데 있다. 어떤 치킨 샌드위치가 가장 좋은 선택일지 따위를 고민할 필요가 없기 때문에 여긴 주문하기가 쉽다. '인앤아웃'에서는 패스트푸드를 먹는 것을 아주 쉽게 만들어준다.

Woot.com은 살짝 꼬인 온라인 상점이다. 수백 수천가지의 상품을 판매하는 대신, 하루에 딱 한가지 상품만 제안한다. 마음에 들면 사고, 그렇지 않으면 사지 말고 내일 어떤 상품이 올라올지 기다리면 된다. 이 가게의 성공과 판매방식은 뭔가 거꾸로된 것처럼 보인다. 어쨌거나 내가 만약 가게를 운영한다면 말이지, 하나의 상품을 100개 팔든 100개의 상품을 하나씩 팔든 다를 게 있나? woot.com은 우리의 선택을 단순히 '예'와 '아니오'로 만들어서 쇼핑 경험을 아주 쉽게 만들어줬다.

앵그리버드가 매 단계마다 꼭 새를 선택하도록 만들었다면 재미가 줄어들지 않았을까? 그런 선택권 따윈 날려버리고 새를 어떻게 사용하는지에만 집중한 것이 게임을 더 재미있게 만들었다.

단순히 직장에서 똑같은 컴퓨터를 쓴다는 이유로 집에서 쓸 컴퓨터로 같은 제품을 사는 사람들이 몇 명쯤 될까? 그 컴퓨터를 직장에서 사용하면서부터 사용하기 쉬워진 것이다. 그게 더 나은 컴퓨터라서가 아니라, - 그 컴퓨터는 쓰기에 가장 쉬울 뿐이다. 우리가 늘 최선을 택하는 것은 아니다- 컴퓨터는 그냥 적당히 쓸만한 것이면 된다.

다른 사이트가 사용하기는 어렵지만 더 좋은 기능이 있다는 이유로 깊은 인상을 받은 적이 몇 번이나 되나? 설령 그들이 더 많은 기능을 갖고 있다 하더라도 사용하기 어렵다면 바꿀 이유가 없다. 그 기능이 내 삶을 더 쉽게 만들어주지 못한다면, 나한테 좋은게 뭐지?

이미지 호스팅이 단순했을 시절의 승자는 등록하거나 로그인하지 않고 사진을 업로드할 수 있도록 했다. 그냥 사진을 업로드하면 끝이었다. 'Imgur'는 이런 사이트의 아주 좋은 예이고, 지금은 세계에서 가장 유명한 이미지 호스팅 사이트가 되었다. 이것이 플리커 같은 사이트가 성장하지 못한다는 뜻은 아니다 - 그들은 더 많은 사용자를 모으기 위해 더욱 노력했고, 회원가입이라는 귀찮은 상황을 이겨낼만큼의 가치를 보여줬을 뿐이다.

사용자 설정과 선택

최근 기사를 보면 Jared Spool은 오직 5%의 사용자만이 MS워드의 기본값을 바꾼다는 것을 알아냈다. 나 같은 컴퓨터 광의 입장에서는 아주 놀라운 일인데, 나는 내가 사용하는 모든 어플리케이션의 설정값을 내가 갖고 놀기 쉽도록 바꾸는 걸 좋아하기 때문이다. 대다수의 사람들은 이렇게 하는 걸 좋아하지 않는 것 같다. 그들은 그냥 그 어플리케이션을 쓰고자 할 뿐이다.

사용자에게 설정을 바꿀 수 있는 기능을 제공하는 것은 좋은 일이지만, 설정값이 꼭 갖춰야할 기능은 아니다. 잘 작동하는, 끝내주는 제품을 만드는 것이 일순위이고, 어떤 설정값이 수정될 것인지를 알아낸 후에 설정 패널을 추가하는 것을 생각해야 한다.

사용자는 당신이 그들이 즉시 사용할 수 있는 최적의 세팅값으로 제품을 제공했다고 추측한다. 만약 그렇지 않다면 그들은 당신의 제품을 실패작으로 볼 것이다.

선택의 패러독스

'선택의 패러독스'에서는 많은 선택안을 제공할수록 선택하기 어려워진다고 한다. 일례로, 무료 잼 샘플이 가게에 전시됐을 때, 24개의 제품이 있는 경우보다 6개의 제품이 있는 경우 사람들이 잼을 사는 경우가 더 많았다. 많은 선택권이 사람들이의 선택 과정을 쉽게 만들지는 못한다. 그러나 아무런 선택권이 없는 것은 그들이 가졌다고 생각하는 선택의 자유를 없애버린다.

새로운 아이폰을 사려고 생각할 때, 당신은 그냥 검은색이냐 흰색이냐와 3가지 다른 메모리 종류만 선택하면 된다. 몇 개의 통신사가 추가되면서 선택이 조금 더 복잡해지기 시작했지만 말이다.

고객이 당신에게 당신이 원하는 어떤 방향으로든 디자인을 해도 좋다고 얘기하는 것은 제한이 있는 상태에서 디자인하는 것보다 더 어렵다. 당신의 선택안이 끝이 없기 때문이다. 우리는 모든 일을 하기 위해 제한이 있고, 범위가 정해진 선택안이 필요하다. 이것이 결정을 쉽게 만들어주고, 쉬운 결정이 사용하기 쉬운 디자인을 만들어준다.

어떻게든 당신이 가장 쉽고 가장 좋은 제품을 만든다면, 당신은 승리자가 된다. 주어진 매일 매일 우리가 얼마나 많은 선택을 해야 하는지를 생각하고, 고객이 선택해야 하는 것을 줄이는데 최대한 관심을 둬야 한다. 그렇게 해야만 당신의 제품이 고객들이 하루에 결정하는 가장 중요한 결정이 되지 않을 가능성이 있기 때문이다.

평가하기 쉬운 디자인(선택해야 하는 옵션이 적은 디자인)을 만든다는 것은 승리하기 쉬운 제품이 된다는 뜻이다. 당신의 카피를 핵심에 바로 찔러넣어라. 핵심이 아닌 그래픽에 시간을 낭비하지 말라. 웃긴 티셔츠와 범퍼 스티커가 효과적인 이유는 그것들이 평가하기 쉽기 때문이다. 아침마다 입고 나갈 옷을 고르는 것도 쉽지 않은 판에 250개의 기본 아바타 디자인 중에 내가 사용할 걸 고르게 만들지 말라.

프로토타입과 페이퍼 목업을 만드는 이유

mindfree — Thu, 24 Nov 2011 15:21:19 +0900

제가 다니는 회사 블로그에 기록하는 개발일기입니다. 원문은 여기. 참고로 이 글은 별도 CCL을 적용합니다.

지난 글에 서 왜 우리가 폭포수 방식을 버리고, 다른 방식을 선택하기로 마음 먹었는지, 그 이유를 적었습니다. 그 때 폭포수 방식이 가진 중대한 결점을 하나 언급했죠. 바로 '프로토타입의 부재'입니다. 어떤 분들은 디자인 시안을 프로토타입이라 생각하기도 합니다. 제가 가진 지식이 많이 모자라서 디자인 시안도 프로토타입으로 봐야 하는지는 잘 모르겠습니다만, 우리가 추구하고 말하는 프로토타입은 '작동하는' 프로토타입니다. 이 단어가 핵심입니다. 작동하는.

웹은 인터랙티브(interactive)한 매체입니다. 사용자와 상호작용을 한다는 얘깁니다. 링크를 클릭하면 화면이 이동하고, 뭔가 버튼을 누르면 글이 등록되든, 이전 화면으로 돌아가든, 뭔가가 튀어나오든 아무튼 사용자의 움직임에 따라 반응을 합니다. 그것도 실시간으로 말이죠. (실시간. 이 단어가 또한 우리가 만드는 서비스의 중요한 키워드이기도 합니다) 저는 사용자의 움직임에 반응을 하지 않는 프로토타입은 아무런 가치가 없다고 봅니다. 잘 만들어진 디자인 시안은 시각적인 쾌감을 줍니다. 마치 실제로 뭔가 작동하는 서비스를 만든 것 같은 환각을 주기도 합니다. 하지만요, 그건 화면설계와 다를 게 하나도 없는, 종이쪼가리에 불과합니다. 물론 일종의 '청사진'으로 쓸 수는 있습니다만, 그 이하도 그 이상도 아닙니다. 디자이너가 근사하게 뽑아낸 디자인 시안을 종이에 프린트하거나 화면에 펼쳐놓은들 그걸로는 아무런 기능도 확인할 수 없으니까요.

그래서 저희는 일단 프로토타입을 만들기로 했습니다. 그렇다고 무작정 코드를 타이핑할 수는 없지요. 최소한의 방향은 필요합니다. 그래서 나온 결과물이 '단 한 장의 기획안'입니다. 이 기획안에는 서비스를 구성하는 각 기능을 간략히 기재했습니다. 이걸 두고 팀원들이 둘러앉아 포커를 쳤습니다. (어떤 포커를 쳤는지 궁금하신 분들은 이 글을 참조하세요) 며칠간 포커를 치면서 대략적인 할 일 목록(Task)를 뽑아냈습니다. 여기서 중요한 것은 할 일 목록을 뽑아낸 것이 아닙니다. 그 과정에서 각자 생각하는 '논리 실험'을 주고 받는 것이 중요합니다. 개발자A는 '이 기능을 이렇게 받아들였고, 그러므로 이렇게 구현하고, 그러니 이렇게 시간이 걸릴 것이다'고 말하고, 그 말을 들은 나머지 사람들이 각자 자신이 생각하는 걸 이야기합니다. 때론 일치하고 때론 전혀 다릅니다. 포커를 치는 동안 '천 명의 사람이 있으면 천 개의 생각이 있다'는 걸 배웁니다. 아울러 포커를 칠 때는 하루에 8시간 일한다고 생각하면 안됩니다. 물론 '예측'이니만큼 의미가 좀 덜할 수도 있습니다만, 아무튼 하루에 4~6시간을 일한다고 생각하고 일정을 산정하는 것이 좋습니다. 왜냐구요? 저도 하루에 8시간을 일해본 경험이 없습니다. 불가능해요.

포커를 치고난 뒤부터는 2주 단위로 이터레이션을 합니다. 이터레이션을 시작하는 날에는 각 개발자들이 포커의 결과물로 만들어진 일감을 선택해서 '이번 이터레이션에서는 이걸 하겠다'고 발표합니다. 이 사이에 중요한 일 하나가 더 있는데, 바로 '일감 쪼개기'이죠. 한 장짜리 기획안에 들어 있는 기능들은 큰 덩어리일 가능성이 높습니다. 이 덩어리를 잘게 쪼개지 않고 그대로 진행하면 기간만 조금 줄어들 뿐 별로 달라질 것이 없죠. 그래서 이 덩어리를 조금 잘게 쪼개서 일감을 등록해놓습니다. 잘게 쪼갤수록 좀 더 현실에 가까워지고, 구현할 방법을 찾아내기도 수월합니다. 그 결과 관리하기도 쉽죠.

이렇게 쪼개진 일감을 각자 선택하면서 또 다시 예상 시간에 대한 이야기가 나오기 마련입니다. 왜 그럴까요? 우리가 포커 게임의 결과로 일감을 만들고, 예상 시간을 산정하기는 했지만 그것 역시 논리 실험에 지나지 않습니다. 그 일감 중 몇 개를 골라서 실제로 구현을 하다보면 일을 시작할 때는 발견하지 못한 장애물이 등장하기 마련입니다. 누누히 얘기합니다만, 어떤 방법론을 사용하든 이렇게 실제로 구현을 해봐야만 발견되는 장애물을 예상하고 일정에 포함하지 않으면 백전백패합니다. (그래서 버퍼를 넣는다, 고 할테지만, 글쎄요. 그 '버퍼', 제대로 버퍼 노릇을 하던가요?)

이터레이션이 진행되는 동안 저(기획자)는 뭘 할까요? 더구나 전통적인 화면설계(스토리보드)는 만들지 않는다고 했으니 말이죠. 아울러 우린 흔히 하듯이 엑셀이나 프로젝트 관리 툴로 WBS를 만들지도 않습니다. 저는 이 때 목업(Mockup)을 만듭니다. 제가 목업을 만들기 위해 사용한 툴은 발사믹(Balsamiq Mockups)입니다. 굳이 이런 툴을 사용하지 않고, 그냥 펜으로 종이에 그려서 만들어도 됩니다. 저 역시도 펜으로 종이에 목업을 그리기도 했습니다.

제가 그린 페이퍼 목업.

목업을 만드는 이유는 개발자들의 이해를 돕기 위해서입니다. 전체 일감을 쪼개어 등록해두고 개발을 시작하지만, 실제로 일을 하다보면 시야가 좁아질 수 있습니다. 아울러 기능을 작은 단위로 잘게 쪼개어 개발을 하기 때문에 내가 지금 만들고 있는 기능이 다 합쳐졌을 때 어떤 모습으로 구현되느냐에 대한 이해를 명확히 할 필요가 있습니다. 목업을 만들어서 이를 좀 더 이해하기 쉽게 하고, 아울러 모든 이들이 같은 결과물을 예상하도록 하는 거지요.

굳이 손으로 그린 목업을 다시 컴퓨터를 이용해 만든 이유는 배포하기 쉽기 때문입니다. PDF파일로 만들어서 구글Docs 같은 곳에 올려두면 언제라도 찾아볼 수 있으니까요. (물론 손으로 그린 뒤에 스캔을 해서 이미지 파일로 만들어도 좋겠지요) 다른 목업 툴도 많은데, 발사믹을 선택한 이유가 바로 여기에 있습니다. 목업이 너무 정교하면 마치 화면설계처럼 거기에 갇힐 우려가 있습니다. 목업을 통해 생각을 발전시켜야 하는데, 목업이 생각의 종결점이 되면 안되잖아요. 그래서 적당한 툴을 찾다가 발사믹을 선택했죠. 발사믹의 장점은 마치 손으로 그려놓은 것 같은 구불구불한 선입니다. 안타깝게도 한글은 서체 지원이 잘 안되서 딱딱한 고딕 계열의 서체를 써야합니다만. (아 그러고보니 이걸 개선해달라고 요청한다는 걸 깜빡 잊었네요.) 너무 정교하지 않으면서도 간편하게 제가 생각하는 모습을 스케치해서 팀원들과 공유할 수 있지요. (실제로 써보시면 아실텐데, 발사믹 목업은 기존 폭포수 개발방식에는 사용할 수 없을 겁니다.)

목업은 주요 화면 몇 개와 중요한 기능에 대해서만 만들었습니다. 이 과정에서 사실 '차라리 이걸 화면설계로 해버릴까' 하는 마음과 '이렇게 자꾸 하다보면 이게 화면설계가 되겠는데?' 하는 마음이 교차했습니다. 그래서 대표적인 화면 목업이 나온 뒷부터는 더 이상 목업을 만들지 않습니다. 그러나 앞으로도 페이퍼 목업은 계속 만들 듯 합니다. 특히 새로 합류하게 되는 디자이너와 의견 교환을 위해서 말이죠.

이터레이션 선정 회의 혹은 개발 과정에서 나타난 이슈를 해결하기 위한 회의를 진행해보면 재밌는 현상을 목격할 수 있습니다. 제가 10년 넘도록 이 일을 하면서 정말 희귀하게 목격한 현상입니다. 개발자가 새로운 아이디어를 제공하기 시작해요. 때론 그것이 오류를 해결하기 위한 차원일 때도 있으나, 많은 경우 좀 더 나은 사용자 경험을 제공하기 위해서입니다. '이렇게 하면 더 좋은 서비스를 제공할 수 있다'는 생각으로 아이디어를 제시하는데, 어떤 때는 그 아이디어로 개발자의 일이 훨씬 더 어려워지기도 합니다. 그럼에도 개발자들은 꾸준히 좋은 아이디어를 제시합니다. 이것이 바로 일정에 사람을 짜맞추는 개발 방식으로는 절대 얻을 수 없는 소득입니다. 만약 내가 낸 아이디어가 내 짐으로 돌아오면 아무도 새로운 아이디어를 내지 않을 겁니다. 개발자는 아이디어와 그 아이디어를 실현할 수 있는 능력을 동시에 가진, 흔치 않은 집단입니다. 이 집단의 창의력을 살려줘야 서비스가 발전합니다.

2주간의 이터레이션이 종료하면 모두 모여 앉아 이번 이터레이션에 만든 프로토타입을 사용해봅니다. 비록 아직은 많이 엉성하지만, 실제로 작동합니다. 링크를 클릭하면 이동하고, 로그인도 되고 회원가입도 됩니다. 몇 차례의 이터레이션이 지난 지금은 작동하는 기능이 제법 많습니다. 이렇게 하면 어떤 장점이 있을까요? 무엇보다 오류가 발생할 경우 그걸 발견하기가 쉽습니다. 우리는 프로젝트 막판에 가서 한 번 크게 실패하는 방식을 택하지 않고, 몇 주 단위로 지속적으로 작게 실패하는 방식을 택했기 때문입니다. 뭔가 잘못되었거나 작동하지 않으면 바로 알 수 있습니다.

웹 개발 프로젝트는 왜 실패하나, 두 번째 글

mindfree — Mon, 07 Nov 2011 10:03:10 +0900

이 글은 회사 블로그에 등록한 글입니다. 개발 일기는 계속... 참고로 이 글은 별도의 CCL을 적용합니다.

지난 글에 이어.

지난 글에서 기존의 웹 개발 방식이 포드식 대량생산방식과 일맥상통하는 면이 있으며, 포드식 대량생산방식이 완전해지기 위해서는 어떤 조건이 필요한지를 얘기했습니다. 웹 개발 프로젝트에서 기존의 방식을 유지하기 위해서는 설계 단계에서의 완벽성이 보장되어야 합니다. 그러나 이 점이 큰 함정입니다.

웹 개발 프로젝트에서 그 사이트의 최종 결과물을 그려내는 사람은 기획자입니다. 고객(내부고객이든 외부고객이든)의 요구사항을 받아 그것을 (흔히 스토리보드라고 부르는)화면설계로 구체화합니다. 그 다음 이걸 기준으로 고객의 승인을 받죠. 고객 승인이 끝났다는 말은 이 화면설계대로 개발하기만 하면 모든 사람이 행복해진다는 뜻입니다. 여기엔 결정적인 전제가 있습니다. 바로 ‘화면설계가 완벽해야 한다’는 것이죠. 그러나 안타깝게도 완벽한 화면설계란 우리의 현실에는 존재하지 않습니다. 제 여자친구처럼요.

왜 완벽한 화면설계가 존재하지 않느냐. 답은 간단합니다. 화면설계는 종이쪼가리에 불과하기 때문입니다. 웹 개발 프로젝트의 결과물은 실제로 작동하는 제품입니다. 사용자가 글을 읽고, 무언가를 입력하고, 버튼을 누르고, 결과를 받아봅니다. 화면설계는 이 모든 과정을 단지 기획자의 머리 속 시뮬레이션에 의해, 다른 말로 하면 추측에 기반해 제작됩니다. 현명한 기획자는 이 과정에서 개발자에게 조언을 구하고, 피드백을 받아 수정하기도 합니다. 다만 이 조언 역시 개발자의 머리 속 시뮬레이션에 지나지 않는다는 것이 문제지만요.

많은 계획이 실패하는 이유는 계획을 한 사람들이 계획을 세우고는 모든 일이 끝난 것처럼 생각하기 때문입니다. 무능한 관리자는 고작 업무 분담을 한 것을 가지고 마치 그 업무가 끝난 것처럼 좋아합니다. 사실은 그렇지 않습니다. 계획은 일의 종료가 아니라, 시작에 불과합니다. 그것도 실천 과정에서 무수히 많은 장애물을 만나는. 웹 개발 프로젝트의 화면설계 역시 마찬가집니다. 화면설계는 고작해야 ‘지금 이 순간, 고객의 요구사항을 받아 기획자가 적당히 만들어낸’ 가상의 결과물에 불과합니다. 이 사실을 있는 그대로 인정하고, 거기서부터 실제 구현을 출발하면 그나마 덜할테지만, 안타깝게도 많은 경우 이 화면설계를 마치 ‘알파이자 오메가이며, 모든 것’인냥 절대화한다는 겁니다. 고작 종이 뭉텅이를 만들어놓고는 말이죠.

더 큰 문제는 화면설계가 나온 이후에야 비로소 고객의 요구사항이나 개발 스펙이 구체화된다는 데 있습니다. 스티브 잡스가 그랬지요. 고객은 자신이 뭘 원하는지 모른다고. 화면설계대로 개발이 한창 진행된 다음에야 고객은 자신이 승인해준 종이쪼가리가 실제로 눈 앞에서 작동하는 걸 확인합니다. 웹 개발 프로젝트의 재앙은 대개 이 순간 시작합니다. 기획 단계에서 정의한 기능 열 가지 중 세 가지는 쓸모 없는 것이라 판정이 나지만 그대로 구현합니다. 왜? 고객의 도장이 찍혀있으니까요. 그리고 기획 단계에서 생각하지 못한 문제점 다섯 가지와 새로운 -사실은 고객이 스스로도 알지 못했던, 그러나 지금 와서 생각해보니 그 때 알고 있었고, 얘기도 했지만 기획자가 제대로 이해하지 못했거나, 고객 외에는 아무도 기억하지 못하는- 요구사항 다섯 가지가 등장합니다. 문제점은 왜 생길까요? 누누히 말하지만 화면설계는 종이쪼가리에 불과하기 때문입니다. 막상 개발을 시작해보니 동네 뒷산 약수터가 호수공원이 되는 경우가 허다합니다.

자동차를 만드는 것과 비교해서 정리를 하자면 이렇습니다. 새로운 자동차를 개발한다고 칩시다. 처음부터 설계도를 그려서 그걸 바로 공장에 던지고 조립라인을 구성하는 경우는 없습니다. 새로운 자동차를 만들 때도 컨셉 스케치부터 프로토타입 제작까지 무수히 많은 단계를 거칩니다. 생산라인에 올리기 전까지 많은 사람들이 여러가지 방법으로 설계를 검토합니다. 그러고나서야 대량 생산에 돌입합니다. 웹 개발 프로젝트는 어떤가요? 설계와 구현이 바로 연결됩니다. 이 사이에 있는 중요한 단계가 하나 생략됩니다. 바로 프로토타입입니다. 프로토타이핑을 통해 우리가 설계한 것이 정말로 구현 가능한 것인지, 과연 우리에게 필요한 것인지를 판단하고 다듬는 과정을 거쳐야 하는데, 그것을 과감히 생략합니다.

기획 단계에서 모든 화면의 설계와 기능을 예측한다는 실현 불가능한 허상을 믿고 프로젝트에 돌입한다면 이후에 확인하는 것은 그것이 허상임을 깨닫는 일 뿐입니다. 안타깝게도 매 프로젝트에서 그것을 경험하면서도 다음 프로젝트에서는 지난 일은 모두 잊은 것처럼 그대로 반복합니다. 이번에는 그런 일이 생기지 않을 것처럼 계획을 하고 일을 진행하죠. 이건 스스로를 기만하는 겁니다.

10개월 예정의 프로젝트에서 2개월을 기획, 2개월을 디자인, 4개월을 개발, 2개월을 테스트에 할당한다고 가정합시다. 모든 일이 계획대로 진행될 경우 기획자는 자신이 만든 화면설계가 실제로 작동하는 것을 최소한 두 달이 지난 뒤부터 확인할 수 있다는 뜻입니다. (물론 현실에선 두 달 뒤에 확인할 수 있는 것은 아무것도 없습니다. 아직 개발자는 한 줄도 코딩을 시작하지 못했을테니까요) 두 달이면 기획자 본인도 화면설계에 대한 질문을 받으면 문서를 다시 열어봐야 하는 시점입니다. 석 달 쯤 지나면 개발자로부터 ‘이 기능은 이런 뜻인가요?’ 질문을 받으면 ‘그게 무슨 기능이었는지’를 기억해내야하는 일도 생깁니다. 애초에 그렇게 기획을 한 의도를 조금씩 잊어버리기도 합니다.

웹 개발 프로젝트의 결과물은 형체가 없습니다. 수 천 페이지나 되는 웹 사이트를 기획하면서 만들어낸 수 천 페이지짜리 화면설계는 실제로는 아무것도 보장해주지 못합니다. 그 기능들이 실제로 구현이 가능한지, 구현하면 어떻게 작동할 것인지 아무것도 테스트해보지 않았습니다. 그런 종이뭉텅이를 만들기 위해 여러 명이 몇 달을 씁니다. 모든 팝업창 하나, 에러 메시지 하나까지 포함된 완벽한 계획이 나올 것을 기대하면서 말이지요. 다시 말하지만 완벽한 계획은 우리의 현실에선 존재하지 않습니다. 제 여자친구처럼요.

다음 글에서는 그래서 우리는 어떻게 했는지, 그 과정에서 어떤 문제점을 발견했는지를 얘기하도록 하죠.