nothing special

어째서인지 모르겠지만 1년 가까이 묵혀두게 된 글이다. 아마 런치할 즈음에 이미 다음 프로젝트가 들이닥치는 바람에 써두기만 하고 발행을 하지 못한 것 같다. 시간은 참 빨리도 가서, 곧 Gboard가 출시된 지 1년이 다 되어간다. 

얼마 전에 작업하던 스케치 파일을 다시 열어볼 일이 있었다. 길지 않은 기간이었지만 그 사이에 많은 일이 있었다. 나도 조금은 성장해 있었으면 좋겠다. 

--

안녕하세요.

아마도 이번 글이 제가 번역 / 소개 하는 외국 아티클의 마지막이 될 것 같습니다. 

길다면 길고, 짧다면 짧은 2년여의 기간 동안 많은 글을 소개하고, 그 덕에 많은 분들께 고마운 말씀을 많이 들었습니다. 감사합니다. 개인적으로도 읽으며 많은 도움을 얻은 글들이었고, 나누어서 다른 분들이 도움을 받으셨다는 말로도 큰 보람을 느꼈습니다.

하지만 번역을 하는 빈도가 점점 줄고, 내용도 번역이라기보다는 소개에 제 의견이 반 이상이 되어가는 것을 보며 그만 할때가 되었다는 생각을 하게 되었습니다. 이젠 꽤 많은 블로그가 좋은 글을 번역/소개 하고 있기 때문에 저는 한발 뒤로 물러나도 좋지 않을까 하는 생각에 조심스럽게 이렇게 마무리 글을 적으려고 합니다.

아무 글도 안올리고 방치할 수도 있겠지만, 그렇게 되면 많은 분들이 헛걸음을 할 수도 있겠다는 생각이 들었습니다. 글은 그대로 남아 있을 거고, 블로그를 폐쇄하는 일도 없을 것입니다(텀블러가 없어질 수는 있겠지만). 많은 분들이 계속 찾아와서 예전 글을 봐주신다고 말씀해 주시고, 실제로도 그렇게 기록이 남고 있기 때문에 있던 글은 그대로 유지하려고 합니다. 

그 동안 많이 읽어주셔서 고맙습니다. 남아있는 글들이 가끔 도움이 되길 바랍니다.

새로운 글을 또 쓰게 될 지 모르겠지만, 아마도 다음에 새로운 글이 올라간다면 제 생각을 담은 글이 올라가지 않을까 싶습니다. 책임감이 조금 더 필요한 일이겠지만 말입니다.

더불어, 좋은 디자인 번역 글이 올라오는 블로그를 소개합니다. 이 외에도 좋은 블로그를 알고 계신다면 리플로 남겨주세요. 

https://brunch.co.kr/@byeon/

https://brunch.co.kr/@sooscape/

https://medium.com/translated-articles-about-design

페이스북 디자인 디렉터 줄리 주(Julie Zhuo)가 쓴 글. 전문 번역이 아니니 관심이 있으신 분은 꼭 링크를 눌러 전체 내용을 확인하시길. 

8개의 교훈

우선은 교훈부터 간략하게 묶어보았다.

천재적으로 보이는 결과물은 사실 수많은 시행착오의 산물이다.

가장 중요한 것은 “보는 눈"을 기르는 것이다.

혼자서는 큰 영향력을 주는 일을 할 수 없다.

의도를 모르고는 디자인을 평가할 수 없다.

‘디자인 해주는 사람’이 되기 싫다면, 어떤 문제를 풀어야 하고 왜 그런지 말할 수 있어야 한다.

커뮤니케이션 스킬에 투자를 하면 두 배의 효과를 거둘 수 있다.

누구나 가끔은 “내가 가짜가 아닌가" 하는 생각을 한다.

좋은 디자인은 뻔하다.

1. 천재적으로 보이는 결과물은 사실 수많은 시행착오의 산물이다.

훌륭한 디자인 산물을 보면 천재 디자이너가 일필휘지로 만들어낸 작품같이 생각되기 마련이지만, 사실은 수 많은 노력 끝에 나온 결과물이다. 그 동안 최고 디자이너들이 어떻게 일하는 지 어깨너머로 훔쳐볼 기회가 있었는데 어떤 사람도 한번에 끝내지 않았다. 

가능한 모든 방법을 해본 다음에, 최고의 결과물을 얻게 된다

간단히 말하면 그렇다. 말 그대로 내 스킬 내에서 가능한 모든 버전을 친 다음에야 좋은 디자인을 얻게 되는 것이다. 마법이 아니다. 스킬이 늘 수록 시행착오를 겪는 시간이 줄어들겠지만 거기까지 가기 위해선 어쨌든 시행착오를 겪어야만 한다. 지름길을 걸으려고만 하면 결국은 덜 성장하게 되어있다.

2. 가장 중요한 것은 “보는 눈"을 기르는 것이다.

보는 눈이 결국은 결과물을 좌우한다. 어디에 어떻게 시간을 더 쏟아야 할 지를 판단하는 것도 결국에는 안목에 좌우된다. 어떻게 하면 안목을 기를 수 있을까.

당신의 안목이 “충분히 좋다"고 가정하지 말아라.

스스로에게 ‘어떻게하면 이 디자인이 더 나아질 수 있을까?’를 끊임없이 물어라. 실제로 그 결과를 적용하지 않더라도 말이다.

당신이 아는 가장 비판적인 사람을 찾아내어 피드백을 받아라.

피드백을 잘 받는 건 중요하다. 인정을 받으려고 하지말고, 실제로 더 잘하려는 자세를 가져야 한다. 굳이 타협을 할 필요 없다. 디자인은 이해하기 쉬우면서도 아주 잘 만든 것 처럼 느껴질 수 있다. 둘 중에서 선택을 할 필요가 없다. 비쥬얼이 좋으면 쓰기 어려울 거야. 쓰기 쉬우면 비쥬얼이 구려져 같은 양자택일의 오류에 빠져서는 안된다.

3. 혼자서는 큰 영향력을 주는 일을 할 수 없다

가끔은 의견이 안맞는 사람들하고 일하면 짜증이 나기도 한다. 원하는 대로 일이 진행되지 않을 때도 있다. 하지만 그렇다고 해서 혼자 모든 걸 결정하게 되면 어떨까. 재미는 있을 지 몰라도 그다지 영향력이 있는 제품이 나오긴 힘들 것이다. 혼자 회사를 시작하더라도 결국엔 다른 사람과 일을 해야 하고, 결정을 많이 하게 되긴 하겠지만 결국엔 공동 작업을 하는 건 마찬가지이다.

관점을 바꾸어서, 싸워서 이기려고 하지 말고, (차이를 인정한 상태애서) 더 좋은 협업 관계를 가지기 위해서 노력해야 한다. 혼자서는 해낼 수 없는 일을 같이 일해서 이뤄낼 수 있다는 것, 그리고 거기까지 가는데 있어서의 의견 차이와 토론이 필요한 일이었다는 것을 깨달아야 한다. 

4. 의도를 모르고는 디자인을 평가할 수 없다.

마치 체조경기처럼 하나의 기준만으로 디자인을 평가할 수 있다고 믿었던 시절이 있었지만, 사실은 그렇지 않다는 것을 깨달았다. 디자인은 추상적이기보다는 구체적인 문제를 푸는 기술이고, 따라서 문제가 명확하지 않다면 솔루션이 얼마나 문제를 잘 해결하고 있는지 측정할 수 없다. 

“왜 이렇게 인터페이스가 복잡한가"라고 표면만으로 평가하지 말고, 그 이면의 의도를 봐야 한다. 어쩌면 복잡한 인터페이스는 효율성을 살리기 위함일지도 모른다. 깔끔하게 만들기 위한 디자인 결정이 유저가 특정 태스크를 수행하는데 30초 이상을 더 쓰게 만들고, 그게 계속 더해지면 효율성에서 굉장한 차이가 나게 된다.

때론 문제가 굉장히 뻔해보이지만, 그렇지 않을 때도 많다. 그래서 어떤 것이 문제고 왜 그렇게 했는지 아는 것이 크리틱에 있어 중요하다.

5. ‘디자인 해주는 사람’이 되기 싫다면, 어떤 문제를 풀어야 하고 왜 그런지 말할 수 있어야 한다.

디자이너가 문제를 해결하는 사람이라는 것은 “예쁘게 만들어주는 사람"보다는 나은 설명이다. 하지만 그렇다고 해서 남이 해결할 문제를 가져와주기만을 기다리면 당신은 영원히 “서비스"하는 사람에 머무르게 된다. 전략을 결정하는 자리에도 함께 있어야 한다. 예전에 전략에 대한 질문을 받았던 적이 있다. “당신이 지금 우리 자리에 있고, 뭐든 할 수 있다면 어떻게 하겠어요?” 라는 질문이었는데, 그야말로 꿀먹은 벙어리가 되었다. 

단순히 “디자인 해 주는 사람"에서 벗어나려면 내가 푸는 그 문제가 정말 풀 가치가 있는 건지, 지금 회사에 도움이 되는 결정인건지를 알아야 한다. 그리고 여기에는 단순히 디자인 스킬 뿐 이니라, 기술적인 부분, 인력적인 부분까지 따지는 능력이 필요하다. 경력이 많은 디자이너들도 이런 일을 하는 것을 힘들어한다. 쉬운 일은 아니다.

6. 커뮤니케이션 스킬에 투자를 하면 두 배의 효과를 거둘 수 있다.

‘디자인만 잘하면 되지'같은 생각을 한 적이 있지만, 사실 그건 레모네이드 스탠드를 세워놓고 쥬스 만드는 일에만 집중하는 것에 가깝다. 얼마나 팔리는 지에는 관심을 끄고 말이다. 내가 아는 “잘하는 디자이너"들은 커뮤니케이션을 잘 한다. 디자인에 대한 스토리텔링을 잘 풀어놓아 자신의 아이디어가 어떤 결과물이 될 지, 상대를 이해시키고 설득한다.

디자이너라는 것은 미래를 보여주는 초능력을 가진 것이라 할 수 있다. 추상적인 컨셉을 현실화시킬 수 있다. 지금보다 더 나은 버전은 어떻게 생긴 것인지 보여줄 수 있다. 이 기술을 잘 익히는 것도 중요하지만, 당신이 만든 그 미래를, 그 비전을 어떻게 보여주는 것도 그만큼 중요하다.

사람들이 가끔 당신의 디자인을 잘 이해하지 못한다고 느낀다면, 1) 상대가 정말 디자인을 몰라서, 같이 일하기 힘든 사람들이거나, 2) 당신이 스토리를 잘 표현하지 못하는 것일지도 모른다. 왜 이 문제가 그렇게 중요하고, 왜 당신의 아이디어가 최선의 방법인지 효율적으로 설명해야 한다. 우리가 만든 디자인을 유저가 선택하지 않는다고 해서 사용자를 비난하지 않는것처럼, 동료들에게도 마찬가지로 디자인을 팔아야 한다.

7. 누구나 가끔은 “내가 가짜가 아닌가" 하는 생각을 한다.

스스로에게 의문을 갖는 일은 이상한 일이 아니다. 내가 아는 최고의 디자이너들은 모두 스스로에게 의문을 가진 적이 있다. 이건 흔한 일이고 당연한 일이다. 나도 블로그를 쓰며 내가 이 모든 걸 다 알고 말하는건가 의문을 가질 때가 있다. 이걸 인정해야 한다.

남을 보고 좌절할 필요가 없다. 모든 디자이너는 다르다. 잘하는 사람은 영감을 받는 대상이어야 한다. 내가 만약 지난주보다 X영역을 잘 하게 되었다면, 설사 아직 Y보다는 못한다 하더라도 그건 충분히 자랑할만한 일이다.

8. 좋은 디자인은 뻔하다.

우리는 디자이너기 때문에, 디자인 비전문가의 평은 한귀로 듣고 한귀로 흘리는 경우가 많다. 하지만 우리는 그런 사람들을 위해 디자인을 한다. 그들은 디자이너도 아니고, 테크에도 서툰 경우가 많을 것이다. 맥락과 이력을 아는 것은 생산적인 토론에는 도움이 되지만, 종국에 가서 디자인의 성공 여부를 판가름하는 일은 그렇게 복잡하진 않다.

우리는 제약 위에서 디자인을 하고, 더 좋은 / 덜 나쁜 길을 택하며 제품을 만들어 나간다. 사용자의 마음을 알아서 한번에 완벽한 솔루션을 얻으면 좋겠지만 아직 그런 일은 가능하지 않다. 복잡한 일이지만, 우리가 선택한 길 자체가 좋은지 나쁜지 판단하는 일은 간단하다.

구글, 시리, 알렉사, 코타나, 누구에게 물어보아도 말문이 막히는 순간이 온다. 가끔은 보이스 커맨드를 잘못 입력했을 수도 있고, 아직은 할 수 없는 것을 시켰을 지도 모른다. 문제는 이것은 그냥 어느 쪽에건 “실패"라는 것이다. 

구글 검색 제품의 디자인 리드인 Hector Ouilhet은 이 문제의 대한 해답을 자신의 딸인 Anna Julia와의 대화에서 찾는다.  

중요하다고 생각한 내용만 요약한 글이니, 관심이 있으신 분은 링크를 따라가서 직접 확인해주세요.

구글은 왜 말을 하나

“우리는 3살짜리와 이야기를 하건, 90살 먹은 노인과 이야기를 하건 그들에 대한 일정한 기대가 있다” 달리 말하면 우리는 상대와 대화를 할 때 그 사람이 이전에 보여주었던 것에 기반하여 일정한 “능력”을 예상한다는 것이다. 

하지만 구글은 어떤가, 모든 것이 가능하거나, 아무것도 가능하지 않다. 수백만가지의 일을 처리할 수 있지만 어떻게 사용할 수 있는지는 모른다. 그렇다면 사용자는 구글만큼 크고, 파워풀한 대상과 어떻게 상호작용할 수 있을지 예상할 수 있을까?

Ouilet은 그 해답이 구글이 좀 더 사람처럼 행동하는 것에 있다고 믿는다. 이것은 단순히 구글을 의인화하거나, AI와 하는 것에 대한 문제만은 아니다. 오히려 “사람들이 머리를 감싸쥐고, 대체 내가 이야기하는 대상은 뭐지?”라고 고민하는 것을 돕는 일에 가깝다.

보이스 어시스턴트의 불협화음

음성으로 컴퓨터와 대화하는 것에 매달려있는 것은 구글만이 아니다. 애플은 시리, 마이크로소프트는 코타나가 있고, 아마존은 알렉사를 가지고 있다. 음성이 마이수 클릭이나 탭보다는 좀 더 자연스러운 방법이긴 하지만, 한편으로는 여러 문제들을 야기하기도 한다. 사람의 음성을 따라하지만, 사람처럼 행동하진 않기 때문이다.

아마존 에코와 이야기를 할 때를 상상해보면, 재즈를 플레이한다거나, 아이템을 아마존 위시리스트에 담는 일 같은 것은 잘 하지만 오븐을 끄라던가, 엄마에게 전화하라거나 하는 일은 불가능하다. 만약 잘 못들었거나, 커맨드가 예상한 대로 안온다면 마찬가지의 일이 벌어질 것이다. 사람과 다르게 컴퓨터는 애매한 상황에서 무력하기 때문이다.

결국 사람들은 가능한 몇가지의 커맨드에만 집중하고 다른 것은 시도조차 하지 않는다. 제품은 계속 진화하고 있는데도 말이다. 

왜 구글은 (아직) 3살짜리 아이보다 똑똑하지 못한가

Ouilet은 그의 딸 Anna Julia와의 관계에서 이 문제를 해결할 힌트를 찾는다. Anna Julia는 구글의 보이스 어시스턴트와 마찬가지로 아빠가 무슨 말을 하는지 잘 모를 때가 있다. 아빠가 말하고 있을 때 딴 생각을 해서 놓칠 때도 있다. 하지만 그녀가 반응하는 방법은 다른 “제품들"과는 많이 다르다.

저녁을 만드는 장면을 상상해보자. “테이블을 준비해(Set the table)”라는 말을 들었지만 고작 3살인 Anna Julia는 어떻게 해야 할 지를 모른다. 하지만 단순히 “몰라요"라고 말하는 대신 그녀는 그녀가 알아들은 몇 가지 단어를 가지고 아빠가 뭐라고 말한 지를 유추한다. 그리고는 이렇게 말할 지 모른다. “아빠, 식탁에 가서 앉으라고요?”

여기선 세 가지 정도에 주목할 필요가 있다. 1) 아빠의 말을 이해 가능한 단위로 쪼갤 수 있는 능력 2) 맥락을 이해한다는 점 - 저녁이 준비되고 있고, 아빠는 주로 식탁에 가서 앉으라는 말을 한다는 것을 알고 있다는 것 3) Anna Julia는 “준비해(set)”가 무슨 말인지는 정확하게 몰라서 그 말을 함과 동시에, 아빠를 실망시키고 싶지 않기 때문에 그녀가 해석한 최선의 안을 동시에 제안한다는 것이다.

결과적으로 Anna Julia는 아빠가 시킨 것을 수행하지는 못했더라도 아빠에 대한 멘탈 모델에 정보 하나를 추가할 수 있게 되었다. 다음에 테이블을 준비하라고 하면 아마도 그녀는 성공적으로 일을 수행할 수 있을 것이다. 또한 Ouilhet의 경우에도 딸을 독려하면 다음에는 결과를 얻을 수 있다는 것을 알았다. 이것은 단순히 하나의 과업을 수행하는 것에 그치지 않는다. 관계를 만들어가는 것이다.

구글을 안나 줄리아 처럼 만들기

음성 인식 기술 뿐 아니라, 구글은 사용자의 요구를 이해하는 능력도 좋아지고 있다. 지식 그래프(Knowledge Graph)는 검색어에 맞는 결과 이상의 것을 사용자에게 제공하고 있다. 구글 나우와 나우 온 탭은 맥락을 이해한다. 사용자에 대한 멘탈 모델을 만들어, 개개인에게 딱 맞는 결과를 제공하는 것이다. 개인정보 문제가 있긴 하지만, 구글은 사용자가 이전에 무엇을 했는지 점점 더 잘 이해하게 되고, 그래서 다음에는 더 나은 결과를 전달해 줄 수 있다.

Ouilhet은 음성 검색이나 “Zero UI”의 문제들은 기술적인 것이라기보다는 디자인적인 문제에 가깝다고 말한다. 만일 voice ux를 컴퓨터와 대화하는 느낌이 아닌, Anna Julia와 이야기하는 것처럼 바꿀 수 있다면 - 아빠를 기쁘게 해 주고, 배우고 싶어하고, 추측하는 것을 두려워 하지 않는 - 우리에 대해 더 알고싶어하고, 우리로 하여금 그들을 더 알고싶게 만들게 할 수 있다면 어떨까.

‘싫어요' 버튼을 추가해달라는 요구가 많았지만, 페이스북은 엄지 손가락을 뒤집는 것으로 일을 마무리 짓지 않았다. 오늘부터 조금 더 풍부한 감정을 친구의 페이스북 포스트에 전할 수 있게 되었다. 아직 인생의 “모든 감정"이 들어갔다고 할 순 없겠지만 그래도 조금은 더 가까워지지 않았을까.

페이스북의 디자인 디렉터 중인 한명인 Geoff Teehan(그는 Teehan+Lax의 공동 창업자이기도 하다)이 새로운 “리액션" 기능의 디자인 과정을 돌아보는 포스트를 썼다. 간략 요약본이니 관심있는 분은 꼭 본문을 확인하시길.

--

리액션 기능에 있어 가장 중요한 것은 “누구나 이해할 수 있는 언어(universally understood vocabulary)”로 조금 더 잘, 풍부히 자신의 감정을 표현할 수 있게 하는 일이었다. 이를 위해서 팀은 문제를 크게 두가지로 나누었다.

‘좋아요’를 넘어 쓸 수 있는 리액션이 무엇일까?

사람들은 어떻게 리액션을 입력하고 소비할까?

이 문제를 해결하기 위해 팀은 몇가지 원칙(Principle)을 세웠다. 이 원칙은 문제를 해결하는 과정마다 길잡이 역할을 했다. 무엇이 결론이 되어야하는가를 정하진 못했지만, 적어도 무엇이 “우리의 해결방안"이 아닌지는 확인해주었고 나아갈 방향을 정하는 데 도움이 되었다. 이 원칙은 다양한 리서치 결과와 업계 엘리트 인력들의 경험, 직관이 합쳐진 산물이다. 

참여한 디자이너들은 Andy Chung, Brandon Walkin, Brian Frick이다. 링크를 확인해서 그들의 작업을 확인하시길.

리액션

원칙은 다음과 같다.

리액션은 어디서든 이해될 수 있어야 한다 : (미국 뿐 아니라) 전 세계에서 이해될 수 있어야 한다. 그래서 더 많은 사람들이 서로 연결되고 공감할 수 있어야 한다.

리액션은 널리 쓰여야하고, 더 표현적이어야 한다 : 실생활과 연결된 감정들을 좀 더 풍부하게 표현할 수 있어야 한다. 

방법은 간단히 좋아요 엄지를 뒤집는 것과, 100개가 넘는 이모지(emoji) 사이의 어딘가에 있을 것이다. 해결 방안을 찾아내기 위해서 다음과 같은 것들을 살펴보았다.

사람들이 가장 많이 쓴 스티커

스티커를 검색할 때에 많이 사용한 검색어

가장 많이 달린 “짧은" 답글 (eg. “RIP”,”Wow”,”Love it”,”Thanks)

여기에 내부 리서치와 인터내셔널라이제션 팀의 노력이 더해져 아래와 같은 첫 번째 리액션 세트가 만들어졌다.

Like

Love

Haha

Wow

Sad

Angry

Confused

Yay

오늘 공개된 기능에는 “Confused”와 “Yay”가 빠져있다. 이유는 Confused는 다른 리액션만큼 많이 쓰이지 않았고, “Yay”는 다른 감정(Haha, Like)와 겹치는 부분이 있었기 때문이다.

일러스트레이션 작업 역시 매우 중요한 단계였다. 일러스트들은 페이스북만의 개성을 가져야 하면서도 널리 이해되고 생태계에 잘 안착될 수 있어야 한다. 초기 일러스트들은 플레이스홀더로 두고, 다양한 버전을 만들어보았다. 중요한 것은 겹치는 감정이 생겨 혼란을 주어서는 안된다는 것이었다. 예를 들어 “Yay”는 입모양이나 눈표현이 조금 바뀌는 것만으로 “Haha”가 될 수 있기 때문이다. 혹은 디테일 하나에 아무 감정도 표현하지 못하는 상태가 될 수 있기도 하기에 중요한 작업이었다.

라벨을 달기도 하고, 떼보면서 다양한 테스트를 했다. 분명 라벨링은 이 감정이 무엇인지 좀 더 확실하게 정의하는 효과가 있었다. 그래서 인터내셔널라이제이션 팀과 함께 이 감정들이 세계 어디에서나 공유될 수 있는 것들인지 확인하는 작업들을 거쳤다. 예를 들어, 일본에 있는 당신의 친구가 표현한 감정을 당신도 그대로 받아들일 수 있는지 같은 것 말이다.

애니메이션을 더하는 것은 초기의 정적인 리액션에 생기를 불어넣었다. 애니메이터들이 만든 최적의 표현을 디자이너와 엔지니어가 잘 구현하기 위해 노력했다. 디자이너들이 짠 애니메이션은 엔지니어에게 넘겨져 정밀하게 작업되었고, 결과적으로 최종 빌드에서 부드럽게 구현되었다.

한꺼번에 움직이는 것이 너무 부담스러울 것 같아, 처음엔 손가락이 멈추는 곳의 리액션만 애니메이트 시키려고 했지만, 최종 저커버그 리뷰에서 어차피 손가락을 빨리 움직이면 한꺼번에 움직인다는 것을 깨달았고, 저커버그는 독(dock)이 노출되었을 때 한번에 움직이게 하자는 제안을 했다. 그리고 그것이 최종안이 되었다.

시스템

원칙 없이 가다보면 제대로 스케일링 할 수 없는 복잡한 시스템을 만들고 만다. 따라서 시스템을 만들 때에도 몇가지 원칙을 정했다.

리액션은 “좋아요”의 연장선이 되어야 한다 : 좋아요, 코멘트, 공유는 페이스북 어디에나 있는 기능이다. 네 번째 옵션을 더하는 일은 복잡도를 많이 올리게 될 것이다.

리액션은 이미 존재하는 기능을 더 어렵게 만들어서는 안된다 : 수억명이 쓰고 있는 서비스이기 때문에 이미 있는 기능을 사용하는 일을 어렵게 만들지 않도록 노력해야 한다. 리액션은 좋아요를 누르는 것 만큼 쉬워야 한다.

첫 번째 프로토타입 : 아직 얼마나 많은 리액션이 있을지 모르는 상황에서 많은 리액션을 소개하는 목적으로 만든 프로토타입이다. 리액션은 모두 실제 결과물과 관계가 없다.

이 프로토타입에서 발견한 문제들은 아래와 같았다.

UI가 위에서 잘릴 수 있다

손가락을 움직이는 범위가 넓은데도 라벨 위에서만 스와이프를 하려 했다

텍스트를 읽는 게 힘들었고, 다른 나라 말로 번역하는 일도 힘들었다

라인 아트 형식은 큰 화면에선 좋았지만 스크린이 작아질수록 알아보기 힘들었다

화면을 문질러서 선택해야 하는데, 일단 리액션 리스트가 나타나면 손을 떼고 리액션을 탭 하려고 해서, 리스트가 사라져버리는 문제가 있었다

리액션이 너무 많으면 겹치는 것들이 생겼다

다음 프로토타입의 문제는 한번에 하나씩의 일러스트만 보인다는 것이었다. 이렇게 되니 텍스트를 읽어서 리액션을 선택해야 했고, 시간이 오래 걸렸다. 그래서 한번에 모든 리액션을 보여주는 독(dock)모델을 채택하게 되었다. 독이 화면 밖으로 나가는 일도 없앴고, 일단 독이 보여지면 리액션을 탭 해서 선택할 수 있게도 되었다.

리액션을 소비하기

기존에는 “좋아요 17개"로 모든 것이 설명되었지만, 이제는 어떻게 설명해야 할까? “리액션 17개"가 무슨 뜻을 가질 수 있을까. 어떤 리액션을 받았는지 보여주는 일도 굉장히 중요하다. 팀이 가장 먼저 시도한 일은 - 당연하게도 - 모든 리액션 리스트를 한번에 보여주는 일이었다.

하지만 이렇게 되니 “좋아요 17개"에 비해 의미를 해독하기가 힘들어졌다. 예전에는 쓱 훑어보고도 의미를 파악할 수 있었던 것을 이제는 하나 하나 읽어내야 했기 때문이다. 수 많은 안을 테스트 해 보았고, 결국에는 가장 많은 리액션을 받은 세 개를 모아 표시하고, 총 개수를 옆에 같이 보여주는 안이 선택되었다.

--

한 디자이너가 100일 동안 스위프트를 익히며 느낀 점을 공유했다. 너무 훌륭한 프로젝트라고 생각한다. 그게 꼭 코딩 공부라서 그런게 아니라 이렇게 혼자 목표를 세우고 꾸준히 달려나가는 것이 얼마나 힘든 것인지 알기 때문이다. 글을 읽다가 너무 내 생각같은 구절이 있어서 짧게 공유해본다.

--

그동안 많은 시간을 들여 뭔가를 만들려고 했고, 제품이 어떻게 만들어졌는지에 대한 질문을 던졌다. 아직 배우는 중이므로, 내가 프로그래밍을 배웠다고 말하고 싶진 않다. 하지만 내 머릿속에 뭔가 울린 순간만큼은 기억한다 - 뭐가 어떻게 돌아가는지 깨달은 그 순간 말이다. 사실은 이것은 Swift와는 무관하다. 그 순간에 내가 사용하던 툴은 Framer라는 프로토타이핑 툴이었기 때문이다. 이 툴은 Bret Victor의 발표인 “원칙에 기반하여 발명하다"에서 소개되기도 한, 즉각적인 인터랙티브 코드 시각화(immediate interactive code visualization)이라는 개념에 기초해서 만들어졌다. Framer를 사용하며 나는 기본적인 코드 구조에 대해 깨우칠 수 있었다. Framer는 나에게 이런 개념들을 알려주었다.

왜 함수를 사용하지? (Why write a function?)

for loop으로 뭘 만들 수 있지? (What can I make with a for loop?)

If 선언문으로 뭘 할 수 있지? (What’s the use case of an if statement?)

그 외에 많은 것들 (And many more.)

Framer는 이 모든 것에 비쥬얼적인 방법으로 답을 주었다. 코드에 작은 변화를 주면 그 효과를 바로 확인할 수 있었다. 이 과정을 통해 코드가 뭔가를 만드는 것에 어떻게 활용되는 지 이해할 수 있게 되었다. 그리고 이것은 Swift로 뭔가를 만드는 것에 있어 필수적인 요소였다. 지금 Framer를 배우면 iOS앱을 만들 수 있다는 이야기를 하는 것은 아니다. 단지 Framer가 iOS앱을 만드는 데 필요한 것들을 좀 더 쉽게 이해할 수 있도록 도와주었다는 이야기를 하고 싶은 것이다. (후략)

-- 

나 역시 프로그래밍을 배워보려고 많은 노력을 했다. 책도 여러권 사 보았고, 동영상 강좌도 보았다. 하지만 모두 기본부터 시작했고 그게 나를 중간에 여러번 좌절케 만들었다. 더하기 빼기, 논리 구조, 변수와 상수, 함수.. 그게 나쁘다는 이야기를 하는 것은 아니다. 난 단지 버튼을 누르면 화면이 전환되는 걸 해보고 싶었을 뿐인데 그걸 위해 거쳐야 하는 관문이 너무 많았을 뿐이다. 내가 지금 보고 있는 이 개념들이 대체 내가 구현하고자 하는 결과물과 무슨 관계가 있는지 모르는 상황에서 책을 붙들고 있으려니 졸음만 올 수 밖에.

하지만 Framer는 시작부터 뭔가 움직인다. 일단 뷰를 그리고, 거기에 터치 이벤트를 입히고, 그 다음에 바로 움직이는 것이 한 세트다. 당장 뭔가 돌아가니 그 다음을 배울 의욕이 생겨난다. 질문이 늘어나게 된다. 

“한 방향으로는 갔는데, 되돌아가려면 어떻게 해야하지?” 에서 if문을 배울 생각이 난다. 

“매번 버튼을 만들어야 하나...” 라는 생각에서 for loop의 중요함을 깨닫는다.

“매번 애니메이션을 선언해야 하나...” 라는 생각에서 function의 필요성을 느낀다.

예전에는 남의 코드를 copy & paste하고 살짝 값을 고치는 것도 버거워했고, 벌벌대며 돌아다니는 js소스를 짜깁기해서 덜컥거리는 결과물을 내놓고 머리를 싸맸다면, 이제는 바닥부터 내가 짜볼 용기를 내게 된다. 조금 어렵게 느껴지는 부분도 배울 생각이 난다. 문법이 조금 다를 뿐, 구조가 비슷하다는 것을 깨닫게 된 이후로는 코드를 보는 데 두려움이 좀 덜해졌다. 예전에는 내가 원하는 값을 바꾸는 부분만 찾아보았다면, 지금은 읽어보려고 노력을 한다는 점이 가장 큰 차이이다.

2015년에도 이 블로그를 운영할 수 있을거라 생각하지 못했다. 사실 일 때문에 2014년만큼은 글을 잘 올리지 않았다. 출장이 잦았기 때문에 번역을 하는 일은 사치였고, 그래서 그냥 원문을 간단히 요약하고 내 생각을 덧붙이거나, 내 이야기를 주로 했던 것 같다. 

이미 주변에도 번역을 해서 글을 공유하는 좋은 블로그들이 생겨나고 있기 때문에 그랬다고 말하고 싶지만, 그것은 핑계에 가까운 것 같다. 아무튼 1년 동안 그럭 저럭 글을 올렸고, 그에 비해 과분한 관심을 받았던 것 같다. 고맙습니다.

올해도 2015년 한해동안 많이 읽혔던 글을 모아 정리해보았다 (지난해 정리 : http://radiofun.tumblr.com/post/106421826066/nothing-special-best-of-2014)

1. 속 빈 아이콘이 정말 인식하기 더 어려울까? 리서치 스터디 결과 (페이지뷰 : 12,038, 텀블러 반응 : 64)

iOS의 특징인 라인 아이콘이 꽉 찬 아이콘에 비해 인식이 어렵다는 비판이 많았는데, 이걸 실제로 테스트 해본 사람이 있었다. 결과는 “유의미한 차이가 없었다" 였는데, 그 내용 보다도 과정이 흥미로웠던 글이었다. 데이터는 중요한 것 같다. 그것이 정성적인(qualitative)것이든, 정량적인(quantitative)것이든 간에 말이다.

2. 내 경력 중 가장 큰 실수 (페이지뷰 : 6,891, 텀블러 반응 : 48개)

“디자이너는 코딩을 해야 하는가"는 굉장히 논쟁적인 질문이다. 이 글은 “코딩을 해야 한다"에 가까운 내용이라기보다는, 두 손으로 직접 만들어내고, 디지털 환경에서 “디자인"이라는 경계를 끝까지 밀어부쳐보는 것이 얼마나 가치있는 일인지를 말하고자 하는 글이라고 생각한다. 

다른 영역의 디자이너들과 다르게 보통의 UI 디자이너들은 정지 화면 목업에서 작업이 끝나는데, 이걸 움직이게 만들면 전혀 새로운 가능성이 보이고, 그건 남의 일이 아니라 본인이 일로 해도 전혀 이상할 것이 없다는, 어찌 보면 만드는 사람 입장에서는 당연한 이야기가 아닌가 싶다.

3. 구글 취업기 (페이지뷰 : 4,925, 텀블러 반응 : 65개)

Google Chrome팀 디자이너의 글을 소개하면서 내 이야기를 하려고 했던 것인데, 지금 다시 보니 아예 내 이야기만 한 것 같다. 2014년 구글에 면접을 보고, 합격을 하기까지의 이야기를 써보았다. 올릴까 말까 고민을 좀 했지만, 내 입장에서는 굉장히 궁금한 이야기였기 때문에 가치가 있을 것이라 생각하고 공유했다. 이 글을 올린 이후 질문 메일도 들어오고, 메시지도 받기 시작했는데 사실 나도 한번 봤을 뿐이고 잘 알지 못해서 곤란했던 기억이 있다.

4. 저 목폴라가 니 목을 조른다고 (페이지뷰 : 4,543, 텀블러 반응 : 98개)

2014년 초에 올린 글인데 아직도 많이 읽히고 있다 (페이지뷰는 2015년 데이터이지만 텀블러 반응은 2년 합산치이다) 굉장히 많은 사람들이 글을 공유하고 참고할 디자인을 찾아다니지만 사실은 작업에 몰두하는 것 만큼 중요한 것이 없다는, 근본을 찌르는 내용을 담고 있다. 

올리면서도 뭔가 미묘하게 자기 비판을 하는 듯한 기분이 들었고, 지금도 조금은 그런 느낌이 들고 있다. 하지만 공유를 하는 것도 분명히 의미 있는 일이라고 생각하기 때문에 두 입장 사이에서 늘 줄타기 중인 것 같다.

5. 디자이너는 코딩을 해야 할까요? (페이지뷰 : 3,289, 텀블러 반응 : 33개)

직접 쓴 글이다. 그 동안 Framer나 Form, 혹은 Origami 등의 프로토타이핑 툴을 서울과 도쿄, 심지어 샌프란시스코까지 돌아다니며 소개해왔다. 지금도 팀 동료들에게 툴을 소개해주고 가르쳐주기도 하지만, “이것만이 정답인가" 에 대해 의문이 있었고, 간혹 보이는 글에서 “JS를 알면 디자인을 잘하게 된다” 같은 내용을 본다거나, 메일에 “디자인을 잘하고 싶은데 프로토타이핑을 못해서 걱정…” 같은 내용을 보며, 뭔가 이상한 방향으로 흘러간다는 느낌이 들었다. 

무조건적인 찬성을 받지 않을 것도 알았고 여태껏 툴을 소개해 온 주제에 이런 글을 쓰는게 모순적이라는 생각도 들었지만, 고민 끝에 공유했다. 디자인이라는 작업의 다음 단계가 “프로토타이핑"이고, 이걸 모르면 후진 디자이너가 된다거나, “디자이너는 코딩 공부를 안해서 연봉이 그 따위" 황당한 글을 보며 결국 공유하기 잘 했다는 생각이 들었다. 

몇가지 팩트를 정리해보았다.

여전히 페이스북과 트위터가 가장 높은 소셜 유입 채널이지만, 2015년에는 네이버에서도 꽤 들어왔다. 가끔 네이버 블로그에 완전히 copy & paste한 글이 돌아다니는 걸 보곤 했는데, 어지간하면 여기서 봐 주시길. 

지난해보다 살짝 늘은 62,161명의 사용자가 들어왔다(2014년은 53,354명). 페이지뷰는 108,605로 조금 줄었고, 세션은 81,615로 전반적으로 조금씩 통계가 감소했다. 글을 덜 올린 탓이라 생각한다. 미안합니다.

크롬이 여전히 제일 높지만, 이번부터 모바일 브라우저가 통합이 되어서인지 작년에 비해 Safari의 비중이 엄청나게 높아졌다. 총 34% 가량의 유저가 Safari에서 방문했고, IE는 8.9%로 크게 줄었다. 애도를…

운영체제는 iOS가 60% 가까이 되었고, Android는 39.5%로 더 줄었다.

텀블러 팔로워는 1,703명으로 조금 늘었다. (+330명)

–

한해동안 방문해 주셔서 고맙습니다. 가끔 만나는 분들도 “블로그 글 잘 읽고 있습니다" 같은 인사를 해 주셔서 그만둘까 하다가도 글을 올리게 되는 것 같습니다. 앞으로도 최대한 게으르지 않게 운영해보겠습니다.

팀에서 선물 받은 책이다. 팀 전체에게 한권씩 돌렸다고 했는데 내가 마침 자리에 없어서 뒤늦게 받았다. 

Frank Chimero가 쓴 아주 짧고 얇은 책인데, 최근에는 좀처럼 책을 손에 잡기가 어려워서 방치하고 있다가 지난 중국 출장때 바짝 읽었다. 아직 읽고 있는 중이지만 공감하는 문장을 몇 문장 떼어 글을 적어보려 한다.

창조적인 프로세스는 본질적으로 자신과 작업물간의 대화라고 할 수 있다. 화가는 이젤에서 떨어져 있을 때 멀리서 작업을 관찰하고 분석한다. 꼼꼼하게 뜯어보고 (내면의 목소리를) 들어가며 다음 스트로크를 결정한다. 그리고 나서야 캔버스에 다가가 그림을 그린다. 그리고 그 과정을 다시 반복하는 것이다.

p23, “How and Why”

언제나 큰 그림을 봐야 한다는 말을 듣지만 작업을 할 때 한발 떨어져서 전체를 보는 일은 쉽게 생각나는 것은 아니다. 그냥 모니터에서 멀찍이 떨어져서, 혹은 그림을 디바이스에 넣어서 (모바일 앱이라면) 관찰하는 것도 해당되는 일이겠지만, 이 서비스가 다른 서비스와 붙었을 때엔 어떻게 동작하는지, 내가 상정한 하나의 이상적인 상황이 아니라면 어떻게 될 지를 생각해 보는 일도 중요하다. 그렇게 되면 지금 얹어놓은 버튼이 과연 옳은 위치에 있는 지 점검할 수 있게 되는 것이다. 

한걸음 떨어진다는 것은 물리적인 거리가 될 수도 있지만, 내가 작업한 사람이라는 입장에서 떨어져서 비평을 받는 것도 해당될 수 있다. 주관적인 작업자의 입장에서 여러 발자국 떨어져서, 내가 작업한 결과물에 대한 비평을 담담하게 수용하고, 건설적으로 작업을 재 구성하는 일 말이다. 치열하게 작업하고, 마치 내가 작업한 것이 아닌 양 거리를 두고, 다시 거기서 배운 교훈을 가지고 뛰어든다...고 받아들이고 싶다.

제약은 큰 프로세스를 조금 더 작고, 이해할 수 있는 공간으로 만들어 오히려 탐색의 여지를 넓혀준다. 그것은 풀에서 수영을 하는 것과 망망대해에 놓여진 것의 차이와 비슷하다. 

p45, “Improvisation and Limitations”

창조적인 작업에서 내가 움직일 수 있는 폭을 일부러 제한한다는 것은 처음엔 굉장히 이상하게 들릴 지도 모르지만, 오히려 명확하게 움직일 수 있는 범위를 좁히는 것은 작업에 큰 도움이 된다. 색을 몇개를 써야 하는지, 패딩은 어떤 종류가 있는지 같은 실질적인 디자인 작업에도 도움이 되지만, 보다 관념적인 단계에서의 제한도 도움이 되는 것 같다. 

앱을 들어 이야기해보자면, 이 앱이 어떤 일을 할 수 있는지를 정하는 것도 중요하지만, 어떤 일을 하지 않아야 하는지 정의하는 것도 중요하다. 생각은 꼬리에 꼬리를 물고 이어져 나간다. 내가 움직이는 운동장이 명확하게 정의되어있지 않다면 그 생각을 따라다니다 어느새 지쳐버리고 말 것이다. 내가 움직일 곳과 움직이는 곳을 명확하게 그어놓으면 그 안에서의 생각이 깊어질 수 있다. 결국에는 생각의 방법과도 연결되는 이야기인 것 같다.

형식의 변화는 완전히 새로운 문을 열어준다. (중략) 하지만 우리는 종종 늘 하던대로 셋업을 하며 그 새로운 기회를 무시하곤 한다.

p54, “Form and Magic”

책에서는 프로모션 포스터와 웹 페이지의 차이를 들어 설명한다. 프로모션 포스터는 종이 위에 출력된 정적인 물건이기 때문에, 연주자의 얼굴이나 프로그램, 가격과 공연 장소 등의 정보가 굉장히 잘 정리되어야 한다. 여기에 잘 집중한 결과물은 성공적인 프로모션 포스터라고 할 수 있을 것이다. 그리고 이 원칙을 웹에 그대로 가져가더라도 실패하진 않을테다. 

하지만 웹이라는 재료를 다시 한번 살펴보면, 이 재료로 할 수 있는 일이 훨씬 많다는 것을 알게 된다. HTML 오디오로 음악이라는 전혀 새로운 레이어를 얹을 수 있게 되는데, 이건 포스터 디자인의 원칙만으로는 가능하지 않은 일이다. 마찬가지의 일이 모든 디자인 영역에서 일어난다. 앱이 할 수 있는 일을 모른 채 10년 전 웹 기술로 디자인을 한다면 어떨까? 이건 실제로 일어나고 있었던 일이고 이 일은 앞으로도 일어나게 될 것이다. 내가 만드는 결과물은 재료와 깊은 연관이 있다. 재료를 먼저 이해하는 일이 없다면 결과물은 이전 시대의 복사판이나 다름 없을 것이다.

(디자인에서의 문제 해결이 과녁을 맞추는 일이라면) 과녁을 맞추는 일은 일시적인 일일 뿐이다. 그리고 과녁이 움직인다는 것을 문제로 여기기보다는 기꺼이 화살통에서 화살을 하나 더 빼어 그 움직이는 과녁을 맞추어야 할 것이다. 

p79, “Content and response”

디자인은 상대적이고 주관적이라고 한다. 하지만 동시에 그것은 문제 해결이기도 하다. 어떠한 문제를 상정하고 거기에 대한 답을 내놓아야 하지만, 답이 하나라는 법은 없다. 내가 지금여기에서 내놓은 답이 다른 모든 곳에서 먹히리라 생각할 수도 없다. 난 예전부터 - 흔히 말하는 - 미국의 솔루션을 좋아했고, 마치 그것이 정답인 양 이 상황에서는 이렇게 하는 게 “맞다" 라고 말하곤 했다. 하지만 그것은 굉장히 오만한 이야기였다. 

내가 디자인하는 상황과 내 제품을 쓸 사람을 생각하지 않고 제품을 만들 수 없다. 한국인/중국인들은 왜 덕지덕지 버튼이 붙은 웹 서비스를 좋아할까? 그게 그렇게 주어졌으니까? 아니면 그 뒤에 뭔가 다른 문화적인 배경이 있기 때문에? 텅 빈 검색창만을 보여주는 것이 정답일까 아니면 그들의 원하는 많은 양의 정보를 뿌려주는 것이 맞을까? 어느 결과물을 내더라도 내가 처한 상황을 이해하려는 노력은 꼭 필요한 것 같다.

--

디자인 관련 글은 아니지만, 혹시나 외국 회사로의 이직을 생각하는 분이 있다면 도움이 될까 싶어서 제 경험을 공유해 봅니다. 다른 곳으로 전재되지 않았으면 좋겠습니다.

–

외국 회사에서 영어를 쓰며 일하기 시작한 지 이제 1년이 거의 다 되어간다. 그 동안은 한국 회사에서 한국말만 쓰며 일해왔기 때문에 ‘말이 안통한다'는 건 의견이 대립될때나 쓰는 표현이었다. 하지만 정말 말이 안통하는 곳에서 일하게 될 줄이야.. 

참고로, 나는 영어권 국가에서 거주한 경험이 없고, 30여년 동안의 인생을 모조리 한국에서 보냈다. 학창시절엔 영어 점수를 제법 잘 받는 편이었지만, 지하철에서 길을 헤매는 외국인이 보이면 혹시나 말을 걸까 가던 길을 돌아가는 평범한(?) 한국 남자 중 한명이라고 할 수 있다.

벙어리 3개월

한국에서 일할 때에도 말수가 많은 편은 아니었지만, 입사 후 첫 3개월은 말이 없어도 너무 없었다. 회의 시간엔 거의 묵언 수행을 하는 수준이었고, 리액션이라고 해봐야 고개를 끄덕이는 게 전부였다(못 알아 들었는데도 장단을 맞춘 적도 있었다). 일단 들리는 말이 모두 영어라는 것이 과부하를 줬고, 생각이 정리되어 의견을 말할 수 있을 때 즈음엔 이미 나는 호텔 침대에 누워 있었다. 

일을 할 때엔 내가 외국인이라고 생각해서 천천히 말해주거나, 내 의견을 일부러 물어봐주지 않는다. 나서서 말하지 않으면 누구도 “자네 의견은 어떤가" 라고 말하지 않는다. 대화의 흐름 속에 자연스레 의견을 끼워넣는 분위기에서 가뜩이나 처리 속도가 느린 내가 말을 보탤 여유따윈 없었다. 하필이면 오자마자 디자인 스프린트에 들어가서 그런지, 더더욱 힘들었다.

하지만 입을 다물고 있으면 영원히 다물고 있게 된다. 어느 날은 “굳이 내가 의견을 보태지 않아도 될 정도였어" 라고 자위하기도 했지만, 보통은 내가 의견을 내지 않으면 모든 것은 남들 뜻대로 흘러가게 된다. 영겁과도 같은 시간이었다. 내가 과연 말을 하게 될 시간이 오기나 할까? 자신감이 많이 떨어졌고, 한국으로 돌아가고 싶다는 생각이 들었다.

굳이 내가 여기 있을 이유가 없다는 생각을 많이 했던 시기였는데, 어차피 내가 여기 오려고 계획했던 것도 아니고, 지금으로선 서울에서 일하는 게 더 자연스러운 일이었다. 언제 돌아가도 이상한 일은 아니다. 안되면 돌아가면 되지 뭐.

그렇게 바닥을 치고 나자 차라리 아무 말이나 해보자는 생각이 들었다. 어차피 자연스럽게 끼기는 무리다. 그래서 무작정 손을 들었다. 번쩍 손을 든 나를 보고 처음엔 모두 당황했는데, 어쨌든 내가 발언권을 확실하게 가지게 되었고, 그 순간엔 긴장도 되고 해서 뭐라고 했는지 기억도 안날 정도로 횡설수설했지만 그 순간 이후로 말하는 것에 조금씩 부담을 덜게 되었다.

아직도 대화 중에 자연스레 말을 얹는 건 어려운 일이다. 하지만 조금씩 요령이 늘었다. “hmmm..”, “uhmmm..”, “well”, “one question” 같이 말길을 일단 터 놓고 그 다음에 되는대로 이야기하거나, 아니면 말할 키워드를 슬쩍 적어둔다. 그리고 적어둔 순간에서 그리 멀지 않은 순간에 그냥 일단 끼어든다. 내가 지금 말 안하면 누가 비슷한 내용의 말을 해버리기가 쉽고, 그럼 내가 적은 키워드는 버려지기 때문이다. 

사실 말하는 것에 집착할 이유는 전혀 없긴 하지만 말을 못하는 상황이 싫어서 계속 어거지로 말을 보태려고 노력했던 것 같다.

뭐라고? (Sorry?)

이번에 깨달은 안좋은 습관은, 확실하게 모르는데도 대충 아는 것 처럼 퉁치고 넘어가는 것이었다. 처음에 다소 바보같이 보이더라도 정확하게 질문을 파악하고, 내 의견을 확실하게 이야기하는 것이 낫다. 두루뭉술하게 넘어가는 건 외국어에선 거의 불가능한 것 같다. 특히 저쪽에서 요구사항을 이리저리 이야기했는데 내가 대강 알아들었다고 해서 넘어가면 디테일한 부분에서 문제가 생기는 경우가 있다. 서로 다른 아이콘을 3개 달라고 했는데, 같은 아이콘을 3 버전 그려간다거나 하는 경우는 비일비재하다. 특히 구두로 이야기가 오가는 경우에 실수가 많이 생긴다.

어차피 나는 네이티브가 아니고, 질문은 나쁜 일이 아니다. 오히려 제대로 안물어보고 마음대로 하는게 문제다. 하지만 처음엔 뭔가 “뭐라고?”하는 말 자체가 왠지 모르게 실례처럼 느껴졌다. 그래서 되도록이면 한번에 알아들은 척을 하려고 넘어갔다. 

회사의 특성 상 화상 회의가 잦은데, 화상 회의는 더더욱 고역이었다. 일단 내 의견을 제대로 표현하지도 못할 뿐더러, 남의 질문조차 제대로 들리지 않기 때문에 대답을 제대로 하지 못하는 경우가 많았다. 그냥 회의에 들어가면 슬쩍 묻어가기가 쉽지만, 화상회의는 정확하게 내 이야기를 하지 않으면 할 이유 자체가 없다. 그래서 더욱 힘들었다. 발표를 할 때에는 대본을 준비하기도 했지만 질문에는 속수무책이었다.

잘 안들리던 말이 제대로 들릴 리도 없다. 그럴 때엔 그냥 “뭐라고?”를 말해야 하는 것 같다. 내가 어떤 말을 제대로 못알아 들을때면, 그 사람은 똑같은 말을 반복하기도 하지만, 좀 더 쉬운 표현으로 바꿔주는 등의 노력을 해서 뜻을 전하려고 노력한다. 그렇게 하면 두 배 세 배의 시간이 들긴 하지만, 무턱대고 일을 진행해서 일을 되돌리는 수고를 덜 수 있다. 

구두로 확인이 되었다고 해도 모든 게 확실하지 않을 수도 있으니 처음 몇 개월 간은 다시 메일을 보내 내가 이해한 바를 전달했고, 틀린 게 있으면 수정해달라고 물어봤다. 그렇게 해서 구두 커뮤니케이션에서 생길 수 있는 오류를 미리 잡으려고 노력했다.

인정했어야 하는 것은 나는 영어를 잘 못하는 사람이라는 사실이었다. 그 동안은 겉멋이 들었는지 대충 발음 굴리고 하면 말 잘하는 것 처럼 보이겠지 하는 착각속에 살았다. “번역도 좀 하니까 난 영어를 잘해, 그러니 영어를 잘하는 사람처럼 굴어야지.” 라고 생각했다. 그래서 발음이 이상할까봐 걱정했고, 내가 잘 못 알아듣는 것 처럼 보일까봐 걱정했다. 

하지만 그런건 전혀 중요한 게 아니었고, 그 사람이 말하는 바를 얼마나 잘 이해하고, 내가 말하고자 하는 바를 정확하게 전달하는 것이 핵심이라는 것을 깨달았다. 표현이 틀리거나 문법이 이상한 건 문제가 아니다. 점잖은 사교 자리라면 문제가 될 수도 있겠지만, 나는 일을 하러 왔고, 일을 잘 끝낸다면 그 외의 문제는 그렇게 중요하지 않다.

잡담

위에 적어둔 것 처럼 힘겹게 일을 하고 나면 만사가 피곤했다. 내 모국어가 아닌 언어로 하루종일 이야기하는 것은 쉬운 일이 아니다. 영어를 하루 종일 하고 나면 마치 밥을 굶은 사람 처럼 한국어가 고파진다. 그래서 한동안은 바깥에도 안나가고 그냥 한국 방송만 찾아봤다. 하지만 그렇게 하고 나면 다음 날이면 다시 모든 것이 리셋이 된다. 그러면 다시 영어를 힘들게 말해야 하고 돌아오면 한국어가 고파지는 악순환이 이어졌다.

이 회사에는 1:1이라는 게 제법 널리 퍼져있다. 잘 모르는 사람이라도 같은 회사 안에 있다면 쉽게 “커피나 한잔 하며 이야기하자" 라고 미팅을 잡을 수 있다. 순다 피차이나 마티아스 듀왈테 같은 사람이야 좀 어렵겠지만, 사실 만나자고 한다면 그런 사람들 조차 의외로 쉽게 만나줄 수도 있을 것 같은 느낌이다. 내 경우엔 Framer 커뮤니티에서 조금 알려진 덕을 봤는데, 원래 커뮤니티에서 알던 친구들이 나에게 커피를 마시자고 연락을 하는 경우도 있었고, 내가 커뮤니티에서 보던 친구에게 커피를 마시자고 연락을 하는 경우도 있었다.

만나서 하는 이야기는 미팅에서 하는 이야기보다 훨씬 가벼울 수 밖에 없고, 내가 잘 아는 분야 (Framer) 였기 때문에 말을 하기도 쉬웠다. 게다가 1:1 이기 때문에 내가 하는 말의 속도를 그쪽에서도 쉽게 받아주고, 내가 말을 할 기회도 훨씬 많아진다. 게다가 만약 그 친구가 다음 회의에 들어오게 된다면 긴장도 좀 덜 하게 되기도 한다. 억양이나 자주 쓰는 표현들도 잡담을 하면서 좀 더 익히게 되기 때문에 전반적으로 자신감이 올라가는 효과가 있다.

잡담은 일보다 긴장도가 낮고, 계속 나를 영어를 쓰는 환경에 노출시켜 내가 영어로 말하는 데에 거부감을 줄여주는 효과가 있었다. 그래서 내가 먼저 1:1을 많이 요청했다. 단순히 영어에 익숙해지는 것을 넘어서 회의 때 차마 못한 말을 하거나, 서로간에 공감대를 형성하는 데도 효과가 컸다. 그렇게 한 두번 만나다 보면 회사 밖에서도 가끔 보게 되고, 그렇게 하다 보면 어느새 친구가 된다. 이렇게 한 덕분에 이제 회사에는 아는 사람들도 제법 생겼고, 그 덕분에 회의도 쉬워지고, 일도 쉬워지게 되었다. 상대적인 이야기긴 하지만.

–

글쓰기 서비스인 미디엄이 새 로고를 내놓고, 앱도 업데이트했으며, 새 API도 내놓았다. 굉장히 큰 변화가 연달아 일어났고, 미디엄의 2막이 시작된 느낌인데, 변화를 간략하게 정리해 보았다.

새 로고

최초에 디자인 된 세리프 체의 로고는 굉장히 훌륭했지만 변화해 나가는 미디엄의 모습을 제대로 반영하지 못한다는 느낌이 들었고, 그래서 리뉴얼을 단행했다. (참고로 예전 로고는 Leigh Taylor라고 하는 디자이너가 작업했다. Behance 작업기는 여기를 확인하시길 : https://www.behance.net/gallery/7226653/Medium-Brand-Development)

초점은 서로 연결된 생각과 모양이 서로 합쳐졌을 때 새로운 의미를 가질 수 있는 형상을 구현하는 것이었다. PSY/OPS 의 Rod Cavazos와 협업했다. 네 개의 면이 만나 서로 겹쳐졌을 때 톤과 방향이 조금씩 바뀌는 형상을 디자인했는데, 대화를 하면서 서로 생각을 바꾸어나가는 미디엄의 성격을 반영하고자 했다. 

반응은 그다지 좋지 못하다. 많은 디자이너들이 새로운 로고를 비꼬거나 잘못된 결정이었다고 비판하고 있다. 내 생각에도 “글쓰기"라는 측면에서 봤을 때 이전의 세리프 체의 로고가 진중한 느낌을 주었고, 따라서 “긴 글쓰기" 라는 서비스 특성과도 잘 어울렸는데, 지금의 로고는 한 두어발 더 나간 느낌이다. 

시간이 지나면 반응이 어떻게 달라질 지는 모르겠지만 지금으로서는 작업한 디자이너들이 차가운 반응에 마음이 좀 상했을 것 같다.

새로운 앱 

아이폰, 안드로이드 앱도 새로워졌는데 주요한 골자는 홈 화면의 마이너 개선, 그리고 검색 탭의 추가 (5분짜리 짧은 글을 전면에 내세움), 그리고 글쓰기 기능의 대폭 강화 (첫 버전에는 글쓰기 기능이 아예 없었다는 것을 기억하는가?) 등이 있다. 아이폰 버전은 탭 바를 활용해 메뉴를 단정하게 정리했고, 안드로이드는 햄버거 메뉴를 활용해서 플랫폼 가이드라인을 최대한 따르려고 했다. 안드로이드 버전엔 FAB 버튼이 있는데, 글쓰기 기능을 할당해 대폭 강화된 에디터를 강조했다. 

그동안은 읽기에 초점을 맞춘 “읽기 앱"이었다면 이번 업데이트로 완전히 서비스 전체를 다 사용할 수 있는 앱으로 거듭났다. 모두가 기다려온 당연한 업데이트라고 생각한다. 

글쓰기 API의 공개

글쓰기를 다른 서비스에서도 할 수 있다는 것은 다른 어떤 것 보다 주요한 변화라고 생각한다. 이젠 원하는 툴에서 글을 쓰고 미디엄으로 퍼블리싱 할 수 있게 되었다. 자체 에디터의 기능을 강화하는 한편 유입되는 채널을 기하급수적으로 늘이겠다는 생각이 뒤에 있는 것으로 보인다. 이것은 metric을 신경쓴 정책이기도 할테지만, 이 변화는 미디엄이 “생각있는 사람들이 쓰는 진중한 글"을 다수의 사용자가 읽는 플랫폼에서, IFTTT의 플로우에도 녹을만큼 쉽고 편한 플랫폼이 되어가는 주요한 계기가 될 것이다.

이전처럼 소수정예가 아닌 만큼 전체적인 글의 퀄리티가 낮아질 수는 있겠지만, 일방적인 생각을 받고, 그걸 속으로 삼키기보다는 모두가 글을 자유롭게 배포하고 그 안에서 생각이 교차하며 발전해나가는 (로고가 보여주듯) 서비스의 방향을 짐작할 수 있다.

이 외에도 멘션 기능과 도메인 연동 등이 추가되었다. 멘션 기능은 필자들 간의 대화를 촉진하기 위한 장치일 것이고, 도메인 연동은 미디엄을 자신의 홈페이지처럼 활용하라는 의도로 보인다. 쉽게 이 서비스를 나의 본거지로 삼고, 서로의 본거지를 넘나들며 활발하게 토론할 수 있게 되었다. 어찌보면 서비스가 완전히 판갈이를 했다고도 볼 수 있을 것 같다. 그들은 이 모든 변화를 통틀어 “미디엄의 다음 단계(Next Level)”라고 부른다.

--

미디엄은 한동안은 “읽는 곳"이었다. 트위터나 페이스북에서는 쉽게 쓰기 어려운 글을, 조금 더 긴 호흡으로 써내려가고 그걸 다른 채널으로 배포해 나가는, 소위 말하면 “작가님들의 글이 모여있는" Endpoint였다. 그 안에서 콘텐츠를 탐색하기 쉽게 만드는 장치들을 지속해서 붙여나갔지만 본질적으로 크게 바뀐 것은 없다고 본다. 결국 생각은 다른 곳에서 생겨나고 충돌해왔다. 트위터나 페이스북 같은 곳 말이다.

이제 일어난 새로운 변화들로 인해 미디엄은 생각이 시작되는 곳이 될 수 있을 것 같다. 사용자들이 의도대로 움직여줄지는 둘째 문제이긴 하지만, 글의 호흡은 조금 더 짧아졌고, 대화의 불꽃이 튈 지점들은 많이 늘어났다. 시간을 들여 진중하게 글을 쓰는 데스크톱 에디터에, 쉽고 짧게 글을 쓰게 되는 모바일 에디터가 추가되었다. 그 뿐 아니라 (API 공개로 인해) 내가 좋아하는 에디터로, 내가 선호하는 방식으로 글을 마음대로 보낼 수 있게 되면서 이전에 비해 표현의 성격이 굉장히 다양해졌다. 

“저는 ㅇㅇ을 하는 ㅇㅇ라고 합니다. 여자저차한데 코딩을 배워야 할까요? 프로토타이핑을 해야 하나요?”

내가 소개하는 글이 글이다 보니, 이런 질문을 담은 메일이 가끔 오는 편이다. 최대한 성의를 다해 답장을 쓰려고 하지만 가끔은 나도 답을 모르는 경우가 많다. 아니, 오히려 대부분은 답을 모른다고 해야 맞을 것이다. 

애초에 나 조차도 매일 매일의 디자인 문제를 잡고 씨름하고 답을 못내고 찝찝한 마음으로 잠자리에 드는데, 남의 고민에 제대로 된 충고를 해 줄 수 있을리가 없다.

하지만 늘 비슷한 질문이 꽤 오고, 어떻게든 답장을 써주다 보니 나도 이젠 이 질문에 대해서는 어느 정도 생각을 정리할 수 있을 것 같다. 그래서 정리된 생각을 남겨두려고 한다. 혹시라도 질문을 하실 생각이시라면 이 글을 참고해 주세요.

간단한 답을 말하자면 이렇다. “코딩을 하는 것은 훌륭한 디자이너가 되는 것과 큰 관계가 없습니다". “아니 니가 코딩(혹은 프로토타이핑)을 하라며!”라고 발끈할 사람들도 있겠지만, 그런 사람들을 위해 좀 더 긴 버전을 준비했다.

코딩을 하거나, 프로토타이핑을 하는 것은 분명 어떤 측면에서는 커다란 도움이 된다. 어떤 도움이 되는지는 여러 글을 통해서 설명한 바 있지만, 이런 글이나 저런 글이 도움이 될 것 같다. 요약하면 지금의 소프트웨어 디자인에는 포토샵과 같은 정적인 툴이 메울 수 없는 영역이 있다는 것이고, 그걸 메우기 위한 툴을 배우는 것은 어찌보면 프로세스 측면에서 보았을 때 당연한 일일지도 모르겠다. 즉, 기존의 툴이 지금의 제품을 디자인하기에 부적합하다는 이야기이다. 사실 그리고 그게 전부인 것 같다.

툴은 툴일 뿐이다. 툴을 쓰는 것은 디자이너의 스킬에 있어 굉장히 중요한 영역이지만, 그것이 “디자인"과 어떤 관계가 있는가는 별개의 문제다. 포토샵 cs2를 쓰는 사람보다 스케치 최신 버전을 쓰는 사람이 “좋은 디자이너"라는 보장은 어디에도 없다. Framer를 잘 쓴다고 해서, 나머지 디자이너들보다 압도적으로 뛰어나지지 않는다. 디자이너 우대 요건에 흔히 등장하는 html / css / js 는 마법의 도구가 아니다.

나는 오히려 툴에 경도되어 실질적인 디자인 문제는 무시하는 경우도 종종 봤다. 툴이 주는 편리함과, 툴이 제시하는 방향성에 빠져들어버려 시작을 이상한 곳에서 해버리는 것이다. 당신이 레이어를 합치는 새로운 방법에 기뻐하기 전에, 새로 나온 프레이머 모듈에 흥분하기 전에 생각해야 할 것이 있다는 이야기이다. 

우리 시대의 위대한 디자인 리더들의 이야기를 들어보면 결국 디자인은 얼마나 사려깊게 생각하느냐와 관계가 있다. 버튼의 위치 하나, 거기에 달린 이름, 그리고 내가 설계한 하나의 동선에서 파생되는 다른 동선들, 이것이 더 큰 기기에서는 어떻게 보일지, 더 작은 기기에선 어떻게 보일지, 시각 장애인은 어떻게 사용할 지, 이 모든 질문들 중 디자인 툴 자체가 답할 수 있는 것은 많지 않다. 당신이 반응형 코드를 짤 수 있다는 사실만으로 다양한 기기에서의 디자인 문제가 해결되지 않는다는 말이다. 

“되도록 가능한 것을 한다"라는 말이 있다. 바로 실제 코드를 짜기 시작하면 많은 난관에 부딪힌다. 나에게 제대로 된 설계도나 지침, 원칙이 없다면 난관을 핑계삼아 돌아가기가 아주 쉬워진다. 이게 더 나은 길일거야 하면서, 결국 그렇게 완성된 제품은 훌륭하지 않을 것이 뻔하다. 아니, 완성이나 될 지 모르겠다. 펜과 노트에서 시작해서 개발툴까지 가는 이유가 거기에 있다.

다시 말하지만 툴은 툴일 뿐이다. 코딩을 못한다고 해서 가슴에 무엇이 얹힌 채로 살지 않아도 된다. 내가 아는 훌륭한 디자이너들 중 코딩을 할 줄 아는 디자이너의 비율은 그렇지 않은 사람들보다 낮다. 편한 마음으로 살란 이야기도 아니다. 다른 이유로 가슴에 무엇이 얹힌 느낌을 먼저 받아야 한다는 이야기에 가깝다.

먼저 해야 할 일은, 내가 디자인 문제에 대해 얼마나 열심히 생각하고 있는지 자문하는 것이다. 코딩은 그 다음 문제이다. 나의 프로세스에 코딩이 필요하다면 코딩을 배워야 할 것이고, 아니면 다른 툴을 배우면 된다. 선택지는 많다. 매일 매일 해결해야 하는 디자인 문제 중에 코드를 써서 해결해야 하는 것이 얼마나 있다고 생각하는가? 당신이 코딩을 배우는 시간 때문에, 더 고차원의 고민을 해야 할 시간을 잃어버린다면 그것은 큰 그림에선 손해나 다름이 없다. 

페이스북 디자이너인 J.T. Trollman이 쓴 글, 최근의 고민과도 맞닿은 글이기 때문에 읽으면서 꽤 도움이 되었습니다. 간단히 요약해서 공유해봅니다. 관심이 가셨다면 링크를 눌러 원문을 꼭 읽어주세요.

--

시지푸스의 바위를 디자인에 비유하자면, 맥북에 디자인 소프트웨어를 들고 세상 모든 사람이 만족할 제품을 만드는 일이라 할 수 있겠다. 말하자면 불가능한 일이란 것이다. 모두를 만족시키는 일은 불가능하다. 창의적인 일은 극단적이기 때문이다. 어떤 사람은 당신의 그림을 숭배하지만 당신이 디자인한 의자는 싫어한다. 혹은 당신의 블로그 아티클을 좋아하지만, 당신이 디자인한 앱은 혐오하기도 한다. 강한 의견은 잘 들리지만, 때로 그건 당신이 상대해야 하는 대중의 극히 일부에 지나지 않을 수 있다. 

우리 모두 한 걸음 떨어져 한숨 돌릴 필요가 있다. 바깥의 비판에 귀 기울이는 일은 중요하다. 하지만 그렇다고 해서 길을 잃어서도 안된다. 당신은 언제나 강한 PM, 투자자, 사용자, 혹은 창업자를 만나 그들이 주장하는 바를 들어야 할 것이다. 어떻게 들어야 하는가를 배우는건 그래서 중요하다.

비판을 어떻게 대해야 하나?

나는 여러 경력을 거쳐왔다. 지금은 페이스북의 제품 디자이너이지만 그 전에는 저널리스트로 일해왔다. 작가로서 부정적인 피드백에 대응하는 방법은 어떤 반응이건 좋은 반응일 수 있다는 것을 받아들이는 연습을 하는 것이었다. 내 자신의 스토리와 사실에 자신만 있다면 악의에 찬 이메일 하나하나에 반응하지 않고 다음 글로 넘어가는 것이다.

제품 디자인은 전혀 다른 영역이긴 하다. 트윗 하나, 코멘트, 혹은 부정적인 리뷰 아티클은 악몽의 소재가 되기에 충분하다. 적어도 전략을 다시 생각하게 만든다. 게다가 제대로 된 수치도 없다면 공포는 증폭된다. 모두가 이걸 싫어하는건가? 이제 우리는 끝난건가? 난 이제 오바마를 만나긴 글렀나? 5명짜리 스타트업이건, 10,000명짜리 대기업이건 내 첫 반응은 늘 비슷했다. 큰일났다. 다 바꿔야겠어!

하지만 잠시 숨을 고르자. 저 1점짜리 앱 스토어 리뷰들에서도 진실을 뽑아낼 방법은 있다. 게다가 그 방법은 두 개나 된다.

1. 당신의 핵심 가치를 알아라

여기서 말하고자하는 건 사람들이 당신 제품에 대해 말하는 문제를 무시하라는 것이 아니다. 중요한 것은 그 문제를 어떻게 듣느냐이다. (배트맨 비유 생략) 당신 제품의 모든 것은 당신 제품의 관점을 통해 이루어져야 한다. 페이스북에서 일하며 제품 방향에 대하여 고민할 때를 수없이 만났고, 그 때마다 결국은 우리의 목적으로 돌아가게 되었다. “페이스북은 세상을 좀 더 열리고, 연결된 곳으로 만든다" 이 핵심 선언을 통해 우리는 많은 문제를 접근했다. 

얼마 전 출시된 “Moments”라는 앱의 예를 들어보자. 수 많은 사진 앱이 여러 방식으로 사진을 보여준다. 우리도 쉽게 따라쟁이가 되어 비슷한 앱을 만들 수 있었지만 우리는 우리의 방식으로 앱을 만들기로 했다. “친구들에게 쉽게 사진을 주고, 사진을 쉽게 받는다". 이 앱은 페이스북 앱이기 때문에, 사람과 사람을 연결하는 것은 그 어떤 것 보다 큰 가치를 가졌다.

당신의 회사의 가치를 배반하는 제품을 만들지 말길 바란다. 당신의 제품은 왜 존재해야 하는가? 어떤 문제를 해결하고자 하는가? 확실하지 않다면 답을 얻을 때 까지 계속 고민하라. 

핵심 가치를 먼저 알면, 수많은 의견들을 헤치고 지나갈 등불을 얻게 된다. 어쩌면 저기서 누군가가 소리치는 그 말이 맞을 지 모른다. 하지만 당신만의 관점을 통하지 않는다면 그 안에서 사실을 발견하기란 굉장히 어려울 것이다.

2. 의심이 들땐, 세어라

두 번째 교훈은 사람들이 어떻게 의견을 형성하는지, 그리고 그들이 어떻게 이야기하는지 아는 것에서 출발한다. 

극단적인 의견을 말하는 사람들이 조금 더 크고 빠르게 말하며, 스스로가 다수 의견이라고 착각하는 경향이 있다는 스탠포드 대학의 연구 결과가 있다. 이들은 스스로가 대중을 대변한다고 생각한다. 실제로 그렇지 않을 때에도 말이다. 새로 만든 Sprocket 완전 구려! 다 싫어한다고! 옛날걸로 바꿔!

하지만 이런 의견들은 틀리는 경우가 많다. 실제로 제품을 쓰는 사람들의 의견은 전혀 다를 때가 많다. 그러니 (사람들을) 세라, 일찍, 자주 세라. 데이터는 당신이 어떤 의견을 들어야 할 지 알려준다. 그리고 의견은 어떤 데이터를 읽어야 하는지 알려주기도 한다. 

당신이 제품을 만들기 전이건, 만들고 난 후건, 데이터는 유용하다. 특히 만든 뒤는 더욱 그렇다. 사람들이 어떻게 당신이 쓴 글을 읽고 공유하는지, 당신이 만든 제품을 어떻게 사용하는지 알아보는 건 신뢰할 수 있는 방법이다. 어떤 데이터를 읽어야 하는지를 아는 것도 힘든 일이다. 이럴 땐 당신의 제품이 가지고 있는 핵심 가치를 아는 것이 도움이 된다.

위의 그래프에서 내 머리 모양의 핵심가치가 “어머니와 여자친구를 기쁘게 한다" 라면 잘 깎은 셈이 되지만, 만약 모든 사람들을 다 만족시켜야 하는 상황이라면 머리를 다른 스타일로 깎아야 할 것이다. 

좀 더 구체적인 예를 들어보자, Facebook 제품 지원 팀에서 우리는 매년 더 많은 사람들을 만족시키기 위해 노력하고, 그 기준은 얼마나 많은 사람들이 만족했느냐로 측정된다. 하지만 때때로 다수가 아니더라도 문제가 중요해질 때가 있다. 자해나 자살을 실제로 말하는 사람이 많지 않지만 그 경험 자체가 굉장히 심각한 것이기 때문에 우리는 이들이 그런 상황에서 실제로 친구나 전문가에 연결될 수 있도록 하기 위해 많은 공을 들였다.

만들기 전에 세는 것도 도움이 될 수 있다. 1년쯤 전에 우리는 인도 같은 나라에서 사람들이 페이스북의 안드로이드 버전을 어떻게 사용하고 있는지 알아보았다. 흥미로웠던 점은 Wi-Fi가 끊어지면 바로 비행기 모드로 들어가서 데이터를 차단한다는 것이었는데, 한달에 30메가 정도밖에 모바일 데이터를 쓸 수 없기 때문에 민감하게 반응하고 있었다. 이런 데이터를 통해 우리는 이 앱이 오프라인에서 어떻게 작동해야 할지 설계하는데 공을 들였고, 2g 네트워크에서는 작은 이미지를 보내는 식으로 퍼포먼스를 많이 향상시켰다. 그리고 이런 것들은 데이터 환경이 열악한 개발 도상 국가에서는 큰 차이를 만들어 낸다.

데이터를 효과적으로 쓰라는 말은 직관 대신 엑셀만 쓰라는 이야기도 아니고, 핵심 가치를 알라는 말은 앞뒤옆도 돌아보지 말라는 이야기도 아니다. 주변의 이야기는 들어야 한다. 하지만 어떻게 들어야 하는지에 대해 조금만 더 현명하게 생각할 줄 안다면, 어떤 문제를 해결할지에 대해서도 조금 더 현명해질 수 있다. 어쩌면 당신이 만드는 제품이 문제 자체를 잘못 설정한 것일수도 있다. 시지프스에게 좀 더 나은 손수레를 줄 것이 아니라, 바위 자체를 없어버리는 게 더 나은 방법인 것 처럼 말이다.

(끝)

--

피드백은 정말 다양한 방식에서 들어온다. 디자인은 때로 이미지 한장으로 표현되지만, 그 이면에는 많은 의사결정들이 들어있다. 그냥 만드는 디자인은 없다. 하지만 그 배경을 제대로 설명하지 못한 채 이미지만 보여주게 된다면 온갖 레벨에서의 다양한 피드백이 들어오게 된다. 물론 피드백은 좋은 것이다. 어쨌든 상대도 의견을 주는 데 시간이 든다. 

하지만 모든 의견을 그대로 다 따를 순 없다. 흔히 받는 피드백들에는 이런 것들이 있다.

“초록색이 이상해요.”

“버튼이 좀 더 둥글었으면 좋겠어요.”

와 같은 의견은 그 자체로는 아무것도 아니다. 정말 이상한 초록색이라면 모를까, 그것만으로는 좋은 피드백이 될 순 없다. 이것들은 초록색이 제품을 사용하는 경험에 어떤 영향을 주는가? 둥근 버튼은 어떻게 메뉴 인식에 영향을 주는가? 와 같은 질문으로 변형되어야 하며, 계량화될 수 있다면 계량화되어야 한다. 그렇지 않고서는 마음아픈 악담으로만 남게 된다. 초록색을 저 의견에 맞게 바꾸면, 누군가는 또 색깔에 대해 의견을 낼 것이다. 당신이 모두를 만족시킬 완벽한 초록색 rgb값과 버튼의 radius를 찾을 수 있을 지는 모르겠지만, 그것은 결국 당신 제품에 어떤 가치를 주게 되는가? 

어도비 리드 디자이너였던 Andrei Herasimchuk이 쓴 글. 간단하게 요약해보았다. 간단 요약이기 때문에 늘 전문 확인을…

–

디자이너는 코드를 배워야 할까? 흔한 질문이지만 이 질문에 답을 내기 전에 내(Andrei) 개인적인 이야기를 좀 해보려고 한다.

나는 어도비에 처음 입사한 이후 인터페이스를 디자인하며 어도비의 모든 프로그램이 같은 인터페이스를 공유하면 어떨까 하는 생각을 하게 되었다. 아는 사람도 별로 없었기에 매일 밤 나인 인치 네일스를 틀어놓고 사무실에 쳐박혀서 디자인 작업에 몰두했고, 어느 날 밤 꽤 괜찮은 단계에 진입했다. 그리고는 입사 전 늘 하던대로 매크로미디어 디렉터를 열고 스크린샷들을 이어붙여 움직이게 만들었다. 메뉴가 열리고 버튼이 켜지고 꺼지며, 팔레트가 드래그되는 등 거의 가벼운 프로토타입에 가까운 수준이었다. 최근에 인비젼이나 프레이머같은 툴로 디자이너들이 하듯, 아이디어를 정적인 목업 이상의 것으로 구현하는 작업이었다.

디자이너가 되기 전, 나는 극장에서 일했는데 디렉터, 혹은 프로덕션 디자이너 역할을 했다. 극장에서도 비슷한 수순으로 일했다. 아이디어를 그려내고, 다듬고, 스케일 모델을 만들고, 다시 다듬고, 그리곤 실제로 만든다음 관객들에게 보이기 전에 한번 리허설 하는 - 그 모든 작업들이 당연하게 느껴졌었다.

1995년 그 주말에, 나는 Lingo Script 를 붙들고 48시간을 꼬박 보내며 목업을 살아 움직이게 만들었다. 초기 프로토타입을 보고 꽤 흡족했다. 픽셀-퍼펙트한 목업이 있었고 그것으로도 변화를 설명하는 데 충분했을 지 모르겠지만, 인터랙션이 가미되면서 훨씬 더 좋아졌다. 그게 프로토타입이 해야 하는 일이었으니까.

다음 주에 프로덕트 매니저들이 찾아왔고, 기쁜 마음으로 지난 주에 고생해서 만든 “프로토타입"을 보여주었다. 메뉴를 클릭해서 메뉴가 오픈되고, 팔레트를 실제로 드래그하자 사람들의 눈이 빛났다. 들어온지 얼마 되지 않았기 때문인지 모르지만, 그게 좋은 일이라고 생각했고, 스스로가 꽤 자랑스러웠다.

그리고 그 일이 일어났다.

한 프로덕트 매니저가 굉장히 기뻐하면서도, 잠시 말을 멈추더니 “Andrei, 이건 굉장히 좋긴 한데… 사실 새 디자인 제안하면서 이렇게까지 한 사람은 없었거든요. 이거 얼마 정도 걸렸어요?”

난 어깨를 움츠리며 “그렇게 오래 걸리진 않았어요. 주말하고 며칠 좀 더 정도…” 

그러자 그들은 “정말 고생 많이 했는데, 사실 이정도로 할 필요는 없어요. 그냥 스크린샷만으로 충분했는데, 굳이 이렇게까지 할 필요 없어요.” 라고 했고, 여기서 나는 실수를 하고 만다. 치명적인 실수 말이다.

“아.. 네 그래요 ㅎㅎ"

그 후 어도비에서 일하면서 다시는 프로토타입을 만들지 않았다. 

누굴 지적하고자 하는 생각은 없다. 그냥 그렇게 하지 못한 것이 후회될 뿐이고, 이제 와서 다시 하자니 예전에 하던 대로 되질 않아 답답하다. 조금 더 일찍 이런 작업 프로세스를 정착시킬 수 있었지만 그렇게 하지 못했다. 

다시 질문으로 돌아가자. 디자이너들은 코딩을 배워야 할까?

내 답은 “당연하다” 이다. 특히 당신이 이 직업을 진지하게 “경력"으로 생각한다면. 하나 덧붙이자면 HTML+CSS는 코딩이 아니다. 그냥 기본적인 스크립팅일 뿐이다. 배워둬라. 솔직히 말하면 스케치나 포토샵 쓰는것 보다 쉽다. 그리고 자바스크립트를 배워라. 자바스크립트를 잘 하게 되기 전까지 다른 모든 것들은 무시해라(이건 사실 최근 주변의 탑 엔지니어들에게 얻은 조언이다). 

테크 제품을 만드는 것을 경력으로 삼고 싶다면 코딩을 배워라. 그게 아니라도 직업을 구할 수 있겠지만, 그건 그냥 직업일 뿐이다. (둘 간의 차이는) 이러하다. 직업은 주로 시장이나, 회사 상황, 그리고 단기간의 프로덕트 트렌드에 휘둘린다. 경력은 당신이 더 오랜 기간동안 쫒을 수 있는 것이다. 어쩌면 평생을. 경력은 돈이나 포지션이 줄 수 없는 즐거움을 준다. 죽어서 이걸 더 이상 못한다고 생각하면 가슴이 아플 정도로.

당신이 만약에 디지털 제품을 만드는 디자이너를 경력으로 생각한다면, 코드의 기술을 익히기 위해 뭐든 해야 한다. 지식을 익히면 익힐수록 남에게 기대는 것이 아니라 자기 스스로 제품을 만들 수 있게 된다. 그리고 사실 그게 당신이 디자이너가 된 이유가 아니던가? 세상에 없던 무엇을 만들기 위한 것?

당신이 디자이너로서 느끼게 될 중독은, 세상에 존재하지 않던 어떤 것을 만든 다음의 기분일 것이다. 누군가의 손을 빌려 만드는 것도 보람있긴 하지만 결코 같은 경험은 아니다. 마치 레이싱 카의 조수석에 앉는 것과 직접 운전하는 것의 차이라고 할 수 있다. 혹은 15분 동안의 인도어 스카이다이빙을 하는 것과 비행기에 직접 뛰어내리는 차이 등등. 

직접 당신의 두 손으로 뭔가를 만드는 일은 초능력이다. 대체 왜 그걸 그냥 내주는가? 코드는 디지털 제품을 만드는데 있어 결정적인 구성 요소이다. 어떻게 돌아가는지 모르는 채 일하는 건 장님처럼 눈 감고 일하는 거나 마찬가지이다. 

당신은 경력 내내 코딩을 배울 수 있다.

물론 사람들은 2주만에 코딩을 마스터하고자 한다. 혹은 일주일 만에 20파운드를 빼고 싶어 하기도 하고, 연습도 안하고 기타를 연주하고 싶어한다. 두렵겠지만 이건 당신의 경력이다. 할 수 있을까? 잘하게 될까? 일이 너무 많은데 같은 생각은 하지 말고, 그냥 오늘, 당장 시작해라. 

나는 이렇게 일하는 것이 얼마나 뿌듯하게 느껴지는 일이 될 지 약속할 수 있다. 그 누구에게도 이 기회를 빼앗기질 말길 바란다.

–

Andrei Herasimchuk가 후속 트윗에서 말하듯, 코딩이 좋은 디자이너를 만들어 주진 않는다. 이건 그냥 디자이너가 갖추어야 할 여러가지 소양 중 하나일 뿐이다. 코드를 짤 줄 알면 무조건 좋은 디자이너가 된다는 식으로 읽히지 않길 바란다. 디자인에는 여러 층위가 있고, 여러 기술이 필요하다. 하이레벨의 컨셉, 리서치, 비쥬얼 폴리싱, 그 어느 하나 코드보다 떨어지는 영역이 아니다. 재료는 잘 굽는데, 색을 엉망으로 뽑는다면? 아니 애초에 만들 필요가 없는 제품을 만든다면? 

페이스북 디자이너인 Beth Dean이 쓴 글. 그 동안 제품 디자인에 있어 간과되어왔던 “감정" 혹은 “감성"의 존재를 환기시키는 글이다. 간단하게 정리해본다. 

*아래 글은 완전 번역본이 아니기 때문에 상세한 내용을 보시려면 꼭 링크를 방문해주세요.

--

사람들의 “웹에서의 삶"은 실제 삶과 꽤 괴리되어있다. Beth가 그걸 처음으로 느낀 건 그녀의 어머니가 사망하고 난 뒤였다. 어머니는 돌아가셨지만 매해 생일이 다가올때마다 선물 추천 이메일이 메일함에 들어왔다. 이제는 익숙해졌지만 처음에는 고통스러웠다. 사례는 이 뿐만이 아니다. 장례를 치르러 떠나는 여행에 프로모션 추천을 날려야 한다던가, 사고 후 보험처리를 받을 때 과거의 기억이 떠올라 고통스러워지는 사용자를 보면 무언가 빠져있다는 생각이 드는 것이다. 사람들은 온라인에 접속해서도 여전히 사람들이다. 감정이 사라지진 않는다는 이야기이다.

수년 동안 우리는 소프트웨어를 중립적인 도구로만 생각해왔다. 하지만 사람들은 소프트웨어를 사용할 때 사람을 대하듯 한다. 디자인 할 때의 접근 방식도 바뀔 필요가 있다. 마치 옆에 있는 다른 사람이랑 대화할 때의 느낌을 평가하듯, 소프트웨어의 사용 경험도 같은 선상에서 평가되어야 한다. 관계를 핸들링하고 감정을 읽어내는 능력을 감성 지능(Emotional Intelligence)라고 한다. 그리고 소프트웨어 디자인에는 감성 지능이 결여되어 있는 경우가 많다.

감성 지능의 5가지 영역

자각 능력 (Self awareness)

감성 관리 (Self regulation)

동기 (Motivation)

공감 (Empathy)

대인관계 (People skills)

자각 능력

(아직까지는) 소프트트웨어는 감정이 없기 때문에, 감성을 자각하기 힘들다. 사람들에게 표현되는 건 결국 디자이너가 설계한 명시적인 무엇이거나, 사용자가 실제 사용하며 느끼는 묵시적인 감정일 것이다. 페이스북 광고 설정을 예로 들면, 설정 메뉴들을 나열하는 것 이전에 의도를 먼저 설명한다. 사람들은 어쩌면 영원히 광고 설정 메뉴를 조작하지 않을 수도 있다. 결정하지 않는 것에서 생기는 경험을 인식하는 것은 힘들다. 

결국은 관계를 만들어나가는 것이고 관계에서 감정은 급격히 바뀌기도 한다. 

정부가 만든 소프트웨어와 사용자가 상호작용하는 것을 상상해 보자. 마치 젖은 수건을 바닥위에 그냥 두었거나 쓰레기 버리러 나가는 것을 잊은 것 처럼 무신경하게 생기는 일들이 사용자의 감정을 자극할 수 있다. “왜 이게 안되는거야!” 라는 사용자의 감정은 진짜다. 

감성 관리

소프트웨어가 중립적이라면 모든 상황에서의 논리적 결과물을 이해할 수 있을지는 몰라도, 가치를 부여할 수는 없다. 그냥 “했다" “안했다' 정도로만 상황을 이해하면 그 이면에 있는 감정은 무시되는 것이다. 

간단한 예를 들어보자. Beth의 친구는 한 사이트에서 연락처를 ‘긁어가는' 기능을 사용했다. 당연히 자동으로 모두 연결될 줄은 모르고 말이다. 그녀는 친한 사람들 이외에 거의 연락을 안하던 사람들에게까지 모두 연결되어버렸고 그 중에는 그녀가 다시 말을 섞고 싶지 않은 사람도 있다. 숫자는 올라갔지만 과연 그 올라간 숫자가 사용자가 사이트로 다시 돌아오는 데 도움을 줄까?

동기

사용자의 동기를 파악하는 데에는 입장을 바꿔보는 것이 도움이 된다. Beth는 한때 살이 굉장히 많이 찐 적이 있다. 그리고 옷을 사러 갔을 때 맞는 사이즈가 하나도 없는 것을 알고 이 세상이 나를 위해 디자인 되지 않았다는 것을 깨달았다. 가게가 그녀를 거부하는 것 처럼 느꼈고, 그녀의 몸이 다른 사람들의 몸 보다 못하다는 인식을 받게 되었다.

다양한 관점을 얻는 데 도움이 되는 건 다양한 배경의 팀원과 일하는 것이다. 다양한 관점을 가지고 제품을 만들면 놓치는 부분이 적어지고 실제 사람들이 필요로 하는 것을 줄 수 있게 된다. 

공감

디자이너는 사용자가 아니다. 만드는 의도가 A라고 해도, 사용자는 아예 판이하게 사용할 수 있다. 그리고 그건 실제 사용자를 만나서 테스트 해보기 전까지는 절대 모른다. Beth의 어머니가 돌아가신 뒤 양아버지는 매년 생일이나 크리스마스 때 특정 상표의 기프트 카드를 준다. 돌아가신 어머니가 좋아했기 때문에 그녀도 좋아할거라는 추측으로 준 것이지만 사실 Beth는 그 상표를 좋아하지 않는다. 

의도는 선했지만, 받는 사람은 선물한 사람의 의도대로 움직이지 않는다.

대인관계

제품의 목소리는 어떠해야 하는가? 사용자와의 관계에서 소프트웨어는 어떤 사람인가? 선생님? 친구? 사용자가 최악의 상황에 놓였을 때 어떻게 대처해야 하는가? 어떤 것을 선택하면 다른 것을 내려놓게 된다. 어떤 것을 내려놓게 되었는지 아는 것은 굉장히 중요하다. 당신이 어떤 걸 엣지 케이스라고 칭하는 순간 그것이 당신이 친 경계선이 된다. 스트레스 케이스라고 부르는 것이 합당할 것이다. 페이스북에서 한해 돌아보기 기능을 내놓았을 때, “아주 좋은 한해를 보내셨군요!” 라고 말하며 딸이 사망한 포스트를 포함한 것 같은 게 그 예이다. 무언가를 놓치면 그것으로 인해 누군가는 상처를 받게 된다.

잘 콘트롤 된 상황에서 제품은 잘 동작하기 마련이다. 실제로 바깥에 나갔을 때 얻는 결과들에서 우리는 가정에 대한 답을 얻을 수도 있을 것이며 답해야 할 질문들을 새로 찾을 수도 있을 것이다.

(후략)

--

아직까지 많은 디지털 제품은 무신경하고 사람들은 때로 그걸 너무 당연하게 여긴다. 

한 연예인이 자신의 구글 검색 결과에서의 프로필 사진이 아버지 장례식에서 찍힌 사진이라고 분노할 때, 몇몇은 “그게 기계가 하는 일이니 어쩔 수 없지 않나" 라고 말했다. 하지만 본인에게는 큰 상처였을 것이고 그건 분명히 고쳐질 수 있는 일이다. 그리고 고쳐졌다.

헤어진 연인이 친구 추천에 뜬다던가, 남이 올린 혐오 게시물을 “피드에 있다”는 이유만으로 봐야 하는 게 당연한 일은 아니다. 무신경하게 오는 상품 추천 메시지, 사용자의 화면을 갑자기 가려버리는 광고들은 모두 어떤 인격을 상징한다. 사람이었다면 어땠을까? 당신은 무례하게 끼어들어 전단지를 주는 사람에게 웃으며 대응하는가?

나온지 꽤 된 폰이지만 제법 사용했기에 소감을 남겨본다

디자인이 가장 멀쩡한 갤럭시라는 것에 동의. 전체적인 폼팩터가 안정적이고, 잡는 느낌도 좋은 편이다. 

카메라는 이제 어지간한 컴팩트 카메라 수준인 것 같다. 물론 최근에 나오는 괴물 똑딱이(RX100)들은 논외로 하고... 아이폰6와도 결과물에서 확연한 차이가 난다. 야간 샷도 발군. 이젠 정말 카메라가 필요 없겠다.

터치위즈, 정말 많이 좋아졌다. S3부터 이어진 고리타분한 비쥬얼과 무거운 스킨이 날아갔다. 테마 스토어에 있는 Material Design 스킨을 입히면 얼추 순정 안드로이드 느낌도 난다. 예전에는 기본 앱들을 안쓰는 것은 물론이고 숨기기 바빴는데 몇개는 정말 그냥 써도 될 정도.

성능이 발군이라고 하는데, 구동 속도나 사용 중 속도는 굉장히 빠르다. 부드러운 느낌보다도, 그냥 힘으로 밀어부쳐 빠르게 돌아가는 느낌이다. 하지만 넥서스6와 큰 차이가 있는 것 같진 않다. 게임을 하지 않기 때문인지 몰라도 요즘 나오는 폰들은 대부분 다 빠르다.

화면은 QHD인데, 뚫어져라 보지 않는 이상 ppi가 크게 와닿지는 않는다. 하지만 굉장히 밝고, 발색도 좋아서 여태까지 본 그 어떤 스마트폰 디스플레이보다 좋게 느껴진다. 아이폰6에서 느꼈던 스티커 같은 느낌이 강화된 듯.

지문 인식 센서는 정확한 편이고 굉장히 빠르다. 다만 완전한 원형인 아이폰에 비해 손가락이 커버되지 않는 영역이 있는데 이 때문에 잡는 위치에 따라서 인식 실패가 되는 경우가 잦다. S5의 없느니만 못한 지문센서에 비하면 천지개벽 수준의 변화이긴 하다.

그 외 단점:

소프트웨어는 여전히 큰 단점이다. 널리 알려진 바 있듯 갤럭시엔 안쓰는 편의기능들이 참 많다. 이번에 터치위즈 경량화를 했다고 하는데, 그러면서 설정 옵션들도 대거 삭제되었다. 덕분에 안쓰는 편의기능들을 끌 수 있는 방법이 사라졌는데 그 대표적인 예가 멀티 윈도우 모드다. 화면의 가장자리를 쓸어내리면 화면이 작아지면서 멀티 윈도우 모드가 실행되는데 이게 알림 영역을 보는 제스쳐와 비슷하다. 그래서 알림영역을 보려다가 윈도우가 작아지는 경우가 꽤 많이 생긴다. 끌 수가 없으니 더 답답하다.

안드로이드를 커스터마이즈하면서 생기는 부수적인 문제들이 있다. 대표적인 예가 위젯인데 대부분의 음악 앱의 경우 레이아웃이 깨진다. 잠금화면에 앨범 커버 배경화면이 나오지 않는 문제도 있다. 이런건 그냥 애교로 넘긴다고 해도 치명적인 문제가 있는데 그게 바로 멀티 태스킹이다. 롤리팝 5.1에서는 대부분 해결된 문제인데 내 갤럭시 S6는 아직도 5.0.2이다. 몇번 앱 사이를 왔다갔다하면 대부분 새로 시작한다. 사용이 불가능할 정도는 아니지만 짜증은 난다.

갤럭시 S3,S4,S5를 모두 사봤지만 사실 한달을 넘기지 못했다. 그 중 S5가 최악이었는데 사자마자 후회했다. 덕지덕지의 끝이었던 터치위즈와 충격적으로 못생긴 하드웨어, 방수 기능을 위한 타협 치고는 너무 끔찍한 외관이었다. S4가 그나마 괜찮았지만 소프트웨어는 아무리 가리고 숨겨도 신경쓰일 정도로 못생겼었다. 커스텀 런처를 쓰고 아이콘을 다 바꾸면 그나마 낫다고 하지만 윈도우에 테마질 하는 느낌이라 결국 포기하고 팔아버리곤 했다.

이번 S6는 내가 돈 내고 산 제품은 아니지만 꽤 오래 쓸 수 있을 것 같은 느낌이다. 사실 지금 쓰면서도 큰 불만은 없다. 멀티 윈도우만 끌 수 있으면 그냥저냥 계속 쓸 것 같다.

다만, 안드로이드 커스터마이즈에 대해서는 할말이 많은데, 사실 진저브레드나 프로요까지만 해도 이게 순정으로 쓰기 참 곤란한 수준이었기 때문에 너도 나도 커스터마이즈를 했고 그게 잘 먹혔다. 문제는 2015년인 지금까지 이걸 하고 있다는 건데, 스킨 좀 적당히 입히고 다른 데 힘쓰면 좋겠다. 

“왜 노력을 들여 안드로이드를 더 나쁘게 만드냐"라는게 내가 늘 하는 말인데, 커스터마이즈를 하지 말라는 이야기가 아니고, 커스터마이즈의 방향이 문제라는 이야기이다. Oneplus나 모토롤라처럼 플랫폼의 장점을 흡수하면서 그 위에 자신들이 잘하는 걸 얹는 방향이 좋아보인다. 그 어마어마한 인력으로 제품을 더 좋게 만들 수 있는데 이상한 곳에 힘을 쓸 이유가 없다. 예를 들어 구글 캘린더랑 비슷한거 굳이 하나 더 안만들고, 다른 쩌는 킬러 앱을 만드는게 나을 것 같다.

제품이 출시되고 나면 후기들이 제법 올라온다. 개발자들도 마찬가지겠지만, 디자이너들도 작업기를 올리곤 하는데, 읽어보고 소개하지 않은 작업기들이 꽤 쌓여 한꺼번에 소개해 본다.

Moments 앱 작업기 by Laura Javier

https://medium.com/facebook-design/designing-moments-2b5362430125

: 얼마 전에 공개된 Facebook의 사진 공유 앱 “Moments”의 작업기이다. 왜 프로젝트가 시작되었는지부터, 앱의 상세한 구조까지 직접 디자인 한 당사자가 찬찬히 설명하고 있다. 무엇보다 좋은 부분은 “교훈" 부분인데, 간략하게 소개해본다.

솔루션보다 문제 자체에 빠져들어라 : 성공적인 디자인 프로세스를 위해서는 정말 많은 단계의 iteration이 필요하다. 첫 번째 솔루션이 최종 결과물이 되는 경우는 드물다. 처음 생각난 기발한 아이디어에 집착하지말고 꾸준하게 다듬어나가라.

단순하게, 더 단순하게, 더 단순하게, 조금 더 단순하게 : 디자인하는 제품을 명료하게 설명할 수 없다면, 잘못된 방법으로 접근하는 것일지 모른다. 아이디어들이 아무리 기발하더라도, 우선순위를 정해서 단순하게 만드는 것이 중요하다. 많은 걸 한꺼번에 하려면 명확해지지 못한다. 

가정을 점검하라 : 제품 개발의 중심을 잡는데 있어 유저 리서치는 필수적이다. 제품 구상시에 했던 가정을 일찍, 그리고 자주 점검해야 한다. 때로는 레이아웃이나 버튼 이름을 검증하기도 하지만, ‘왜 공유를 안하려 하는가’ 같은 인간관계적인 질문들도 한다. 이렇게 실제 사용자들의 의견을 꾸준히 듣는 것은 디자이너의 본능만 따라가는 것을 막아주고, 더 빠르게 제품을 다듬을 수 있게 해준다.

출시는 시작일 뿐이다 : 제품을 잘 만들기 위해 많은 노력을 한 뒤 출시했지만, 그 노력이 잘못되었을 수 있다는 생각을 잊지 말아야 한다. 제품을 출시한 후에 더 많이 배우고, 제품을 발전시킬 수 있다.

Google Chrome 리디자인 작업기 by Sebastian Gabriel

https://medium.com/google-design/redesigning-chrome-android-11eab15dc7ee

: 방대한 양을 자랑하는 작업기. 심지어 2부도 있다고 한다. 앱이 구동되는 플랫폼부터, 회사 전체에 녹아있는 디자인 언어, 그리고 실제 콘텐츠가 얹혀지는 상황까지 자세한 사례와 함께 소개하고 있다. 실제 그래픽 에셋과 함께 사례를 소개하기 때문에 전부 소개하기가 힘들긴 하지만, 인상적인 부분을 몇가지만 소개해 본다.

새로운 버전의 가장 큰 디자인 변화는 앱 자체의 리디자인이 아니라, 플랫폼의 변화에 따라가는 것이었음. 안드로이드 L로 들어서면서 크롬의 탭이 다른 앱 목록과 같이 표시되는 구조로 바뀌었기 때문임. 하지만 동시에 L 이전 버전도 지원해야 했기 때문에 두 UI 모드가 일관된 look & feel을 가지도록 신경썼음. 

크롬은 브라우저이고, 브라우저 안에 있는 콘텐츠가 주인공이기 때문에 UI의 변화를 거의 느끼기 힘들 정도로 살짝씩 주긴 하지만, 그럼에도 작은 부분에서 분명한 변화를 줌. 코어 스타일에서, 컬러 스킴, 아이콘까지 전체 시스템과 잘 어울리면서도 콘텐츠를 방해하지 않도록 세세하게 신경을 썼음. 특히 헤더같은 경우 웹 개발자들이 직접 컬러를 커스터마이즈할 수 있게 해서, 콘텐츠와 크롬이 더욱 조화롭게 보일 수 있도록 배려함.

마테리얼 디자인은 디자인의 출발점이지 끝이 아니었음. 원칙과 핵심 요소들은 그대로 가져오되, 제품에 필요하다면 그래픽 에셋을 새로 디자인하기도 했음. 

“Rooms” 검색 기능 디자인 작업기 by Julius Tarng

https://medium.com/facebook-design/designing-search-for-rooms-f48985ba5cad

: 올 2월에 발행된 글이니 꽤 지난 글이지만, 한번 소개해야겠다고 마음먹고 그냥 지나쳐버린 글이라 이 기회를 빌어 다시 꺼내본다. 앱 자체는 성공적이라고 하기 힘들지만, 새로운 기능을 붙일 때 어떤 자세로 접근하는지 잘 보여주는 글이다.

검색 기능을 붙일 때, Parse를 활용해서 직접 검색 기능을 구현했음(실제 Rooms가 Parse기반으로 만들어짐). 디자인을 할 때 픽셀부터 깎는 게 아니라, 데이터가 어떤 순서로 보여져야 하는지, 어떤 정보가 중요한지 실제 데이터로 실제 검색을 해가면서 작업해 나갔음. 

애니메이션은 Origami를 활용해서 High-Fidelity로 작업했음. 검색 후 진입점을 보여주고, 테이블 뷰로 전환된 후 다음 뷰로 넘어가는 플로우 하나를 위해 수많은 버전들을 만들어가며 어떤 느낌이 가장 적합한지 테스트함.

작업을 끝냈다고 해서 손을 놓지 않고, 한동안 계속 써보면서 다듬는 기간을 가짐. 특히 검색 결과 페이지에서는 아이콘과 텍스트를 섞어가며 어떤 것이 가장 명확하게 사용자에게 의미를 전달 할 수 있는지 테스트해봄. 

--

비슷한 내용이 반복되는데, 이 글들에서 다시 중요한 부분을 몇 가지 추릴 수 있을 것 같다. 다시 한번 정리해보면...

디자인은 반복 작업이다. 첫 번째 솔루션이 마지막 결과물이 될 수 없다.

(디자인) 가설은 검증되어야 한다. 빨리, 자주.

실제 데이터, 실제 사용자가 중요하다.

디자인 가이드라인은 출발점이다, 콘텐츠와 플랫폼을 같이 생각해야 한다.

출시 (개발완료) 가 진정한 시작이다. 실제 피드백이 들어오는 순간을 놓치지 말아야한다.

예전에 읽었던 ‘목폴라를...’ 처럼 글로만 읽는 것이 디자인 작업은 아니다. 오히려 그 반대일 것이다. 나부터도 작업을 할 시간에 글을 쓰고 있는 것이 바보같게 느껴질 때가 있지만, 작업기를 정리하고 느낀 점을 공유하는 것은 중요하다고 생각한다. 바깥에 공유해서 남에게 알려주는 것도 큰 목적이지만, 자기 스스로 정리하는 것도 큰 의미를 가진다. 작업할 당시에 어렴풋하게 느꼈던 부분들을 구체화시키면 같은 실수를 반복하지 않을 수 있고, 잘했던 부분은 더 속도를 내서 잘 할 수 있다. 그만큼 성장하게 되는 것이다. 

뉴욕타임즈에서 한국의 앱 비즈니스가 어떻게 실리콘 밸리와 다른지 조명하는 기사를 냈다. 반향이 꽤 있는 기사여서 간략하게 내용을 소개해 본다. 원문은 링크를 눌러 확인하시길.

뉴욕 타임즈 기사 링크

한국의 인터넷 망은 실리콘 밸리가 상상하기 힘들 정도로 앞서나가 있음. 미국에서 일하다 얼마 전에 한국으로 들어와 일하고 있는 Mike Kim은 “실리콘 밸리에 돌아가면 오히려 암흑기처럼 느껴진다” 라고 이야기하기도. 심지어 이 속도는 점점 더 빨라져서 2020년이 되면 지금보다 1,000배 정도 빨라진다고. 영화 한편을 거의 1초만에 다운로드 받을 수 있는 속도. 한편 미국은 한국의 1/600 속도 정도를 목표로 하고 있음.

하지만 이런 미래적인 면과 대조적으로 디자인 적으로 보면 한국의 앱/웹서비스들은 구닥다리처럼 느껴짐. 마치 90년대를 보는 듯하다고. 대표적인 사례는 카카오톡임. 한게임 창업자인 김범수가 만든 이 서비스는 앱 안에 인터넷이 들어와있는 듯함. 뉴스를 보거나, 친구에게 대화를 하거나, 저녁을 주문하거나 게임을 할 때 모두 이 앱을 사용함. 미국과는 사뭇 대조적인 제작 방식임.

이런 제작 방식의 차이는 네트워크 스피드나, 폰 사이즈에 기인하기도 함. 한국은 인터넷도 빠르고 큰 폰이 인기인 반면, 미국은 그렇지 못하기 때문에 기능을 때려넣기가 힘들기 때문. 이런 환경의 차이 때문에 미국에 진출하고자 하는 한국의 기업들은 어려움을 겪을 때가 많음.

“선샤인"이라는 파일 공유 서비스를 만든 Nicole Kim은 미국 진출 이후 서비스를 더 단순하게 만들고, 작은 사이즈 파일 공유에 적합하게 바꿔야 했는데, 그 이유는 한국이나 홍콩과 달리 미국은 네트워크 속도가 느리기 때문. 

그렇지만 환경 문제에 국한지을 수만은 없음. 2014년에 서비스 밴드(Band)를 미국에 런칭한 Doyoun Kim은 “서비스의 수많은 기능이 사용자들을 헷갈리게 만들었다"라고 자평. 기능이 너무 많아 이 앱이 제일 잘 수행하는 기능이 뭔지 어필하기 힘들었고, 그 결과 외면을 받음. 한국에서는 3천만명이 쓰는 서비스이지만, 미국에서는 별 소득이 없었음. 

미국은 가끔 너무 “기능 하나"에 집착하는 경향이 있는데, 그 결과가 “Yo.”임. 이런 식으로 단순한 서비스가 성공하면, 거의 끝자리만 다른 비슷한 서비스들이 우후죽순으로 생겨남. 예를 들면 “Uber for ㅇㅇㅇ” 같은 식으로.

하지만 한국에서는 이런 식의 서비스보다는 편리함을 제공하는 서비스가 성공할 가능성이 높은데, 쿠팡같은 회사가 그런 예임. 적어도 하루만에, 빠르다면 주문한 그 시간에 식료품이나 기저귀같은 물품을 배송해주는데 이는 인구의 1/5이 서울에 집중된 환경 덕분이 큼. 미국에서는 성장하기 힘든 서비스가 한국에서는 성공함.

--

이후 실리콘 밸리가 한국(서울)에서 배울 점들을 나열하고 있는데, 1) 폰에서 바로 결제가 가능하고 광고 이외에 디지털 제품(스티커)으로 실제 수익을 거두는 점, 2) 시작부터 다른 나라로의 진출을 염두에 두는 점(내수 시장이 작기 때문에) 3) 새로운 서비스가 가능한 인프라를 갖추는 일 등이다. 

많은 미국 회사들이 이제 새로운 시장에 눈을 돌리고 있다. 페이스북은 internet.org을 설립하여 세계 구석구석에 경량화된 웹서비스를 보급하고 있고, 구글은 풍선을 띄워 인터넷 접근성을 높이려고 하고, 값싼 안드로이드 폰을 판매하기 시작했다. 애플은 중국 시장을 위해 금색 폰을 만든다. 미국은 그 동안 자신들의 관점으로 제품을 만들어도 충분히 잘 팔아왔지만, 성장의 정체를 피하자면 결국 시장을 확장해야 하는 것이다.

서울의 몇몇 회사들은 자신의 성공을 그대로 미국 시장에서 재현하고자 했지만, 처절하게 실패했다. 인터넷이 상대적으로 느리고, 사용자들이 복잡한 기능을 제대로 이해하지 못한다는 점은 어찌보면 실리콘 밸리의 회사들에게도 공통적으로 적용될 수 있는 이야기일 것 같다. 그들이 목표로 하는 시장은 미국보다 인터넷이 느리고, 문화도 완전히 다르다. 한국의 고전에서 교훈을 얻어 다른 접근을 하려는 노력이 필요할 것이다.

--

한가지 동의하기 힘든 부분은 한국의 앱 / 웹 디자인이 왜 그렇게 복잡하고 정신없는지에 대한 분석이다. 인터넷 속도가 빠르고, 큰 폰이 많기 때문에 많은 기능을 표현하기에 충분하다는 이야기인데... 그것만은 아닐 것이다. 나는 오히려 그것이 주된 이유가 아니라고 생각한다.

언젠가 외국 디자이너에게 “삼성폰의 UI컬러와 아이콘들은 너무 끔찍하다"라고 이야기했을 때, “이유가 무엇인것 같냐”는 질문을 받은 적이 있다. “아마도 피쳐폰때의 느낌을 그대로 유지하고자 한 것이 아닐까?”라고 답하고 넘어갔지만, 사실은 회사의 조직문화, 의사결정 구조와도 깊은 관계가 있을 것이다.

디자인 전문가가 아닌 사람이 디자인을 실제로 결정하고, 그 과정에서 실무자의 의견이 존중되지 않는 수직적인 의사결정 구조, 쉽게 극적인 변화를 만들기에 어려운 보수적인 분위기가 큰 회사에 팽배해 있고, 이는 자연스레 주류로 자리잡아 다른 작은 회사에게도 영향을 끼친다. “삼성 / 네이버가 했으니까 괜찮아" 같은 이야기는 실제 한국 회사에서 많이 나오는 이야기이다. 그리고 이제 실리콘 밸리에서 “잘했다"고 하는 디자인의 서비스들도 꽤 많이 나오고 있고 그 중 좋은 반응을 받는 서비스들도 늘어나고 있다.

인터넷이 빠르기 때문에 더 많은 정보가 들어가고, 폰이 크다고 기능을 우겨넣을 필요는 없다.

--

텀블러 코멘트에 답을 달 수 없어서 여기에 추가합니다.

Picsplay 2 : http://time.com/3756760/iphone-best-apps-layout-instagram/

TIDY : http://techcrunch.com/2014/02/17/tidy-organizes-your-smartphone-photos-into-albums-with-just-a-swipe/

SolCalendar : http://www.engadget.com/2014/02/13/best-google-alternative-android-apps/