'드롭박스'에 해당하는 글 2건

제목: Yeah, redesign(Part 1)

모바일 세상에서 어떻게 리디자인에 접근할 수 있을까

나는 디자인 수석으로서, 항상 내 자신에게 이렇게 질문한다. "우리 팀이 사용자에게 어떻게 최고의 제품 경험을 계속해서 전달할 수 있을까?" 내 대답은 항상 같다. '급격하게 변하는 커뮤니티에서 변화하고 진화하는 사용자의 기호를 항상 고려해야한다.' 그러나 제품 경험을 리디자인하는 것이 방법이라면, 시작된 프로세스를 얻어내기 위한 내부 토론을 어떻게 시작할까? 제품 아이덴티티는 유지한채로 새로운 기능과 디자인의 균형을 맞춰가며 확장가능할 솔루션을 어떻게 달성할 수 있을까?

여러분도 비슷한 디자인 과제를 안고있다면, 아래 질문들의 대답을 찾아가며 이 글이 어느정도 도움이 될 수 있을 것이다.

  1. 그 사용자가 이미 사랑하고 있을때 왜 제품을 리디자인해야할까?
  2. 어떻게 데이터 주도 회사의 패이스에 맞춰가며 리디자인을 시행할까?
  3. 결과물을 어떻게 측정할까?
  4. 다음 단계는 무엇일까?

이 질문에대한 답변을 찾는데 우리 메인 제품인 Sing! Karaoke가 겪은 리디자인을 공유하고, 우리 팀이 이 방법으로 어떻게 난과을 극복했는지 보여주고 싶다.

2년하고도 6개월전에 내가 처음 회사에 들어왔을때, 각 앱(Sing! Karaoke, Magic Piano, Autiharp, Guitar)마다 배치된 팀이 하나씩 있었다. 각 팀은 디자이너 한명, 프로덕트 메니저 한명, 그리고 두명의 엔지니어로 구성된다. 서로다른 성장 속도로인해 Smule 식구중에 Sing!이 선두에있는 앱이 되었다. 회사는 앱 기반 개발 구조에서 기능 기반 구조로 초점을 바꾸기 시작했다. Sing에 기능을 추가하는데 더 많은 노력이 들어가고 디자이너들 사이에 디자인 협업이 더 많이 필요하게 되었다는 의미이다. 사업이 바뀌면서 우리는 기존의 제품 디자인과 프로세스는 팀을 키우고 사용자를 만족시키는데 요구사항이 충족되지 못했다는 것을 알았다.

리디자인을 단지 한 프로젝트에만 적용시키는게 아니라 우리 사용자와 디자이너, 프로덕트 매니저, 인지니어, 이사원들을 끌여 들여야 한다는것을 알았다. 당사자들은 리디자인의 목적을 위해 초기 단계에 얻고 리디자인이 어떻게 진행되어야하는지에대한 피드백을 받음으로써 4가지 범주에서 리디자인이 달성하고자하는 명확한 목표를 설정할 수 있게 도와준다(Have these parties buy into at early stage for the reasons of redesign and provide feedback for “how” the redesign should happen helped us set a clear goal what redesign would achieve in four areas).


  • 사용자 경험 증진하기(Improve user experience)
  • 디자인 팀을 확장가능하게 만들기(Empower design team for scale)
  • 제품 인게이지먼트 증진하기(Increase product engagement)
  • 유지가능한 공학적인 솔루션 만들기(Build a sustainable engineering solution)

1. Sing!의 사용자 경험 증진하기
Sing! 경험에 일관성과 지속성 만들기
수많은 사용자 연구에서 사용성에 가장 강력하게 기여하는 녀석 중 하나가 일관성이라는 것을 알고있다. Sing!은 많은 기능으로 즐거운 제품이다. 이 제품이 2012년도에 출시되었을때는 더 적은 기능과 작은 사용자 기본을 가졌었다. 이런 적은 기능들은 서로 다른 문맥에서 분리된 컨텐트를 표현하기위해 서로다른 칼라를 쓰는 디자인의 결과를 낳았다. 예를들어 이전 버전의 Sing!은 다양한 사용으로 'Call to Actions'를 표시하는데 4가지 이상의 칼라를 사용했다. 예전 디자인이 사용자를 즐겁게하는 목적에 맞춰져있는동안 이런 여러 칼라 CTA(wiki, 역자가 이해한바로는 CTA는 광고버튼 등을 의미함)는 새로운 사용자를 혼란스럽게 만든다는 사실을 알아냈다. 현재 사용자 경험을 증진하기위해서 리디자인은 일관적인 UI 랭귀지를 설립할 필요가 있다는 의미이다.

새로운 사용자 인게이지먼트(engagement, 참고링크) 증진하기
컨덕팅 사용자 연구(Conducting user studies)에서는, 새로운 사용자는 그들의 (다른 앱이나 제품으로부터 UI 인터랙트했던) 예전 경험을 가져와서 처음 Sing!의 인터렉션 기능처럼 동작할거라 생각한다는 것을 인지해야 한다고 말한다. 그리고 아주 중요하게도, Sing! 인터페이스가 사용자 경험에 일치하지 않았을때는 그 인터페이스를 배우고 이해하는데 추가적인 에너지가 소비되고, 이것은 새로운 제품을 관심있게 시도해보게 만들기도 하지만 생소한것을 겪어야하기도 하게 만든다. 리디자인 과정에서 개발해온 패턴을 매칭시키기위해 표준적인 UI가 증가하거나 커스텀 UI를 바꾸는 것이 사용자들에게 더 빨리 더 쉽게 제품에 친숙해지게 돕는다는 생각했다. 이렇게하여 사용자들이 빨리 더 나은 인게이지먼트의 제품을 자연스럽게 이해하는데 도움을 줄 수 있다.

기존에있던 사용자 잔존율을 증가시키기
앱과의 인터렉션에서의 비용은 육체적(physical)으로나 정신적(mental)으로 둘 다 측정가능하다. 육체적 비용은 사용자가 필요로하는 특정 목표를 달성하는데 몇 단계인지 측정한다. 정신적 비용은 사용자가 한 작업을 완료시키거나 어떤 목표 혹은 스트레스(stress)를 달성하기위해 필요한 내제적, 외부적 인식 로드를 측정한다. 예를들어 Sing!의 사용자들이 다른 사용자와 듀엣을 시작하길 원할때, 이 목표를 달성하기위해 다중 UI로 넘어간다. 이것은 컨텐트의 이해를 돕지 못하여 시간적으로나 스트레스적으로 비용이 드는 것이다. 여기에는 명확한 표준적 인터렉션과 UI 디자인의 계획과 신조로 사용자의 육체적, 정신적 비용을 줄일 것이다.




2. 디자인 팀을 확장가능하게 만들기
Sing!을 위한 새로운 폰트 만들기
Sing!은 Gotham 폰트로 시작했었다, 이 폰트는 뉴욕시티의 중세 건축에서 착안되었다. Gotham은 Smule의 제미와 기발함, 환영하는 기분을 알리기위한 훌륭한 폰트이다. 오늘날까지도 Smule의 브렌드 아이덴티티로 표현되고 있다. 그러나 Gotham은 보통 인쇄나 미디어 어플리케이션에 사용되는 폰트이다. 모바일 기기에서 폰트를 사용할때, 많은 이슈를 야기한다. Gotham은 넓은 커닝(kerning, 텍스트가 시각적으로 보기 좋도록 글자간의 간격을 조정한것)을 가지고 있고, 주어진 단어나 문장에대해 너 많은 공간을 차지했다. 모바일 기기는 제한적인 소유지(화면 크기)를 가지므로 디자이너들은 항상 그 텍스트들을 iOS와 안드로이드 둘다에서 잘 보이도록 만들어야하는 추가적인 노력을 해야했다. 그 폰트 크기는 작은 공간에 맞추기위해 여러번 줄여야했고, 이것은 사용자에게 가독성 이슈를 만들었다. Gothan에의한 또다른 이슈로는 낮은 기준선(baseline)이다. 시각적으로 중앙에 놓으려면 이것때문에 수작업을 해야했다. 이런 예시들에서 볼 수 있듯, 결과적으로 개발동안 많은 디자인 이슈를 만났다. 이제는 리니자인을 하면서 해야할 것으로서, 확장가능하고 플랫폼 표준 폰트를 잦는것이 중요한 결정사항이라는 것을 안다.

Sing!은 그 디자인 언어인 표준화가 필요하다.
디자인은 유기적(organic)이기도하고 향수를 불러일으키기(nostalgic)도한 창의적인 과정이다. 표준 UX/UI 디자인 가이드라인이 제자리에 없이는, 프로젝트에서 작업하는 각 디자이너의 미학으로 이 제품은 뒤죽박죽이 될것이다. 이런 디자인으로 계속 작업하다가는 디자인 팀에서 혼란을 만들고, 디자이너 결과물의 한계와 질이 떨어진 제품을 만들었다. 우리의 예전 Sing! 디자인 표준이 명확하게 정의되있지 않았다는걸 알았다. 이런 모호함은 디자인 비평/검토 과정을 더 지연시키고 더 힘들게 하였다. 팀에서 누구도 우리가 목표로 하고있는 디자인 표준을 분명하게 말할 수 없었을때, 모든 피드백이나 리뷰는 개신 선호에따라 판단되었으며, 결국 대부분 정당성을 입증할 수 없었다. 한 팀으로서, 사용자에게 최고의 제품과 경험을 제공하기위해서는 협력적인 노력이 들것이라는 것을 인지했다. 결국 리디자인하고 앞으로 나가기위해서는, 모든 디자인 팀원들간에 소통할 수 있는 명확한 표준이 필요했음을 깨달았다. 우리는 팀에의해 모든 제품 디자인 결정사항에대한 표준을 설정하였다.

디자인팀에서 거대한 성장은 몇가지 규칙들을 설립해야한다는 것을 알게 만들어주었다. 이 가이드라인은 IA, 레이아웃, 폰트, 칼라, 그림요소(imagery), 인터렉션을 다루는 법을 세울 것이다. 이 가이드라인은 디자이너들이 한번에 올바른 디자인 결정을 만들 수 있도록하는데, 디자인 프로세스를 절감해 많은 디자인 이슈에 적용할 수 있는 프레임워크가 될 수 있다. 더욱 중요하게도 디자인 팀은 우리의 스타일, 요소, 패턴을 문서화하여 가지고 있어야하는데, 공유되고, 중앙 저장소이고, 필요한만큼 빈번하게 업데이트되야한다. 한곳에 공유된 중심원(hub)이 있으면 디자인의 일관성을 증진시킬 수 있으며, 뿐만 아니라 디자인의 질과 양도 따라온다. 즉 디자인팀은 Sing! 리디자인으로 가이드라인을 만들어낼 필요가 있었으므로, 분리되고 개인적인 디자인을 줄이고, 외관상으로 일관적이게 남길 것이다. 이것이 우리의 목표이며, 결국 디자이너들은 세세한 아이콘으로 작업할 수 없고 올바른 명세가 무엇인지 생각할 수 없을 것이다. 대신 사용자를위한 더 창의적인 디자인 솔루션에 집중할 수 있다.

디자인팀은 규모가 확장되야할 필요가 있다
제품에 추가되고있는 기능이 많아지고 더 많은 Sing 사용자가 생기면서, 우리 디자인 팀은 협력을 성장하고 증진할 필요가 있다. 협력을위한 기본적인 틀의 작은 블럭을 만드는 공통된 이해 없이는, 팀에게 이런 성장을 유지하기위해 넣는 압력은 복잡해진 의사소통을 만들 수 있다. 우리 팀이 잘하고있다는 확신을 위해서, 우리는 디자인 접근법과 워크플로우를 모듈화시켜야 한다는 점을 알았다. 이 말은,  리디자인팀이 작은 블럭을 만들며 디자인을 만들어야할 필요가 있다는 뜻인데, 이 블럭은 리디자인의 기초가 되고 모든 디자인 노력(effort)이 될것이다. 이렇게 각자가 블럭을 만드는 것은 디자이너들이 쉽게 협력할 수 있게 해주고 필요에따라 작업을 쪼개게 해준다. 게다가 새로운 디자이너가 오면, 기존의 팀원이 프로젝트를 이끌기위해 블럭을 만드는 것을 활용할 수 있고, 새 맴버를 위한 일정을 명확하게 정할 수 있게 된다.




3. 제품 인게이지먼트 증진하기
새 사용자에게 내장된 경험 증진하기
새로운 사용자가 새 앱을 쓰려고 할때, 한번에 두가지를 배우는데, 첫째로 앱의 기능이고, 둘째로 이 기능을 어떻게 쓰는지이다. 명확하고 표준화된 UI/UX 디자인이 없으면 사용자는 앱에서 개별적인 인터페이스 요소를 완전히 소화하지 못할 것이다. 사용자에게 인터페이스 디자인을 소개하는 것보다 제품 기능 사용에대해 초점을 맞추기 때문에, 우리는 새로운 사용자의 기대를 이해하고 그들에게 명확하게 유용한 정보를 전달해야했다. 전반적으로 새 디자인은 앱의 혼란스러운 부분을 간단하게 만들어야했고, 사용자들이 새 기능을 시도하고 인터렉트함에 편안하도록 해주어야 했다.

사용자 잔존율(retention)을 증가시키기
Smule에서는 새 사용자가 앱을 처음 경험하고나서 이후에 얼마만에 다시 돌아오는지(예를들어 2일이나 7일같이) 정의하여 사용자 잔존율을 면밀히 모니터링한다. 만약 사용자의 첫번째 경험이 좋지 않았다면, 이틀연속 다시 돌아오기 힘들 것이다. 사용자 연구를 통해 알아내었는데. 사용자들이 처음하는 시점에서 기능을 찾아내면 많은 기능들을 즐긴다. 혹은 이미 있는 기능들을 요청했다. 이런 발견으로부터 우리 디자인 안내가 사용자의 유지를 잡지 못하고 있음을 의미했다. 만약 디자인이 사용자의 생각속에 있는 기능을 어디서 찾고 어떻게 접근하는지 알려주지 못한다면 사용자들은 혼란에 빠지고 Sing을 계속 사용하고 싶다는 흥미를 잃어버리게 될것이다. 리디자인으로 사용자 잔존율과 제품 사업 목표를 만족시키는 더 나은 안내를 고안해내야한다.

개발과 배포 사이클 증진하기
2014년도에 리디자인을 고려하기 시작할때부터 iOS와 안드로이드에서의 제품 기능을 동일하지 않았다. Sing! iOS는 Sing 안드로이드보다 더 많은 기능이 있었다. iOS와 안드로이드간의 일관성 부재는 디자인 팀에게 일거리를 두배로 주고 개발 사이클을 지연시켰다. Sing!은 우리가 리디자인을 생각하기 시작할때부터 많은 사용자들이 생겼었다. 제품 디자인과 개발 사이클에 추진력과 속도를 높히고 싶었다. 이런 마음을 가지고 우리는 내부 디자인 팀의 워크플로우와 효율을 올리는데 리디자인이 필요하다는 것을 알았다. 리디자인으로 디자인과 개발 시간을 50%나 줄일 수 있었고, 이것은 현재 리소스로 새로운 기능을 테스트하고 배포하는데 더 많은 기회를 줄 것이다.




4. 유지가능한 공학적인 솔루션 만들기
개발 프로세스 증진하기
부조화스러운 UI는 사용성 이슈를 만들 뿐만 아니라 디자이너와 엔지니어들에게 추가적인 작업 과중을 안겨준다. 예를들어, 디자이너들은 한 아이콘일지라도 여러 시나리오에서 사용될 여러 칼라와 사이즈로 아이콘들을 만든다. 엔지니어에게 이 아이콘들을 올바른 화면에 놓게 하기위해 아이콘들을 만들고 명세하는데 디자이너들은 추가적인 40% 시간이 더 든다. 엔지니어도 이 명세를 따르고, 각 아이콘이 올바르게 위치하도록 커스터마이징된 코드를 짜야한다. 말은 쉬워보이지만 다양한 화면 크기나 플랫폼(iOS와 안드로이드)에 부딪혔을때 이 프로세스는 끔찍해진다. 엔지니어와 이야기하고나면 디자이너와 엔지니어 모두 더 나은 방법으로 서로 협력하고 싶어한다. 여기서 리디자인의 필요성에대한 서로다른 관점이 나온다. 디자이너와 엔지니어가 어떻게 효율적으로 제품을 설정하고 만들지에대한 체계적인 방법을 만들자.

제품 개발 품질을 증가시키기
디자인 QA를 하는것과 올바르게 구현되었는지 확인하는 것은 디자이너의 책임이다. 디자이너와 엔지니어에게 가장 비극의 순간은, 디자인 부분을 변경하다가 생긴 디자인 버그를 엔지니어가 수정하는 것인데, 여기서 또다른 버그가 만들어진다. 이때문에 엔지니어는 디자인 버그를 고치는데 더 많은 시간이 들고, 그 구현이 버그없이 디자인과 일치한다고 보장할 수 없었다. 앞단에 나오는 모든 디자인 버그를 해결하기위한 리디자인을 요구하는것은 비현실적이라는 것쯤은 우리도 안다. 그러나 마진을 어떻게 줄것인지, 아이콘 사이즈를 어떻게 만들것인지, 누른 상태는 어떻게 적용시킬지 등에 대한 표준의 중심 디자인 가이드라인을 만들어서 예전과같은 일이 일어나지 않게 할 수 있다.

세계 현지화 준비하기
리디자인에대한 생각을 시작할쯤에 Sing은 US 중심의 앱에서 다국적인 제품으로 옮겨가고 있었다. 세계 사용자에게 소통하기위해, 우리는 12가지 언어에서 20가지 언어로 현지화 시켜야 했다. 영어기반 앱을 외국어로 적용시킬때 UI는 쉽게 망가질 수 있다. 예를들어 영어와 독일어/러시아어를 비교해보면 같은 의미라도 독일어/러시아어가 더 많은 문자로 표현된다. 영어 레이블에 맟춰놓은 제한된 공간에서는 독일어와 러시아어가 제대로 작동하지 않을 수 있었다. 공간을 설정하고 올바른 계층을 적용시는 규칙을 명확하게 하지 않고서는 현지화된 언어가 작은 사이즈로 표시되거나 짤리게 될 것이다. 언어 하나하나 이 이슈를 해결하면서 엔지니어와 QA에 어마어마한 수고가 들어갔다. 리디자인을 통해 미래에는 서로다른 모든 언어를 최적화할 수 있는 유지가능한 솔류션을 찾아야한다.



이 블로그는 공부하고 공유하는 목적으로 운영되고 있습니다. 번역글에대한 피드백은 언제나 환영이며, 좋은글 추천도 함께 받고 있습니다. 피드백은 

으로 보내주시면 됩니다.



WRITTEN BY
tucan.dev
개인 iOS 개발, tucan9389

트랙백  0 , 댓글  0개가 달렸습니다.
제목: Design words with data


우리가 작성하는 것을 어떻게 데이터로 알 수 있을까?

쓰는것은 양식의 예술이다. 단어는 우리를 웃게 만들기도 하고, 울게 만들기도 하며, 멋진일을 하는데 영감을 주기도 한다.

그러나 나는 쓰기에도 과학이 있다는 것에 대해 오늘 이야기해보고 싶다. 우리는 데이터로부터 어떻 용어를 쓸지에 대한 정보를 제공받고 그 용어에대해 객관적으로 생각하게 해준다.

무엇이 옳고 무엇이 그른가?
나는 드롭박스의 UX 작성자로서, 우리의 목표는 모든 사람들이 우리가 사용하는 모든 단어를 이해할 수 있게 만드는 것이다. 잘못된 단어 하나라도 사용자 경험을 파괴할 수 있다. 모호한 버튼의 글자 하나나 익숙하지 않은 용어는 사용자를 쉽게 낙담시킨다.

우리가 옳바른 단어를 골랐음을 확신하려면, 쓰기에대해 정보에 근거한 선택을 하기위해서 조금 특별한 기술들을 사용하고 있다.

1. Google Trends
몇몇의 용어들 중에 적절한 것을 선택해야한다고 가정해보자. 예를들어 다음 중에 어느것을 여러분 제품에 사용할 수 있을까?

* Log in
* Log on
* Sign in
* Sign on

첫번째로 소개할 것은 Google Trends이다. 쉼표를 기준으로 비교하고 싶은 단어를 모두 입력해 넣으면 된다. Google Trends는 사람들이 Google에서 이 단어를 얼마나 자주 검색했는지 비교해준다. 그 검색은 자동으로 "페이스북은 log in" 혹은 "Sign in은 안된다" 같은 말도 포함된다.

그래서 Google Trends는 어떤 결과물을 보여줄까?

Google Trends를 사용한 용어비교Google Trends를 사용한 용어비교


짜잔! 여기선 깔끔하게 Sign in이 이겼다. 이 말은 사용자들이 이 동작을 부를때 "Sign in:을 더 많이 쓰는 것으로 보인다. 당신이 사용자 경험에 단어를 맞추려면, 다른 것보다는 "Sign in"을 고르는게 더 안전할 것이다.


드롭박스에서는 "Version history" 기능을 표현할때 각기 다른 용어를 쓴다는 것을 발견했다.


우리는 이런 부조화를 고치고 싶었으나 어떤 용어를 사용해야할지 확신이 서지 않았다. "version history"라 해야하나, 아니면 "file history"? 우리는 여러개 고려대상 중, Google Trends의 결과로 그 한가지를 뽑아냈다.

Google Trends에서는 "version history" 검색이 더 많아보이게 나왔고, 우리가 제품 전반에서 "version history"라 부르는 가장 큰 이유가 이것이다. 

2. Google Ngram Viewer
Ngram Viewer는 Google Trends와 비슷한데, 구글이 스캔한 출판된 책에서 검색한다는 점만 다르다. 여러분은 이 데이터를 이용하여 여러분의 언어에서 어떤 용어가 더 일반적으로 쓰이는지 볼 수 있다.

드롭박스는 최근에 iOS앱에 새로운 서명 툴을 출시했다. 여러분의 서명을 그리는 화면에서, 이것을 검토하기 전에는 "Sign Your Signature"이라 적어놓았었다.

우리도 "Sign Your Signature"가 이상하게 보인다는 점을 인지하고 있었으나, 이상하게 보인다는 이유로 이것을 바꿀 순 없었다. 어떻게 이 변경을 납득시켰을까?

Ngram Viewer를 보여주며 "Sign Your Signature"과 "Sign Your Name"을 비교했을 때이다. 이것은 "Sign Your Signature"이 좋지 않음을 보여주었다. 이 데이터를 팀에게 보여주니 그들은 빠르게 "Sign Your Name"으로 바꾸어주었다.

Ngram Viewer를 사용한 용어 비교Ngram Viewer를 사용한 용어 비교


3. 가독성 테스트
몇년동안 언어 전문가들은 여러분의 단어가 어떻게 쉽게 이해되는지 측정해주는 여러 가독성 테스트를 개발해왔다.

이 테스트의 많은 것이 여려분이 쓴 것의 등급을 매겨줄 것이다. 예를들어 8등급이라는 의미는 US에서 일반적으로 8등급이 여러분이 쓴 거을 이해할 수 있다는 뜻이다.

나는 이 테스트중 하나를 사용해 내 Medium 이야기(How to design words)를 하나 돌려보았다. 아래에 그 결과이다.

Readability-Score.com의 결과Readability-Score.com의 결과


여기서 아주 흥미로운 데이터를 얻을 수 있다. 예를들어
  • 나는 6등급으로 이야기를 썼다.
  • 내 어조가 중립적이지만 약간 긍정적이다.
  • 나는 문장당 평균 10.7 단어를 쓴다(드롭박스에서는 문장을 15단어 이하로 쓰려고 노력하고 있다).

이런 테스트 중 하나를 받아보고 싶다면 아래에 몇 시도해볼 수 있는 링크를 준비해놓았다. 이 중 몇개의 테스트는 더 좋은 가독성으로 작성하기 위한 수정도 제안해줄 것이다.

4. 리서치 조사
새 기능에 어떤 이름을 붙일지 알아보고 있는가? 아니면 어떤 가치관에 집중하는가(Or what value prop to focus on)? 이런 상황에서는 리서치 조사를 세팅하는게 도움이 될 수 있다.

많은 조사 툴이 여러분의 타겟 대중을 선택할 수 있게 해준다. 따라서 잠재적 사용자로부터 쉽게 피드백을 받을 수 있다.

아래에는 여러분이 연구 조사를 설정할 수 있는 몇가지이다.
드롭박스는 우리 제품을 사용하는데 가장 큰 이점이 무엇인지 물어보는 설문조사를 시행했다. 대부분의 사람들이 "접근"이라고 대답했다(어떠한 기기에서도 내 파일을 가져올 수 있는 능력). 결론적으로 우리는 대문 페이지를 '접근'에 맞춰 다시 디자인하게 되었다.


5. 사용자 연구
사용자 연구는 여러분이 작성한 것에 대한 피드백을 받을 수 있게 해준다. 일반적으로 사용자 연구에서는 여러 사람들 초대해 글을 읽게 하거나 제품을 사용하게 한 다음 그것에 대해 질문을 한다. 이런 것은 여러분이 작성한 것이 이해되었는지 아닌지 알아보기에 매우 좋다.

우리의 조사자 중 한명은 최근 새로운 흐름을 테스트했던 연구를 진행했다. 거기서 말한 한 단계이다.
Select "Remove local copy" to save space
사용자가 이 기능을 사용할때 질문해보았다. 대부분 이 기능을 이해나는데 힘들었고, 유용하다고 생각되지 않았다. 그래서 사용자에게 유리한 말을 앞쪽으로 놓음으로서 단어의 순서를 바꾸었다.
Save space by selecting "Remove local copy"
이번에는 참여자들이 이 기능을 사용할때 훨씬 쉬웠다고 말해주었다. 그리고 우리는 모든 단어의 순서를 바꾸었다.

자성자의 직감이 어떻게 경험으로 바뀔수 있는지 보여주고, 여러분은 다른 디자인 선택처럼 테스트할 수 있다.

마음으로 쓰고 머리로 고치자
특정 용어를 선택하려 할때는 데이터가 유용할 수 있다. 그러나 이 말뜻이 기계처럼 작성하라는 의미는 아니다.

내가 본 바로는, 먼저 마음으로 초안을 그린다. 당신의 결단력을 믿자. 그러고나서 당신의 생각을 써내고 이제 단어를 다듬기위해 조사나 데이터를 찾아보면 된다.

글쓰기는 예술이자 과학이다. 마음으로 쓰고 머리로 고침으로써 근거있고 유악한 것을 만들어낼 수 있다.

데이터는 작성자에게 편리함을 제공한다. 데이터는 여러분이 쓴 것이 "옳도록" 만든다.



이 블로그는 공부하고 공유하는 목적으로 운영되고 있습니다. 번역글에대한 피드백은 언제나 환영이며, 좋은글 추천도 함께 받고 있습니다. 피드백은 

으로 보내주시면 됩니다.



WRITTEN BY
tucan.dev
개인 iOS 개발, tucan9389

트랙백  0 , 댓글  0개가 달렸습니다.