기본 콘텐츠로 건너뛰기

[Insight] UX디자인의 대부 도널드 노먼, 25년만의 개정판 출간에 대한 사색


[Insight] UX디자인의 대부 도널드 노먼, 25년만의 개정판 출간에 대한 사색


 사운들리의 고객 개발에 대한 중요한 고민중 하나는, "TV를 시청 중인 사용자의 모바일에 전달되는 부가 정보는 과연 어떤 형태(UI/UX)가 되어야 할까?"입니다. 사용자는 정말이지 기술에는 관심이 없습니다. 단지 기존 행동 패턴에서 큰 노력을 들이지 않고도 좀 더 편해지길 바라는 것 뿐입니다. 우리는 이런 사용자 관점에서 고민했던 사람들이 분명 존재 했을 것이라 생각했고, 그들 중 인지심리학과 UX디자인의 대부인 도널드 노먼의 저서에 관심을 갖지 않을 수 없었습니다.

 본 블로그에서는 노먼 교수의 저서들을 요약하거나 구체적인 설명을 하진 않습니다 (PXD 블로그 또는 Design M 블로그를 참고하시면 더 심도 있는 내용을 확인 할 수 있습니다). 제가 이야기 하고자 하는 부분은 왜! 25년이나 지난 시점에서 UX의 고전으로 불리우던 '디자인과 인간심리 개정판(2013년)-아직까지 한글번역본은 미출간'을 출간했는 지에 대한 짧은 사색입니다.

25년의 시간이 흐른만큼 최신 예제를 추가


 본디 예제라는 것이 내용 이해를 쉽게 도와주는 역활을 해야 하는데, 워낙 오래전에 나온 책이다 보니 유선전화기나 슬라이더 프로젝터등이 최신 IT기계들로 소개되고 있었습니다. 젊은 독자들을 위해 예제를 바꾸는 노력을 기울이면서도 앞으로 바뀌지 않을 일상 생활속 예제들(냉장고, 오븐, 세면대 등)은 선별하여 유지하는 세심함도 엿볼 수 있습니다. 그림1을 보면 무엇에 쓰는 물건인지 아시겠나요? 저는 위키를 찾아보고서야 알게 되었습니다 :)

  

<그림1> 환등기



애매하게 사용되던 용어의 재정리와 상세 설명


어포던스(Affordance)와 시그니파이어(Signifier)

  1. 어포던스(Affordance)
     한국어로는 '행동유도성'이라고 표현할 수 있는데, 사물의 지각된 특성 또는 사물이 갖고 있는 실제적 특성, 특히 그것을 어떻게 사용 할 수 있느냐를 결정하는 근본적인 속성을 말합니다. 엄밀히 이야기하자면 도널드 노먼의 어포던스는 '지각된 행동유도성(Perceived Affordance) ' 이라고 말해야 합니다. 
  2. 시그니파이어(Signifier) 사람과 의사소통 하는 적절한 행동 즉, 어떤 마크나 소리등 인지 가능한 지표들을 말하고 의도 되었든 안 되었든지간에 Signifier는 가치 있는 단서가 됩니다.

 좀 더 쉽게 예를 들어보겠습니다. 문(door)은 누구에게나 열거나 닫는 행동을 유도합니다. 따라서 웹이나 모바일에서 문의 이미지나 아이콘은 입구나 출구가 될 것이라는 속성을 여전히 갖고 있습니다. 즉, 문이 갖고 있는 어포던스입니다.
 반면 Push / Pull 등의 텍스트는 시그니파이어라 할 수 있습니다. 물론 문이 열리는 소리나 잠기는 소리 또한 시그니파이어가 됩니다. 


개념 모형(Conceptual Model)과 심성모형(Mental model)

개념모형은 주로 과학적인 원리를 우리가 연상하는 과정을 생각해 보면 이해하기 쉽습니다. 도널드 노먼은 키노트 연설에서 물의 순환(물 → 수증기 → 비의 순환)을 사람들이 이해하는 것도 과학자들이 밝혀낸 원리를 이해하고 있기 때문이라고 말하고 있으며, 이것이 바로 개념모형이라고 말합니다. 즉, 개념적인 정리가 되어 있기 때문에 연상할 수 있는 모형인 것입니다.

심성모형 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형을 말합니다.  사람들은 심성모형을 경험, 훈련, 지시를 통해 형성하고 어떤 도구의 심성모형은 주로 그 장치의 작용과 가시적 구조를 지각하고 해석함으로써 형성됩니다. 심성모형 중 눈에 보이지 않는 개념적인 것들에 대한 한 부분을 개념모형으로 이해하면 되겠습니다.


도널드 노먼은 아직도 성장중?


기존 저서의 내용이 추가

1. 감성 디자인(Emotional Design)
 '이왕이면 다홍치마'라는 속담과 같은 디자인적 관점이 추가 되었습니다. 보기 좋은 UI는 실제 사용이 엄청 어렵다 하더라도, 사용자들은 쉽게 생각하게 된다는 이야기가 주 골자입니다. 

 "Complexity Is Good: It Is confusion That Is Bad" 라는 이야기인데, 처음엔 무슨 소리인가 했습니다. 지금껏 사용자 중심으로 생각하라고 이야기하다가 말이죠. 우리의 일상이 단순하지 않기 때문에 복잡해질 수밖에 없고, 문제는 사용자가 원치 않는 혼란스러움에 있다는 이야기입니다."다른 사람의 주방은 사용하기 어렵게 느껴지지만 나의 주방은 사용하기 편하다!"


다른 이론 소개

1. 디자인적 사고(Design Thinking)
 개인적으로 가장 공감하는 내용입니다. 역시 대가는 다릅니다. 
해결 해달라고 요청이 들어온 문제를 해결하지 않는다고 합니다. 근간에 있는 문제가 아니고 단순히 증상이기 때문이라는군요. 진짜 문제가 무엇인지 파악해야 성공적인 디자인이 가능하다고 강조합니다. 어떤 문제에 대해 이런 저런 분석을 들고 와서 해결책을 내놓은 사람들에게 "그래서 정확히 맞는 문제를 해결했다는 것을 어떻게 알 수 있나요?" 라고 물어보면 혼란에 빠진다는 이야기는 통쾌하기까지 합니다. 실제 세계에서는 문제가 일정한 조건을 가지고 해결하기 쉽게 나타나는 경우가 많지 않으므로 문제의 표면이 아닌 핵심을 봐야한다는 말에 경의를 표합니다.

2. 인간중심디자인(HCD, Human Centered Design)
 도널드 노먼이 디자인과 인간심리 초판을 발행한 시기에는 이런 개념 조차 없었을테고, 오히려 인간중심디자인에 영향을 끼친 저자가 책에서 별도 내용을 다룬 점은 절대 고수의 본질에 대한 고민이 느껴지는 대목입니다.


<그림2> Human Centered Design Process

  1. 관찰(공감과 문제정의)   고객 및 고려 중인 프로덕트를 사용할 사람들에 대한 리서치. 잠재 고객의 활동을 파악하고 관심과 모티브, 정말로 원하는 것(진짜 문제)을 파악해야 함. 가장 중요한 테크닉은 실제로 프로덕트나 서비스가 사용될 곳의 일반적인 환경을 파악하는 것입니다.
  2. 아이디어   디자인 요구사항들이 도출되면 구현 가능한 방법을 만들어내야 한다. 아이데이션, 창의성이 가장 중요한 영역. 브레인스토밍을 근간으로 하는 많은 아이데이션 방법론이 있습니다. 아이디어를 낼 때에는 다음과 같은  기준을 갖습니다.
    1. 최대한 많은 아이디어를 내놓기
    2. 제약을 고려하지 않고 최대한 창의적으로 활동하기 (비판 금지!)
    3. 모든 것에 대해 질문하기 - 소위 말하는 "멍청한" 질문 포함. 누구나 답을 알 수 있는 질문에 대한 답은 자명하지만, 종종 자명하지 않을 때도 있기 때문입니다.
  3. 프로토타이핑    아이디어가 말이 되는지 테스트하는 방법. 프로토타입이나 목업을 빠르게 만들어서 아이디어와 프로세스를 체크. 도구는 크게 중요하지 않음. 정말로 도구는 하나도 중요하지 않습니다. 일단 해보는 것이 하지 않는 것보다는 무조건 많이 배웁니다.
  4. 테스팅    프로덕트 주요 타겟과 거의 비슷한 작은 그룹을 만들어 테스트하기. 그들이 프로덕트를 실제로 사용하게 될 때와 거의 유사한 단계의 프로토타입을 제공해야 함. 만약 한 사람만을 위한 프로덕트라면 테스트 인원도 한 명이어야 함.(그러나 거의 유사한 단계의 프로토타입을 만드는데 너무 공을 들이는 것보다는 어설픈 프로토타입으로 빠르게 테스트하는것이 결과적으로 고객을 더 빨리 이해할 수 있음) 이후 테스트 인원이 그들이 겪은 절차에 대한 자세한 정보를 수집하고, 질문해야 함. 프로토타이핑처럼 테스팅도 문제 파악 단계와 문제 해결 단계 양쪽에서 모두 시행되어야 합니다.
  5. 반복    인간 중심 디자인 방법론의 반복 수행은 프로덕트의 지속적인 수정과 향상을 목표로 함. IDEO의 격언 "자주, 바르게 실패하기"의 목적과 상통합니다.


교수에서 사업가로서의 변화


 초판을 쓸 때만 해도 도널드 노먼은 아카데미에만 있었던 학자였습니다. 이후 다양한 실무와 산업 현장을 통해 사용성이 뛰어나다는 것만으로 제품의 상업적 성공을 보장할 수 없다는 것을 알게 되었으리라 생각합니다. 성공하는 제품을 위해서는 사업을 이해하는 것이 뒷받침되어야 함을 개정판에 추가하였습니다.

  1.  실제 현실은 이론대로 돌아가지 않는다. 이것은 사업적인 문제나 디자인 팀 구성의 문제, 시간이나 돈의 문제 때문에 그렇습니다. 이를 해결하기 위해서는 언제나 필드에 나가있는 디자인 리서처를 통해 항상 고객과 가능한 제품에 대해 리서치해야 한다고 말하고 있습니다. 이러한 환경에서 디자이너는 문제를 미리 파악해서 해결책을 내놓을 수 있기 때문입니다. 서로를 이해하고 존중하는 별도의 디자인 팀이 필요함에 공감합니다. 정말이지 최소 한 명(한 명도 1인팀이니까)의 디자이너는 반드시 있어야 합니다. 그래야 시간과 돈을 더 아낍니다. 
  2. 제품은 복잡하고 여러 상반된 요구사항을 가지고 있다. 디자이너는 클라이언트를 만족시켜야 하는데, 클라이언트는 엔드 유저가 아닐 수도 있습니다. 클라이언트의 최우선 기준이 비용에 맞춰질 때도 있습니다. 디자인은 클라이언트의 우선 요구 조건이나, 내부에서 진행되는 경우에는 여러 우선순위들을 고려해서 진행되어야 하는 복잡한 업무입니다. 

개정판 출간의 이유 한줄 요약


더 쉬운 설명(easy to use)을 통해
독자의 이해도를 향상(easy to learn)시키고,
그로 인해 오래동안 기억에 남게(easy to remember) 하고자 하는 것

앞으로는 UX 관련 글뿐 아니라, 사용자에 대한 고민도 함께 공유해 나가겠습니다.

읽어주셔서 감사합니다!


댓글

이 블로그의 인기 게시물

[Insight] 안드로이드 백그라운드 서비스 개발시 고려해야 할 사항

[Insight] 안드로이드 백그라운드 서비스 개발시 고려해야 할 사항

지난 시간엔 사운들리 백엔드에 대해 설명을 드렸었죠. 이번 시간엔 사운들리 서비스중 클라이언트에 해당하는 안드로이드 SDK, 그 중에서도 백그라운드 서비스에 초점을 맞추어 설명을 해 볼까 합니다. 안드로이드의 특징 중 하나로 Service를 들 수 있습니다. 이 서비스란 녀석은 백그라운드에서 실행 될 수 있다는 점이 가장 큰 특징인데요. 물론 iOS 에서도 일부 지원은 합니다만 매우 제한적인 경우(음악 재생 등)에만 사용 가능합니다.
제가 생각하는 백그라운드 서비스 개발 시 유의 사항은 아래와 같습니다. 동작 기간 - 상시 동작 해야 하는가, 특정 조건에서 특정 작업을 할때만 동작 해야 하는가글로벌 프로세스 사용 유무 - 서로 다른 어플리케이션에서 접근이 가능 해야 하는가동작 조건 - 특정 시간 혹은 기간마다 동작 해야 하는가, 특정 이벤트 발생시 동작 해야 하는가그 외에도 많은 부분들이 있지만 일단 저 정도만 고려해도 개인적인 생각으로는 충분히 개발 가능하다고 생각 합니다. 그러면 각각에 대해서 좀 더 자세하게 알아 볼까요?
1. 동작 기간동작 기간에 대해서 이야기 하기 전에 먼저 유저 레벨에서 가장 많이 사용하는 Service 와 IntentService 의 차이점에 대하여 짚고 넘어가보겠습니다. Service 를 상속`Context#startService//Context#stopService` 혹은 `Context#bindService(w/BIND_AUTO_CREATE)//Context#unbindService` 를 통해 수명 조절 (Service 내에서 Service#stopSelf 를 호출하는 방법도 있습니다.)Service 시작된 이후에 커뮤니케이션 가능수명 종료 API(stopService or unbindService) 를 호출 하기 전에는 프로세스가 사라지지 않음 (물론 LMK에 의해서 종료 된다던지 등등이 있지만 여기서는 논외로 하겠습니다.)IntentService 를 상속start…

[스타트업] [Insight] 사운들리 코드 품질 관리 이야기

[스타트업] [Insight] 사운들리 코드 품질 관리 이야기
 안녕하세요 "사운들리"입니다 :)

오늘은 사운들리의 코드 품질 관리에 대해 이야기 해보려 합니다. 몇몇 개발자에게는 지루하고 악몽같은 이야기일 수 있겠네요.
제 경우에는 예전에는 이런 품질이라는 단어를 멀리했지만 결국 제가 작성한 코드에 발목을 많이 잡히다 보니, 자연스레 관심을 갖게 되었습니다.

일단, 어떤 소프트웨어가 좋은 품질의 소프트웨어일까요?
좋은 품질이란?  책에 나올법한 내용을 보면, 아래와 같은 항목을 토대로 소프트웨어 품질을 판단한다고 합니다.
ISO/IEC 9126 : Software engineering - Product quality Functionality: 명시된 요구사항을 잘 충족했는지Reliability: 명시된 조건과 시간 아래에서 일정 성능을 유지 하는지Usability: 사용하기 위해 어느정도의 노력과 자원이 필요한지Efficiency: 소모 자원과 성능간의 효율Maintainability: 수정하기 위해 어느정도의 노력이 필요한지Portability: 다른 환경에서도 사용 할수 있는지출처: https://en.wikipedia.org/wiki/ISO/IEC_9126  뭔가 복잡해 보이지만, 결국 개발자라면 위의 항목은 누구나 추구하게 되는 가치라고 생각 합니다.

그런데 말입니다.이런 좋은 내용을 마음 속으로만 간직한 채 코드를 작성하면 정말 좋은 소프트웨어를 만들 수 있을까요? 저는 객관적인 방법으로 코드를 평가한다면 좋은 피드백이 될 것이라고 생각합니다. (물론 이 성적표를 남에게 보여주는 것과는 다른 문제에요 ㅎㅎ)
어떻게 품질을 체크하는가  소프트웨어의 품질을 체크하는 데에 다양한 방법과 툴이 제시되고 있는데요, 저는 크게 두 가지로 분류 해보겠습니다.
유저 입장의 품질: 유저의 요구사항에 맞는 소프트웨어인지 체크개발자 입장의 품질: 내가 지금 이 코드를 의도한 대로 잘 작성하고 있는지 체크 유저 입장의 품질은 언급하지 않아도 중요함을 누구나 알고 있습니다. 이…

[스타트업] [Insight] 사운들리 방송 송출테스트 이야기

[스타트업] [Insight] 사운들리 방송 송출테스트 이야기
안녕하세요 "사운들리"입니다 :)


 오늘은 사운들리 사운드 비콘을 방송 콘텐츠에 실어 보내어 시청자의 모바일로 유용한 정보를 전달하기 위해 가장 중요하고, 힘들지만 마치고 나면 모든 팀원들이 가장 뿌듯함을 느끼는 방송 송출테스트 이야기를 하려 합니다.


송출 테스트, 사운들리가 그 어려운 걸 또 해냅니다.
<디지털 방송의 송출 경로>
 위 그림은 우리나라 디지털 방송의 송출 경로의 한 예입니다. 실제 방송국이 지상파인지, 종편인지, 기타 케이블 채널인지 등에 따라 세부적인 변화가 더 있을 수 있지만, 위 그림만 보셔도 충분히 복잡해 보이실 것입니다.
 우리나라는 DMB 등 일부 영역을 제외하고 디지털 방송 영역에서 대부분 미국식 표준 ATSC 관련 표준을 따르고 있지만, 유럽 국가와 뉴질랜드 등은 유럽식 표준인 DVB 관련 표준을 따르고 있습니다. 사운들리가 실제 송출테스트를 통해 증명하기 전까지 마주친 수많은 방송 실무자들, 방송 장비 업계 관계자, 학계 연구자들은 다양한 방송 장비에 의해서 사운들리 사운드 비콘이 유실되거나 왜곡되어 서비스가 불가능할 것 이라며 포기하라고 하였습니다.

 하지만 이렇게 복잡하고 다양한 환경에서 사운들리는 대한민국과 터키에서 모두 서비스를 성공(!)함으로써 미국식 디지털 방송의 대표적인 예인 대한민국과 전형적인 유럽식 디지털 방송의 예인 터키 모두에서 서비스 제공이 가능하다는 것을 증명해 냈습니다 :)


방송 송출, 그 험난한 검증의 시간  그렇다면 이렇게 복잡한 방송망을 거치고 나서도 사운들리 사운드 비콘이 시청자의 모바일로 안전하고 완전하게 전달될 수 있다는 것을 테스트하기 위해 어떤 과정을 거치는지 살펴보겠습니다.

 사운들리가 방송 쪽으로 사업 방향을 잡고 나서 가장 힘들고 오랜 시간이 걸린 부분 중 하나가 방송국들에게 기술의 안전성과 안정성, 정확성을 설득하는 것이었습니다.
기술의 안전성: 시청자 또는 반려 동물에게 선진국들의 가장 보수적인 규제 보다…