Dropbox 디자인 수장이 밝히는 "개인화"의 미래 (Dropbox's Head of Design on the Dawn of Personalized Products)

First Round는 그가 말하는 제품 개인화, 그리고 개인화를 이루는 4가지 핵심 요소들을 간략히 소개했습니다. 사용자, 제품 개발/디자인에 대한 깊은 이해가 드러나는 굉장한 글입니다. 전체 글은 제목에 걸린 링크를 눌러 확인하시길.

오늘날의 개인화

  • 개인화는 퍼스널 컴퓨팅이 시작되면서 같이 발전해왔음. 매킨토시의 스큐몰픽 디자인이 바로 그것인데, 폴더와 파일은 실제 생활에서의 그것과 비슷하게 생겼을 뿐 아니라 비슷하게 동작했음. 
  • 지난 10년 동안의 컴퓨터 기술을 통해 우리 이름, 위치, 관심사, 관계를 알아낼 수 있게 되었고, 이 때 Cuervo가 업계에 들어왔음. 페이스북에서 만든 알고리듬을 통해 사용자에 최적화된 경험을 제공할 수 있게 됨. 사람들이 계속 이용할수록 경험이 좋아지게 되는 형태의 UI. 하지만 이제 뉴스 피드도 낡은 생각처럼 느껴지게 됨.
  • 갈 길은 아직 멈. 매일 엄청난 수의 아이폰이 개통되지만, 사람들은 모두 똑같은 시작 경험을 하게 되어있음. 미래엔 제품 개봉과 동시에 사용자의 정체성을 따르게 될 것임(영화 “그녀”의 그것과 비슷할 것).
  • 이미 스타텁 생태계에서 개인화의 새로운 기회들을 확인할 수 있으며, 데이터와 기술은 이미 그 수준까지 도달해 있음. Cuervo는 4개의 요소로 개인화를 정리했는데, 이 요소들을 잘 적용한다면 사람들이 제품이나 다른 사람들과 상호작용하는 방식을 완전히 바꿀 수 있을 것임.

정체성 (Identity)

  • 어떠한 개인화 경험에서건, 정체성은 그 핵심이라 할 수 있음. 여기서 정체성은 이름이나 프로필 사진 같은 것 이상의 개념을 말하는데. 여러 개의 디바이스와 플랫폼에 걸쳐 당신이 내린 결정과 액션들에 의해 진화되는 실체임.
  • 정체성을 정의하고 명확히 한 노력 중 포토 태깅(Photo Tagging)의 예를 들었음. 사진에 다른 사람을 태그하는 일은 작성자 본인 뿐 아니라, 대상이 되는 사람에게도 가치를 만들어냄. 그리고 태그가 되었다는 알림을 받음으로써 자연스레 서로가 서로에게 기능을 알려주는 효과도 얻었음.
  • 실제 세계에서와 달리, 사람들이 하나 이상의 정체성을 가지고 있다는 것을 깨닫는 것도 중요함. 사람들은 서비스에 따라 자신을 굉장히 다르게 정의함. 링크드인과, 인스타그램, 페이스북에서 보여지는 모습은 각기 다름. 서비스는 거기서 표현하고자 하는 정체성을 만족시켜줘야 함.
  • 드롭박스에서는 Dropbox for Business를 출시하며 일 / 개인적인 맥락에 따라 달라지는 정체성을 받아줘야 했음. 즉, 개인 계정(그리고 정체성)을 업무 계정과 분리해야 했음. 사람들의 업무적인 정체성은 회사, 역할, 팀, 그리고 가장 많이 일하는 사람들, 일하기 위해 필요한 정보들로 인해 형성됨. 업무, 사업적인 부분에서는 리듬이 완전히 다름. 조직은 그들만의 정체성과 요구사항이 있는데, 그걸 파악해내야 했음.
  • 스타트업들은 이렇게 사람들의 정체성을 적극적으로 관리해서, 원하는 행동을 하도록 독려해야 함.해시태그, 멘션같은 요소들로 사람들이 트위터에서 돋보이려는 행동을 깨닫고, 서비스의 기능으로 넣어 행동을 강화한 사례 같이, 적극적으로 패턴을 파악해서 적절한 시점에 강화할 필요가 있다는 듯.

그래프 (Graphs)

  • 그래프는 당사자 뿐 아니라, 그 안에 있는 모든 사람들에게도 관계됨. 사람들이 많이 가입할수록, 그래프 자체의 가치가 올라가게 됨. 요즘은 여러 플랫폼에 걸쳐 많은 그래프가 형성되어 있음. 실제로는 별로 관계 없어보일 것 같은 사람들이 같은 그룹에 형성되어 있거나, 유명인을 팔로우하거나, 뉴스를 받아보는데 우리는 이런 모든 관계들을 그래프로 활용하여 개인들에게 최적화된 경험을 제공할 수 있는 것.
  • 드롭박스에 파일을 하나 공유하거나, 핀터레스트에서 re-pin한번 하는 것도 그래프로 볼 수 있음. 이런 경험들이 늘어날수록 데이터와의 관계는 공고해짐. 사람들이 무엇을 원하고, 어떻게 행동할 지에 대한 정보들이 늘어나게 되는 것임.
  • 페이스북 커넥트도 그 일환. 전혀 관계 없는 서비스이지만, 페이스북의 계정을 통해서 로그인하면 친구들도 모두 가져올 수 있고 지금 그 서비스를 통해 뭘 하고 있는지 페이스북에 알릴 수 있음. Runkeeper, Lift, Duolingo같은 서비스들이 페이스북 커넥트를 활용하는 방법을 참고.
  • 나의 제품에 가장 그럴듯한 그래프를 붙이는 것이 중요. 제품 차별화, 유저 관여도를 높이는 데 주요한 효과를 가져올 수 있음.

맥락 (Context)

  • 모바일 덕분에 사용패턴은 엄청나게 많이 바뀌었고, 결국 그 모든 맥락에 맞는 제품을 공급해야 하는 시대가 도래했음. 스마트폰이나 태블릿에서 비슷하게 보이는 것만으로는 부족함. 기기마다 동일한 경험을 하는 것보다, 각 기기에서 사용자가 보이는 행동 패턴을 파악해서 이에 최적화된 경험을 제공하는 것이 관건임.
  • 스마트폰하고 컴퓨터가 고작이었던 시대에서 시계, 안경, 차, 텔레비전같이 디바이스들이 계속 늘어나는 지금, 어쩌면 이것은 가장 중요한 개인화 전략일지 모름. 기기가 늘어나면 늘어날수록, 제품은 뉘앙스를 더 잘 파악할 수 있어야 함. 최근 큰 성공을 거두는 회사들은 여러 플랫폼, 디바이스에 걸쳐 섬세하게 차별화된 경험을 제공하고 있음. 
  • 개인당 한 기기에서 얻어낼 수 있는 정보는 어마어마하고, 이를 토대로 사람들의 관심을 끌어낼 수 있는 능력도 엄청나질 것임. 이미 잠시 자리를 비웠을 때 스마트폰에 잔뜩 쌓인 알림으로 사람들은 짜증내고 있고, 조만간 상황, 장소, 기기에 딱 맞는 정보만을 보여주는 것이 차세대 혁신의 관건이 될 것임.
  • 만일 컴퓨터 앞에 앉아있는 사람과, 회의에 늦은 사람이 폰을 보는 것의 차이를 구별해 낼 수 있다면, 그에 맞는 정보를 제공할 수 있는 기회를 맞게 될 것임. 우버(Uber)의 사례를 봐도 도착까지 몇분 남았는지, 지금 위치는 어디인지 알 수 있는데 이걸 통해 사람들은 차를 탈지 버스를 탈지, 기사가 오기 전에 커피를 한잔 살 수 있을지 없을지 판단할 수 있음. 사용자가 상황을 통제하고 있다는 느낌을 가지고 있지만, 사실은 우리가 그들의 관심을 매우 고의적으로 관리하고 있는 것임.
  • 개인화된 제품을 출시하려는 스타텁들은 여러 기기에서 태스크와 사용자 니즈가 어떻게 달라지는지 주목해야 할 것임. 시계에서는 메일을 어떻게 받을지, TV, 자동차에서는 어떨지. 각 디바이스 별로 사용자의 실제 삶에서 어떻게 작동할지 깊은 이해를 해야 하고, 만일 use case가 그 기기에서 맞지 않다면 밀어붙이진 말아야 할 것.

행동 (Behavior)

  • 사용자가 어떻게 행동해야 할지 결정하는 것에 두려움을 가져선 안됨. 사용자가 뭔가 해야 하는 제품을 만들었다면, 사용자가 그렇게 하도록 만들어야 함. 지금 제공하는 서비스에서 사람들이 뭘 해야 하는지, 강력한 관점을 가지고 밀어붙여야 함. 
  • Nest는 학습하는 UI의 좋은 예인데, 사람들의 행동을 관찰했다가 집에 있는지, 밖으로 나가는지 파악함. 그래서 건물에 들어오자마자 에어컨을 켠다거나 하는 일이 가능함. 이 이면에는 “보통 95%의 확률로 8시쯤 집에 오고, 저녁에는 22도 정도를 좋아할거야” 하는 행동 모델이 있음.
  • Netflix도 좋은 예인데, 통상적인 네비게이션 패턴에서 정교하게 계산된 영화 추천쪽으로 UI를 짜고 있음. 과거의 소비 패턴으로 봤을 때 지금 이 시점쯤에 사용자가 뭘 원하고 있을지 알고 있으므로, 자신있게 추천이 가능.
  • 이런 “automagical”한 경험은 내가 원하기도 전에 내가 원하는 것을 앞에 가져다 주는 놀라운 경험이지만 모두가 좋아하는 것은 아님. 따라서 알아서 계속 기어를 바꾸다가 외면받는 일을 겪지 않도록 밸런스를 잘 맞춰야 함. 예를 들어, “이 사람에게서 온 메일은 대부분 보관함으로 넘기는데, 앞으로는 자동으로 넘겨버릴까요?” 하고 묻듯이, 사용자가 통제권을 가지고 있다는 느낌을 주는 것이 중요함. 

재료 섞기 (Mixing Ingredients)

  • (개인화된 제품을 디자인 할 때) 스크린샷 한장 공유하는 것은 큰 도움이 되지 않음. 이해관계자들(Stakeholder)의 그래프 데이터를 뽑아낼 수 있는 프로토타입을 만들고, 그들에게 개인화된 경험을 제공해야 함. 그렇게 해야 실제 사용자 관점의 경험을 알아낼 수 있음. 페이스북과 드롭박스에서 그의 팀은 내부 테스트를 할 때 이런 식으로 피드백을 받아내었음. 그리고 이것이 최고의 피드백을 받아내는 방법임. 이해관계자들이 그들의 개인적인 시각으로 프로토타입을 경험하게 하는 것.
  • 이미 다른 회사에서 했던 작업들을 가져오는 것도 방법임. 페이스북 커넥트와 같은 API나 리소스는 스타트업에게 큰 추진력을 가져다 줄 수 있음. Timehop같은 앱은 좋은 사례인데, 페이스북, 트위터, 플리커, 인스타그램 등에 남겼던 과거의 컨텐츠를 다시 끌어올려 추억을 다시 찾아볼 수 있는 즐거운 경험을 제공함. 남의 데이터를 가져다 쓴다고 해서 특별한 것을 만들지 못하는 것은 아님.

마지막으로, 다른 서비스와 경쟁하려 말고 사람들의 습관과 경쟁해야 할 것. 시장을 뒤집는 회사들은 사람들의 습관에 도전함. “지금까지 바깥에 나가서 택시를 잡았다면, Uber로 책상에서 택시를 잡아보세요. 길거리 나가서 택시 잡는 습관을 버리세요” 같이. 제품을 만들 때, 사람들이 언제나 지금 뭘 하고 있는지 생각하고, 서비스를 통해 어떤 새로운 습관을 만들 수 있을 지 생각해야 함. 성공적인 테크 회사들은 바로 그걸 해내고 있음.

속 빈 아이콘이 정말 인식하기 더 어려울까? 리서치 스터디 결과 (Are Hollow Icons Really Harder to Recognize Than Solid Icons? A Research Study)

전체 번역은 아니지만, 대부분의 내용을 담은 요약본입니다. 관심이 가셨다면 꼭 원문을 한번 읽어주세요. 멋지게 수행된 탄탄한 리서치라고 생각합니다. :-)

지난 여름, iOS7 발표와 함께 화제가 되었던 속이 빈 아이콘(Hollow Icon)에 대한 이야기가 많이 있었는데, Viget의 디자이너인 Curt Arledge가 간단한 리서치를 통해 진짜 그런지 알아보았음. 방법은, 웹 앱을 만들어서 사용자가 얼마나 빨리, 정확하게 아이콘을터치하는지 알아보는 것으로 1,000명 이상의 샘플을 모았음.

아이콘

iOS7의 탭 바는 외곽선만 딴 아이콘(기본), 색이 칠해진 아이콘(선택되었을 때)을 한 세트로 사용함. 그런데 사실 뭐가 “속이 빈” 아이콘인지가 느슨하게 정의되어있어 되도록 명확하게 구분되는 20개의 아이콘 세트를 선정하였음. 여기에 구체적인 대상을 지칭하며, 라벨까지 붙여주어 이름과 아이콘을 매칭하는 인지적 수고를 줄였음.

테스트

실제로 여기서 테스트를 해 볼 수 있는데, 테스트는 아래와 같이 진행됨.

  1. 20개의 아이콘을 미리 보여주고, 눈에 익도록 함
  2. 원형으로 배치된 20개의 아이콘 중, 제시된 이름에 맞는 아이콘을 선택하도록 함
  3. 이걸 24회 진행함
  4. 초반 4번의 테스트는 웜업으로 쳐서 배제하고, 나머지 데이터를 사용
  5. 테스트 시퀀스는 모두 랜덤으로 운영됨 (아이콘 배치, 모양 등)

결과

열흘 동안 1,260회 테스트가 진행됨(개별 아이콘 테스트는 25,000회). 참가자는 어린 편(18-40세)에, 애플 유저들이었음. 평균 선택시간은 3초, 표준편차 1.5초.

결과를 일단 전체적으로 보면, 속이 빈 아이콘이 평균적으로 0.1초씩 선택이 느렸음. 이렇게 되면 Johnson의 가설을 지지하는 결과라고도 볼 수 있지만, 꼭 그렇진 않음. 사실 외곽선 / 색이 들어간 아이콘의 스타일은 두개가 아니라 네개였음. 

이렇게 4개의 그룹을 놓고, 2-way ANOVA(이원 분산분석, 두개 이상의 집단의 차이를 검증하는 테스트)테스트를 돌림. 결과를 놓고 보면, 아래와 같음.

  1. 검정 배경에 속이 빈 아이콘이 나머지 아이콘에 비해 0.17초 늦었음 (유의한 결과)
  2. 나머지 세개의 집단 간 차이는 통계적으로 유의하지 않음.
  3. 즉, 흰색 바탕이라면 속이 찼건 비었건 인식시간에 차이가 없고. 속이 찬 경우엔 검정인지 하얀색인지는 큰 차이가 없었음. 검정 바탕에 속이 빌 경우에만 조금 시간이 더 걸린 것임.

여기서 끝내지 않고, Curt는 좀 더 깊게 실험하기로 함. 이번에는 모양 따라서 하나하나 살펴봤는데, 반 정도(9개)는 차이가 없었고, 나머지 반 중에서도 몇 개 아이콘들(3개)은 오히려 속이 빈 쪽의 인식 속도가 빨랐음. 상세한 아이콘들은 아래와 같음. 

(꽉 찼을 때 인식이 빠름 / 외곽선일때 더 빠름 / 차이 없음)

결론적으로 아이콘의 스타일과 컬러는 사용자가 아이콘을 정확히 선택하는데 영향을 주지 못한다고 할 수 있음. 한가지 특이한 점은 자물쇠 아이콘인데, 하얀색 배경에 검정색일 때 인식이 더 느렸음. 

결론

Johnson의 “속이 빈 아이콘” 가설은 실험을 통해 입증되지 못했음. 속이 비었다고 해서 인식이 안되는 것도 아니었고, 차이도 사용자가 큰 피로를 느낀다고 할 만한 수준이 아니었음. 사용자가 아이콘을 매번 해석해내는 것도 아니고, 아이콘의 위치를 통해서도 의미를 그려낸다는 연구도 있음. 이렇게 두 가지 방식으로 아이콘을 표현하는 일은 색 말고도 부가적인 표현 방식을 하나 더 제공하기 때문에 접근성 부분에서도 이점을 가짐.

아이콘이 외곽선으로만 표현되면 인식이 안된다느니 하는 이분법적인 방식으로 문제가 해결되지 않음. 인식이 쉽고 비쥬얼적으로 매력적인 아이콘 그리기는 더 복잡한 문제임. 애플의 HIG를 읽어보면, 애플도 어떤 아이콘은 어떤 방식으로도 먹히지 않을 거라는 것을 인식하고 있다는 것을 알 수 있음.

마지막으로 이 글이 실제 사용자에 대한 데이터가 디자인 결정에 얼마나 중요한지 보여주는 기회가 되었으면 함. 

Material Design 활용 노트

kwangbae:



Google I/O 2014를 통해 발표된 material design 원칙과 자료들은 제품을 만드는 이들에게는 크고 고마운 하나의 패키지였다.

혹시나 몇 안되는 주위 분들에게 도움이 될까 하여, 혼자 보려고 적어두었던 메모를 블로그에도 남겨둔다. 디자인의 흐름이 어떻고 철학이 어떻고 이런건 없고, 실질적인 활용에 대한 부분이다.

고맙다, Google.

==

이해를 위한 자료
- Google Design http://www.google.com/design/
- Material Design on…

(pixstory에서)

Material Design과 모션 디자인

image

지난 주에 Google I/O에 다녀왔다. 원래는 호텔 방에서 관련한 글을 쓰고 있었는데, 실수로 날려먹은 후 겨우 정신줄을 부여잡고 글을 다시 쓰려니… 이미 좋은 글이 올라와 버렸다. 이에 일단 링크를 건다.

Provide meaning with motion (모션으로 의미 부여하기)

Material Design은 iOS7만큼이나 과격한 디자인 선언은 아니었다. 오히려 메트로 디자인부터 여태껏 나왔던 크롬이 적고, 움직임이 많은 화면을 다듬어 정리한 입장이라 보여진다. 결국은 우리가 손에 쥐고 있는 이 검고 길다란 화면이 종이와 같은 새로운 소재라고 본다면, 어떻게 움직여야 할까? 라는 질문에 대한 구글 버전의 답이라고 할 수 있다. 하지만 곰곰히 살펴보면, 그 깊이는 다른 OS별 디자인에 비해 굉장히 깊다고 할 수 있다. 어찌 보면 스마트폰으로 대표되는 “새로운 기기”에 대한 인터랙션 디자인에 대한 철학이라고도 할 수 있겠다.

화면을 720x1280 따위의 사이즈를 가진 페이지로 재단하여, 그것을 움직이는 것이 아니라 픽셀 하나 하나에 생명을 불어넣어, 그것이 색깔 뿐 아니라 깊이까지 가지게 되는.. 마치 SF영화에 나오는 자유자재로 형상을 바꾸는 모래같은 것이 내 손안에 있다면, 그것은 조금 더 다이나믹하게 움직여야 함은 물론, 그 움직임에 의미마저 담겨있어야 한다는 것. 그것이 Material Design의 사조라고 생각한다.

Twitter의 디자이너인 Paul Stamatiou는 이젠 비쥬얼 디자인 만큼이나 모션 디자인이 중요하다고 이야기 한다. 사실 I/O에서의 대부분 이야기도 모션 디자인에 치중되어 있었다. 모든 디자인 세션에 모션이라는 키워드가 등장했다(물론, 이미지, 컬러, 타이포에 대한 이야기도 많았다. 굉장히 디테일하기도 했고). 단순히 ease-in, ease-out 같은 것을 넘어, 어떤 curve가 논리적으로 타당한지, 어떤 방향에서 오브젝트가 들어와야 혼란이 없는지. 촘촘하게 따지고 들었다. 

그 툴이 무엇이 되어야 하는가에 대해서는 아직 논의의 여지가 많지만, 적어도 한가지 이상의 툴로 “이 화면에 어떤 움직임이 만들어져야 하는가”에 대한 입장을 정리할 의무가 디자이너에게 부여되었다고 생각한다. 단순히 해외에서 본 어떤 앱의 트랜지션이 멋져서, 요새 다들 이렇게 하니까를 넘어서서, 지금 내가 제공하는 기능 A에서 어떻게 움직여야 사용자가 물 흐르듯 사용할 수 있을까? 단순히 spec sheet 몇 페이지 어딘가에서 조항을 집어내는 가이드라인 팔로잉을 넘어서서, 그냥 보는 것 만으로도 말이 되게 만드는. 그 무언가를 디자인해낼 필요가 생긴 것이다.

I/O는 그런 측면에서 많은 자극이 되었고, 앞으로 해나갈 일에 방향을 잡아준 것 같다. 그 전까진 내가 기획자, 혹은 UX 디자이너 같은 직군에 속해있다는 게 뭔가 어색해서 스스로를 interaction designer라고 불렀다면, 이젠 정말 그런 일을 하는 회사나 팀에서, 그렇게 일해야 겠다는 생각이 들었으니까. 싸구려 지 워치를 받았어도 이득인 셈이 아닌가 하고 스스로를 위로할 따름이다(…)

본격 인터랙션 디자인 툴 - Framer Studio

Framer.js에 대한 포스트는 이미 한번 소개한 적이 있으니… 긴 설명은 생략하고, Framer는 굉장히 멋진 툴이지만 결국에는 Javascript Framework이다. 때문에 기획자나 디자이너가 쉽게 손을 대기엔 여전히 장벽이 많다. 코딩은 제쳐두더라도 일단 에디터도 있어야 하고, 로컬에서 보기 힘드니까 웹에 올려야 하고, 셋업하는 데만도 좀 버겁다. 그리고 한번 고치고 나면 Ctrl(Cmd)+R을 눌러 다시 확인해야 하는데 이만저만 괴로운 일이 아니다.

Quartz Composer는 그런 수고로움은 없는데, 선이 꼬이기 시작하면 머리가 너무 복잡해진다는 단점이 있다. 나는 어느 쪽인가 하면… QC의 즉시성은 참 마음에 들지만, 아무래도 정리를 하는 데에는 Framer가 나은 것 같다. 그래서 둘 중 무엇에 좀 더 공을 들일까 하던 차에, 좋은 제안이 들어와 이 툴을 미리 써볼 수 있게 되었다.

나에게 이 툴을 소개해준 멋진 디자이너 Jorn Van Dijk은 얼마 전까지 페이스북에 근무하던 스타 디자이너이다. 그리고 이 툴을 개발한 Koen Bok도 Jorn과 함께 페이스북에서 일했는데, 사실 이 둘은 애플 디자인 어워드를 수 차례 수상한 것으로 유명한 맥 앱 스튜디오 Sofa의 창업자들이다. 맥 앱을 많이 만들어본 일류 디자이너들 답게 인터페이스는 매우 깔끔하다. 

이 툴은 번거로웠던 Framer의 셋업 과정을 깔끔하게 정리해준다. 시작하자마자 바로 인터랙티브 프로토타입을 가지고 놀 수 있으며, 값을 바꾸면 바로 프로토타입에 반영되기 때문에 막막함과 번거로움이 확 줄었다.

게다가 파워풀한 PSD 플러그인 (이미지를 알아서 잘라준다!)은 스케치로까지 확장 되었는데, 베타 버전을 사용한다면 바로 시험해볼 수 있다. 디자인 하고 버튼 한번만누르면 바로 그림이 나오는 것은 QC에 비해 확실한 우위이다.

전체 화면으로 프로토타입을 보여줄 수 있고, 디바이스 이미지들도 여러가지다. 물론 html이기 때문에 웹에 올리면 대부분의 기기에서 아무나 다 볼 수 있다!

일반 에디터에서는 제공하지 못하는 Auto Complete도 장점이다. 기본적인 Framer의 기능들은 그대로 사용할 수 있고, Snippet을 가지고 여러가지 프리셋을 시험해 볼 수 있다. 결국엔 JS기반이기 때문에 골머리를 썩는 경우도 있지만, 코드가 주는 자유도는 다른 툴 (Flinto, POP)에 비해 한 차원 높다고 생각한다. Framer는 코드 베이스를 지키면서, 초심자들이 길을 잃지 않도록 최대한 배려하고 있다. 앞으로 좀 더 좋아져야 하겠지만, 그럴 것이라 기대한다. JS를 어설프게 아는 나는 좀 헤맸지만, Coffeescript도 이해하기에 훨씬 직관적이다.

정말 괜찮은 툴이다. 개발자이자 디자이너인 Koen은 더 많은 것들을 계획하고 있다고 하니, 앞으로가 더 기대되는 툴이다. 본격적인 인터랙션 디자인 툴이라고 부를만 하다.

여기까지 읽고 관심이 생기셨다면 아래 페이지에 방문을: http://framerjs.com

이미 FramerStudio로 만든 프로토타입도 참고하시길!

Medium의 스와이프 페이지 뷰

트위터 아이폰 앱의 런치 애니메이션

앱 비평하기 (How to do a Product Critique)

믿고보는 줄리 주(Julie Zhou)의 아티클. 이 글은 요약본이니 관심이 가신다면 원문을 확인해주세요.

제품을 어떻게 살펴보고 비판하는지도 디자이너에겐 중요한 스킬. 친절하게도 크리틱하는 방법을 알려준다. 사실 제품이라고 했지만, 이후 문단부터는 앱이라고 나오기 때문에 번역한 제목은 “앱 크리틱하기” 로 정함.

우선 앱을 받고, 실행하기 전에 체크할 것들:

  1. 이 앱이 어떤 부분에서 흥미를 끌었나? 친구에게 들었나? 친구가 뭐라고 했길래 깔았나? 아이콘이 맘에 들었나? 앱 이름이? 예전에 들은 적이 있나? 몇번이나 들었나? 왜 예전에는 안깔다가 지금은 깔았을까? 
  2. 지금 상태에서 한줄로 이 앱을 요약해본다면? 이후에 앱을 써본 뒤에 비교해보는 것도 좋겠다.
  3. 지금 이 앱에 대해서 오가는 말들은? 인기가 있나? 유용한가? 끝내주나? 평가나 리뷰, 설명같은 걸 봤나?

이런 것들을 하면서 앱의 첫 인상을 형성하게 된다. 이 앱의 밸류 포지션이나, 마케팅에 대해서도 좀 더 많이 이해할 수 있게 되고 말이다.

앱을 켜 보고 사용하며 체크할 것들:

  1. 처음 시작하고 가입할 때의 경험은 어땠나? 쉬웠나? 인증이 많아서 귀찮았나?
  2. 처음 순간 앱이 어떻게 자신을 설명하나? 뭐하는 앱인지 바로 알겠는가? 아니면 문구가 너무 혼란스러운가? 문구를 이해하고 숙지했는가, 아니면 너무 귀찮고 지루해서 넘겨버렸나?
  3. 앱은 얼마나 쓰기 쉬운가? 이 앱의 목적을 보자마자 파악했는가? 아니면 이것저것 눌러봐야 알 수 있었나? 네비게이션할 아이템들이 많아서 정신없었나, 아니면 익숙하고 편안하고 심플했나?
  4. 앱을 탐색하면서 받은 느낌은? 미소지을만한 요소들(귀여운 일러스트, 재미있는 문구, 흥미로운 콘텐트)이 있었나? 혹은 이전 화면으로 돌아가기 어려워서 짜증이 났나? 이 앱을 쓰면서 좀 더 스마트해졌다거나, 효율적이 된 것 같았나? 어떤 디테일을 보고 “와 이건 한번도 못본거야!” 라는 느낌을 받은 적이 있나?
  5. 기대에 맞는 앱이었는가? 앱이 뭘 할것 같았는지 돌아보고, 이 앱이 거기에 맞게 동작하는지 확인하라. 유틸리티 앱이라면, 문제를 의미있는 방식으로 해결하나? 컨텐츠 앱이라면 컨텐츠가 매력적이었는가?
  6. 앱을 얼마나 오래 사용했나? 시간은 흥미와 상관관계에 있다. 오랫동안 썼나? 만약 그렇다면 무엇 때문인가?

사람들에게와 마찬가지로, 앱에 대한 의견도 대부분 처음 몇 분안에 형성되기 마련이다. 잠깐 사용해보는 것으로 이 앱이 어떤 가치를 가지는지, 사용하기 쉬운지, 잘 만들어졌는지 파악해볼 수 있다.

며칠, 몇 주가 지나고 확인해볼 것들:

  1. 얼마나 자주 열었나? 언제 주로 쓰나? 무엇때문에 열게 되나? 매력적인 푸시노티 때문인가? 아직도 친구들이 많이 이야기하고 써서? 여기에 계속 의존하게 되나? 습관처럼 쓰게 되는가? 왜 그런가? 그렇지 않다면 무엇 때문일까?
  2. 이 앱을 다른 비슷한 앱과 비교해본다면? 어떤 면에서 낫고, 어떤 면에선 모자란지… 비슷한 앱 대신 왜 이 앱을 쓰게 되었는지.
  3. 다른 사람들은 어떻게 생각하나? 다른 관점을 살펴보는 것은 더 넓은 시장에서 뭐가 먹히고, 먹히지 않는지 파악하는 빠른 방법이다. 리뷰나 블로그 코멘트를 읽어보고, 트윗을 찾아라. 친구들에게 물어보고 다른 지역에 사는 사촌에게도 물어보라. 그들도 당신과 같이 느끼고 있나? 다르다면, 왜 다르다고 생각하나?
  4. 지금까지 살펴본 바로, 1년 뒤엔 이 앱이 얼마나 성공해 있을 것 같나? 공개적으로 떠벌일 필요는 없다. 그냥 혼자서라도 기록해둬라. 투명하고, 솔직하게 이 앱에 대해 걸어봐라. 그럼 1년 뒤에 당신이 틀렸는지 맞았는지 확인해볼 수 있다. 이런 방식으로 “이거봐 난 원래 이거 성공할 줄 알았어” 하는 사후확신 편항을 제거할 수 있다.
  5. (많은 시간이 지난 후) 당신의 예측이 맞았나? 만일 그렇지 않다면, 왜 그런가? 개인적인 취향이 시장의 그것과 얼마나 달랐나? 미래에 당신의 의견을 조정하기 위해서라도, 이건 꼭 이해해야 하는 부분이다.

잘 관찰하지 않고서는 좋은 제품에 대한 감각을 키울 수 없다. 이렇게 많은 리뷰를 하면서 당신은 어떤 디테일이 어떤 결과로 이어지는지에 대해 파악할 수 있다.

최고의 디자이너들과, 제품 기획자들은 사람들을 이해한다. 무엇이 사람들을 움직이고, 무엇이 사람들을 기쁘게 하는지 안다. 왜 이 제품이 성공적이었는지, 어떤 부분 때문에 망했는지에 대해 강력한 이론을 가지고 있다. 그들이 그걸 가지고 태어난 게 아니라, 꾸준하게 사람들을 관찰하고 배웠기 때문이다.

이런 프로세스는 굳이 제품 크리틱이라고 불릴 필요도 없다. 테스트나 면접 질문일 필요도 없다. 다른 사람이 시켜서, 혹은 의무감에 해서도 안된다.

이건 그냥 당신이 호기심이 많기 때문에, 꾸준히, 계속 이뤄져야 하는 일이다. 당신이 더 나은 걸 만드는 방법을 알고 싶기 때문에.

꾸준하게 관찰하고 배워라. 그것만이 길이다.

좋은 제품을 만드는 길은, 사람을 이해하는 것에서 출발한다. 본능적인 천재성에 기대는 것은 무리하고 무식한 일이다.

2014 — The Year of Interaction Design Tools

인터랙션 디자인 툴이 정말 쏟아져 나오고 있다고 하는데.. 모아보니 꽤 많네.

Macaw나 Flinto같은 쉽게 만들수 있지만 제한적인 툴부터, Origami나 Framer.js같이 조금은 복잡하지만 가능성은 거의 무한한 툴까지 입맛에 맞는 놈으로 골라 쓰면 될 것 같다.

이 외에도 Pixate (아직 런칭되진 않음)같은 멋진 툴과, 이번 Google I/O에서 본격적으로 다뤄질 Polymer도 줄서있다. 트위터 디자인의 말 대로, 정말 인터랙션 디자이너하기 딱 좋은 시기가 아닌가 싶다.

애플과 반응형 디자인

기사의 내용을 ‘대강’ 포함하고 있습니다. 번역문이 아니니 전체 내용이 궁금하신 분은 원문을 꼭 확인해주세요.

애플 홈페이지는 반응형 디자인과 무관한 노선을 걷고 있는데, 아이폰으로 들어가나 맥으로 들어가나 ‘거의’ 똑같아 보인다. 2007년 첫 아이폰이 발표되었을 때의 뉴욕 타임즈 홈페이지를 보는 느낌인데…

디바이스에서도 마찬가지였음. 유니버설 앱이라고 하는 건 결국 완전히 다른 두 개의 레이아웃을 하나의 앱으로 묶어 내는 것일 뿐이었기 때문에, 웹으로 치면 그냥 다른 페이지 두개를 내놓는 것과 마찬가지라는 이야기.

그러던 것이 아이폰5가 나오면서 조금씩 달라졌는데, 여전히 아이패드는 완전히 다른 레이아웃을 사용해야 했지만 아이폰의 경우 3.5인치와 4인치가 같은 레이아웃을 쓰면서 다른 화면 크기에 대응하는 auto-layout이 포함된 것(ios6부터)

그리고 지난 주 WWDC에서 adaptive ui를 발표했는데, 여기선 Size Class에 따라서 레이아웃 규칙을 정할 수 있음. 아직은 애플이 정한 breakpoint만 따르게 되어있지만… 이제 개발자들은 하나의 ViewController를 사용해서 모든 디바이스에 대응할 수 있게 되었음. 지금은 Size Class 자체가 두개(compact, regular)만 있지만, 앞으로 추가될 여지는 많아보임.

마침내 애플이 반응형 시장에 들어왔는데, 늦게 들어왔지만 과연 어떤 파괴력을 발휘할 지 기대됨. 코드가 좀 있긴 하지만 그림 위주로 되어있는 WWDC 세션을 보는 것을 추천. 

"Building Adaptive Apps with UIKit"

포토샵은 디자인 툴이 아니다. 커뮤니케이션 툴이다.

image

by Leigh Taylor (Gravita.co 디자이너, 전 Medium / ObviousCorp)

https://medium.com/design-ux/photoshop-is-not-a-design-tool-10489d3cc430

난 그동안 일해오며 포토샵을 빡세게 써왔고, 나 자신, 그리고 동료들에게 보여줄 ‘궁극의’ 디자인 표현을 위해 매일 연습하고 다듬어 왔다. 그 결과 난 자랑스러운 영광의 뱃지를 달았고, 더 이상 배울 게 없었다. 늘 되고싶어하던 마스터 장인이 된 것이다. 퀄리티에 집중하고, 효율적이고 많은 결과를 쏟아내었다. 친구들 사이에선 “포토샵에 문제 생기면 걔한테 물어보면 돼” 하는 수준에 이르렀다.

하지만, 난 결코 결과물에 만족할 수 없었다. 뭔가 덜 완성된 것 같았고, 정적이었으며, 연약했다. 난 이 섬세한 이미지가 팀으로부터의 의문들, 그리고 불확실성과 싸워야 한다는 걸 알았다. 이런 대화를 거친 뒤에야, 얼마간의 타협을 거쳐 디자인이 실제로 빌드되기 시작하는 것이다.

이런 리뷰들을 받고 나면 난 종종 패배감에 빠지게 된다. 멘탈이 바닥나고 불만이 쌓이고 뭘 어떻게 해야 할 지 갈피를 못잡게 된다. 대체 난 그렇게 많은 시간 동안 이렇게 이야기될 것을 만들려고 노력했던 건가.

깨닫는데까지 정말 오랜 시간이 걸렸다. 내가 디자인한다고 그렇게 열심이던 그 시간들은, 사실은 픽셀을 보여주는 걸 잘 하려는 노력에 불과했던 것이다.

불편한 진실은 말이다. 당신이 포토샵으로 디자인하는 것은 그냥 불필요한 일일 뿐이다. (포토샵 파일은) 이야기가 시작되는 지점이고, 이야기할 때 필요한 참고 대상이거나, 만들어 나갈 플랫폼이 될 뿐이다. 그것은 결코 결정적인 조각이 아니다.

디자인은 여러 기술을 합해 만들어진다. 협력 과정이다. 불명확한 것을 명확하게 하고, 불확실성을 지우며 앞으로 함께 나아갈 목표를 만드는 데에는 시간이 걸린다. 

우리는 포토샵 말고도 여러 과정을 통해 디자인하고 있다. 모호한 경계 위에 사람들이 협업하는 와중에 이루어진다. 대화, 스케치, 문서, 다이어그램, 피드백을 통해 말이다. 결국 포토샵의 디자인 툴로서의 한계를 느끼는 것으로부터 우리는 그것의 커뮤니케이션 툴로서의 강점을 발견하게 되는 것이다.

내게 있어서 포토샵의 중요성은 많이 사라졌다. 난 디자인에 숨을 불어넣기를 갈망해왔다. 그것이 코드화되길 바랬다. 애니메이션의 뉘앙스나, 실시간 피드백을 포토샵에서는 그려낼 수 없다. 시도해볼수는 있지만, 결국은 빠르게 움직이는 스토리보드에 올라가는 이미지 프리뷰나 만들 뿐이다. 나도 해봤다!

다음 단계는 코드로 한걸음 더 나아가는거다. 난 프론트엔드 코드는 짤 줄 알지만 하지 않기로 했다. 별로 좋아하지 않는다. 텍스트 에디터와 비쥬얼 피드백 사이의 간극은 나에겐 너무 넓다. 난 좀 더 빠르고, 덜 어려운 것을 택하기로 했다. 쿼츠 컴포저가 일말의 희망을 안겨줬다. 그 툴은 포토샵이 할 수 있던것 보다 더 HCI를 잘 설명해낼 수 있었다. 하지만 프로토타입만 만들 수 있었고, 언제 지원이 끊길 지 모른다는 루머로 인해 두려웠다.

디자이너들은 코드 기반의 세계에서는 무력하다

우리는 아이디어를 공유하고, 잠재적인 솔루션과 픽셀을 표현하기 위해 시간을 들이지만, 결국 우리의 디자인을 현실화 하기 위해서는 남의 기술이 필요하다.

브렛 빅터(Bret Victor)는 애플의 다양한 디자인 그룹에 몸담은 바 있는데, 아래와 같이 탄식했다.

”(전략) 이런 뛰어난 디자이너들이 실제 물건을 못 만들어내요. 제안만 할 수 있는거예요. 포토샵으로 목업을 그리지만 그대로 출하되는 제품은 못만들죠. 대신에 그들은 엔지니어들에 의존하죠. 아이디어를 텍스트로 만들어달라고 말이예요. 디자인이 대우받는 애플에서조차, 미묘한 무력함이 흘러요. 스스로 해결할 수 없기 때문이죠. 뭐 듣기 좋으라고 이런 걸 “보완적인 기술 세트”라고 말할수는 있겠죠. 하지만 진실은 뭐냐면요. 작가는 책을 내고, 뮤지션은 노래를 만들고, 애니메이터는 단편을 만들고, 화가는 그림을 내는데, 대부분의 (UI) 디자이너들은 창조물을 현실로 못 만들어내는거예요. 이게 내 마음을 찢어놓죠.”

이 갭을 줄이기 위해 블로그들에 “디자이너도 코딩을 할 줄 알아야한다” 라는 주장들이 마치 해답처럼 나돌곤 했다. 하지만 많은 디자이너들을 만나 이야기를 해 본 결과, 난 코딩도 해답이 아니라는 결론에 이르렀다. 코드를 한줄 한줄 늘릴 때마다 부식해가고, 복잡도만 늘어간다. 코드가 늘어갈수록 리팩토링을 해야 하고, 버그가 늘어가며 신입들은 배울게 늘어간다. 결국에는 스파게티 코드가 되어버리고 마는 것이다.

실제 문제는, 우리의 지식이 부족해서 생기는 거나, 이해나 기술이 부족해서 생기는 것이 아니다. 협력적인 환경이 제대로 갖춰져있지 않아서 생기는 문제인 것이다. 디자인부터 소프트웨어 개발의 복잡성에도 잘 대응하며, 제품 생산을 위한 하나의 플랫폼을 제공하는 그런 툴 말이다. 이건 디자인과 코드간의 대결이 아니고, 디자인과 코드의 화합인 것이다.

복잡한 코드를 담으면서도, 좀 더 접근이 쉬운. 디자인을 해나가며 같이 개발을 할 수 있는, 그런 툴 말이다.

줄리 주가 언급한 대로, 쿼츠 컴포저는 이 두 세계를 통합하는 데 가장 가까이 갔다. 하지만 여전히 프로토타입은 프로토타입인 채 멈춰있다. 제안 이상의 것이 될 수 없다. 누군가는 여전히 따로 제로부터 코드를 짜야한다.

이런 툴의 제약은 더 협력할 수 있는 우리의 잠재력을 제한해버린다. 디자인과 개발 팀을 나눠서 일하는 게 아니라, 프로젝트 자체에만 집중하고 팀 내의 기술을 충분히 활용해서 제품을 만들 수 있는 그런 툴이 필요하다.

디자인, 협력, 그리고 만들기

이 문제를 해결하기 위해 만든 툴이 바로 NoFlo이다. 디자인과 개발의 커뮤니케이션 격차를 줄이고, 실제로 효과적인 협력을 가능하게 하는 플랫폼을 제공하는 툴이다.

쿼츠 컴포저와 달리, NoFlo로 당신은 제품화할 수 있는 결과물을 만들 수 있다. 바로바로 개발, 인터랙션, 디자인 간 피드백을 공유하며 제품을 만들어나갈 수 있는 환경인 것이다.

image

16471라인의 코드로 표현한 Jekyll이,

image

NoFlo에선 이렇게 표현됨.

image

Contextual Cards

예를 들어보자. 지킬 안의 16471줄의 코드를 표현하기는 누구에게나 막막한 일이겠지만, NoFlo에서는 상호 독립적인 요소들이 그래프 내에 연결되어 있는 구조이기 때문에 논리적인 부분에서 말이 되는지, 그리고 서로 어떻게 연결되어 있는지 확인해볼 수 있다. 앱을 만들기 위해 코딩을 할 필요가 없다.

UI레이어 덕에 코딩 능력에 의존이 줄게 되었다. (코딩은) 여전히 존재하긴 하지만, 비쥬얼 스택 깊숙한 곳에 숨어있다. 코드는 좀 더 관리하기 좋고 적절한 조합으로 분리되었다. (분리되었지만) 로직의 맥락도 놓치지 않는다.

코딩하고 싶다면 할 수 있다. 그 덕에 다른 역할의 사람들, 혹은 새로 온 사람들이 좀 더 많은 이해 위에서 제품을 만들 수 있게 된다. 디자인이 실제 돌아가는 코드 위에서 실현될 수 있게 할 수도 있을 것이고 말이다. 진정한 디자인-개발 환경이 주어지기 때문에 각 직군 간의 모호함의 층이 최소화된다. 통역이 안되어서 엇갈리는 일은 줄고, 진정한 협력이 일어날 것이다.

제 4의 시스템을 제공하여 사람들의 삶에 극적인 영향을 끼치는 것 만큼 개인적으로, 경제적으로 보상이 큰 일은 없다고 생각한다.

완전히 새로운 방식은 아니다. 플로우 기반의 프로그래밍은 우리 곁에 수 십년 동안 있어왔다. 헐리웃, 게임, 인공지능 같은 영역에서 이미 많이 쓰이고 있고, 웹에도 적용하려는 시도가 있었다.

그렇다면 왜 하필 지금, 내가 NoFlo를 만들려고 노력하고 있는것일까?

수백년 전만 해도 대서양을 비행기로 가로지른다는 라이트 형제의 아이디어는 웃음거리에 불과했을 것이다. 하지만, 누군가는 가능성을 타진했을 것이고 어떤이는 같은 비전을 가졌을 지도 모른다. 미래의 여행 방식으로 너무도 당연한 방법같이 느껴졌을 것이다. 단지 이뤄내기가 어려웠을 뿐. 수십년간의 실패와 시도 끝에 우리는 드디어 대륙간 비행의 꿈을 이뤄냈다. 그리고 오늘날 엄청난 사람들은 원래 이랬다는 것 마냥 수천 마일을 날아다닌다.

가끔은 새로운 패러다임이 적용되길 기다려야 하는 때가 있다. 우리의 환경, 기술, 그리고 믿음이 우리의 비젼과 발맞추길 기다려야 하는 것이다. 

그리고 우린 이제 때가 되었다고, 변화의 시작이 무르익었다고 생각한다. 우리는 단지 디자인하고, 개발하는 툴이 아니라 무언가를 창조하고 만들어내는 데 있어 최고의 툴을 만들려고 한다. 

NoFlo를 실현하기

아직은 NoFlo의 초기 디자인 개발단계에 있지만, 비전에는 자신이 있다. 단지 당신의 도움이 필요할 뿐이다. 모든 질문에 대한 답을 가지고 있지 않다, 당신의 도움이 필요하다. 우린 플로우 기반의 프로그래밍 패러다임이 디지털 세계에 어떤 가능성을 가져올 지 열심히 탐색하고 있다. 당신도 우리의 탐험에 함께 해주길 바란다.

우리의 킥스타터 페이지에 방문해서, 지지를 보여주길!

전문 번역입니다만, 저자인 Leigh Taylor에게 번역허가를 받은 후 진행되었음을 알립니다. This article is translated under agreement of the author of article, Leigh Taylor. 

Kickstarter는 이미 펀딩이 성공적으로 완료되었다고 합니다. 그래도 한번 방문해보세요!