monging's blog

radiofun:

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

8개의 교훈

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

1. 천재적으로 보이는 결과물은 사실 수많은 시행착오의 산물이다.
   
2. 가장 중요한 것은 “보는 눈"을 기르는 것이다.
   
3. 혼자서는 큰 영향력을 주는 일을 할 수 없다.
4. 의도를 모르고는 디자인을 평가할 수 없다.
5. ‘디자인 해주는 사람’이 되기 싫다면, 어떤 문제를 풀어야 하고 왜 그런지 말할 수 있어야 한다.
6. 커뮤니케이션 스킬에 투자를 하면 두 배의 효과를 거둘 수 있다.
7. 누구나 가끔은 “내가 가짜가 아닌가" 하는 생각을 한다.
8. 좋은 디자인은 뻔하다.

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

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

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

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

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

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

• 당신의 안목이 “충분히 좋다"고 가정하지 말아라.
  
• 스스로에게 ‘어떻게하면 이 디자인이 더 나아질 수 있을까?’를 끊임없이 물어라. 실제로 그 결과를 적용하지 않더라도 말이다.
  
• 당신이 아는 가장 비판적인 사람을 찾아내어 피드백을 받아라.
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

우리의 제품을 쓰는 사람들은 우리가 어떤 과정을 통해 이 제품을 만들었는지 모른다. 그들은 그냥 이게 쓸만한지 아닌지만을 따질 뿐이다. 아무런 정보가 없더라도 말이다. 

radiofun:

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

–

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

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

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

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

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

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

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

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

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

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

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

2. 의심이 들땐, 세어라

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

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

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

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

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

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

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

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

(끝)

–

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

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

“초록색이 이상해요.”

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

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

결국 그것들은 한차원 높은 질문으로 이어져야 한다. 나는 이 제품을 왜 디자인했으며, 이 제품은 어떤 가치를 가지고 있는가와 같은 것들 말이다. 결국 이것은 하나의 구조라고 볼 수 있을텐데, 이 구조가 서지 않으면 피드백은 방황하는 칼날처럼 당신 안의 이곳 저곳을 쑤시고 다니게 될 것이다. 

radiofun:

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

–

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

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

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

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

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

그리고 그 일이 일어났다.

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

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

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

“아.. 네 그래요 ㅎㅎ"

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

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

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

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

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

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

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

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

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

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

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

–

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

그럼 그 모든 기술을 다 익혀야 하나? 일하는 곳에 따라서 다르겠지만, 그걸 혼자 다 할 필요도 없다. 이건 이미 소개했던 Cemre의 글에 잘 나와있다. 

radiofun:

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

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

–

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

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

감성 지능의 5가지 영역

1. 자각 능력 (Self awareness)
   
2. 감성 관리 (Self regulation)
3. 동기 (Motivation)
4. 공감 (Empathy)
5. 대인관계 (People skills)

자각 능력

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

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

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

감성 관리

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

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

동기

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

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

공감

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

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

대인관계

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

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

(후략)

–

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

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

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

아직 이 모든 것들은 시작 단계에 있고 대부분의 소프트웨어는 무례하다. 하지만 그게 당연한 일은 아니다.